From ecrit-bounces@ietf.org Tue Jan 02 18:29:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1t4f-00066Q-Hs; Tue, 02 Jan 2007 18:29:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1t4e-00066D-LS for ecrit@ietf.org; Tue, 02 Jan 2007 18:29:40 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1t4d-0000Rx-9Z for ecrit@ietf.org; Tue, 02 Jan 2007 18:29:40 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 02 Jan 2007 15:29:39 -0800 X-IronPort-AV: i="4.12,228,1165219200"; d="scan'208"; a="97370319:sNHT42232068" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l02NTcWa007329 for ; Tue, 2 Jan 2007 15:29:38 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l02NTc4g026912 for ; Tue, 2 Jan 2007 15:29:38 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 18:29:37 -0500 Received: from jmpolk-wxp.cisco.com ([10.89.16.141]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 18:29:37 -0500 Message-Id: <4.3.2.7.2.20070102172322.034170c0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 02 Jan 2007 17:29:17 -0600 To: "'ecrit@ietf.org'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 02 Jan 2007 23:29:37.0868 (UTC) FILETIME=[DE7038C0:01C72EC5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1681; t=1167780578; x=1168644578; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20New=20Location=20Conveyance=20-06=20submitted |Sender:=20; bh=555Lv296P/McuReTEJtZbelWk1aSnJnNLuvC1Lo88Fc=; b=nA4/tX+nRus8znvmbn/5x6ENbgu8XSkdb613D6S2voWqN0TKZgeCb71yKryVmPfPAP7VSr6E fdx91V49NaIRtCTjokUDaD1NBoYyOjIkoCWUJbdXAUXt03OZxdhxGnsk; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Ecrit] New Location Conveyance -06 submitted X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I've submitted the -06 version of Location Conveyance for review http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-06.txt This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The extension covers end to end conveyance as well as location-based routing, where proxy servers make routing decisions based on the location of the UAC. The changes from -05 to -06 are as follows: - cleaned up some inconsistencies wrt the S/MIME example in Section 4.2 - changed the ABNF to include the ability to indicate which SIP element inserted a particular location URI, and how a message routing server indicates which location the message was routed upon (based on the location in the message) - give examples of the above in section 5.3.1 - changed the granular error code from a Reason header indication to a Warning code indication (section 3.4), and IANA registered 14 new Warning codes in this document - As a consequence of the above bullet, changed the specific SIP element behaviors of each SIP element regarding sending or receiving a 424 response with a Warning header - Added rules about indicating which SIP element inserted a particular location into a message (a new Geolocation header parameter), as well as when a server adds another new header parameter indicating the request was routed based on a particular location included in the message Please comment on the SIP WG list James _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 04 14:42:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2YU8-0004Fy-CO; Thu, 04 Jan 2007 14:42:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2YU6-0004Fn-O5 for ecrit@ietf.org; Thu, 04 Jan 2007 14:42:43 -0500 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2YU4-0006Sl-Gg for ecrit@ietf.org; Thu, 04 Jan 2007 14:42:42 -0500 Received: from [172.16.10.88] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 04 Jan 2007 14:42:00 -0500 id 015884A8.459D5888.0000732C Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <05301591-AC5B-40C2-B78E-342ED12B5F0B@hxr.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Andrew Newton Date: Thu, 4 Jan 2007 14:42:24 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ecrit] call marking X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'm not sure where we left off with this issue, but it needs to be resolved. Previously, I leaned toward the sos URN in the request URI (I believe this was Henning's suggestion). I no longer think this is a good idea, because the request URI is actively used in emergency calls today, many times containing psuedo-codes relevant to call routing. Admittedly, this is an artifact of gatewaying to the PSTN, but picking another method that would remain compatible with this practice seems to offer easier transition. For the clueless, why is the Priority header with the "emergency" value not useable here? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 04 14:54:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Yfa-0004Zc-1Z; Thu, 04 Jan 2007 14:54:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2YfY-0004VN-Jp for ecrit@ietf.org; Thu, 04 Jan 2007 14:54:32 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2YfX-0000OY-BX for ecrit@ietf.org; Thu, 04 Jan 2007 14:54:32 -0500 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l04JsTCk004324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Jan 2007 14:54:30 -0500 (EST) In-Reply-To: <05301591-AC5B-40C2-B78E-342ED12B5F0B@hxr.us> References: <05301591-AC5B-40C2-B78E-342ED12B5F0B@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <450D7FDA-2F7E-4E85-B90D-E9CF205A030F@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] call marking Date: Thu, 4 Jan 2007 14:55:48 -0500 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Maybe it would be helpful to discuss requirements first and who would use the call marking for what. The first usage is presumably for call routing. This matters only if a proxy needs to do something different to route emergency calls, such as invoke LoST, and if it sees something other than emergency calls. (For example, if we have hierarchical routing, the state proxy will simply forward calls to one of the county proxies, but all such calls need to be re-mapped. Or, alternatively, the URL identifies emergency calls for that destination, without any standardized convention, such as sip:some-local-string@esr.queens.ny.us) A second usage is that the destination (PSAP) can tell if the call is an emergency or "business" call. One could argue that the destination URL is the appropriate marker for that, without any standardization. In other words, as long as a PSAP doesn't use its business E.164 number or SIP URL as the service URL in the LoST record, there is no problem. Again, no standardization is needed. Another, orthogonal, usage is to provide some kind of prioritization in call handling. This is more closely related to the SIP Resource- Priority header. So, what are the goals and when precisely do we need this? Henning On Jan 4, 2007, at 2:42 PM, Andrew Newton wrote: > I'm not sure where we left off with this issue, but it needs to be > resolved. > > Previously, I leaned toward the sos URN in the request URI (I > believe this was Henning's suggestion). I no longer think this is > a good idea, because the request URI is actively used in emergency > calls today, many times containing psuedo-codes relevant to call > routing. Admittedly, this is an artifact of gatewaying to the > PSTN, but picking another method that would remain compatible with > this practice seems to offer easier transition. > > For the clueless, why is the Priority header with the "emergency" > value not useable here? > > -andy > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 04 14:57:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2YiX-0006U4-SC; Thu, 04 Jan 2007 14:57:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2YiX-0006SF-4I for ecrit@ietf.org; Thu, 04 Jan 2007 14:57:37 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2YiV-0001Si-R5 for ecrit@ietf.org; Thu, 04 Jan 2007 14:57:37 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 04 Jan 2007 14:57:35 -0500 X-IronPort-AV: i="4.12,239,1165208400"; d="scan'208"; a="110892832:sNHT45605644" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l04JvZBi020094; Thu, 4 Jan 2007 14:57:35 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l04JvZ7f020447; Thu, 4 Jan 2007 14:57:35 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 14:57:35 -0500 Received: from jmpolk-wxp.cisco.com ([10.89.20.131]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 14:57:34 -0500 Message-Id: <4.3.2.7.2.20070104135206.03c53f00@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Jan 2007 13:57:33 -0600 To: Andrew Newton , ECRIT From: "James M. Polk" Subject: Re: [Ecrit] call marking In-Reply-To: <05301591-AC5B-40C2-B78E-342ED12B5F0B@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 04 Jan 2007 19:57:34.0839 (UTC) FILETIME=[93BF9070:01C7303A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1402; t=1167940655; x=1168804655; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20call=20marking |Sender:=20 |To:=20Andrew=20Newton=20,=20ECRIT=20; bh=OzpKj4eW5WzWQ1fml4zcIU757mJKq7Vqu0XTHFb3IKo=; b=iARASHPH/I5HMnJhHpdcvjpDP3NxsjlbtfTiNWCFbgwsX+IlMEANRuOtJMu4Y5pvo5ihjf7R Bd8ZTLitEKsZ4cpDD0f8bQ676ndFNvDY+HARxltScNSCA+EQ1Ny/o0d+; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 02:42 PM 1/4/2007 -0500, Andrew Newton wrote: >I'm not sure where we left off with this issue, but it needs to be >resolved. > >Previously, I leaned toward the sos URN in the request URI (I believe >this was Henning's suggestion). I no longer think this is a good >idea, because the request URI is actively used in emergency calls >today, many times containing psuedo-codes relevant to call routing. >Admittedly, this is an artifact of gatewaying to the PSTN, but >picking another method that would remain compatible with this >practice seems to offer easier transition. I agree with Andy that this indication needs to be somewhere other than the R-URI that may change or be otherwise not obvious (perhaps it is not following a certain "emergency" format we haven't come up with yet). I feel whatever the indication is, it needs to be obvious what it means. >For the clueless, why is the Priority header with the "emergency" >value not useable here? The Priority header is for the recipient end user to determine how important the message was to the sender, and can get confused with other uses (such as a GETS (IEPREP) call, does that call also get marked as an emergency call)? my 2 and a 3rd cents James >-andy > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 04 15:02:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2YnT-0001Fg-Jm; Thu, 04 Jan 2007 15:02:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2YnS-0001FZ-Hx for ecrit@ietf.org; Thu, 04 Jan 2007 15:02:42 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2YnR-0002NO-6H for ecrit@ietf.org; Thu, 04 Jan 2007 15:02:42 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1H2YnF-00020y-0M; Thu, 04 Jan 2007 14:02:29 -0600 From: "Brian Rosen" To: "'Andrew Newton'" , "'ECRIT'" Subject: RE: [Ecrit] call marking Date: Thu, 4 Jan 2007 15:02:37 -0500 Message-ID: <021701c7303b$4a051800$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AccwOH+TrQ2qYtZnTL2IvSy+6hXxLAAANjzw In-Reply-To: <05301591-AC5B-40C2-B78E-342ED12B5F0B@hxr.us> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think the current proposal is to leave the sos URN in the Request URI and change the top of the Route stack as the call is routed, in line with Jonathan's mechanism for a similar problem with GRUUs. I think your reasoning is specious because you are talking about an upgraded phone or network, that understands the sos URI, and uses it, and you want to have backwards compatibility with the existing systems while keeping the new marking. That won't work. If you take a new (in NENA we would call that an "i3" call) and you want to put it in the existing ("i2") system, then the sos URI is meaningless within that system, and like a current i2 call, you don't need or want special marking. This would mean that a call enters a proxy with urn:service:sos in the Request URI, and some meaningful thing in a Route header. The proxy determines that the call has to be routed on the i2 network. It pops the Route header and replaces the Request URI with what it needs to do to get it to route in the i2 network. It would then look just like any other i2 call. If you attempt to send the call with any marking, the i2 system may well be unhappy, but even if it was okay (as it really should be), the marking, however you do it, is meaningless. Now, I do want to use the RP header, because we really do want resource priority in the signaling. Similarly, I'd like to mark the media, because I'd like some priority there also (but only packet level stuff, so I mean a DSCP). The former COULD be implied by whatever marking we end up with, but I don't like implications. I'd rather be explicit. But that doesn't affect the issue of sos in the RequestURI. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Thursday, January 04, 2007 2:42 PM > To: ECRIT > Subject: [Ecrit] call marking > > I'm not sure where we left off with this issue, but it needs to be > resolved. > > Previously, I leaned toward the sos URN in the request URI (I believe > this was Henning's suggestion). I no longer think this is a good > idea, because the request URI is actively used in emergency calls > today, many times containing psuedo-codes relevant to call routing. > Admittedly, this is an artifact of gatewaying to the PSTN, but > picking another method that would remain compatible with this > practice seems to offer easier transition. > > For the clueless, why is the Priority header with the "emergency" > value not useable here? > > -andy > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 04 16:40:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2aJn-00086y-GT; Thu, 04 Jan 2007 16:40:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2aJm-00086h-85 for ecrit@ietf.org; Thu, 04 Jan 2007 16:40:10 -0500 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2aJk-0002PN-1p for ecrit@ietf.org; Thu, 04 Jan 2007 16:40:10 -0500 Received: from [172.16.10.88] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 04 Jan 2007 16:39:29 -0500 id 015884AB.459D7411.000011F3 In-Reply-To: <450D7FDA-2F7E-4E85-B90D-E9CF205A030F@cs.columbia.edu> References: <05301591-AC5B-40C2-B78E-342ED12B5F0B@hxr.us> <450D7FDA-2F7E-4E85-B90D-E9CF205A030F@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <86ADE804-CA44-4CCA-91B7-B18280891327@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] call marking Date: Thu, 4 Jan 2007 16:39:53 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jan 4, 2007, at 2:55 PM, Henning Schulzrinne wrote: > Maybe it would be helpful to discuss requirements first and who > would use the call marking for what. > [...snip..] > So, what are the goals and when precisely do we need this? I agree that we need to understand the requirement. And I'd prefer that the requirement be this: "Marking a call as an emergency call without implying anything else." The arguments, as I understand them, against the resource priority header is that it overloading another mechanism: I guess some jurisdictions don't think emergency calls are worthy of a priority higher than normal. I'd say the argument is also true for using the request URI. You are overloading another mechanism that has another purpose. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 04 16:42:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2aM3-0000xI-Et; Thu, 04 Jan 2007 16:42:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2aM2-0000x9-43 for ecrit@ietf.org; Thu, 04 Jan 2007 16:42:30 -0500 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2aLz-0002xS-AN for ecrit@ietf.org; Thu, 04 Jan 2007 16:42:30 -0500 Received: from [172.16.10.88] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 04 Jan 2007 16:41:57 -0500 id 015884AB.459D74A5.000012B2 In-Reply-To: <4.3.2.7.2.20070104135206.03c53f00@email.cisco.com> References: <4.3.2.7.2.20070104135206.03c53f00@email.cisco.com> Mime-Version: 1.0 Message-Id: From: Andrew Newton Subject: Re: [Ecrit] call marking Date: Thu, 4 Jan 2007 16:42:23 -0500 To: "James M. Polk" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1173318706==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============1173318706== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-4790-1167946918-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-4790-1167946918-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Jan 4, 2007, at 2:57 PM, James M. Polk wrote: > The Priority header is for the recipient end user to determine how > important the message was to the sender, and can get confused with > other uses (such as a GETS (IEPREP) call, does that call also get > marked as an emergency call)? Being unfamiliar with GETS, I don't know. However, I do see a distinction between the recipient understanding the call is marked as an emergency and other elements in the call path understanding the same. I'm not sure the distinction is relevant, as I cannot think of a scenario where it matters. But I'd welcome such education. -andy --=_zeke.ecotroph.net-4790-1167946918-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.3
On Jan 4, 2007, at 2:57= PM, James M. Polk wrote:

The Prio= rity header is for the recipient end user to determine how important the = message was to the sender, and can get confused with other uses (such as = a GETS (IEPREP) call, does that call also get marked as an emergency call= )?


Being unfamiliar with GETS, I d= on't know.=A0 However, I do see a distinction between the recipient under= standing the call is marked as an emergency and other elements in the cal= l path understanding the same.=A0 I'm not sure the distinction is relevan= t, as I cannot think of a scenario where it matters.=A0 But I'd welcome s= uch education.

-andy --=_zeke.ecotroph.net-4790-1167946918-0001-2-- --===============1173318706== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1173318706==-- From ecrit-bounces@ietf.org Thu Jan 04 16:46:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2aPx-0006gt-0A; Thu, 04 Jan 2007 16:46:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2aPw-0006fO-4a for ecrit@ietf.org; Thu, 04 Jan 2007 16:46:32 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2aPu-0003fb-Sy for ecrit@ietf.org; Thu, 04 Jan 2007 16:46:32 -0500 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l04LkRne020006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Jan 2007 16:46:27 -0500 (EST) In-Reply-To: <86ADE804-CA44-4CCA-91B7-B18280891327@hxr.us> References: <05301591-AC5B-40C2-B78E-342ED12B5F0B@hxr.us> <450D7FDA-2F7E-4E85-B90D-E9CF205A030F@cs.columbia.edu> <86ADE804-CA44-4CCA-91B7-B18280891327@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] call marking Date: Thu, 4 Jan 2007 16:47:45 -0500 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org But marking for what purpose? Without knowing what this supposed to be used for, it's hard to design a mechanism that has the right properties. As one obvious issue, if the marking is just informational, we wouldn't care if somebody marked calls to the local pizza delivery outfit as "emergency" if they are hungry. But in that case, I'm somewhat at a loss as to why this would be useful for real emergency calls. Also, in general, I think it's a good design approach to see if there's a broader context here. For example, is this a special instance of marking types or classes of calls? On Jan 4, 2007, at 4:39 PM, Andrew Newton wrote: > > On Jan 4, 2007, at 2:55 PM, Henning Schulzrinne wrote: > >> Maybe it would be helpful to discuss requirements first and who >> would use the call marking for what. >> > [...snip..] >> So, what are the goals and when precisely do we need this? > > I agree that we need to understand the requirement. And I'd prefer > that the requirement be this: "Marking a call as an emergency call > without implying anything else." The arguments, as I understand > them, against the resource priority header is that it overloading > another mechanism: I guess some jurisdictions don't think emergency > calls are worthy of a priority higher than normal. I'd say the > argument is also true for using the request URI. You are > overloading another mechanism that has another purpose. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 04 16:50:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2aTc-000137-T3; Thu, 04 Jan 2007 16:50:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2aTa-00011t-Hb for ecrit@ietf.org; Thu, 04 Jan 2007 16:50:19 -0500 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2aTZ-0004E3-AE for ecrit@ietf.org; Thu, 04 Jan 2007 16:50:18 -0500 Received: from [172.16.10.88] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 04 Jan 2007 16:49:46 -0500 id 015884AD.459D767A.00001523 In-Reply-To: <021701c7303b$4a051800$640fa8c0@cis.neustar.com> References: <021701c7303b$4a051800$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] call marking Date: Thu, 4 Jan 2007 16:50:13 -0500 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jan 4, 2007, at 3:02 PM, Brian Rosen wrote: > I think the current proposal is to leave the sos URN in the Request > URI and > change the top of the Route stack as the call is routed, in line with > Jonathan's mechanism for a similar problem with GRUUs. > > I think your reasoning is specious because you are talking about an > upgraded > phone or network, that understands the sos URI, and uses it, and > you want to > have backwards compatibility with the existing systems while > keeping the new > marking. That won't work. > > If you take a new (in NENA we would call that an "i3" call) and you > want to > put it in the existing ("i2") system, then the sos URI is > meaningless within > that system, and like a current i2 call, you don't need or want > special > marking. > > This would mean that a call enters a proxy with urn:service:sos in the > Request URI, and some meaningful thing in a Route header. The proxy > determines that the call has to be routed on the i2 network. It > pops the > Route header and replaces the Request URI with what it needs to do > to get it > to route in the i2 network. It would then look just like any other > i2 call. > If you attempt to send the call with any marking, the i2 system may > well be > unhappy, but even if it was okay (as it really should be), the > marking, > however you do it, is meaningless. This seems to be a specious argument about i2 being fragile, and that it requires the R-URI to be the sos URN. Is either really true? I sure hope that everyone understands there will be no flag day regarding LoST. VSPs will have to operate in both worlds, where some LoST queries resolve and others do not. Those that do not will require the routing to fall back to the old SIP termination methods. When LoST does not produce a result, I'd still like to mark the call as an emergency in a universal and standard manner and I'd still like to have a GeoLocation header. Just because the call may not be routable via LoST does not mean it won't terminate to an IP end point. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 04 16:51:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2aV1-0001xX-0r; Thu, 04 Jan 2007 16:51:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2aUz-0001wx-9y for ecrit@ietf.org; Thu, 04 Jan 2007 16:51:45 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2aUw-0004Oh-W1 for ecrit@ietf.org; Thu, 04 Jan 2007 16:51:45 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 04 Jan 2007 13:51:42 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l04LpgQH028207; Thu, 4 Jan 2007 13:51:42 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l04LpDJD029315; Thu, 4 Jan 2007 13:51:42 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 16:51:35 -0500 Received: from jmpolk-wxp.cisco.com ([10.89.20.131]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 16:51:34 -0500 Message-Id: <4.3.2.7.2.20070104154834.03426d08@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Jan 2007 15:51:33 -0600 To: "Brian Rosen" , "'ECRIT'" From: "James M. Polk" Subject: RE: [Ecrit] call marking In-Reply-To: <021701c7303b$4a051800$640fa8c0@cis.neustar.com> References: <05301591-AC5B-40C2-B78E-342ED12B5F0B@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 04 Jan 2007 21:51:35.0263 (UTC) FILETIME=[80F56EF0:01C7304A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=632; t=1167947502; x=1168811502; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Ecrit]=20call=20marking |Sender:=20; bh=3xWHiCN3k2CLW73u0q/kGLarW5G5tJA2+oBbvRNLs3w=; b=Au39F8n06JUPSUEUNys/HP7/IL+M2ZDCQbEldX19Ic/JWDDcgvE9z6ZN1UZzxJi0VTZVhlev OijYrl5VCfJVP5bENUQxdJpM2o/qFQSdINjBWqLtTEaGlohXfgoAQ2iF; Authentication-Results: sj-dkim-5; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 03:02 PM 1/4/2007 -0500, Brian Rosen wrote: >Now, I do want to use the RP header, because we really do want resource >priority in the signaling. Similarly, I'd like to mark the media, because >I'd like some priority there also (but only packet level stuff, so I mean a >DSCP). In this regard, there is this TSVWG ID that we authors believe can be used for 911/112 calling too (plus ETS calling) http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-admitted-realtime-dscp-00.txt >The former COULD be implied by whatever marking we end up with, but >I don't like implications. I'd rather be explicit. > >Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 04 16:52:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2aVG-00022K-Di; Thu, 04 Jan 2007 16:52:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2aVF-00022D-4L for ecrit@ietf.org; Thu, 04 Jan 2007 16:52:01 -0500 Received: from smtp02out.dot.gov ([199.79.178.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2aVB-0004Pl-S3 for ecrit@ietf.org; Thu, 04 Jan 2007 16:52:01 -0500 Received: from dothqnwms005.ad.dot.gov ([152.119.86.155]) by smtp02out.dot.gov with ESMTP; 04 Jan 2007 16:51:56 -0500 Received: from OSTMAIL03VS3.ad.dot.gov ([152.119.86.69]) by DOTHQNWMS005.ad.dot.gov with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 16:51:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] call marking Date: Thu, 4 Jan 2007 16:51:54 -0500 Message-ID: <0A0D0FBCB8154043B909C961D02A7A44031DAECB@OSTMAIL03VS3.ad.dot.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] call marking Thread-Index: AccwSc3enPfx5Y7XT960mRy2aAN1vAAAD+Og From: To: , X-OriginalArrivalTime: 04 Jan 2007 21:51:55.0296 (UTC) FILETIME=[8CE63A00:01C7304A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org You're both on to something here, but remember (and Andy mentions it with other mechanisms), MOST PSAPS, via their Computer Aided Dispatch systems, will be overriding the priority codes for all calls as they're processed according to the Standard Operating Procedures within their agency. The call path (network routing) will identify the call as "an emergency call" (based on the actual "line" of delivery)... The "marker" will be provided elsewhere (other mechanisms) for the most part. If you think it is necessary for your routing practices, that's another issue, but from the operational aspect of marking calls as "emergencies" -- it's done elsewhere and differently from PSAP to PSAP. For what it's worth. Jenny=20 -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Thursday, January 04, 2007 4:48 PM To: Andrew Newton Cc: ECRIT Subject: Re: [Ecrit] call marking But marking for what purpose? Without knowing what this supposed to be used for, it's hard to design a mechanism that has the right properties. As one obvious issue, if the marking is just informational, we wouldn't care if somebody marked calls to the local pizza delivery outfit as "emergency" if they are hungry. But in that case, I'm somewhat at a loss as to why this would be useful for real emergency calls. Also, in general, I think it's a good design approach to see if there's a broader context here. For example, is this a special instance of marking types or classes of calls? On Jan 4, 2007, at 4:39 PM, Andrew Newton wrote: > > On Jan 4, 2007, at 2:55 PM, Henning Schulzrinne wrote: > >> Maybe it would be helpful to discuss requirements first and who would >> use the call marking for what. >> > [...snip..] >> So, what are the goals and when precisely do we need this? > > I agree that we need to understand the requirement. And I'd prefer=20 > that the requirement be this: "Marking a call as an emergency call=20 > without implying anything else." The arguments, as I understand them, > against the resource priority header is that it overloading another=20 > mechanism: I guess some jurisdictions don't think emergency calls are=20 > worthy of a priority higher than normal. I'd say the argument is also > true for using the request URI. You are overloading another mechanism > that has another purpose. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 04 16:54:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2aXQ-0002XU-Rb; Thu, 04 Jan 2007 16:54:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2aXP-0002W9-P2 for ecrit@ietf.org; Thu, 04 Jan 2007 16:54:15 -0500 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2aXO-0004uW-I4 for ecrit@ietf.org; Thu, 04 Jan 2007 16:54:15 -0500 Received: from [172.16.10.88] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 04 Jan 2007 16:53:44 -0500 id 01588484.459D7768.00001668 In-Reply-To: References: <05301591-AC5B-40C2-B78E-342ED12B5F0B@hxr.us> <450D7FDA-2F7E-4E85-B90D-E9CF205A030F@cs.columbia.edu> <86ADE804-CA44-4CCA-91B7-B18280891327@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5BAFA1E2-781B-4698-B264-3E9D11ECF6FC@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] call marking Date: Thu, 4 Jan 2007 16:54:11 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jan 4, 2007, at 4:47 PM, Henning Schulzrinne wrote: > But marking for what purpose? Without knowing what this supposed to > be used for, it's hard to design a mechanism that has the right > properties. As one obvious issue, if the marking is just > informational, we wouldn't care if somebody marked calls to the > local pizza delivery outfit as "emergency" if they are hungry. But > in that case, I'm somewhat at a loss as to why this would be useful > for real emergency calls. The purpose of "implying nothing else" is that you do not overload mechanisms that are already in use and may have unknown side affects. > Also, in general, I think it's a good design approach to see if > there's a broader context here. For example, is this a special > instance of marking types or classes of calls? If you want to generalize the mechanism, I'm fine with that within the constraints of what I said above. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 04 16:58:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2aao-0003KM-DU; Thu, 04 Jan 2007 16:57:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2aam-0003IU-DM for ecrit@ietf.org; Thu, 04 Jan 2007 16:57:44 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2aal-0005UD-23 for ecrit@ietf.org; Thu, 04 Jan 2007 16:57:44 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 04 Jan 2007 13:57:42 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l04LvgD0031817; Thu, 4 Jan 2007 13:57:42 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l04LvAJJ005018; Thu, 4 Jan 2007 13:57:42 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 16:57:33 -0500 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 16:57:32 -0500 From: "Marc Linsner" To: "'Henning Schulzrinne'" , "'Andrew Newton'" Subject: RE: [Ecrit] call marking Date: Thu, 4 Jan 2007 16:57:31 -0500 Message-ID: <00d001c7304b$55f5efd0$200d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AccwSdnorGAvOsQLSxuV2nrYfgCkMgAAG5mA In-Reply-To: X-OriginalArrivalTime: 04 Jan 2007 21:57:32.0669 (UTC) FILETIME=[55FD42D0:01C7304B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2428; t=1167947862; x=1168811862; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20call=20marking |Sender:=20; bh=QV2nh3KBLPL5VPsCPR3y/HZHsSCqktxrh4uDS+6uZc8=; b=D7qX5DIXDFdDDNsQ8f5KOp53fJuqK79Y70o8vIa8EB07pVIbSEcBVQJ6ns7q5EryBl9dRsDy fjsfjAGjR2G4oC2RNCriu/Vtfav0tLnzRSt9rAyZrUyw2PtL0JNotYgO; Authentication-Results: sj-dkim-7; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org FWIW....wireline 9-1-1 in the U.S. currently has no special markings/priority except what is achieved by the fact that there is a dedicated network (at least bearer) from the Class 5 to the Selective Router/PSAP. So creating a marking which leads to special treatment may become ugly with the prospect of spoofing the marking and the possibility of pre-empting a legit call not marked as emergency with one that is asking directions to Pizza Hut. Ugly at best for the IETF.... -Marc- > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, January 04, 2007 4:48 PM > To: Andrew Newton > Cc: ECRIT > Subject: Re: [Ecrit] call marking > > But marking for what purpose? Without knowing what this > supposed to be used for, it's hard to design a mechanism that > has the right properties. As one obvious issue, if the > marking is just informational, we wouldn't care if somebody > marked calls to the local pizza delivery outfit as > "emergency" if they are hungry. But in that case, I'm > somewhat at a loss as to why this would be useful for real > emergency calls. > > Also, in general, I think it's a good design approach to see > if there's a broader context here. For example, is this a > special instance of marking types or classes of calls? > > On Jan 4, 2007, at 4:39 PM, Andrew Newton wrote: > > > > > On Jan 4, 2007, at 2:55 PM, Henning Schulzrinne wrote: > > > >> Maybe it would be helpful to discuss requirements first > and who would > >> use the call marking for what. > >> > > [...snip..] > >> So, what are the goals and when precisely do we need this? > > > > I agree that we need to understand the requirement. And I'd prefer > > that the requirement be this: "Marking a call as an emergency call > > without implying anything else." The arguments, as I > understand them, > > against the resource priority header is that it overloading another > > mechanism: I guess some jurisdictions don't think emergency > calls are > > worthy of a priority higher than normal. I'd say the > argument is also > > true for using the request URI. You are overloading > another mechanism > > that has another purpose. > > > > -andy > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 04 19:55:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2dMQ-0005VH-8E; Thu, 04 Jan 2007 19:55:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2dMP-0005VC-2X for ecrit@ietf.org; Thu, 04 Jan 2007 19:55:05 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2dMN-0000gZ-Oa for ecrit@ietf.org; Thu, 04 Jan 2007 19:55:05 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1H2dM8-0005pN-Aq; Thu, 04 Jan 2007 18:54:48 -0600 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] call marking Date: Thu, 4 Jan 2007 19:54:59 -0500 Message-ID: <008c01c73064$22208d50$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AccwSkzy+2lpmwZfQ/isKrIUsW7KswAF9d8g In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > > > This would mean that a call enters a proxy with urn:service:sos in the > > Request URI, and some meaningful thing in a Route header. The proxy > > determines that the call has to be routed on the i2 network. It > > pops the > > Route header and replaces the Request URI with what it needs to do > > to get it > > to route in the i2 network. It would then look just like any other > > i2 call. > > If you attempt to send the call with any marking, the i2 system may > > well be > > unhappy, but even if it was okay (as it really should be), the > > marking, > > however you do it, is meaningless. > > This seems to be a specious argument about i2 being fragile, and that > it requires the R-URI to be the sos URN. Is either really true? I hope the systems are not fragile, but they are pretty special purpose and thus the level of testing for extremes of signaling is not likely all that great. I would think the basics of ignoring a header you didn't understand would be there. i2 doesn't know anything about the sos URN. It generally has something called an ESRN (a "Route Number") in the Request URI, which cause the network that has gateways connected to the selective routers to route to the right gateway, and also is used by the gateway to select the right trunk group. That pretty much has to be what is in R-URI. Right now there are only two networks of such gateways in the U.S. There are some changes in the NENA specs coming (which may not matter, as the existing implementations aren't conformant to the i2 specs) which change the ESRN somewhat. It's turning from something that looks like a telephone number to a more general URI, and has the possibility of a gateway network sensitive translation from the new "ESRN" (it's got a new name too) to something specific to the gateway network. > > I sure hope that everyone understands there will be no flag day > regarding LoST. VSPs will have to operate in both worlds, where some > LoST queries resolve and others do not. Those that do not will > require the routing to fall back to the old SIP termination methods. > When LoST does not produce a result, I'd still like to mark the call > as an emergency in a universal and standard manner and I'd still like > to have a GeoLocation header. Just because the call may not be > routable via LoST does not mean it won't terminate to an IP end point. In the U.S. I think you will not have any case of an IP termination that is not LoST routed, but I never say never. I think trying to anticipate all sorts of transition strategies is fruitless. The basic idea you describe above, where you try to see if a LoST route exists, and use it if it does, falling back to existing mechanisms if it does not, is the likely transition strategy. Existing mechanisms don't use sos URNs and they don't need markings. They have their own conventions. Carrying the geolocation header is probably good all the way, again assuming implementations follow 3261 rules on ignoring headers they don't understand. I am more than a little worried about multipart in this case however. If the existing systems don't implement multipart, they get hosed pretty badly. I'll see if I can get a "heads up" on that out to the right folks. Roger Marshall, are you listening? Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 04 20:06:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2dWs-0005DU-P5; Thu, 04 Jan 2007 20:05:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2dWr-0005DM-0n for ecrit@ietf.org; Thu, 04 Jan 2007 20:05:53 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2dWp-0003ng-LS for ecrit@ietf.org; Thu, 04 Jan 2007 20:05:53 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1H2dWZ-0007TN-9J; Thu, 04 Jan 2007 19:05:36 -0600 From: "Brian Rosen" To: , , Subject: RE: [Ecrit] call marking Date: Thu, 4 Jan 2007 20:05:47 -0500 Message-ID: <009001c73065$a451c180$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AccwSc3enPfx5Y7XT960mRy2aAN1vAAAD+OgAAaFSyA= In-Reply-To: <0A0D0FBCB8154043B909C961D02A7A44031DAECB@OSTMAIL03VS3.ad.dot.gov> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Jenny Apples to Oranges comparison. The SIP call never gets to CAD, at least for the current definition of CAD. Some data extracted from the call will, but that won't be SIP signaling. We're talking about the mechanisms used within the Internet and carrier networks to get calls to what we would now call the "Emergency Services IP Network". We may end up remarking calls within the network for some of the marks we are talking about, but I'd like to avoid that if possible. I think within the ESInet, we'll use the existing MLPP priority mechanisms, which is the RP header. Whether we need a new name space in RP for use within public safety networks is debatable. I think the existing military one will work okay, but we can make one if we need one. The questing in this context is whether it's appropriate to use RP, with a new name space, in the Internet and carrier networks. That's what we are discussing. I personally think we should. Probably not relevant to this list, but since calls need to be progressed, redirected, forwarded, conferenced and transferred between PSAPs, you have to assume that there is standardized marking and priority nationwide within the networks the PSAPs are connected to. That's external to a particular PSAP. Within a PSAP, there may be some remarking or PHBs that are specific to the PSAP. Brian > -----Original Message----- > From: Jenny.Hansen@dot.gov [mailto:Jenny.Hansen@dot.gov] > Sent: Thursday, January 04, 2007 4:52 PM > To: hgs@cs.columbia.edu; andy@hxr.us > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] call marking > > You're both on to something here, but remember (and Andy mentions it > with other mechanisms), MOST PSAPS, via their Computer Aided Dispatch > systems, will be overriding the priority codes for all calls as they're > processed according to the Standard Operating Procedures within their > agency. The call path (network routing) will identify the call as "an > emergency call" (based on the actual "line" of delivery)... The "marker" > will be provided elsewhere (other mechanisms) for the most part. If you > think it is necessary for your routing practices, that's another issue, > but from the operational aspect of marking calls as "emergencies" -- > it's done elsewhere and differently from PSAP to PSAP. > > For what it's worth. > > Jenny > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, January 04, 2007 4:48 PM > To: Andrew Newton > Cc: ECRIT > Subject: Re: [Ecrit] call marking > > But marking for what purpose? Without knowing what this supposed to be > used for, it's hard to design a mechanism that has the right properties. > As one obvious issue, if the marking is just informational, we wouldn't > care if somebody marked calls to the local pizza delivery outfit as > "emergency" if they are hungry. But in that case, I'm somewhat at a loss > as to why this would be useful for real emergency calls. > > Also, in general, I think it's a good design approach to see if there's > a broader context here. For example, is this a special instance of > marking types or classes of calls? > > On Jan 4, 2007, at 4:39 PM, Andrew Newton wrote: > > > > > On Jan 4, 2007, at 2:55 PM, Henning Schulzrinne wrote: > > > >> Maybe it would be helpful to discuss requirements first and who would > > >> use the call marking for what. > >> > > [...snip..] > >> So, what are the goals and when precisely do we need this? > > > > I agree that we need to understand the requirement. And I'd prefer > > that the requirement be this: "Marking a call as an emergency call > > without implying anything else." The arguments, as I understand them, > > > against the resource priority header is that it overloading another > > mechanism: I guess some jurisdictions don't think emergency calls are > > worthy of a priority higher than normal. I'd say the argument is also > > > true for using the request URI. You are overloading another mechanism > > > that has another purpose. > > > > -andy > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 04 20:21:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2dlk-00063u-NV; Thu, 04 Jan 2007 20:21:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2dli-00061m-SE for ecrit@ietf.org; Thu, 04 Jan 2007 20:21:14 -0500 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2dlg-0000Nc-Ja for ecrit@ietf.org; Thu, 04 Jan 2007 20:21:14 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 04 Jan 2007 20:20:36 -0500 id 01588493.459DA7E4.00004532 In-Reply-To: <008c01c73064$22208d50$640fa8c0@cis.neustar.com> References: <008c01c73064$22208d50$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Message-Id: From: Andrew Newton Subject: Re: [Ecrit] call marking Date: Thu, 4 Jan 2007 20:21:03 -0500 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0746419122==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0746419122== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-17716-1167960043-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-17716-1167960043-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Jan 4, 2007, at 7:54 PM, Brian Rosen wrote: > Existing mechanisms don't use sos URNs and they don't need > markings. They have their own conventions. Good, then I'd hope you would agree the re-purposing something they do use, the request-URI, for call marking is asking for collisions. Finding some other mechanism means that the logic is the same regardless of the path, which is likely to result in greater interoperability and fewer mistakes. > Carrying the geolocation header is probably good all the way, again > assuming > implementations follow 3261 rules on ignoring headers they don't > understand. > I am more than a little worried about multipart in this case > however. If > the existing systems don't implement multipart, they get hosed > pretty badly. I've always intended to do LbyR here. -andy --=_zeke.ecotroph.net-17716-1167960043-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.3
On Jan 4, 2007, at 7:54= PM, Brian Rosen wrote:

=A0Existing mechanisms don't use sos U= RNs and they don't need

markings. =A0 They have t= heir own conventions.


Good, then I'd hope you would agree the re-pur= posing something they do use, the request-URI, for call marking is asking= for collisions.=A0 Finding some other mechanism means that the logic is = the same regardless of the path, which is likely to result in greater int= eroperability and fewer mistakes.

Carrying the geolocation header is p= robably good all the way, again assuming

implementations follow 3261 rules on ignoring headers= they don't understand.

I am more than a little worried about multipart in this case however.<= SPAN class=3D"Apple-converted-space">=A0 If

the existing systems don't implement multip= art, they get hosed pretty badly.


= I've always intended to do LbyR here.

-andy
--=_zeke.ecotroph.net-17716-1167960043-0001-2-- --===============0746419122== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0746419122==-- From ecrit-bounces@ietf.org Thu Jan 04 20:24:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2doX-0007bs-6L; Thu, 04 Jan 2007 20:24:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2doV-0007bj-DI for ecrit@ietf.org; Thu, 04 Jan 2007 20:24:07 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2doU-0001E0-4E for ecrit@ietf.org; Thu, 04 Jan 2007 20:24:07 -0500 Received: from [192.168.0.41] (pool-141-153-205-123.mad.east.verizon.net [141.153.205.123]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l051Nvf3018870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Jan 2007 20:23:58 -0500 (EST) In-Reply-To: References: <008c01c73064$22208d50$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4A25A744-B2E1-4B05-ADD0-A673606AC03E@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] call marking Date: Thu, 4 Jan 2007 20:23:54 -0500 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I don't think my basic question has been answered: what's the purpose of marking? Who interprets these markings for what purpose? Adding random strings to protocols in the hope that they might be useful for somebody somewhere for something isn't too useful. (The URI/routing mechanisms are simply that - routing mechanisms. They obviously work just as well for urn:service:pizza as for emergency.) On Jan 4, 2007, at 8:21 PM, Andrew Newton wrote: > > On Jan 4, 2007, at 7:54 PM, Brian Rosen wrote: > >> Existing mechanisms don't use sos URNs and they don't need >> markings. They have their own conventions. > > Good, then I'd hope you would agree the re-purposing something they > do use, the request-URI, for call marking is asking for > collisions. Finding some other mechanism means that the logic is > the same regardless of the path, which is likely to result in > greater interoperability and fewer mistakes. > >> Carrying the geolocation header is probably good all the way, >> again assuming >> implementations follow 3261 rules on ignoring headers they don't >> understand. >> I am more than a little worried about multipart in this case >> however. If >> the existing systems don't implement multipart, they get hosed >> pretty badly. > > I've always intended to do LbyR here. > > -andy > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 04 20:38:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2e2K-0008Rd-6b; Thu, 04 Jan 2007 20:38:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2e2I-0008RD-8U for ecrit@ietf.org; Thu, 04 Jan 2007 20:38:22 -0500 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2e2F-0005lA-UG for ecrit@ietf.org; Thu, 04 Jan 2007 20:38:22 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 04 Jan 2007 20:37:49 -0500 id 01588493.459DABED.0000490F In-Reply-To: <4A25A744-B2E1-4B05-ADD0-A673606AC03E@cs.columbia.edu> References: <008c01c73064$22208d50$640fa8c0@cis.neustar.com> <4A25A744-B2E1-4B05-ADD0-A673606AC03E@cs.columbia.edu> Mime-Version: 1.0 Message-Id: <10C87631-E8FF-44BE-B7E6-DC3C24DCF3A9@hxr.us> From: Andrew Newton Subject: Re: [Ecrit] call marking Date: Thu, 4 Jan 2007 20:38:16 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0141765056==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0141765056== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-18706-1167961070-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-18706-1167961070-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Jan 4, 2007, at 8:23 PM, Henning Schulzrinne wrote: > I don't think my basic question has been answered: what's the > purpose of marking? Who interprets these markings for what purpose? > > Adding random strings to protocols in the hope that they might be > useful for somebody somewhere for something isn't too useful. Ok. I think I understand what you are asking. And I didn't answer it, nor do I think I can answer it... other than to say I thought it was a requirement we had to fulfill (in our requirements draft). I could theorize and say that some element might notice that a call is an emergency and knowingly assign it higher priority in the network, or that routing decisions might be made otherwise. But I'd really be guessing. So, if the conclusion is that "call marking" isn't really useful outside of LoST-based routing, then that seems reasonable to me. -andy --=_zeke.ecotroph.net-18706-1167961070-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.3
On Jan 4, 2007, at 8:23= PM, Henning Schulzrinne wrote:

I = don't think my basic question has been answered: what's the purpose of ma= rking? Who interprets these markings for what purpose?


Adding random = strings to protocols in the hope that they might be useful for somebody s= omewhere for something isn't too useful.

Ok. I think I understand what you are asking.=A0 And I didn't answ= er it, nor do I think I can answer it... other than to say I thought it w= as a requirement we had to fulfill (in our requirements draft).=A0 I coul= d theorize and say that some element might notice that a call is an emerg= ency and knowingly assign it higher priority in the network, or that rout= ing decisions might be made otherwise.=A0 But I'd really be guessing.

So, if the conclu= sion is that "call marking" isn't really useful outside of LoST-based rou= ting, then that seems reasonable to me.

-andy
--=_zeke.ecotroph.net-18706-1167961070-0001-2-- --===============0141765056== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0141765056==-- From ecrit-bounces@ietf.org Thu Jan 04 20:42:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2e6Y-0003D7-T3; Thu, 04 Jan 2007 20:42:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2e6X-0003Cc-Qa for ecrit@ietf.org; Thu, 04 Jan 2007 20:42:45 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2e6W-0007q1-BE for ecrit@ietf.org; Thu, 04 Jan 2007 20:42:45 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1H2e6G-0006eR-P6; Thu, 04 Jan 2007 19:42:28 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Andrew Newton'" Subject: RE: [Ecrit] call marking Date: Thu, 4 Jan 2007 20:42:40 -0500 Message-ID: <009701c7306a$cb4d0ec0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AccwaCd0nMft53IeRzyquops4XMcsgAAQxiA In-Reply-To: <4A25A744-B2E1-4B05-ADD0-A673606AC03E@cs.columbia.edu> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 1.0 (+) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Well, let me cite some reasons for marking: 1. Actual routing; knowing how to route the call, especially if there is more than one element involved. I think this is the big one. We need the service URN to stay around even after we have done one level of LoST routing. This includes things like having the call go to the E-CSCF in the visited network instead of anything in the home network, for example. 2. Allowing the UAS, and a proxy on the route, to know what service is being requested 3. Invoking emergency call specific behavior, like adding location 4. Priority handling of signaling and media within the network at all levels 5. Disabling of services like call waiting that are provided by the network 6. Charging issues or lack thereof 7. Processing of the call at all (some systems will allow emergency calls, but no other forms of call), like a cellphone with no service plan. 8. Assistance in detecting theft of service when fraudulent attempts to get the above are attempted without a genuine service call Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, January 04, 2007 8:24 PM > To: Andrew Newton > Cc: Brian Rosen; 'ECRIT' > Subject: Re: [Ecrit] call marking > > I don't think my basic question has been answered: what's the purpose > of marking? Who interprets these markings for what purpose? > > Adding random strings to protocols in the hope that they might be > useful for somebody somewhere for something isn't too useful. > > (The URI/routing mechanisms are simply that - routing mechanisms. > They obviously work just as well for urn:service:pizza as for > emergency.) > > On Jan 4, 2007, at 8:21 PM, Andrew Newton wrote: > > > > > On Jan 4, 2007, at 7:54 PM, Brian Rosen wrote: > > > >> Existing mechanisms don't use sos URNs and they don't need > >> markings. They have their own conventions. > > > > Good, then I'd hope you would agree the re-purposing something they > > do use, the request-URI, for call marking is asking for > > collisions. Finding some other mechanism means that the logic is > > the same regardless of the path, which is likely to result in > > greater interoperability and fewer mistakes. > > > >> Carrying the geolocation header is probably good all the way, > >> again assuming > >> implementations follow 3261 rules on ignoring headers they don't > >> understand. > >> I am more than a little worried about multipart in this case > >> however. If > >> the existing systems don't implement multipart, they get hosed > >> pretty badly. > > > > I've always intended to do LbyR here. > > > > -andy > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 04 20:50:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2eDw-0006LG-II; Thu, 04 Jan 2007 20:50:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2eDu-0006JM-48 for ecrit@ietf.org; Thu, 04 Jan 2007 20:50:22 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2eDs-0001H7-K8 for ecrit@ietf.org; Thu, 04 Jan 2007 20:50:22 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1H2eDc-0007z8-QK; Thu, 04 Jan 2007 19:50:05 -0600 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] call marking Date: Thu, 4 Jan 2007 20:50:17 -0500 Message-ID: <009801c7306b$db2fdf10$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AccwZ76M7x3vwZo1TYCEmsEFxZEnlgAAyGDg In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a2f5df4c6f30e0d5df43748fb095119 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0192149148==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0192149148== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0099_01C73041.F259D710" This is a multi-part message in MIME format. ------=_NextPart_000_0099_01C73041.F259D710 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit _____ From: Andrew Newton [mailto:andy@hxr.us] Sent: Thursday, January 04, 2007 8:21 PM To: Brian Rosen Cc: 'ECRIT' Subject: Re: [Ecrit] call marking On Jan 4, 2007, at 7:54 PM, Brian Rosen wrote: Existing mechanisms don't use sos URNs and they don't need markings. They have their own conventions. Good, then I'd hope you would agree the re-purposing something they do use, the request-URI, for call marking is asking for collisions. Finding some other mechanism means that the logic is the same regardless of the path, which is likely to result in greater interoperability and fewer mistakes. See my list of requirements I just sent Henning. You need the service URN all the way to the UAS. It doesn't have to be in the R-URI though. I don't see a practical problem with Henning/Jonathan's proposal, but I'd agree in general with your observation that not doing something "odd", from an existing implementation point of view is best. Carrying the geolocation header is probably good all the way, again assuming implementations follow 3261 rules on ignoring headers they don't understand. I am more than a little worried about multipart in this case however. If the existing systems don't implement multipart, they get hosed pretty badly. I've always intended to do LbyR here. Don't get me started. I think LbyR is a very bad idea for emergency calls because it requires more relationships and interconnects to work in situations where they are less likely to work. I know others don't agree. It does avoid multipart problems, I'll give you that. We're not going to require LbyR, so we must get the existing systems to allow multipart. If they do, then there is no advantage of LbyR from that standpoint.. Brian ------=_NextPart_000_0099_01C73041.F259D710 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: = Andrew Newton [mailto:andy@hxr.us]
Sent: Thursday, January = 04, 2007 8:21 PM
To: Brian Rosen
Cc: 'ECRIT'
Subject: Re: [Ecrit] call = marking

 

 

On Jan 4, 2007, at 7:54 PM, Brian Rosen = wrote:



Existing mechanisms = don't use sos URNs and they don't need

markings. They have = their own conventions.

 

Good, then I'd hope you would agree the re-purposing something = they do use, the request-URI, for call marking is asking for collisions. Finding = some other mechanism means that the logic is the same regardless of the path, = which is likely to result in greater interoperability and fewer = mistakes.

 

See my list of requirements I just = sent Henning.  You need the service URN all the way to the UAS.  It = doesn’t have to be in the R-URI though.  I don’t see a practical = problem with Henning/Jonathan’s proposal, but I’d agree in general = with your observation that not doing something “odd”, from an = existing implementation point of view is best.  =



Carrying the geolocation = header is probably good all the way, again = assuming

implementations follow = 3261 rules on ignoring headers they don't understand.

I am more than a little = worried about multipart in this case however. If

the existing systems = don't implement multipart, they get hosed pretty = badly.

 

I've always intended to do LbyR = here.

 

Don’t get me started.  I = think LbyR is a very bad idea for emergency calls because it requires more relationships and interconnects to work in situations where they are = less likely to work.  I know others don’t agree.  It does = avoid multipart problems, I’ll give you that.  We’re not = going to require LbyR, so we must get the existing systems to allow = multipart.  If they do, then there is no advantage of LbyR from that = standpoint..

 

=

 

Brian

------=_NextPart_000_0099_01C73041.F259D710-- --===============0192149148== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0192149148==-- From ecrit-bounces@ietf.org Thu Jan 04 20:51:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2eFB-0006vH-FK; Thu, 04 Jan 2007 20:51:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2eFA-0006vB-Ea for ecrit@ietf.org; Thu, 04 Jan 2007 20:51:40 -0500 Received: from smtp02out.dot.gov ([199.79.178.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2eF8-0001VN-Uf for ecrit@ietf.org; Thu, 04 Jan 2007 20:51:40 -0500 Received: from dotfaawms005.ad.dot.gov ([152.119.86.161]) by smtp02out.dot.gov with ESMTP; 04 Jan 2007 20:51:39 -0500 Received: from OSTMAIL03VS3.ad.dot.gov ([152.119.86.69]) by DOTFAAWMS005.ad.dot.gov with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 20:51:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [Ecrit] call marking Date: Thu, 4 Jan 2007 20:51:37 -0500 Message-ID: <0A0D0FBCB8154043B909C961D02A7A4402C7160A@OSTMAIL03VS3.ad.dot.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] call marking Thread-Index: AccwaCd0nMft53IeRzyquops4XMcsgAAQxiAAAC1ckQ= From: To: , , X-OriginalArrivalTime: 05 Jan 2007 01:51:38.0478 (UTC) FILETIME=[09F1A0E0:01C7306C] X-Spam-Score: 1.2 (+) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0408880598==" Errors-To: ecrit-bounces@ietf.org --===============0408880598== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V291bGQgdGhpcyBhbHNvIHBsYXlpbnRvIHByaW9yaXR5IGFjY2Vzcz8gRm9yIGV4YW1wbGUsIHRo ZSBMb25kb24gQm9tYmluZyBBZnRlciBBY3Rpb24gcmVwb3J0IHdoZW4gRVZFUllPTkUgdHJpZWQg dG8gbWFrZSBhIGNhbGwuICg/KSBPciAtIGR1cmluZyBhIHRyYW5zZmVyIGZyb20gYSBQU0FQIChv ciB0aGlyZCBwYXJ0eSBwcm92aWRlciBUTyBhIFBTQVApIHdoZW4gdGhleSBoYXZlIGEgYm9uYWZp ZGUgZW1lcmdlbmN5IGFuZCB3YW50IHRoZSByZWNpcGllbnQgdG8ga25vdyB0aGF0IHRoZSBpbmNv bWluZyBjYWxsIElTIHRydWx5IGFuIGVtZXJnZW5jeS4gPyBUaGUgTG9uZG9uIGV4YW1wbGUgaXMg c29tZXRoaW5nIHRoYXQgZml0cyBoZXJlIEkgdGhpbmsgLi4uIElmIHUgd2FudCBhIHJlYWwgd29y bGQgZXhhbXBsZS4gDQpTZW50IGZyb20gSkgvQmxhY2tiZXJyeSANCg0KLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLQ0KRnJvbTogQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0Pg0KVG86 ICdIZW5uaW5nIFNjaHVsenJpbm5lJyA8aGdzQGNzLmNvbHVtYmlhLmVkdT47ICdBbmRyZXcgTmV3 dG9uJyA8YW5keUBoeHIudXM+DQpDYzogJ0VDUklUJyA8ZWNyaXRAaWV0Zi5vcmc+DQpTZW50OiBU aHUgSmFuIDA0IDIwOjQyOjQwIDIwMDcNClN1YmplY3Q6IFJFOiBbRWNyaXRdIGNhbGwgbWFya2lu Zw0KDQpXZWxsLCBsZXQgbWUgY2l0ZSBzb21lIHJlYXNvbnMgZm9yIG1hcmtpbmc6DQoxLiBBY3R1 YWwgcm91dGluZzsga25vd2luZyBob3cgdG8gcm91dGUgdGhlIGNhbGwsIGVzcGVjaWFsbHkgaWYg dGhlcmUgaXMNCm1vcmUgdGhhbiBvbmUgZWxlbWVudCBpbnZvbHZlZC4gIEkgdGhpbmsgdGhpcyBp cyB0aGUgYmlnIG9uZS4gIFdlIG5lZWQgdGhlDQpzZXJ2aWNlIFVSTiB0byBzdGF5IGFyb3VuZCBl dmVuIGFmdGVyIHdlIGhhdmUgZG9uZSBvbmUgbGV2ZWwgb2YgTG9TVA0Kcm91dGluZy4gIFRoaXMg aW5jbHVkZXMgdGhpbmdzIGxpa2UgaGF2aW5nIHRoZSBjYWxsIGdvIHRvIHRoZSBFLUNTQ0YgaW4g dGhlDQp2aXNpdGVkIG5ldHdvcmsgaW5zdGVhZCBvZiBhbnl0aGluZyBpbiB0aGUgaG9tZSBuZXR3 b3JrLCBmb3IgZXhhbXBsZS4NCjIuIEFsbG93aW5nIHRoZSBVQVMsIGFuZCBhIHByb3h5IG9uIHRo ZSByb3V0ZSwgdG8ga25vdyB3aGF0IHNlcnZpY2UgaXMgYmVpbmcNCnJlcXVlc3RlZA0KMy4gSW52 b2tpbmcgZW1lcmdlbmN5IGNhbGwgc3BlY2lmaWMgYmVoYXZpb3IsIGxpa2UgYWRkaW5nIGxvY2F0 aW9uDQo0LiBQcmlvcml0eSBoYW5kbGluZyBvZiBzaWduYWxpbmcgYW5kIG1lZGlhIHdpdGhpbiB0 aGUgbmV0d29yayBhdCBhbGwgbGV2ZWxzDQo1LiBEaXNhYmxpbmcgb2Ygc2VydmljZXMgbGlrZSBj YWxsIHdhaXRpbmcgdGhhdCBhcmUgcHJvdmlkZWQgYnkgdGhlIG5ldHdvcmsNCjYuIENoYXJnaW5n IGlzc3VlcyBvciBsYWNrIHRoZXJlb2YNCjcuIFByb2Nlc3Npbmcgb2YgdGhlIGNhbGwgYXQgYWxs IChzb21lIHN5c3RlbXMgd2lsbCBhbGxvdyBlbWVyZ2VuY3kgY2FsbHMsDQpidXQgbm8gb3RoZXIg Zm9ybXMgb2YgY2FsbCksIGxpa2UgYSBjZWxscGhvbmUgd2l0aCBubyBzZXJ2aWNlIHBsYW4uDQo4 LiBBc3Npc3RhbmNlIGluIGRldGVjdGluZyB0aGVmdCBvZiBzZXJ2aWNlIHdoZW4gZnJhdWR1bGVu dCBhdHRlbXB0cyB0byBnZXQNCnRoZSBhYm92ZSBhcmUgYXR0ZW1wdGVkIHdpdGhvdXQgYSBnZW51 aW5lIHNlcnZpY2UgY2FsbA0KDQpCcmlhbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IEhlbm5pbmcgU2NodWx6cmlubmUgW21haWx0bzpoZ3NAY3MuY29sdW1iaWEuZWR1 XQ0KPiBTZW50OiBUaHVyc2RheSwgSmFudWFyeSAwNCwgMjAwNyA4OjI0IFBNDQo+IFRvOiBBbmRy ZXcgTmV3dG9uDQo+IENjOiBCcmlhbiBSb3NlbjsgJ0VDUklUJw0KPiBTdWJqZWN0OiBSZTogW0Vj cml0XSBjYWxsIG1hcmtpbmcNCj4gDQo+IEkgZG9uJ3QgdGhpbmsgbXkgYmFzaWMgcXVlc3Rpb24g aGFzIGJlZW4gYW5zd2VyZWQ6IHdoYXQncyB0aGUgcHVycG9zZQ0KPiBvZiBtYXJraW5nPyBXaG8g aW50ZXJwcmV0cyB0aGVzZSBtYXJraW5ncyBmb3Igd2hhdCBwdXJwb3NlPw0KPiANCj4gQWRkaW5n IHJhbmRvbSBzdHJpbmdzIHRvIHByb3RvY29scyBpbiB0aGUgaG9wZSB0aGF0IHRoZXkgbWlnaHQg YmUNCj4gdXNlZnVsIGZvciBzb21lYm9keSBzb21ld2hlcmUgZm9yIHNvbWV0aGluZyBpc24ndCB0 b28gdXNlZnVsLg0KPiANCj4gKFRoZSBVUkkvcm91dGluZyBtZWNoYW5pc21zIGFyZSBzaW1wbHkg dGhhdCAtIHJvdXRpbmcgbWVjaGFuaXNtcy4NCj4gVGhleSBvYnZpb3VzbHkgd29yayBqdXN0IGFz IHdlbGwgZm9yIHVybjpzZXJ2aWNlOnBpenphIGFzIGZvcg0KPiBlbWVyZ2VuY3kuKQ0KPiANCj4g T24gSmFuIDQsIDIwMDcsIGF0IDg6MjEgUE0sIEFuZHJldyBOZXd0b24gd3JvdGU6DQo+IA0KPiA+ DQo+ID4gT24gSmFuIDQsIDIwMDcsIGF0IDc6NTQgUE0sIEJyaWFuIFJvc2VuIHdyb3RlOg0KPiA+ DQo+ID4+ICBFeGlzdGluZyBtZWNoYW5pc21zIGRvbid0IHVzZSBzb3MgVVJOcyBhbmQgdGhleSBk b24ndCBuZWVkDQo+ID4+IG1hcmtpbmdzLiAgIFRoZXkgaGF2ZSB0aGVpciBvd24gY29udmVudGlv bnMuDQo+ID4NCj4gPiBHb29kLCB0aGVuIEknZCBob3BlIHlvdSB3b3VsZCBhZ3JlZSB0aGUgcmUt cHVycG9zaW5nIHNvbWV0aGluZyB0aGV5DQo+ID4gZG8gdXNlLCB0aGUgcmVxdWVzdC1VUkksIGZv ciBjYWxsIG1hcmtpbmcgaXMgYXNraW5nIGZvcg0KPiA+IGNvbGxpc2lvbnMuICBGaW5kaW5nIHNv bWUgb3RoZXIgbWVjaGFuaXNtIG1lYW5zIHRoYXQgdGhlIGxvZ2ljIGlzDQo+ID4gdGhlIHNhbWUg cmVnYXJkbGVzcyBvZiB0aGUgcGF0aCwgd2hpY2ggaXMgbGlrZWx5IHRvIHJlc3VsdCBpbg0KPiA+ IGdyZWF0ZXIgaW50ZXJvcGVyYWJpbGl0eSBhbmQgZmV3ZXIgbWlzdGFrZXMuDQo+ID4NCj4gPj4g Q2FycnlpbmcgdGhlIGdlb2xvY2F0aW9uIGhlYWRlciBpcyBwcm9iYWJseSBnb29kIGFsbCB0aGUg d2F5LA0KPiA+PiBhZ2FpbiBhc3N1bWluZw0KPiA+PiBpbXBsZW1lbnRhdGlvbnMgZm9sbG93IDMy NjEgcnVsZXMgb24gaWdub3JpbmcgaGVhZGVycyB0aGV5IGRvbid0DQo+ID4+IHVuZGVyc3RhbmQu DQo+ID4+IEkgYW0gbW9yZSB0aGFuIGEgbGl0dGxlIHdvcnJpZWQgYWJvdXQgbXVsdGlwYXJ0IGlu IHRoaXMgY2FzZQ0KPiA+PiBob3dldmVyLiAgSWYNCj4gPj4gdGhlIGV4aXN0aW5nIHN5c3RlbXMg ZG9uJ3QgaW1wbGVtZW50IG11bHRpcGFydCwgdGhleSBnZXQgaG9zZWQNCj4gPj4gcHJldHR5IGJh ZGx5Lg0KPiA+DQo+ID4gSSd2ZSBhbHdheXMgaW50ZW5kZWQgdG8gZG8gTGJ5UiBoZXJlLg0KPiA+ DQo+ID4gLWFuZHkNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+IEVjcml0IG1haWxpbmcgbGlzdA0KPiA+IEVjcml0QGlldGYub3JnDQo+ID4g aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRWNyaXQgbWFpbGluZyBs aXN0DQpFY3JpdEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZWNyaXQNCg== --===============0408880598== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0408880598==-- From ecrit-bounces@ietf.org Thu Jan 04 20:58:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2eLW-00043X-N8; Thu, 04 Jan 2007 20:58:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2eLV-00043I-Oa for ecrit@ietf.org; Thu, 04 Jan 2007 20:58:13 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2eLU-0004KJ-Bc for ecrit@ietf.org; Thu, 04 Jan 2007 20:58:13 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1H2eLE-0000kU-Fn; Thu, 04 Jan 2007 19:57:56 -0600 From: "Brian Rosen" To: , , Subject: RE: [Ecrit] call marking Date: Thu, 4 Jan 2007 20:58:08 -0500 Message-ID: <00a701c7306c$f45aa190$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AccwaCd0nMft53IeRzyquops4XMcsgAAQxiAAAC1ckQAABjoYA== In-Reply-To: <0A0D0FBCB8154043B909C961D02A7A4402C7160A@OSTMAIL03VS3.ad.dot.gov> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 1.0 (+) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This is yet another issue, which is congestion control. That's not an ecrit issue. We're working that issue now in NENA. Generally, everyone that called considered the call to BE an emergency call. Furthermore, there were lots of side incidents that actually ARE emergency calls. The caller doesn't know what the PSAP knows yet. It may be duplicative of information they already have, it may not. The only way to deal with this is to answer all the calls, and let a human decide what to do. We can make that work. I'll send you a idea I've proposed to NENA if you wish. Again, it's not (currently) an ecrit issue. Brian > -----Original Message----- > From: Jenny.Hansen@dot.gov [mailto:Jenny.Hansen@dot.gov] > Sent: Thursday, January 04, 2007 8:52 PM > To: br@brianrosen.net; hgs@cs.columbia.edu; andy@hxr.us > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] call marking > > Would this also playinto priority access? For example, the London Bombing > After Action report when EVERYONE tried to make a call. (?) Or - during a > transfer from a PSAP (or third party provider TO a PSAP) when they have a > bonafide emergency and want the recipient to know that the incoming call > IS truly an emergency. ? The London example is something that fits here I > think ... If u want a real world example. > Sent from JH/Blackberry > > ----- Original Message ----- > From: Brian Rosen > To: 'Henning Schulzrinne' ; 'Andrew Newton' > > Cc: 'ECRIT' > Sent: Thu Jan 04 20:42:40 2007 > Subject: RE: [Ecrit] call marking > > Well, let me cite some reasons for marking: > 1. Actual routing; knowing how to route the call, especially if there is > more than one element involved. I think this is the big one. We need the > service URN to stay around even after we have done one level of LoST > routing. This includes things like having the call go to the E-CSCF in > the > visited network instead of anything in the home network, for example. > 2. Allowing the UAS, and a proxy on the route, to know what service is > being > requested > 3. Invoking emergency call specific behavior, like adding location > 4. Priority handling of signaling and media within the network at all > levels > 5. Disabling of services like call waiting that are provided by the > network > 6. Charging issues or lack thereof > 7. Processing of the call at all (some systems will allow emergency calls, > but no other forms of call), like a cellphone with no service plan. > 8. Assistance in detecting theft of service when fraudulent attempts to > get > the above are attempted without a genuine service call > > Brian > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Thursday, January 04, 2007 8:24 PM > > To: Andrew Newton > > Cc: Brian Rosen; 'ECRIT' > > Subject: Re: [Ecrit] call marking > > > > I don't think my basic question has been answered: what's the purpose > > of marking? Who interprets these markings for what purpose? > > > > Adding random strings to protocols in the hope that they might be > > useful for somebody somewhere for something isn't too useful. > > > > (The URI/routing mechanisms are simply that - routing mechanisms. > > They obviously work just as well for urn:service:pizza as for > > emergency.) > > > > On Jan 4, 2007, at 8:21 PM, Andrew Newton wrote: > > > > > > > > On Jan 4, 2007, at 7:54 PM, Brian Rosen wrote: > > > > > >> Existing mechanisms don't use sos URNs and they don't need > > >> markings. They have their own conventions. > > > > > > Good, then I'd hope you would agree the re-purposing something they > > > do use, the request-URI, for call marking is asking for > > > collisions. Finding some other mechanism means that the logic is > > > the same regardless of the path, which is likely to result in > > > greater interoperability and fewer mistakes. > > > > > >> Carrying the geolocation header is probably good all the way, > > >> again assuming > > >> implementations follow 3261 rules on ignoring headers they don't > > >> understand. > > >> I am more than a little worried about multipart in this case > > >> however. If > > >> the existing systems don't implement multipart, they get hosed > > >> pretty badly. > > > > > > I've always intended to do LbyR here. > > > > > > -andy > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 04 21:12:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2eZ0-0004Jb-U6; Thu, 04 Jan 2007 21:12:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2eZ0-0004JV-Dj for ecrit@ietf.org; Thu, 04 Jan 2007 21:12:10 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2eYx-0008SX-W0 for ecrit@ietf.org; Thu, 04 Jan 2007 21:12:10 -0500 Received: from [192.168.0.41] (pool-141-153-205-123.mad.east.verizon.net [141.153.205.123]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l052BxZ3023523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Jan 2007 21:12:00 -0500 (EST) In-Reply-To: <009701c7306a$cb4d0ec0$640fa8c0@cis.neustar.com> References: <009701c7306a$cb4d0ec0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0CF668A4-32AE-4DB0-B1D8-59A1B0449FB7@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] call marking Date: Thu, 4 Jan 2007 21:11:54 -0500 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 1.0 (+) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org In general, one of the SIP design principles is not to design for services, but to have service building blocks. Thus, I think the "marking" question has it backwards, as it starts from mechanism and syntax, rather than requirements and behaviors. We should, like you're starting to do, identify behaviors that we need for emergency services and then see how these can be invoked. In many cases, similar behaviors will also be needed for other, non-emergency services, in various combinations. Your list is helpful; let's work through it. On Jan 4, 2007, at 8:42 PM, Brian Rosen wrote: > Well, let me cite some reasons for marking: > 1. Actual routing; knowing how to route the call, especially if > there is > more than one element involved. I think this is the big one. We > need the > service URN to stay around even after we have done one level of LoST > routing. This includes things like having the call go to the E- > CSCF in the > visited network instead of anything in the home network, for example. We discussed this before. Just for routing, we don't need a generic emergency marking. Let's go through this: (1) Let's assume the UAC recognizes the emergency call (things work if it inserts a tel: URI or a sip dial string, it's just one stage delayed) (2) The request URI is urn:service:sos and the call gets proxied to the outbound proxy, P-CSCF or some special ES proxy, based on UAC policy. (3) That proxy recognizes the routing, invokes LoST based on the service and sends it to sip:something@somewhere. If the service matters, each service gets a different (user part) URL. (4) The call arrives 'somewhere'; since it recognizes the URL as requiring special treatment (by normal proxy behavior and local rules), it does another LoST lookup. (5) Repeat (3) and (4) until the call terminates at a PSAP. > 2. Allowing the UAS, and a proxy on the route, to know what service > is being > requested I agree that the destination needs to know whether I want "fire" or "police" if these are different PSAPs or call takers or call taker protocols, but it is not clear that this requires a single, uniform marking. If these should be handled differently, the LoST-invoking can easily generate police@psap.nyc.gov poison@psap.nyc.gov or any other local convention that makes sense. This ensures that there is no intra-protocol disagreement, such as INVITE sip:police@psap.nyc.gov Emergency-service: poison i.e., another error condition. For a variety of reasons (such as the SIP history mechanism), adding non-URL/non-Route things that influence call routing is dubious. > 3. Invoking emergency call specific behavior, like adding location I fully agree that a UAC should be able to ask a proxy to insert location; however, it should do this with an explicit protocol request "please insert location", since I might want the same location-insertion behavior when asking for AAA car-towing service or Domino's pizza delivery service. > 4. Priority handling of signaling and media within the network at > all levels As you noted, media is its own thing (DSCP) and signaling is presumably SIP Resource-Priority. We may want to define an R-P namespace. > 5. Disabling of services like call waiting that are provided by the > network Not a signaling function. > 6. Charging issues or lack thereof This is a critical one where the properties matter. We don't want to a mechanism that allows INVITE sip:alice@nursinghome.org (my grandmother) Service: don't-charge-since-its-an-emergency Thus, for this to be useful, all such calls need to be forced to be routed to a PSAP. At the first hop (UAC to first proxy), the service URN has the right property: it can disable charging and enforces that the call only goes to a PSAP. I suspect that for most practical purposes, this is sufficient or we need a more general mechanism that relies on inter-provider trust assertions or settlement mechanisms. > 7. Processing of the call at all (some systems will allow emergency > calls, > but no other forms of call), like a cellphone with no service plan. Seems similar to (6). > 8. Assistance in detecting theft of service when fraudulent > attempts to get > the above are attempted without a genuine service call > That's more of a requirement, related to (6). Thus, I believe that the only real issue are (6) and (7), which need to satisfy the "atomicity" that call routing and behavior are inextricably tied (only calls routed to an emergency location get this behavior). Conveniently, the current SIP routing proposal (Route + request URI) has the right properties to make that happen. In summary, I think we have the right tools, except for - something in R-P - an "insert location please" mechanism, for proxy-provided location Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 04 21:24:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ekt-0002MR-DU; Thu, 04 Jan 2007 21:24:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2eks-0002DX-Oi for ecrit@ietf.org; Thu, 04 Jan 2007 21:24:26 -0500 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2efz-0003Dt-NH for ecrit@ietf.org; Thu, 04 Jan 2007 21:19:25 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 04 Jan 2007 21:18:53 -0500 id 015884AB.459DB58D.00005110 In-Reply-To: <009801c7306b$db2fdf10$640fa8c0@cis.neustar.com> References: <009801c7306b$db2fdf10$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Message-Id: From: Andrew Newton Subject: LbyR (was Re: [Ecrit] call marking) Date: Thu, 4 Jan 2007 21:19:20 -0500 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0198777258==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0198777258== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-20754-1167963534-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-20754-1167963534-0001-2 Content-Type: text/plain; charset=windows-1252; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable On Jan 4, 2007, at 8:50 PM, Brian Rosen wrote: > Don=92t get me started. Oh, but I might. > I think LbyR is a very bad idea for emergency calls because it =20 > requires more relationships and interconnects to work in situations =20= > where they are less likely to work. I know others don=92t agree. It =20= > does avoid multipart problems, I=92ll give you that. We=92re not = going =20 > to require LbyR, so we must get the existing systems to allow =20 > multipart. If they do, then there is no advantage of LbyR from =20 > that standpoint.. I agree with you if LbyR introduces authorization outside the =20 reference itself (as, in passwords, certs, etc). But absent that =20 idea (which I think is a really bad idea for ECRIT), LbyR gets us =20 around trying to fix the network before we go to deployment. If we =20 have to fix the network first and also force operators to do things =20 like TLS where they normally do not, then ECRIT will go nowhere. -andy --=_zeke.ecotroph.net-20754-1167963534-0001-2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.3
On Jan 4, 2007, at 8:50= PM, Brian Rosen wrote:

Don=92t get me started.=A0

Oh,= but I might.

I think LbyR is a very bad id= ea for emergency calls because it requires more relationships and interco= nnects to work in situations where they are less likely to work.=A0 I kno= w others don=92t agree.=A0 It does avoid multipart problems, I=92ll give = you that.=A0 We=92re not going to require LbyR, so we must get the existi= ng systems to allow multipart.=A0 If they do, then there is no advantage = of LbyR from that standpoint..
I agree with you if LbyR introduces authorization outside th= e reference itself (as, in passwords, certs, etc).=A0 But absent that ide= a (which I think is a really bad idea for ECRIT), LbyR gets us around try= ing to fix the network before we go to deployment.=A0 If we have to fix t= he network first and also force operators to do things like TLS where the= y normally do not, then ECRIT will go nowhere.

-andy

--=_zeke.ecotroph.net-20754-1167963534-0001-2-- --===============0198777258== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0198777258==-- From ecrit-bounces@ietf.org Fri Jan 05 11:45:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sBh-0002j0-6W; Fri, 05 Jan 2007 11:45:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sBg-0002iY-0b for ecrit@ietf.org; Fri, 05 Jan 2007 11:45:00 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2sBb-0006vv-JC for ecrit@ietf.org; Fri, 05 Jan 2007 11:44:59 -0500 Received: (qmail invoked by alias); 05 Jan 2007 16:44:54 -0000 Received: from p54985262.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.82.98] by mail.gmx.net (mp010) with SMTP; 05 Jan 2007 17:44:54 +0100 X-Authenticated: #29516787 Message-ID: <459E8084.7080800@gmx.net> Date: Fri, 05 Jan 2007 17:44:52 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Subject: [Ecrit] [Fwd: [Geopriv] Fwd: ATIS ESIF Liaison RE: Request for Input/Comments Regarding the ATIS ESIF Evaluation of Location Acquisition Protocols] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, we, Marc and myself, also received this document. Ciao Hannes -------- Original Message -------- Subject: [Geopriv] Fwd: ATIS ESIF Liaison RE: Request for Input/Comments Regarding the ATIS ESIF Evaluation of Location Acquisition Protocols Date: Fri, 5 Jan 2007 09:41:58 -0500 From: Andrew Newton To: GEOPRIV WG References: <18FD127A3F3A6344928B7AE9878D61E7062FD1@Exchsvr02.atis.org> I got this yesterday. FYI.. -andy Begin forwarded message: > From: "Margo Zeidner" > Date: January 4, 2007 2:46:26 PM EST > Subject: ATIS ESIF Liaison RE: Request for Input/Comments Regarding > the ATIS ESIF Evaluation of Location Acquisition Protocols > > Dear Leaders, > > > > Please accept the attached correspondence on behalf of the ATIS > ESIF NGES Subcommittee. The liaison and attachment have been > logged and posted to the ATIS ESIF Website (http://www.atis.org/ > esif/correspondenseoutgoing.asp): > > > > 010407-037: Request for Input/Comments Regarding the ATIS ESIF > Evaluation of Location Acquisition Protocols > > http://www.atis.org/esif/Docs/OutgoingCorrespondence/01-04-07-037- > Liaison.pdf > > > > 010407-037-Attachment-2: NGES Draft Document “Location Acquisition > and Location Parameter Conveyance for Internet Access Networks in > Support of Emergency Services” > > http://www.atis.org/esif/Docs/OutgoingCorrespondence/01-04-07-037- > Attachment-2.pdf > > > > If you have any questions please contact the ATIS ESIF Director, > Steve Barclay - sbarclay@atis.org, and the ATIS ESIF Chair Robert > Montgomery -robert.montgomery@sprint.com. > > > > Respectfully, > > > > Margo Zeidner > > Committee Administrator – ESIF, INC > > Alliance for Telecommunications Industry Solutions > > 1200 G St. NW, Suite 500 > > Washington, DC 20005 > > 202-662-8654 > > MZeidner@atis.org > > www.atis.org > > > > > > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jan 05 11:46:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sDW-0003cZ-Ve; Fri, 05 Jan 2007 11:46:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sDV-0003cT-A5 for ecrit@ietf.org; Fri, 05 Jan 2007 11:46:53 -0500 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2sDP-0007HV-Ij for ecrit@ietf.org; Fri, 05 Jan 2007 11:46:53 -0500 Received: from ([139.76.131.87]) by aismt06p.bellsouth.com with SMTP id KP-AXPRN.13968879; Fri, 05 Jan 2007 11:46:10 -0500 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 5 Jan 2007 11:42:54 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 5 Jan 2007 11:42:54 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Jan 2007 11:42:53 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA2B5343@crexc41p> In-Reply-To: <008c01c73064$22208d50$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] call marking Thread-Index: AccwSkzy+2lpmwZfQ/isKrIUsW7KswAF9d8gACDidKA= Importance: normal Priority: normal From: "Stark, Barbara" To: "Brian Rosen" X-OriginalArrivalTime: 05 Jan 2007 16:42:54.0257 (UTC) FILETIME=[8BFDF210:01C730E8] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ECRIT Subject: [Ecrit] multipart X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian, You said "I am more than a little worried about multipart in this case however. If the existing systems don't implement multipart, they get hosed pretty badly." Forgive my ignorance -- Can you expand on what this means? My understanding of SDP and MIME types and such is only surface deep, and this comment flew straight over my head. I would have just emailed you, and not copied ecrit. But experience has taught me I'm usually not alone in my ignorance, and I don't remember having seen this mentioned or discussed in any previous threads. Barbara ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA623 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jan 05 11:51:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sHc-0005F2-6D; Fri, 05 Jan 2007 11:51:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sHb-0005Ev-9e for ecrit@ietf.org; Fri, 05 Jan 2007 11:51:07 -0500 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2sHX-0000xC-TF for ecrit@ietf.org; Fri, 05 Jan 2007 11:51:07 -0500 Received: from ([139.76.131.79]) by aismt06p.bellsouth.com with SMTP id KP-AXPRN.13969319; Fri, 05 Jan 2007 11:50:47 -0500 Received: from 01AL10015010626.AD.BLS.COM ([90.152.44.195]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 5 Jan 2007 11:50:46 -0500 Received: from 01AL10015010647.AD.BLS.COM ([90.152.44.147]) by 01AL10015010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 5 Jan 2007 10:50:46 -0600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] multipart Date: Fri, 5 Jan 2007 10:50:46 -0600 Message-ID: <6FEBBDAA0B74D34E806D366A431F36B70166F558@brexc47p> In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA2B5343@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] multipart Thread-Index: AccwSkzy+2lpmwZfQ/isKrIUsW7KswAF9d8gACDidKAAAPfCwA== From: "Beyer, Loraine" To: "Stark, Barbara" , "Brian Rosen" Importance: normal Priority: normal X-OriginalArrivalTime: 05 Jan 2007 16:50:46.0478 (UTC) FILETIME=[A57526E0:01C730E9] X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Thanks for bringing that up. Where can I go to get a 15-min summary of ecrit?=20 -----Original Message----- From: Stark, Barbara=20 Sent: Friday, January 05, 2007 10:43 AM To: Brian Rosen Cc: ECRIT Subject: [Ecrit] multipart Brian, You said "I am more than a little worried about multipart in this case however. If the existing systems don't implement multipart, they get hosed pretty badly." Forgive my ignorance -- Can you expand on what this means? My understanding of SDP and MIME types and such is only surface deep, and this comment flew straight over my head. I would have just emailed you, and not copied ecrit. But experience has taught me I'm usually not alone in my ignorance, and I don't remember having seen this mentioned or discussed in any previous threads. Barbara ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA621 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jan 05 12:03:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sTq-0001aZ-KG; Fri, 05 Jan 2007 12:03:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sTo-0001aS-Vc for ecrit@ietf.org; Fri, 05 Jan 2007 12:03:44 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2sTm-0004Wp-M1 for ecrit@ietf.org; Fri, 05 Jan 2007 12:03:44 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1H2sT9-0001zz-OK; Fri, 05 Jan 2007 11:03:03 -0600 From: "Brian Rosen" To: "'Stark, Barbara'" Date: Fri, 5 Jan 2007 12:03:38 -0500 Message-ID: <01e501c730eb$73a5ec10$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AccwSkzy+2lpmwZfQ/isKrIUsW7KswAF9d8gACDidKAAAPTE8A== In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA2B5343@crexc41p> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: 'ECRIT' Subject: [Ecrit] RE: multipart X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Okay, in a SIP message, there is a "body". The body is MIME encoded. Simple MIME has a type like "application/SDP", and that would be what you find in an INVITE with an offer. When you send the geolocation header and you include location by value, the value goes in the body of the message, with "application/pidf+xml". So now you get to ask, what mime type do you use if you have BOTH a hunk of SDP and a location value. The answer is you use mime/multipart, as in the following snippet: Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ... --boundary1 Content-Type: application/sdp ...SDP here --boundary1 Content-Type: application/pidf+xml Content-ID: alice123@atlanta.example.com ..... The problem is that many SIP implementations have neglected to include support for multipart. If a UA was upgraded to support geolocation, it would have to be upgraded to support multipart. Proxies don't normally look at bodies, so that's probably not much of a problem. The concern would be things like SBCs and other B2BUAs, as well as the specific concern here of the gateways in the i2 systems. Brian > -----Original Message----- > From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] > Sent: Friday, January 05, 2007 11:43 AM > To: Brian Rosen > Cc: ECRIT > Subject: multipart > > Brian, > You said > "I am more than a little worried about multipart in this case however. > If > the existing systems don't implement multipart, they get hosed pretty > badly." > > Forgive my ignorance -- > Can you expand on what this means? My understanding of SDP and MIME > types and such is only surface deep, and this comment flew straight over > my head. > > I would have just emailed you, and not copied ecrit. But experience has > taught me I'm usually not alone in my ignorance, and I don't remember > having seen this mentioned or discussed in any previous threads. > Barbara > > ***** > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential, proprietary, and/or > privileged material. Any review, retransmission, dissemination or other > use of, or taking of any action in reliance upon this information by > persons or entities other than the intended recipient is prohibited. If > you received this in error, please contact the sender and delete the > material from all computers. GA623 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jan 05 12:55:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tIA-0006oc-21; Fri, 05 Jan 2007 12:55:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tI8-0006oW-PL for ecrit@ietf.org; Fri, 05 Jan 2007 12:55:44 -0500 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2tI7-0003NM-Jg for ecrit@ietf.org; Fri, 05 Jan 2007 12:55:44 -0500 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 05 Jan 2007 12:55:09 -0500 id 015884B9.459E90FD.00002FF5 In-Reply-To: <6FEBBDAA0B74D34E806D366A431F36B70166F558@brexc47p> References: <6FEBBDAA0B74D34E806D366A431F36B70166F558@brexc47p> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] multipart Date: Fri, 5 Jan 2007 12:55:31 -0500 To: "Beyer, Loraine" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jan 5, 2007, at 11:50 AM, Beyer, Loraine wrote: > Thanks for bringing that up. Where can I go to get a 15-min > summary of > ecrit? You might be able to sweet talk Henning into providing you a sneak peak at a really good paper he just submitted to NetCri on this subject. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jan 05 13:42:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2u1C-0007Vq-8H; Fri, 05 Jan 2007 13:42:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2u1B-0007Vb-FR for ecrit@ietf.org; Fri, 05 Jan 2007 13:42:17 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2u19-000068-2t for ecrit@ietf.org; Fri, 05 Jan 2007 13:42:17 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 05 Jan 2007 10:42:13 -0800 X-IronPort-AV: i="4.13,154,1167638400"; d="scan'208"; a="354889077:sNHT52795594" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l05IgCr5015246; Fri, 5 Jan 2007 10:42:12 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l05Ig7Us026477; Fri, 5 Jan 2007 10:42:12 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 13:42:07 -0500 Received: from jmpolk-wxp.cisco.com ([10.89.16.129]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 13:42:06 -0500 Message-Id: <4.3.2.7.2.20070105123717.0296bc30@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 05 Jan 2007 12:42:06 -0600 To: "Brian Rosen" , "'Stark, Barbara'" From: "James M. Polk" Subject: Re: [Ecrit] RE: multipart In-Reply-To: <01e501c730eb$73a5ec10$640fa8c0@cis.neustar.com> References: <7582BC68E4994F4ABF0BD4723975C3FA2B5343@crexc41p> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 05 Jan 2007 18:42:06.0979 (UTC) FILETIME=[3358B530:01C730F9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3391; t=1168022532; x=1168886532; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20RE=3A=20multipart |Sender:=20; bh=QHP48bu5fqG5itgIlD8TJqrR8vGOQ+zp83tE9Ea5vOQ=; b=eIUPi0qpr3iTTazlnYzoH9tTsMo71eY2eBto39P8ctd+jpcXa7cWjDEMI4fdBnEwtntIXLXO w3lnnG5UkMiUsOahhDvAf4pVw3jFj39O+JOmZsaLmqwv/G9uuZLpZOXf; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Barbara It is not specified in RFC3261 (the base SIP spec) that "mulitpart" (i.e. multiple message body parts) be able to be included in any one SIP message; though this has been talked about at IETF meetings from years to remedy - someone always sways the WG not to consider it "now". Unfortunately, there are several of these little tweeks to SIP the WG has been talking about for the same set of years (i.e. like removing UDP as an appropriate transport because of fragmentation problems with large messages - instead using TCP or SCTP). At 12:03 PM 1/5/2007 -0500, Brian Rosen wrote: >Okay, in a SIP message, there is a "body". The body is MIME encoded. >Simple MIME has a type like "application/SDP", and that would be what you >find in an INVITE with an offer. > >When you send the geolocation header and you include location by value, the >value goes in the body of the message, with "application/pidf+xml". > >So now you get to ask, what mime type do you use if you have BOTH a hunk of >SDP and a location value. > >The answer is you use mime/multipart, as in the following snippet: > Content-Type: multipart/mixed; boundary=boundary1 > Content-Length: ... > > --boundary1 > > Content-Type: application/sdp > > ...SDP here > > --boundary1 > > Content-Type: application/pidf+xml > Content-ID: alice123@atlanta.example.com > > >..... > >The problem is that many SIP implementations have neglected to include >support for multipart. If a UA was upgraded to support geolocation, it >would have to be upgraded to support multipart. Proxies don't normally look >at bodies, so that's probably not much of a problem. The concern would be >things like SBCs and other B2BUAs, as well as the specific concern here of >the gateways in the i2 systems. > >Brian > > > -----Original Message----- > > From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] > > Sent: Friday, January 05, 2007 11:43 AM > > To: Brian Rosen > > Cc: ECRIT > > Subject: multipart > > > > Brian, > > You said > > "I am more than a little worried about multipart in this case however. > > If > > the existing systems don't implement multipart, they get hosed pretty > > badly." > > > > Forgive my ignorance -- > > Can you expand on what this means? My understanding of SDP and MIME > > types and such is only surface deep, and this comment flew straight over > > my head. > > > > I would have just emailed you, and not copied ecrit. But experience has > > taught me I'm usually not alone in my ignorance, and I don't remember > > having seen this mentioned or discussed in any previous threads. > > Barbara > > > > ***** > > > > The information transmitted is intended only for the person or entity to > > which it is addressed and may contain confidential, proprietary, and/or > > privileged material. Any review, retransmission, dissemination or other > > use of, or taking of any action in reliance upon this information by > > persons or entities other than the intended recipient is prohibited. If > > you received this in error, please contact the sender and delete the > > material from all computers. GA623 > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jan 05 14:17:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2uYb-0002QC-CF; Fri, 05 Jan 2007 14:16:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2uYa-0002Q6-J4 for ecrit@ietf.org; Fri, 05 Jan 2007 14:16:48 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2uYY-0001he-B5 for ecrit@ietf.org; Fri, 05 Jan 2007 14:16:48 -0500 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l05JGcQt020693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 5 Jan 2007 14:16:38 -0500 (EST) In-Reply-To: References: <6FEBBDAA0B74D34E806D366A431F36B70166F558@brexc47p> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] multipart Date: Fri, 5 Jan 2007 14:17:58 -0500 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: "Beyer, Loraine" , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The paper has just been accepted at NetCri 07 (http://www.cs.umd.edu/ ~sharno/NetCri07/). A preliminary version can be found at http://www.cs.columbia.edu/~hgs/papers/Schu07_LoST.pdf The published version will look a bit different. This is joint work with Hannes, Andy and Ted. Naturally, comments from the ECRIT WG would be most welcome as we prepare the final version. On Jan 5, 2007, at 12:55 PM, Andrew Newton wrote: > > On Jan 5, 2007, at 11:50 AM, Beyer, Loraine wrote: > >> Thanks for bringing that up. Where can I go to get a 15-min >> summary of >> ecrit? > > You might be able to sweet talk Henning into providing you a sneak > peak at a really good paper he just submitted to NetCri on this > subject. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jan 05 15:58:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2w95-0007re-KT; Fri, 05 Jan 2007 15:58:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2w94-0007rP-Bc for ecrit@ietf.org; Fri, 05 Jan 2007 15:58:34 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2w90-0002Qk-03 for ecrit@ietf.org; Fri, 05 Jan 2007 15:58:34 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1H2w8K-0000FD-03; Fri, 05 Jan 2007 14:57:48 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] call marking Date: Fri, 5 Jan 2007 15:58:25 -0500 Message-ID: <029201c7310c$40446060$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AccwbtwRr+51o20aQR+BZPRi74GemQAfV47w In-Reply-To: <0CF668A4-32AE-4DB0-B1D8-59A1B0449FB7@cs.columbia.edu> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 1.0 (+) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Inline > > 1. Actual routing; knowing how to route the call, especially if > > there is > > more than one element involved. I think this is the big one. We > > need the > > service URN to stay around even after we have done one level of LoST > > routing. This includes things like having the call go to the E- > > CSCF in the > > visited network instead of anything in the home network, for example. > > We discussed this before. Just for routing, we don't need a generic > emergency marking. Let's go through this: > > (1) Let's assume the UAC recognizes the emergency call (things work > if it inserts a tel: URI or a sip dial string, it's just one stage > delayed) > > (2) The request URI is urn:service:sos and the call gets proxied to > the outbound proxy, P-CSCF or some special ES proxy, based on UAC > policy. How? Specifically, you are hoping that the routing up to the LoST stage doesn't need any changes to the R-URI. I'm not sure that always works. It may work to force anything that needs something specific to use a Route header. > > (3) That proxy recognizes the routing, invokes LoST based on the > service and sends it to sip:something@somewhere. If the service > matters, each service gets a different (user part) URL. Haven't you now done something we try not to do: imply service meaning in a general SIP URI? We have the service URN for that purpose :) We've been down that road more than once, with not so great results. > > (4) The call arrives 'somewhere'; since it recognizes the URL as > requiring special treatment (by normal proxy behavior and local > rules), it does another LoST lookup. Ah, but you've skipped a step. You are assuming there is no proxy between the one from step 3 and "somewhere". Take, for example, an exit proxy on a domain. It can't tell this is an emergency call, and it may wish to do something different for routing such a call. I also object, although I agree it works, to do something that amounts to hiding the service name in a SIP uri, then recreating the service uri using string hacking on the made up sip URI for the purpose of doing the next pass of routing. > > (5) Repeat (3) and (4) until the call terminates at a PSAP. > > > > > > 2. Allowing the UAS, and a proxy on the route, to know what service > > is being > > requested > > I agree that the destination needs to know whether I want "fire" or > "police" if these are different PSAPs or call takers or call taker > protocols, but it is not clear that this requires a single, uniform > marking. If these should be handled differently, the LoST-invoking > can easily generate > > police@psap.nyc.gov > poison@psap.nyc.gov > > or any other local convention that makes sense. This ensures that > there is no intra-protocol disagreement, such as > > INVITE sip:police@psap.nyc.gov > Emergency-service: poison > > i.e., another error condition. For a variety of reasons (such as the > SIP history mechanism), adding non-URL/non-Route things that > influence call routing is dubious. Well, agree that non-RequestURI/non-Route things that influence routing are dubious. > > > 3. Invoking emergency call specific behavior, like adding location > > I fully agree that a UAC should be able to ask a proxy to insert > location; however, it should do this with an explicit protocol > request "please insert location", since I might want the same > location-insertion behavior when asking for AAA car-towing service or > Domino's pizza delivery service. Yeah, I don't think this is emergency specific. It may well be service specific. I think this does need some care in design, because it could be a way to trick you into revealing location if not carefully specified. > > > > 4. Priority handling of signaling and media within the network at > > all levels > > As you noted, media is its own thing (DSCP) and signaling is > presumably SIP Resource-Priority. We may want to define an R-P > namespace. Yes, I think these are orthogonal, and I don't want them commingled with something that affects routing. > > > > 5. Disabling of services like call waiting that are provided by the > > network > > Not a signaling function. I don't know what you are getting at here. I'll kind of agree that is is more state (you are in an emergency call) then a message parameter of some sort, but the reality, rightly or wrongly, is that in many systems the network implements services (using things like 3PCC) and some of those services have to be disabled in an emergency call > > > > 6. Charging issues or lack thereof > > This is a critical one where the properties matter. We don't want to > a mechanism that allows > > INVITE sip:alice@nursinghome.org (my grandmother) > Service: don't-charge-since-its-an-emergency > > Thus, for this to be useful, all such calls need to be forced to be > routed to a PSAP. At the first hop (UAC to first proxy), the service > URN has the right property: it can disable charging and enforces that > the call only goes to a PSAP. I suspect that for most practical > purposes, this is sufficient or we need a more general mechanism that > relies on inter-provider trust assertions or settlement mechanisms. Well if the endpoint does the LoST route, which you and I advocate, then the downstream proxies don't know this is an emergency call, and thus would assume you can charge. I do think this case has the problem that if you were to do: INVITE urn:service:sos Route: sip:alice@nursinghome.org Then you create the problem we're talking about. The way I think you can mitigate it is to allow the carrier to re-run the LoST query, if it wants to, to figure out that the right thing is happening. In most cases, it will be able to cache domains that it knows are PSAPs, so the incidence of actual LoST query just to validate charging issues should be rare. Doing that implies it can get the location, and that pushes the authorization hot button again, but if emergency calls are allowed to dereference without authorization, it works. Note that in most cases, this can be a non-real-time check. You can progress the call and worry about the charging later. > > > > 7. Processing of the call at all (some systems will allow emergency > > calls, > > but no other forms of call), like a cellphone with no service plan. > > Seems similar to (6). Well, it may be similar but it may need different mechanisms. If you use the service urn in the R-URI and the PSAP URI in the Route header, the same mechanism is sufficient. > > > 8. Assistance in detecting theft of service when fraudulent > > attempts to get > > the above are attempted without a genuine service call > > > > That's more of a requirement, related to (6). > > Thus, I believe that the only real issue are (6) and (7), which need > to satisfy the "atomicity" that call routing and behavior are > inextricably tied (only calls routed to an emergency location get > this behavior). Conveniently, the current SIP routing proposal (Route > + request URI) has the right properties to make that happen. Hmmm, did I miss something? I think service URN in the R-URI and PSAP URI in Route is a good mark for routing. The last proposal I heard from you was replace R-URI with PSAP URI. What are you advocating? > > In summary, I think we have the right tools, except for > > - something in R-P > > - an "insert location please" mechanism, for proxy-provided location I agree with this, although I'd add a DSCP for media _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jan 05 21:06:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H30wf-0001Vj-JL; Fri, 05 Jan 2007 21:06:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H30wd-0001Ve-Rt for ecrit@ietf.org; Fri, 05 Jan 2007 21:06:03 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H30wc-0000LL-Gm for ecrit@ietf.org; Fri, 05 Jan 2007 21:06:03 -0500 Received: from [192.168.0.41] (pool-141-153-205-123.mad.east.verizon.net [141.153.205.123]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0625ouu021843 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 5 Jan 2007 21:05:51 -0500 (EST) In-Reply-To: <029201c7310c$40446060$640fa8c0@cis.neustar.com> References: <029201c7310c$40446060$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4A4B36D7-200A-48E7-8864-7499A6324EBC@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] call marking Date: Fri, 5 Jan 2007 21:05:47 -0500 To: Brian Rosen X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jan 5, 2007, at 3:58 PM, Brian Rosen wrote: >> (2) The request URI is urn:service:sos and the call gets proxied to >> the outbound proxy, P-CSCF or some special ES proxy, based on UAC >> policy. > How? Specifically, you are hoping that the routing up to the LoST > stage > doesn't need any changes to the R-URI. I'm not sure that always > works. It > may work to force anything that needs something specific to use a > Route > header. > See below. >> >> (3) That proxy recognizes the routing, invokes LoST based on the >> service and sends it to sip:something@somewhere. If the service >> matters, each service gets a different (user part) URL. > Haven't you now done something we try not to do: imply service > meaning in a > general SIP URI? We have the service URN for that purpose :) > We've been > down that road more than once, with not so great results. This is local only, between consenting proxies. > >> >> (4) The call arrives 'somewhere'; since it recognizes the URL as >> requiring special treatment (by normal proxy behavior and local >> rules), it does another LoST lookup. > Ah, but you've skipped a step. You are assuming there is no proxy > between > the one from step 3 and "somewhere". Take, for example, an exit > proxy on a > domain. It can't tell this is an emergency call, and it may wish > to do > something different for routing such a call. If a proxy gets a call, there are four cases: (1) it's a local URL and handled via its registration database (not applicable here) (2) route it to a fixed place (if the URL is not recognized at all) (3) route it to the destination domain specified in the URL (not applicable here) (4) recognize a service or tel URI and map it to something routable For your case, you're assuming it's not (4) since it is not recognizing the emergency call, so it doesn't matter what it is and case (2) applies. > > I also object, although I agree it works, to do something that > amounts to > hiding the service name in a SIP uri, then recreating the service > uri using > string hacking on the made up sip URI for the purpose of doing the > next pass > of routing. It's not re-creating the service URN. It's just mapping a string to a service URN, no different than mapping sip:911@somewhere.com to a service. Again, this is a somewhat pointless discussion with the R-URI/Route mechanism currently proposed. I'm just trying to show that this can work. >> >>> 3. Invoking emergency call specific behavior, like adding location >> > > I think this does need some care in design, because it could be a > way to > trick you into revealing location if not carefully specified. > Indeed, but that illustrates that having a single marking is probably a bad idea, as some markings are dangerous to the UAC if inserted by third parties (such as this one) and others are dangerous to the PSAP or the carrier (such as anything that bypasses charging). Thus, the necessary trust relationships are different. For this particular kind of request, I'm not that tying this to routing is helpful, but it might be as long as routing is done by the same entity that inserts the location information. (If Trudy modifies a request to obtain location information, she can only get it routed to a PSAP, not a location of her choosing, where she can inspect the result.) >> >> >>> 5. Disabling of services like call waiting that are provided by the >>> network >> >> Not a signaling function. > I don't know what you are getting at here. I'll kind of agree that > is is > more state (you are in an emergency call) then a message parameter > of some > sort, but the reality, rightly or wrongly, is that in many systems the > network implements services (using things like 3PCC) and some of those > services have to be disabled in an emergency call I suspect we'd have to talk more concretely about specific services. Again, I'd rather have something that turns off a particular service explicitly, rather than implying this indirectly. Also, not all emergency calls will be routed via the home proxy, so this is not likely to be too helpful. > Well if the endpoint does the LoST route, which you and I advocate, > then the > downstream proxies don't know this is an emergency call, and thus > would > assume you can charge. I do think this case has the problem that > if you > were to do: > > INVITE urn:service:sos > Route: sip:alice@nursinghome.org > > Then you create the problem we're talking about. The way I think > you can > mitigate it is to allow the carrier to re-run the LoST query, if it > wants > to, to figure out that the right thing is happening. In most > cases, it will > be able to cache domains that it knows are PSAPs, so the incidence > of actual > LoST query just to validate charging issues should be rare. Doing > that > implies it can get the location, and that pushes the authorization hot > button again, but if emergency calls are allowed to dereference > without > authorization, it works. Note that in most cases, this can be a > non-real-time check. You can progress the call and worry about the > charging > later. I mostly agree. However, if the call is unauthenticated, "charging later" is not likely to be an option. For different reasons, I think that encouraging unauthenticated emergency calls is a bad idea. (As discussed elsewhere, having an emergency call authenticator does not imply having a monthly subscription with the phone company. "Get code at DMV" will do, as will other mechanisms.) > >> > Hmmm, did I miss something? I think service URN in the R-URI and > PSAP URI > in Route is a good mark for routing. The last proposal I heard > from you was > replace R-URI with PSAP URI. What are you advocating? > I think either will work. I'm still of the opinion that Route + service R-URI is the best solution, but we can probably make things work even without it, i.e., the traditional "replace R-URI" approach. >> >> In summary, I think we have the right tools, except for >> >> - something in R-P >> >> - an "insert location please" mechanism, for proxy-provided location > I agree with this, although I'd add a DSCP for media Sure, although I'm somewhat doubtful that DSCP is likely to be implemented or useful across the Internet, as it is much harder to secure than signaling priority. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jan 06 09:31:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Ca9-0004Hc-Gl; Sat, 06 Jan 2007 09:31:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Ca9-0004HX-47 for ecrit@ietf.org; Sat, 06 Jan 2007 09:31:37 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H3Ca7-00062u-Le for ecrit@ietf.org; Sat, 06 Jan 2007 09:31:37 -0500 Received: (qmail invoked by alias); 06 Jan 2007 14:31:31 -0000 Received: from p54987B18.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.123.24] by mail.gmx.net (mp002) with SMTP; 06 Jan 2007 15:31:31 +0100 X-Authenticated: #29516787 Message-ID: <459FB2C2.9050206@gmx.net> Date: Sat, 06 Jan 2007 15:31:30 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: ECRIT X-Y-GMX-Trusted: 0 X-Spam-Score: 0.3 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Subject: [Ecrit] ECRIT Charter Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1252220264==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1252220264== Content-Type: multipart/alternative; boundary="------------070102010602080201090805" This is a multi-part message in MIME format. --------------070102010602080201090805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, this is our current goals and milestone list: Jul 2006 Informational RFC containing terminology definitions and the requirements Jul 2006 An Informational document describing the threats and security considerations Jul 2006 A Standards Track RFC describing how to identify a session set-up request is to an emergency response center Nov 2006 A Standards Track RFC describing how to route an emergency call based on location information Nov 2006 An Informational document describing the Mapping Protocol Architecture Dec 2006 An Informational document describing the ECRIT Framework Feb 2007 A BCP document describing the emergency call support for devices We need to update the webpage to reflect reality. Here is a suggestion: DONE Informational RFC containing terminology definitions and the requirements DONE An Informational document describing the threats and security considerations DONE A Standards Track RFC describing how to identify a session set-up request is to an emergency response center March 2007 A Standards Track RFC describing how to route an emergency call based on location information March 2007 An Informational document describing the Mapping Protocol Architecture March 2007 An Informational document describing the ECRIT Framework April 2007 A BCP document describing the emergency call support for devices Thoughts? Deadline: 20th January 2007 Ciao Hannes & Marc --------------070102010602080201090805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

this is our current goals and milestone list:

Jul 2006    Informational RFC containing terminology definitions and the requirements
Jul 2006    An Informational document describing the threats and security considerations
Jul 2006    A Standards Track RFC describing how to identify a session set-up request is to an emergency response center
Nov 2006    A Standards Track RFC describing how to route an emergency call based on location information
Nov 2006    An Informational document describing the Mapping Protocol Architecture
Dec 2006    An Informational document describing the ECRIT Framework
Feb 2007    A BCP document describing the emergency call support for devices

We need to update the webpage to reflect reality. Here is a suggestion:

DONE    Informational RFC containing terminology definitions and the requirements
DONE    An Informational document describing the threats and security considerations
DONE    A Standards Track RFC describing how to identify a session set-up request is to an emergency response center
March 2007    A Standards Track RFC describing how to route an emergency call based on location information
March 2007    An Informational document describing the Mapping Protocol Architecture
March 2007    An Informational document describing the ECRIT Framework
April 2007
    A BCP document describing the emergency call support for devices

Thoughts?

Deadline: 20th January 2007

Ciao
Hannes & Marc

--------------070102010602080201090805-- --===============1252220264== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1252220264==-- From ecrit-bounces@ietf.org Sat Jan 06 09:42:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3CkP-0007hD-Bq; Sat, 06 Jan 2007 09:42:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3CkO-0007h3-4I for ecrit@ietf.org; Sat, 06 Jan 2007 09:42:12 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H3CkJ-0000aS-Lu for ecrit@ietf.org; Sat, 06 Jan 2007 09:42:12 -0500 Received: (qmail invoked by alias); 06 Jan 2007 14:42:06 -0000 Received: from p54987B18.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.123.24] by mail.gmx.net (mp037) with SMTP; 06 Jan 2007 15:42:06 +0100 X-Authenticated: #29516787 Message-ID: <459FB53C.2090003@gmx.net> Date: Sat, 06 Jan 2007 15:42:04 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: iab@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Christian.Militeau@Intrado.com, ECRIT Subject: [Ecrit] ATIS Liaison X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Dear IAB members, recently, ATIS released emergency service documents (ESMI and EISI standards, see attachment) and Christian Militeau (ATIS/ESIF TF34 Chair) kindly offered the possibility to make the mentioned ATIS documents available for the ECRIT working group. An official liaison letter to ATIS is need for this purpose. Do we have an active liaison to ATIS? If not, is there an easy and fast way to setup a liaison so that the ECRIT working group can review the documents? Ciao Hannes & Marc From: owner-atispr@lists.atis.org [mailto:owner-atispr@lists.atis.org] On Behalf Of ATIS Sent: Monday, December 04, 2006 12:11 PM Subject: ATIS PRESS RELEASE: ATIS Releases Suite of IP-based Emergency Services Standards ATIS Releases Suite of IP-based Emergency Services Standards December 4, 2006, Washington ? ATIS today announced the availability of its newly developed suite of IP-based Emergency Services Network Interface (ESNI) standards that will enable the expansion of E9-1-1 services and functionality within the Next Generation Network (NGN). The ESNI suite of standards includes an overall emergency services framework for the ESNI applications and protocols such as the Emergency Information Services Interface (EISI) that provide access to emergency services within or external to the Emergency Services Network (ESNet). The ESNI standards suite also includes the Emergency Services Messaging Interface (ESMI), released in September 2005, which provides managed interconnections between next generation public service answering points (PSAPs) and the ESNet. For more information, see the full release online at http://www.atis.org/PRESS/pressreleases2006/120406.htm. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jan 06 09:59:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3D0u-0005ou-4A; Sat, 06 Jan 2007 09:59:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3D0s-0005ok-Rq for ecrit@ietf.org; Sat, 06 Jan 2007 09:59:14 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H3D0o-00049K-D0 for ecrit@ietf.org; Sat, 06 Jan 2007 09:59:14 -0500 Received: (qmail invoked by alias); 06 Jan 2007 14:59:09 -0000 Received: from p54987B18.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.123.24] by mail.gmx.net (mp039) with SMTP; 06 Jan 2007 15:59:09 +0100 X-Authenticated: #29516787 Message-ID: <459FB93B.9060909@gmx.net> Date: Sat, 06 Jan 2007 15:59:07 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: bernard_aboba@hotmail.com, bwijnen@alcatel-lucent.com, dromasca@avaya.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ECRIT Subject: [Ecrit] IETF ECRIT and IEEE X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Bernard, Bert, Dan, at the last "SDO Emergency Services Coordination Workshop (ESW06)" (see http://www.ietf-ecrit.org/EmergencyWorkshop2006/) we noticed that the IEEE does a lot of work in the area of emergency services. Two suggestions were made: a) In the IETF ECRIT working group we are developing a framework document (see http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-framework/draft-ietf-ecrit-framework-00.txt) and we believe that it is important to consider link layer aspects to capture the big picture of emergency services. Currently, our framework document does not adequately address this subject. We would appreciate a review and help. b) At the workshop we noticed that the details of the ongoing IEEE work in this space is not widely known. I wonder whether there is a chance to arrange a more detailed information exchange between the IETF ECRIT (potentially IETF GEOPRIV) working group and the respective groups within the IEEE. A workshop in the style of the joint IETF ECRIT / 3GPP Emergency Services Workshop might be useful. We would appreciate your help to arrange a closer cooperation between the IETF and the IEEE regarding this subject. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jan 06 10:00:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3D2E-0006Bs-Is; Sat, 06 Jan 2007 10:00:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3D2D-0006Bl-OE for ecrit@ietf.org; Sat, 06 Jan 2007 10:00:37 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H3D2C-0004PE-G8 for ecrit@ietf.org; Sat, 06 Jan 2007 10:00:37 -0500 Received: (qmail invoked by alias); 06 Jan 2007 15:00:35 -0000 Received: from p54987B18.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.123.24] by mail.gmx.net (mp051) with SMTP; 06 Jan 2007 16:00:35 +0100 X-Authenticated: #29516787 Message-ID: <459FB992.4010200@gmx.net> Date: Sat, 06 Jan 2007 16:00:34 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Ecrit] ECRIT Status X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, this is a reminder to sometimes look at the ECRIT status webpage: http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/IetfEcritRoadMap Please let us know if something is wrong or missing. Some folks might also recognize that they promised a review but haven't provided anything so far. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jan 06 10:10:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3DBt-0000aP-Vq; Sat, 06 Jan 2007 10:10:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3DBs-0000Zr-7p for ecrit@ietf.org; Sat, 06 Jan 2007 10:10:36 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H3DBq-0007Jn-Qu for ecrit@ietf.org; Sat, 06 Jan 2007 10:10:36 -0500 Received: (qmail invoked by alias); 06 Jan 2007 15:10:33 -0000 Received: from p54987B18.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.123.24] by mail.gmx.net (mp013) with SMTP; 06 Jan 2007 16:10:33 +0100 X-Authenticated: #29516787 Message-ID: <459FBBE7.7020905@gmx.net> Date: Sat, 06 Jan 2007 16:10:31 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: iab@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ECRIT Subject: [Ecrit] Topic Specific Liaisons X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Dear IAB members, at the last "SDO Emergency Services Coordination Workshop (ESW06)" (see http://www.ietf-ecrit.org/EmergencyWorkshop2006/) we were asking ourself whether there is a chance to establish topic specific liaisons between the IETF ECRIT working group (potentially the GEOPRIV working group as well) and different organizations (such as the Packet Cable, DSL Forum, NENA, ETSI TISPAN, ETSI EMTEL, ATIS-ESIF, OMA, etc.) to have a formal basis for the exchange of documents, for initiating reviews, etc. We wonder how difficult and time consuming it is to setup these liaisons. What are other alternatives (particularly when documents by some organizations are not publically available)? Can you help us? Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jan 06 14:42:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3HQK-00029x-E3; Sat, 06 Jan 2007 14:41:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3HQJ-000293-27 for ecrit@ietf.org; Sat, 06 Jan 2007 14:41:47 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3HQE-0005b1-NK for ecrit@ietf.org; Sat, 06 Jan 2007 14:41:47 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1H3HQ0-0004Js-Om; Sat, 06 Jan 2007 13:41:29 -0600 From: "Brian Rosen" To: "'Hannes Tschofenig'" Subject: RE: [Ecrit] ATIS Liaison Date: Sat, 6 Jan 2007 14:41:36 -0500 Message-ID: <042401c731ca$af50c750$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AccxoN1CXdp2pTwCQiCZfl4rXHcQtwAKWlXQ In-Reply-To: <459FB53C.2090003@gmx.net> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Christian.Militeau@Intrado.com, 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Since the document was attached to the liaison, and available on the web at the indicated URL, what would we get if we did get a liaison relationship established? They sent us the document. We can send comment back through Christian or any of the numberous ecrit members who have access to ATIS contribution processes. I am NOT opposed to a liaison relationship with NGES, I'm just trying to avoid work. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Saturday, January 06, 2007 9:42 AM > To: iab@ietf.org > Cc: Christian.Militeau@Intrado.com; ECRIT > Subject: [Ecrit] ATIS Liaison > > Dear IAB members, > > recently, ATIS released emergency service documents (ESMI and EISI > standards, see attachment) and Christian Militeau (ATIS/ESIF TF34 Chair) > kindly offered the possibility to make the mentioned ATIS documents > available for the ECRIT working group. > > An official liaison letter to ATIS is need for this purpose. > > Do we have an active liaison to ATIS? If not, is there an easy and fast > way to setup a liaison so that the ECRIT working group can review the > documents? > > Ciao > Hannes & Marc > > > > From: owner-atispr@lists.atis.org [mailto:owner-atispr@lists.atis.org] On > Behalf Of ATIS > Sent: Monday, December 04, 2006 12:11 PM > Subject: ATIS PRESS RELEASE: ATIS Releases Suite of IP-based Emergency > Services Standards > > ATIS Releases Suite of IP-based Emergency Services Standards > December 4, 2006, Washington ? ATIS today announced the availability of > its newly developed suite of IP-based Emergency Services Network Interface > (ESNI) standards that will enable the expansion of E9-1-1 services and > functionality within the Next Generation Network (NGN). > The ESNI suite of standards includes an overall emergency services > framework for the ESNI applications and protocols such as the Emergency > Information Services Interface (EISI) that provide access to emergency > services within or external to the Emergency Services Network (ESNet). The > ESNI standards suite also includes the Emergency Services Messaging > Interface (ESMI), released in September 2005, which provides managed > interconnections between next generation public service answering points > (PSAPs) and the ESNet. > > > For more information, see the full release online at > http://www.atis.org/PRESS/pressreleases2006/120406.htm. > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jan 06 14:44:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3HTP-0003C7-0r; Sat, 06 Jan 2007 14:44:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3HTN-0003C1-DA for ecrit@ietf.org; Sat, 06 Jan 2007 14:44:57 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3HTM-0006A5-0z for ecrit@ietf.org; Sat, 06 Jan 2007 14:44:57 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1H3HTA-0004e0-ED; Sat, 06 Jan 2007 13:44:44 -0600 From: "Brian Rosen" To: "'Brian Rosen'" , "'Hannes Tschofenig'" Subject: RE: [Ecrit] ATIS Liaison Date: Sat, 6 Jan 2007 14:44:52 -0500 Message-ID: <042901c731cb$23e54aa0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AccxoN1CXdp2pTwCQiCZfl4rXHcQtwAKWlXQAAAg5TA= In-Reply-To: <62B89492B130A740A48CEE3227174D9D03CD30FA2F@stntexch12.cis.neustar.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Christian.Militeau@Intrado.com, 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Oops, wrong documents. ESMI/EISI was not sent to us, it was the location document. Sorry for the confusion. I guess we need a liaison to get them. You might want to think through what we can do with the docs if we get them. We can't put them on a public website can we? Do we have to email the doc as an attachment to the list? Ugh. Brian > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Saturday, January 06, 2007 2:42 PM > To: Hannes Tschofenig > Cc: Christian.Militeau@Intrado.com; ECRIT > Subject: RE: [Ecrit] ATIS Liaison > > > > > Since the document was attached to the liaison, and available on the web > at the indicated URL, what would we get if we did get a liaison > relationship established? They sent us the document. We can send comment > back through Christian or any of the numberous ecrit members who have > access to ATIS contribution processes. > > I am NOT opposed to a liaison relationship with NGES, I'm just trying to > avoid work. > > Brian > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Saturday, January 06, 2007 9:42 AM > > To: iab@ietf.org > > Cc: Christian.Militeau@Intrado.com; ECRIT > > Subject: [Ecrit] ATIS Liaison > > > > Dear IAB members, > > > > recently, ATIS released emergency service documents (ESMI and EISI > > standards, see attachment) and Christian Militeau (ATIS/ESIF TF34 Chair) > > kindly offered the possibility to make the mentioned ATIS documents > > available for the ECRIT working group. > > > > An official liaison letter to ATIS is need for this purpose. > > > > Do we have an active liaison to ATIS? If not, is there an easy and fast > > way to setup a liaison so that the ECRIT working group can review the > > documents? > > > > Ciao > > Hannes & Marc > > > > > > > > From: owner-atispr@lists.atis.org [mailto:owner-atispr@lists.atis.org] > On > > Behalf Of ATIS > > Sent: Monday, December 04, 2006 12:11 PM > > Subject: ATIS PRESS RELEASE: ATIS Releases Suite of IP-based Emergency > > Services Standards > > > > ATIS Releases Suite of IP-based Emergency Services Standards > > December 4, 2006, Washington ? ATIS today announced the availability of > > its newly developed suite of IP-based Emergency Services Network > Interface > > (ESNI) standards that will enable the expansion of E9-1-1 services and > > functionality within the Next Generation Network (NGN). > > The ESNI suite of standards includes an overall emergency services > > framework for the ESNI applications and protocols such as the Emergency > > Information Services Interface (EISI) that provide access to emergency > > services within or external to the Emergency Services Network (ESNet). > The > > ESNI standards suite also includes the Emergency Services Messaging > > Interface (ESMI), released in September 2005, which provides managed > > interconnections between next generation public service answering points > > (PSAPs) and the ESNet. > > > > > > For more information, see the full release online at > > http://www.atis.org/PRESS/pressreleases2006/120406.htm. > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 07 06:24:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3W8B-00033N-Jx; Sun, 07 Jan 2007 06:24:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3W8A-00033H-Dw for ecrit@ietf.org; Sun, 07 Jan 2007 06:24:02 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H3W85-0002Z4-Tl for ecrit@ietf.org; Sun, 07 Jan 2007 06:24:02 -0500 Received: (qmail invoked by alias); 07 Jan 2007 11:23:56 -0000 Received: from p54987905.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.121.5] by mail.gmx.net (mp010) with SMTP; 07 Jan 2007 12:23:56 +0100 X-Authenticated: #29516787 Message-ID: <45A0D849.1080704@gmx.net> Date: Sun, 07 Jan 2007 12:23:53 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] ATIS Liaison References: <042901c731cb$23e54aa0$640fa8c0@cis.neustar.com> In-Reply-To: <042901c731cb$23e54aa0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: Christian.Militeau@Intrado.com, 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Brian, Brian Rosen wrote: > Oops, wrong documents. ESMI/EISI was not sent to us, it was the location > document. Sorry for the confusion. I guess we need a liaison to get them. > > You might want to think through what we can do with the docs if we get them. > We also ask other SDOs, including ATIS, to review our documents and to return feedback. Hence, we review their document and provide feedback. Christian, would this be useful for the group within ATIS that produced the document? > We can't put them on a public website can we? Do we have to email the doc > as an attachment to the list? Ugh. > If someone makes documents accessible to us then they are essentially accessible for everyone. Ciao Hannes > Brian > > >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Saturday, January 06, 2007 2:42 PM >> To: Hannes Tschofenig >> Cc: Christian.Militeau@Intrado.com; ECRIT >> Subject: RE: [Ecrit] ATIS Liaison >> >> >> >> >> Since the document was attached to the liaison, and available on the web >> at the indicated URL, what would we get if we did get a liaison >> relationship established? They sent us the document. We can send comment >> back through Christian or any of the numberous ecrit members who have >> access to ATIS contribution processes. >> >> I am NOT opposed to a liaison relationship with NGES, I'm just trying to >> avoid work. >> >> Brian >> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: Saturday, January 06, 2007 9:42 AM >>> To: iab@ietf.org >>> Cc: Christian.Militeau@Intrado.com; ECRIT >>> Subject: [Ecrit] ATIS Liaison >>> >>> Dear IAB members, >>> >>> recently, ATIS released emergency service documents (ESMI and EISI >>> standards, see attachment) and Christian Militeau (ATIS/ESIF TF34 Chair) >>> kindly offered the possibility to make the mentioned ATIS documents >>> available for the ECRIT working group. >>> >>> An official liaison letter to ATIS is need for this purpose. >>> >>> Do we have an active liaison to ATIS? If not, is there an easy and fast >>> way to setup a liaison so that the ECRIT working group can review the >>> documents? >>> >>> Ciao >>> Hannes & Marc >>> >>> >>> >>> From: owner-atispr@lists.atis.org [mailto:owner-atispr@lists.atis.org] >>> >> On >> >>> Behalf Of ATIS >>> Sent: Monday, December 04, 2006 12:11 PM >>> Subject: ATIS PRESS RELEASE: ATIS Releases Suite of IP-based Emergency >>> Services Standards >>> >>> ATIS Releases Suite of IP-based Emergency Services Standards >>> December 4, 2006, Washington ? ATIS today announced the availability of >>> its newly developed suite of IP-based Emergency Services Network >>> >> Interface >> >>> (ESNI) standards that will enable the expansion of E9-1-1 services and >>> functionality within the Next Generation Network (NGN). >>> The ESNI suite of standards includes an overall emergency services >>> framework for the ESNI applications and protocols such as the Emergency >>> Information Services Interface (EISI) that provide access to emergency >>> services within or external to the Emergency Services Network (ESNet). >>> >> The >> >>> ESNI standards suite also includes the Emergency Services Messaging >>> Interface (ESMI), released in September 2005, which provides managed >>> interconnections between next generation public service answering points >>> (PSAPs) and the ESNet. >>> >>> >>> For more information, see the full release online at >>> http://www.atis.org/PRESS/pressreleases2006/120406.htm. >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 07 11:46:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3b9o-00066Y-S3; Sun, 07 Jan 2007 11:46:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3b9n-00066N-D2 for ecrit@ietf.org; Sun, 07 Jan 2007 11:46:03 -0500 Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3b9m-0006j8-5Y for ecrit@ietf.org; Sun, 07 Jan 2007 11:46:03 -0500 Received: from s73602 (failure[218.104.123.2]) by comcast.net (rwcrmhc14) with SMTP id <20070107164600m1400ep7s4e>; Sun, 7 Jan 2007 16:46:00 +0000 Message-ID: <0ae301c7327a$d67d8e20$807b68da@china.huawei.com> From: "Spencer Dawkins" To: "'ECRIT'" References: <7582BC68E4994F4ABF0BD4723975C3FA2B5343@crexc41p> <4.3.2.7.2.20070105123717.0296bc30@email.cisco.com> Subject: Re: [Ecrit] RE: multipart Date: Mon, 8 Jan 2007 00:42:20 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi, James, Just so I don't misquote you... > It is not specified in RFC3261 (the base SIP spec) that "mulitpart" (i.e. > multiple message body parts) be able to be included in any one SIP > message; though this has been talked about at IETF meetings from years to > remedy - someone always sways the WG not to consider it "now". Are you saying that since it's not explicitly specified, that some implementations support it while others don't? Thanks, Spencer _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 07 12:49:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3c9M-0006lm-CG; Sun, 07 Jan 2007 12:49:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3c9M-0006lh-5O for ecrit@ietf.org; Sun, 07 Jan 2007 12:49:40 -0500 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3c9H-0001QV-Td for ecrit@ietf.org; Sun, 07 Jan 2007 12:49:40 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sun, 07 Jan 2007 12:48:54 -0500 id 01588137.45A13286.00004958 In-Reply-To: <0ae301c7327a$d67d8e20$807b68da@china.huawei.com> References: <7582BC68E4994F4ABF0BD4723975C3FA2B5343@crexc41p> <4.3.2.7.2.20070105123717.0296bc30@email.cisco.com> <0ae301c7327a$d67d8e20$807b68da@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Message-Id: <478132E4-7873-45C0-9865-1EE70C5C3FAB@hxr.us> From: Andrew Newton Subject: Re: [Ecrit] RE: multipart Date: Sun, 7 Jan 2007 12:49:22 -0500 To: "Spencer Dawkins" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2109534300==" Errors-To: ecrit-bounces@ietf.org --===============2109534300== Content-Type: multipart/alternative; boundary=Apple-Mail-20-906401604 --Apple-Mail-20-906401604 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jan 7, 2007, at 11:42 AM, Spencer Dawkins wrote: > Are you saying that since it's not explicitly specified, that some > implementations support it while others don't? I don't know what the cause and effect are, but it is true that many implementations do not support it. As to the spec being the cause... well, the spec says MUST for TLS and there are still a good many implementations that do not support this. -andy --Apple-Mail-20-906401604 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=US-ASCII
On Jan 7, 2007, at 11:42 AM, Spencer Dawkins wrote:

Are you saying that since it's not explicitly specified, that some implementations support it while others don't?


I don't know what the cause and effect are, but it is true that many implementations do not support it.

As to the spec being the cause... well, the spec says MUST for TLS and there are still a good many implementations that do not support this.

-andy
--Apple-Mail-20-906401604-- --===============2109534300== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============2109534300==-- From ecrit-bounces@ietf.org Sun Jan 07 12:54:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3cDp-0001Bg-6P; Sun, 07 Jan 2007 12:54:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3cDn-0001BW-HS for ecrit@ietf.org; Sun, 07 Jan 2007 12:54:15 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3cDh-00026f-U5 for ecrit@ietf.org; Sun, 07 Jan 2007 12:54:15 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l07Hs70u023717 for ; Sun, 7 Jan 2007 12:54:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] ATIS Liaison Date: Sun, 7 Jan 2007 19:54:07 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ATIS Liaison Thread-Index: AccxoN1CXdp2pTwCQiCZfl4rXHcQtwAKWlXQAAAg5TAALVQ94A== From: "Romascanu, Dan \(Dan\)" To: "Brian Rosen" , "Hannes Tschofenig" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: Christian.Militeau@Intrado.com, ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I do not know what are the rules of AIS, but it looks to me that sending a document as an attachment to the list ends by having it available in the archives, which is the same as a public website.=20 In the case of other SDOs like the IEEE 802 we had in place agreements where the work-in-progress documents from the IEEE were accessible on a password-protected web site. The WG chair could send the username and password to all WG members per request, but this information was not circulated on the list. Maybe something similar can be put in place in agreement with ATIS.=20 Dan =20 =20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Saturday, January 06, 2007 9:45 PM > To: 'Brian Rosen'; 'Hannes Tschofenig' > Cc: Christian.Militeau@Intrado.com; 'ECRIT' > Subject: RE: [Ecrit] ATIS Liaison >=20 > Oops, wrong documents. ESMI/EISI was not sent to us, it was=20 > the location document. Sorry for the confusion. I guess we=20 > need a liaison to get them. >=20 > You might want to think through what we can do with the docs=20 > if we get them. > We can't put them on a public website can we? Do we have to=20 > email the doc as an attachment to the list? Ugh. >=20 > Brian >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Saturday, January 06, 2007 2:42 PM > > To: Hannes Tschofenig > > Cc: Christian.Militeau@Intrado.com; ECRIT > > Subject: RE: [Ecrit] ATIS Liaison > >=20 > >=20 > > > >=20 > > Since the document was attached to the liaison, and=20 > available on the=20 > > web at the indicated URL, what would we get if we did get a liaison=20 > > relationship established? They sent us the document. We can send=20 > > comment back through Christian or any of the numberous=20 > ecrit members=20 > > who have access to ATIS contribution processes. > >=20 > > I am NOT opposed to a liaison relationship with NGES, I'm=20 > just trying=20 > > to avoid work. > >=20 > > Brian > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: Saturday, January 06, 2007 9:42 AM > > > To: iab@ietf.org > > > Cc: Christian.Militeau@Intrado.com; ECRIT > > > Subject: [Ecrit] ATIS Liaison > > > > > > Dear IAB members, > > > > > > recently, ATIS released emergency service documents (ESMI=20 > and EISI=20 > > > standards, see attachment) and Christian Militeau (ATIS/ESIF TF34=20 > > > Chair) kindly offered the possibility to make the mentioned ATIS=20 > > > documents available for the ECRIT working group. > > > > > > An official liaison letter to ATIS is need for this purpose. > > > > > > Do we have an active liaison to ATIS? If not, is there an=20 > easy and=20 > > > fast way to setup a liaison so that the ECRIT working group can=20 > > > review the documents? > > > > > > Ciao > > > Hannes & Marc > > > > > > > > > > > > From: owner-atispr@lists.atis.org=20 > > > [mailto:owner-atispr@lists.atis.org] > > On > > > Behalf Of ATIS > > > Sent: Monday, December 04, 2006 12:11 PM > > > Subject: ATIS PRESS RELEASE: ATIS Releases Suite of IP-based=20 > > > Emergency Services Standards > > > > > > ATIS Releases Suite of IP-based Emergency Services Standards=20 > > > December 4, 2006, Washington ? ATIS today announced the=20 > availability=20 > > > of its newly developed suite of IP-based Emergency=20 > Services Network > > Interface > > > (ESNI) standards that will enable the expansion of E9-1-1=20 > services=20 > > > and functionality within the Next Generation Network (NGN). > > > The ESNI suite of standards includes an overall emergency=20 > services=20 > > > framework for the ESNI applications and protocols such as the=20 > > > Emergency Information Services Interface (EISI) that=20 > provide access=20 > > > to emergency services within or external to the Emergency=20 > Services Network (ESNet). > > The > > > ESNI standards suite also includes the Emergency Services=20 > Messaging=20 > > > Interface (ESMI), released in September 2005, which=20 > provides managed=20 > > > interconnections between next generation public service answering=20 > > > points > > > (PSAPs) and the ESNet. > > > > > > > > > For more information, see the full release online at=20 > > > http://www.atis.org/PRESS/pressreleases2006/120406.htm. > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 07 13:52:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3d8H-0006fq-Vx; Sun, 07 Jan 2007 13:52:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3d8G-0006fl-Ur for ecrit@ietf.org; Sun, 07 Jan 2007 13:52:36 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3d8C-0004Hj-LV for ecrit@ietf.org; Sun, 07 Jan 2007 13:52:36 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l07IqRZC027335 for ; Sun, 7 Jan 2007 13:52:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 7 Jan 2007 20:52:25 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF ECRIT and IEEE Thread-Index: Accxo2ribQ6iZ7hQQ+qaEqtT2jHuogA5tTxA From: "Romascanu, Dan \(Dan\)" To: "Hannes Tschofenig" , , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: ECRIT Subject: [Ecrit] RE: IETF ECRIT and IEEE X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes, It would be useful to be somehow more specific about the purpose of the exchange of information that you want to entertain with the IEEE 802 Working Groups. A few clarification questions:=20 1. What is the status of draft-ietf-ecrit-framework-00.txt? Is it mature enough for a review by the IEEE or do you need more expert help in filling in with content the link layer sections?=20 2. Do you have any reference about what was the level of information exchange in the joint IETF ECRIT / 3GPP Emergency Services Workshop? Would not a short presentation from each of the IEEE WGs in the ECRIT and GEOPRIV meetings accompanied by appropriate references be enough to start with? We can find probably folks attending both activities who can rely this information, I can do it for 802.1 if needed.=20 Sending liaison letters from ECRIT to the IEEE WGs with specific questions would be a good start. 802.11 will be meting in London the week of 1/15, 802.1 meet in Monterey the week of 1/22.=20 Also, http://www.ietf-ecrit.org/EmergencyWorkshop2006/ mentions the following as IEEE 802 activities - 802.1, IA LLDP MED, 802.11k, 802.11u. Note that LLDP MED is not a IEEE standard, but an extension of IEEE 802.1AB standard (LLDP) which was authored the TIA TR41.4 Working Group. Dan =20 =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Saturday, January 06, 2007 4:59 PM > To: bernard_aboba@hotmail.com; bwijnen@alcatel-lucent.com;=20 > Romascanu, Dan (Dan) > Cc: ECRIT; Marc Linsner > Subject: IETF ECRIT and IEEE >=20 > Hi Bernard, Bert, Dan, >=20 > at the last "SDO Emergency Services Coordination Workshop=20 > (ESW06)" (see > http://www.ietf-ecrit.org/EmergencyWorkshop2006/) we noticed=20 > that the IEEE does a lot of work in the area of emergency services. >=20 > Two suggestions were made: >=20 > a) In the IETF ECRIT working group we are developing a=20 > framework document (see > http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-framework/draf > t-ietf-ecrit-framework-00.txt)=20 >=20 > and we believe that it is important to consider link layer=20 > aspects to capture the big picture of emergency services.=20 > Currently, our framework document does not adequately address=20 > this subject. We would appreciate a review and help. >=20 > b) At the workshop we noticed that the details of the ongoing=20 > IEEE work in this space is not widely known. I wonder whether=20 > there is a chance to arrange a more detailed information=20 > exchange between the IETF ECRIT (potentially IETF GEOPRIV)=20 > working group and the respective groups within the IEEE. A=20 > workshop in the style of the joint IETF ECRIT / 3GPP=20 > Emergency Services Workshop might be useful. >=20 > We would appreciate your help to arrange a closer cooperation=20 > between the IETF and the IEEE regarding this subject. >=20 > Ciao > Hannes & Marc >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 07 15:22:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3eWT-0007h0-J8; Sun, 07 Jan 2007 15:21:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3eWR-0007gh-Lk for ecrit@ietf.org; Sun, 07 Jan 2007 15:21:39 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H3eWP-0002u3-Cb for ecrit@ietf.org; Sun, 07 Jan 2007 15:21:39 -0500 Received: (qmail invoked by alias); 07 Jan 2007 20:21:35 -0000 Received: from p54987301.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.115.1] by mail.gmx.net (mp047) with SMTP; 07 Jan 2007 21:21:35 +0100 X-Authenticated: #29516787 Message-ID: <45A1564D.7000200@gmx.net> Date: Sun, 07 Jan 2007 21:21:33 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" Subject: Re: [Ecrit] ATIS Liaison References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: Christian.Militeau@Intrado.com, ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Dan, Romascanu, Dan (Dan) wrote: > I do not know what are the rules of AIS, but it looks to me that sending > a document as an attachment to the list ends by having it available in > the archives, which is the same as a public website. > > In the case of other SDOs like the IEEE 802 we had in place agreements > where the work-in-progress documents from the IEEE were accessible on a > password-protected web site. The WG chair could send the username and > password to all WG members per request, but this information was not > circulated on the list. Maybe something similar can be put in place in > agreement with ATIS. > Sounds good to me. Christian, what do you think about the suggested approach? Ciao Hannes > Dan > > > > > > >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Saturday, January 06, 2007 9:45 PM >> To: 'Brian Rosen'; 'Hannes Tschofenig' >> Cc: Christian.Militeau@Intrado.com; 'ECRIT' >> Subject: RE: [Ecrit] ATIS Liaison >> >> Oops, wrong documents. ESMI/EISI was not sent to us, it was >> the location document. Sorry for the confusion. I guess we >> need a liaison to get them. >> >> You might want to think through what we can do with the docs >> if we get them. >> We can't put them on a public website can we? Do we have to >> email the doc as an attachment to the list? Ugh. >> >> Brian >> >> >>> -----Original Message----- >>> From: Brian Rosen [mailto:br@brianrosen.net] >>> Sent: Saturday, January 06, 2007 2:42 PM >>> To: Hannes Tschofenig >>> Cc: Christian.Militeau@Intrado.com; ECRIT >>> Subject: RE: [Ecrit] ATIS Liaison >>> >>> >>> >>> >>> Since the document was attached to the liaison, and >>> >> available on the >> >>> web at the indicated URL, what would we get if we did get a liaison >>> relationship established? They sent us the document. We can send >>> comment back through Christian or any of the numberous >>> >> ecrit members >> >>> who have access to ATIS contribution processes. >>> >>> I am NOT opposed to a liaison relationship with NGES, I'm >>> >> just trying >> >>> to avoid work. >>> >>> Brian >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Saturday, January 06, 2007 9:42 AM >>>> To: iab@ietf.org >>>> Cc: Christian.Militeau@Intrado.com; ECRIT >>>> Subject: [Ecrit] ATIS Liaison >>>> >>>> Dear IAB members, >>>> >>>> recently, ATIS released emergency service documents (ESMI >>>> >> and EISI >> >>>> standards, see attachment) and Christian Militeau (ATIS/ESIF TF34 >>>> Chair) kindly offered the possibility to make the mentioned ATIS >>>> documents available for the ECRIT working group. >>>> >>>> An official liaison letter to ATIS is need for this purpose. >>>> >>>> Do we have an active liaison to ATIS? If not, is there an >>>> >> easy and >> >>>> fast way to setup a liaison so that the ECRIT working group can >>>> review the documents? >>>> >>>> Ciao >>>> Hannes & Marc >>>> >>>> >>>> >>>> From: owner-atispr@lists.atis.org >>>> [mailto:owner-atispr@lists.atis.org] >>>> >>> On >>> >>>> Behalf Of ATIS >>>> Sent: Monday, December 04, 2006 12:11 PM >>>> Subject: ATIS PRESS RELEASE: ATIS Releases Suite of IP-based >>>> Emergency Services Standards >>>> >>>> ATIS Releases Suite of IP-based Emergency Services Standards >>>> December 4, 2006, Washington ? ATIS today announced the >>>> >> availability >> >>>> of its newly developed suite of IP-based Emergency >>>> >> Services Network >> >>> Interface >>> >>>> (ESNI) standards that will enable the expansion of E9-1-1 >>>> >> services >> >>>> and functionality within the Next Generation Network (NGN). >>>> The ESNI suite of standards includes an overall emergency >>>> >> services >> >>>> framework for the ESNI applications and protocols such as the >>>> Emergency Information Services Interface (EISI) that >>>> >> provide access >> >>>> to emergency services within or external to the Emergency >>>> >> Services Network (ESNet). >> >>> The >>> >>>> ESNI standards suite also includes the Emergency Services >>>> >> Messaging >> >>>> Interface (ESMI), released in September 2005, which >>>> >> provides managed >> >>>> interconnections between next generation public service answering >>>> points >>>> (PSAPs) and the ESNet. >>>> >>>> >>>> For more information, see the full release online at >>>> http://www.atis.org/PRESS/pressreleases2006/120406.htm. >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 07 15:32:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3egx-0003Y9-Nb; Sun, 07 Jan 2007 15:32:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3egw-0003Xt-GK for ecrit@ietf.org; Sun, 07 Jan 2007 15:32:30 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H3egr-0004UX-Eu for ecrit@ietf.org; Sun, 07 Jan 2007 15:32:30 -0500 Received: (qmail invoked by alias); 07 Jan 2007 20:32:24 -0000 Received: from p549849B6.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.73.182] by mail.gmx.net (mp045) with SMTP; 07 Jan 2007 21:32:24 +0100 X-Authenticated: #29516787 Message-ID: <45A158C6.6020608@gmx.net> Date: Sun, 07 Jan 2007 21:32:06 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: bernard_aboba@hotmail.com, ECRIT , bwijnen@alcatel-lucent.com Subject: [Ecrit] Re: IETF ECRIT and IEEE X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Dan, thanks for the quick response. Romascanu, Dan (Dan) wrote: > Hannes, > > It would be useful to be somehow more specific about the purpose of the > exchange of information that you want to entertain with the IEEE 802 > Working Groups. A few clarification questions: > > 1. What is the status of draft-ietf-ecrit-framework-00.txt? Is it > mature enough for a review by the IEEE or do you need more expert help > in filling in with content the link layer sections? > I think that we need help with both aspects - review and link layer parts. Let me ask the draft authors whether they feel confident with a review by the IEEE. Brian, Henning, Andy and James: Do you think that the document is mature enough? > 2. Do you have any reference about what was the level of information > exchange in the joint IETF ECRIT / 3GPP Emergency Services Workshop? > Sure. Please take a look at the documents and presentations available at: http://www.ietf-ecrit.org/3GPP-IETF-2006/ > Would not a short presentation from each of the IEEE WGs in the ECRIT > and GEOPRIV meetings accompanied by appropriate references be enough to > start with? This would already be sufficient. I do, however, think that the working group sessions are too short to have detailed discussions. That's what we learned from the joint IETF ECRIT / 3GPP emergency services workshop. We spent a couple of hours together on a Sunday afternoon before the IETF meeting started. > We can find probably folks attending both activities who > can rely this information, I can do it for 802.1 if needed. > That would be great. > Sending liaison letters from ECRIT to the IEEE WGs with specific > questions would be a good start. 802.11 will be meting in London the > week of 1/15, 802.1 meet in Monterey the week of 1/22. > We can compile a few questions to get a discussion started. > Also, http://www.ietf-ecrit.org/EmergencyWorkshop2006/ mentions the > following as IEEE 802 activities - 802.1, IA LLDP MED, 802.11k, 802.11u. > Note that LLDP MED is not a IEEE standard, but an extension of IEEE > 802.1AB standard (LLDP) which was authored the TIA TR41.4 Working Group. > > > In the meanwhile we know that LLDP MED is not an IEEE standard. Btw, I am not sure whether we captured all IEEE working groups that focus on emergency service aspects. Ciao Hannes > Dan > > > > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Saturday, January 06, 2007 4:59 PM >> To: bernard_aboba@hotmail.com; bwijnen@alcatel-lucent.com; >> Romascanu, Dan (Dan) >> Cc: ECRIT; Marc Linsner >> Subject: IETF ECRIT and IEEE >> >> Hi Bernard, Bert, Dan, >> >> at the last "SDO Emergency Services Coordination Workshop >> (ESW06)" (see >> http://www.ietf-ecrit.org/EmergencyWorkshop2006/) we noticed >> that the IEEE does a lot of work in the area of emergency services. >> >> Two suggestions were made: >> >> a) In the IETF ECRIT working group we are developing a >> framework document (see >> http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-framework/draf >> t-ietf-ecrit-framework-00.txt) >> >> and we believe that it is important to consider link layer >> aspects to capture the big picture of emergency services. >> Currently, our framework document does not adequately address >> this subject. We would appreciate a review and help. >> >> b) At the workshop we noticed that the details of the ongoing >> IEEE work in this space is not widely known. I wonder whether >> there is a chance to arrange a more detailed information >> exchange between the IETF ECRIT (potentially IETF GEOPRIV) >> working group and the respective groups within the IEEE. A >> workshop in the style of the joint IETF ECRIT / 3GPP >> Emergency Services Workshop might be useful. >> >> We would appreciate your help to arrange a closer cooperation >> between the IETF and the IEEE regarding this subject. >> >> Ciao >> Hannes & Marc >> >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 07 15:43:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3erd-00088x-E3; Sun, 07 Jan 2007 15:43:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3erc-00088r-Ee for ecrit@ietf.org; Sun, 07 Jan 2007 15:43:32 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3erX-0006QT-Sw for ecrit@ietf.org; Sun, 07 Jan 2007 15:43:32 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l07KhP0R014545 for ; Sun, 7 Jan 2007 15:43:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 7 Jan 2007 22:43:25 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF ECRIT and IEEE Thread-Index: Accym1VrDxiIz+4aQWik+R5wbTMGwQAAMGDw From: "Romascanu, Dan \(Dan\)" To: "Hannes Tschofenig" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: bernard_aboba@hotmail.com, ECRIT , bwijnen@alcatel-lucent.com Subject: [Ecrit] RE: IETF ECRIT and IEEE X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org =20 =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > > Would not a short presentation from each of the IEEE WGs in=20 > the ECRIT > > and GEOPRIV meetings accompanied by appropriate references=20 > be enough to > > start with? > This would already be sufficient. I do, however, think that=20 > the working=20 > group sessions are too short to have detailed discussions. > That's what we learned from the joint IETF ECRIT / 3GPP emergency=20 > services workshop. We spent a couple of hours together on a Sunday=20 > afternoon before the IETF meeting started. >=20 This can be finessed somehow. For example by having geopriv or ecrit ask for a second session in Prague which would have a dedicated agenda for this purpose.=20 Dan _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 07 16:30:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3fac-0001F9-3H; Sun, 07 Jan 2007 16:30:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3fab-0001F4-Lf for ecrit@ietf.org; Sun, 07 Jan 2007 16:30:01 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H3faa-0008Le-9K for ecrit@ietf.org; Sun, 07 Jan 2007 16:30:01 -0500 Received: (qmail invoked by alias); 07 Jan 2007 21:29:59 -0000 Received: from p549861DB.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.97.219] by mail.gmx.net (mp018) with SMTP; 07 Jan 2007 22:29:59 +0100 X-Authenticated: #29516787 Message-ID: <45A16655.30901@gmx.net> Date: Sun, 07 Jan 2007 22:29:57 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: bernard_aboba@hotmail.com, ECRIT , bwijnen@alcatel-lucent.com Subject: [Ecrit] Re: IETF ECRIT and IEEE X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Dan, > This can be finessed somehow. For example by having geopriv or ecrit ask > for a second session in Prague which would have a dedicated agenda for > this purpose. > > That's certainly a good idea. Two issues: a) I hope we can find enough IETF participants with a good IEEE background of the relevant groups. b) I also hope that we can find a few folks from the ECRIT and the GEOPRIV working group who are willing to speak at an upcomming IEEE meeting. This should ensure that the information exchange works in both directions. Ciao Hannes > Dan > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 07 16:59:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3g3M-0004Hf-D2; Sun, 07 Jan 2007 16:59:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3g3L-0004Ha-P9 for ecrit@ietf.org; Sun, 07 Jan 2007 16:59:43 -0500 Received: from smtp3.andrew.com ([198.17.217.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3g3K-0005zE-B8 for ecrit@ietf.org; Sun, 07 Jan 2007 16:59:43 -0500 X-SEF-Processed: 5_0_0_910__2007_01_07_16_04_28 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1 [10.3.20.66] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 07 Jan 2007 16:04:27 -0600 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 7 Jan 2007 15:59:39 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] RE: multipart Date: Sun, 7 Jan 2007 15:59:38 -0600 Message-ID: In-Reply-To: <478132E4-7873-45C0-9865-1EE70C5C3FAB@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RE: multipart Thread-Index: AccyhFIHbpaIQ6uJRLSevOnykvA5kwAIrYUA From: "Thomson, Martin" To: "Andrew Newton" , "Spencer Dawkins" X-OriginalArrivalTime: 07 Jan 2007 21:59:39.0460 (UTC) FILETIME=[20CD4840:01C732A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2104060013==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============2104060013== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C732A7.20A975E4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C732A7.20A975E4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXNu4oCZdCB0aGUgY2F1c2UgYSBjb21iaW5hdGlvbiBvZiBhIFNIT1VMRCBhbmQgdGhlIGZhY3Qg dGhhdCBpdCBoYXMgYmVlbiBlYXN5IHRvIGF2b2lkIG5lZWRpbmcgbXVsdGlwYXJ0IHVwIHVudGls IG5vdz8NCg0KIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpGcm9tOiBB bmRyZXcgTmV3dG9uIFttYWlsdG86YW5keUBoeHIudXNdIA0KU2VudDogTW9uZGF5LCA4IEphbnVh cnkgMjAwNyA0OjQ5IEFNDQpUbzogU3BlbmNlciBEYXdraW5zDQpDYzogJ0VDUklUJw0KU3ViamVj dDogUmU6IFtFY3JpdF0gUkU6IG11bHRpcGFydA0KDQogDQoNCiANCg0KT24gSmFuIDcsIDIwMDcs IGF0IDExOjQyIEFNLCBTcGVuY2VyIERhd2tpbnMgd3JvdGU6DQoNCg0KDQoNCg0KQXJlIHlvdSBz YXlpbmcgdGhhdCBzaW5jZSBpdCdzIG5vdCBleHBsaWNpdGx5IHNwZWNpZmllZCwgdGhhdCBzb21l IGltcGxlbWVudGF0aW9ucyBzdXBwb3J0IGl0IHdoaWxlIG90aGVycyBkb24ndD8NCg0KIA0KDQpJ IGRvbid0IGtub3cgd2hhdCB0aGUgY2F1c2UgYW5kIGVmZmVjdCBhcmUsIGJ1dCBpdCBpcyB0cnVl IHRoYXQgbWFueSBpbXBsZW1lbnRhdGlvbnMgZG8gbm90IHN1cHBvcnQgaXQuDQoNCiANCg0KQXMg dG8gdGhlIHNwZWMgYmVpbmcgdGhlIGNhdXNlLi4uIHdlbGwsIHRoZSBzcGVjIHNheXMgTVVTVCBm b3IgVExTIGFuZCB0aGVyZSBhcmUgc3RpbGwgYSBnb29kIG1hbnkgaW1wbGVtZW50YXRpb25zIHRo YXQgZG8gbm90IHN1cHBvcnQgdGhpcy4NCg0KIA0KDQotYW5keQ0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0 ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFy eSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2Vp dmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFu ZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1h aWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KW21mMl0NCg== ------_=_NextPart_001_01C732A7.20A975E4 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM9Imh0dHA6Ly93 d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KDQo8aGVhZD4NCg0KPG1ldGEgbmFtZT1HZW5lcmF0 b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTEgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT4NCjxzdHlsZT4NCnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9c Oioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVm YXVsdCNWTUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHls ZT4NCjwhW2VuZGlmXS0tPg0KPHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMTowIDExIDUg MCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnANCgl7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpzcGFuLkVtYWls U3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpB cmlhbDsNCgljb2xvcjptYXJvb247DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6 bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBw dDt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQoNCjwv aGVhZD4NCg0KPGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlIHN0eWxlPSd3 b3JkLXdyYXA6IGJyZWFrLXdvcmQ7DQota2h0bWwtbmJzcC1tb2RlOiBzcGFjZTsta2h0bWwtbGlu ZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2UnPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW1hcm9vbiBmYWNlPUFyaWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bWFy b29uJz5Jc27igJl0IHRoZSBjYXVzZSBhIGNvbWJpbmF0aW9uIG9mIGENClNIT1VMRCBhbmQgdGhl IGZhY3QgdGhhdCBpdCBoYXMgYmVlbiBlYXN5IHRvIGF2b2lkIG5lZWRpbmcgbXVsdGlwYXJ0IHVw IHVudGlsDQpub3c/PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1tYXJvb24gZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm1hcm9vbic+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz4N Cg0KPGRpdj4NCg0KPGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0 LWFsaWduOmNlbnRlcic+PGZvbnQgc2l6ZT0zDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz4NCg0KPGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgYWxp Z249Y2VudGVyIHRhYmluZGV4PS0xPg0KDQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PGI+PGZvbnQgc2l6ZT0yIGZhY2U9VGFob21hPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6VGFob21hO2ZvbnQtd2VpZ2h0OmJvbGQnPkZyb206 PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0yDQpmYWNlPVRhaG9tYT48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWEnPiBBbmRyZXcgTmV3dG9uDQpbbWFp bHRvOmFuZHlAaHhyLnVzXSA8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+ U2VudDo8L3NwYW4+PC9iPiBNb25kYXksIDggSmFudWFyeSAyMDA3IDQ6NDkNCkFNPGJyPg0KPGI+ PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlRvOjwvc3Bhbj48L2I+IFNwZW5jZXIgRGF3 a2luczxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5DYzo8L3NwYW4+PC9i PiAnRUNSSVQnPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlN1YmplY3Q6 PC9zcGFuPjwvYj4gUmU6IFtFY3JpdF0gUkU6IG11bHRpcGFydDwvc3Bhbj48L2ZvbnQ+PG86cD48 L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 DQoxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxkaXY+DQoN CjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz5PbiBKYW4gNywgMjAwNywg YXQgMTE6NDIgQU0sIFNwZW5jZXIgRGF3a2lucyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIHN0eWxlPSdtYXJnaW46 MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PGZvbnQgc2l6ZT0xIGZhY2U9SGVsdmV0aWNhPjxz cGFuDQpzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSc+QXJlIHlv dSBzYXlpbmcgdGhhdCBzaW5jZSBpdCdzDQpub3QgZXhwbGljaXRseSBzcGVjaWZpZWQsIHRoYXQg c29tZSBpbXBsZW1lbnRhdGlvbnMgc3VwcG9ydCBpdCB3aGlsZSBvdGhlcnMNCmRvbid0Pzwvc3Bh bj48L2ZvbnQ+PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPGRpdj4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPkkgZG9uJ3Qga25vdyB3aGF0IHRoZSBj YXVzZSBhbmQgZWZmZWN0IGFyZSwgYnV0IGl0IGlzIHRydWUgdGhhdCBtYW55DQppbXBsZW1lbnRh dGlvbnMgZG8gbm90IHN1cHBvcnQgaXQuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0K PC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPkFzIHRvIHRoZSBzcGVjIGJlaW5nIHRoZSBjYXVzZS4u LiB3ZWxsLCB0aGUgc3BlYyBzYXlzIE1VU1QgZm9yIFRMUyBhbmQNCnRoZXJlIGFyZSBzdGlsbCBh IGdvb2QgbWFueSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkbyBub3Qgc3VwcG9ydCB0aGlzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4N Cg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4tYW5k eTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9k aXY+DQoNCjxicj48YnI+PHRhYmxlIGJnY29sb3I9d2hpdGUgc3R5bGU9ImNvbG9yOmJsYWNrIj48 dHI+PHRkPjxicj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpU aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2lzJm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7ZGVzaWduYXRl ZCZuYnNwO3JlY2lwaWVudCZuYnNwO29ubHkmbmJzcDthbmQmbmJzcDttYXk8YnI+DQpjb250YWlu Jm5ic3A7cHJpdmlsZWdlZCwmbmJzcDtwcm9wcmlldGFyeSwmbmJzcDtvciZuYnNwO290aGVyd2lz ZSZuYnNwO3ByaXZhdGUmbmJzcDtpbmZvcm1hdGlvbi4mbmJzcDsmbmJzcDs8YnI+DQpJZiZuYnNw O3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO2l0Jm5ic3A7aW4mbmJzcDtlcnJvciwm bmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtzZW5kZXI8YnI+DQppbW1lZGlh dGVseSZuYnNwO2FuZCZuYnNwO2RlbGV0ZSZuYnNwO3RoZSZuYnNwO29yaWdpbmFsLiZuYnNwOyZu YnNwO0FueSZuYnNwO3VuYXV0aG9yaXplZCZuYnNwO3VzZSZuYnNwO29mPGJyPg0KdGhpcyZuYnNw O2VtYWlsJm5ic3A7aXMmbmJzcDtwcm9oaWJpdGVkLjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NClttZjJdPC90ZD48L3RyPjwvdGFibGU+PC9ib2R5Pg0K DQo8L2h0bWw+DQo= ------_=_NextPart_001_01C732A7.20A975E4-- --===============2104060013== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============2104060013==-- From ecrit-bounces@ietf.org Sun Jan 07 17:04:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3g7q-0006Sq-IX; Sun, 07 Jan 2007 17:04:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3g7p-0006Sk-8Z for ecrit@ietf.org; Sun, 07 Jan 2007 17:04:21 -0500 Received: from smtp3.andrew.com ([198.17.217.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3g7n-0006Rq-Ae for ecrit@ietf.org; Sun, 07 Jan 2007 17:04:20 -0500 X-SEF-Processed: 5_0_0_910__2007_01_07_16_09_06 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1 [10.3.20.66] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 07 Jan 2007 16:09:06 -0600 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 7 Jan 2007 16:04:17 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] RE: multipart Date: Sun, 7 Jan 2007 16:04:15 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RE: multipart Thread-Index: AccyhFIHbpaIQ6uJRLSevOnykvA5kwAIrYUAAAAb7xA= From: "Winterbottom, James" To: "Thomson, Martin" , "Andrew Newton" , "Spencer Dawkins" X-OriginalArrivalTime: 07 Jan 2007 22:04:17.0818 (UTC) FILETIME=[C6B757A0:01C732A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1867558400==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1867558400== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C732A7.C695D7BC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C732A7.C695D7BC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The fact that there any implementations that do not support multi-part,=0D=0A= make setting up a voice call AND including a location value perilous.=0D=0A=0D= =0AIt seems that location by reference may be the only sure bet.. *8)=0D=0A=0D= =0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A________________________________=0D=0A=0D=0A= From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]=20=0D=0ASent: Mond= ay, 8 January 2007 9:00 AM=0D=0ATo: Andrew Newton; Spencer Dawkins=0D=0ACc:= ECRIT=0D=0ASubject: RE: [Ecrit] RE: multipart=0D=0A=0D=0A=20=0D=0A=0D=0AIs= n't the cause a combination of a SHOULD and the fact that it has been=0D=0A= easy to avoid needing multipart up until now=3F=0D=0A=0D=0A=20=0D=0A=0D=0A_= _______________________________=0D=0A=0D=0AFrom: Andrew Newton [mailto:andy= @hxr.us]=20=0D=0ASent: Monday, 8 January 2007 4:49 AM=0D=0ATo: Spencer Dawk= ins=0D=0ACc: 'ECRIT'=0D=0ASubject: Re: [Ecrit] RE: multipart=0D=0A=0D=0A =0D= =0A=0D=0A=20=0D=0A=0D=0AOn Jan 7, 2007, at 11:42 AM, Spencer Dawkins wrote:=0D= =0A=0D=0A=20=0D=0A=0D=0AAre you saying that since it's not explicitly speci= fied, that some=0D=0Aimplementations support it while others don't=3F=0D=0A=0D= =0A=20=0D=0A=0D=0AI don't know what the cause and effect are, but it is tru= e that many=0D=0Aimplementations do not support it.=0D=0A=0D=0A=20=0D=0A=0D= =0AAs to the spec being the cause... well, the spec says MUST for TLS and=0D= =0Athere are still a good many implementations that do not support this.=0D= =0A=0D=0A=20=0D=0A=0D=0A-andy=0D=0A=0D=0A=20=0D=0A=0D=0A=0D=0A-------------= -----------------------------------------------------------=0D=0A----------= --------------=0D=0AThis message is for the designated recipient only and m= ay=0D=0Acontain privileged, proprietary, or otherwise private information. = =20=0D=0AIf you have received it in error, please notify the sender=0D=0Aim= mediately and delete the original. Any unauthorized use of=0D=0Athis email= is prohibited.=0D=0A------------------------------------------------------= ------------------=0D=0A------------------------=0D=0A[mf2]=0D=0A=0D=0A=20=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C732A7.C695D7BC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A

The fact that there any implementations that=0D=0Ado not support mul= ti-part, make setting up a voice call AND including a=0D=0Alocation value p= erilous.

=0D=0A=0D=0A

It seems that location by reference may be=0D=0A= the only sure bet.. *8)

=0D=0A=0D=0A

 =

=0D=0A=0D=0A

 

=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D= =0A
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A

From:=0D=0AThomson, Martin=0D= =0A[mailto:Martin.Thomson@andrew.com]
=0D=0ASent: Monday, 8 January 2007 9:00=0D=0AAM
=0D=0A<= span style=3D'font-weight:bold'>To: Andrew Newton; Spencer Dawki= ns
=0D=0ACc: ECRIT
=0D= =0ASubject: RE: [Ecrit] RE: = multipart

=0D=0A=0D= =0A
=0D=0A=0D=0A

 

=0D=0A=0D=0A

Isn’t the cause a=0D=0Acombination of a SHOULD and the f= act that it has been easy to avoid needing=0D=0Amultipart up until now=3F

=0D=0A=0D=0A

 

=0D=0A=0D= =0A
=0D=0A=0D=0A
=0D=0A=0D=0A
= =0D=0A=0D=0A
=0D=0A=0D=0A
=0D= =0A=0D=0A

F= rom:=0D=0AAndrew Newton [mailto:a= ndy@hxr.us]
=0D=0ASent: = Monday, 8 January 2007 4:49=0D=0AAM
=0D=0ATo: Spencer Dawkins
=0D=0ACc: 'ECRIT'
=0D=0A= Subject: Re: [Ecrit] RE: multipart

=0D=0A=0D=0A
=0D=0A=0D=0A

 

=0D=0A=0D=0A

 

=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A

On Jan= 7, 2007, at 11:42 AM, Spencer Dawkins wrote:

=0D= =0A=0D=0A
=0D=0A=0D=0A

 

=0D=0A=0D=0A

Are you say= ing that=0D=0Asince it's not explicitly specified, that some implementation= s support it while=0D=0Aothers don't=3F

=0D=0A=0D=0A
=0D=0A=0D=0A

 

=0D=0A=0D=0A
=0D=0A=0D=0A=

I don't know what the cause and effect= are, but it is=0D=0Atrue that many implementations do not support it.=

=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A

 

=0D=0A=0D=0A=
=0D=0A=0D=0A
=0D=0A=0D=0A

As = to the spec being the cause... well, the spec says=0D=0AMUST for TLS and th= ere are still a good many implementations that do not=0D=0Asupport this.

=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A 

=0D=0A=0D= =0A
=0D=0A=0D=0A
=0D=0A=0D=0A

= -andy

=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D= =0A

 

=0D=0A=0D=0A=0D= =0A =0D=0A =0D=0A =0D=0A
=0D=0A


=0D=0A -------------------= ---------------------------------------------------------------------------= --
=0D=0A This message is for the designated&n= bsp;recipient only and may
=0D=0A contain privilege= d, proprietary, or otherwise private information.&= nbsp; 
=0D=0A If you have received it in&= nbsp;error, please notify the sender
=0D=0A immedia= tely and delete the original.  Any unaut= horized use of
=0D=0A this email is prohibited= =2E
=0D=0A ------------------------------------------------------------= ------------------------------------
=0D=0A [mf2]

=0D=0A
=0D=0A=0D=0A

 

=0D=0A=0D=0A
=0D=0A=0D=0A=0D=0A=0D=0A


---------------------------------------------------------------------= ---------------------------
=0D=0AThis message is for&nbs= p;the designated recipient only and may
=0D=0Ac= ontain privileged, proprietary, or otherwise priva= te information.  
=0D=0AIf you have receiv= ed it in error, please notify the sender=
=0D=0Aimmediately and delete the original. &nb= sp;Any unauthorized use of
=0D=0Athis email is&= nbsp;prohibited.
=0D=0A-------------------------------------------------= -----------------------------------------------
=0D=0A[mf2]=0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01C732A7.C695D7BC-- --===============1867558400== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1867558400==-- From ecrit-bounces@ietf.org Mon Jan 08 01:54:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3oOY-0000nV-79; Mon, 08 Jan 2007 01:54:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3oOX-0000mW-04 for ecrit@ietf.org; Mon, 08 Jan 2007 01:54:09 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3oOV-00078f-PJ for ecrit@ietf.org; Mon, 08 Jan 2007 01:54:08 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l086s2uF016403 for ; Mon, 8 Jan 2007 01:54:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Jan 2007 08:54:02 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF ECRIT and IEEE Thread-Index: Accyo2bSanMq1dBTT+2p02dcAhTHMAASrGtA From: "Romascanu, Dan \(Dan\)" To: "Hannes Tschofenig" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: bernard_aboba@hotmail.com, ECRIT , bwijnen@alcatel-lucent.com Subject: [Ecrit] RE: IETF ECRIT and IEEE X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org =20 =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Sunday, January 07, 2007 11:30 PM > To: Romascanu, Dan (Dan) > Cc: bernard_aboba@hotmail.com; bwijnen@alcatel-lucent.com;=20 > ECRIT; Marc Linsner > Subject: Re: IETF ECRIT and IEEE >=20 > Hi Dan, >=20 > > This can be finessed somehow. For example by having geopriv=20 > or ecrit=20 > > ask for a second session in Prague which would have a=20 > dedicated agenda=20 > > for this purpose. > > > > =20 > That's certainly a good idea. >=20 > Two issues: >=20 > a) I hope we can find enough IETF participants with a good=20 > IEEE background of the relevant groups. >=20 Bert and me can represent IEEE 802.1. We need to coordinate this within the IEEE 802.1, we can discuss this at the interim meeting two weeks from now.=20 > b) I also hope that we can find a few folks from the ECRIT=20 > and the GEOPRIV working group who are willing to speak at an=20 > upcomming IEEE meeting. This should ensure that the=20 > information exchange works in both directions. IEEE 802 meets in Orlando in March the week before the IETF. It's a plenary meeting, and the right time for liaison letters to be officially sent and responded from the IEEE perspective.=20 Dan >=20 > Ciao > Hannes >=20 > > Dan > > =20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 08 09:21:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3vMp-0005ZE-Cs; Mon, 08 Jan 2007 09:20:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3vMn-0005Z9-Re for ecrit@ietf.org; Mon, 08 Jan 2007 09:20:49 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3vMm-0006l2-Hk for ecrit@ietf.org; Mon, 08 Jan 2007 09:20:49 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1H3vMZ-0007GG-Rl; Mon, 08 Jan 2007 08:20:36 -0600 From: "Brian Rosen" To: "'Romascanu, Dan \(Dan\)'" , "'Hannes Tschofenig'" Subject: RE: [Ecrit] RE: IETF ECRIT and IEEE Date: Mon, 8 Jan 2007 09:20:38 -0500 Message-ID: <070601c73330$2e568f60$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Accyo2bSanMq1dBTT+2p02dcAhTHMAASrGtAABBr05A= In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: bernard_aboba@hotmail.com, 'ECRIT' , bwijnen@alcatel-lucent.com X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I can probably go to this and present on both geopriv and ecrit. Brian > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Monday, January 08, 2007 1:54 AM > To: Hannes Tschofenig > Cc: bernard_aboba@hotmail.com; ECRIT; bwijnen@alcatel-lucent.com > Subject: [Ecrit] RE: IETF ECRIT and IEEE > > > > > > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Sunday, January 07, 2007 11:30 PM > > To: Romascanu, Dan (Dan) > > Cc: bernard_aboba@hotmail.com; bwijnen@alcatel-lucent.com; > > ECRIT; Marc Linsner > > Subject: Re: IETF ECRIT and IEEE > > > > Hi Dan, > > > > > This can be finessed somehow. For example by having geopriv > > or ecrit > > > ask for a second session in Prague which would have a > > dedicated agenda > > > for this purpose. > > > > > > > > That's certainly a good idea. > > > > Two issues: > > > > a) I hope we can find enough IETF participants with a good > > IEEE background of the relevant groups. > > > > Bert and me can represent IEEE 802.1. We need to coordinate this within > the IEEE 802.1, we can discuss this at the interim meeting two weeks > from now. > > > b) I also hope that we can find a few folks from the ECRIT > > and the GEOPRIV working group who are willing to speak at an > > upcomming IEEE meeting. This should ensure that the > > information exchange works in both directions. > > IEEE 802 meets in Orlando in March the week before the IETF. It's a > plenary meeting, and the right time for liaison letters to be officially > sent and responded from the IEEE perspective. > > Dan > > > > > > Ciao > > Hannes > > > > > Dan > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 08 19:40:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4528-0006TM-6d; Mon, 08 Jan 2007 19:40:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4527-0006TH-2b for ecrit@ietf.org; Mon, 08 Jan 2007 19:40:07 -0500 Received: from ns2.sccx.com ([209.108.197.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H451z-0003tw-Mi for ecrit@ietf.org; Mon, 08 Jan 2007 19:40:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] ATIS Liaison Date: Mon, 8 Jan 2007 17:34:08 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ATIS Liaison Thread-Index: AccyTlSvtNph1BkOSpOQvQ/6loxT7ABN0LqA From: "Militeau, Christian" To: "Hannes Tschofenig" , "Brian Rosen" X-OriginalArrivalTime: 09 Jan 2007 00:34:13.0683 (UTC) FILETIME=[E3152830:01C73385] X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes Yes it will be useful for the ATIS ESIF group to receive the comments. I will initiate a request to send the documents from ATIS to IETF so you don't have to worry about preparing a liaison on your hand. Best, Christian -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Sunday, January 07, 2007 4:24 AM To: Brian Rosen Cc: Militeau, Christian; 'ECRIT' Subject: Re: [Ecrit] ATIS Liaison Hi Brian, Brian Rosen wrote: > Oops, wrong documents. ESMI/EISI was not sent to us, it was the location > document. Sorry for the confusion. I guess we need a liaison to get them. > > You might want to think through what we can do with the docs if we get them. > =20 We also ask other SDOs, including ATIS, to review our documents and to=20 return feedback. Hence, we review their document and provide feedback. Christian, would=20 this be useful for the group within ATIS that produced the document? > We can't put them on a public website can we? Do we have to email the doc > as an attachment to the list? Ugh. > =20 If someone makes documents accessible to us then they are essentially=20 accessible for everyone. Ciao Hannes > Brian > > =20 >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Saturday, January 06, 2007 2:42 PM >> To: Hannes Tschofenig >> Cc: Christian.Militeau@Intrado.com; ECRIT >> Subject: RE: [Ecrit] ATIS Liaison >> >> >> >> >> Since the document was attached to the liaison, and available on the web >> at the indicated URL, what would we get if we did get a liaison >> relationship established? They sent us the document. We can send comment >> back through Christian or any of the numberous ecrit members who have >> access to ATIS contribution processes. >> >> I am NOT opposed to a liaison relationship with NGES, I'm just trying to >> avoid work. >> >> Brian >> =20 >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: Saturday, January 06, 2007 9:42 AM >>> To: iab@ietf.org >>> Cc: Christian.Militeau@Intrado.com; ECRIT >>> Subject: [Ecrit] ATIS Liaison >>> >>> Dear IAB members, >>> >>> recently, ATIS released emergency service documents (ESMI and EISI >>> standards, see attachment) and Christian Militeau (ATIS/ESIF TF34 Chair) >>> kindly offered the possibility to make the mentioned ATIS documents >>> available for the ECRIT working group. >>> >>> An official liaison letter to ATIS is need for this purpose. >>> >>> Do we have an active liaison to ATIS? If not, is there an easy and fast >>> way to setup a liaison so that the ECRIT working group can review the >>> documents? >>> >>> Ciao >>> Hannes & Marc >>> >>> >>> >>> From: owner-atispr@lists.atis.org [mailto:owner-atispr@lists.atis.org] >>> =20 >> On >> =20 >>> Behalf Of ATIS >>> Sent: Monday, December 04, 2006 12:11 PM >>> Subject: ATIS PRESS RELEASE: ATIS Releases Suite of IP-based Emergency >>> Services Standards >>> >>> ATIS Releases Suite of IP-based Emergency Services Standards >>> December 4, 2006, Washington ? ATIS today announced the availability of >>> its newly developed suite of IP-based Emergency Services Network >>> =20 >> Interface >> =20 >>> (ESNI) standards that will enable the expansion of E9-1-1 services and >>> functionality within the Next Generation Network (NGN). >>> The ESNI suite of standards includes an overall emergency services >>> framework for the ESNI applications and protocols such as the Emergency >>> Information Services Interface (EISI) that provide access to emergency >>> services within or external to the Emergency Services Network (ESNet). >>> =20 >> The >> =20 >>> ESNI standards suite also includes the Emergency Services Messaging >>> Interface (ESMI), released in September 2005, which provides managed >>> interconnections between next generation public service answering points >>> (PSAPs) and the ESNet. >>> >>> >>> For more information, see the full release online at >>> http://www.atis.org/PRESS/pressreleases2006/120406.htm. >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 08 19:46:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H458C-00016r-HL; Mon, 08 Jan 2007 19:46:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4589-00014f-Td for ecrit@ietf.org; Mon, 08 Jan 2007 19:46:21 -0500 Received: from ns2.sccx.com ([209.108.197.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H453w-0004XD-Hh for ecrit@ietf.org; Mon, 08 Jan 2007 19:42:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] ATIS Liaison Date: Mon, 8 Jan 2007 17:38:01 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ATIS Liaison Thread-Index: AccymXRAs90Eng+vRhKt41suuJyU9gA7IhdA From: "Militeau, Christian" To: "Hannes Tschofenig" , "Romascanu, Dan \(Dan\)" X-OriginalArrivalTime: 09 Jan 2007 00:40:07.0540 (UTC) FILETIME=[B5FF7340:01C73386] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This is fine. I will work with ATIS in order to provide "web links" like we did for the location protocols analysis that was sent to IETF last week. Thanks, Christian -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Sunday, January 07, 2007 1:22 PM To: Romascanu, Dan (Dan) Cc: Brian Rosen; Militeau, Christian; ECRIT Subject: Re: [Ecrit] ATIS Liaison Hi Dan, Romascanu, Dan (Dan) wrote: > I do not know what are the rules of AIS, but it looks to me that sending > a document as an attachment to the list ends by having it available in > the archives, which is the same as a public website.=20 > > In the case of other SDOs like the IEEE 802 we had in place agreements > where the work-in-progress documents from the IEEE were accessible on a > password-protected web site. The WG chair could send the username and > password to all WG members per request, but this information was not > circulated on the list. Maybe something similar can be put in place in > agreement with ATIS.=20 > =20 Sounds good to me. Christian, what do you think about the suggested approach? Ciao Hannes > Dan > > > =20 > =20 > > =20 >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net]=20 >> Sent: Saturday, January 06, 2007 9:45 PM >> To: 'Brian Rosen'; 'Hannes Tschofenig' >> Cc: Christian.Militeau@Intrado.com; 'ECRIT' >> Subject: RE: [Ecrit] ATIS Liaison >> >> Oops, wrong documents. ESMI/EISI was not sent to us, it was=20 >> the location document. Sorry for the confusion. I guess we=20 >> need a liaison to get them. >> >> You might want to think through what we can do with the docs=20 >> if we get them. >> We can't put them on a public website can we? Do we have to=20 >> email the doc as an attachment to the list? Ugh. >> >> Brian >> >> =20 >>> -----Original Message----- >>> From: Brian Rosen [mailto:br@brianrosen.net] >>> Sent: Saturday, January 06, 2007 2:42 PM >>> To: Hannes Tschofenig >>> Cc: Christian.Militeau@Intrado.com; ECRIT >>> Subject: RE: [Ecrit] ATIS Liaison >>> >>> >>> >>> >>> Since the document was attached to the liaison, and=20 >>> =20 >> available on the=20 >> =20 >>> web at the indicated URL, what would we get if we did get a liaison=20 >>> relationship established? They sent us the document. We can send=20 >>> comment back through Christian or any of the numberous=20 >>> =20 >> ecrit members=20 >> =20 >>> who have access to ATIS contribution processes. >>> >>> I am NOT opposed to a liaison relationship with NGES, I'm=20 >>> =20 >> just trying=20 >> =20 >>> to avoid work. >>> >>> Brian >>> =20 >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Saturday, January 06, 2007 9:42 AM >>>> To: iab@ietf.org >>>> Cc: Christian.Militeau@Intrado.com; ECRIT >>>> Subject: [Ecrit] ATIS Liaison >>>> >>>> Dear IAB members, >>>> >>>> recently, ATIS released emergency service documents (ESMI=20 >>>> =20 >> and EISI=20 >> =20 >>>> standards, see attachment) and Christian Militeau (ATIS/ESIF TF34=20 >>>> Chair) kindly offered the possibility to make the mentioned ATIS=20 >>>> documents available for the ECRIT working group. >>>> >>>> An official liaison letter to ATIS is need for this purpose. >>>> >>>> Do we have an active liaison to ATIS? If not, is there an=20 >>>> =20 >> easy and=20 >> =20 >>>> fast way to setup a liaison so that the ECRIT working group can=20 >>>> review the documents? >>>> >>>> Ciao >>>> Hannes & Marc >>>> >>>> >>>> >>>> From: owner-atispr@lists.atis.org=20 >>>> [mailto:owner-atispr@lists.atis.org] >>>> =20 >>> On >>> =20 >>>> Behalf Of ATIS >>>> Sent: Monday, December 04, 2006 12:11 PM >>>> Subject: ATIS PRESS RELEASE: ATIS Releases Suite of IP-based=20 >>>> Emergency Services Standards >>>> >>>> ATIS Releases Suite of IP-based Emergency Services Standards=20 >>>> December 4, 2006, Washington ? ATIS today announced the=20 >>>> =20 >> availability=20 >> =20 >>>> of its newly developed suite of IP-based Emergency=20 >>>> =20 >> Services Network >> =20 >>> Interface >>> =20 >>>> (ESNI) standards that will enable the expansion of E9-1-1=20 >>>> =20 >> services=20 >> =20 >>>> and functionality within the Next Generation Network (NGN). >>>> The ESNI suite of standards includes an overall emergency=20 >>>> =20 >> services=20 >> =20 >>>> framework for the ESNI applications and protocols such as the=20 >>>> Emergency Information Services Interface (EISI) that=20 >>>> =20 >> provide access=20 >> =20 >>>> to emergency services within or external to the Emergency=20 >>>> =20 >> Services Network (ESNet). >> =20 >>> The >>> =20 >>>> ESNI standards suite also includes the Emergency Services=20 >>>> =20 >> Messaging=20 >> =20 >>>> Interface (ESMI), released in September 2005, which=20 >>>> =20 >> provides managed=20 >> =20 >>>> interconnections between next generation public service answering=20 >>>> points >>>> (PSAPs) and the ESNet. >>>> >>>> >>>> For more information, see the full release online at=20 >>>> http://www.atis.org/PRESS/pressreleases2006/120406.htm. >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>> =20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 09 03:36:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4CSR-00061T-3K; Tue, 09 Jan 2007 03:35:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4CSP-0005zL-6I for ecrit@ietf.org; Tue, 09 Jan 2007 03:35:45 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4CSK-0006lr-HW for ecrit@ietf.org; Tue, 09 Jan 2007 03:35:45 -0500 Received: (qmail invoked by alias); 09 Jan 2007 08:35:39 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp040) with SMTP; 09 Jan 2007 09:35:39 +0100 X-Authenticated: #29516787 Message-ID: <45A353DA.8070501@gmx.net> Date: Tue, 09 Jan 2007 09:35:38 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: "Militeau, Christian" Subject: Re: [Ecrit] ATIS Liaison References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Christian, that's great. Thanks. Ciao Hannes Militeau, Christian wrote: > This is fine. I will work with ATIS in order to provide "web links" like > we did for the location protocols analysis that was sent to IETF last > week. > > Thanks, > Christian > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Sunday, January 07, 2007 1:22 PM > To: Romascanu, Dan (Dan) > Cc: Brian Rosen; Militeau, Christian; ECRIT > Subject: Re: [Ecrit] ATIS Liaison > > Hi Dan, > > Romascanu, Dan (Dan) wrote: > >> I do not know what are the rules of AIS, but it looks to me that >> > sending > >> a document as an attachment to the list ends by having it available in >> the archives, which is the same as a public website. >> >> In the case of other SDOs like the IEEE 802 we had in place agreements >> where the work-in-progress documents from the IEEE were accessible on >> > a > >> password-protected web site. The WG chair could send the username and >> password to all WG members per request, but this information was not >> circulated on the list. Maybe something similar can be put in place in >> agreement with ATIS. >> >> > > Sounds good to me. > > Christian, what do you think about the suggested approach? > > Ciao > Hannes > > >> Dan >> >> >> >> >> >> >> >>> -----Original Message----- >>> From: Brian Rosen [mailto:br@brianrosen.net] >>> Sent: Saturday, January 06, 2007 9:45 PM >>> To: 'Brian Rosen'; 'Hannes Tschofenig' >>> Cc: Christian.Militeau@Intrado.com; 'ECRIT' >>> Subject: RE: [Ecrit] ATIS Liaison >>> >>> Oops, wrong documents. ESMI/EISI was not sent to us, it was >>> the location document. Sorry for the confusion. I guess we >>> need a liaison to get them. >>> >>> You might want to think through what we can do with the docs >>> if we get them. >>> We can't put them on a public website can we? Do we have to >>> email the doc as an attachment to the list? Ugh. >>> >>> Brian >>> >>> >>> >>>> -----Original Message----- >>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>> Sent: Saturday, January 06, 2007 2:42 PM >>>> To: Hannes Tschofenig >>>> Cc: Christian.Militeau@Intrado.com; ECRIT >>>> Subject: RE: [Ecrit] ATIS Liaison >>>> >>>> >>>> >>>> >>>> Since the document was attached to the liaison, and >>>> >>>> >>> available on the >>> >>> >>>> web at the indicated URL, what would we get if we did get a liaison >>>> relationship established? They sent us the document. We can send >>>> comment back through Christian or any of the numberous >>>> >>>> >>> ecrit members >>> >>> >>>> who have access to ATIS contribution processes. >>>> >>>> I am NOT opposed to a liaison relationship with NGES, I'm >>>> >>>> >>> just trying >>> >>> >>>> to avoid work. >>>> >>>> Brian >>>> >>>> >>>>> -----Original Message----- >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>> Sent: Saturday, January 06, 2007 9:42 AM >>>>> To: iab@ietf.org >>>>> Cc: Christian.Militeau@Intrado.com; ECRIT >>>>> Subject: [Ecrit] ATIS Liaison >>>>> >>>>> Dear IAB members, >>>>> >>>>> recently, ATIS released emergency service documents (ESMI >>>>> >>>>> >>> and EISI >>> >>> >>>>> standards, see attachment) and Christian Militeau (ATIS/ESIF TF34 >>>>> Chair) kindly offered the possibility to make the mentioned ATIS >>>>> documents available for the ECRIT working group. >>>>> >>>>> An official liaison letter to ATIS is need for this purpose. >>>>> >>>>> Do we have an active liaison to ATIS? If not, is there an >>>>> >>>>> >>> easy and >>> >>> >>>>> fast way to setup a liaison so that the ECRIT working group can >>>>> review the documents? >>>>> >>>>> Ciao >>>>> Hannes & Marc >>>>> >>>>> >>>>> >>>>> From: owner-atispr@lists.atis.org >>>>> [mailto:owner-atispr@lists.atis.org] >>>>> >>>>> >>>> On >>>> >>>> >>>>> Behalf Of ATIS >>>>> Sent: Monday, December 04, 2006 12:11 PM >>>>> Subject: ATIS PRESS RELEASE: ATIS Releases Suite of IP-based >>>>> Emergency Services Standards >>>>> >>>>> ATIS Releases Suite of IP-based Emergency Services Standards >>>>> December 4, 2006, Washington ? ATIS today announced the >>>>> >>>>> >>> availability >>> >>> >>>>> of its newly developed suite of IP-based Emergency >>>>> >>>>> >>> Services Network >>> >>> >>>> Interface >>>> >>>> >>>>> (ESNI) standards that will enable the expansion of E9-1-1 >>>>> >>>>> >>> services >>> >>> >>>>> and functionality within the Next Generation Network (NGN). >>>>> The ESNI suite of standards includes an overall emergency >>>>> >>>>> >>> services >>> >>> >>>>> framework for the ESNI applications and protocols such as the >>>>> Emergency Information Services Interface (EISI) that >>>>> >>>>> >>> provide access >>> >>> >>>>> to emergency services within or external to the Emergency >>>>> >>>>> >>> Services Network (ESNet). >>> >>> >>>> The >>>> >>>> >>>>> ESNI standards suite also includes the Emergency Services >>>>> >>>>> >>> Messaging >>> >>> >>>>> Interface (ESMI), released in September 2005, which >>>>> >>>>> >>> provides managed >>> >>> >>>>> interconnections between next generation public service answering >>>>> points >>>>> (PSAPs) and the ESNet. >>>>> >>>>> >>>>> For more information, see the full release online at >>>>> http://www.atis.org/PRESS/pressreleases2006/120406.htm. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >>> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 10 08:34:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4daf-0004l0-0L; Wed, 10 Jan 2007 08:34:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4dae-0004kp-4U for ecrit@ietf.org; Wed, 10 Jan 2007 08:34:04 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4daX-0000UH-1g for ecrit@ietf.org; Wed, 10 Jan 2007 08:34:04 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 10 Jan 2007 05:33:56 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l0ADXuSk010979; Wed, 10 Jan 2007 05:33:56 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0ADXjld005998; Wed, 10 Jan 2007 05:33:54 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 08:33:44 -0500 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 08:33:43 -0500 From: "Marc Linsner" To: "'Winterbottom, James'" Subject: RE: [Ecrit] RE: multipart Date: Wed, 10 Jan 2007 08:33:43 -0500 Message-ID: <007b01c734bb$f2fdb370$200d0d0a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AccyhFIHbpaIQ6uJRLSevOnykvA5kwAIrYUAAAAb7xAAhQl/oA== In-Reply-To: X-OriginalArrivalTime: 10 Jan 2007 13:33:44.0473 (UTC) FILETIME=[F30F1890:01C734BB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4748; t=1168436036; x=1169300036; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20RE=3A=20multipart |Sender:=20; bh=bfgM8UH8plRpUHw4d+uC2tUpq8IaigdVVbwO+eBbp9c=; b=QV/SMtiug7ZJP+kbZ5PqMpspodZX+peUlYLTB15e6xw6AXEnU/3O6qtZNBzAIaIIoc1KwcsW 7VVfaHX+/dpun0DqGBgJB5fyLabAdsJR1ZiFokHqB5S+D0jJFvradJpo; Authentication-Results: sj-dkim-6; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0541159930==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0541159930== Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01C73492.0A27AB70" This is a multi-part message in MIME format. ------=_NextPart_000_007C_01C73492.0A27AB70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The fact that there any implementations that do not support multi-part, make setting up a voice call AND including a location value perilous. It seems that location by reference may be the only sure bet.. *8) Absolutely! All those proxies that don't support multipart are certain to support the yet-to-be-defined location conveyance headers! -Marc- ------=_NextPart_000_007C_01C73492.0A27AB70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 

The fact = that there=20 any implementations that do not support multi-part, make setting up a = voice=20 call AND including a location value = perilous.

It seems = that=20 location by reference may be the only sure bet..=20 *8)

 

 

Absolutely!  All those proxies that = don't support=20 multipart are certain to support the yet-to-be-defined location = conveyance=20 headers!

 

-Marc-

------=_NextPart_000_007C_01C73492.0A27AB70-- --===============0541159930== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0541159930==-- From ecrit-bounces@ietf.org Wed Jan 10 08:51:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4drU-0004K7-KO; Wed, 10 Jan 2007 08:51:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4drT-0004K2-EJ for ecrit@ietf.org; Wed, 10 Jan 2007 08:51:27 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4drD-0002zE-AW for ecrit@ietf.org; Wed, 10 Jan 2007 08:51:27 -0500 Received: (qmail invoked by alias); 10 Jan 2007 13:51:09 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp044) with SMTP; 10 Jan 2007 14:51:09 +0100 X-Authenticated: #29516787 Message-ID: <45A4EF4C.6000409@gmx.net> Date: Wed, 10 Jan 2007 14:51:08 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: "Nennker, Axel" Subject: [Ecrit] Review of the ECRIT Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, Axel Nennker has done a review of draft-ietf-ecrit-framework-00.txt and he also suggests text! Here is his review: http://www.ietf-ecrit.org/TEMP/draft-ietf-ecrit-framework-00-nennker.doc Thank you Axel for your work. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 10 09:42:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4eeY-0001w4-3j; Wed, 10 Jan 2007 09:42:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4eeW-0001vz-Lj for ecrit@ietf.org; Wed, 10 Jan 2007 09:42:08 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4eeU-0001Lv-Al for ecrit@ietf.org; Wed, 10 Jan 2007 09:42:08 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l0AEfsVd003756; Wed, 10 Jan 2007 08:41:54 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 08:41:54 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 15:41:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] RE: multipart Date: Wed, 10 Jan 2007 15:41:51 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180AB0897@DEEXC1U01.de.lucent.com> In-Reply-To: <007b01c734bb$f2fdb370$200d0d0a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RE: multipart thread-index: AccyhFIHbpaIQ6uJRLSevOnykvA5kwAIrYUAAAAb7xAAhQl/oAACR8oQ From: "Drage, Keith \(Keith\)" To: "Marc Linsner" , "Winterbottom, James" X-OriginalArrivalTime: 10 Jan 2007 14:41:52.0389 (UTC) FILETIME=[77A59350:01C734C5] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org As far as location-conveyance is concerned, the situation is exactly the same as for bodies as for headers. The default handling rules at a proxy are to pass on, unchanged, headers and bodies that are not understood. I assume that any proxies that need to provide functionality based on location, e.g. special routeing or dereferencing of a location by reference, would be required to support location-conveyance functionality. With regard to the support of multipart, I think that is well understood in the SIP WG that needs to be a mandatory part of SIP and we need to address some text somewhere to cover it. We can not of course cover those implementations that refuse to conform to the specifications (for example those that do not implement TCP or TLS). Regards Keith ________________________________ From: Marc Linsner [mailto:mlinsner@cisco.com]=20 Sent: 10 January 2007 13:34 To: 'Winterbottom, James' Cc: 'ECRIT' Subject: RE: [Ecrit] RE: multipart =09 =09 =20 The fact that there any implementations that do not support multi-part, make setting up a voice call AND including a location value perilous. It seems that location by reference may be the only sure bet.. *8) =20 =20 Absolutely! All those proxies that don't support multipart are certain to support the yet-to-be-defined location conveyance headers! =20 -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 10 10:14:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4f9h-0007ZU-Jq; Wed, 10 Jan 2007 10:14:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4f9g-0007Z9-4M for ecrit@ietf.org; Wed, 10 Jan 2007 10:14:20 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4f9e-0005iB-SQ for ecrit@ietf.org; Wed, 10 Jan 2007 10:14:20 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Jan 2007 07:14:19 -0800 X-IronPort-AV: i="4.13,168,1167638400"; d="scan'208"; a="50433572:sNHT46534976" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0AFEIRx025678; Wed, 10 Jan 2007 10:14:18 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0AFEE7j000846; Wed, 10 Jan 2007 10:14:19 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 10:14:15 -0500 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 10:14:14 -0500 From: "Marc Linsner" To: "'Drage, Keith \(Keith\)'" , "'Winterbottom, James'" Subject: RE: [Ecrit] RE: multipart Date: Wed, 10 Jan 2007 10:14:13 -0500 Message-ID: <00a501c734c9$fd6b5890$200d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AccyhFIHbpaIQ6uJRLSevOnykvA5kwAIrYUAAAAb7xAAhQl/oAACR8oQAAFF49A= In-Reply-To: <5D1A7985295922448D5550C94DE29180AB0897@DEEXC1U01.de.lucent.com> X-OriginalArrivalTime: 10 Jan 2007 15:14:14.0977 (UTC) FILETIME=[FD84FB10:01C734C9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1815; t=1168442058; x=1169306058; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20RE=3A=20multipart |Sender:=20 |To:=20=22'Drage, =20Keith=20\(Keith\)'=22=20, =0 A=20=20=20=20=20=20=20=20=22'Winterbottom, =20James'=22=20; bh=GtxBw6ThUlbPZxFHOfgXsDVuOX3hWLy/4ScXWrJF7AA=; b=moQIvcmeNrtLq/zsR7RJDNkEhYjd7RDtbMHzIHnSSgFU0OuCBXVQ61WARzfHhrsydbicN48+ Qpi1D9EBuU+lqBJdRvztPGwh4Wee+U09Djmt65LuLm9dGthkBHzFkcQS; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Keith, I agree with everything you said. -Marc- > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Wednesday, January 10, 2007 9:42 AM > To: Marc Linsner; Winterbottom, James > Cc: ECRIT > Subject: RE: [Ecrit] RE: multipart > > As far as location-conveyance is concerned, the situation is > exactly the same as for bodies as for headers. > > The default handling rules at a proxy are to pass on, > unchanged, headers and bodies that are not understood. > > I assume that any proxies that need to provide functionality > based on location, e.g. special routeing or dereferencing of > a location by reference, would be required to support > location-conveyance functionality. > > With regard to the support of multipart, I think that is well > understood in the SIP WG that needs to be a mandatory part of > SIP and we need to address some text somewhere to cover it. > We can not of course cover those implementations that refuse > to conform to the specifications (for example those that do > not implement TCP or TLS). > > Regards > > Keith > > > ________________________________ > > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: 10 January 2007 13:34 > To: 'Winterbottom, James' > Cc: 'ECRIT' > Subject: RE: [Ecrit] RE: multipart > > > > > The fact that there any implementations that do > not support multi-part, make setting up a voice call AND > including a location value perilous. > > It seems that location by reference may be the > only sure bet.. *8) > > > > > > Absolutely! All those proxies that don't support > multipart are certain to support the yet-to-be-defined > location conveyance headers! > > > > -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 10 10:21:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fG6-00035L-EJ; Wed, 10 Jan 2007 10:20:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fG5-00035D-1O for ecrit@ietf.org; Wed, 10 Jan 2007 10:20:57 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4fG2-0006Vt-Ky for ecrit@ietf.org; Wed, 10 Jan 2007 10:20:57 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1H4fFw-0005dj-IO; Wed, 10 Jan 2007 09:20:49 -0600 From: "Brian Rosen" To: "'Drage, Keith \(Keith\)'" , "'Marc Linsner'" , "'Winterbottom, James'" Subject: RE: [Ecrit] RE: multipart Date: Wed, 10 Jan 2007 10:20:48 -0500 Message-ID: <0c4001c734ca$ead5d970$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AccyhFIHbpaIQ6uJRLSevOnykvA5kwAIrYUAAAAb7xAAhQl/oAACR8oQAAGB1wA= In-Reply-To: <5D1A7985295922448D5550C94DE29180AB0897@DEEXC1U01.de.lucent.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Just for completeness, you need multipart to support S/MIME, also a mandatory to implement part of sip. Brian > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Wednesday, January 10, 2007 9:42 AM > To: Marc Linsner; Winterbottom, James > Cc: ECRIT > Subject: RE: [Ecrit] RE: multipart > > As far as location-conveyance is concerned, the situation is exactly the > same as for bodies as for headers. > > The default handling rules at a proxy are to pass on, unchanged, headers > and bodies that are not understood. > > I assume that any proxies that need to provide functionality based on > location, e.g. special routeing or dereferencing of a location by > reference, would be required to support location-conveyance > functionality. > > With regard to the support of multipart, I think that is well understood > in the SIP WG that needs to be a mandatory part of SIP and we need to > address some text somewhere to cover it. We can not of course cover > those implementations that refuse to conform to the specifications (for > example those that do not implement TCP or TLS). > > Regards > > Keith > > > ________________________________ > > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: 10 January 2007 13:34 > To: 'Winterbottom, James' > Cc: 'ECRIT' > Subject: RE: [Ecrit] RE: multipart > > > > > The fact that there any implementations that do not > support multi-part, make setting up a voice call AND including a > location value perilous. > > It seems that location by reference may be the only sure > bet.. *8) > > > > > > Absolutely! All those proxies that don't support multipart are > certain to support the yet-to-be-defined location conveyance headers! > > > > -Marc- > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 10 14:51:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4jU8-0002gR-IJ; Wed, 10 Jan 2007 14:51:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4jU7-0002gM-Oe for ecrit@ietf.org; Wed, 10 Jan 2007 14:51:43 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4jU3-0007lg-8a for ecrit@ietf.org; Wed, 10 Jan 2007 14:51:43 -0500 Received: (qmail invoked by alias); 10 Jan 2007 19:51:37 -0000 Received: from p54986061.dip.t-dialin.net (EHLO [192.168.178.10]) [84.152.96.97] by mail.gmx.net (mp003) with SMTP; 10 Jan 2007 20:51:37 +0100 X-Authenticated: #29516787 Message-ID: <45A543C7.5000809@gmx.net> Date: Wed, 10 Jan 2007 20:51:35 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [Ecrit] WG Status Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, I think we did a lot of work in the past few months to finish our documents as initially planned. Still, it takes a bit longer. Here are recent activities we would like to mention: * Reviews ----------- To improve the quality of the documents we need more feedback and require more discussion input. We have reached a state in the life cycle of our working group where the work focuses on details that require more thoughts (and more time). Hence, it might appear that it is not always easy to provide feedback. Just try it - don't be reluctant. We have triggered reviews from different sources: inside the IETF and outside. At the last IETF meeting we have selected a few expert reviewers. Many reviews are still pending. We have also sent requests for reviews to VoIP providers. We hope to see some responses soon. With respect to some architectural issues we are also hoping to get input from the IEEE. We are therefore planning to organize an information sharing event with them. Here is the plan: We are going to request a longer ECRIT (and potentially GEOPRIV) working group slot at the next IETF meeting to have time for presentations by IEEE members. A few ECRIT WG members will attend one of the next IEEE meetings. We might also need to trigger Keith to organize another phone conference call to discuss further details between the 3GPP and TISPAN. * SDO Emergency Services Coordination Workshop ----------------------------------------------------- We have started with the organization of the next workshop. The program chairs are Hannu Hietalahti (3GPP), Harry Worstell, Stephen McCann (IEEE), Christian Militeau (ATIS/ESIF), Jenny Hansen (US DOT), Henning Schulzrinne, Marc Linsner, and myself. Details are obviously still in progress. We will keep you informed as we make progress. * IAB Involvement ------------------- We are trying to interact with the IAB to make them aware of the architectural aspects and the challenges of our work. We are convinced that the IAB is a good source for feedback. Thanks to Bernhard and Dan for helping us to get something arranged. For more information regarding the current working group status take a look at: http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/IetfEcritRoadMap Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 11 10:58:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52Jq-0000hv-LH; Thu, 11 Jan 2007 10:58:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52Jq-0000hp-5c for ecrit@ietf.org; Thu, 11 Jan 2007 10:58:22 -0500 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H52Jk-0004Mn-3r for ecrit@ietf.org; Thu, 11 Jan 2007 10:58:22 -0500 Received: from ([139.76.131.91]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.169157264; Thu, 11 Jan 2007 10:57:52 -0500 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 11 Jan 2007 10:57:52 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 11 Jan 2007 10:57:53 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 11 Jan 2007 10:57:52 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA2B535F@crexc41p> X-MS-Has-Attach: Priority: normal Importance: normal X-MS-TNEF-Correlator: Thread-Topic: Comments on [draft-ietf-ecrit-framework-00.txt] Thread-Index: Acc1mWegHbAYW4oZR5CanKpFGjpNIw== From: "Stark, Barbara" To: "ECRIT" X-OriginalArrivalTime: 11 Jan 2007 15:57:53.0113 (UTC) FILETIME=[40769490:01C73599] X-Spam-Score: 0.7 (/) X-Scan-Signature: 1a2f5df4c6f30e0d5df43748fb095119 Subject: [Ecrit] Comments on [draft-ietf-ecrit-framework-00.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1914972457==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1914972457== Content-class: urn:content-classes:message Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73599.40374B9E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73599.40374B9E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I reviewed this document from the perspective of an employee of a major = service provider. Nonetheless, these opinions are mine, as an = individual. I think the overall framework here is reasonable and do-able, and I = support this effort. I also understand that this document is incomplete = and not ready for publication, and it will continue to be improved upon. As a general comment, I had to review phonebcp in conjunction with this = framework, because there are so many references to it. I realize = phonebcp isn't an ecrit document, but I would recommend it be included = on the service provider review page. It's highly integral to = understanding the overall architecture. Specific comments: ------------------------------ The definition of ESRP in ecrit requirements seems different than the = definition of ESRP in the NENA i3 Functional and Interface Standards. = The ecrit requirements and the usage of the term in "framework" seem to = suggest that the ESRP could be in the VSP (voice provider) network, = since proxies in the VSP network may also do LoST queries. It's not = clear that the ESRP expects to get a different LoST response than the = endpoint. The NENA doc says that the ESRP is an entry point to a group = of PSAPs, and implies that it is the thing that gets routed to by the = uri returned by the SIP device's LoST query. Is there something we can = do so ESRP means the same thing in both places? I think the NENA usage = is what's intended, and the query for routing info done by the ESRP = returns different and more detailed routing info than the one done by = the SIP end device. The SIP device LoST query leads to the ESRP, and the = ESRP query leads to the PSAP. It's also possible for the VSP proxy to do = LoST queries, but that doesn't make it an ESRP. A VSP proxy's LoST query = would return the same uri as the SIP device's query. ecrit requirements:=20 Emergency Service Routing Proxy (ESRP): An ESRP is an emergency call = routing support entity that invokes the location-to-PSAP URI mapping, to = return either the URI for the appropriate PSAP, or the URI for another = ESRP. (In a SIP system, the ESRP would typically be a SIP proxy, but may = also be a back-to-back user agent (B2BUA)).=20 NENA:=20 Emergency Services Routing Proxy (ESRP) - This ESRP is a routing proxy = that acts on behalf of a group of PSAPs, to provide intermediate or = final routing to the PSAP, based on the caller's location. This function = is not identified explicitly in the i3 functional architecture, but has = been discussed in industry presentations and the concept is included in = Framework for Emergency Calling in Internet Multimedia = = [3]. The ESRP function is included in the example physical architecture. Section 2, 3rd full paragraph on Page 6 The term "master-slave" is considered politically incorrect by many = governmental bodies in the US. I recommend using other terms to describe = these protocols. Section 3, Figure 1 Needs descriptive text. What do the numbers mean? Boxes also need = definition, although they're defined in the Figure 2 description. This = is all just editorial, though.=20 Bullet 2 (of Figure 2 description) What is meant by "local domain"? I usually consider my "local domain" to = be the domain of my home router, or the domain of my ISP (if my router = has no domain). But SIP registration uses a SIP domain, which I don't = see as overly "local", since the registration server could be 1000 miles = away, or more. Could this maybe be worded something like "...for = Alice's UA to register with. Most SIP UAs will register with a server, = so it will be a common scenario for UAs that make emergency calls to be = registered with a server." Bullet 3 [editorial]: change "initiated" to "initiates" Paragraph after the bullets "...UA ... has location configured within her UA when her UA boots..." = Is this meant to describe the case where the UA gets location = configuration as part of its boot process, such as DHCP or L7 CP? Or = does it imply a statically stored location which the UA finds and uses = during its boot process? This wasn't clear to me. In general, I think = there are 3 basic ways the UA could be configured: (1) a saved manually = entered location, (2) location manually entered after it boots, (3) = receives a location from the network. The location from the network = could be a measured location, or it could be based on knowing the = physical locations of network termination points. This sentence doesn't = convey that to me. Next paragraph, that starts with "Some time..." [Editorial]: change "initiated" to "initiates" Section 6.3 2nd paragraph: "XRef" should probably be [phonebcp]? If it is, then the = 3rd to last sentence and the last sentence would be redundant. Note that = these guidelines for dealing with multiple locations are not in phonebcp = at this time. I'll make this comment against phonebcp. 3rd paragraph [editorial] end of the paragraph "...and ask the caller with." doesn't = make sense. Section 5.4 [editorial] 2 instances where "can" needs to be "can be" Section 5.8 I recommend changing "...to ensure that phone billing records correspond = to valid..." to "...to ensure that the service addresses in phone billing records = correspond to valid..." Section 5.9 What is CMTS? Naturally, "(how?)" needs to be resolved. Section 6 Paragraph at the end of page 20.=20 I had questions here as to whether this VSP proxy would be an ESRP, = based on the ecrit requirements definition and the usage of that term in = this document. I'm hoping it would not be an ESRP. Section 7 I'm not sure how practical persistent TLS connection are for large VSPs, = given that they may have to connect to thousands of PSAPs. Section 9 Recommend several references to phonebcp in this section, since phonebcp = specifically discusses where these IDs are placed in the SIP message. Section 11 I would slightly expand this section to also mention the disabling of = calling features. For example, change the header and add a sentence like = "The disabling of other call features, such as call waiting, is also = discussed in phonebcp. Barbara Stark BellSouth Science & Technology (a recently acquired part of AT&T) ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA624 ------_=_NextPart_001_01C73599.40374B9E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on [draft-ietf-ecrit-framework-00.txt]

I reviewed this document from the = perspective of an employee of a major service provider. Nonetheless, = these opinions are mine, as an individual.

I think the overall framework here is = reasonable and do-able, and I support this effort. I also understand = that this document is incomplete and not ready for publication, and it = will continue to be improved upon.

As a general comment, I had to review = phonebcp in conjunction with this framework, because there are so many = references to it. I realize phonebcp isn't an ecrit document, but I = would recommend it be included on the service provider review page. It's = highly integral to understanding the overall architecture.

Specific comments:
------------------------------
The definition of ESRP in ecrit = requirements seems different than the definition of ESRP in the NENA i3 = Functional and Interface Standards. The ecrit requirements and the usage = of the term in "framework" seem to suggest that the ESRP could = be in the VSP (voice provider) network, since proxies in the VSP network = may also do LoST queries. It's not clear that the ESRP expects to get a = different LoST response than the endpoint. The NENA doc says that the = ESRP is an entry point to a group of PSAPs, and implies that it is the = thing that gets routed to by the uri returned by the SIP device's LoST = query. Is there something we can do so ESRP means the same thing in both = places? I think the NENA usage is what's intended, and the query for = routing info done by the ESRP returns different and more detailed = routing info than the one done by the SIP end device. The SIP device = LoST query leads to the ESRP, and the ESRP query leads to the PSAP. It's = also possible for the VSP proxy to do LoST queries, but that doesn't = make it an ESRP. A VSP proxy's LoST query would return the same uri as = the SIP device's query.

ecrit requirements:
Emergency Service Routing Proxy (ESRP): An ESRP is an emergency call = routing support entity that invokes the location-to-PSAP URI mapping, to = return either the URI for the appropriate PSAP, or the URI for another = ESRP. (In a SIP system, the ESRP would typically be a SIP proxy, but may = also be a back-to-back user agent (B2BUA)).

NENA:
Emergency Services Routing Proxy (ESRP) - This ESRP is a routing proxy = that acts on behalf of a group of PSAPs, to provide intermediate or = final routing to the PSAP, based on the caller’s location. This = function is not identified explicitly in the i3 functional architecture, = but has been discussed in industry presentations and the concept is = included in Framework for Emergency Calling in Internet Multimedia <http://www.ietf.org/internet-drafts/draft-rosen-ecrit-framework-00= .txt> [3]. The ESRP = function is included in the example physical architecture.

Section 2, 3rd full paragraph on Page = 6
The term "master-slave" is = considered politically incorrect by many governmental bodies in the US. = I recommend using other terms to describe these protocols.

Section 3, Figure 1
Needs descriptive text. What do the = numbers mean? Boxes also need definition, although they're defined in = the Figure 2 description. This is all just editorial, though. =

Bullet 2 (of Figure 2 = description)
What is meant by "local = domain"? I usually consider my "local domain" to be the = domain of my home router, or the domain of my ISP (if my router has no = domain). But SIP registration uses a SIP domain, which I don't see as = overly "local", since the registration server could be 1000 = miles away, or more. Could this maybe be worded something like  = "...for Alice's UA to register with. Most SIP UAs will register = with a server, so it will be a common scenario for UAs that make = emergency calls to be registered with a server."

Bullet 3 [editorial]: change = "initiated" to "initiates"

Paragraph after the bullets
"...UA ... has location = configured within her UA when her UA boots..." Is this meant to = describe the case where the UA gets location configuration as part of = its boot process, such as DHCP or L7 CP? Or does it imply a statically = stored location which the UA finds and uses during its boot process? = This wasn't clear to me. In general, I think there are 3 basic ways the = UA could be configured: (1) a saved manually entered location, (2) = location manually entered after it boots, (3) receives a location from = the network. The location from the network could be a measured location, = or it could be based on knowing the physical locations of network = termination points. This sentence doesn't convey that to me.

Next paragraph, that starts with = "Some time..."
[Editorial]: change = "initiated" to "initiates"

Section 6.3
2nd paragraph: "XRef" should = probably be [phonebcp]? If it is, then the 3rd to last sentence and the = last sentence would be redundant. Note that these guidelines for dealing = with multiple locations are not in phonebcp at this time. I'll make this = comment against phonebcp.

3rd paragraph
[editorial] end of the paragraph = "...and ask the caller with." doesn't make sense.

Section 5.4
[editorial] 2 instances where = "can" needs to be "can be"

Section 5.8
I recommend changing "...to = ensure that phone billing records correspond to valid..." to
"...to ensure that the service = addresses in phone billing records correspond to valid..."

Section 5.9
What is CMTS?
Naturally, "(how?)" needs to = be resolved.

Section 6
Paragraph at the end of page 20. =
I had questions here as to whether = this VSP proxy would be an ESRP, based on the ecrit requirements = definition and the usage of that term in this document. I'm hoping it = would not be an ESRP.

Section 7
I'm not sure how practical persistent = TLS connection are for large VSPs, given that they may have to connect = to thousands of PSAPs.

Section 9
Recommend several references to = phonebcp in this section, since phonebcp specifically discusses where = these IDs are placed in the SIP message.

Section 11
I would slightly expand this section = to also mention the disabling of calling features. For example, change = the header and add a sentence like "The disabling of other call = features, such as call waiting, is also discussed in = phonebcp.

Barbara Stark
BellSouth Science & Technology = (a recently acquired part of AT&T)

*****

The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers. GA624

 ------_=_NextPart_001_01C73599.40374B9E-- --===============1914972457== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1914972457==-- From ecrit-bounces@ietf.org Thu Jan 11 10:58:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52Jx-0000kX-Re; Thu, 11 Jan 2007 10:58:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52Jw-0000kS-FH for ecrit@ietf.org; Thu, 11 Jan 2007 10:58:28 -0500 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H52Ju-0004QB-1f for ecrit@ietf.org; Thu, 11 Jan 2007 10:58:28 -0500 Received: from ([139.76.131.87]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.169157309; Thu, 11 Jan 2007 10:58:14 -0500 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 11 Jan 2007 10:58:14 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 11 Jan 2007 10:58:14 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 11 Jan 2007 10:58:14 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA2B5360@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Importance: normal Priority: normal Thread-Topic: Comments on [draft-ietf-ecrit-mapping-arch-01.txt] Thread-Index: Acc1mXS9Z8qeYjOAThOaUpn4sxdrBw== From: "Stark, Barbara" To: "ECRIT" X-OriginalArrivalTime: 11 Jan 2007 15:58:14.0298 (UTC) FILETIME=[4D1727A0:01C73599] X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: [Ecrit] Comments on [draft-ietf-ecrit-mapping-arch-01.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0217858391==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0217858391== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73599.4D56BDFE" Content-Transfer-Encoding: 7bit This is a multi-part message in MIME format. ------_=_NextPart_001_01C73599.4D56BDFE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I reviewed this document from the perspective of an employee of a major = service provider. Nonetheless, these opinions are mine, as an = individual. This is a good document. I only have one substantive comment. Section 6, paragraph 3 "i.e." means that this is intended to be a precise and complete list. I = would recommend and prefer "e.g.", since there are other ways to provide = configuration information, both for VSPs and ISPs. To this point, I = think it would be useful if the L7 config protocol could provide = resolver / forest guide address. Barbara Stark BellSouth Science & Technology (a recently acquired part of AT&T) ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA623 ------_=_NextPart_001_01C73599.4D56BDFE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on [draft-ietf-ecrit-mapping-arch-01.txt]

I reviewed this document from the = perspective of an employee of a major service provider. Nonetheless, = these opinions are mine, as an individual.

This is a good document. I only have = one substantive comment.

Section 6, paragraph 3
"i.e." means that this is = intended to be a precise and complete list. I would recommend and prefer = "e.g.", since there are other ways to provide configuration = information, both for VSPs and ISPs. To this point, I think it would be = useful if the L7 config protocol could provide resolver / forest guide = address.

Barbara Stark
BellSouth Science & Technology = (a recently acquired part of AT&T)

*****

The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers. GA623

 ------_=_NextPart_001_01C73599.4D56BDFE-- --===============0217858391== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0217858391==-- From ecrit-bounces@ietf.org Thu Jan 11 11:06:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52RE-0004Ks-Hw; Thu, 11 Jan 2007 11:06:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52RA-0004Ii-8a for ecrit@ietf.org; Thu, 11 Jan 2007 11:05:56 -0500 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H52Ly-0004tZ-PS for ecrit@ietf.org; Thu, 11 Jan 2007 11:00:55 -0500 Received: from ([139.76.131.87]) by aismt06p.bellsouth.com with SMTP id KP-AXPRN.14295505; Thu, 11 Jan 2007 11:00:04 -0500 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 11 Jan 2007 11:00:03 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 11 Jan 2007 11:00:04 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 11 Jan 2007 11:00:04 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA2B5361@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Importance: normal Priority: normal Thread-Topic: Comments on [draft-ietf-ecrit-lost-02.txt] Thread-Index: Acc1mbY3C4skgwusQgi/uEc3kM7ILQ== From: "Stark, Barbara" To: "ECRIT" X-OriginalArrivalTime: 11 Jan 2007 16:00:04.0352 (UTC) FILETIME=[8EB01000:01C73599] X-Spam-Score: 0.7 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Subject: [Ecrit] Comments on [draft-ietf-ecrit-lost-02.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1988174681==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1988174681== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73599.8E7CC31E" Content-Transfer-Encoding: 7bit This is a multi-part message in MIME format. ------_=_NextPart_001_01C73599.8E7CC31E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I reviewed this document from the perspective of an employee of a major = service provider. Nonetheless, these opinions are mine, as an = individual. I believe this is the right type of protocol to meet this need, and that = it is progressing well. I've been following the discussion of issues, = and am satisfied that the right issues are being discussed and properly = addressed. I have no specific comments on the actual text. I would like to see some other industry bodies (such as NENA in the US) = expand on "Civic Address Validation". I think the level of detail in = this document is appropriate, but that for validation to really work, = national bodies need to specify more detailed validation rules, = consistent with how location information is managed and used in their = country. For example, when ZIP Code and city name are both "valid", but = do not match, which is considered invalid? Is the street name used as a = tie breaker (street name is valid in ZIP code, but not city)? This might = be useful work to suggest at the next SDO meeting. Barbara Stark BellSouth Science & Technology (a recently acquired part of AT&T) ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA623 ------_=_NextPart_001_01C73599.8E7CC31E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on [draft-ietf-ecrit-lost-02.txt]

I reviewed this document from the = perspective of an employee of a major service provider. Nonetheless, = these opinions are mine, as an individual.

I believe this is the right type of = protocol to meet this need, and that it is progressing well. I've been = following the discussion of issues, and am satisfied that the right = issues are being discussed and properly addressed. I have no specific = comments on the actual text.

I would like to see some other industry = bodies (such as NENA in the US) expand on "Civic Address = Validation". I think the level of detail in this document is = appropriate, but that for validation to really work, national bodies = need to specify more detailed validation rules, consistent with how = location information is managed and used in their country. For example, = when ZIP Code and city name are both "valid", but do not = match, which is considered invalid? Is the street name used as a tie = breaker (street name is valid in ZIP code, but not city)? This might be = useful work to suggest at the next SDO meeting.

Barbara Stark
BellSouth Science & Technology = (a recently acquired part of AT&T)

*****

The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers. GA623

 ------_=_NextPart_001_01C73599.8E7CC31E-- --===============1988174681== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1988174681==-- From ecrit-bounces@ietf.org Thu Jan 11 11:09:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52Ue-0007hu-8p; Thu, 11 Jan 2007 11:09:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52Ud-0007fR-2a for ecrit@ietf.org; Thu, 11 Jan 2007 11:09:31 -0500 Received: from smtp01out.dot.gov ([199.79.179.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H52Ua-0007FD-Jb for ecrit@ietf.org; Thu, 11 Jan 2007 11:09:31 -0500 Received: from dotfaawms005.ad.dot.gov ([152.119.86.161]) by smtp01out.dot.gov with ESMTP; 11 Jan 2007 11:09:12 -0500 X-IronPort-AV: i="4.13,173,1167627600"; d="scan'208,217"; a="61420700:sNHT16561433336" Received: from OSTMAIL03VS3.ad.dot.gov ([152.119.86.69]) by DOTFAAWMS005.ad.dot.gov with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 11:09:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Comments on [draft-ietf-ecrit-lost-02.txt] Date: Thu, 11 Jan 2007 11:09:03 -0500 Message-ID: <0A0D0FBCB8154043B909C961D02A7A44031DB4FE@OSTMAIL03VS3.ad.dot.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on [draft-ietf-ecrit-lost-02.txt] Thread-Index: Acc1mbY3C4skgwusQgi/uEc3kM7ILQAAN73w From: To: , X-OriginalArrivalTime: 11 Jan 2007 16:09:04.0391 (UTC) FILETIME=[D0937970:01C7359A] X-Spam-Score: 0.2 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0686089318==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0686089318== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7359A.D08601B3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7359A.D08601B3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with including "Civic Address Validation" as a meeting topic. This varies around the country, from local government to local government and becomes problematical especially for emergency services. =20 Jenny Hansen ________________________________ From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com]=20 Sent: Thursday, January 11, 2007 11:00 AM To: ECRIT Subject: [Ecrit] Comments on [draft-ietf-ecrit-lost-02.txt] I reviewed this document from the perspective of an employee of a major service provider. Nonetheless, these opinions are mine, as an individual. I believe this is the right type of protocol to meet this need, and that it is progressing well. I've been following the discussion of issues, and am satisfied that the right issues are being discussed and properly addressed. I have no specific comments on the actual text. I would like to see some other industry bodies (such as NENA in the US) expand on "Civic Address Validation". I think the level of detail in this document is appropriate, but that for validation to really work, national bodies need to specify more detailed validation rules, consistent with how location information is managed and used in their country. For example, when ZIP Code and city name are both "valid", but do not match, which is considered invalid? Is the street name used as a tie breaker (street name is valid in ZIP code, but not city)? This might be useful work to suggest at the next SDO meeting. Barbara Stark BellSouth Science & Technology (a recently acquired part of AT&T)=20 ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623 ------_=_NextPart_001_01C7359A.D08601B3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments on [draft-ietf-ecrit-lost-02.txt]
I agree with including "Civic Address = Validation" as a=20 meeting topic. This varies around the country, from local government to = local=20 government and becomes problematical especially for emergency=20 services.
 
Jenny Hansen

From: Stark, Barbara=20 [mailto:Barbara.Stark@BellSouth.com]
Sent: Thursday, January = 11, 2007=20 11:00 AM
To: ECRIT
Subject: [Ecrit] Comments on=20 [draft-ietf-ecrit-lost-02.txt]

I reviewed this document from the = perspective of an=20 employee of a major service provider. Nonetheless, these opinions are = mine, as=20 an individual.

I believe this is the right type of = protocol to meet=20 this need, and that it is progressing well. I've been following the = discussion=20 of issues, and am satisfied that the right issues are being discussed = and=20 properly addressed. I have no specific comments on the actual = text.

I would like to see some other industry = bodies (such=20 as NENA in the US) expand on "Civic Address Validation". I think the = level of=20 detail in this document is appropriate, but that for validation to = really work,=20 national bodies need to specify more detailed validation rules, = consistent with=20 how location information is managed and used in their country. For = example, when=20 ZIP Code and city name are both "valid", but do not match, which is = considered=20 invalid? Is the street name used as a tie breaker (street name is valid = in ZIP=20 code, but not city)? This might be useful work to suggest at the next = SDO=20 meeting.

Barbara Stark
BellSouth Science & Technology (a recently acquired part of = AT&T)

*****

The information = transmitted is=20 intended only for the person or entity to which it is addressed and may = contain=20 confidential, proprietary, and/or privileged material. Any review,=20 retransmission, dissemination or other use of, or taking of any action = in=20 reliance upon this information by persons or entities other than the = intended=20 recipient is prohibited. If you received this in error, please contact = the=20 sender and delete the material from all computers.=20 GA623

 ------_=_NextPart_001_01C7359A.D08601B3-- --===============0686089318== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0686089318==-- From ecrit-bounces@ietf.org Thu Jan 11 11:57:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H53F2-0006Om-DY; Thu, 11 Jan 2007 11:57:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H53F1-0006OW-EA for ecrit@ietf.org; Thu, 11 Jan 2007 11:57:27 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H53En-0002F2-I0 for ecrit@ietf.org; Thu, 11 Jan 2007 11:57:27 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1H53Ed-00088n-Gu; Thu, 11 Jan 2007 10:57:03 -0600 From: "Brian Rosen" To: , , Subject: RE: [Ecrit] Comments on [draft-ietf-ecrit-lost-02.txt] Date: Thu, 11 Jan 2007 11:57:10 -0500 Message-ID: <005f01c735a1$8ad52620$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <0A0D0FBCB8154043B909C961D02A7A44031DB4FE@OSTMAIL03VS3.ad.dot.gov> Thread-Index: Acc1mbY3C4skgwusQgi/uEc3kM7ILQAAN73wAAGtrSA= X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org We recently did some work on this topic in the NENA i2.5 effort. We had = a discussion today about how to get the ideas out of that work into the = LoST effort. Terry Reese will be sending an email to ecrit on that subject. Brian ________________________________________ From: Jenny.Hansen@dot.gov [mailto:Jenny.Hansen@dot.gov]=20 Sent: Thursday, January 11, 2007 11:09 AM To: Barbara.Stark@BellSouth.com; ecrit@ietf.org Subject: RE: [Ecrit] Comments on [draft-ietf-ecrit-lost-02.txt] I agree with including "Civic Address Validation" as a meeting topic. = This varies around the country, from local government to local government and becomes problematical especially for emergency services. =A0 Jenny Hansen ________________________________________ From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com]=20 Sent: Thursday, January 11, 2007 11:00 AM To: ECRIT Subject: [Ecrit] Comments on [draft-ietf-ecrit-lost-02.txt] I reviewed this document from the perspective of an employee of a major service provider. Nonetheless, these opinions are mine, as an = individual. I believe this is the right type of protocol to meet this need, and that = it is progressing well. I've been following the discussion of issues, and = am satisfied that the right issues are being discussed and properly = addressed. I have no specific comments on the actual text. I would like to see some other industry bodies (such as NENA in the US) expand on "Civic Address Validation". I think the level of detail in = this document is appropriate, but that for validation to really work, = national bodies need to specify more detailed validation rules, consistent with = how location information is managed and used in their country. For example, = when ZIP Code and city name are both "valid", but do not match, which is considered invalid? Is the street name used as a tie breaker (street = name is valid in ZIP code, but not city)? This might be useful work to suggest = at the next SDO meeting. Barbara Stark BellSouth Science & Technology (a recently acquired part of AT&T)=20 ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by persons = or entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the material from = all computers. GA623 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 11 12:07:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H53Ow-000547-2p; Thu, 11 Jan 2007 12:07:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H53Ou-00053z-9N for ecrit@ietf.org; Thu, 11 Jan 2007 12:07:40 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H53Os-00049J-Rx for ecrit@ietf.org; Thu, 11 Jan 2007 12:07:40 -0500 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0BH7ZNt012861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Jan 2007 12:07:35 -0500 (EST) In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA2B5361@crexc41p> References: <7582BC68E4994F4ABF0BD4723975C3FA2B5361@crexc41p> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <42C033A0-DF83-4914-A9A3-ACAAD74F5329@cs.columbia.edu> From: Henning Schulzrinne Subject: Re: [Ecrit] Comments on [draft-ietf-ecrit-lost-02.txt] Date: Thu, 11 Jan 2007 12:09:08 -0500 To: "Stark, Barbara" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1028214657==" Errors-To: ecrit-bounces@ietf.org --===============1028214657== Content-Type: multipart/alternative; boundary=Apple-Mail-1--897895980 --Apple-Mail-1--897895980 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Thanks for your comments. The -03 version will probably amplify this aspect a bit, but I think the general notion should be - the protocol indicates which elements it used for mapping (in your example, it would indicate 'zip' or 'city') - it would return a best-guess mapping. There is a sub-case that is of practical interest: Namely, that the address is self-contradicting, but the result is the same. For example, if somebody were to use the wrong NYC zip code, the same PSAP would be returned. I don't think a protocol specification can reasonably predict information quality trade-offs. In general, these should not occur for actual emergency calls, as they are discovered long beforehand in our current model. I'm not even sure NENA can come up with national rules for this, as this is less of a US-vs-other-country issue but rather a local decision, possibly informed by local circumstances. ("The telco folks in Smalltown always get the zip code wrong since it was just changed; we'll ignore it for now.") Thus, to avoid discussions in the abstract, I think it would be helpful to clearly identify the type of decisions that a local policy might make. Having these spelled out will also help implementors to provide the right hooks, since we really don't want every police chief to program Java. Henning On Jan 11, 2007, at 11:00 AM, Stark, Barbara wrote: > I reviewed this document from the perspective of an employee of a > major service provider. Nonetheless, these opinions are mine, as an > individual. > > I believe this is the right type of protocol to meet this need, and > that it is progressing well. I've been following the discussion of > issues, and am satisfied that the right issues are being discussed > and properly addressed. I have no specific comments on the actual > text. > > I would like to see some other industry bodies (such as NENA in the > US) expand on "Civic Address Validation". I think the level of > detail in this document is appropriate, but that for validation to > really work, national bodies need to specify more detailed > validation rules, consistent with how location information is > managed and used in their country. For example, when ZIP Code and > city name are both "valid", but do not match, which is considered > invalid? Is the street name used as a tie breaker (street name is > valid in ZIP code, but not city)? This might be useful work to > suggest at the next SDO meeting. > > Barbara Stark > BellSouth Science & Technology (a recently acquired part of AT&T) > > ***** > > The information transmitted is intended only for the person or > entity to which it is addressed and may contain confidential, > proprietary, and/or privileged material. Any review, > retransmission, dissemination or other use of, or taking of any > action in reliance upon this information by persons or entities > other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete the material > from all computers. GA623 > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit --Apple-Mail-1--897895980 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Thanks for your = comments.=A0

The -03 version will = probably amplify this aspect a bit, but I think the general notion = should be

- = the protocol indicates which elements it used for mapping (in your = example, it would indicate 'zip' or 'city')

- it would return a = best-guess mapping.

There is a sub-case that is = of practical interest: Namely, that the address is self-contradicting, = but the result is the same. For example, if somebody were to use the = wrong NYC zip code, the same PSAP would be returned.

I don't think a protocol = specification can reasonably predict information quality trade-offs. In = general, these should not occur for actual emergency calls, as they are = discovered long beforehand in our current model. I'm not even sure NENA = can come up with national rules for this, as this is less of a = US-vs-other-country issue but rather a local decision, possibly informed = by local circumstances. ("The telco folks in Smalltown always get the = zip code wrong since it was just changed; we'll ignore it for = now.")

Thus, = to avoid discussions in the abstract, I think it would be helpful to = clearly identify the type of decisions that a local policy might make. = Having these spelled out will also help implementors to provide the = right hooks, since we really don't want every police chief to program = Java.

Henning

On= Jan 11, 2007, at 11:00 AM, Stark, Barbara wrote:

I reviewed this document from the perspective = of an employee of a major service provider. Nonetheless, these opinions = are mine, as an individual.

I= believe this is the right type of protocol to meet this need, and that = it is progressing well. I've been following the discussion of issues, = and am satisfied that the right issues are being discussed and properly = addressed. I have no specific comments on the actual = text.

I would like to see = some other industry bodies (such as NENA in the US) expand on "Civic = Address Validation". I think the level of detail in this document is = appropriate, but that for validation to really work, national bodies = need to specify more detailed validation rules, consistent with how = location information is managed and used in their country. For example, = when ZIP Code and city name are both "valid", but do not match, which is = considered invalid? Is the street name used as a tie breaker (street = name is valid in ZIP code, but not city)? This might be useful work to = suggest at the next SDO meeting.

Barbara Stark
BellSouth Science & Technology (a recently acquired = part of AT&T)

*****

The information transmitted = is intended only for the person or entity to which it is addressed and = may contain confidential, proprietary, and/or privileged material. Any = review, retransmission, dissemination or other use of, or taking of any = action in reliance upon this information by persons or entities other = than the intended recipient is prohibited. If you received this in = error, please contact the sender and delete the material from all = computers. GA623

Ecrit mailing list

= --Apple-Mail-1--897895980-- --===============1028214657== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1028214657==-- From ecrit-bounces@ietf.org Thu Jan 11 13:37:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54o1-0006Do-KC; Thu, 11 Jan 2007 13:37:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54o0-0006Dg-DI for ecrit@ietf.org; Thu, 11 Jan 2007 13:37:40 -0500 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H54ng-0005vz-3d for ecrit@ietf.org; Thu, 11 Jan 2007 13:37:40 -0500 Received: from ([139.76.131.83]) by aismt06p.bellsouth.com with SMTP id KP-AXPRN.14314028; Thu, 11 Jan 2007 13:36:55 -0500 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 11 Jan 2007 13:36:55 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 11 Jan 2007 13:36:54 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 11 Jan 2007 13:36:55 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA2B5364@crexc41p> X-MS-Has-Attach: Importance: normal Priority: normal X-MS-TNEF-Correlator: Thread-Topic: Comments on [draft-ietf-ecrit-phonebcp-00.txt] Thread-Index: Acc1r5/N387sCGtwQLSNfCYTLcTGVA== From: "Stark, Barbara" To: "ECRIT" X-OriginalArrivalTime: 11 Jan 2007 18:36:54.0709 (UTC) FILETIME=[77B29650:01C735AF] X-Spam-Score: 0.7 (/) X-Scan-Signature: 90f8d7cac99eccf384c4cdc57475e98c Subject: [Ecrit] Comments on [draft-ietf-ecrit-phonebcp-00.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0593998733==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0593998733== Content-class: urn:content-classes:message Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C735AF.782476FE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C735AF.782476FE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable General Comments phonebcp has requirements for end devices, proxies, and PSAPs. It would = be useful if there were some way to easily distinguish which = requirements applied to which elements, such as specific subsections for = the different elements, or by numbering the requirements, with a = separate numbering scheme for each element. I would like to be able to = use this document by telling vendors that they must comply with it. I = would want to tell proxy vendors they must comply with the proxy = requirements, and SIP endpoint vendors that they must comply with the = SIP endpoint requirements. The easier it is for them to locate all the = individual requirements that apply, the greater the likelihood that they = will successfully comply. I'm happy to help with this, in any way. I also believe this document needs considerably more detail. Some = specifics on this are at the end of this email, along with an offer to = help write some of those specifics. In general, I would like to see this = document provide specifications at a level so that device behavior is = highly consistent and predictable between different vendors. Specific Comments Section 2 Numbered list, number 2=20 It really doesn't matter whether the user dialed a "visited" or "home" = number, so long as the number is recognized by the device as an = emergency number. Could this be genericized to say "User dials an = emergency number that is known to the device."? Bullet list, 3rd bullet When I read "as the uri of an emergency call", this suggested = "Request-URI" to me. But Section 6.1 says this would be the uri in = "To:". There are just so many URIs in SIP Invite. Could this be made = more explicit to say "as the "To:" uri of an emergency call"? 4th bullet And say that the PSAP's URI is the "Request-URI". I think it's also = important to note that the LoST query validated the location. Section 4 2nd paragraph [editorial] expand "LCPs" acronym [editorial] 3rd and 7th paragraphs are redundant; 4th and 8th are also = effectively redundant. Recommend deleting 3rd paragraph, and merging the = best parts of 4 and 8. I have grave concerns over the mandating of LLDP in consumer products, = and will address this in a separate email. I realize LLDP has been = discussed before, but I don't think it was fully resolved. Section 6.1 Item 1 The initial SHOULD statement is too weak. I would prefer "If the device = recognizes the dialstring as an emergency call, and it successfully gets = a uri as a response to a LoST query, then it MUST place that uri in the = Request-URI. If the device recognizes the call as an emergency call, but = does not succeed in getting a uri from a LoST query, then it MUST place = an "sos" service URN in the Request-URI. [I assume that the reference to = the "To:" field for the "sos" service urn should have been = "Request-URI".] I appreciate the purpose of draft-rosen-iptel-dialstring-04, but I'm not = sure it's really appropriate or needed as a requirement in this bcp. = That is, devices will continue to format dial strings just as they = always have (e.g., sip:911@myvsp.com), unless VSPs adopt the changes = recommended in the referenced draft. And it's not at all clear to me = when those changes will happen. I recommend saying that "If the device = cannot do local dialstring interpretation, then it is expected that the = device will place the dialed digits in the Request-URI, consistent with = the expectations of its VSP's proxy." Item 2 The "SHOULD" statement regarding the service URN is too weak. Stating = that "To:" must be present seems unnecessary to me, since RFC 3261 = already requires it. I would prefer:=20 If the device recognizes the dial string as an emergency number, it MUST = place an "sos" service URN in the To: header. sips MUST be specified ... = TLS connection. If the device does not recognize the dial string, it is = expected that the device will place the dialed digits in the To: header, = consistent with the expectations of its VSP's proxy. Item 3 [editorial] Expand "AoR" RFC 3261 requires From:. The MUST statement seems redundant. How is this requirement intended to modify the requirements of RFC 3261, = in which AoR in To: is effectively a "MAY" ("possibly" is the exact word = used), and where it is explicit that "Anonymous" with a meaningless URI = is perfectly ok?=20 Item 4 RFC 3261 requires Via:, and it frequently has the local IP address and = port of the device. This requirement is suggesting it should be = something else?=20 Item 5 Need to include reference (draft-rosenberg-sip-ua-loose-route-00) for = loose route parameter? I didn't have a clue what a loose route parameter = was. References [editorial] update dhcp-civil reference to RFC 4676, here and in = document text. ------------------------------------------- What I think is missing --------------------------------- I'm happy to provide text for any of these items. The way I see it, if = it isn't in phonebcp, I'm going to have to write it anyway, either to go = into a document at another standards body, or for the company I'm with = to be able to provide requirements to its equipment vendors. Per the framework document, this phonebcp needs to address what happens = when it receives multiple locations. Requirements for multipart (per the discussion on the email reflector) Expanded requirements on the disabling of features. For example, instead = of simply listing "Outbound Call Blocking", it might be better to say = "The calling device MUST NOT apply any outbound call blocking rules to = dial strings or URIs that are defined in the device as emergency dial = strings or URIs." In many cases, these features are frequently provided = out of a VSP features server. Therefore, requirements for disabling of = features need to be written for VSP features, as well as calling device = features. Requirements for routers that may have VoiP behind them Considerably more detail on location determination. Here is a slightly = updated version of what I sent previously: Endpoint device 1. If the device has a DHCP client, the client MUST support RFC 3825 = and RFC 4676. [There is an expectation that the responding DHCP server = has the intelligence to respond to only one or the other.] a. If the device is configured to use DHCP for bootstrapping, it MUST = include both options in its DHCP REQUEST. b. When this device initiates an emergency call (see section on = requirements for recognizing emeregency calls), it MUST send a DHCP = INFORM message to refresh the location information. [Should it only use = the option that was previously successful?] 2. If the device supports LLDP-MED, it MUST support the "Location = Identification TLV" as defined in . 3. The device MUST support whatever L7 mechanism we come up with. 4. The device MUST support certain discovery mechanisms for finding = that L7 server. a. Server discovery MUST be done before any VPNs are initiated. 5. If the device allows for bootstrapping methods other than DHCP, it = SHOULD support being configured to request location through a DHCP = INFORM message with options as described in RFC 3825 and RFC 4676, when = it is configured to use one of these alternate bootstrap methods (e.g., = PPPoE, PPPoA, static IP address). a. If the device is configured to request location through = DHCPINFORM, then it MUST include both options in a DHCP INFORM message = sent shortly after bootstrap, and before any VPN sessions are initiated. b. When this device initiates an emergency call (see section on = requirements for recognizing emeregency calls), it MUST send a DHCP = INFORM message to refresh the location information. [Should it only use = the option that was previously successful?] 6. Interactions of the various methods a. If a device receives location information from both LLDP-MED and = DHCP which takes precedence? b. If a device successfully receives location information through = either DHCP or LLDP-MED, it MUST NOT request a location through the L7 = mechanism. 7. Location from embedded GPS? 8. Handling of multiple locations?=20 9. The device MUST discover a LoST server. [This needs more detail, as = to precisely which steps to take, and how to determone which steps to = take.] 10. The device MUST do a LoST query, using its location, for each "sos" = URI that is known to it. Devices with DHCP servers 1. The DHCP server MUST support RFC 3825 and RFC 4676. The device MUST = be configurable to respond to either 0 (zero) or 1 of these options. The = device MUST NOT allow both options to be enabled simultaneously. 2. If the device supports LLDP-MED, it MUST meet the requirements of an = LLDP-MED Network Connectivity Device, as defined in . This is NOT a requirement for the device to support LLDP-MED = -- only a requirement that if LLDP-MED is implemented, it must be done = according to the spec. 3. We might want to require this device to participate in some of the = L7 server discovery mechanisms.=20 4. If the device has a WAN interface, it MUST meet requirements 1, 3, = 5, 6, and 7 of the Endpoint device, over that WAN interface. 5. A different set of L7 server discover mechanisms will probably need = to be recommended. 6. Do we want to require the device to be able to translate an L7 = response on the WAN side to a DHCP response to LAN devices? Should this = occur automatically? 7. If the device receives location information via DHCP on its WAN = interface, it MUST automatically configure itself to pass this = information on to LAN-side devices that request it. 8. Does this device have a role in LoST discovery? Barbara Stark BellSouth Science & Technology (a recently acquired part of AT&T) ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA622 ------_=_NextPart_001_01C735AF.782476FE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on [draft-ietf-ecrit-phonebcp-00.txt]

General Comments
phonebcp has requirements for end = devices, proxies, and PSAPs. It would be useful if there were some way = to easily distinguish which requirements applied to which elements, such = as specific subsections for the different elements, or by numbering the = requirements, with a separate numbering scheme for each element. I would = like to be able to use this document by telling vendors that they must = comply with it. I would want to tell proxy vendors they must comply with = the proxy requirements, and SIP endpoint vendors that they must comply = with the SIP endpoint requirements. The easier it is for them to locate = all the individual requirements that apply, the greater the likelihood = that they will successfully comply. I'm happy to help with this, in any = way.

I also believe this document needs = considerably more detail. Some specifics on this are at the end of this = email, along with an offer to help write some of those specifics. In = general, I would like to see this document provide specifications at a = level so that device behavior is highly consistent and predictable = between different vendors.

Specific Comments
Section 2
Numbered list, number 2
It really doesn't matter whether the = user dialed a "visited" or "home" number, so long as = the number is recognized by the device as an emergency number. Could = this be genericized to say "User dials an emergency number that is = known to the device."?

Bullet list, 3rd bullet
When I read "as the uri of an = emergency call", this suggested "Request-URI" to me. But = Section 6.1 says this would be the uri in "To:". There are = just so many URIs in SIP Invite. Could this be made more explicit to say = "as the "To:" uri of an emergency call"?

4th bullet
And say that the PSAP's URI is the = "Request-URI". I think it's also important to note that the = LoST query validated the location.

Section 4
2nd paragraph
[editorial] expand "LCPs" = acronym

[editorial] 3rd and 7th paragraphs are = redundant; 4th and 8th are also effectively redundant. Recommend = deleting 3rd paragraph, and merging the best parts of 4 and = 8.

I have grave concerns over the = mandating of LLDP in consumer products, and will address this in a = separate email. I realize LLDP has been discussed before, but I don't = think it was fully resolved.

Section 6.1
Item 1
The initial SHOULD statement is too = weak. I would prefer "If the device recognizes the dialstring as an = emergency call, and it successfully gets a uri as a response to a LoST = query, then it MUST place that uri in the Request-URI. If the device = recognizes the call as an emergency call, but does not succeed in = getting a uri from a LoST query, then it MUST place an "sos" = service URN in the Request-URI. [I assume that the reference to the = "To:" field for the "sos" service urn should have = been "Request-URI".]

I appreciate the purpose of = draft-rosen-iptel-dialstring-04, but I'm not sure it's really = appropriate or needed as a requirement in this bcp. That is, devices = will continue to format dial strings just as they always have (e.g., = sip:911@myvsp.com), unless VSPs adopt the changes recommended in the = referenced draft. And it's not at all clear to me when those changes = will happen. I recommend saying that "If the device cannot do local = dialstring interpretation, then it is expected that the device will = place the dialed digits in the Request-URI, consistent with the = expectations of its VSP's proxy."

Item 2
The "SHOULD" statement = regarding the service URN is too weak. Stating that "To:" must = be present seems unnecessary to me, since RFC 3261 already requires it. = I would prefer:

If the device recognizes the dial = string as an emergency number, it MUST place an "sos" service = URN in the To: header. sips MUST be specified ... TLS connection. If the = device does not recognize the dial string, it is expected that the = device will place the dialed digits in the To: header, consistent with = the expectations of its VSP's proxy.

Item 3
[editorial] Expand = "AoR"

RFC 3261 requires From:. The MUST = statement seems redundant.
How is this requirement intended to = modify the requirements of RFC 3261, in which AoR in To: is effectively = a "MAY" ("possibly" is the exact word used), and = where it is explicit that "Anonymous" with a meaningless URI = is perfectly ok?

Item 4
RFC 3261 requires Via:, and it = frequently has the local IP address and port of the device. This = requirement is suggesting it should be something else?

Item 5
Need to include reference = (draft-rosenberg-sip-ua-loose-route-00) for loose route parameter? I = didn't have a clue what a loose route parameter was.

References
[editorial] update dhcp-civil = reference to RFC 4676, here and in document text.

-------------------------------------------
What I think is missing
---------------------------------
I'm happy to provide text for any of = these items. The way I see it, if it isn't in phonebcp, I'm going to = have to write it anyway, either to go into a document at another = standards body, or for the company I'm with to be able to provide = requirements to its equipment vendors.

Per the framework document, this = phonebcp needs to address what happens when it receives multiple = locations.

Requirements for multipart (per the = discussion on the email reflector)

Expanded requirements on the disabling = of features. For example, instead of simply listing "Outbound Call = Blocking", it might be better to say "The calling device MUST = NOT apply any outbound call blocking rules to dial strings or URIs that = are defined in the device as emergency dial strings or URIs." In = many cases, these features are frequently provided out of a VSP features = server. Therefore, requirements for disabling of features need to be = written for VSP features, as well as calling device features.

Requirements for routers that may have = VoiP behind them

Considerably more detail on location = determination. Here is a slightly updated version of what I sent = previously:
Endpoint device
 1. If the device has a DHCP = client, the client MUST support RFC 3825 and RFC 4676. [There is an = expectation that the responding DHCP server has the intelligence to = respond to only one or the other.]

   a. If the device is = configured to use DHCP for bootstrapping, it MUST include both options = in its DHCP REQUEST.
   b. When this device = initiates an emergency call (see section on requirements for recognizing = emeregency calls), it MUST send a DHCP INFORM message to refresh the = location information. [Should it only use the option that was previously = successful?]

 2. If the device supports = LLDP-MED, it MUST support the “Location Identification TLV” = as defined in <LLDP-MED reference>.

 3. The device MUST support = whatever L7 mechanism we come up with.
 4. The device MUST support = certain discovery mechanisms for finding that L7 server.
    a. Server discovery = MUST be done before any VPNs are initiated.
 5. If the device allows for = bootstrapping methods other than DHCP, it SHOULD support being = configured to request location through a DHCP INFORM message with = options as described in RFC 3825 and RFC 4676, when it is configured to = use one of these alternate bootstrap methods (e.g., PPPoE, PPPoA, static = IP address).

   a. If the device is = configured to request location through DHCPINFORM, then it MUST include = both options in a DHCP INFORM message sent shortly after bootstrap, and = before any VPN sessions are initiated.

   b. When this device = initiates an emergency call (see section on requirements for recognizing = emeregency calls), it MUST send a DHCP INFORM message to refresh the = location information. [Should it only use the option that was previously = successful?]

 6. Interactions of the various = methods
   a. If a device receives = location information from both LLDP-MED and DHCP which takes = precedence?
   b. If a device = successfully receives location information through either DHCP or = LLDP-MED, it MUST NOT request a location through the L7 = mechanism.

7. Location from embedded GPS?
8. Handling of multiple locations? =
9. The device MUST discover a LoST = server. [This needs more detail, as to precisely which steps to take, = and how to determone which steps to take.]

10. The device MUST do a LoST query, = using its location, for each "sos" URI that is known to = it.

Devices with DHCP servers
 1. The DHCP server MUST support = RFC 3825 and RFC 4676. The device MUST be configurable to respond to = either 0 (zero) or 1 of these options. The device MUST NOT allow both = options to be enabled simultaneously.

 2. If the device supports = LLDP-MED, it MUST meet the requirements of an LLDP-MED Network = Connectivity Device, as defined in <LLDP-MED reference>. This is = NOT a requirement for the device to support LLDP-MED -- only a = requirement that if LLDP-MED is implemented, it must be done according = to the spec.

 3. We might want to require this = device to participate in some of the L7 server discovery mechanisms. =
 4. If the device has a WAN = interface, it MUST meet requirements 1, 3, 5, 6, and 7 of the Endpoint = device, over that WAN interface.

 5. A different set of L7 server = discover mechanisms will probably need to be recommended.
 6. Do we want to require the = device to be able to translate an L7 response on the WAN side to a DHCP = response to LAN devices? Should this occur automatically?

 7. If the device receives = location information via DHCP on its WAN interface, it MUST = automatically configure itself to pass this information on to LAN-side = devices that request it.

8. Does this device have a role in LoST = discovery?

Barbara Stark
BellSouth Science & Technology = (a recently acquired part of AT&T)

*****

The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers. GA622

 ------_=_NextPart_001_01C735AF.782476FE-- --===============0593998733== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0593998733==-- From ecrit-bounces@ietf.org Thu Jan 11 13:39:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54pw-0007Bd-Cm; Thu, 11 Jan 2007 13:39:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54pv-0007BY-DF for ecrit@ietf.org; Thu, 11 Jan 2007 13:39:39 -0500 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H54ps-0006P4-W2 for ecrit@ietf.org; Thu, 11 Jan 2007 13:39:39 -0500 Received: from ([139.76.131.79]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.169176602; Thu, 11 Jan 2007 13:39:18 -0500 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 11 Jan 2007 13:39:18 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 11 Jan 2007 13:39:19 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 11 Jan 2007 13:39:19 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA2B5365@crexc41p> Importance: normal Priority: normal X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLDP-MED in phonebcp Thread-Index: Acc1r/WCal808lT1RNmBIGwoHQSg+Q== From: "Stark, Barbara" To: "ECRIT" X-OriginalArrivalTime: 11 Jan 2007 18:39:19.0018 (UTC) FILETIME=[CDB664A0:01C735AF] X-Spam-Score: 0.7 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Subject: [Ecrit] LLDP-MED in phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2030371297==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============2030371297== Content-class: urn:content-classes:message Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C735AF.CDDAF81E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C735AF.CDDAF81E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm a bit concerned about the suggestion that LLDP-MED be implemented in = all consumer VoIP devices. Specifically, I'm worried about security. I haven't found any document that attempts to describe the security = risks of devices that advertise themselves with LLDP, and that are on = either a consumer LAN (assumed to generally have no other LLDP devices) = or on a public non-LLDP network (such as a hotspot). If this security = information exists, I'd appreciate being pointed to it. LLDP seems to be = very much designed to operate in an enterprise environment, where = network administrators exist, and where devices can generally trust each = other.=20 Is there some way for a device to determine whether the network it is in = is truly LLDP-enabled, before it starts sending out LLDP messages? LLDP-MED says that a wireless AP shouldn't broadcast LLDP-MED multicast = messages received from a wireless device, to other wireless devices. But = I assume that a non-LLDP-capable AP would mindlessly broadcast. What = does this mean in a hotspot environment? Could someone else on the = hotspot have a device that maliciously configures devices through LLDP = and LLDP-MED? Is it possible to write a trojan that would reside on a PC, and could = maliciously configure devices in a non-LLDP-capable consumer LAN? I really don't know enough. Would it be possible/appropriate for one of = the LLDP proponents to provide verbiage for the "Security = Considerations" section of phonebcp? I'm not convinced that the = normative references adequately address security concerns of its use in = these non-enterprise networks.=20 When should a device attempt to get location through LLDP? Would it be = appropriate for a device to only try it if DHCP and L7 fail? Barbara ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA621 ------_=_NextPart_001_01C735AF.CDDAF81E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LLDP-MED in phonebcp

I'm a bit concerned about the = suggestion that LLDP-MED be implemented in all consumer VoIP devices. = Specifically, I'm worried about security.

I haven't found any document that = attempts to describe the security risks of devices that advertise = themselves with LLDP, and that are on either a consumer LAN (assumed to = generally have no other LLDP devices) or on a public non-LLDP network = (such as a hotspot). If this security information exists, I'd appreciate = being pointed to it. LLDP seems to be very much designed to operate in = an enterprise environment, where network administrators exist, and where = devices can generally trust each other.

Is there some way for a device to = determine whether the network it is in is truly LLDP-enabled, before it = starts sending out LLDP messages?

LLDP-MED says that a wireless AP = shouldn't broadcast LLDP-MED multicast messages received from a wireless = device, to other wireless devices. But I assume that a non-LLDP-capable = AP would mindlessly broadcast. What does this mean in a hotspot = environment? Could someone else on the hotspot have a device that = maliciously configures devices through LLDP and LLDP-MED?

Is it possible to write a trojan that = would reside on a PC, and could maliciously configure devices in a = non-LLDP-capable consumer LAN?

I really don't know enough. Would it be = possible/appropriate for one of the LLDP proponents to provide verbiage = for the "Security Considerations" section of phonebcp? I'm not = convinced that the normative references adequately address security = concerns of its use in these non-enterprise networks.

When should a device attempt to get = location through LLDP? Would it be appropriate for a device to only try = it if DHCP and L7 fail?

Barbara

*****

The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers. GA621

 ------_=_NextPart_001_01C735AF.CDDAF81E-- --===============2030371297== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============2030371297==-- From ecrit-bounces@ietf.org Thu Jan 11 16:24:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57PD-00041X-Fg; Thu, 11 Jan 2007 16:24:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57PB-00040b-T6 for ecrit@ietf.org; Thu, 11 Jan 2007 16:24:13 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H57PA-0006aP-L6 for ecrit@ietf.org; Thu, 11 Jan 2007 16:24:13 -0500 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0BLO7iA012013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Jan 2007 16:24:11 -0500 (EST) In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA2B5360@crexc41p> References: <7582BC68E4994F4ABF0BD4723975C3FA2B5360@crexc41p> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <6D15FA18-B43B-4328-B6D6-47ECD962E3B1@cs.columbia.edu> From: Henning Schulzrinne Subject: Re: [Ecrit] Comments on [draft-ietf-ecrit-mapping-arch-01.txt] Date: Thu, 11 Jan 2007 16:25:40 -0500 To: "Stark, Barbara" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1110991645==" Errors-To: ecrit-bounces@ietf.org --===============1110991645== Content-Type: multipart/alternative; boundary=Apple-Mail-8--882504034 --Apple-Mail-8--882504034 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Thanks for the comment. Quick response inline below. On Jan 11, 2007, at 10:58 AM, Stark, Barbara wrote: > I reviewed this document from the perspective of an employee of a > major service provider. Nonetheless, these opinions are mine, as an > individual. > > This is a good document. I only have one substantive comment. > > Section 6, paragraph 3 > "i.e." means that this is intended to be a precise and complete > list. I would recommend and prefer "e.g.", since there are other > ways to provide configuration information, both for VSPs and ISPs. > To this point, I think it would be useful if the L7 config protocol > could provide resolver / forest guide address. I hope you're not talking about the L7 location configuration protocol here. Providing the address of the LoST resolver to the UA would be the role of the DHCP server and/or SIP configuration, depending on who is providing the service. Henning --Apple-Mail-8--882504034 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII
Thanks for the comment. = Quick response inline below.

On Jan 11, 2007, at = 10:58 AM, Stark, Barbara wrote:

I reviewed this document from the perspective = of an employee of a major service provider. Nonetheless, these opinions = are mine, as an individual.

This is a good document. I only have one substantive = comment.

Section 6, = paragraph 3
"i.e." means that = this is intended to be a precise and complete list. I would recommend = and prefer "e.g.", since there are other ways to provide configuration = information, both for VSPs and ISPs. To this point, I think it would be = useful if the L7 config protocol could provide resolver / forest guide = address.

I hope you're not talking about the L7 = location configuration protocol here. Providing the address of the LoST = resolver to the UA would be the role of the DHCP server and/or SIP = configuration, depending on who is providing the = service.

Henning

= --Apple-Mail-8--882504034-- --===============1110991645== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1110991645==-- From ecrit-bounces@ietf.org Thu Jan 11 19:55:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5AhE-0003UE-0d; Thu, 11 Jan 2007 19:55:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5AhC-0003Rz-P0 for ecrit@ietf.org; Thu, 11 Jan 2007 19:55:02 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5AhB-00053o-IM for ecrit@ietf.org; Thu, 11 Jan 2007 19:55:02 -0500 Received: from [192.168.0.41] (pool-141-153-205-123.mad.east.verizon.net [141.153.205.123]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0C0snMJ026464 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Jan 2007 19:54:54 -0500 (EST) In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA2B5360@crexc41p> References: <7582BC68E4994F4ABF0BD4723975C3FA2B5360@crexc41p> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Comments on [draft-ietf-ecrit-mapping-arch-01.txt] Date: Thu, 11 Jan 2007 19:54:45 -0500 To: "Stark, Barbara" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org One additional note: If the provider of a L7 location server wants to offer LoST services, this is easily accomplished: Simply advertise LoST in the NAPTR record for the domain of the server. This requires no protocol additions. On Jan 11, 2007, at 10:58 AM, Stark, Barbara wrote: > I reviewed this document from the perspective of an employee of a > major service provider. Nonetheless, these opinions are mine, as an > individual. > > This is a good document. I only have one substantive comment. > > Section 6, paragraph 3 > "i.e." means that this is intended to be a precise and complete > list. I would recommend and prefer "e.g.", since there are other > ways to provide configuration information, both for VSPs and ISPs. > To this point, I think it would be useful if the L7 config protocol > could provide resolver / forest guide address. > > Barbara Stark > BellSouth Science & Technology (a recently acquired part of AT&T) > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jan 12 08:44:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Mhe-0000l5-Ep; Fri, 12 Jan 2007 08:44:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Mhc-0000ky-UE for ecrit@ietf.org; Fri, 12 Jan 2007 08:44:17 -0500 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Mha-0003Rw-Cj for ecrit@ietf.org; Fri, 12 Jan 2007 08:44:16 -0500 Received: from ([139.76.131.87]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.169221715; Fri, 12 Jan 2007 08:43:43 -0500 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 12 Jan 2007 08:43:43 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 12 Jan 2007 08:43:43 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Comments on [draft-ietf-ecrit-mapping-arch-01.txt] Date: Fri, 12 Jan 2007 08:43:43 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA2B536C@crexc41p> In-Reply-To: X-MS-Has-Attach: Importance: normal Priority: normal X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on [draft-ietf-ecrit-mapping-arch-01.txt] Thread-Index: Acc15FgCSmiCpSAnRx6AhkLITqupQQAaTdKw From: "Stark, Barbara" To: "Henning Schulzrinne" X-OriginalArrivalTime: 12 Jan 2007 13:43:43.0042 (UTC) FILETIME=[ACA8FA20:01C7364F] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Using a NAPTR record sounds like a reasonable approach to me.=20 Barbara > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, January 11, 2007 7:55 PM > To: Stark, Barbara > Cc: ECRIT > Subject: Re: [Ecrit] Comments on=20 > [draft-ietf-ecrit-mapping-arch-01.txt] >=20 >=20 > One additional note: If the provider of a L7 location server=20 > wants to =20 > offer LoST services, this is easily accomplished: Simply advertise =20 > LoST in the NAPTR record for the domain of the server. This requires =20 > no protocol additions. >=20 > On Jan 11, 2007, at 10:58 AM, Stark, Barbara wrote: >=20 > > I reviewed this document from the perspective of an employee of a =20 > > major service provider. Nonetheless, these opinions are=20 > mine, as an =20 > > individual. > > > > This is a good document. I only have one substantive comment. > > > > Section 6, paragraph 3 > > "i.e." means that this is intended to be a precise and complete =20 > > list. I would recommend and prefer "e.g.", since there are other =20 > > ways to provide configuration information, both for VSPs and ISPs. =20 > > To this point, I think it would be useful if the L7 config=20 > protocol =20 > > could provide resolver / forest guide address. > > > > Barbara Stark > > BellSouth Science & Technology (a recently acquired part of AT&T) > > > > >=20 ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA623 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jan 12 14:17:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5RuP-0003uh-MB; Fri, 12 Jan 2007 14:17:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5RuO-0003u2-7Z for ecrit@ietf.org; Fri, 12 Jan 2007 14:17:48 -0500 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5RuN-0000T6-MF for ecrit@ietf.org; Fri, 12 Jan 2007 14:17:48 -0500 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 5863120053; Fri, 12 Jan 2007 14:17:47 -0500 (EST) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30519-03; Fri, 12 Jan 2007 14:17:46 -0500 (EST) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id C1B3F2009B; Fri, 12 Jan 2007 14:17:44 -0500 (EST) In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA2B5365@crexc41p> To: "Stark, Barbara" Subject: Re: [Ecrit] LLDP-MED in phonebcp MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: peter_blatherwick@mitel.com Date: Fri, 12 Jan 2007 14:17:42 -0500 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 01/12/2007 02:17:42 PM, Serialize complete at 01/12/2007 02:17:42 PM Content-Type: text/plain; charset="US-ASCII" X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: Manfred Arndt , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Barbara, list. I've also added a couple of the other LLDP-MED authors in CC here, who are familiar with the ECRIT problem space. > I'm a bit concerned about the suggestion that LLDP-MED be implemented > in all consumer VoIP devices. Specifically, I'm worried about > security. > > I haven't found any document that attempts to describe the security > risks of devices that advertise themselves with LLDP, and that are > on either a consumer LAN (assumed to generally have no other LLDP > devices) or on a public non-LLDP network (such as a hotspot). If > this > security information exists, I'd appreciate being pointed to > it. LLDP seems to be very much designed to operate in an enterprise > environment, where network administrators exist, and where devices > can generally trust each other. ... > I really don't know enough. Would it be possible/appropriate for one > of the LLDP proponents to provide verbiage for the "Security > Considerations" section of phonebcp? I'm not convinced that the > normative references adequately address security concerns of its use > in these non-enterprise networks. OK, here goes. First, I certainly agree completely that Security Considerations content on LLDP-MED, and the other methods also of course, would be a very good thing! It should include considerations for consumer and public networks, as well as enterprise ones, and also both wired and wireless. I'd be more than happy to contribute specific text for LLDP-MED in this, but let's bash it out on the list a bit first. Please count on me for that (really to Brian Rosen here I assume). We believe LLDP (and by inference LLDP-MED extensions) do not open significant security risks in a wired environment, and certainly not relative to DHCP methods. We also believe that LLDP-MED is also quite manageable in a wireless environment, where DHCP does not appear to be a very good option (IMHO). Can't really comment on merits relative to L7 methods at this point, since they are not actually settled. This is for the following key reasons: o LLDP frames, hence LLDP-MED extensions as well, are link specific. Hence any attack on the end device would need to be "on-wire" (ie effectively same as PSTN today, physical wiretap scenario). More details on this below. o Also since LLDP does not propagate past the single link, attacks from "higher" in the infrastructure are not possible through it (as can be the case for DHCP for example). o The information supplied from the device towards the network infrastructure is only ever sent to the upstream L2 switch, not propagated beyond it, and mechanisms to extract the information (SNMP MIBs) can readily be secured. o Information sent from the network infrastructure towards the device (specifically location objects in this discussion) is either strictly device-specific (wired case) or equally applicable to all devices in the broadcast (wireless AP case). In the latter case, if the information cannot be made generic to all, then LLDP would not be configured -- it is the administrator's choice. Now, some more detailed answers to your questions ... > Is there some way for a device to determine whether the network it > is in is truly LLDP-enabled, before it starts sending out LLDP > messages? Not really. The device could passively listen for LLDP before initiating its LLDP-MED, but that would add time to the startup (bad) and really only indicates the upstream L2 entity *says* it is LLDP compliant. I do not see this as a real risk however, unless the upstream device is compromised of course, but then all bets are off for all methods. > LLDP-MED says that a wireless AP shouldn't broadcast LLDP-MED > multicast messages received from a wireless device, to other > wireless devices. But I assume that a non-LLDP-capable AP would > mindlessly broadcast. What does this mean in a hotspot environment? > Could someone else on the hotspot have a device that maliciously > configures devices through LLDP and LLDP-MED? No, that would not be possible. Reasons for this are as follows (sorry, lots of details for full understanding). The LLDP-MED multicast address falls within the IEEE 802.1D block of reserved BPDU addresses, that must not be forwarded by a compliant Media Access Control Bridge (including APs). This reserved address list also includes Spanning Tree BPDUs, 802.1X PAE, and LLDP. Packets to these destinations must not be forwarded, whether or not the bridge supports that protocol. As such a properly implemented AP will not forward LLDP, even if the AP doesn't support LLDP. In addition, most Ethernet switches used for public access services support 'private VLANs' specifically designed to prevent this type of connectivity between devices on the same access switches. This feature is frequently deployed to prevent clients with rogue DHCP service from bringing down the network by misconfiguring all devices in the local subnet. This private VLAN feature also will prevent LLDP-MED flooding between clients. Many APs in public hot-spots have a similar feature, specifically to prevent two clients on the same AP from communicating directly. That being said, some APs are not properly implemented/configured and will mindlessly broadcast. (This will cause lots of other grief outside of LLDP also.) If this should occur, then multiple location mechanisms are beneficial to help identify configuration conflicts and/or rogue devices. When multiple formats are provided and there is a conflict, this *should* be brought to the users and/or administrator's attention. > Is it possible to write a trojan that would reside on a PC, and could > maliciously configure devices in a non-LLDP-capable consumer LAN? No, for reasons above. > When should a device attempt to get location through LLDP? Would it > be appropriate for a device to only try it if DHCP and L7 fail? This is not a security question, it is a reliability one, at least in my mind. I personally believe LLDP-MED should be tried first, then DHCP, then L7. This is in network layered order, from bottom up, closest source first. It is also "least moving parts" first order, hence most likely to be reliable. All this is IMHO at this point, certainly open to debate. I hope this helps. Sorry for the rather long reply. Cheers, Peter Blatherwick (Editor, ANSI/TIA-1057 / LLDP-MED) "Stark, Barbara" 11.01.07 13:39 To: "ECRIT" cc: Subject: [Ecrit] LLDP-MED in phonebcp I'm a bit concerned about the suggestion that LLDP-MED be implemented in all consumer VoIP devices. Specifically, I'm worried about security. I haven't found any document that attempts to describe the security risks of devices that advertise themselves with LLDP, and that are on either a consumer LAN (assumed to generally have no other LLDP devices) or on a public non-LLDP network (such as a hotspot). If this security information exists, I'd appreciate being pointed to it. LLDP seems to be very much designed to operate in an enterprise environment, where network administrators exist, and where devices can generally trust each other. Is there some way for a device to determine whether the network it is in is truly LLDP-enabled, before it starts sending out LLDP messages? LLDP-MED says that a wireless AP shouldn't broadcast LLDP-MED multicast messages received from a wireless device, to other wireless devices. But I assume that a non-LLDP-capable AP would mindlessly broadcast. What does this mean in a hotspot environment? Could someone else on the hotspot have a device that maliciously configures devices through LLDP and LLDP-MED? Is it possible to write a trojan that would reside on a PC, and could maliciously configure devices in a non-LLDP-capable consumer LAN? I really don't know enough. Would it be possible/appropriate for one of the LLDP proponents to provide verbiage for the "Security Considerations" section of phonebcp? I'm not convinced that the normative references adequately address security concerns of its use in these non-enterprise networks. When should a device attempt to get location through LLDP? Would it be appropriate for a device to only try it if DHCP and L7 fail? Barbara ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jan 12 14:41:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5SHg-0003Yh-DU; Fri, 12 Jan 2007 14:41:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5SHe-0003Wi-R9 for ecrit@ietf.org; Fri, 12 Jan 2007 14:41:50 -0500 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5SHb-0006rJ-8n for ecrit@ietf.org; Fri, 12 Jan 2007 14:41:50 -0500 Received: from ([139.76.131.79]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.169263953; Fri, 12 Jan 2007 14:41:26 -0500 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 12 Jan 2007 14:41:26 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 12 Jan 2007 14:41:26 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] LLDP-MED in phonebcp Date: Fri, 12 Jan 2007 14:41:26 -0500 Importance: normal Priority: normal Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA2B5370@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LLDP-MED in phonebcp Thread-Index: Acc2fmS8TxCg3J8wQaGTnCv3vlIYdgAAxnTQ From: "Stark, Barbara" To: X-OriginalArrivalTime: 12 Jan 2007 19:41:26.0899 (UTC) FILETIME=[A61DA430:01C73681] X-Spam-Score: 0.1 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: Manfred Arndt , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Thanks! That was extremely helpful and informative. I appreciate the level of detail. Barbara > -----Original Message----- > From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] > Sent: Friday, January 12, 2007 2:18 PM > To: Stark, Barbara > Cc: ECRIT; Dan Romascanu; Manfred Arndt > Subject: Re: [Ecrit] LLDP-MED in phonebcp >=20 >=20 > Hi Barbara, list.=20 >=20 > I've also added a couple of the other LLDP-MED authors in CC here,=20 > who are familiar with the ECRIT problem space.=20 >=20 > > I'm a bit concerned about the suggestion that LLDP-MED be=20 > implemented=20 > > in all consumer VoIP devices. Specifically, I'm worried about=20 > > security.=20 > >=20 > > I haven't found any document that attempts to describe the security=20 > > risks of devices that advertise themselves with LLDP, and that are=20 > > on either a consumer LAN (assumed to generally have no other LLDP=20 > > devices) or on a public non-LLDP network (such as a hotspot). If=20 > > this > security information exists, I'd appreciate being pointed to=20 > > it. LLDP seems to be very much designed to operate in an enterprise=20 > > environment, where network administrators exist, and where devices=20 > > can generally trust each other.=20 > ... > > I really don't know enough. Would it be=20 > possible/appropriate for one=20 > > of the LLDP proponents to provide verbiage for the "Security=20 > > Considerations" section of phonebcp? I'm not convinced that the=20 > > normative references adequately address security concerns=20 > of its use=20 > > in these non-enterprise networks.=20 >=20 > OK, here goes.=20 >=20 > First, I certainly agree completely that Security Considerations=20 > content on LLDP-MED, and the other methods also of course, would be a=20 > very good thing! It should include considerations for consumer and=20 > public networks, as well as enterprise ones, and also both wired and=20 > wireless. I'd be more than happy to contribute specific text for=20 > LLDP-MED in this, but let's bash it out on the list a bit first.=20 > Please count on me for that (really to Brian Rosen here I assume).=20 >=20 > We believe LLDP (and by inference LLDP-MED extensions) do not open=20 > significant security risks in a wired environment, and certainly not=20 > relative to DHCP methods. We also believe that LLDP-MED is=20 > also quite=20 > manageable in a wireless environment, where DHCP does not=20 > appear to be=20 > a very good option (IMHO). Can't really comment on merits=20 > relative to=20 > L7 methods at this point, since they are not actually settled. This=20 > is for the following key reasons:=20 >=20 > o LLDP frames, hence LLDP-MED extensions as well, are link specific.=20 > Hence any attack on the end device would need to be "on-wire" (ie=20 > effectively same as PSTN today, physical wiretap scenario). More=20 > details on this below.=20 >=20 > o Also since LLDP does not propagate past the single link,=20 > attacks from=20 > "higher" in the infrastructure are not possible through it=20 > (as can be=20 > the case for DHCP for example).=20 >=20 > o The information supplied from the device towards the network=20 > infrastructure is only ever sent to the upstream L2 switch, not=20 > propagated beyond it, and mechanisms to extract the information=20 > (SNMP MIBs) can readily be secured.=20 >=20 > o Information sent from the network infrastructure towards the device=20 > (specifically location objects in this discussion) is=20 > either strictly=20 > device-specific (wired case) or equally applicable to all=20 > devices in=20 > the broadcast (wireless AP case). In the latter case, if the=20 > information cannot be made generic to all, then LLDP would not be=20 > configured -- it is the administrator's choice.=20 >=20 > Now, some more detailed answers to your questions ... >=20 > > Is there some way for a device to determine whether the network it=20 > > is in is truly LLDP-enabled, before it starts sending out LLDP=20 > > messages?=20 >=20 > Not really. The device could passively listen for LLDP before=20 > initiating its LLDP-MED, but that would add time to the startup (bad)=20 > and really only indicates the upstream L2 entity *says* it is LLDP=20 > compliant. I do not see this as a real risk however, unless the=20 > upstream device is compromised of course, but then all bets are off=20 > for all methods.=20 >=20 > > LLDP-MED says that a wireless AP shouldn't broadcast LLDP-MED=20 > > multicast messages received from a wireless device, to other=20 > > wireless devices. But I assume that a non-LLDP-capable AP would=20 > > mindlessly broadcast. What does this mean in a hotspot environment?=20 > > Could someone else on the hotspot have a device that maliciously=20 > > configures devices through LLDP and LLDP-MED? >=20 > No, that would not be possible. Reasons for this are as follows=20 > (sorry, lots of details for full understanding).=20 >=20 > The LLDP-MED multicast address falls within the IEEE 802.1D block of > reserved BPDU addresses, that must not be forwarded by a=20 > compliant Media > Access Control Bridge (including APs). This reserved address=20 > list also > includes Spanning Tree BPDUs, 802.1X PAE, and LLDP. Packets to these > destinations must not be forwarded, whether or not the bridge supports > that protocol. As such a properly implemented AP will not=20 > forward LLDP, > even if the AP doesn't support LLDP. >=20 > In addition, most Ethernet switches used for public access services > support 'private VLANs' specifically designed to prevent this type of > connectivity between devices on the same access switches. =20 > This feature > is frequently deployed to prevent clients with rogue DHCP=20 > service from bringing down the network by misconfiguring all=20 > devices in=20 > the local subnet. This private VLAN feature also will=20 > prevent LLDP-MED=20 > flooding between clients. >=20 > Many APs in public hot-spots have a similar feature, specifically to > prevent two clients on the same AP from communicating directly.=20 >=20 > That being said, some APs are not properly implemented/configured and > will mindlessly broadcast. (This will cause lots of other grief=20 > outside of LLDP also.) If this should occur, then multiple location=20 > mechanisms are beneficial to help identify configuration conflicts=20 > and/or rogue devices. When multiple formats are provided and=20 > there is=20 > a conflict, this *should* be brought to the users and/or=20 > administrator's=20 > attention.=20 >=20 > > Is it possible to write a trojan that would reside on a PC,=20 > and could=20 > > maliciously configure devices in a non-LLDP-capable consumer LAN? >=20 > No, for reasons above.=20 >=20 > > When should a device attempt to get location through LLDP? Would it=20 > > be appropriate for a device to only try it if DHCP and L7 fail? >=20 > This is not a security question, it is a reliability one, at least in=20 > my mind. I personally believe LLDP-MED should be tried=20 > first, then DHCP,=20 > then L7. This is in network layered order, from bottom up, closest=20 > source first. It is also "least moving parts" first order,=20 > hence most=20 > likely to be reliable. All this is IMHO at this point,=20 > certainly open=20 > to debate.=20 >=20 > I hope this helps. Sorry for the rather long reply.=20 >=20 > Cheers, > Peter Blatherwick=20 > (Editor, ANSI/TIA-1057 / LLDP-MED) >=20 >=20 >=20 >=20 >=20 >=20 > "Stark, Barbara" > 11.01.07 13:39 > =20 > To: "ECRIT" > cc:=20 > Subject: [Ecrit] LLDP-MED in phonebcp >=20 >=20 > I'm a bit concerned about the suggestion that LLDP-MED be=20 > implemented in=20 > all consumer VoIP devices. Specifically, I'm worried about security. > I haven't found any document that attempts to describe the=20 > security risks=20 > of devices that advertise themselves with LLDP, and that are=20 > on either a=20 > consumer LAN (assumed to generally have no other LLDP=20 > devices) or on a=20 > public non-LLDP network (such as a hotspot). If this security=20 > information=20 > exists, I'd appreciate being pointed to it. LLDP seems to be=20 > very much=20 > designed to operate in an enterprise environment, where network=20 > administrators exist, and where devices can generally trust=20 > each other.=20 > Is there some way for a device to determine whether the=20 > network it is in=20 > is truly LLDP-enabled, before it starts sending out LLDP messages? > LLDP-MED says that a wireless AP shouldn't broadcast LLDP-MED=20 > multicast=20 > messages received from a wireless device, to other wireless=20 > devices. But I=20 > assume that a non-LLDP-capable AP would mindlessly broadcast.=20 > What does=20 > this mean in a hotspot environment? Could someone else on the=20 > hotspot have=20 > a device that maliciously configures devices through LLDP and=20 > LLDP-MED? > Is it possible to write a trojan that would reside on a PC, and could=20 > maliciously configure devices in a non-LLDP-capable consumer LAN? > I really don't know enough. Would it be possible/appropriate=20 > for one of=20 > the LLDP proponents to provide verbiage for the "Security=20 > Considerations"=20 > section of phonebcp? I'm not convinced that the normative references=20 > adequately address security concerns of its use in these=20 > non-enterprise=20 > networks.=20 > When should a device attempt to get location through LLDP?=20 > Would it be=20 > appropriate for a device to only try it if DHCP and L7 fail? > Barbara=20 > ***** > The information transmitted is intended only for the person=20 > or entity to=20 > which it is addressed and may contain confidential,=20 > proprietary, and/or=20 > privileged material. Any review, retransmission,=20 > dissemination or other=20 > use of, or taking of any action in reliance upon this information by=20 > persons or entities other than the intended recipient is=20 > prohibited. If=20 > you received this in error, please contact the sender and delete the=20 > material from all computers. GA621 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jan 13 14:49:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5osq-0005VT-QH; Sat, 13 Jan 2007 14:49:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5osp-0005VO-J7 for ecrit@ietf.org; Sat, 13 Jan 2007 14:49:43 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5oso-00051f-AO for ecrit@ietf.org; Sat, 13 Jan 2007 14:49:43 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 13 Jan 2007 11:49:41 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l0DJnfTg020770 for ; Sat, 13 Jan 2007 11:49:41 -0800 Received: from [192.168.1.5] (sjc-vpn2-444.cisco.com [10.21.113.188]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0DJl9hu018475 for ; Sat, 13 Jan 2007 11:49:41 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <860B7041-E83D-4436-8085-47C13EE8305E@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Cullen Jennings Date: Sat, 13 Jan 2007 11:49:37 -0800 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=439; t=1168717781; x=1169581781; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20New=20RAI=20mailing=20list=20formed=20=20 |Sender:=20; bh=aYF9ifkEszPCZDECS+DKE+Xp7XzOBy9zCsTm4P/L9Jg=; b=BiyFw8Pl2pH4EYyRchWasU/LI7dH9nz5huXEorC1L/WXc9Zim+3zZIlSatCbwlcjXOhiXXKx pElSZ6Z5fbExO7ik36PFrz8Owtpzw5g9PgeIuO90kfqCUjFyS31H3mMy; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ecrit] New RAI mailing list formed X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Sorry for the many duplicate posts. A new mailing list for announcement and discussion of general topics of interest to RAI Area has been created. The list is rai@ietf.org You can subscribe at: https://www1.ietf.org/mailman/listinfo/rai Or by sending email with a body containing "subscribe" to rai- request@ietf.org Please do subscribe to it so you can find announcements for things like RAI BOFs. Thanks, Cullen & Jon _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 15 07:42:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6RAK-0008SR-JW; Mon, 15 Jan 2007 07:42:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6RAJ-0008SI-Re for ecrit@ietf.org; Mon, 15 Jan 2007 07:42:19 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H6RAI-0007Gz-9B for ecrit@ietf.org; Mon, 15 Jan 2007 07:42:19 -0500 Received: (qmail invoked by alias); 15 Jan 2007 12:42:17 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp010) with SMTP; 15 Jan 2007 13:42:17 +0100 X-Authenticated: #29516787 Message-ID: <45AB76A8.2070703@gmx.net> Date: Mon, 15 Jan 2007 13:42:16 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ecrit] Meeting Slots for IETF#68 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, we have requested 2 slots for the ECRIT working group meeting, namely * a 2 hour slot, and * a 1 hour slot The 1 hour slot will be used for the IEEE - ECRIT discussions. The 2 hour slot is reserved for our working group items. Since we want to finish all our charter items in the very near future we need to have some time to discuss the remaining open issues. A LoST draft update will be submitted soon. We plan to start a WGLC early next month based on the new draft. If you would like to discuss something else please let us know. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 17 16:07:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Hzg-0003ny-SE; Wed, 17 Jan 2007 16:06:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Hzg-0003nn-C8 for ecrit@ietf.org; Wed, 17 Jan 2007 16:06:52 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7Hzf-0006II-4F for ecrit@ietf.org; Wed, 17 Jan 2007 16:06:52 -0500 Received: (qmail invoked by alias); 17 Jan 2007 21:06:49 -0000 Received: from kone56.eurocity3.vip.fi (EHLO [212.149.115.57]) [212.149.115.57] by mail.gmx.net (mp019) with SMTP; 17 Jan 2007 22:06:49 +0100 X-Authenticated: #29516787 Message-ID: <45AE8FE7.5030309@gmx.net> Date: Wed, 17 Jan 2007 22:06:47 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Subject: [Ecrit] test X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org please ignore. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 17 16:20:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ID7-0007m7-QP; Wed, 17 Jan 2007 16:20:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ID5-0007lF-3O for ecrit@ietf.org; Wed, 17 Jan 2007 16:20:44 -0500 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7ID1-0007zR-OO for ecrit@ietf.org; Wed, 17 Jan 2007 16:20:43 -0500 Received: from [172.16.10.88] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 17 Jan 2007 15:51:47 -0500 id 01588460.45AE8C63.00000AD7 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Andrew Newton Date: Wed, 17 Jan 2007 15:52:20 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Ecrit] lost -03 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org All, At the urging of the co-chairs, the LoST author team just submitted -03 of draft-ietf-ecrit-lost. Until it hits the repository, you can view it here: txt version: http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf- ecrit-lost-03.txt html version: http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf- ecrit-lost-03.html You can find a side-by-side comparison of -02 and -03 here: longish url version: http://tools.ietf.org//rfcdiff?url1=http://www.tschofenig.priv.at/svn/ draft-ietf-ecrit-lost/draft-ietf-ecrit-lost-02.txt&url2=http:// www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit- lost-03.txt tinyurl verson: http://tinyurl.com/3x6yzk This version incorporates many, many of the changes talked about at the last IETF meeting and on this list since the publication of -02. At high level, they are: o New element which holds the important result data, and the ability to have multiple of elements. Not only does this organize the data better, it will better enable re-use of these items in other specs (such as the fg-to-fg syncing spec) and with future things like XML DSig. o As discussed in San Diego, the errors and warnings have been reworked to be much more compartmentalized. o Address validation is separated out. o Requests and responses now have a new element which contains the elements. This better enables loop detection. o The query has had the location version separated out into a new query called . o ... and much, much more. Be the first kid on the block to pull this draft down to your browser! -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 18 15:50:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7eCx-0007Tj-8T; Thu, 18 Jan 2007 15:50:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7eCw-0007T1-8C; Thu, 18 Jan 2007 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7eCv-00060O-Vo; Thu, 18 Jan 2007 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id E7EA932A6B; Thu, 18 Jan 2007 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H7eCv-0004PP-Qn; Thu, 18 Jan 2007 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 18 Jan 2007 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-lost-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : LoST: A Location-to-Service Translation Protocol Author(s) : T. Hardie, et al. Filename : draft-ietf-ecrit-lost-03.txt Pages : 70 Date : 2007-1-18 This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate PSAP for emergency services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-lost-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-lost-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-18103328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-lost-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-lost-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-18103328.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Fri Jan 19 10:14:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7vRn-0007Op-GG; Fri, 19 Jan 2007 10:14:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7vRm-0007O6-1Z for ecrit@ietf.org; Fri, 19 Jan 2007 10:14:30 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7vOf-0006RJ-C9 for ecrit@ietf.org; Fri, 19 Jan 2007 10:11:18 -0500 Received: (qmail invoked by alias); 19 Jan 2007 15:11:15 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp044) with SMTP; 19 Jan 2007 16:11:15 +0100 X-Authenticated: #29516787 Message-ID: <45B0DF93.6090100@gmx.net> Date: Fri, 19 Jan 2007 16:11:15 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ecrit] LoST Document getting close to WGLC X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, the LoST draft is getting close to start a WGLC. We would like to get some feedback whether the current version meets the expectation of the working group. The draft authors have worked hard to incorporate many review comments. Here is the document: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-03.txt Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jan 19 10:14:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7vRn-0007Of-Bk; Fri, 19 Jan 2007 10:14:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7vRl-0007O6-Vh for ecrit@ietf.org; Fri, 19 Jan 2007 10:14:29 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7vOp-0006Tz-6S for ecrit@ietf.org; Fri, 19 Jan 2007 10:11:28 -0500 Received: (qmail invoked by alias); 19 Jan 2007 15:11:26 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp015) with SMTP; 19 Jan 2007 16:11:26 +0100 X-Authenticated: #29516787 Message-ID: <45B0DF9C.8050904@gmx.net> Date: Fri, 19 Jan 2007 16:11:24 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: Jonathan Rosenberg , Tom-PT Taylor , steve.norreys@bt.com, shida@ntt-at.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ECRIT Subject: [Ecrit] LoST Expert Reviews Requested X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Jonathan, Hi Tom, Hi Steve, Hi Shida, at the last IETF ECRIT meeting you volunteered to make a review of the LoST document. Now, we believe that the document is getting ready for WGLC and your input is urgently needed. Here is the document: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-03.txt Please submit your review to the ECRIT mailing list asap. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jan 19 11:48:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7wuW-0006mr-NS; Fri, 19 Jan 2007 11:48:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7wuU-0006lu-Rm for ecrit@ietf.org; Fri, 19 Jan 2007 11:48:14 -0500 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7wuQ-0001mb-IK for ecrit@ietf.org; Fri, 19 Jan 2007 11:48:14 -0500 Received: from po2.bbn.com ([128.33.0.56]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1H7wuP-0001Mi-63; Fri, 19 Jan 2007 11:48:09 -0500 Received: from [127.0.0.1] (col-dhcp33-244-160.bbn.com [128.33.244.160]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l0JGm9w26676; Fri, 19 Jan 2007 11:48:09 -0500 (EST) Message-ID: <45B0F648.2050500@bbn.com> Date: Fri, 19 Jan 2007 11:48:08 -0500 From: Richard Barnes User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] LoST Document getting close to WGLC References: <45B0DF93.6090100@gmx.net> In-Reply-To: <45B0DF93.6090100@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Could someone say why LoST doesn't allow for provision of location information by reference? Not trying to imply that it should, just curious. Thanks, --Richard Hannes Tschofenig wrote: > Hi all, > > the LoST draft is getting close to start a WGLC. We would like to get > some feedback whether the current version meets the expectation of the > working group. > The draft authors have worked hard to incorporate many review comments. > > Here is the document: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-03.txt > > Ciao > Hannes > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jan 19 11:55:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7x18-0001eG-W9; Fri, 19 Jan 2007 11:55:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7x18-0001cj-Cc for ecrit@ietf.org; Fri, 19 Jan 2007 11:55:06 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7x12-0002Xf-Or for ecrit@ietf.org; Fri, 19 Jan 2007 11:55:06 -0500 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0JGsd21021120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 19 Jan 2007 11:54:40 -0500 (EST) In-Reply-To: <45B0F648.2050500@bbn.com> References: <45B0DF93.6090100@gmx.net> <45B0F648.2050500@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST Document getting close to WGLC Date: Fri, 19 Jan 2007 11:56:30 -0500 To: Richard Barnes X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org In the end, the LoST servers have to resolve it, since you can't map references. Thus, this simply delays the resolution and adds additional error conditions. Plus, multiple forest guide and authoritative LoST servers typically have to resolve a single query (e.g., country -> state -> county -> city), so you'd be going across the wide area network to whatever access network three or four times, each time worrying that there's some kind of access problem. This just increases the delay, since you'd suffer TCP (and possibly TLS) setup delay for each one of these. In other words, the likely consequence of doing this is far more work for the LoST servers, resulting in much lower query capacity, and higher delay for the querier. And yes, this has been discussed before, several times, so you can probably find additional discussion in the archives. Henning On Jan 19, 2007, at 11:48 AM, Richard Barnes wrote: > Could someone say why LoST doesn't allow for provision of location > information by reference? Not trying to imply that it should, just > curious. > > Thanks, > --Richard > > > > Hannes Tschofenig wrote: >> Hi all, >> the LoST draft is getting close to start a WGLC. We would like to >> get some feedback whether the current version meets the >> expectation of the working group. >> The draft authors have worked hard to incorporate many review >> comments. >> Here is the document: >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-03.txt >> Ciao >> Hannes >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jan 19 13:12:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7yDm-0002ix-UN; Fri, 19 Jan 2007 13:12:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7yDl-0002in-K1 for ecrit@ietf.org; Fri, 19 Jan 2007 13:12:13 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7yDe-00086f-NC for ecrit@ietf.org; Fri, 19 Jan 2007 13:12:13 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 19 Jan 2007 10:12:06 -0800 X-IronPort-AV: i="4.13,212,1167638400"; d="scan'208"; a="51169695:sNHT241115456" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0JIBx3b016299; Fri, 19 Jan 2007 13:11:59 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0JIBxOA006766; Fri, 19 Jan 2007 13:11:59 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 13:11:59 -0500 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 13:11:58 -0500 From: "Marc Linsner" To: "'Richard Barnes'" Subject: RE: [Ecrit] LoST Document getting close to WGLC Date: Fri, 19 Jan 2007 13:11:57 -0500 Message-ID: <001201c73bf5$4f569890$200d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <45B0F648.2050500@bbn.com> Thread-Index: Acc76a9ucCE8rMlaQYabU7JpNyMh0gACzkKg X-OriginalArrivalTime: 19 Jan 2007 18:11:58.0682 (UTC) FILETIME=[4F4CFBA0:01C73BF5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=314; t=1169230319; x=1170094319; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20LoST=20Document=20getting=20close=20to=20WG LC |Sender:=20 |To:=20=22'Richard=20Barnes'=22=20; bh=OWqfM+v+nKs14PBChPATycj+AEzaSsYon879AETHoIE=; b=WHga4380ZKi08sG42s0jhYRRy+J4J1kfncQYBJo8FdBK5c9JN3jmKUnhTHko2lwRt+oZEHBU Qy10EXG7Xh9NOkwMxksFjVwh3WYAuCcsgHztW4IJYvsrdQbKc0Rx0oIz; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Richard, > Could someone say why LoST doesn't allow for provision of > location information by reference? Not trying to imply that > it should, just curious. In the case of using a LbyR that points to the AOR presence service, how would one build the rules that authorize the de-reference? -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 22 16:13:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H96Tp-0000ZY-DD; Mon, 22 Jan 2007 16:13:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H96To-0000ZA-4V for ecrit@ietf.org; Mon, 22 Jan 2007 16:13:28 -0500 Received: from [2001:858:745:a0e4:20b:dbff:fe95:d83a] (helo=sil1.mah.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H96Tn-0007iS-O7 for ecrit@ietf.org; Mon, 22 Jan 2007 16:13:28 -0500 Received: from [86.59.64.45] (helo=[192.168.0.133]) by sil1.mah.priv.at with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1H96Tn-00021Z-0H for ecrit@ietf.org; Mon, 22 Jan 2007 22:13:27 +0100 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <5093833F-DECF-45C9-A4B0-5372CF464C2D@mah.priv.at> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Haberler Michael Date: Mon, 22 Jan 2007 22:13:19 +0100 X-Mailer: Apple Mail (2.752.3) X-SA-Exim-Connect-IP: 86.59.64.45 X-SA-Exim-Mail-From: ml1234@mah.priv.at X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on sil1.mah.priv.at X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 X-SA-Exim-Version: 4.2.1 (built Tue, 09 Jan 2007 17:23:22 +0000) X-SA-Exim-Scanned: Yes (on sil1.mah.priv.at) X-Spam-Score: -2.3 (--) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Ecrit] Service area format standards X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I am looking for references to standards, format descriptions or examples for PSAP service areas. background: Reporting service areas in a machine-readable format will be required by the regulator starting July 2007 for Austria, both from ESO's (as they want it) and by the network operators (as they actually do it). We are engaging in a data collection effort in Austria to collate the status quo since this will be the input to the LoST database. There is no "standard" in use (nobody asked for this so far) and we do expect a hodgepodge of different formats. So the first task might well be to moderate the process on the delivery format. We'd of course like them to deliver polygons plus attributes. I would assume that such data has been/is currently collected elsewhere and I rather go into the process with a reference to something in use rather than invent our own. thanks for any pointers -Michael sorry if this might be a bit OT for this list, but I would assume people in the know are cued in. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 24 10:03:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jel-0002Ah-21; Wed, 24 Jan 2007 10:03:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jej-000289-Bc for ecrit@ietf.org; Wed, 24 Jan 2007 10:03:21 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H9jeg-000302-Dr for ecrit@ietf.org; Wed, 24 Jan 2007 10:03:21 -0500 Received: (qmail invoked by alias); 24 Jan 2007 15:03:17 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp052) with SMTP; 24 Jan 2007 16:03:17 +0100 X-Authenticated: #29516787 Message-ID: <45B77533.2020608@gmx.net> Date: Wed, 24 Jan 2007 16:03:15 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Haberler Michael Subject: Re: [Ecrit] Service area format standards References: <5093833F-DECF-45C9-A4B0-5372CF464C2D@mah.priv.at> In-Reply-To: <5093833F-DECF-45C9-A4B0-5372CF464C2D@mah.priv.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Michael, Haberler Michael wrote: > > I am looking for references to standards, format descriptions or > examples for PSAP service areas. > > background: > > Reporting service areas in a machine-readable format will be required > by the regulator starting July 2007 for Austria, both from ESO's (as > they want it) and by the network operators (as they actually do it). That's very good. Service boundaries should be public in every country. > > We are engaging in a data collection effort in Austria to collate the > status quo since this will be the input to the LoST database. > > There is no "standard" in use (nobody asked for this so far) and we do > expect a hodgepodge of different formats. So the first task might well > be to moderate the process on the delivery format. We'd of course like > them to deliver polygons plus attributes. I would assume that such > data has been/is currently collected elsewhere and I rather go into > the process with a reference to something in use rather than invent > our own. Ideally, it would be good to have the collected data in the same format as described in Section 11 (Location Profiles) of http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-03.txt Since most of the PSAP boundary data is not available to the public I suspect that the formats vary substantially. Ciao Hannes > > thanks for any pointers > > -Michael > > sorry if this might be a bit OT for this list, but I would assume > people in the know are cued in. > > > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 24 10:54:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kRu-0000UN-Ah; Wed, 24 Jan 2007 10:54:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kRs-0000UE-KJ for ecrit@ietf.org; Wed, 24 Jan 2007 10:54:08 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9kRr-00044B-0j for ecrit@ietf.org; Wed, 24 Jan 2007 10:54:08 -0500 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0OFs060021081 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 24 Jan 2007 10:54:05 -0500 (EST) In-Reply-To: <45B77533.2020608@gmx.net> References: <5093833F-DECF-45C9-A4B0-5372CF464C2D@mah.priv.at> <45B77533.2020608@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2480FA42-782A-4054-B511-29B9DFF75243@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Service area format standards Date: Wed, 24 Jan 2007 10:54:00 -0500 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The ones I have seen are in ESRI shape files or similar semi-standard GIS formats. A common exchange format would be a good thing - maybe something for NENA to take on. > > Since most of the PSAP boundary data is not available to the public > I suspect that the formats vary substantially. > > Ciao > Hannes > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 24 17:44:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9qrE-00011w-Do; Wed, 24 Jan 2007 17:44:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9qrD-000117-5K for ecrit@ietf.org; Wed, 24 Jan 2007 17:44:43 -0500 Received: from smtp3.andrew.com ([198.17.217.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9qrB-0008Pn-QF for ecrit@ietf.org; Wed, 24 Jan 2007 17:44:43 -0500 X-SEF-Processed: 5_0_0_910__2007_01_24_16_49_42 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1 [10.3.20.66] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 24 Jan 2007 16:49:42 -0600 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 16:44:34 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Service area format standards Date: Wed, 24 Jan 2007 16:44:33 -0600 Message-ID: In-Reply-To: <2480FA42-782A-4054-B511-29B9DFF75243@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Service area format standards Thread-Index: Acc/z+dMWSw8y6waSw2Zc51Ua/t8lwAOMukQ From: "Winterbottom, James" To: "Henning Schulzrinne" , "Hannes Tschofenig" X-OriginalArrivalTime: 24 Jan 2007 22:44:34.0997 (UTC) FILETIME=[387D5650:01C74009] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org In NENA we are defining a file format based around the geoshapes polygon=0D= =0Aand the revised civic format as part of the i2.5 initiative. Henning, I=0D= =0Awould need to have another look at your forest guide interchange format=0D= =0Abut I suspect that it is not that different.=0D=0A=0D=0ACheers=0D=0AJame= s=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Henning Schulzrinne = [mailto:hgs@cs.columbia.edu]=0D=0A> Sent: Thursday, 25 January 2007 2:54 AM=0D= =0A> To: Hannes Tschofenig=0D=0A> Cc: ECRIT=0D=0A> Subject: Re: [Ecrit] Ser= vice area format standards=0D=0A>=20=0D=0A> The ones I have seen are in ESR= I shape files or similar semi-standard=0D=0A> GIS formats. A common exchang= e format would be a good thing - maybe=0D=0A> something for NENA to take on= =2E=0D=0A>=20=0D=0A> >=0D=0A>=20=0D=0A>=20=0D=0A> > Since most of the PSAP = boundary data is not available to the public=0D=0A> > I suspect that the fo= rmats vary substantially.=0D=0A> >=0D=0A> > Ciao=0D=0A> > Hannes=0D=0A> >=0D= =0A>=20=0D=0A>=20=0D=0A> _______________________________________________=0D= =0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/= mailman/listinfo/ecrit=0D=0A=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0AThis message i= s for the designated recipient only and may=0D=0Acontain privileged, propri= etary, or otherwise private information. =20=0D=0AIf you have received it i= n error, please notify the sender=0D=0Aimmediately and delete the original.= Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A-------------= ---------------------------------------------------------------------------= --------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 24 19:36:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9sbR-0001F5-Nf; Wed, 24 Jan 2007 19:36:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9sbQ-0001Bs-3L for ecrit@ietf.org; Wed, 24 Jan 2007 19:36:32 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9sbO-0001vy-RC for ecrit@ietf.org; Wed, 24 Jan 2007 19:36:32 -0500 Received: from [192.168.0.41] (pool-141-153-190-218.mad.east.verizon.net [141.153.190.218]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0P0aJQw022755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 24 Jan 2007 19:36:20 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Service area format standards Date: Wed, 24 Jan 2007 19:36:16 -0500 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org It would be nice to actually work on aligning them by more than coincidence, so that no lossy transformation is necessary (and preferably no transformation beyond just XML wrapping.) As you know, LoST and the element are likely to get frozen very soon, so there isn't a whole lot of time. On Jan 24, 2007, at 5:44 PM, Winterbottom, James wrote: > In NENA we are defining a file format based around the geoshapes > polygon > and the revised civic format as part of the i2.5 initiative. > Henning, I > would need to have another look at your forest guide interchange > format > but I suspect that it is not that different. > > Cheers > James > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Thursday, 25 January 2007 2:54 AM >> To: Hannes Tschofenig >> Cc: ECRIT >> Subject: Re: [Ecrit] Service area format standards >> >> The ones I have seen are in ESRI shape files or similar semi-standard >> GIS formats. A common exchange format would be a good thing - maybe >> something for NENA to take on. >> >>> >> >> >>> Since most of the PSAP boundary data is not available to the public >>> I suspect that the formats vary substantially. >>> >>> Ciao >>> Hannes >>> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > ---------------------------------------------------------------------- > -------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ---------------------------------------------------------------------- > -------------------------- > [mf2] > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 24 20:41:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9tcK-0003IO-4n; Wed, 24 Jan 2007 20:41:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9tcI-0003IE-6u for ecrit@ietf.org; Wed, 24 Jan 2007 20:41:30 -0500 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9tcF-0006AE-Uo for ecrit@ietf.org; Wed, 24 Jan 2007 20:41:30 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 24 Jan 2007 20:40:50 -0500 id 0158C328.45B80AA2.00005137 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Service area format standards Date: Wed, 24 Jan 2007 20:41:24 -0500 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Is the "geoshapes polygon" somehow different than the GML polygon? -andy On Jan 24, 2007, at 5:44 PM, Winterbottom, James wrote: > In NENA we are defining a file format based around the geoshapes > polygon > and the revised civic format as part of the i2.5 initiative. > Henning, I > would need to have another look at your forest guide interchange > format > but I suspect that it is not that different. > > Cheers > James > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Thursday, 25 January 2007 2:54 AM >> To: Hannes Tschofenig >> Cc: ECRIT >> Subject: Re: [Ecrit] Service area format standards >> >> The ones I have seen are in ESRI shape files or similar semi-standard >> GIS formats. A common exchange format would be a good thing - maybe >> something for NENA to take on. >> >>> >> >> >>> Since most of the PSAP boundary data is not available to the public >>> I suspect that the formats vary substantially. >>> >>> Ciao >>> Hannes >>> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > ---------------------------------------------------------------------- > -------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ---------------------------------------------------------------------- > -------------------------- > [mf2] > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 24 21:06:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9u0T-0000aA-2l; Wed, 24 Jan 2007 21:06:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9u0R-0000Wc-7P for ecrit@ietf.org; Wed, 24 Jan 2007 21:06:27 -0500 Received: from smtp3.andrew.com ([198.17.217.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9u0O-0003HS-Tc for ecrit@ietf.org; Wed, 24 Jan 2007 21:06:27 -0500 X-SEF-Processed: 5_0_0_910__2007_01_24_20_11_31 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1 [10.3.20.66] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 24 Jan 2007 20:11:30 -0600 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 20:06:23 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Service area format standards Date: Wed, 24 Jan 2007 20:06:21 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Service area format standards Thread-Index: AcdAIfBISukXjQuNQq6FqnoR6UZ/bQAA3U9w From: "Winterbottom, James" To: "Andrew Newton" X-OriginalArrivalTime: 25 Jan 2007 02:06:23.0297 (UTC) FILETIME=[69994B10:01C74025] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Nope=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Andrew Newt= on [mailto:andy@hxr.us]=0D=0A> Sent: Thursday, 25 January 2007 12:41 PM=0D=0A= > To: Winterbottom, James=0D=0A> Cc: Henning Schulzrinne; Hannes Tschofenig= ; ECRIT=0D=0A> Subject: Re: [Ecrit] Service area format standards=0D=0A> =0D= =0A> Is the "geoshapes polygon" somehow different than the GML polygon=3F=0D= =0A>=20=0D=0A> -andy=0D=0A>=20=0D=0A> On Jan 24, 2007, at 5:44 PM, Winterbo= ttom, James wrote:=0D=0A>=20=0D=0A> > In NENA we are defining a file format= based around the geoshapes=0D=0A> > polygon=0D=0A> > and the revised civic= format as part of the i2.5 initiative.=0D=0A> > Henning, I=0D=0A> > would = need to have another look at your forest guide interchange=0D=0A> > format=0D= =0A> > but I suspect that it is not that different.=0D=0A> >=0D=0A> > Cheer= s=0D=0A> > James=0D=0A> >=0D=0A> >> -----Original Message-----=0D=0A> >> Fr= om: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A> >> Sent: Thursd= ay, 25 January 2007 2:54 AM=0D=0A> >> To: Hannes Tschofenig=0D=0A> >> Cc: E= CRIT=0D=0A> >> Subject: Re: [Ecrit] Service area format standards=0D=0A> >>=0D= =0A> >> The ones I have seen are in ESRI shape files or similar=0D=0Asemi-s= tandard=0D=0A> >> GIS formats. A common exchange format would be a good thi= ng - maybe=0D=0A> >> something for NENA to take on.=0D=0A> >>=0D=0A> >>>=0D= =0A> >>=0D=0A> >>=0D=0A> >>> Since most of the PSAP boundary data is not av= ailable to the=0D=0Apublic=0D=0A> >>> I suspect that the formats vary subst= antially.=0D=0A> >>>=0D=0A> >>> Ciao=0D=0A> >>> Hannes=0D=0A> >>>=0D=0A> >>=0D= =0A> >>=0D=0A> >> _______________________________________________=0D=0A> >>= Ecrit mailing list=0D=0A> >> Ecrit@ietf.org=0D=0A> >> https://www1.ietf.or= g/mailman/listinfo/ecrit=0D=0A> >=0D=0A> >=0D=0A---------------------------= -------------------------------------------=0D=0A> > ----------------------= ----=0D=0A> > This message is for the designated recipient only and may=0D=0A= > > contain privileged, proprietary, or otherwise private information.=0D=0A= > > If you have received it in error, please notify the sender=0D=0A> > imm= ediately and delete the original. Any unauthorized use of=0D=0A> > this em= ail is prohibited.=0D=0A> >=0D=0A------------------------------------------= ----------------------------=0D=0A> > --------------------------=0D=0A> > [= mf2]=0D=0A> >=0D=0A> >=0D=0A> > ___________________________________________= ____=0D=0A> > Ecrit mailing list=0D=0A> > Ecrit@ietf.org=0D=0A> > https://w= ww1.ietf.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A=0D=0A------------------= ---------------------------------------------------------------------------= ---=0D=0AThis message is for the designated recipient only and may=0D=0Acon= tain privileged, proprietary, or otherwise private information. =20=0D=0AIf= you have received it in error, please notify the sender=0D=0Aimmediately a= nd delete the original. Any unauthorized use of=0D=0Athis email is prohibi= ted.=0D=0A-----------------------------------------------------------------= -------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 24 21:54:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ukt-00042r-Ob; Wed, 24 Jan 2007 21:54:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ukr-0003wS-PB for ecrit@ietf.org; Wed, 24 Jan 2007 21:54:25 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9ukq-0007Ui-EX for ecrit@ietf.org; Wed, 24 Jan 2007 21:54:25 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1H9ukZ-0008NJ-QZ; Wed, 24 Jan 2007 20:54:08 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Hannes Tschofenig'" Subject: RE: [Ecrit] Service area format standards Date: Wed, 24 Jan 2007 21:54:19 -0500 Message-ID: <00d901c7402c$1e1e9d50$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <2480FA42-782A-4054-B511-29B9DFF75243@cs.columbia.edu> Thread-Index: Acc/z+LY+BLUPkkYQ1G4p5ZpXA7PVwAPNE+w X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Indeed, the most common way to do this is a "shape file" which is ESRI specific, but most other GIS systems have translators. It is the defacto standard. Recently, there have been discussions in NENA and elsewhere about changing this to be a GML based format. Mark Berryman would have more info. Perhaps we can let them complete this work and then adopt it, but I see this question as addressing a small part of a larger problem of provisioning the LoST database. We probably need to get into an extended discussion of that, which might begin with a discussion of whether we want to standardize a provisioning interface at this time at all. It does seem to me that we don't know enough yet about how one wants to do this. For example, it is possible to construct a LoST server from a GIS system and not have any form of tabular data at all. In effect, for a civic query, you geocode it, and then do a boundary check against a set of polygons. Another way to construct the server is a have a hybrid of a set of polygons used for geo queries and a table based civic query that mirrors some existing databases. So, then we get to ask if the provisioning interface needs to accommodate both models or not. I'm inclined to let this area go without IETF attention for a while. LoST authoritative servers are local in nature. It would be reasonable to, for example, let NENA work on provisioning interfaces for North America. After we have some experience, we could revisit and see if having more global standards is useful. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, January 24, 2007 10:54 AM > To: Hannes Tschofenig > Cc: ECRIT > Subject: Re: [Ecrit] Service area format standards > > The ones I have seen are in ESRI shape files or similar semi-standard > GIS formats. A common exchange format would be a good thing - maybe > something for NENA to take on. > > > > > > > Since most of the PSAP boundary data is not available to the public > > I suspect that the formats vary substantially. > > > > Ciao > > Hannes > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 25 03:31:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA01A-0006cm-G8; Thu, 25 Jan 2007 03:31:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA019-0006cc-HA for ecrit@ietf.org; Thu, 25 Jan 2007 03:31:35 -0500 Received: from [86.59.12.252] (helo=sil1.mah.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA017-0005F5-M6 for ecrit@ietf.org; Thu, 25 Jan 2007 03:31:35 -0500 Received: from [86.59.64.45] (helo=[192.168.0.133]) by sil1.mah.priv.at with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1HA00s-0004zu-UZ; Thu, 25 Jan 2007 09:31:19 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6B6928DB-2394-49CA-A2AA-E5AE0F09DE26@mah.priv.at> Content-Transfer-Encoding: 7bit From: Haberler Michael Date: Thu, 25 Jan 2007 09:31:15 +0100 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-SA-Exim-Connect-IP: 86.59.64.45 X-SA-Exim-Mail-From: ml1234@mah.priv.at X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on sil1.mah.priv.at X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Subject: Re: [Ecrit] Service area format standards X-SA-Exim-Version: 4.2.1 (built Tue, 09 Jan 2007 17:23:22 +0000) X-SA-Exim-Scanned: Yes (on sil1.mah.priv.at) X-Spam-Score: 0.5 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Am 25.01.2007 um 01:36 schrieb Henning Schulzrinne: > It would be nice to actually work on aligning them by more than > coincidence, so that no lossy transformation is necessary (and > preferably no transformation beyond just XML wrapping.) that is in fact a key question, but I dont think it relates to the LoST shapes directly, at least how I envisage the process. Let me outline y current belief system... The relevant data will come from at least ten different sources (9 counties and state) in Austria, all with their GIS department or consultant on the side. We envisage that this data is collected, loaded into a single reference register, and this is the point where topological integrity is checked (I dont see these folks directly "provisioning" into the LoST database, I think a fail-stop process before that is needed). That would catch cases of overlap or non- coverage, or missing areas for a specific emergency call type (here this would be not just 911 but split into general emergency (112) and at least fire brigade, police and ambulance). The "delegation process" works as follows here: Emergency short codes are allocated by the regulator to either provinces or in case of police and 112 the ministery of interior affairs, defining resonsibility for that short code for a administrative region (example - 122 (fire) - allocated to province government of lower Austria). This allocation carries an obligation to publish the "desired routing" within that admin region (but see below). However, there was no format or indeed any requirements attached to that obligation. In terms of what is needed wrt the data format to enable such checks I came to the following requirements: (1) each entity needs to publish an overall "service area", against which the individual "service regions" can be checked. This service area would not be needed in the LoST server proper but it is needed for integrity. (2) all individual service regions must be fully contained (no overlap) in this service area. (3) the sum of service regions must cover all of the service area. (4) service areas shall not overlap and together fully cover the "national service area". (5) there should be an audit trail from each submitted region through the reference register into the LoST database polygon, AND BACK. These requirements arent LoST requirements, they are requirements on the data collection process (except for the traceback suggestion below). The "service area" would correspond to the area of responsibility for a region - typically a province or the state of Austria. However, there might be exceptions for that: there's at least one case where neighbouring provinces agreed to move service areas outside the province boundaries (in this case to arrange for responsibility of a mountain tunnel between two provinces fully to one county even if the province boundary is somewhere in the middle of the tunnel). I think such exceptions are possible at the national level as well. So that's why just referring to a standard shape "Province of XX" is not sufficient, although in many cases it will coincide. The "service region" of a specific service would be a polygon within a service area with responsibility for that service pegged to (and routed to) a single PSAP operator. That would be typically a county or commune for larger cities, but provinces might choose to just have a single service region within their service area as is the case in a single PSAP for a province. These objects would be part of the refernce data set submitted to the reference register. There would be over time re-submissions because of changes to this data sets. After submission integrity checks are performed and errors resolved between submitting entity and register operator. Thereafter the corrected data set is entered into the reference register, resulting in changes to the LoST database. There would be no transformation or data change between reference register and LoST server. That "forward process" would be easily trackable (logs, transaction numbers..). Beyond that I think it would be very helpful to easily trace *back* each polygon in the LoST server back to a particular data set submission of a particular entity. That suggests that each data set submission is tagged with a few parameters, like: responsible organisation (e.g. province), created-by (e.g. GIS department, GIS consultant..), validity periods and a sequence number. Each object would have a tag pointing to a particular submission. I'd suggest add a backtrackURI to the serviceBoundary object to ease the backtrack process. Note this points "out of LoST space" - it's not for syncing between servers or referring to a particular service boundary object within the LoST server - it refers to the data source and its history. Semantics in the context of the LoST response would be: "I tell you for this location the following PSAP is responsible, and this is because of the information ". If the question ever comes up why a LoST server actually gave a particular answer, that would enable easy tracking to the source of the data. A simple idea: it's a HTTP URI pointing to an application ontop of the reference register, displaying the data set and its origin, and maybe a map of the object. sorry if this is considered OT and I'm really treading thin air here for lack of references. -Michael > > As you know, LoST and the element are likely to get > frozen very soon, so there isn't a whole lot of time. > > On Jan 24, 2007, at 5:44 PM, Winterbottom, James wrote: > >> In NENA we are defining a file format based around the geoshapes >> polygon >> and the revised civic format as part of the i2.5 initiative. >> Henning, I >> would need to have another look at your forest guide interchange >> format >> but I suspect that it is not that different. >> >> Cheers >> James >> >>> -----Original Message----- >>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>> Sent: Thursday, 25 January 2007 2:54 AM >>> To: Hannes Tschofenig >>> Cc: ECRIT >>> Subject: Re: [Ecrit] Service area format standards >>> >>> The ones I have seen are in ESRI shape files or similar semi- >>> standard >>> GIS formats. A common exchange format would be a good thing - maybe >>> something for NENA to take on. >>> >>>> >>> >>> >>>> Since most of the PSAP boundary data is not available to the public >>>> I suspect that the formats vary substantially. >>>> >>>> Ciao >>>> Hannes >>>> >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >> >> --------------------------------------------------------------------- >> --------------------------- >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> --------------------------------------------------------------------- >> --------------------------- >> [mf2] >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 25 09:32:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA5dx-0003ZH-KV; Thu, 25 Jan 2007 09:32:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA5dv-0003Z1-TM for ecrit@ietf.org; Thu, 25 Jan 2007 09:31:59 -0500 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA5du-0000zA-DD for ecrit@ietf.org; Thu, 25 Jan 2007 09:31:59 -0500 Received: from [172.16.10.88] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 25 Jan 2007 09:31:16 -0500 id 0158846B.45B8BF34.00001C47 In-Reply-To: <6B6928DB-2394-49CA-A2AA-E5AE0F09DE26@mah.priv.at> References: <6B6928DB-2394-49CA-A2AA-E5AE0F09DE26@mah.priv.at> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Service area format standards Date: Thu, 25 Jan 2007 09:31:51 -0500 To: Haberler Michael X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Michael, I think you have actually outlined some good requirements. And there seems to be a lot of dovetailing into Henning's synchronization work and the whole concept of location profiles in LoST. Contrary to Brian's statement, I do think the IETF and ECRIT should take this on. First, there seems to be a lot of coordination that needs to go on (as I noted above). Second, NENA is not the right venue as it is U.S. centric. Such a standard would be used in many other places. -andy On Jan 25, 2007, at 3:31 AM, Haberler Michael wrote: > > Am 25.01.2007 um 01:36 schrieb Henning Schulzrinne: > >> It would be nice to actually work on aligning them by more than >> coincidence, so that no lossy transformation is necessary (and >> preferably no transformation beyond just XML wrapping.) > > that is in fact a key question, but I dont think it relates to the > LoST shapes directly, at least how I envisage the process. Let me > outline y current belief system... > > The relevant data will come from at least ten different sources (9 > counties and state) in Austria, all with their GIS department or > consultant on the side. We envisage that this data is collected, > loaded into a single reference register, and this is the point > where topological integrity is checked (I dont see these folks > directly "provisioning" into the LoST database, I think a fail-stop > process before that is needed). That would catch cases of overlap > or non-coverage, or missing areas for a specific emergency call > type (here this would be not just 911 but split into general > emergency (112) and at least fire brigade, police and ambulance). > > The "delegation process" works as follows here: > Emergency short codes are allocated by the regulator to either > provinces or in case of police and 112 the ministery of interior > affairs, defining resonsibility for that short code for a > administrative region (example - 122 (fire) - allocated to province > government of lower Austria). This allocation carries an obligation > to publish the "desired routing" within that admin region (but see > below). However, there was no format or indeed any requirements > attached to that obligation. > > In terms of what is needed wrt the data format to enable such > checks I came to the following requirements: > (1) each entity needs to publish an overall "service area", against > which the individual "service regions" can be checked. This service > area would not be needed in the LoST server proper but it is needed > for integrity. > (2) all individual service regions must be fully contained (no > overlap) in this service area. > (3) the sum of service regions must cover all of the service area. > (4) service areas shall not overlap and together fully cover the > "national service area". > (5) there should be an audit trail from each submitted region > through the reference register into the LoST database polygon, AND > BACK. > > These requirements arent LoST requirements, they are requirements > on the data collection process (except for the traceback suggestion > below). > > The "service area" would correspond to the area of responsibility > for a region - typically a province or the state of Austria. > However, there might be exceptions for that: there's at least one > case where neighbouring provinces agreed to move service areas > outside the province boundaries (in this case to arrange for > responsibility of a mountain tunnel between two provinces fully to > one county even if the province boundary is somewhere in the middle > of the tunnel). I think such exceptions are possible at the > national level as well. So that's why just referring to a standard > shape "Province of XX" is not sufficient, although in many cases it > will coincide. > > The "service region" of a specific service would be a polygon > within a service area with responsibility for that service pegged > to (and routed to) a single PSAP operator. That would be typically > a county or commune for larger cities, but provinces might choose > to just have a single service region within their service area as > is the case in a single PSAP for a province. > > These objects would be part of the refernce data set submitted to > the reference register. There would be over time re-submissions > because of changes to this data sets. After submission integrity > checks are performed and errors resolved between submitting entity > and register operator. Thereafter the corrected data set is entered > into the reference register, resulting in changes to the LoST > database. There would be no transformation or data change between > reference register and LoST server. That "forward process" would be > easily trackable (logs, transaction numbers..). > > Beyond that I think it would be very helpful to easily trace *back* > each polygon in the LoST server back to a particular data set > submission of a particular entity. That suggests that each data set > submission is tagged with a few parameters, like: responsible > organisation (e.g. province), created-by (e.g. GIS department, GIS > consultant..), validity periods and a sequence number. Each object > would have a tag pointing to a particular submission. I'd suggest > add a backtrackURI to the serviceBoundary object to ease the > backtrack process. Note this points "out of LoST space" - it's not > for syncing between servers or referring to a particular service > boundary object within the LoST server - it refers to the data > source and its history. > > Semantics in the context of the LoST response would be: "I tell you > for this location the following PSAP is responsible, and this is > because of the information here>". If the question ever comes up why a LoST server actually > gave a particular answer, that would enable easy tracking to the > source of the data. A simple idea: it's a HTTP URI pointing to an > application ontop of the reference register, displaying the data > set and its origin, and maybe a map of the object. > > sorry if this is considered OT and I'm really treading thin air > here for lack of references. > > -Michael > > > >> >> As you know, LoST and the element are likely to get >> frozen very soon, so there isn't a whole lot of time. >> >> On Jan 24, 2007, at 5:44 PM, Winterbottom, James wrote: >> >>> In NENA we are defining a file format based around the geoshapes >>> polygon >>> and the revised civic format as part of the i2.5 initiative. >>> Henning, I >>> would need to have another look at your forest guide interchange >>> format >>> but I suspect that it is not that different. >>> >>> Cheers >>> James >>> >>>> -----Original Message----- >>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>> Sent: Thursday, 25 January 2007 2:54 AM >>>> To: Hannes Tschofenig >>>> Cc: ECRIT >>>> Subject: Re: [Ecrit] Service area format standards >>>> >>>> The ones I have seen are in ESRI shape files or similar semi- >>>> standard >>>> GIS formats. A common exchange format would be a good thing - maybe >>>> something for NENA to take on. >>>> >>>>> >>>> >>>> >>>>> Since most of the PSAP boundary data is not available to the >>>>> public >>>>> I suspect that the formats vary substantially. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> -------------------------------------------------------------------- >>> ---------------------------- >>> This message is for the designated recipient only and may >>> contain privileged, proprietary, or otherwise private information. >>> If you have received it in error, please notify the sender >>> immediately and delete the original. Any unauthorized use of >>> this email is prohibited. >>> -------------------------------------------------------------------- >>> ---------------------------- >>> [mf2] >>> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 25 09:58:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA636-0003bo-MV; Thu, 25 Jan 2007 09:58:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA634-0003Yf-Qy for ecrit@ietf.org; Thu, 25 Jan 2007 09:57:58 -0500 Received: from [206.173.41.176] (helo=sea-mimesweep-1.telecomsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA633-0007Vf-FH for ecrit@ietf.org; Thu, 25 Jan 2007 09:57:58 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.5) with ESMTP id ; Thu, 25 Jan 2007 06:57:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Service area format standards Date: Thu, 25 Jan 2007 06:57:53 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657506A5C8AB@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <00d901c7402c$1e1e9d50$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Service area format standards Thread-Index: Acc/z+LY+BLUPkkYQ1G4p5ZpXA7PVwAPNE+wACDzQeA= References: <2480FA42-782A-4054-B511-29B9DFF75243@cs.columbia.edu> <00d901c7402c$1e1e9d50$640fa8c0@cis.neustar.com> From: "Roger Marshall" To: "Brian Rosen" , "Henning Schulzrinne" , "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org >On Wednesday, January 24, 2007 6:54 PM, Brian Rosen wrote: >I'm inclined to let this area go without IETF attention for a=20 >while. LoST authoritative servers are local in nature. It=20 >would be reasonable to, for example, let NENA work on=20 >provisioning interfaces for North America. After we have some=20 >experience, we could revisit and see if having more global=20 >standards is useful. I agree with Brian on this. This is already an area of interest within NENA, which will likely have some development work start in the (fairly) near future. Roger Marshall. The information contained in this message may be privileged and/or confiden= tial. If you are not the intended recipient, or responsible for delivering = this message to the intended recipient, any review, forwarding, disseminati= on, distribution or copying of this communication or any attachment(s) is s= trictly prohibited. If you have received this message in error, please so n= otify the sender immediately, and delete it and all attachments from your c= omputer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 25 10:10:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA6FX-0002nm-GZ; Thu, 25 Jan 2007 10:10:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA6FV-0002nc-R0 for ecrit@ietf.org; Thu, 25 Jan 2007 10:10:50 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA6FV-0002HL-92 for ecrit@ietf.org; Thu, 25 Jan 2007 10:10:49 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HA6FP-00006X-NC; Thu, 25 Jan 2007 09:10:44 -0600 From: "Brian Rosen" To: "'Andrew Newton'" , "'Haberler Michael'" Subject: RE: [Ecrit] Service area format standards Date: Thu, 25 Jan 2007 10:10:44 -0500 Message-ID: <02ca01c74092$fe6a9830$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcdAjZgdxMot8CbnRuyd/9z8770neQABNkfg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The thing is that the complexity of the data varies all over the map, with the U.S. (and Canada) generally considered as having the most complex data. U.S. data will be loaded on U.S. LoST servers. Having some regional variation on the provisioning side doesn't strike me as a very large problem, at least for now. Eventually, when we understand how we actually build and use these databases, standardizing the provisioning might be useful. The thing to keep in mind is that while a vendor of LoST servers would probably like a standardized provisioning interface, the users don't really care, because they only ever use ONE. They probably want to specify it to match their existing systems and practice. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Thursday, January 25, 2007 9:32 AM > To: Haberler Michael > Cc: ECRIT > Subject: Re: [Ecrit] Service area format standards > > Michael, > > I think you have actually outlined some good requirements. And there > seems to be a lot of dovetailing into Henning's synchronization work > and the whole concept of location profiles in LoST. > > Contrary to Brian's statement, I do think the IETF and ECRIT should > take this on. First, there seems to be a lot of coordination that > needs to go on (as I noted above). Second, NENA is not the right > venue as it is U.S. centric. Such a standard would be used in many > other places. > > -andy > > On Jan 25, 2007, at 3:31 AM, Haberler Michael wrote: > > > > > Am 25.01.2007 um 01:36 schrieb Henning Schulzrinne: > > > >> It would be nice to actually work on aligning them by more than > >> coincidence, so that no lossy transformation is necessary (and > >> preferably no transformation beyond just XML wrapping.) > > > > that is in fact a key question, but I dont think it relates to the > > LoST shapes directly, at least how I envisage the process. Let me > > outline y current belief system... > > > > The relevant data will come from at least ten different sources (9 > > counties and state) in Austria, all with their GIS department or > > consultant on the side. We envisage that this data is collected, > > loaded into a single reference register, and this is the point > > where topological integrity is checked (I dont see these folks > > directly "provisioning" into the LoST database, I think a fail-stop > > process before that is needed). That would catch cases of overlap > > or non-coverage, or missing areas for a specific emergency call > > type (here this would be not just 911 but split into general > > emergency (112) and at least fire brigade, police and ambulance). > > > > The "delegation process" works as follows here: > > Emergency short codes are allocated by the regulator to either > > provinces or in case of police and 112 the ministery of interior > > affairs, defining resonsibility for that short code for a > > administrative region (example - 122 (fire) - allocated to province > > government of lower Austria). This allocation carries an obligation > > to publish the "desired routing" within that admin region (but see > > below). However, there was no format or indeed any requirements > > attached to that obligation. > > > > In terms of what is needed wrt the data format to enable such > > checks I came to the following requirements: > > (1) each entity needs to publish an overall "service area", against > > which the individual "service regions" can be checked. This service > > area would not be needed in the LoST server proper but it is needed > > for integrity. > > (2) all individual service regions must be fully contained (no > > overlap) in this service area. > > (3) the sum of service regions must cover all of the service area. > > (4) service areas shall not overlap and together fully cover the > > "national service area". > > (5) there should be an audit trail from each submitted region > > through the reference register into the LoST database polygon, AND > > BACK. > > > > These requirements arent LoST requirements, they are requirements > > on the data collection process (except for the traceback suggestion > > below). > > > > The "service area" would correspond to the area of responsibility > > for a region - typically a province or the state of Austria. > > However, there might be exceptions for that: there's at least one > > case where neighbouring provinces agreed to move service areas > > outside the province boundaries (in this case to arrange for > > responsibility of a mountain tunnel between two provinces fully to > > one county even if the province boundary is somewhere in the middle > > of the tunnel). I think such exceptions are possible at the > > national level as well. So that's why just referring to a standard > > shape "Province of XX" is not sufficient, although in many cases it > > will coincide. > > > > The "service region" of a specific service would be a polygon > > within a service area with responsibility for that service pegged > > to (and routed to) a single PSAP operator. That would be typically > > a county or commune for larger cities, but provinces might choose > > to just have a single service region within their service area as > > is the case in a single PSAP for a province. > > > > These objects would be part of the refernce data set submitted to > > the reference register. There would be over time re-submissions > > because of changes to this data sets. After submission integrity > > checks are performed and errors resolved between submitting entity > > and register operator. Thereafter the corrected data set is entered > > into the reference register, resulting in changes to the LoST > > database. There would be no transformation or data change between > > reference register and LoST server. That "forward process" would be > > easily trackable (logs, transaction numbers..). > > > > Beyond that I think it would be very helpful to easily trace *back* > > each polygon in the LoST server back to a particular data set > > submission of a particular entity. That suggests that each data set > > submission is tagged with a few parameters, like: responsible > > organisation (e.g. province), created-by (e.g. GIS department, GIS > > consultant..), validity periods and a sequence number. Each object > > would have a tag pointing to a particular submission. I'd suggest > > add a backtrackURI to the serviceBoundary object to ease the > > backtrack process. Note this points "out of LoST space" - it's not > > for syncing between servers or referring to a particular service > > boundary object within the LoST server - it refers to the data > > source and its history. > > > > Semantics in the context of the LoST response would be: "I tell you > > for this location the following PSAP is responsible, and this is > > because of the information > here>". If the question ever comes up why a LoST server actually > > gave a particular answer, that would enable easy tracking to the > > source of the data. A simple idea: it's a HTTP URI pointing to an > > application ontop of the reference register, displaying the data > > set and its origin, and maybe a map of the object. > > > > sorry if this is considered OT and I'm really treading thin air > > here for lack of references. > > > > -Michael > > > > > > > >> > >> As you know, LoST and the element are likely to get > >> frozen very soon, so there isn't a whole lot of time. > >> > >> On Jan 24, 2007, at 5:44 PM, Winterbottom, James wrote: > >> > >>> In NENA we are defining a file format based around the geoshapes > >>> polygon > >>> and the revised civic format as part of the i2.5 initiative. > >>> Henning, I > >>> would need to have another look at your forest guide interchange > >>> format > >>> but I suspect that it is not that different. > >>> > >>> Cheers > >>> James > >>> > >>>> -----Original Message----- > >>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>>> Sent: Thursday, 25 January 2007 2:54 AM > >>>> To: Hannes Tschofenig > >>>> Cc: ECRIT > >>>> Subject: Re: [Ecrit] Service area format standards > >>>> > >>>> The ones I have seen are in ESRI shape files or similar semi- > >>>> standard > >>>> GIS formats. A common exchange format would be a good thing - maybe > >>>> something for NENA to take on. > >>>> > >>>>> > >>>> > >>>> > >>>>> Since most of the PSAP boundary data is not available to the > >>>>> public > >>>>> I suspect that the formats vary substantially. > >>>>> > >>>>> Ciao > >>>>> Hannes > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>> > >>> -------------------------------------------------------------------- > >>> ---------------------------- > >>> This message is for the designated recipient only and may > >>> contain privileged, proprietary, or otherwise private information. > >>> If you have received it in error, please notify the sender > >>> immediately and delete the original. Any unauthorized use of > >>> this email is prohibited. > >>> -------------------------------------------------------------------- > >>> ---------------------------- > >>> [mf2] > >>> > >> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 25 10:40:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA6hi-0003nr-8w; Thu, 25 Jan 2007 10:39:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA6hh-0003mV-Fs for ecrit@ietf.org; Thu, 25 Jan 2007 10:39:57 -0500 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA6gw-0007Jk-DN for ecrit@ietf.org; Thu, 25 Jan 2007 10:39:57 -0500 Received: from [172.16.10.88] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 25 Jan 2007 10:38:28 -0500 id 01588479.45B8CEF4.00002F44 In-Reply-To: <02ca01c74092$fe6a9830$640fa8c0@cis.neustar.com> References: <02ca01c74092$fe6a9830$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Service area format standards Date: Thu, 25 Jan 2007 10:39:00 -0500 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jan 25, 2007, at 10:10 AM, Brian Rosen wrote: > The thing is that the complexity of the data varies all over the > map, with > the U.S. (and Canada) generally considered as having the most > complex data. > U.S. data will be loaded on U.S. LoST servers. Having some regional > variation on the provisioning side doesn't strike me as a very large > problem, at least for now. Eventually, when we understand how we > actually > build and use these databases, standardizing the provisioning might be > useful. Again, this is a very U.S. centric view. I'll agree the U.S. seems to have a higher quantity of service boundaries, but the complexity of the service boundaries themselves are not specific to the U.S. There are certainly countries with more complex civic addresses, and there is nothing special about the terrestrial makeup of America nor the sky above it that requires the U.S. to have geodetic shapes more complex than anyplace else. As James pointed out, they are using GML polygons and GEOPRIV revised-civic. Just what is U.S. specific about that? > The thing to keep in mind is that while a vendor of LoST servers would > probably like a standardized provisioning interface, the users > don't really > care, because they only ever use ONE. They probably want to > specify it to > match their existing systems and practice. Given all the arguments regarding the need for a standard to synchronize authoritative LoST servers and forrest guides, I'm perplexed why you think the same does not carry over to the provisioning. After all, it is much like the CD-ROM form of wire synchronization. It would certainly be beneficial if an Austrian PSAP could purchase software built by an American vendor (or vice- versa) and expect compatibility. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 25 10:50:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA6rD-0003l8-0r; Thu, 25 Jan 2007 10:49:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA6rB-0003ie-Vu for ecrit@ietf.org; Thu, 25 Jan 2007 10:49:45 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA6r7-00016B-Ia for ecrit@ietf.org; Thu, 25 Jan 2007 10:49:45 -0500 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0PFnQFi015025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 25 Jan 2007 10:49:26 -0500 (EST) In-Reply-To: <02ca01c74092$fe6a9830$640fa8c0@cis.neustar.com> References: <02ca01c74092$fe6a9830$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Service area format standards Date: Thu, 25 Jan 2007 10:49:27 -0500 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This is not quite true. The forest guides need to have a uniform interface and data format, as they are international. Also, as for DNS, we want replication, preferably across different vendors (to avoid a single vulnerability taking down the whole system, say). I'm also a bit lost by the "complexity varies all over the map". Are they using shapes other than polygons? Frankly, I'm not convinced that this is rocket science and that we need to make this terribly complicated. On Jan 25, 2007, at 10:10 AM, Brian Rosen wrote: > The thing is that the complexity of the data varies all over the > map, with > the U.S. (and Canada) generally considered as having the most > complex data. > U.S. data will be loaded on U.S. LoST servers. Having some regional > variation on the provisioning side doesn't strike me as a very large > problem, at least for now. Eventually, when we understand how we > actually > build and use these databases, standardizing the provisioning might be > useful. > > The thing to keep in mind is that while a vendor of LoST servers would > probably like a standardized provisioning interface, the users > don't really > care, because they only ever use ONE. They probably want to > specify it to > match their existing systems and practice. > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 25 10:55:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA6wr-0006dU-DC; Thu, 25 Jan 2007 10:55:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA6wn-0006dK-HV for ecrit@ietf.org; Thu, 25 Jan 2007 10:55:35 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA6wj-00022z-7g for ecrit@ietf.org; Thu, 25 Jan 2007 10:55:33 -0500 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0PFtRkK016630 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 25 Jan 2007 10:55:28 -0500 (EST) In-Reply-To: References: <02ca01c74092$fe6a9830$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4C67F2D8-3441-4D9C-9910-34B273DC6F0D@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Service area format standards Date: Thu, 25 Jan 2007 10:55:30 -0500 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > As a somewhat related example, it has been extremely useful to have a single "provisioning" interface for DNS servers, zone files, even though there are other, proprietary database backends that might be more efficient. The same is true for LDAP (LDIF). I agree with Andrew; putting up "this is really, really complicated and mere mortals can't understand it, only special wizards that have at least a NEWT" doesn't seem all that helpful. > Given all the arguments regarding the need for a standard to > synchronize authoritative LoST servers and forrest guides, I'm > perplexed why you think the same does not carry over to the > provisioning. After all, it is much like the CD-ROM form of wire > synchronization. It would certainly be beneficial if an Austrian > PSAP could purchase software built by an American vendor (or vice- > versa) and expect compatibility. > > -andy > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 25 11:15:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7Fc-0001C7-Bt; Thu, 25 Jan 2007 11:15:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7Fb-00019x-68 for ecrit@ietf.org; Thu, 25 Jan 2007 11:14:59 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA7FZ-0006PJ-SB for ecrit@ietf.org; Thu, 25 Jan 2007 11:14:59 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HA7FU-0006Id-7l; Thu, 25 Jan 2007 10:14:52 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] Service area format standards Date: Thu, 25 Jan 2007 11:14:54 -0500 Message-ID: <02db01c7409b$f4b4d9f0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcdAmGePI7M1mFCORGm+97iCTGzWEgAAMu2g X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I agree that the forest guides need a standard interface and data format. I don't think of that as the same as provisioning the LoST data itself. Agree that we want replication, but I don't think the provisioning interface matters for that (what I want is automatic replication, and I think there are operations defined in LoST to facilitate that, understanding that the actual data sent in the "zone transfer equivalent" has the issues we are talking about). The complexity DOES vary all over the place because of the level of detail in the civic data. In most countries, there is very little detail (if you know the city name, you know the PSAP. In some countries it's more coarse than that). In the U.S., you have to know the number on the street to determine the PSAP, and you better match the street name, pre/post directional, prefix, suffix, etc. If you are hot to do an IETF standardized provisioning interface, let's start with how you define street addresses. Since I advocate doing this as a GIS system, and not as tabular data, I want a GIS layer with street centerlines, an option for actual streets (correct placement and width), a layer for (at least) street addresses as point plots, options for parcels. For both points and parcels there are some provisioned settings that deal with edge cases. For example, in some jurisdictions, there is an algorithm for house numbers (go up by 1 every 50 feet for example), and they want to allow addresses that aren't actually provided as points on the centerline data to be valid using the algorithm. I'm not really up on how they do the equivalent for Japanese and Chinese addresses; it's more complex in some ways. The actual boundaries for each service is a set of polygons (and it is a set, not just one), which we can probably get a simple GML spec for pretty easily. Bring out your GIS experts, we have a lot to learn before we specify this. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, January 25, 2007 10:49 AM > To: Brian Rosen > Cc: 'Andrew Newton'; 'Haberler Michael'; 'ECRIT' > Subject: Re: [Ecrit] Service area format standards > > This is not quite true. The forest guides need to have a uniform > interface and data format, as they are international. > > Also, as for DNS, we want replication, preferably across different > vendors (to avoid a single vulnerability taking down the whole > system, say). > > I'm also a bit lost by the "complexity varies all over the map". Are > they using shapes other than polygons? Frankly, I'm not convinced > that this is rocket science and that we need to make this terribly > complicated. > > On Jan 25, 2007, at 10:10 AM, Brian Rosen wrote: > > > The thing is that the complexity of the data varies all over the > > map, with > > the U.S. (and Canada) generally considered as having the most > > complex data. > > U.S. data will be loaded on U.S. LoST servers. Having some regional > > variation on the provisioning side doesn't strike me as a very large > > problem, at least for now. Eventually, when we understand how we > > actually > > build and use these databases, standardizing the provisioning might be > > useful. > > > > The thing to keep in mind is that while a vendor of LoST servers would > > probably like a standardized provisioning interface, the users > > don't really > > care, because they only ever use ONE. They probably want to > > specify it to > > match their existing systems and practice. > > > > Brian > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 25 11:24:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7OO-00005M-0z; Thu, 25 Jan 2007 11:24:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7OM-0008W3-O2 for ecrit@ietf.org; Thu, 25 Jan 2007 11:24:02 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA7OL-0000dW-GU for ecrit@ietf.org; Thu, 25 Jan 2007 11:24:02 -0500 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0PGNnMs006409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 25 Jan 2007 11:23:49 -0500 (EST) In-Reply-To: <02db01c7409b$f4b4d9f0$640fa8c0@cis.neustar.com> References: <02db01c7409b$f4b4d9f0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3BFB1257-D365-45E8-9DAF-2C1A7640552F@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Service area format standards Date: Thu, 25 Jan 2007 11:23:51 -0500 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org We are talking about service boundaries here, not geocoding software. Thus, I don't see the need for more than an enumeration of civic street-level addresses (which presumably fit into the PIDF-LO mold or else we have other problems) and polygons describing the area. The former is necessary for civic address validation, the latter for boundary matching. I don't see why I would care about parcel boundaries unless I do geocoding of some sort. On Jan 25, 2007, at 11:14 AM, Brian Rosen wrote: > I agree that the forest guides need a standard interface and data > format. I > don't think of that as the same as provisioning the LoST data > itself. Agree > that we want replication, but I don't think the provisioning interface > matters for that (what I want is automatic replication, and I think > there > are operations defined in LoST to facilitate that, understanding > that the > actual data sent in the "zone transfer equivalent" has the issues > we are > talking about). > > The complexity DOES vary all over the place because of the level of > detail > in the civic data. In most countries, there is very little detail > (if you > know the city name, you know the PSAP. In some countries it's more > coarse > than that). In the U.S., you have to know the number on the street to > determine the PSAP, and you better match the street name, pre/post > directional, prefix, suffix, etc. > > If you are hot to do an IETF standardized provisioning interface, > let's > start with how you define street addresses. Since I advocate doing > this as > a GIS system, and not as tabular data, I want a GIS layer with street > centerlines, an option for actual streets (correct placement and > width), a > layer for (at least) street addresses as point plots, options for > parcels. > For both points and parcels there are some provisioned settings > that deal > with edge cases. For example, in some jurisdictions, there is an > algorithm > for house numbers (go up by 1 every 50 feet for example), and they > want to > allow addresses that aren't actually provided as points on the > centerline > data to be valid using the algorithm. I'm not really up on how > they do the > equivalent for Japanese and Chinese addresses; it's more complex in > some > ways. > > The actual boundaries for each service is a set of polygons (and it > is a > set, not just one), which we can probably get a simple GML spec for > pretty > easily. > > Bring out your GIS experts, we have a lot to learn before we > specify this. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 25 11:37:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7aq-0006Uw-4F; Thu, 25 Jan 2007 11:36:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7ap-0006Ur-8f for ecrit@ietf.org; Thu, 25 Jan 2007 11:36:55 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA7an-0002qm-RO for ecrit@ietf.org; Thu, 25 Jan 2007 11:36:55 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0PGap017855; Thu, 25 Jan 2007 11:36:51 -0500 (EST) Received: from [47.130.18.23] ([47.130.18.23] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 11:36:51 -0500 Message-ID: <45B8DC8D.2060405@nortel.com> Date: Thu, 25 Jan 2007 11:36:29 -0500 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Service area format standards References: <02db01c7409b$f4b4d9f0$640fa8c0@cis.neustar.com> <3BFB1257-D365-45E8-9DAF-2C1A7640552F@cs.columbia.edu> In-Reply-To: <3BFB1257-D365-45E8-9DAF-2C1A7640552F@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jan 2007 16:36:51.0127 (UTC) FILETIME=[03CFB470:01C7409F] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'll just toss my limited knowledge of Japanese civic addresses into the pot: street addresses are in random order as far as an outsider is concerned. You find your way to a particular address by asking or by finding the neighbourhood map. I suppose serving areas are defined by neighbourhood rather than street address, because of this. The point being that provisioning and validation procedures may well be country-specific. Henning Schulzrinne wrote: > We are talking about service boundaries here, not geocoding software. > Thus, I don't see the need for more than an enumeration of civic > street-level addresses (which presumably fit into the PIDF-LO mold or > else we have other problems) and polygons describing the area. The > former is necessary for civic address validation, the latter for > boundary matching. > > I don't see why I would care about parcel boundaries unless I do > geocoding of some sort. > > On Jan 25, 2007, at 11:14 AM, Brian Rosen wrote: > >> I agree that the forest guides need a standard interface and data >> format. I >> don't think of that as the same as provisioning the LoST data >> itself. Agree >> that we want replication, but I don't think the provisioning interface >> matters for that (what I want is automatic replication, and I think >> there >> are operations defined in LoST to facilitate that, understanding >> that the >> actual data sent in the "zone transfer equivalent" has the issues >> we are >> talking about). >> >> The complexity DOES vary all over the place because of the level of >> detail >> in the civic data. In most countries, there is very little detail >> (if you >> know the city name, you know the PSAP. In some countries it's more >> coarse >> than that). In the U.S., you have to know the number on the street to >> determine the PSAP, and you better match the street name, pre/post >> directional, prefix, suffix, etc. >> >> If you are hot to do an IETF standardized provisioning interface, >> let's >> start with how you define street addresses. Since I advocate doing >> this as >> a GIS system, and not as tabular data, I want a GIS layer with street >> centerlines, an option for actual streets (correct placement and >> width), a >> layer for (at least) street addresses as point plots, options for >> parcels. >> For both points and parcels there are some provisioned settings >> that deal >> with edge cases. For example, in some jurisdictions, there is an >> algorithm >> for house numbers (go up by 1 every 50 feet for example), and they >> want to >> allow addresses that aren't actually provided as points on the >> centerline >> data to be valid using the algorithm. I'm not really up on how >> they do the >> equivalent for Japanese and Chinese addresses; it's more complex in >> some >> ways. >> >> The actual boundaries for each service is a set of polygons (and it >> is a >> set, not just one), which we can probably get a simple GML spec for >> pretty >> easily. >> >> Bring out your GIS experts, we have a lot to learn before we >> specify this. >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 25 11:41:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7eU-000144-Er; Thu, 25 Jan 2007 11:40:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7eT-00013z-8k for ecrit@ietf.org; Thu, 25 Jan 2007 11:40:41 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA7eR-0003i9-16 for ecrit@ietf.org; Thu, 25 Jan 2007 11:40:41 -0500 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0PGeV5a029996 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 25 Jan 2007 11:40:32 -0500 (EST) In-Reply-To: <45B8DC8D.2060405@nortel.com> References: <02db01c7409b$f4b4d9f0$640fa8c0@cis.neustar.com> <3BFB1257-D365-45E8-9DAF-2C1A7640552F@cs.columbia.edu> <45B8DC8D.2060405@nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <740D51B1-1364-43FD-9B76-6ABED8195C1C@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Service area format standards Date: Thu, 25 Jan 2007 11:40:33 -0500 To: "Tom-PT Taylor" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org True, but I'm not sure this is particularly relevant here. An enumeration of each street address would allow full validation (unlike the even/odd/range validation today) and easily accommodate random assignment of house numbers to service areas. This is why the most recent version of the LoST draft allows multiple civic addresses as part of the service boundary. On Jan 25, 2007, at 11:36 AM, Tom-PT Taylor wrote: > I'll just toss my limited knowledge of Japanese civic addresses > into the pot: street addresses are in random order as far as an > outsider is concerned. You find your way to a particular address by > asking or by finding the neighbourhood map. I suppose serving areas > are defined by neighbourhood rather than street address, because of > this. > > The point being that provisioning and validation procedures may > well be country-specific. > With the generalization noted above, the mechanism can be generic. Hennin _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 25 11:53:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7ql-0000l0-QR; Thu, 25 Jan 2007 11:53:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7qk-0000ku-PK for ecrit@ietf.org; Thu, 25 Jan 2007 11:53:22 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA7qi-00062S-Cp for ecrit@ietf.org; Thu, 25 Jan 2007 11:53:22 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HA7qc-0006nW-Bz; Thu, 25 Jan 2007 10:53:14 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] Service area format standards Date: Thu, 25 Jan 2007 11:53:16 -0500 Message-ID: <02e301c740a1$51206ba0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <3BFB1257-D365-45E8-9DAF-2C1A7640552F@cs.columbia.edu> Thread-Index: AcdAnTQCdpcb3mnJRGutESeVsj2M6AAAiO2Q X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org What good would it do to standardize the service boundary provisioning without standardizing the civic address data provisioning? If you want to do that and stop there, then I'm more amenable, because indeed with just that, there is more agreement on what is needed. Yes, I think if you have accurate data, which a PSAP can have, then you can geocode to route a civic address. This only works if the geocode data is accurate, and any conversions are done with the same data. That can be the case here. By using geocoding, you eliminate the issue of defining how you determine the service boundaries in civic form. This is the direction we are heading in NENA, and it's the general direction for all of these kinds of operations. Geocode the civic, and use polygon boundaries. You really need parcel data to do this well, but they usually can choose the points that represent the parcels well enough to make the polygons very accurate. "Enumeration" of civic addresses is the geocode data for those addresses. Now if you don't use geocoding for civic addresses, then you are back to only having a solution for provisioning service boundaries for geo locations: you can't use the polygons to determine service boundaries for civic addresses without geocoding. You could enumerate civic addresses and tag each address with the services. That is what you would do if you stuck to tabular entry of civic. I think we should allow such a mechanism, but I want the geocode option, because it's the way these things are evolving towards. The problem with that mechanism is that it makes the likelihood of a discrepancy in the service boundaries between the geo and the civic higher, and requires a much more complex data maintenance process to avoid such problems. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, January 25, 2007 11:24 AM > To: Brian Rosen > Cc: 'Andrew Newton'; 'Haberler Michael'; 'ECRIT' > Subject: Re: [Ecrit] Service area format standards > > We are talking about service boundaries here, not geocoding software. > Thus, I don't see the need for more than an enumeration of civic > street-level addresses (which presumably fit into the PIDF-LO mold or > else we have other problems) and polygons describing the area. The > former is necessary for civic address validation, the latter for > boundary matching. > > I don't see why I would care about parcel boundaries unless I do > geocoding of some sort. > > On Jan 25, 2007, at 11:14 AM, Brian Rosen wrote: > > > I agree that the forest guides need a standard interface and data > > format. I > > don't think of that as the same as provisioning the LoST data > > itself. Agree > > that we want replication, but I don't think the provisioning interface > > matters for that (what I want is automatic replication, and I think > > there > > are operations defined in LoST to facilitate that, understanding > > that the > > actual data sent in the "zone transfer equivalent" has the issues > > we are > > talking about). > > > > The complexity DOES vary all over the place because of the level of > > detail > > in the civic data. In most countries, there is very little detail > > (if you > > know the city name, you know the PSAP. In some countries it's more > > coarse > > than that). In the U.S., you have to know the number on the street to > > determine the PSAP, and you better match the street name, pre/post > > directional, prefix, suffix, etc. > > > > If you are hot to do an IETF standardized provisioning interface, > > let's > > start with how you define street addresses. Since I advocate doing > > this as > > a GIS system, and not as tabular data, I want a GIS layer with street > > centerlines, an option for actual streets (correct placement and > > width), a > > layer for (at least) street addresses as point plots, options for > > parcels. > > For both points and parcels there are some provisioned settings > > that deal > > with edge cases. For example, in some jurisdictions, there is an > > algorithm > > for house numbers (go up by 1 every 50 feet for example), and they > > want to > > allow addresses that aren't actually provided as points on the > > centerline > > data to be valid using the algorithm. I'm not really up on how > > they do the > > equivalent for Japanese and Chinese addresses; it's more complex in > > some > > ways. > > > > The actual boundaries for each service is a set of polygons (and it > > is a > > set, not just one), which we can probably get a simple GML spec for > > pretty > > easily. > > > > Bring out your GIS experts, we have a lot to learn before we > > specify this. > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 25 11:54:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7rp-00036c-0H; Thu, 25 Jan 2007 11:54:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7ro-00036W-0r for ecrit@ietf.org; Thu, 25 Jan 2007 11:54:28 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HA7rl-0006FS-Qg for ecrit@ietf.org; Thu, 25 Jan 2007 11:54:27 -0500 Received: (qmail invoked by alias); 25 Jan 2007 16:54:23 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp017) with SMTP; 25 Jan 2007 17:54:23 +0100 X-Authenticated: #29516787 Message-ID: <45B8E0BD.8000800@gmx.net> Date: Thu, 25 Jan 2007 17:54:21 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Tom-PT Taylor Subject: Re: [Ecrit] Service area format standards References: <02db01c7409b$f4b4d9f0$640fa8c0@cis.neustar.com> <3BFB1257-D365-45E8-9DAF-2C1A7640552F@cs.columbia.edu> <45B8DC8D.2060405@nortel.com> In-Reply-To: <45B8DC8D.2060405@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The process might be country specific. The the format of the collected data could be standardized to simplify the provisioning of the LoST database. Currently, you have to go through different data conversion steps and you might reduce the quality of the previously collected data. Ciao Hannes Tom-PT Taylor wrote: > I'll just toss my limited knowledge of Japanese civic addresses into > the pot: street addresses are in random order as far as an outsider is > concerned. You find your way to a particular address by asking or by > finding the neighbourhood map. I suppose serving areas are defined by > neighbourhood rather than street address, because of this. > > The point being that provisioning and validation procedures may well > be country-specific. > > Henning Schulzrinne wrote: >> We are talking about service boundaries here, not geocoding >> software. Thus, I don't see the need for more than an enumeration of >> civic street-level addresses (which presumably fit into the PIDF-LO >> mold or else we have other problems) and polygons describing the >> area. The former is necessary for civic address validation, the >> latter for boundary matching. >> >> I don't see why I would care about parcel boundaries unless I do >> geocoding of some sort. >> >> On Jan 25, 2007, at 11:14 AM, Brian Rosen wrote: >> >>> I agree that the forest guides need a standard interface and data >>> format. I >>> don't think of that as the same as provisioning the LoST data >>> itself. Agree >>> that we want replication, but I don't think the provisioning interface >>> matters for that (what I want is automatic replication, and I think >>> there >>> are operations defined in LoST to facilitate that, understanding >>> that the >>> actual data sent in the "zone transfer equivalent" has the issues >>> we are >>> talking about). >>> >>> The complexity DOES vary all over the place because of the level of >>> detail >>> in the civic data. In most countries, there is very little detail >>> (if you >>> know the city name, you know the PSAP. In some countries it's more >>> coarse >>> than that). In the U.S., you have to know the number on the street to >>> determine the PSAP, and you better match the street name, pre/post >>> directional, prefix, suffix, etc. >>> >>> If you are hot to do an IETF standardized provisioning interface, >>> let's >>> start with how you define street addresses. Since I advocate doing >>> this as >>> a GIS system, and not as tabular data, I want a GIS layer with street >>> centerlines, an option for actual streets (correct placement and >>> width), a >>> layer for (at least) street addresses as point plots, options for >>> parcels. >>> For both points and parcels there are some provisioned settings >>> that deal >>> with edge cases. For example, in some jurisdictions, there is an >>> algorithm >>> for house numbers (go up by 1 every 50 feet for example), and they >>> want to >>> allow addresses that aren't actually provided as points on the >>> centerline >>> data to be valid using the algorithm. I'm not really up on how >>> they do the >>> equivalent for Japanese and Chinese addresses; it's more complex in >>> some >>> ways. >>> >>> The actual boundaries for each service is a set of polygons (and it >>> is a >>> set, not just one), which we can probably get a simple GML spec for >>> pretty >>> easily. >>> >>> Bring out your GIS experts, we have a lot to learn before we >>> specify this. >>> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 25 12:42:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA8bw-0006K9-5a; Thu, 25 Jan 2007 12:42:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA8bu-0006Jd-VF for ecrit@ietf.org; Thu, 25 Jan 2007 12:42:06 -0500 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA8bo-0006ko-MI for ecrit@ietf.org; Thu, 25 Jan 2007 12:42:06 -0500 Received: from [172.16.10.88] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 25 Jan 2007 12:41:23 -0500 id 015880CA.45B8EBC3.00005192 In-Reply-To: <45B8E0BD.8000800@gmx.net> References: <02db01c7409b$f4b4d9f0$640fa8c0@cis.neustar.com> <3BFB1257-D365-45E8-9DAF-2C1A7640552F@cs.columbia.edu> <45B8DC8D.2060405@nortel.com> <45B8E0BD.8000800@gmx.net> Mime-Version: 1.0 Message-Id: <7D7688B9-884F-4A35-8DB4-E578CF45080C@hxr.us> From: Andrew Newton Subject: Re: [Ecrit] Service area format standards Date: Thu, 25 Jan 2007 12:41:57 -0500 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1202979013==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============1202979013== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-20885-1169746883-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-20885-1169746883-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Jan 25, 2007, at 11:54 AM, Hannes Tschofenig wrote: > The process might be country specific. > > The the format of the collected data could be standardized to > simplify the provisioning of the LoST database. > > Currently, you have to go through different data conversion steps > and you might reduce the quality of the previously collected data. Yes. From Michael's email, I think the process of using short codes, etc... sounds pretty specific to Austria. However, none of the things he mentioned that are needed in the provisioning format are specific to Austria and they all sound like general meta data that nearly every country would use or the service boundaries we have already defined. So I'm at a loss to know what it is they do that are mystical, magical incantations that cannot be shared with the rest of us. At the very least, they should be able to clearly spell out what it is that makes their approach unique and special. I have not seen that. -andy --=_zeke.ecotroph.net-20885-1169746883-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.3
On Jan 25, 2007, at 11:= 54 AM, Hannes Tschofenig wrote:

Th= e process might be country specific.


=

The the format of the collected = data could be standardized to simplify the provisioning of the LoST datab= ase.


Currently, you have to go through different data conversion step= s and you might reduce the quality of the previously collected data.


Yes.=A0 From Michael's email, I think = the process of using short codes, etc... sounds pretty specific to Austri= a.=A0 However, none of the things he mentioned that are needed in the pro= visioning format are specific to Austria and they all sound like general = meta data that nearly every country would use or the service boundaries w= e have already defined.

<= /DIV>
So I'm at a loss to know what it is they do that are mystical, = magical incantations that cannot be shared with the rest of us.=A0 At the= very least, they should be able to clearly spell out what it is that mak= es their approach unique and special.=A0 I have not seen that.
=
-andy
--=_zeke.ecotroph.net-20885-1169746883-0001-2-- --===============1202979013== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1202979013==-- From ecrit-bounces@ietf.org Thu Jan 25 20:25:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAFpr-0001mR-1h; Thu, 25 Jan 2007 20:24:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAFpp-0001lh-Ca; Thu, 25 Jan 2007 20:24:57 -0500 Received: from smtp3.andrew.com ([198.17.217.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAFpi-0007rP-Dy; Thu, 25 Jan 2007 20:24:57 -0500 X-SEF-Processed: 5_0_0_910__2007_01_25_19_29_53 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1 [10.3.20.66] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 25 Jan 2007 19:29:53 -0600 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 19:24:44 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jan 2007 19:24:42 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Geoshapes on OGC website Thread-Index: AcdA6MFt2Affhl8/SgKu0c3i7h42Dg== From: "Winterbottom, James" To: , "ECRIT" X-OriginalArrivalTime: 26 Jan 2007 01:24:44.0700 (UTC) FILETIME=[C2BB65C0:01C740E8] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Ecrit] Geoshapes on OGC website X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi All,=0D=0A=0D=0AAt long last you can access the official Geoshapes docum= ent from the OGC=0D=0Awebsite. Thanks to Martin Thomson and Carl Reed for m= aking this happen.=0D=0A=0D=0Ahttp://www.opengeospatial.org/standards/bp#06= -142=0D=0A=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A------------------= ---------------------------------------------------------------------------= ---=0D=0AThis message is for the designated recipient only and may=0D=0Acon= tain privileged, proprietary, or otherwise private information. =20=0D=0AIf= you have received it in error, please notify the sender=0D=0Aimmediately a= nd delete the original. Any unauthorized use of=0D=0Athis email is prohibi= ted.=0D=0A-----------------------------------------------------------------= -------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 25 20:43:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAG7S-0002AC-9T; Thu, 25 Jan 2007 20:43:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAG7Q-000283-WE; Thu, 25 Jan 2007 20:43:09 -0500 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAG7N-0003AZ-N1; Thu, 25 Jan 2007 20:43:08 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 25 Jan 2007 20:42:09 -0500 id 015884E4.45B95C71.000043FC In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <729060EB-AEE9-4DA8-BB83-8683C9A09AEF@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Thu, 25 Jan 2007 20:42:42 -0500 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: geopriv@ietf.org, ECRIT Subject: [Ecrit] Re: [Geopriv] Geoshapes on OGC website X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Completely OT, but they also have a Binary XML spec (BXML). I just scanned it, and it looks very interesting. My brief $0.02: 1) I would probably do a lot more than just skim this spec if I knew exactly which parts were patent encumbered and by whom. 2) One of my first questions was "Why not WBXML?", and there was a section that actually talked to that point and that I found very agreeable. 3) The compromise on the endianness thing gives the worst of both cases. There is a lot, I mean a lot, of code out there that knows and does the right thing with network byte order. Plus, there are far, far more cell phones than desktop computers, and they don't run x86. -andy On Jan 25, 2007, at 8:24 PM, Winterbottom, James wrote: > Hi All, > > At long last you can access the official Geoshapes document from > the OGC > website. Thanks to Martin Thomson and Carl Reed for making this > happen. > > http://www.opengeospatial.org/standards/bp#06-142 > > > Cheers > James > > > ---------------------------------------------------------------------- > -------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ---------------------------------------------------------------------- > -------------------------- > [mf2] > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 31 09:51:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGo3-00086d-D8; Wed, 31 Jan 2007 09:51:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGo2-00086T-9E for ecrit@ietf.org; Wed, 31 Jan 2007 09:51:26 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCGnx-0006ji-Ld for ecrit@ietf.org; Wed, 31 Jan 2007 09:51:26 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 31 Jan 2007 06:51:21 -0800 X-IronPort-AV: i="4.13,263,1167638400"; d="scan'208"; a="36299919:sNHT141938721" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l0VEpKlx013096 for ; Wed, 31 Jan 2007 06:51:20 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0VEpKhq012096 for ; Wed, 31 Jan 2007 06:51:20 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 09:51:20 -0500 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 09:51:19 -0500 From: "Marc Linsner" To: Date: Wed, 31 Jan 2007 09:51:18 -0500 Message-ID: <004b01c74547$4435ce80$290d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdFQfUPHHTOys5kQF+9U2RfTq8scAABTODw X-OriginalArrivalTime: 31 Jan 2007 14:51:19.0475 (UTC) FILETIME=[4454C830:01C74547] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=44637; t=1170255080; x=1171119080; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20LoST=20Review |Sender:=20; bh=w9z3K9CwGhTbC0eLJMHyzoSAtyLYiCQqQF2nQulDh7U=; b=WGxtaDUlkh/xEwuaQdDsOy8MVtv2oXNdG9cdR1AUTG8H5AxWO2mgkIFEjDeepNQgcJTI+s0I RKel9tc+OeRr4uudTza1dksg7mEwPOQ1+nwx0MubaFip1p7GQDTsqW+t; Authentication-Results: sj-dkim-5; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4120a90b86e256a7465e9d130cb2a242 Subject: [Ecrit] LoST Review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes and I asked Patrik Falstrom to review the LoST/Mapping Arch drafts....here is the first of his comments..... .........................................................................= ... ........................................ -----Original Message----- From: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com]=20 Sent: Wednesday, January 31, 2007 9:13 AM To: Marc Linsner Cc: leslie@thinkingcat.com; 'Hannes Tschofenig' Subject: Re: ECRIT help please? First of all, I read documents serially. So, some concern I have had = might be resolved later on. Because of that, read my comments from top to = bottom and interpret as I have not seen what is below the comment. > LoST: A Location-to-Service Translation Protocol > draft-ietf-ecrit-lost-03.txt > > Abstract > > This document describes an XML-based protocol for mapping service > identifiers and geodetic or civic location information to service > contact URIs. In particular, it can be used to determine the > location-appropriate PSAP for emergency services. FYI: I have always been nervous when using as an index something that is = a well known abstraction of a location, such as a civic location. =20 My argument all the time has been that the most important piece of the puzzle is that "the device" have some kind of identifier that later can = be mapped to a PSAP. Secondly (and not the same, note that) that the device = can send information to the PSAP so that the PSAP can (at least in Sweden) = (a) locate the device and (b) reinitiate the connection if the communication breaks. I have seen too many discussions in ECRIT where the two uses of "the location" (the routing issue, and the data that is sent to the PSAP) is claimed to be the same. Anyway... You have heard me saying this before :-) > Table of Contents > > 1. =20 > Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 2. Terminology and Requirements > Notation . . . . . . . . . . . . 6 > 3. Overview of Protocol > Usage . . . . . . . . . . . . . . . . . . 7 > 4. LoST Uniform Resource Locators and Their Resolution . . . . . = > 8 > 5. The > Element . . . . . . . . . . . . . . . . . . . . 9 > 5.1. Data source and version: The 'source', 'sourceId' and > 'version' =20 > Attributes . . . . . . . . . . . . . . . . . . . 9 > 5.2. Time of Last Update: The 'lastUpdated' =20 > Attribute . . . . . 9 > 5.3. Validity: The 'expires' =20 > Attribute . . . . . . . . . . . . 9 > 5.4. Describing the Service with the Element . .=20 > 10 > 5.5. The Mapped Service: the Element . . . . . . . .=20 > 10 > 5.6. Defining the Service Region with the > =20 > Element . . . . . . . . . . . . . . . . . . . . . . . . . 10 > 5.7. Service Boundaries by Reference: the > Element . . . . . . . . . . . .=20 > 11 > 5.8. The Service > Number . . . . . . . . . . . . . . . . . . . . 11 > 5.9. Service URLs: the > Element . . . . . . . . . . . . . 11 > 6. Path of Request: > Element . . . . . . . . . . . . . . . 12 > 7. Mapping a Location and Service to URLs: =20 > . . . . 13 > 7.1. =20 > Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13 > 7.2. =20 > Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13 > 7.2.1. Example Using Geodetic Coordinates . . . . . . . . . .=20 > 13 > 7.2.2. Civic Address Mapping Example . . . . . . . . . . . .=20 > 14 > 7.3. Components of the Request . . . . . . . . .=20 > 16 > 7.3.1. The > Element . . . . . . . . . . . . . . . . 16 > 7.3.2. Identifying the Service: The Element . . .=20 > 17 > 7.3.3. =20 > Recursion . . . . . . . . . . . . . . . . . . . . . . 17 > 7.3.4. Service > Boundary . . . . . . . . . . . . . . . . . . . 17 > 7.3.5. Requesting Civic Location Validation . . . . . . . . .=20 > 17 > 7.4. Components of the Mapping Response > =20 > . . . . . . . . . . . . . . . . . . 19 > 7.4.1. =20 > Overview . . . . . . . . . . . . . . . . . . . . . . . 19 > 7.4.2. Civic Address Validation: the > > Element . . . . . . . . . . . . . 20 > 8. Retrieving the Service Boundary via . . .=20 > 21 > 9. List Services: =20 > . . . . . . . . . . . . . . . . 24 > 10. List Services By Location: =20 > . . . . . 25 > 11. Location > Profiles . . . . . . . . . . . . . . . . . . . . . . 27 > > > > Hardie, et al. Expires July 21, 2007 =20 > [Page 2] > Internet-Draft LoST January =20 > 2007 > > > 11.1. Location Profile > Usage . . . . . . . . . . . . . . . . . . 28 > 11.2. Two Dimensional Geodetic > Profile . . . . . . . . . . . . . 30 > 11.3. Basic Civic > Profile . . . . . . . . . . . . . . . . . . . 31 > 12. Errors, Warnings, and > Redirects . . . . . . . . . . . . . . . 32 > 12.1. =20 > Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 32 > 12.2. =20 > Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 33 > 12.3. =20 > Redirects . . . . . . . . . . . . . . . . . . . . . . . . 34 > 13. LoST > Transport . . . . . . . . . . . . . . . . . . . . . . . . 35 > 14. Relax NG > Schema . . . . . . . . . . . . . . . . . . . . . . . 36 > 15. Internationalization > Considerations . . . . . . . . . . . . . 43 > 16. IANA > Considerations . . . . . . . . . . . . . . . . . . . . . 44 > 16.1. U-NAPTR > Registrations . . . . . . . . . . . . . . . . . . 44 > 16.2. Content-type registration for 'application/lost > +xml' . . . 44 > 16.3. LoST Relax NG Schema > Registration . . . . . . . . . . . . 46 > 16.4. LoST Namespace > Registration . . . . . . . . . . . . . . . 46 > 16.5. URL Registration > Template . . . . . . . . . . . . . . . . 47 > 16.6. LoST Location Profile > Registry . . . . . . . . . . . . . . 48 > 17. Security > Considerations . . . . . . . . . . . . . . . . . . . 49 > 18. =20 > Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 > 19. Open > Issues . . . . . . . . . . . . . . . . . . . . . . . . . 52 > 20. =20 > References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 > 20.1. Normative > References . . . . . . . . . . . . . . . . . . . 53 > 20.2. Informative > References . . . . . . . . . . . . . . . . . . 54 > Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . .=20 > 55 > Authors' =20 > Addresses . . . . . . . . . . . . . . . . . . . . . . . . 69 > Intellectual Property and Copyright Statements . . . . . . . . . .=20 > 70 > > > > > > > > > > > > > > > > > > > > > > > > > > Hardie, et al. Expires July 21, 2007 =20 > [Page 3] > Internet-Draft LoST January =20 > 2007 > > > 1. Introduction > > This document describes a protocol for mapping a service identifier > [10] and location information compatible with PIDF-LO [8], namely > revised civic location information [11] and GML [13]) to one or=20 > more > service URL. Example service URL schemes include sip [14], xmpp > [15], and tel [16]. While the initial focus is on providing=20 > mapping > functions for emergency services, it is likely that the protocol is > applicable to any service URN. For example, in the United States, > the "2-1-1" and "3-1-1" service numbers follow a similar > location-to- > service behavior as emergency services. > > This document names this protocol "LoST", for Location-to-Service > Translation. LoST Satisfies the requirements [18] for mapping > protocols. LoST provides a number of operations, centered around > mapping locations and service URNs to service URLs and associated > information. LoST mapping queries can contain either civic or > geodetic location information. For civic addresses, LoST can > indicate which parts of the civic address are known to be valid or > invalid, thus providing address validation (see Section 3.5 of [18] > for a description of validation). LoST indicates errors in the > location data to facilitate debugging and proper user feedback, but > also provides best-effort answers. > > LoST queries can be resolved recursively or iteratively. To=20 > minimize > round trips and to provide robustness against network failures,=20 > LoST > caches individual mappings and indicates the region for which the > same answer would be returned ("service region"). Hmm...so LoST include caching. This is the first thing I think one = should look at. Who defines the appropriate caching time? Do you need = notifications for emergency updates? Etc? > As defined in this document, LoST messages are carried in HTTP and > HTTPS protocol exchanges, facilitating use of TLS for protecting=20 > the > integrity and confidentiality of requests and responses. Oh, no! Not HTTP again!!! Why? Also, you can not rely on client = certificates or other mechanisms for the authentication of the client sending the = query. You need another layer of username/password/ whatever on top of TLS. TLS = is usable for the encryption of the traffic, but not (much) more. This implies to me that the payload that is moved with the HTTP protocol have to include enough signatures, passwords, usernames and possibly encryption to handle the authentication and authorization of the LoST transaction. Lets see below how this problem is resolved. > This document focuses on the description of the protocol between=20 > the > mapping client (seeker or resolver) and the mapping server=20 > (resolver > or other servers). The relationship between other functions, such=20 > as > discovery of mapping servers, data replication and the overall > mapping server architecture are described in a separate document > [19]. > > The query message carries location information and a service > identifier encoded as a Uniform Resource Name (URN) (see [10]) from > the LoST client to the LoST server. The LoST server uses its > database to map the input values to one or more Uniform Resource > Identifiers (URI) and returns those URIs along with optional > information, such as hints about the service boundary, in a=20 > response > message to the LoST client. If the server cannot resolve the query > itself, it may in turn query another server or return the address=20 > of > > > > Hardie, et al. Expires July 21, 2007 =20 > [Page 4] > Internet-Draft LoST January =20 > 2007 > > > another LoST server, identified by a LoST URL (Section 4). I am a little bit nervous about the fact that the server can either =20 give back a referral OR do a recursive query. For the client the =20 difference is of course that all clients MUST implement the ability =20 to handle referrals, but on the other hand, the ability for a server =20 to query another server might not have to be in this document. Why is =20 that needed? Because it is needed to know wether the data comes from =20 an authoritative source? Or "just" because it imitates the way DNS =20 works? We'll see. > In > addition to the mapping function described in Section 7, the =20 > protocol > also allows to retrieve the service boundary (see Section 8) and to > list the services available for a particular location (see > Section 10) or supported by a particular server (see Section 9). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hardie, et al. Expires July 21, 2007 =20 > [Page 5] > Internet-Draft LoST January =20 > 2007 > > > 2. Terminology and Requirements Notation > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in =20 > this > document are to be interpreted as described in [1]. > > This document furthermore uses the terminology defined in [18]. "Warning" :-) I have not read this [18] document. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hardie, et al. Expires July 21, 2007 =20 > [Page 6] > Internet-Draft LoST January =20 > 2007 > > > 3. Overview of Protocol Usage > > The client may perform the mapping at any time. Among the common > triggers for mapping requests are: > > 1. When the client initially starts up or attaches to a network. > > 2. When the client detects that its location has changed > sufficiently that it is outside the bounds of the service =20 > region > returned in an earlier LoST query. > > 3. When cached mapping information has expired. > > 4. When invoking a particular service. At that time, a client may > omit requests for service boundaries or other auxiliary > information. > > A service-specific Best Current Practice (BCP) document, such as > [20], governs whether a client is expected to invoke the mapping > service just before needing the service or whether to rely on =20 > cached > answers. Cache entries expire at their expiration time (see > Section 5.3), or they become invalid if the caller's device moves > beyond the boundaries of the service region. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hardie, et al. Expires July 21, 2007 =20 > [Page 7] > Internet-Draft LoST January =20 > 2007 > > > 4. LoST Uniform Resource Locators and Their Resolution > > LoST servers are identified by LoST Uniform Resource Locators =20 > (URLs), > which follow the format of URLs defined in RFC 3986 [7], with the > following ABNF: > > LoST-URI =3D "lost:" host > > 'host' is defined in Section 3.2.2 of RFC 3986 [7]. > > An example is 'lost:lostserver.example.com' Have this URI spec been reviewed on the URI-review list? If not, I =20 urge you to pass it on asap. > If a LoST URL contains a host name rather than an IP address, =20 > clients > need to use U-NAPTR [12] using the U-NAPTR specification described > below to obtain a URI (indicating host and protocol) for the > applicable LoST service. In this document, only the HTTP and HTTPS > URL schemes are defined. Note that the HTTP URL can be any valid > HTTP URL, including those containing path elements. > > The following two DNS entries resolve the LoST URL =20 > "lost:example.com" > to the HTTPS URL https://lostserv.example.com/secure or the HTTP =20 > URL > http://lostserver.example.com, with the former being preferred. (1) Please use the same examples all the time. Above you use the =20 example lostserver.example.com, and now example.com. (2) Why do you not only use SRV records for this as lost is only =20 defined for HTTP/HTTPS? lost:example.com -> _lost._tcp.example.com:80 I do not see any need for NAPTR records, unless LOST can be used with =20 some other protocol than HTTP. That is though not what it seems the =20 overall design is for. I.e. possible over-engineering for an abstraction that in reality is =20 not, and will never, be used. > example.com. > > IN NAPTR 100 10 "u" "LoST:https" > "!*.!https://lostserver.example.com/secure!" "" > > IN NAPTR 200 10 "u" "LoST:http" > "!*.!http://lostserver.example.com!" "" How do the end device get the LOST URL? > > > > > > > > > > > > > > > > > > > > > Hardie, et al. Expires July 21, 2007 =20 > [Page 8] > Internet-Draft LoST January =20 > 2007 > > > 5. The Element > > The element is the core data element in LoST, =20 > describing a > service region and the associated service URLs. Its parameters > indicate when the mapping was last updated, how long it is =20 > valid, its > version and the authoritative source for the mapping, along with a > unique identifier. Elements within the element then > provide a human-readable description, the service URN, a service > boundary, the service URIs, and a service number. All elements > except the service URN are optional. Are really all elements optional? sourceId, version, and source =20 attributes as well? This draft contain a lot of words. Not as crisp as I would like to =20 see a protocol specification. Why for example does the above =20 paragraph point out "...provide a human-readable description..." etc, =20 and then the first thing that happen below in 5.1 is that it talks =20 about "Data source and version". Attributes that are not mentioned =20 above? > Below, we describe the > components in turn. Unnecessary text. > 5.1. Data source and version: The 'source', 'sourceId' and 'version' > Attributes > > The 'source', 'sourceId' and 'version' attributes uniquely =20 > identify a > particular mapping record. They are created by the authoritative > source for a mapping and never modified when a mapping is served =20 > from > a cache. The 'source' attribute contains a LoST URL identifying =20 > the > authoritative generator of the mapping. The 'sourceId' attribute > identifies a particular mapping. Should not the URI definition include the ability to also include the =20 sourceId and version in the URI? Else you will not be able to get a URI for the record itself, and I =20 think that would be an opportunity that should not be missed. > The attribute contains a token, > which is opaque, but MUST be unique among all different mappings > maintained by the authoritative source for that particular service. "The attribute" that this sentence talks about, is that the =20 "sourceId" attribute? Not clear. Why btw are several attributes in the same section of the spec? =20 Better with one attribute per section and a crisp short definition of =20 that attribute. > For example, a UUID is a suitable format. The 'version' =20 > attribute is > a positive integer that is incremented by one for each change in =20 > the > mapping. So if the difference between two records I happen to have is 4, there =20 MUST have been that number of versions in between? It is unclear in =20 this text as no MUST, SHOULD etc is in use if this increment of one =20 is mandatory or not. Makes the protocol unclear and might lead to =20 incompatible implementations. > Thus, a higher version number refers to a more recent > mapping. A mapping maintains its sourceId value as long as it > remains logically the same, e.g., represents the same service > boundary or replaces an earlier service boundary. A receiver =20 > should Lower case "should" here... > be able to replace a mapping with another one having the same > 'source' and 'sourceId' and a higher version number. All three > attributes are REQUIRED for all elements. This is not what section 5 said above. You have an attack vector if someone manage to spoof a record into a =20 cache with a version number that is extremely high. How large can =20 this version number be? > 5.2. Time of Last Update: The 'lastUpdated' Attribute > > The 'lastUpdated' attribute describes when the mapping was last > changed. The contents of this attribute is a timezoned XML type > dateTime, in canonical representation. The attribute is REQUIRED. Note that according to 3.2.7.2 of http://www.w3.org/TR/2001/REC-=20 xmlschema-2-20010502/#dateTime (maybe I am looking at the wrong =20 source) the canonical representation of a time is always in UTC, so =20 the timezoned canonical version will always have 'Z' as the timezone =20 indicator. This is what you want? > 5.3. Validity: The 'expires' Attribute > > The 'expires' attribute contains the absolute time until which the > mapping is to be considered valid. Does not "expires" contain the dateTime spec of when the mapping is =20 changing state from valid to not valid? The text above to me seems to =20 be the reverse. > The contents of this attribute is > a timezoned XML type dateTime, in canonical representation. See > Section 3 regarding how this value is to be utilized with a cache. > The 'expires' attribute is REQUIRED to be included in the > element. > > > > > Hardie, et al. Expires July 21, 2007 =20 > [Page 9] > Internet-Draft LoST January =20 > 2007 > > > On occasion, a resolver may be forced to return an expired =20 > mapping if > it cannot reach the authoritative server or the server fails to > return a usable answer. Seekers and resolvers MAY cache the =20 > mapping > so that they have at least some information available. Resolvers > SHOULD re-attempt the query each time a seeker requests a mapping. I think you should try to only use the terms "client" and "server" =20 throughout the document when you talk about the protocol. We already =20 know that a server can act as a proxy, and then act as a client. Try to not use the term "resolver". Experience from the DNS show it =20 is a confusing term. > 5.4. Describing the Service with the Element > > The element describes the service with a string =20 > that is > suitable for display to human users, annotated with the 'xml:lang' > attribute that contains a language tag to aid in the rendering of > text. Why is lang tag needed for the rendering? Because of alternate =20 displayName elements with different lang tags? > 5.5. The Mapped Service: the Element Here you start talking about elements and not attributes. That is =20 confusing. > The 'service' element identifies the service for which this mapping > applies. It is usually the same service URN as in the request. Usually? That is an interesting term to have in a protocol =20 specification... :-) > However, if the requested service, identified by the service URN =20 > [10] > in the element in the request, does not exist for the > location indicated, the server can either return an > (Section 12.1) error or can provide an > alternate service that approximates the desired service for that > location. But if the response is , is that "error" part =20 of the element? We talk about the content of the =20 element here, and I see either the URN of the service, or the URN of =20 an alternative service. Not a third alternative. Once again, not crisp enough, risk that the result is non-=20 interoperable implementations. > In the latter case, the server MUST include a > element with the alternative service URN. The choice of service =20 > URN > is left to local policy, but the alternate service should be =20 > able to > satisfy the original service request. The element may =20 > also > be required if the mapping is to be digitally signed. Resolvability of that URN? It is not a lost URL that is given back so =20 it is a referral within the protocol? > 5.6. Defining the Service Region with the Element Element and not attribute again. > A response can indicate the region for which the service URL =20 > returned > would be the same as in the actual query, the so-called _service > region_. What is "can" in this sentence? What does that word imply? That it =20 might not indicate the same region as in the actual query? > The service region can be indicated by value or by > reference (see Section 5.7). If a client moves outside the service > area and wishes to obtain current service data, it MUST send a new > query with its current location. It is interesting to have "if...wishes...MUST" in the same sentence. =20 What if he do not wish to obtain current service data? I.e. the "if" =20 make the MUST loose its power. > The service region is described by > value in one or more elements, each formatted > according to a different location profile, identified by the > 'profile' atribute. Change the order of the attributes...to me it seems this is a forward =20 reference to "profile" attribute that btw is not defined in section 5. > The client only processes the first element that > it can understand according to its list of supported location > profiles. Thus, the elements are alternative descriptions of the > same service region, not additive geometries. What if there is a difference? Is a difference allowed? > The server returns all suitable service regions, using all =20 > available > location profiles, so that intermediate caches have this =20 > information > available for future queries. Is "suitable" same as "match the query"? > > > > > > Hardie, et al. Expires July 21, 2007 =20 > [Page 10] > Internet-Draft LoST January =20 > 2007 > > > 5.7. Service Boundaries by Reference: the > Element > > Since geodetic service boundaries may contain thousands of =20 > points and > thus be quite large, Can it? Hmmm....(reader start to think here)...yes it can! :-) > clients may opt to conserve bandwidth and > request a reference to the service boundary instead of the value > described in Section 5.6. The identifier of the service =20 > boundary is > returned as an attribute of the element, > along with a LoST URL identifying the server from where it can be > retrieved. Should the reference not be "just" a URL? (See above) > The actual value of the service boundary is then > retrieved with the getServiceBoundary (Section 8) request. > > The identifier is a random token with at least 128 bits of entropy > and can be assumed to be globally unique. It uniquely references a > particular boundary. If the boundary changes, a new identifier =20 > MUST > be chosen. Because of these properties, a client receiving a =20 > mapping > response can simply check if it already has a copy of the boundary > with that identifier. Should the reference then not be a URL plus an identifier? > If so, it can skip checking with the server > whether the boundary has been updated. Since service boundaries =20 > are > likely to remain unchanged for extended periods of time, possibly > exceeding the normal lifetime of the service URL, this approach > avoids refreshing the boundary information even if the cached =20 > service > response has gotten stale. ...even if the URL changes for the object. > > 5.8. The Service Number Element or attribute? > The service number is returned in the optional > element. Aha, element! > It contains a string of digits, * and # that a user on a > device with a 12-key dial pad could use to reach that particular > service. Reference a syntax specification. Max 15 char in the string as in E.164? > 5.9. Service URLs: the Element > > The response returns the service URLs in one or more =20 > elements. > The URLs MUST be absolute URLs. The ordering of the URLs has no > particular significance. Each URL scheme MUST only appear at most > once, but it is permissible to include both secured and regular > versions of a protocol, such as both 'http' and 'https' or 'sip' =20 > and > 'sips'. How to handle load balancing, or the fact two PSAPs might cover the =20 same area? Does that NEVER happen? Did this document not say earlier that all matching service areas =20 (and for me because of that srevice URLs) should be returned that =20 matches? This "one scheme only" to me say that the server must choose =20 "the best one", which seems weird. Or am I confused? > > > > > > > > > > > > > Hardie, et al. Expires July 21, 2007 =20 > [Page 11] > Internet-Draft LoST January =20 > 2007 > > > 6. Path of Request: Element > > To prevent loops and to allow tracing of request and response =20 > paths, > all requests that allow recursion include a element that > contains one or more elements, each possessing an attribute > containing a LoST URL. The order of elements corresponds to > the order of LoST servers, i.e., the first element identifies > the server that first received the request from the seeker. The > authoritative server copies the element verbatim into the > response. I don't know enough about XML to say whether this ordering is ok or =20 not. This is the first time ordering among elements exists in this =20 spec though. > If a query is answered iteratively, the querier includes all =20 > servers > that it has already contacted. > > The example in Figure 5 indicates that the answer was given to the > responding server by the LoST server at esgw.ueber-110.de.example, > which got the answer from the LoST server at > polizei.muenchen.de.example. This is also sent in a request? How else can one prevent loops if a =20 server is acting as a client and do a recursive search, walking into =20 servers that the originator already have queried? I don't understand exactly how this can help with loop prevention. =20 Just how it can help loop detection on the client side. If it is not =20 passed also in requests. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hardie, et al. Expires July 21, 2007 =20 > [Page 12] > Internet-Draft LoST January =20 > 2007 > > > 7. Mapping a Location and Service to URLs: > > 7.1. Overview > > The query constitutes the core of the LoST > functionality, mapping civic or geodetic locations to URLs and > associated data. After giving an example, we enumerate the =20 > elements > of the query and response. > > 7.2. Examples > > 7.2.1. Example Using Geodetic Coordinates > > The following is an example of mapping a service to a location =20 > using > geodetic coordinates, for the service associated with the police > (urn:service:sos.police). > > > > xmlns=3D"urn:ietf:params:xml:ns:lost1" > xmlns:p2=3D"http://www.opengis.net/gml" > serviceBoundary=3D"value" > recursive=3D"true"> > > > > 37.775 -122.422 > > > urn:service:sos.police > > > > Figure 2: A geodetic query > > Given the query above, a server would respond with a service, and > information related to that service. In the example below, the > server has mapped the location given by the client for a police > service to the New York City Police Deparment, instructing the =20 > client > that it may contact them via the URIs "sip:nypd@example.com" and > "xmpp:nypd@example.com". The server has also given the client a > geodetic, two-dimensional boundary for this service. The =20 > mapping was > last updated on November 1, 2006 and expires on January 1, 2007. > This instructs the client that if its location changes beyond the > give service boundary or the expiration time has been reached, it > would need to requery for this information. Does "lastUpdated" imply that it is correct from that point in time? =20 To me that is not crystal clear. One might update a record one month =20 ahead of a move for example. > > > > > Hardie, et al. Expires July 21, 2007 =20 > [Page 13] > Internet-Draft LoST January =20 > 2007 > > > > xmlns:p2=3D"http://www.opengis.net/gml"> > expires=3D"2007-01-01T01:44:33Z" > lastUpdated=3D"2006-11-01T01:00:00Z" > source=3D"lost:authoritative.example" > sourceId=3D"7e3f40b098c711dbb6060800200c9a66" version=3D"1"> > > New York City Police Department > > urn:service:sos.police > > > > > 37.775 -122.4194 > 37.555 -122.4194 > 37.555 -122.4264 > 37.775 -122.4264 > 37.775 -122.4194 > > > > > sip:nypd@example.com > xmpp:nypd@example.com > 911 > > > > > > > > Figure 3: A geodetic answer > > 7.2.2. Civic Address Mapping Example > > The following is an example of mapping a service to a location much > like the example in Section 7.2.1, but using civic address location > information. In this example, the client requests the service > associated with police (urn:service:sos.police) along with a =20 > specific > civic address (house number 6 on a street named Otto-Hahn-Ring in > Munich, Germany). > > > > > > > Hardie, et al. Expires July 21, 2007 =20 > [Page 14] > Internet-Draft LoST January =20 > 2007 > > > > recursive=3D"true" serviceBoundary=3D"value"> > profile=3D"civic"> > xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> > Germany > Bavaria > Munich > Otto-Hahn-Ring > 6 > 81675 > > > urn:service:sos.police > > > Figure 4: A civic address query > > Given the query above, a server would respond with a service, and > information related to that service. In the example below, the > server has mapped the location given by the client for a police > service to the Muenchen Polizei-Abteilung, instructing the client > that it may contact them via the URIs sip:munich-police@example.com > and xmpp:munich-police@example.com. The server has also given the > client a civic address boundary (the city of Munich) for this > service. The mapping was last updated on November 1, 2006 by the > authoritative source "lost:polizei.muenchen.de.example" and expires > on January 1, 2007. This instructs the client to requery for the > information if its location changes beyond the given service =20 > boundary > (i.e., beyond the city of Munich) or after January 1, 2007. > > > > > > > > > > > > > > > > > > > > Hardie, et al. Expires July 21, 2007 =20 > [Page 15] > Internet-Draft LoST January =20 > 2007 > > > > > expires=3D"2007-01-01T01:44:33Z" > lastUpdated=3D"2006-11-01T01:00:00Z" > source=3D"lost:esgw.ueber-110.de.example" > sourceId=3D"e8b05a41d8d1415b80f2cdbb96ccf109" version=3D"1" > > > Muenchen Polizei-Abteilung > > urn:service:sos.police > = profile=3D"urn:ietf:params:lost:location-profile:basic-civic"> > xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> > Germany > Bavaria > Munich > 81675 > > > sip:munich-police@example.com > xmpp:munich-police@example.com > 110 > > > > > > > > Figure 5: A civic address answer > > 7.3. Components of the Request > > The request includes attributes that govern =20 > whether the > request is handled iteratively or recursively, whether location > validation is performed and which elements must be contained in the > response. > > 7.3.1. The Element > > The query communicates location using one or more > elements, which MUST conform to a location profile (see > Section 11). There MUST be no more than one location element for > each distinct location profile. The order of location objects is > significant; the server uses the first location object where it > understands the location profile. Ok, more ordering here. I presume that is ok... Using the first it understand is good. > > > > Hardie, et al. Expires July 21, 2007 =20 > [Page 16] > Internet-Draft LoST January =20 > 2007 > > > 7.3.2. Identifying the Service: The Element > > The type of service desired is specified by the element. > It contains service URNs from the registry established in [10]. > > 7.3.3. Recursion > > LoST and queries can be > recursive, as indicated by the 'recursive' attribute. A value of > "true" indicates a recursive query, with the default being "false" > when the attribute is omitted. In recursive mode, the LoST server > initiates queries on behalf of the requester and returns the result > to the requester, inserting a element to track the response > chain. The elements are appended in responses in order of > visit, i.e., the first element contains the authoritative > server and elements below indicate servers that the response > traversed on its way back to the original querier. Do you need time stamps on the via headers? > 7.3.4. Service Boundary > > LoST elements can describe the service boundary either by > value or by reference. Returning a service boundary reference is > generally more space-efficient for geospatial (polygon) boundaries > and if the boundaries change rarely, but does incur an additional > request. The querier can express a preference > for one or the other modality with the 'serviceBoundary' =20 > attribute in > the request, but the server makes the final =20 > decision as > to whether to return a reference or a value. Servers SHOULD NOT > return a by-value service boundaries if the querier requested a > reference. > > 7.3.5. Requesting Civic Location Validation > > Civic address validation is requested by setting the optional > attribute 'validateLocation' to true. If the attribute is omitted, > it is assumed to be false. The response is described in > Section 7.4.2. The example in Figure 6 demonstrates address > validation, omitting the standard response elements. > > > > > > > > > > > > > > Hardie, et al. Expires July 21, 2007 =20 > [Page 17] > Internet-Draft LoST January =20 > 2007 > > > > xmlns=3D"urn:ietf:params:xml:ns:lost1" > recursive=3D"true" > validateLocation=3D"true" > serviceBoundary=3D"value"> > > xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> > DE > Bavaria > Munich > Otto-Hahn-Ring > 6 > 81675 > > > urn:service:sos.police > > > Figure 6: A query with address validation request > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hardie, et al. Expires July 21, 2007 =20 > [Page 18] > Internet-Draft LoST January =20 > 2007 > > > > > expires=3D"2007-01-01T01:44:33Z" > lastUpdated=3D"2006-11-01T01:00:00Z" > source=3D"lost:authoritative.example" > sourceId=3D"4db898df52b84edfa9b6445ea8a0328e" > version=3D"1" > > > Muenchen Polizei-Abteilung > > urn:service:sos.police > > xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> > Germany > Bavaria > Munich > 81675 > > > sip:munich-police@example.com > xmpp:munich-police@example.com > 110 > > > country A1 A3 A6 > PC > > > > > > > > Figure 7: A message with address validation > information > I stopped here, as the findServiceResponse needed a lot of thinking. =20 I do not have that before monday next week. Patrik _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 31 09:55:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGrn-0001fp-O3; Wed, 31 Jan 2007 09:55:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGrm-0001fk-BJ for ecrit@ietf.org; Wed, 31 Jan 2007 09:55:18 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCGrj-0008EQ-Fe for ecrit@ietf.org; Wed, 31 Jan 2007 09:55:18 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 31 Jan 2007 15:55:16 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0VEtEis021358 for ; Wed, 31 Jan 2007 15:55:14 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0VEiTCe017813 for ; Wed, 31 Jan 2007 15:55:14 +0100 (MET) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 15:55:07 +0100 Received: from [127.0.0.1] ([144.254.226.40]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 15:55:06 +0100 In-Reply-To: <004b01c74547$4435ce80$290d0d0a@amer.cisco.com> References: <004b01c74547$4435ce80$290d0d0a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <820CBAE7-481A-4479-B32D-E00182BBB9DC@cisco.com> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Ecrit] LoST Review Date: Wed, 31 Jan 2007 15:55:03 +0100 To: Marc Linsner X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Jan 2007 14:55:07.0250 (UTC) FILETIME=[CC187D20:01C74547] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=46154; t=1170255314; x=1171119314; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20 |Subject:=20Re=3A=20[Ecrit]=20LoST=20Review |Sender:=20; bh=+gk46snx2T7V70jkUmzlUUSYUr9i7d5186dOj8O8zXQ=; b=ehPEcsaIGvkl+yu/Xuc4niJBki5y1tJ6kqlV+B4KJu/ZlSk7wzAgBly4/iwe65YSSRALsRa0 4bHqPwmr56KxdT0N1Z4YWnrnW5CxfjKpX9JcI4c/QrCqncEJmfpHLV3y; Authentication-Results: ams-dkim-1; header.From=paf@cisco.com; dkim=pass (si g from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: abb09102e905d3cdd1457ac8fdb65b91 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Note that I have NOT followed the discussion on the mailing list, and =20= in my review of the document I most certainly reopen issues that the =20 wg for many many many months ago have put to sleep. So, do not get stuck on the issues I rise. See this review as if =20 someone from the outside that sort of know what you are doing (or =20 think he knows what you are doing, but is wrong :-) ) is reading the =20 document for the first time. Regards, Patrik On 31 jan 2007, at 15.51, Marc Linsner wrote: > Hannes and I asked Patrik Falstrom to review the LoST/Mapping Arch > drafts....here is the first of his comments..... > ......................................................................=20= > ...... > ........................................ > > -----Original Message----- > From: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] > Sent: Wednesday, January 31, 2007 9:13 AM > To: Marc Linsner > Cc: leslie@thinkingcat.com; 'Hannes Tschofenig' > Subject: Re: ECRIT help please? > > First of all, I read documents serially. So, some concern I have =20 > had might > be resolved later on. Because of that, read my comments from top to =20= > bottom > and interpret as I have not seen what is below the comment. > >> LoST: A Location-to-Service Translation Protocol >> draft-ietf-ecrit-lost-03.txt >> >> Abstract >> >> This document describes an XML-based protocol for mapping service >> identifiers and geodetic or civic location information to service >> contact URIs. In particular, it can be used to determine the >> location-appropriate PSAP for emergency services. > > FYI: I have always been nervous when using as an index something =20 > that is a > well known abstraction of a location, such as a civic location. > My argument all the time has been that the most important piece of the > puzzle is that "the device" have some kind of identifier that later =20= > can be > mapped to a PSAP. Secondly (and not the same, note that) that the =20 > device can > send information to the PSAP so that the PSAP can (at least in =20 > Sweden) (a) > locate the device and (b) reinitiate the connection if the =20 > communication > breaks. > > I have seen too many discussions in ECRIT where the two uses of "the > location" (the routing issue, and the data that is sent to the =20 > PSAP) is > claimed to be the same. > > Anyway... You have heard me saying this before :-) > >> Table of Contents >> >> 1. >> Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 >> 2. Terminology and Requirements >> Notation . . . . . . . . . . . . 6 >> 3. Overview of Protocol >> Usage . . . . . . . . . . . . . . . . . . 7 >> 4. LoST Uniform Resource Locators and Their Resolution . . . . . >> 8 >> 5. The >> Element . . . . . . . . . . . . . . . . . . . . 9 >> 5.1. Data source and version: The 'source', 'sourceId' and >> 'version' >> Attributes . . . . . . . . . . . . . . . . . . . 9 >> 5.2. Time of Last Update: The 'lastUpdated' >> Attribute . . . . . 9 >> 5.3. Validity: The 'expires' >> Attribute . . . . . . . . . . . . 9 >> 5.4. Describing the Service with the Element . . >> 10 >> 5.5. The Mapped Service: the Element . . . . . . . . >> 10 >> 5.6. Defining the Service Region with the >> >> Element . . . . . . . . . . . . . . . . . . . . . . . . . 10 >> 5.7. Service Boundaries by Reference: the >> Element . . . . . . . . . . . . >> 11 >> 5.8. The Service >> Number . . . . . . . . . . . . . . . . . . . . 11 >> 5.9. Service URLs: the >> Element . . . . . . . . . . . . . 11 >> 6. Path of Request: >> Element . . . . . . . . . . . . . . . 12 >> 7. Mapping a Location and Service to URLs: >> . . . . 13 >> 7.1. >> Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13 >> 7.2. >> Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13 >> 7.2.1. Example Using Geodetic Coordinates . . . . . . . . . . >> 13 >> 7.2.2. Civic Address Mapping Example . . . . . . . . . . . . >> 14 >> 7.3. Components of the Request . . . . . . . . . >> 16 >> 7.3.1. The >> Element . . . . . . . . . . . . . . . . 16 >> 7.3.2. Identifying the Service: The Element . . . >> 17 >> 7.3.3. >> Recursion . . . . . . . . . . . . . . . . . . . . . . 17 >> 7.3.4. Service >> Boundary . . . . . . . . . . . . . . . . . . . 17 >> 7.3.5. Requesting Civic Location Validation . . . . . . . . . >> 17 >> 7.4. Components of the Mapping Response >> >> . . . . . . . . . . . . . . . . . . 19 >> 7.4.1. >> Overview . . . . . . . . . . . . . . . . . . . . . . . 19 >> 7.4.2. Civic Address Validation: the >> >> Element . . . . . . . . . . . . . 20 >> 8. Retrieving the Service Boundary via . . . >> 21 >> 9. List Services: >> . . . . . . . . . . . . . . . . 24 >> 10. List Services By Location: >> . . . . . 25 >> 11. Location >> Profiles . . . . . . . . . . . . . . . . . . . . . . 27 >> >> >> >> Hardie, et al. Expires July 21, 2007 >> [Page 2] >> Internet-Draft LoST January >> 2007 >> >> >> 11.1. Location Profile >> Usage . . . . . . . . . . . . . . . . . . 28 >> 11.2. Two Dimensional Geodetic >> Profile . . . . . . . . . . . . . 30 >> 11.3. Basic Civic >> Profile . . . . . . . . . . . . . . . . . . . 31 >> 12. Errors, Warnings, and >> Redirects . . . . . . . . . . . . . . . 32 >> 12.1. >> Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 32 >> 12.2. >> Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 33 >> 12.3. >> Redirects . . . . . . . . . . . . . . . . . . . . . . . . 34 >> 13. LoST >> Transport . . . . . . . . . . . . . . . . . . . . . . . . 35 >> 14. Relax NG >> Schema . . . . . . . . . . . . . . . . . . . . . . . 36 >> 15. Internationalization >> Considerations . . . . . . . . . . . . . 43 >> 16. IANA >> Considerations . . . . . . . . . . . . . . . . . . . . . 44 >> 16.1. U-NAPTR >> Registrations . . . . . . . . . . . . . . . . . . 44 >> 16.2. Content-type registration for 'application/lost >> +xml' . . . 44 >> 16.3. LoST Relax NG Schema >> Registration . . . . . . . . . . . . 46 >> 16.4. LoST Namespace >> Registration . . . . . . . . . . . . . . . 46 >> 16.5. URL Registration >> Template . . . . . . . . . . . . . . . . 47 >> 16.6. LoST Location Profile >> Registry . . . . . . . . . . . . . . 48 >> 17. Security >> Considerations . . . . . . . . . . . . . . . . . . . 49 >> 18. >> Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 >> 19. Open >> Issues . . . . . . . . . . . . . . . . . . . . . . . . . 52 >> 20. >> References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 >> 20.1. Normative >> References . . . . . . . . . . . . . . . . . . . 53 >> 20.2. Informative >> References . . . . . . . . . . . . . . . . . . 54 >> Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . >> 55 >> Authors' >> Addresses . . . . . . . . . . . . . . . . . . . . . . . . 69 >> Intellectual Property and Copyright Statements . . . . . . . . . . >> 70 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hardie, et al. Expires July 21, 2007 >> [Page 3] >> Internet-Draft LoST January >> 2007 >> >> >> 1. Introduction >> >> This document describes a protocol for mapping a service =20 >> identifier >> [10] and location information compatible with PIDF-LO [8], namely >> revised civic location information [11] and GML [13]) to one or >> more >> service URL. Example service URL schemes include sip [14], xmpp >> [15], and tel [16]. While the initial focus is on providing >> mapping >> functions for emergency services, it is likely that the =20 >> protocol is >> applicable to any service URN. For example, in the United States, >> the "2-1-1" and "3-1-1" service numbers follow a similar >> location-to- >> service behavior as emergency services. >> >> This document names this protocol "LoST", for Location-to-Service >> Translation. LoST Satisfies the requirements [18] for mapping >> protocols. LoST provides a number of operations, centered around >> mapping locations and service URNs to service URLs and associated >> information. LoST mapping queries can contain either civic or >> geodetic location information. For civic addresses, LoST can >> indicate which parts of the civic address are known to be valid or >> invalid, thus providing address validation (see Section 3.5 of =20 >> [18] >> for a description of validation). LoST indicates errors in the >> location data to facilitate debugging and proper user feedback, =20= >> but >> also provides best-effort answers. >> >> LoST queries can be resolved recursively or iteratively. To >> minimize >> round trips and to provide robustness against network failures, >> LoST >> caches individual mappings and indicates the region for which the >> same answer would be returned ("service region"). > > Hmm...so LoST include caching. This is the first thing I think one =20 > should > look at. Who defines the appropriate caching time? Do you need =20 > notifications > for emergency updates? Etc? > >> As defined in this document, LoST messages are carried in HTTP and >> HTTPS protocol exchanges, facilitating use of TLS for protecting >> the >> integrity and confidentiality of requests and responses. > > Oh, no! Not HTTP again!!! Why? Also, you can not rely on client =20 > certificates > or other mechanisms for the authentication of the client sending =20 > the query. > You need another layer of username/password/ whatever on top of =20 > TLS. TLS is > usable for the encryption of the traffic, but not (much) more. > > This implies to me that the payload that is moved with the HTTP =20 > protocol > have to include enough signatures, passwords, usernames and possibly > encryption to handle the authentication and authorization of the LoST > transaction. > > Lets see below how this problem is resolved. > >> This document focuses on the description of the protocol between >> the >> mapping client (seeker or resolver) and the mapping server >> (resolver >> or other servers). The relationship between other functions, such >> as >> discovery of mapping servers, data replication and the overall >> mapping server architecture are described in a separate document >> [19]. >> >> The query message carries location information and a service >> identifier encoded as a Uniform Resource Name (URN) (see [10]) =20 >> from >> the LoST client to the LoST server. The LoST server uses its >> database to map the input values to one or more Uniform Resource >> Identifiers (URI) and returns those URIs along with optional >> information, such as hints about the service boundary, in a >> response >> message to the LoST client. If the server cannot resolve the =20 >> query >> itself, it may in turn query another server or return the address >> of >> >> >> >> Hardie, et al. Expires July 21, 2007 >> [Page 4] >> Internet-Draft LoST January >> 2007 >> >> >> another LoST server, identified by a LoST URL (Section 4). > > I am a little bit nervous about the fact that the server can either > give back a referral OR do a recursive query. For the client the > difference is of course that all clients MUST implement the ability > to handle referrals, but on the other hand, the ability for a server > to query another server might not have to be in this document. Why is > that needed? Because it is needed to know wether the data comes from > an authoritative source? Or "just" because it imitates the way DNS > works? > > We'll see. > >> In >> addition to the mapping function described in Section 7, the >> protocol >> also allows to retrieve the service boundary (see Section 8) =20 >> and to >> list the services available for a particular location (see >> Section 10) or supported by a particular server (see Section 9). >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hardie, et al. Expires July 21, 2007 >> [Page 5] >> Internet-Draft LoST January >> 2007 >> >> >> 2. Terminology and Requirements Notation >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL =20 >> NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in >> this >> document are to be interpreted as described in [1]. >> >> This document furthermore uses the terminology defined in [18]. > > "Warning" :-) I have not read this [18] document. > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hardie, et al. Expires July 21, 2007 >> [Page 6] >> Internet-Draft LoST January >> 2007 >> >> >> 3. Overview of Protocol Usage >> >> The client may perform the mapping at any time. Among the common >> triggers for mapping requests are: >> >> 1. When the client initially starts up or attaches to a network. >> >> 2. When the client detects that its location has changed >> sufficiently that it is outside the bounds of the service >> region >> returned in an earlier LoST query. >> >> 3. When cached mapping information has expired. >> >> 4. When invoking a particular service. At that time, a client =20= >> may >> omit requests for service boundaries or other auxiliary >> information. >> >> A service-specific Best Current Practice (BCP) document, such as >> [20], governs whether a client is expected to invoke the mapping >> service just before needing the service or whether to rely on >> cached >> answers. Cache entries expire at their expiration time (see >> Section 5.3), or they become invalid if the caller's device moves >> beyond the boundaries of the service region. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hardie, et al. Expires July 21, 2007 >> [Page 7] >> Internet-Draft LoST January >> 2007 >> >> >> 4. LoST Uniform Resource Locators and Their Resolution >> >> LoST servers are identified by LoST Uniform Resource Locators >> (URLs), >> which follow the format of URLs defined in RFC 3986 [7], with the >> following ABNF: >> >> LoST-URI =3D "lost:" host >> >> 'host' is defined in Section 3.2.2 of RFC 3986 [7]. >> >> An example is 'lost:lostserver.example.com' > > Have this URI spec been reviewed on the URI-review list? If not, I > urge you to pass it on asap. > >> If a LoST URL contains a host name rather than an IP address, >> clients >> need to use U-NAPTR [12] using the U-NAPTR specification described >> below to obtain a URI (indicating host and protocol) for the >> applicable LoST service. In this document, only the HTTP and =20 >> HTTPS >> URL schemes are defined. Note that the HTTP URL can be any valid >> HTTP URL, including those containing path elements. >> >> The following two DNS entries resolve the LoST URL >> "lost:example.com" >> to the HTTPS URL https://lostserv.example.com/secure or the HTTP >> URL >> http://lostserver.example.com, with the former being preferred. > > (1) Please use the same examples all the time. Above you use the > example lostserver.example.com, and now example.com. > > (2) Why do you not only use SRV records for this as lost is only > defined for HTTP/HTTPS? > > lost:example.com -> _lost._tcp.example.com:80 > > I do not see any need for NAPTR records, unless LOST can be used with > some other protocol than HTTP. That is though not what it seems the > overall design is for. > > I.e. possible over-engineering for an abstraction that in reality is > not, and will never, be used. > >> example.com. >> >> IN NAPTR 100 10 "u" "LoST:https" >> "!*.!https://lostserver.example.com/secure!" "" >> >> IN NAPTR 200 10 "u" "LoST:http" >> "!*.!http://lostserver.example.com!" "" > > How do the end device get the LOST URL? > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hardie, et al. Expires July 21, 2007 >> [Page 8] >> Internet-Draft LoST January >> 2007 >> >> >> 5. The Element >> >> The element is the core data element in LoST, >> describing a >> service region and the associated service URLs. Its parameters >> indicate when the mapping was last updated, how long it is >> valid, its >> version and the authoritative source for the mapping, along with a >> unique identifier. Elements within the element then >> provide a human-readable description, the service URN, a service >> boundary, the service URIs, and a service number. All elements >> except the service URN are optional. > > > Are really all elements optional? sourceId, version, and source > attributes as well? > > This draft contain a lot of words. Not as crisp as I would like to > see a protocol specification. Why for example does the above > paragraph point out "...provide a human-readable description..." etc, > and then the first thing that happen below in 5.1 is that it talks > about "Data source and version". Attributes that are not mentioned > above? > >> Below, we describe the >> components in turn. > > Unnecessary text. > >> 5.1. Data source and version: The 'source', 'sourceId' and 'version' >> Attributes >> >> The 'source', 'sourceId' and 'version' attributes uniquely >> identify a >> particular mapping record. They are created by the authoritative >> source for a mapping and never modified when a mapping is served >> from >> a cache. The 'source' attribute contains a LoST URL identifying >> the >> authoritative generator of the mapping. The 'sourceId' attribute >> identifies a particular mapping. > > Should not the URI definition include the ability to also include the > sourceId and version in the URI? > > Else you will not be able to get a URI for the record itself, and I > think that would be an opportunity that should not be missed. > >> The attribute contains a token, >> which is opaque, but MUST be unique among all different mappings >> maintained by the authoritative source for that particular =20 >> service. > > "The attribute" that this sentence talks about, is that the > "sourceId" attribute? Not clear. > > Why btw are several attributes in the same section of the spec? > Better with one attribute per section and a crisp short definition of > that attribute. > >> For example, a UUID is a suitable format. The 'version' >> attribute is >> a positive integer that is incremented by one for each change in >> the >> mapping. > > So if the difference between two records I happen to have is 4, there > MUST have been that number of versions in between? It is unclear in > this text as no MUST, SHOULD etc is in use if this increment of one > is mandatory or not. Makes the protocol unclear and might lead to > incompatible implementations. > >> Thus, a higher version number refers to a more recent >> mapping. A mapping maintains its sourceId value as long as it >> remains logically the same, e.g., represents the same service >> boundary or replaces an earlier service boundary. A receiver >> should > > Lower case "should" here... > >> be able to replace a mapping with another one having the same >> 'source' and 'sourceId' and a higher version number. All three >> attributes are REQUIRED for all elements. > > This is not what section 5 said above. > > You have an attack vector if someone manage to spoof a record into a > cache with a version number that is extremely high. How large can > this version number be? > >> 5.2. Time of Last Update: The 'lastUpdated' Attribute >> >> The 'lastUpdated' attribute describes when the mapping was last >> changed. The contents of this attribute is a timezoned XML type >> dateTime, in canonical representation. The attribute is REQUIRED. > > Note that according to 3.2.7.2 of http://www.w3.org/TR/2001/REC- > xmlschema-2-20010502/#dateTime (maybe I am looking at the wrong > source) the canonical representation of a time is always in UTC, so > the timezoned canonical version will always have 'Z' as the timezone > indicator. > > This is what you want? > >> 5.3. Validity: The 'expires' Attribute >> >> The 'expires' attribute contains the absolute time until which the >> mapping is to be considered valid. > > Does not "expires" contain the dateTime spec of when the mapping is > changing state from valid to not valid? The text above to me seems to > be the reverse. > >> The contents of this attribute is >> a timezoned XML type dateTime, in canonical representation. See >> Section 3 regarding how this value is to be utilized with a cache. >> The 'expires' attribute is REQUIRED to be included in the =20 >> >> element. >> >> >> >> >> Hardie, et al. Expires July 21, 2007 >> [Page 9] >> Internet-Draft LoST January >> 2007 >> >> >> On occasion, a resolver may be forced to return an expired >> mapping if >> it cannot reach the authoritative server or the server fails to >> return a usable answer. Seekers and resolvers MAY cache the >> mapping >> so that they have at least some information available. Resolvers >> SHOULD re-attempt the query each time a seeker requests a mapping. > > I think you should try to only use the terms "client" and "server" > throughout the document when you talk about the protocol. We already > know that a server can act as a proxy, and then act as a client. > > Try to not use the term "resolver". Experience from the DNS show it > is a confusing term. > >> 5.4. Describing the Service with the Element >> >> The element describes the service with a string >> that is >> suitable for display to human users, annotated with the 'xml:lang' >> attribute that contains a language tag to aid in the rendering of >> text. > > Why is lang tag needed for the rendering? Because of alternate > displayName elements with different lang tags? > >> 5.5. The Mapped Service: the Element > > Here you start talking about elements and not attributes. That is > confusing. > >> The 'service' element identifies the service for which this =20 >> mapping >> applies. It is usually the same service URN as in the request. > > Usually? That is an interesting term to have in a protocol > specification... :-) > >> However, if the requested service, identified by the service URN >> [10] >> in the element in the request, does not exist for the >> location indicated, the server can either return an >> (Section 12.1) error or can provide an >> alternate service that approximates the desired service for that >> location. > > But if the response is , is that "error" part > of the element? We talk about the content of the > element here, and I see either the URN of the service, or the URN of > an alternative service. Not a third alternative. > > Once again, not crisp enough, risk that the result is non- > interoperable implementations. > >> In the latter case, the server MUST include a >> element with the alternative service URN. The choice of service >> URN >> is left to local policy, but the alternate service should be >> able to >> satisfy the original service request. The element may >> also >> be required if the mapping is to be digitally signed. > > Resolvability of that URN? It is not a lost URL that is given back so > it is a referral within the protocol? > >> 5.6. Defining the Service Region with the Element > > Element and not attribute again. > >> A response can indicate the region for which the service URL >> returned >> would be the same as in the actual query, the so-called _service >> region_. > > What is "can" in this sentence? What does that word imply? That it > might not indicate the same region as in the actual query? > >> The service region can be indicated by value or by >> reference (see Section 5.7). If a client moves outside the =20 >> service >> area and wishes to obtain current service data, it MUST send a new >> query with its current location. > > It is interesting to have "if...wishes...MUST" in the same sentence. > What if he do not wish to obtain current service data? I.e. the "if" > make the MUST loose its power. > >> The service region is described by >> value in one or more elements, each formatted >> according to a different location profile, identified by the >> 'profile' atribute. > > Change the order of the attributes...to me it seems this is a forward > reference to "profile" attribute that btw is not defined in section 5. > >> The client only processes the first element that >> it can understand according to its list of supported location >> profiles. Thus, the elements are alternative descriptions of the >> same service region, not additive geometries. > > What if there is a difference? Is a difference allowed? > >> The server returns all suitable service regions, using all >> available >> location profiles, so that intermediate caches have this >> information >> available for future queries. > > Is "suitable" same as "match the query"? > >> >> >> >> >> >> Hardie, et al. Expires July 21, 2007 >> [Page 10] >> Internet-Draft LoST January >> 2007 >> >> >> 5.7. Service Boundaries by Reference: the >> Element >> >> Since geodetic service boundaries may contain thousands of >> points and >> thus be quite large, > > Can it? Hmmm....(reader start to think here)...yes it can! :-) > >> clients may opt to conserve bandwidth and >> request a reference to the service boundary instead of the value >> described in Section 5.6. The identifier of the service >> boundary is >> returned as an attribute of the =20 >> element, >> along with a LoST URL identifying the server from where it can be >> retrieved. > > Should the reference not be "just" a URL? (See above) > >> The actual value of the service boundary is then >> retrieved with the getServiceBoundary (Section 8) request. >> >> The identifier is a random token with at least 128 bits of entropy >> and can be assumed to be globally unique. It uniquely =20 >> references a >> particular boundary. If the boundary changes, a new identifier >> MUST >> be chosen. Because of these properties, a client receiving a >> mapping >> response can simply check if it already has a copy of the boundary >> with that identifier. > > Should the reference then not be a URL plus an identifier? > >> If so, it can skip checking with the server >> whether the boundary has been updated. Since service boundaries >> are >> likely to remain unchanged for extended periods of time, possibly >> exceeding the normal lifetime of the service URL, this approach >> avoids refreshing the boundary information even if the cached >> service >> response has gotten stale. > > ...even if the URL changes for the object. > >> >> 5.8. The Service Number > > Element or attribute? > >> The service number is returned in the optional >> element. > > Aha, element! > >> It contains a string of digits, * and # that a user on a >> device with a 12-key dial pad could use to reach that particular >> service. > > Reference a syntax specification. Max 15 char in the string as in E.=20= > 164? > >> 5.9. Service URLs: the Element >> >> The response returns the service URLs in one or more >> elements. >> The URLs MUST be absolute URLs. The ordering of the URLs has no >> particular significance. Each URL scheme MUST only appear at most >> once, but it is permissible to include both secured and regular >> versions of a protocol, such as both 'http' and 'https' or 'sip' >> and >> 'sips'. > > How to handle load balancing, or the fact two PSAPs might cover the > same area? > > Does that NEVER happen? > > Did this document not say earlier that all matching service areas > (and for me because of that srevice URLs) should be returned that > matches? This "one scheme only" to me say that the server must choose > "the best one", which seems weird. Or am I confused? > >> >> >> >> >> >> >> >> >> >> >> >> >> Hardie, et al. Expires July 21, 2007 >> [Page 11] >> Internet-Draft LoST January >> 2007 >> >> >> 6. Path of Request: Element >> >> To prevent loops and to allow tracing of request and response >> paths, >> all requests that allow recursion include a element that >> contains one or more elements, each possessing an attribute >> containing a LoST URL. The order of elements corresponds to >> the order of LoST servers, i.e., the first element =20 >> identifies >> the server that first received the request from the seeker. The >> authoritative server copies the element verbatim into the >> response. > > I don't know enough about XML to say whether this ordering is ok or > not. This is the first time ordering among elements exists in this > spec though. > >> If a query is answered iteratively, the querier includes all >> servers >> that it has already contacted. >> >> The example in Figure 5 indicates that the answer was given to the >> responding server by the LoST server at esgw.ueber-110.de.example, >> which got the answer from the LoST server at >> polizei.muenchen.de.example. > > This is also sent in a request? How else can one prevent loops if a > server is acting as a client and do a recursive search, walking into > servers that the originator already have queried? > > I don't understand exactly how this can help with loop prevention. > Just how it can help loop detection on the client side. If it is not > passed also in requests. > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hardie, et al. Expires July 21, 2007 >> [Page 12] >> Internet-Draft LoST January >> 2007 >> >> >> 7. Mapping a Location and Service to URLs: >> >> 7.1. Overview >> >> The query constitutes the core of the LoST >> functionality, mapping civic or geodetic locations to URLs and >> associated data. After giving an example, we enumerate the >> elements >> of the query and response. >> >> 7.2. Examples >> >> 7.2.1. Example Using Geodetic Coordinates >> >> The following is an example of mapping a service to a location >> using >> geodetic coordinates, for the service associated with the police >> (urn:service:sos.police). >> >> >> >> > xmlns=3D"urn:ietf:params:xml:ns:lost1" >> xmlns:p2=3D"http://www.opengis.net/gml" >> serviceBoundary=3D"value" >> recursive=3D"true"> >> >> >> >> 37.775 -122.422 >> >> >> urn:service:sos.police >> >> >> >> Figure 2: A geodetic query >> >> Given the query above, a server would respond with a service, and >> information related to that service. In the example below, the >> server has mapped the location given by the client for a police >> service to the New York City Police Deparment, instructing the >> client >> that it may contact them via the URIs "sip:nypd@example.com" and >> "xmpp:nypd@example.com". The server has also given the client a >> geodetic, two-dimensional boundary for this service. The >> mapping was >> last updated on November 1, 2006 and expires on January 1, 2007. >> This instructs the client that if its location changes beyond the >> give service boundary or the expiration time has been reached, it >> would need to requery for this information. > > Does "lastUpdated" imply that it is correct from that point in time? > To me that is not crystal clear. One might update a record one month > ahead of a move for example. > >> >> >> >> >> Hardie, et al. Expires July 21, 2007 >> [Page 13] >> Internet-Draft LoST January >> 2007 >> >> >> >> > xmlns:p2=3D"http://www.opengis.net/gml"> >> > expires=3D"2007-01-01T01:44:33Z" >> lastUpdated=3D"2006-11-01T01:00:00Z" >> source=3D"lost:authoritative.example" >> sourceId=3D"7e3f40b098c711dbb6060800200c9a66" version=3D"1"> >> >> New York City Police Department >> >> urn:service:sos.police >> >> >> >> >> 37.775 -122.4194 >> 37.555 -122.4194 >> 37.555 -122.4264 >> 37.775 -122.4264 >> 37.775 -122.4194 >> >> >> >> >> sip:nypd@example.com >> xmpp:nypd@example.com >> 911 >> >> >> >> >> >> >> >> Figure 3: A geodetic answer >> >> 7.2.2. Civic Address Mapping Example >> >> The following is an example of mapping a service to a location =20 >> much >> like the example in Section 7.2.1, but using civic address =20 >> location >> information. In this example, the client requests the service >> associated with police (urn:service:sos.police) along with a >> specific >> civic address (house number 6 on a street named Otto-Hahn-Ring in >> Munich, Germany). >> >> >> >> >> >> >> Hardie, et al. Expires July 21, 2007 >> [Page 14] >> Internet-Draft LoST January >> 2007 >> >> >> >> > recursive=3D"true" serviceBoundary=3D"value"> >> > profile=3D"civic"> >> > xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> >> Germany >> Bavaria >> Munich >> Otto-Hahn-Ring >> 6 >> 81675 >> >> >> urn:service:sos.police >> >> >> Figure 4: A civic address query >> >> Given the query above, a server would respond with a service, and >> information related to that service. In the example below, the >> server has mapped the location given by the client for a police >> service to the Muenchen Polizei-Abteilung, instructing the client >> that it may contact them via the URIs sip:munich-=20 >> police@example.com >> and xmpp:munich-police@example.com. The server has also given the >> client a civic address boundary (the city of Munich) for this >> service. The mapping was last updated on November 1, 2006 by the >> authoritative source "lost:polizei.muenchen.de.example" and =20 >> expires >> on January 1, 2007. This instructs the client to requery for the >> information if its location changes beyond the given service >> boundary >> (i.e., beyond the city of Munich) or after January 1, 2007. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hardie, et al. Expires July 21, 2007 >> [Page 15] >> Internet-Draft LoST January >> 2007 >> >> >> >> >> > expires=3D"2007-01-01T01:44:33Z" >> lastUpdated=3D"2006-11-01T01:00:00Z" >> source=3D"lost:esgw.ueber-110.de.example" >> sourceId=3D"e8b05a41d8d1415b80f2cdbb96ccf109" version=3D"1" > >> >> Muenchen Polizei-Abteilung >> >> urn:service:sos.police >> > profile=3D"urn:ietf:params:lost:location-profile:basic-civic">= >> > xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> >> Germany >> Bavaria >> Munich >> 81675 >> >> >> sip:munich-police@example.com >> xmpp:munich-police@example.com >> 110 >> >> >> >> >> >> >> >> Figure 5: A civic address answer >> >> 7.3. Components of the Request >> >> The request includes attributes that govern >> whether the >> request is handled iteratively or recursively, whether location >> validation is performed and which elements must be contained in =20= >> the >> response. >> >> 7.3.1. The Element >> >> The query communicates location using one or more >> elements, which MUST conform to a location profile (see >> Section 11). There MUST be no more than one location element for >> each distinct location profile. The order of location objects is >> significant; the server uses the first location object where it >> understands the location profile. > > Ok, more ordering here. I presume that is ok... > > Using the first it understand is good. > >> >> >> >> Hardie, et al. Expires July 21, 2007 >> [Page 16] >> Internet-Draft LoST January >> 2007 >> >> >> 7.3.2. Identifying the Service: The Element >> >> The type of service desired is specified by the element. >> It contains service URNs from the registry established in [10]. >> >> 7.3.3. Recursion >> >> LoST and queries can be >> recursive, as indicated by the 'recursive' attribute. A value of >> "true" indicates a recursive query, with the default being "false" >> when the attribute is omitted. In recursive mode, the LoST server >> initiates queries on behalf of the requester and returns the =20 >> result >> to the requester, inserting a element to track the response >> chain. The elements are appended in responses in order of >> visit, i.e., the first element contains the authoritative >> server and elements below indicate servers that the response >> traversed on its way back to the original querier. > > Do you need time stamps on the via headers? > >> 7.3.4. Service Boundary >> >> LoST elements can describe the service boundary =20 >> either by >> value or by reference. Returning a service boundary reference is >> generally more space-efficient for geospatial (polygon) boundaries >> and if the boundaries change rarely, but does incur an additional >> request. The querier can express a =20 >> preference >> for one or the other modality with the 'serviceBoundary' >> attribute in >> the request, but the server makes the final >> decision as >> to whether to return a reference or a value. Servers SHOULD NOT >> return a by-value service boundaries if the querier requested a >> reference. >> >> 7.3.5. Requesting Civic Location Validation >> >> Civic address validation is requested by setting the optional >> attribute 'validateLocation' to true. If the attribute is =20 >> omitted, >> it is assumed to be false. The response is described in >> Section 7.4.2. The example in Figure 6 demonstrates address >> validation, omitting the standard response elements. >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hardie, et al. Expires July 21, 2007 >> [Page 17] >> Internet-Draft LoST January >> 2007 >> >> >> >> > xmlns=3D"urn:ietf:params:xml:ns:lost1" >> recursive=3D"true" >> validateLocation=3D"true" >> serviceBoundary=3D"value"> >> >> > xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> >> DE >> Bavaria >> Munich >> Otto-Hahn-Ring >> 6 >> 81675 >> >> >> urn:service:sos.police >> >> >> Figure 6: A query with address validation request >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hardie, et al. Expires July 21, 2007 >> [Page 18] >> Internet-Draft LoST January >> 2007 >> >> >> >> >> > expires=3D"2007-01-01T01:44:33Z" >> lastUpdated=3D"2006-11-01T01:00:00Z" >> source=3D"lost:authoritative.example" >> sourceId=3D"4db898df52b84edfa9b6445ea8a0328e" >> version=3D"1" > >> >> Muenchen Polizei-Abteilung >> >> urn:service:sos.police >> >> > xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> >> Germany >> Bavaria >> Munich >> 81675 >> >> >> sip:munich-police@example.com >> xmpp:munich-police@example.com >> 110 >> >> >> country A1 A3 A6 >> PC >> >> >> >> >> >> >> >> Figure 7: A message with address =20 >> validation >> information >> > > I stopped here, as the findServiceResponse needed a lot of thinking. > I do not have that before monday next week. > > > Patrik > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 31 10:54:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHmN-0000Ku-Eg; Wed, 31 Jan 2007 10:53:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHmM-0000Kj-8y for ecrit@ietf.org; Wed, 31 Jan 2007 10:53:46 -0500 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCHmG-00017K-8D for ecrit@ietf.org; Wed, 31 Jan 2007 10:53:46 -0500 Received: from [172.16.10.88] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 31 Jan 2007 10:52:56 -0500 id 015880C8.45C0BB58.00006906 In-Reply-To: <820CBAE7-481A-4479-B32D-E00182BBB9DC@cisco.com> References: <004b01c74547$4435ce80$290d0d0a@amer.cisco.com> <820CBAE7-481A-4479-B32D-E00182BBB9DC@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable Message-Id: <466714CE-ADC6-4E9A-AA75-DBE84FC1C83D@hxr.us> From: Andrew Newton Subject: Re: [Ecrit] LoST Review Date: Wed, 31 Jan 2007 10:53:34 -0500 To: "=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Patrik, thanks for the read. You found a lot of readability issues. In-line you will find my responses to some of the issues: On Jan 31, 2007, at 9:55 AM, Patrik F=E4ltstr=F6m wrote: >> Oh, no! Not HTTP again!!! Why? Also, you can not rely on client =20 >> certificates >> or other mechanisms for the authentication of the client sending =20 >> the query. >> You need another layer of username/password/ whatever on top of =20 >> TLS. TLS is >> usable for the encryption of the traffic, but not (much) more. A couple of counter comments: 1) We've been back and forth on HTTP. As anybody who has read this =20 list knows, I've proposed other solutions. But we've settled here as =20= a compromise. So I think it is fair that the group can ask "Why not =20 HTTP?" 2) I agree that client side certs will not work, but it is not a =20 technology issue. They certainly work technically. But the =20 deployment model makes any type of client side authentication difficult. >> I am a little bit nervous about the fact that the server can either >> give back a referral OR do a recursive query. For the client the >> difference is of course that all clients MUST implement the ability >> to handle referrals, but on the other hand, the ability for a server >> to query another server might not have to be in this document. Why is >> that needed? Because it is needed to know wether the data comes from >> an authoritative source? Or "just" because it imitates the way DNS >> works? I agree. We need to clarify this. >> (2) Why do you not only use SRV records for this as lost is only >> defined for HTTP/HTTPS? >> >> lost:example.com -> _lost._tcp.example.com:80 >> >> I do not see any need for NAPTR records, unless LOST can be used with >> some other protocol than HTTP. That is though not what it seems the >> overall design is for. >> >> I.e. possible over-engineering for an abstraction that in reality is >> not, and will never, be used. First, we do want the ability to specify full HTTP URIs in the =20 resolution process. Second, we have talked about other protocols. =20 The compromise to stick only with HTTP is that we don't have enough =20 deployment experience, but we'd like the ability to do something =20 later if necessary. >> How do the end device get the LOST URL? Via DHCP and other configuration methods. >> Are really all elements optional? sourceId, version, and source >> attributes as well? Good catch. The mapping in the schema says they are not: div { mapping =3D element ns1:mapping { element ns1:displayName { xsd:string, attribute xml:lang { xsd:language } }*, service, (serviceBoundary | serviceBoundaryReference)?, element ns1:uri { xsd:anyURI }*, element ns1:serviceNumber { xsd:string { pattern =3D "[0-9*#]+" } }?, extensionPoint, expires, attribute lastUpdated { xsd:dateTime }, source, attribute sourceId { xsd:token }, attribute version { xsd:positiveInteger }, message } } >> This draft contain a lot of words. Not as crisp as I would like to >> see a protocol specification. Why for example does the above >> paragraph point out "...provide a human-readable description..." etc, >> and then the first thing that happen below in 5.1 is that it talks >> about "Data source and version". Attributes that are not mentioned >> above? I agree. >> Should not the URI definition include the ability to also include the >> sourceId and version in the URI? >> >> Else you will not be able to get a URI for the record itself, and I >> think that would be an opportunity that should not be missed. There is no need for this. Plus, a specific may not =20 apply. It depends on the input. >>> 5.2. Time of Last Update: The 'lastUpdated' Attribute >>> >>> The 'lastUpdated' attribute describes when the mapping was last >>> changed. The contents of this attribute is a timezoned XML type >>> dateTime, in canonical representation. The attribute is =20 >>> REQUIRED. >> >> Note that according to 3.2.7.2 of http://www.w3.org/TR/2001/REC- >> xmlschema-2-20010502/#dateTime (maybe I am looking at the wrong >> source) the canonical representation of a time is always in UTC, so >> the timezoned canonical version will always have 'Z' as the timezone >> indicator. >> >> This is what you want? I think so, though we could be a bit more explicit, huh? >> Why is lang tag needed for the rendering? Because of alternate >> displayName elements with different lang tags? Yes. >>> It contains a string of digits, * and # that a user on a >>> device with a 12-key dial pad could use to reach that particular >>> service. >> >> Reference a syntax specification. Max 15 char in the string as in =20 >> E.164? I don't believe emergency numbers such as 911 or 112 or E.164 numbers. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 31 10:54:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHnW-0000rj-Lo; Wed, 31 Jan 2007 10:54:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHnU-0000ow-0d for ecrit@ietf.org; Wed, 31 Jan 2007 10:54:57 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCHnQ-0001RK-Qb for ecrit@ietf.org; Wed, 31 Jan 2007 10:54:55 -0500 Received: from [10.20.132.53] (vpn-128-59-249-14.vpn.columbia.edu [128.59.249.14]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0VFsgtu011115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 31 Jan 2007 10:54:45 -0500 (EST) In-Reply-To: <004b01c74547$4435ce80$290d0d0a@amer.cisco.com> References: <004b01c74547$4435ce80$290d0d0a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5EBB42EF-6E6F-40B3-86A1-480C20AEC3C0@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST Review - part 1 Date: Wed, 31 Jan 2007 10:54:40 -0500 To: "Marc Linsner" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Comments on the comments; I'm hoping that Patrik is on the list. Thanks for the comments! To simplify discussion a bit, I'm stripping out the text. I think most of the comments can be understood as-is. On Jan 31, 2007, at 9:51 AM, Marc Linsner wrote: > Hannes and I asked Patrik Falstrom to review the LoST/Mapping Arch > drafts....here is the first of his comments..... > ...................................................................... > ...... > > FYI: I have always been nervous when using as an index something > that is a > well known abstraction of a location, such as a civic location. > My argument all the time has been that the most important piece of the > puzzle is that "the device" have some kind of identifier that later > can be > mapped to a PSAP. Secondly (and not the same, note that) that the > device can > send information to the PSAP so that the PSAP can (at least in > Sweden) (a) > locate the device and (b) reinitiate the connection if the > communication > breaks. > > I have seen too many discussions in ECRIT where the two uses of "the > location" (the routing issue, and the data that is sent to the > PSAP) is > claimed to be the same. > > Anyway... You have heard me saying this before :-) > LoST only deals with mapping and doesn't say anything about whether the same location is delivered to the PSAP. Indeed, for geo, this is unlikely to be the case if the device moves around. Thus, I don't understand the comment. > > Hmm...so LoST include caching. This is the first thing I think one > should > look at. Who defines the appropriate caching time? Do you need > notifications > for emergency updates? Etc? > The authoritative server defines the object lifetime, as discussed later. There are several other layers of indirection, such as DNS NAPTR, SRV and proxies, that are much better for short-term changes. Duplicating this at the LoST level seems unlikely to be effective or necessary. > > Oh, no! Not HTTP again!!! Why? Also, you can not rely on client > certificates Because it works :-) > or other mechanisms for the authentication of the client sending > the query. > You need another layer of username/password/ whatever on top of > TLS. TLS is > usable for the encryption of the traffic, but not (much) more. > Hmm, server certs seem to be fairly widespread. If they are deeply problematic, I think the world has larger problems than the use of LoST over HTTP. > This implies to me that the payload that is moved with the HTTP > protocol > have to include enough signatures, passwords, usernames and possibly > encryption to handle the authentication and authorization of the LoST > transaction. > LoST deals with public information, so client authentication is generally not a concern. It is also not clear to me that if we should need client authentication, why Basic or Digest (or client certs) would not be sufficient. It would be helpful to have this concern elaborated on, as this is a fairly fundamental design issue. > > I am a little bit nervous about the fact that the server can either > give back a referral OR do a recursive query. For the client the > difference is of course that all clients MUST implement the ability > to handle referrals, but on the other hand, the ability for a server > to query another server might not have to be in this document. Why is > that needed? Because it is needed to know wether the data comes from > an authoritative source? Or "just" because it imitates the way DNS > works? > A server can obviously choose to only refer, so I don't quite understand the comment. The reason for referrals is two-fold: - allows intermediaries to cache results - avoids multiple trips across a possibly narrow-bandwidth last-hop link > > Have this URI spec been reviewed on the URI-review list? If not, I > urge you to pass it on asap. > Will do so. > > (1) Please use the same examples all the time. Above you use the > example lostserver.example.com, and now example.com. Noted. > > (2) Why do you not only use SRV records for this as lost is only > defined for HTTP/HTTPS? > > lost:example.com -> _lost._tcp.example.com:80 > > I do not see any need for NAPTR records, unless LOST can be used with > some other protocol than HTTP. That is though not what it seems the > overall design is for. > > I.e. possible over-engineering for an abstraction that in reality is > not, and will never, be used. I tend to agree with that simplification. > > How do the end device get the LOST URL? > Later. > > > Are really all elements optional? sourceId, version, and source > attributes as well? > Just the elements, not the attributes. Maybe that's too non-obvious a distinction. > This draft contain a lot of words. Not as crisp as I would like to > see a protocol specification. Why for example does the above I'm always happy to remove text, as long as somebody else then doesn't complain that they need more examples, more background and design information and a longer security considerations section... > > Should not the URI definition include the ability to also include the > sourceId and version in the URI? > At this point, the URI does not attempt to provide the ability to issue arbitrary LoST queries. We'd have to add a lot more to the URI to be able to do this, such as the location information and query type. One could define a URI that allow to simply retrieve a specific mapping, but not be rich enough to express a query. > Else you will not be able to get a URI for the record itself, and I > think that would be an opportunity that should not be missed. > Retrieving a particular mapping by identifier (as opposed to by location) doesn't seem a particularly important operation for LoST, but I don't have a strong opinion on this. [Since this is getting far too long for a single message, I'll continue the discussion in a separate message.] > > Why btw are several attributes in > Do you need time stamps on the via headers? > Good question; unlike email, it seems highly unlikely (and broken) if the requests take more than a few milliseconds for each hop, so second-resolution timestamps are unlikely to be useful and below that, clock synchronization seems to make the timestamp more or less random. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 31 11:06:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHyf-0000G0-M2; Wed, 31 Jan 2007 11:06:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHye-0000Fn-Jz for ecrit@ietf.org; Wed, 31 Jan 2007 11:06:28 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCHya-0004rC-2W for ecrit@ietf.org; Wed, 31 Jan 2007 11:06:28 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 31 Jan 2007 17:06:23 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0VG6NIk027298; Wed, 31 Jan 2007 17:06:23 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0VG6IC8016168; Wed, 31 Jan 2007 17:06:23 +0100 (MET) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 17:06:18 +0100 Received: from [127.0.0.1] ([144.254.226.40]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 17:06:18 +0100 In-Reply-To: <466714CE-ADC6-4E9A-AA75-DBE84FC1C83D@hxr.us> References: <004b01c74547$4435ce80$290d0d0a@amer.cisco.com> <820CBAE7-481A-4479-B32D-E00182BBB9DC@cisco.com> <466714CE-ADC6-4E9A-AA75-DBE84FC1C83D@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Ecrit] LoST Review Date: Wed, 31 Jan 2007 17:06:17 +0100 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Jan 2007 16:06:18.0574 (UTC) FILETIME=[BE00CEE0:01C74551] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4282; t=1170259583; x=1171123583; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20 |Subject:=20Re=3A=20[Ecrit]=20LoST=20Review |Sender:=20; bh=FXZMP6Ef7njaw4syEVmus8BwOrfalCG69TtVB9KzQgc=; b=cMkX3duPY+KIjqdC+0ure1yZzH1dEVSzisRmlCzirB0goqVwQmKNT5N49UpNWwISKyNFuXDE X/mS7svwjMqsXMFE8aZQnTiTDEvtfXBGgqNBHuuVPbzlioW+U5fINqIf; Authentication-Results: ams-dkim-2; header.From=paf@cisco.com; dkim=pass (si g from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On 31 jan 2007, at 16.53, Andrew Newton wrote: > On Jan 31, 2007, at 9:55 AM, Patrik F=E4ltstr=F6m wrote: >>> Oh, no! Not HTTP again!!! Why? Also, you can not rely on client =20 >>> certificates >>> or other mechanisms for the authentication of the client sending =20 >>> the query. >>> You need another layer of username/password/ whatever on top of =20 >>> TLS. TLS is >>> usable for the encryption of the traffic, but not (much) more. > > A couple of counter comments: > > 1) We've been back and forth on HTTP. As anybody who has read this =20= > list knows, I've proposed other solutions. But we've settled here =20 > as a compromise. So I think it is fair that the group can ask "Why =20= > not HTTP?" Of course. Regarding the "real world", I do understand why you choose =20= HTTP. But, at the same time I will never stop asking "why http?" :-) > 2) I agree that client side certs will not work, but it is not a =20 > technology issue. They certainly work technically. But the =20 > deployment model makes any type of client side authentication =20 > difficult. Correct. I just would not like the architecture of the protocol rely =20 on the fact certs in both ends work for anything else than encrypting =20= the session. This was a generic advice I got as AD :-) from my wg =20 participants once upon a time. Maybe the current AD have a different =20 policy? >>> (2) Why do you not only use SRV records for this as lost is only >>> defined for HTTP/HTTPS? >>> >>> lost:example.com -> _lost._tcp.example.com:80 >>> >>> I do not see any need for NAPTR records, unless LOST can be used =20 >>> with >>> some other protocol than HTTP. That is though not what it seems the >>> overall design is for. >>> >>> I.e. possible over-engineering for an abstraction that in reality is >>> not, and will never, be used. > > First, we do want the ability to specify full HTTP URIs in the =20 > resolution process. Second, we have talked about other protocols. =20= > The compromise to stick only with HTTP is that we don't have enough =20= > deployment experience, but we'd like the ability to do something =20 > later if necessary. Ok, fine. >>> How do the end device get the LOST URL? > > Via DHCP and other configuration methods. Ok. Maybe that should be spelled out. >>> Should not the URI definition include the ability to also include =20= >>> the >>> sourceId and version in the URI? >>> >>> Else you will not be able to get a URI for the record itself, and I >>> think that would be an opportunity that should not be missed. > > There is no need for this. Plus, a specific may not =20 > apply. It depends on the input. Ok. >>>> 5.2. Time of Last Update: The 'lastUpdated' Attribute >>>> >>>> The 'lastUpdated' attribute describes when the mapping was last >>>> changed. The contents of this attribute is a timezoned XML type >>>> dateTime, in canonical representation. The attribute is =20 >>>> REQUIRED. >>> >>> Note that according to 3.2.7.2 of http://www.w3.org/TR/2001/REC- >>> xmlschema-2-20010502/#dateTime (maybe I am looking at the wrong >>> source) the canonical representation of a time is always in UTC, so >>> the timezoned canonical version will always have 'Z' as the timezone >>> indicator. >>> >>> This is what you want? > > I think so, though we could be a bit more explicit, huh? No no. I just wanted you to understand that the way *I* read your =20 spec, the dateTime will always be in UTC. Just so people do not =20 misunderstand what the paragraph in 5.2 say. I think using UTC is fine. >>>> It contains a string of digits, * and # that a user on a >>>> device with a 12-key dial pad could use to reach that particular >>>> service. >>> >>> Reference a syntax specification. Max 15 char in the string as in =20= >>> E.164? > > I don't believe emergency numbers such as 911 or 112 or E.164 numbers. Correct, as countries (Sweden at least) have as a requirement for E.=20 164 that it is possible to call an E.164 from any other E.164. They =20 are from the same "namespace" though...and because of that have =20 similar constraints. Maybe that is in the schema though? Patrik _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 31 11:15:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCI6y-0006tz-Rk; Wed, 31 Jan 2007 11:15:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCI6x-0006tq-LC for ecrit@ietf.org; Wed, 31 Jan 2007 11:15:03 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCI6w-000880-4O for ecrit@ietf.org; Wed, 31 Jan 2007 11:15:03 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 31 Jan 2007 17:15:01 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0VGF1Pf029916; Wed, 31 Jan 2007 17:15:01 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0VGF0C8018695; Wed, 31 Jan 2007 17:15:01 +0100 (MET) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 17:15:00 +0100 Received: from [127.0.0.1] ([144.254.226.40]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 17:15:00 +0100 In-Reply-To: <5EBB42EF-6E6F-40B3-86A1-480C20AEC3C0@cs.columbia.edu> References: <004b01c74547$4435ce80$290d0d0a@amer.cisco.com> <5EBB42EF-6E6F-40B3-86A1-480C20AEC3C0@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Ecrit] LoST Review - part 1 Date: Wed, 31 Jan 2007 17:14:58 +0100 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Jan 2007 16:15:00.0317 (UTC) FILETIME=[F4FC78D0:01C74552] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3937; t=1170260101; x=1171124101; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20 |Subject:=20Re=3A=20[Ecrit]=20LoST=20Review=20-=20part=201 |Sender:=20; bh=HdW3L2d+NTNUdrmu/nVaf3fjewGhyfdDzKyIf163Dfw=; b=KqaQClwWQpa5s9pbgzJuq7PwYw0a+NA8635zDXYZn20DjfjpHfwwEs8QmgHykdRq0ySbzDp+ hfKrjCJ7skLpvcCne8RoEur4rvjbUHNzylbjOSLm3B8TnmKes/2wLU9S; Authentication-Results: ams-dkim-2; header.From=paf@cisco.com; dkim=pass (si g from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On 31 jan 2007, at 16.54, Henning Schulzrinne wrote: > Comments on the comments; I'm hoping that Patrik is on the list. Yes I am. But I have not read all messages as you could see on my comments :-) >> or other mechanisms for the authentication of the client sending >> the query. >> You need another layer of username/password/ whatever on top of >> TLS. TLS is >> usable for the encryption of the traffic, but not (much) more. > > Hmm, server certs seem to be fairly widespread. If they are deeply > problematic, I think the world has larger problems than the use of > LoST over HTTP. Well, it all depends on what you use the fact the cert "worked" for. I just do not want you "trust" the cert more than what you in reality can. As we all know, certs of CAs exist in browsers that we never check, and if one get a question about a cert from an unknown CA, we all "just click ok-continue". The end result because of this is an encrypted session, with some automatic checks between the DN in the cert and domain name. That is not bad! I just do not want you (as architects of this protocol) trust the fact you manage to get a TLS session "too much", for some definition of "too much". >> I am a little bit nervous about the fact that the server can either >> give back a referral OR do a recursive query. For the client the >> difference is of course that all clients MUST implement the ability >> to handle referrals, but on the other hand, the ability for a server >> to query another server might not have to be in this document. Why is >> that needed? Because it is needed to know wether the data comes from >> an authoritative source? Or "just" because it imitates the way DNS >> works? > > A server can obviously choose to only refer, so I don't quite > understand the comment. The reason for referrals is two-fold: > > - allows intermediaries to cache results > > - avoids multiple trips across a possibly narrow-bandwidth last-hop > link I think referrals are good. But, my recommendation is always regarding these things that a server can always refuse a request on doing referral (because of load or whatever), and because of that clients must be able to manage without getting the referral request fulfilled. >> Are really all elements optional? sourceId, version, and source >> attributes as well? > > Just the elements, not the attributes. Maybe that's too non-obvious > a distinction. For me it was. Sorry... >> Should not the URI definition include the ability to also include the >> sourceId and version in the URI? > > At this point, the URI does not attempt to provide the ability to > issue arbitrary LoST queries. We'd have to add a lot more to the > URI to be able to do this, such as the location information and > query type. One could define a URI that allow to simply retrieve a > specific mapping, but not be rich enough to express a query. What I was thinking of was the fact a reference to an object seems to contain both a lost URI for the server one go to, and the ID of the object itself. I "just" had the idea that the lost uri spec could be extended just a little bit with an optional object id, so it is possible to express the location of a location object (or whatever you call it) with a URI (only). >> Why btw are several attributes in >> Do you need time stamps on the via headers? > > Good question; unlike email, it seems highly unlikely (and broken) > if the requests take more than a few milliseconds for each hop, so > second-resolution timestamps are unlikely to be useful and below > that, clock synchronization seems to make the timestamp more or > less random. "No" is a perfectly alright answer. I just wanted to know that you had been thinking of "more data in a via header"... Time was an example. Patrik _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 31 11:19:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIAt-0000Oy-TO; Wed, 31 Jan 2007 11:19:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIAs-0000OF-CN for ecrit@ietf.org; Wed, 31 Jan 2007 11:19:06 -0500 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCIAl-0001B9-Pe for ecrit@ietf.org; Wed, 31 Jan 2007 11:19:06 -0500 Received: from [172.16.10.88] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 31 Jan 2007 11:12:59 -0500 id 015880C8.45C0C00B.00006F14 In-Reply-To: References: <004b01c74547$4435ce80$290d0d0a@amer.cisco.com> <820CBAE7-481A-4479-B32D-E00182BBB9DC@cisco.com> <466714CE-ADC6-4E9A-AA75-DBE84FC1C83D@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable Message-Id: <5B5FE3B7-C03C-4CC2-830C-AA388DE468AB@hxr.us> From: Andrew Newton Subject: Re: [Ecrit] LoST Review Date: Wed, 31 Jan 2007 11:13:37 -0500 To: "=?ISO-8859-1?Q?\"Patrik_F=E4ltstr=F6m\"?=" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jan 31, 2007, at 11:06 AM, Patrik F=E4ltstr=F6m wrote: >>>>> 5.2. Time of Last Update: The 'lastUpdated' Attribute >>>>> >>>>> The 'lastUpdated' attribute describes when the mapping was last >>>>> changed. The contents of this attribute is a timezoned XML =20 >>>>> type >>>>> dateTime, in canonical representation. The attribute is =20 >>>>> REQUIRED. >>>> >>>> Note that according to 3.2.7.2 of http://www.w3.org/TR/2001/REC- >>>> xmlschema-2-20010502/#dateTime (maybe I am looking at the wrong >>>> source) the canonical representation of a time is always in UTC, so >>>> the timezoned canonical version will always have 'Z' as the =20 >>>> timezone >>>> indicator. >>>> >>>> This is what you want? >> >> I think so, though we could be a bit more explicit, huh? > > No no. I just wanted you to understand that the way *I* read your =20 > spec, the dateTime will always be in UTC. Just so people do not =20 > misunderstand what the paragraph in 5.2 say. > > I think using UTC is fine. Then you read it correctly... or said more accurately, your =20 interpretation is as we intended. I still think we could be a heck =20 of a lot more specific. >>>>> It contains a string of digits, * and # that a user on a >>>>> device with a 12-key dial pad could use to reach that =20 >>>>> particular >>>>> service. >>>> >>>> Reference a syntax specification. Max 15 char in the string as =20 >>>> in E.164? >> >> I don't believe emergency numbers such as 911 or 112 or E.164 =20 >> numbers. > > Correct, as countries (Sweden at least) have as a requirement for E.=20= > 164 that it is possible to call an E.164 from any other E.164. They =20= > are from the same "namespace" though...and because of that have =20 > similar constraints. Maybe that is in the schema though? =46rom the schema: element ns1:serviceNumber { xsd:string { pattern =3D "[0-9*#]+" } }?, We don't say anything about E.164. And E.164 numbers cannot be =20 dialed on a lot of phones. How do you dial the beginning "+" =20 character. These are dialstrings that must be recognized by the UA. -andy= _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 31 11:30:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCILN-0006Ee-Mw; Wed, 31 Jan 2007 11:29:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCILM-0006Dy-SL for ecrit@ietf.org; Wed, 31 Jan 2007 11:29:57 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCILL-0004cj-Ic for ecrit@ietf.org; Wed, 31 Jan 2007 11:29:56 -0500 Received: from [10.20.132.53] (vpn-128-59-249-14.vpn.columbia.edu [128.59.249.14]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0VGTpMU024741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 31 Jan 2007 11:29:52 -0500 (EST) In-Reply-To: <004b01c74547$4435ce80$290d0d0a@amer.cisco.com> References: <004b01c74547$4435ce80$290d0d0a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <39650993-F535-4586-B875-E241B07125FB@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST Review - part 2 Date: Wed, 31 Jan 2007 11:29:49 -0500 To: "Marc Linsner" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org More comments on comments. > >> For example, a UUID is a suitable format. The 'version' >> attribute is >> a positive integer that is incremented by one for each change in >> the >> mapping. > > So if the difference between two records I happen to have is 4, there > MUST have been that number of versions in between? It is unclear in > this text as no MUST, SHOULD etc is in use if this increment of one > is mandatory or not. Makes the protocol unclear and might lead to > incompatible implementations. > I'm not sure why this matters. If a version exists only for a femtosecond, did it really exist, even though nobody could ever see it? Did the tree fall in the forest if nobody heard the sound? What interoperability problem would you imagine? I'm trying to avoid unnecessary text. > > You have an attack vector if someone manage to spoof a record into a > cache with a version number that is extremely high. How large can > this version number be? > It's an XML integer. I don't think restricting the range would ameliorate that problem since being able to pick something that is only modestly large would have the same effect. Longer-term, these mappings will be signed. >> 5.2. Time of Last Update: The 'lastUpdated' Attribute >> >> The 'lastUpdated' attribute describes when the mapping was last >> changed. The contents of this attribute is a timezoned XML type >> dateTime, in canonical representation. The attribute is REQUIRED. > > Note that according to 3.2.7.2 of http://www.w3.org/TR/2001/REC- > xmlschema-2-20010502/#dateTime (maybe I am looking at the wrong > source) the canonical representation of a time is always in UTC, so > the timezoned canonical version will always have 'Z' as the timezone > indicator. > > This is what you want? Yes, unless there's a better alternative. (We definitely don't want to express time zones, since they don't add any value here.) > >> 5.3. Validity: The 'expires' Attribute >> >> The 'expires' attribute contains the absolute time until which the >> mapping is to be considered valid. > > Does not "expires" contain the dateTime spec of when the mapping is > changing state from valid to not valid? The text above to me seems to > be the reverse. This seems to be the same thing. It is valid until 'expires' arrives; I'll rephrase to use invalid. > > I think you should try to only use the terms "client" and "server" > throughout the document when you talk about the protocol. We already > know that a server can act as a proxy, and then act as a client. > > Try to not use the term "resolver". Experience from the DNS show it > is a confusing term. Please take a look at the architecture document, where these terms are defined, to see if they are sufficiently precise for our purposes. I'll avoid the terminology here, to avoid cross-references. As you say, they are probably not necessary here. > > Why is lang tag needed for the rendering? Because of alternate > displayName elements with different lang tags? > Yes. For example, in Canada, the mapping would presumably return both the English and French version. > >> A response can indicate the region for which the service URL >> returned >> would be the same as in the actual query, the so-called _service >> region_. > > What is "can" in this sentence? What does that word imply? That it > might not indicate the same region as in the actual query? MAY; fixed. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 31 11:52:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIgm-0003KC-2r; Wed, 31 Jan 2007 11:52:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIgk-0003JJ-DH for ecrit@ietf.org; Wed, 31 Jan 2007 11:52:02 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HCIgj-0003vs-2J for ecrit@ietf.org; Wed, 31 Jan 2007 11:52:02 -0500 Received: from [10.20.132.53] (vpn-128-59-249-14.vpn.columbia.edu [128.59.249.14]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0VGpwET001162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 31 Jan 2007 11:51:59 -0500 (EST) In-Reply-To: <004b01c74547$4435ce80$290d0d0a@amer.cisco.com> References: <004b01c74547$4435ce80$290d0d0a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <679E2B94-B917-49F7-AD85-B4484AD09C4E@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST Review - Part 3 Date: Wed, 31 Jan 2007 11:51:55 -0500 To: "Marc Linsner" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > Why btw are several attributes in the same section of the spec? > Better with one attribute per section and a crisp short definition of > that attribute. > Each definition is one or two sentences long; I broke them into paragraphs. > >> 5.6. Defining the Service Region with the Element > > Element and not attribute again. > I don't see the problem with defining an element here. > >> The service region can be indicated by value or by >> reference (see Section 5.7). If a client moves outside the >> service >> area and wishes to obtain current service data, it MUST send a new >> query with its current location. > > It is interesting to have "if...wishes...MUST" in the same sentence. > What if he do not wish to obtain current service data? I.e. the "if" > make the MUST loose its power. MUST is probably not quite appropriate here. It is a simple condition (if the client wants something, it needs to do something), so I removed it. > >> The client only processes the first element that >> it can understand according to its list of supported location >> profiles. Thus, the elements are alternative descriptions of the >> same service region, not additive geometries. > > What if there is a difference? Is a difference allowed? I don't understand this comment. > >> The server returns all suitable service regions, using all >> available >> location profiles, so that intermediate caches have this >> information >> available for future queries. > > Is "suitable" same as "match the query"? The paragraph is not really necessary; I just dropped it. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 31 12:28:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJGO-0007qR-78; Wed, 31 Jan 2007 12:28:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJGN-0007qI-8q for ecrit@ietf.org; Wed, 31 Jan 2007 12:28:51 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCJGI-00089W-4J for ecrit@ietf.org; Wed, 31 Jan 2007 12:28:51 -0500 Received: from [10.20.132.53] (vpn-128-59-249-14.vpn.columbia.edu [128.59.249.14]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0VHScBx006264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 31 Jan 2007 12:28:42 -0500 (EST) In-Reply-To: <004b01c74547$4435ce80$290d0d0a@amer.cisco.com> References: <004b01c74547$4435ce80$290d0d0a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5FD15326-FC3B-4F86-BA7B-200EBF0005D6@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST Review - part 4 Date: Wed, 31 Jan 2007 12:28:36 -0500 To: "Marc Linsner" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org >> [I'm skipping the parts where I made wording updates to hopefully address the issue.] >> The identifier is a random token with at least 128 bits of entropy >> and can be assumed to be globally unique. It uniquely >> references a >> particular boundary. If the boundary changes, a new identifier >> MUST >> be chosen. Because of these properties, a client receiving a >> mapping >> response can simply check if it already has a copy of the boundary >> with that identifier. > > Should the reference then not be a URL plus an identifier? > Not quite. It couldn't really be a LoST URL, unless we add the query type as an attribute to that URL. This doesn't seem to be a good approach. We clearly don't want to allow random URLs, such as an http or mailto URL here, so allowing URLs just seems to open up more error conditions. > >> 5.9. Service URLs: the Element >> >> The response returns the service URLs in one or more >> elements. >> The URLs MUST be absolute URLs. The ordering of the URLs has no >> particular significance. Each URL scheme MUST only appear at most >> once, but it is permissible to include both secured and regular >> versions of a protocol, such as both 'http' and 'https' or 'sip' >> and >> 'sips'. > > How to handle load balancing, or the fact two PSAPs might cover the > same area? We had a long discussion on this early on. We have several mechanisms at the SIP layer to do load balancing and it seems unwise and unnecessary to add another one, which would likely have to replicate much of the NAPTR and SRV (weight/priority) mechanisms. Also, as soon as you present multiple URIs with the same scheme, the client has to choose somehow, as presenting two URLs to the user and asking which one they like better is not too useful. If the two PSAPs are cooperating, they can easily define a record in the DNS to do randomization. In extreme cases such as territorial disputes, returning two s is probably a better option, although that still doesn't help the end user all that much. > > Did this document not say earlier that all matching service areas > (and for me because of that srevice URLs) should be returned that > matches? This "one scheme only" to me say that the server must choose > "the best one", which seems weird. Or am I confused? > We generally do not try to address overlapping service areas for one service, for the reasons above. I don't see how a user can make a reasonable choice. > I don't know enough about XML to say whether this ordering is ok or > not. This is the first time ordering among elements exists in this > spec though. > Ordering in XML seems common. After all, the outcome of
  • Boil water.
  • Add noodles and simmer for 5 minutes. is different from
  • Add noodles and simmer for 5 minutes.
  • Boil water. >> If a query is answered iteratively, the querier includes all >> servers >> that it has already contacted. >> >> The example in Figure 5 indicates that the answer was given to the >> responding server by the LoST server at esgw.ueber-110.de.example, >> which got the answer from the LoST server at >> polizei.muenchen.de.example. > > This is also sent in a request? How else can one prevent loops if a > server is acting as a client and do a recursive search, walking into > servers that the originator already have queried? > > I don't understand exactly how this can help with loop prevention. > Just how it can help loop detection on the client side. If it is not > passed also in requests. > > Yes, it is ("querier includes all servers it has already contacted"). If you have a hybrid iterative-recursive query, i.e,. that starts iteratively and then goes recursive, the initial query will have the list of servers already visited. > Does "lastUpdated" imply that it is correct from that point in time? > To me that is not crystal clear. One might update a record one month > ahead of a move for example. > We have not defined mappings that only become valid in the future. This is only used to indicate how long the mapping has been unchanged and is just an informational item. It is not strictly necessary for caching, so I'm happy to remove it. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 31 12:49:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJac-0000JL-6h; Wed, 31 Jan 2007 12:49:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJaW-0000DH-JC for ecrit@ietf.org; Wed, 31 Jan 2007 12:49:40 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCJWh-0004bM-A9 for ecrit@ietf.org; Wed, 31 Jan 2007 12:45:44 -0500 Received: from [10.20.132.53] (vpn-128-59-249-14.vpn.columbia.edu [128.59.249.14]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0VHjUY1014972 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 31 Jan 2007 12:45:32 -0500 (EST) In-Reply-To: References: <004b01c74547$4435ce80$290d0d0a@amer.cisco.com> <5EBB42EF-6E6F-40B3-86A1-480C20AEC3C0@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <234E4EAE-ED95-4E5D-98D7-22B39E588EC5@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST Review - part 1 Date: Wed, 31 Jan 2007 12:45:28 -0500 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > As we all know, certs of CAs exist in browsers that we never check, > and if one get a question about a cert from an unknown CA, we all > "just click ok-continue". The end result because of this is an > encrypted session, with some automatic checks between the DN in the > cert and domain name. > Once the CA or public key can't be verified, you could be talking to a man-in-the-middle instead, so the crypto property is also greatly diminished. Fortunately, it is unlikely that LoST is accessed through a user interface with click-happy users. > > I think referrals are good. But, my recommendation is always > regarding these things that a server can always refuse a request on > doing referral (because of load or whatever), and because of that > clients must be able to manage without getting the referral request > fulfilled. > Agreed and noted. > > Patrik _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit