From ecrit-bounces@ietf.org Mon Dec 05 18:31:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjPnq-0008Ba-JC; Mon, 05 Dec 2005 18:31:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjPno-0008Ax-SV for ecrit@megatron.ietf.org; Mon, 05 Dec 2005 18:31:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00754 for ; Mon, 5 Dec 2005 18:30:31 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjQ99-0007Jg-Bt for ecrit@ietf.org; Mon, 05 Dec 2005 18:53:28 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id for ; Mon, 5 Dec 2005 18:31:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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, 5 Dec 2005 15:31:00 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657503B88E67@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: Issue 23: list of uri's - draft-ietf-ecrit-requirements-01 edits Thread-Index: AcXvbgJjSdaLkHEUQOiR+60qVtTqMwKfp44Q From: "Roger Marshall" To: X-Spam-Score: 2.6 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Issue 23: list of uri's - draft-ietf-ecrit-requirements-01 edits 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org All: I'm picking up once again on getting all the issues listed at www.ietf-ecrit.org/issues/ resolved. Here's an easy one, which was mentioned at IETF64 and was logged by Rohan as issue 23: (thanks Rohan) Issue 23: Author: rohan Date: 2005-11-07.22:25:20 =20 Today the requirements doc specifies sip:, sips:, and tel: Why is tel: included and why don't we include im: and xmpp: URI schemes? Editor's Comment: My understanding is that a reference to tel:uri is needed for those use cases where the target might only be reachable via the PSTN. This might include slow-to-upgrade PSAPs or perhaps fallback call handling scenarios. Wrt additional uri's, I've added a couple (those provided). Though there are many other uri schemes listed in the IANA registry, I've capped the example list with "etc.", which at least implies that the list is not constrained. ORIGINAL TEXT: emergency address: The sip:uri, sips:uri, or tel:uri=20 which represents the address of the PSAP useful for the completion of=20 an emergency call. PROPOSED REPLACEMENT TEXT: emergency address: The uri scheme (e.g. sip:uri, sips:uri,=20 xmpp:uri, im:uri, tel:uri, etc.) which represents the address of the PSAP=20 useful for the completion of an emergency call. Objections? Please send to me and the list, along with new proposed text. This issue will be marked resolved after 10 days if no comments are received.=20 Thanks. Roger Marshall _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 05 18:56:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjQC0-0007SU-4C; Mon, 05 Dec 2005 18:56:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjQBy-0007SD-Fm for ecrit@megatron.ietf.org; Mon, 05 Dec 2005 18:56:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02947 for ; Mon, 5 Dec 2005 18:55:31 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjQXM-00081c-OM for ecrit@ietf.org; Mon, 05 Dec 2005 19:18:29 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Mon, 5 Dec 2005 18:56:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Date: Mon, 5 Dec 2005 15:56:11 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657503B88EA3@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Thread-Index: AcXUFeX8wpzsAP7sT7O87+dhkPMmoAADXQAgBC0wMeAFR3ldUA== From: "Roger Marshall" To: , X-Spam-Score: 2.6 (++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org NOTE: prior issue tracker url was wrong - should be: http://www.ietf-ecrit.org:8080/ecrit-req/ Brian: Issue 28 talks about some new proposed text to be placed at the end of the Introduction section. I've changed the text slightly from what you originally had, and is listed below: PROPOSED NEW TEXT (at end of Introduction): Ideally, the mapping protocol would yield a URI which would allow an=20 emergency call to be completed using IP end-to-end (via the Internet). =20 However, not all PSAPs may have IP based connectivity. Thus the URI=20 scheme cannot be fixed, and in fact may end up being a tel uri to allow=20 calls to be completed over the PSTN. Editor's Comment: This seems to be consistent with the definition of "emergency address" (see Terminology section), which lists tel:uri as one potential uri scheme. Objections? Please send to the list, along with new proposed text. This issue will be marked resolved after 10 days if no comments are received. Roger Marshall >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net]=20 >Sent: Tuesday, November 08, 2005 6:50 PM >To: Roger Marshall; ecrit@ietf.org >Subject: RE: [Ecrit] NENA Comments on=20 >draft-ietf-ecrit-requirements-00 -Alternate Routes > >Consider adding the following paragraph to the introductory=20 >text on mapping: > >Ideally, the mapping protocol would yield a URI which would=20 >allow an emergency call to be completed on the Internet. =20 >However, not all PSAPs may have IP based connectivity. Thus=20 >the URI scheme cannot be fixed, and in fact may end up being a=20 >tel uri to allow calls to be completed on the PSTN. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 05 20:49:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjRxJ-0005N3-1T; Mon, 05 Dec 2005 20:49:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjRxH-0005Mc-Qm for ecrit@megatron.ietf.org; Mon, 05 Dec 2005 20:49:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17347 for ; Mon, 5 Dec 2005 20:48:28 -0500 (EST) 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 1EjSIg-0004TL-DF for ecrit@ietf.org; Mon, 05 Dec 2005 21:11:26 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 05 Dec 2005 17:49:10 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB61mABn006967; Mon, 5 Dec 2005 17:49:08 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 17:48:56 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.121.59]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 17:48:55 -0800 Message-Id: <4.3.2.7.2.20051205193522.0326dbb8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Dec 2005 19:48:54 -0600 To: "Roger Marshall" , , From: "James M. Polk" Subject: RE: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes In-Reply-To: <8C837214C95C864C9F34F3635C2A657503B88EA3@SEA-EXCHVS-2.tele comsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 06 Dec 2005 01:48:56.0044 (UTC) FILETIME=[37F4EAC0:01C5FA07] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org A tel:uri has nothing to do with the receiver, and is not a routable uri scheme because it has no domain side of the URI. If the PSAP is not IP enabled, something is going to have to get the emeregency call to a ESGW, and a tel:uri is not that something that fixes this in the routing process. I can right now direct a SIP message with a Request-URI at a GW that will get to a SR to a phase 0 PSAP (the phase 0 comment is to elicit the fact that the PSAP is ancient). That Request URI may be a tel uri with the sequence 9999999999 or it could be PSAP1@colleyville.tx.us What matters is how the SIP element that has to route the message based on whatever URI decides where that message should go. If this is a known destination based a configured address, it still gets to that ESGW and SR and PSAP. I recommend the text below be rewritten to something like: "Ideally, the mapping protocol would yield a SIPS-URI which would allow an emergency call to be completed using IP end-to-end (via the Internet). However, securing the signaling path may cause unwanted failures, therefore a SIP URI map be the best attainable in some situations. If a tel:url is returned, this will require either prior knowledge of where to route this message, or to do an additional translation to a routable SIP or SIPS URI to forward towards the PSAP directly, or to the ESGW for non-IP-enabled PSAPs." At 03:56 PM 12/5/2005 -0800, Roger Marshall wrote: >NOTE: prior issue tracker url was wrong - should be: >http://www.ietf-ecrit.org:8080/ecrit-req/ > >Brian: > >Issue 28 talks about some new proposed text to be placed at the end of >the Introduction section. I've changed the text slightly from what you >originally had, and is listed below: > >PROPOSED NEW TEXT (at end of Introduction): >Ideally, the mapping protocol would yield a URI which would allow an >emergency call to be completed using IP end-to-end (via the Internet). >However, not all PSAPs may have IP based connectivity. Thus the URI >scheme cannot be fixed, and in fact may end up being a tel uri to allow >calls to be completed over the PSTN. > >Editor's Comment: This seems to be consistent with the definition of >"emergency address" (see Terminology section), which lists tel:uri as >one potential uri scheme. > >Objections? Please send to the list, along with new proposed text. This >issue will be marked resolved after 10 days if no comments are received. > > > >Roger Marshall > > > >-----Original Message----- > >From: Brian Rosen [mailto:br@brianrosen.net] > >Sent: Tuesday, November 08, 2005 6:50 PM > >To: Roger Marshall; ecrit@ietf.org > >Subject: RE: [Ecrit] NENA Comments on > >draft-ietf-ecrit-requirements-00 -Alternate Routes > > > >Consider adding the following paragraph to the introductory > >text on mapping: > > > >Ideally, the mapping protocol would yield a URI which would > >allow an emergency call to be completed on the Internet. > >However, not all PSAPs may have IP based connectivity. Thus > >the URI scheme cannot be fixed, and in fact may end up being a > >tel uri to allow calls to be completed on the PSTN. > > > > >_______________________________________________ >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 Dec 05 21:34:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjSey-00021a-Ix; Mon, 05 Dec 2005 21:34:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjSew-00021T-G1 for ecrit@megatron.ietf.org; Mon, 05 Dec 2005 21:34:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21169 for ; Mon, 5 Dec 2005 21:33:32 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjT0J-0005cq-NP for ecrit@ietf.org; Mon, 05 Dec 2005 21:56:32 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 20:34:12 -0600 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 05 Dec 2005 20:34:11 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 20:34:11 -0600 Message-ID: From: "Winterbottom, James" To: "James M. Polk" , "Roger Marshall" , , Date: Mon, 5 Dec 2005 20:34:09 -0600 Subject: RE: [Ecrit] Issue 28: NENA Comments ondraft-ietf-ecrit-requirements-00 -Alternate Routes MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 06 Dec 2005 02:34:11.0210 (UTC) FILETIME=[8A525EA0:01C5FA0D] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Issue 28: NENA Comments ondraft-ietf-ecrit-requirements-00 -Alternate Routes Thread-Index: AcX6B17prcMbfuS6RUKz2Y0tqtdbsgABarOg X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Change ESGW to "a PSTN gateway" or the such like and I am happy with this. ESGW has very specific meaning (at least to some of us), where in some countries there is no true separate emergency network it is all PSTN. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > James M. Polk > Sent: Tuesday, 6 December 2005 12:49 PM > To: Roger Marshall; br@brianrosen.net; ecrit@ietf.org > Subject: RE: [Ecrit] Issue 28: NENA Comments ondraft-ietf-ecrit- > requirements-00 -Alternate Routes >=20 > A tel:uri has nothing to do with the receiver, and is not a routable uri > scheme because it has no domain side of the URI. If the PSAP is not IP > enabled, something is going to have to get the emeregency call to a ESGW, > and a tel:uri is not that something that fixes this in the routing > process. >=20 > I can right now direct a SIP message with a Request-URI at a GW that will > get to a SR to a phase 0 PSAP (the phase 0 comment is to elicit the fact > that the PSAP is ancient). That Request URI may be a tel uri with the > sequence 9999999999 or it could be PSAP1@colleyville.tx.us >=20 > What matters is how the SIP element that has to route the message based on > whatever URI decides where that message should go. If this is a known > destination based a configured address, it still gets to that ESGW and SR > and PSAP. >=20 > I recommend the text below be rewritten to something like: >=20 > "Ideally, the mapping protocol would yield a SIPS-URI which would allow an > emergency call to be completed using IP end-to-end (via the > Internet). However, securing the signaling path may cause unwanted > failures, therefore a SIP URI map be the best attainable in some > situations. If a tel:url is returned, this will require either prior > knowledge of where to route this message, or to do an additional > translation to a routable SIP or SIPS URI to forward towards the PSAP > directly, or to the ESGW for non-IP-enabled PSAPs." >=20 > At 03:56 PM 12/5/2005 -0800, Roger Marshall wrote: > >NOTE: prior issue tracker url was wrong - should be: > >http://www.ietf-ecrit.org:8080/ecrit-req/ > > > >Brian: > > > >Issue 28 talks about some new proposed text to be placed at the end of > >the Introduction section. I've changed the text slightly from what you > >originally had, and is listed below: > > > >PROPOSED NEW TEXT (at end of Introduction): > >Ideally, the mapping protocol would yield a URI which would allow an > >emergency call to be completed using IP end-to-end (via the Internet). > >However, not all PSAPs may have IP based connectivity. Thus the URI > >scheme cannot be fixed, and in fact may end up being a tel uri to allow > >calls to be completed over the PSTN. > > > >Editor's Comment: This seems to be consistent with the definition of > >"emergency address" (see Terminology section), which lists tel:uri as > >one potential uri scheme. > > > >Objections? Please send to the list, along with new proposed text. This > >issue will be marked resolved after 10 days if no comments are received. > > > > > > > >Roger Marshall > > > > > > >-----Original Message----- > > >From: Brian Rosen [mailto:br@brianrosen.net] > > >Sent: Tuesday, November 08, 2005 6:50 PM > > >To: Roger Marshall; ecrit@ietf.org > > >Subject: RE: [Ecrit] NENA Comments on > > >draft-ietf-ecrit-requirements-00 -Alternate Routes > > > > > >Consider adding the following paragraph to the introductory > > >text on mapping: > > > > > >Ideally, the mapping protocol would yield a URI which would > > >allow an emergency call to be completed on the Internet. > > >However, not all PSAPs may have IP based connectivity. Thus > > >the URI scheme cannot be fixed, and in fact may end up being a > > >tel uri to allow calls to be completed on the PSTN. > > > > > > > > >_______________________________________________ > >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 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 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 Mon Dec 05 21:41:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjSmC-0004Az-Tj; Mon, 05 Dec 2005 21:41:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjSmB-0004AI-Rq for ecrit@megatron.ietf.org; Mon, 05 Dec 2005 21:41:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21966 for ; Mon, 5 Dec 2005 21:41:04 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjT7b-0005sI-D2 for ecrit@ietf.org; Mon, 05 Dec 2005 22:04:03 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 05 Dec 2005 18:41:46 -0800 X-IronPort-AV: i="3.99,218,1131350400"; d="scan'208"; a="374340197:sNHT39204012" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB62fV9w020435; Mon, 5 Dec 2005 18:41:44 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 18:41:29 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.121.59]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 18:41:29 -0800 Message-Id: <4.3.2.7.2.20051205203840.03fd0d18@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Dec 2005 20:41:28 -0600 To: "Winterbottom, James" , "Roger Marshall" , , From: "James M. Polk" Subject: RE: [Ecrit] Issue 28: NENA Comments ondraft-ietf-ecrit-requirements-00 -Alternate Routes In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 06 Dec 2005 02:41:29.0310 (UTC) FILETIME=[8F731FE0:01C5FA0E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 08:34 PM 12/5/2005 -0600, Winterbottom, James wrote: >Change ESGW to "a PSTN gateway" or the such like and I am happy with >this. I'm ok with this change, as that was what I basically meant BTW - in my suggested text -- the word "map" needs to be changed to "may".... I don't know how I fat-figured that one ;-) >ESGW has very specific meaning (at least to some of us), where in some >countries there is no true separate emergency network it is all PSTN. no problem > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >Of > > James M. Polk > > Sent: Tuesday, 6 December 2005 12:49 PM > > To: Roger Marshall; br@brianrosen.net; ecrit@ietf.org > > Subject: RE: [Ecrit] Issue 28: NENA Comments ondraft-ietf-ecrit- > > requirements-00 -Alternate Routes > > > > A tel:uri has nothing to do with the receiver, and is not a routable >uri > > scheme because it has no domain side of the URI. If the PSAP is not >IP > > enabled, something is going to have to get the emeregency call to a >ESGW, > > and a tel:uri is not that something that fixes this in the routing > > process. > > > > I can right now direct a SIP message with a Request-URI at a GW that >will > > get to a SR to a phase 0 PSAP (the phase 0 comment is to elicit the >fact > > that the PSAP is ancient). That Request URI may be a tel uri with the > > sequence 9999999999 or it could be PSAP1@colleyville.tx.us > > > > What matters is how the SIP element that has to route the message >based on > > whatever URI decides where that message should go. If this is a known > > destination based a configured address, it still gets to that ESGW and >SR > > and PSAP. > > > > I recommend the text below be rewritten to something like: > > > > "Ideally, the mapping protocol would yield a SIPS-URI which would >allow an > > emergency call to be completed using IP end-to-end (via the > > Internet). However, securing the signaling path may cause unwanted > > failures, therefore a SIP URI map be the best attainable in some > > situations. If a tel:url is returned, this will require either prior > > knowledge of where to route this message, or to do an additional > > translation to a routable SIP or SIPS URI to forward towards the PSAP > > directly, or to the ESGW for non-IP-enabled PSAPs." > > > > At 03:56 PM 12/5/2005 -0800, Roger Marshall wrote: > > >NOTE: prior issue tracker url was wrong - should be: > > >http://www.ietf-ecrit.org:8080/ecrit-req/ > > > > > >Brian: > > > > > >Issue 28 talks about some new proposed text to be placed at the end >of > > >the Introduction section. I've changed the text slightly from what >you > > >originally had, and is listed below: > > > > > >PROPOSED NEW TEXT (at end of Introduction): > > >Ideally, the mapping protocol would yield a URI which would allow an > > >emergency call to be completed using IP end-to-end (via the >Internet). > > >However, not all PSAPs may have IP based connectivity. Thus the URI > > >scheme cannot be fixed, and in fact may end up being a tel uri to >allow > > >calls to be completed over the PSTN. > > > > > >Editor's Comment: This seems to be consistent with the definition of > > >"emergency address" (see Terminology section), which lists tel:uri as > > >one potential uri scheme. > > > > > >Objections? Please send to the list, along with new proposed text. >This > > >issue will be marked resolved after 10 days if no comments are >received. > > > > > > > > > > > >Roger Marshall > > > > > > > > > >-----Original Message----- > > > >From: Brian Rosen [mailto:br@brianrosen.net] > > > >Sent: Tuesday, November 08, 2005 6:50 PM > > > >To: Roger Marshall; ecrit@ietf.org > > > >Subject: RE: [Ecrit] NENA Comments on > > > >draft-ietf-ecrit-requirements-00 -Alternate Routes > > > > > > > >Consider adding the following paragraph to the introductory > > > >text on mapping: > > > > > > > >Ideally, the mapping protocol would yield a URI which would > > > >allow an emergency call to be completed on the Internet. > > > >However, not all PSAPs may have IP based connectivity. Thus > > > >the URI scheme cannot be fixed, and in fact may end up being a > > > >tel uri to allow calls to be completed on the PSTN. > > > > > > > > > > > > >_______________________________________________ > > >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 > >------------------------------------------------------------------------------------------------ >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 Tue Dec 06 07:52:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjcJS-00028V-3i; Tue, 06 Dec 2005 07:52:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjcJQ-00028Q-17 for ecrit@megatron.ietf.org; Tue, 06 Dec 2005 07:52:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23328 for ; Tue, 6 Dec 2005 07:52:00 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejceu-0000O6-BX for ecrit@ietf.org; Tue, 06 Dec 2005 08:15:05 -0500 Received: from acs-24-154-127-115.zoominternet.net ([24.154.127.115] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EjcJ6-00066F-BE; Tue, 06 Dec 2005 06:52:32 -0600 From: "Brian Rosen" To: "'James M. Polk'" , "'Roger Marshall'" , Subject: RE: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Date: Tue, 6 Dec 2005 07:48:40 -0500 Message-ID: <01eb01c5fa63$643294f0$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 In-Reply-To: <4.3.2.7.2.20051205193522.0326dbb8@email.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcX6Bz585oncl6GXS4a7uzVs8sX/vwAWW3vA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm sorry, have there been some changes to VoIP call handling while I was sleeping last night? A tel uri has been routable for some time now, through a variety of mechanisms, most involving a gateway. There is static routing, TRIP and ENUM. All of them route a tel uri. Every VoIP system I know of does this seamlessly. Do we really need to say this in a requirements document? Further, Roger's "not all PSAPs may have IP based connectivity" is useful to motivate why a tel uri may be returned. Roger's proposed text is simpler and clearer. You might want to add "possibly" in front of "via the Internet". It may be a private network. Brian -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Monday, December 05, 2005 8:49 PM To: Roger Marshall; br@brianrosen.net; ecrit@ietf.org Subject: RE: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes A tel:uri has nothing to do with the receiver, and is not a routable uri scheme because it has no domain side of the URI. If the PSAP is not IP enabled, something is going to have to get the emeregency call to a ESGW, and a tel:uri is not that something that fixes this in the routing process. I can right now direct a SIP message with a Request-URI at a GW that will get to a SR to a phase 0 PSAP (the phase 0 comment is to elicit the fact that the PSAP is ancient). That Request URI may be a tel uri with the sequence 9999999999 or it could be PSAP1@colleyville.tx.us What matters is how the SIP element that has to route the message based on whatever URI decides where that message should go. If this is a known destination based a configured address, it still gets to that ESGW and SR and PSAP. I recommend the text below be rewritten to something like: "Ideally, the mapping protocol would yield a SIPS-URI which would allow an emergency call to be completed using IP end-to-end (via the Internet). However, securing the signaling path may cause unwanted failures, therefore a SIP URI map be the best attainable in some situations. If a tel:url is returned, this will require either prior knowledge of where to route this message, or to do an additional translation to a routable SIP or SIPS URI to forward towards the PSAP directly, or to the ESGW for non-IP-enabled PSAPs." At 03:56 PM 12/5/2005 -0800, Roger Marshall wrote: >NOTE: prior issue tracker url was wrong - should be: >http://www.ietf-ecrit.org:8080/ecrit-req/ > >Brian: > >Issue 28 talks about some new proposed text to be placed at the end of >the Introduction section. I've changed the text slightly from what you >originally had, and is listed below: > >PROPOSED NEW TEXT (at end of Introduction): >Ideally, the mapping protocol would yield a URI which would allow an >emergency call to be completed using IP end-to-end (via the Internet). >However, not all PSAPs may have IP based connectivity. Thus the URI >scheme cannot be fixed, and in fact may end up being a tel uri to allow >calls to be completed over the PSTN. > >Editor's Comment: This seems to be consistent with the definition of >"emergency address" (see Terminology section), which lists tel:uri as >one potential uri scheme. > >Objections? Please send to the list, along with new proposed text. This >issue will be marked resolved after 10 days if no comments are received. > > > >Roger Marshall > > > >-----Original Message----- > >From: Brian Rosen [mailto:br@brianrosen.net] > >Sent: Tuesday, November 08, 2005 6:50 PM > >To: Roger Marshall; ecrit@ietf.org > >Subject: RE: [Ecrit] NENA Comments on > >draft-ietf-ecrit-requirements-00 -Alternate Routes > > > >Consider adding the following paragraph to the introductory > >text on mapping: > > > >Ideally, the mapping protocol would yield a URI which would > >allow an emergency call to be completed on the Internet. > >However, not all PSAPs may have IP based connectivity. Thus > >the URI scheme cannot be fixed, and in fact may end up being a > >tel uri to allow calls to be completed on the PSTN. > > > > >_______________________________________________ >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 Tue Dec 06 09:28:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejdnz-0008DA-GC; Tue, 06 Dec 2005 09:28:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejdnw-0008Ct-8U for ecrit@megatron.ietf.org; Tue, 06 Dec 2005 09:28:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05954 for ; Tue, 6 Dec 2005 09:27:36 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eje9D-0003wD-4t for ecrit@ietf.org; Tue, 06 Dec 2005 09:50:42 -0500 Received: from ZTCFHXM0.corp.nortel.com (ztcfhxm0.corp.nortel.com [47.10.33.94]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id jB6EOcL21785; Tue, 6 Dec 2005 09:24:38 -0500 (EST) Received: from zcarhxs1.corp.nortel.com ([47.129.230.89]) by ZTCFHXM0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Dec 2005 09:27:48 -0500 Received: from [127.0.0.1] ([47.130.25.64] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Dec 2005 09:27:47 -0500 Message-ID: <43959FDE.8000605@nortel.com> Date: Tue, 06 Dec 2005 09:27:42 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: br@brianrosen.net Subject: Re: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes References: <01eb01c5fa63$643294f0$640fa8c0@cis.neustar.com> In-Reply-To: <01eb01c5fa63$643294f0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Dec 2005 14:27:47.0562 (UTC) FILETIME=[3ADB34A0:01C5FA71] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I've finished a new draft of the Security Requirements document. It is just circulating amongst the authors for approval now. However, the possibility that we are talking a mixed IP-PSDTN path adds a new twist. I suppose we should have a look at it before issuing the new version of the draft. Brian Rosen wrote: > I'm sorry, have there been some changes to VoIP call handling while I was > sleeping last night? > > A tel uri has been routable for some time now, through a variety of > mechanisms, most involving a gateway. There is static routing, TRIP and > ENUM. All of them route a tel uri. Every VoIP system I know of does this > seamlessly. Do we really need to say this in a requirements document? > > Further, Roger's "not all PSAPs may have IP based connectivity" is useful to > motivate why a tel uri may be returned. > > Roger's proposed text is simpler and clearer. > > You might want to add "possibly" in front of "via the Internet". It may be > a private network. > > Brian > ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Dec 06 14:44:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejijp-00043A-DR; Tue, 06 Dec 2005 14:44:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejijn-00042t-Tw for ecrit@megatron.ietf.org; Tue, 06 Dec 2005 14:44:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13574 for ; Tue, 6 Dec 2005 14:43:40 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejj5J-0006w7-43 for ecrit@ietf.org; Tue, 06 Dec 2005 15:06:48 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 06 Dec 2005 11:44:18 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,223,1131350400"; d="scan'208"; a="16705504:sNHT25158220" 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 jB6JhwUd027202; Tue, 6 Dec 2005 14:44:14 -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.211); Tue, 6 Dec 2005 14:44:13 -0500 Received: from jmpolk-wxp.cisco.com ([10.86.242.192]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Dec 2005 14:44:12 -0500 Message-Id: <4.3.2.7.2.20051206132818.031086c8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Dec 2005 13:44:11 -0600 To: , "'Roger Marshall'" , From: "James M. Polk" Subject: RE: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes In-Reply-To: <01eb01c5fa63$643294f0$640fa8c0@cis.neustar.com> References: <4.3.2.7.2.20051205193522.0326dbb8@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 06 Dec 2005 19:44:13.0078 (UTC) FILETIME=[6F1B0B60:01C5FA9D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 07:48 AM 12/6/2005 -0500, Brian Rosen wrote: >I'm sorry, have there been some changes to VoIP call handling while I was >sleeping last night? > >A tel uri has been routable for some time now, through a variety of >mechanisms, most involving a gateway. A GW is an instance of a SIP endpoint, it is not a Proxy - which is a SIP message router. > There is static routing, I can configure a static route on a Call-ID sequence, on an option-tag, or a TCP port number - I wouldn't consider these worth mentioning >TRIP how deployed is this and how deployed will this be? >and >ENUM. ENUM does a conversion from E.164 to SIP URI to then do the routing. ENUM is analogous to a mapping protocol. Do we want two of these to get a 911 call to work? The text offering has the work "ideally", and we ideally want a SIPS URI. WE will settle for a SIP URI. If a tel:uri is returned, we need to do more processing, like convert this uri to a SIP URI to route the message *because* we do not know if the next hop proxy is PSAP, and it might be a intermediate proxy doing the final resolution of URI to IP address, or AOR (or a state's emergency VSP) to contact address (of a specific city's PSAP). >All of them route a tel uri. Every VoIP system I know of does this >seamlessly. Do we really need to say this in a requirements document? > >Further, Roger's "not all PSAPs may have IP based connectivity" is useful to >motivate why a tel uri may be returned. Movitvate? Why do we need motivation here? Whether my text is used or not, this requirement has the ability to have a hierarchy of preferred options listed, and my text gives that order for motivation to work towards the most secure solution. It does not dismiss tel:uris, it just says they are not preferred. >Roger's proposed text is simpler and clearer. > >You might want to add "possibly" in front of "via the Internet". It may be >a private network. > >Brian > >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: Monday, December 05, 2005 8:49 PM >To: Roger Marshall; br@brianrosen.net; ecrit@ietf.org >Subject: RE: [Ecrit] Issue 28: NENA Comments on >draft-ietf-ecrit-requirements-00 -Alternate Routes > >A tel:uri has nothing to do with the receiver, and is not a routable uri >scheme because it has no domain side of the URI. If the PSAP is not IP >enabled, something is going to have to get the emeregency call to a ESGW, >and a tel:uri is not that something that fixes this in the routing process. > >I can right now direct a SIP message with a Request-URI at a GW that will >get to a SR to a phase 0 PSAP (the phase 0 comment is to elicit the fact >that the PSAP is ancient). That Request URI may be a tel uri with the >sequence 9999999999 or it could be PSAP1@colleyville.tx.us > >What matters is how the SIP element that has to route the message based on >whatever URI decides where that message should go. If this is a known >destination based a configured address, it still gets to that ESGW and SR >and PSAP. > >I recommend the text below be rewritten to something like: > >"Ideally, the mapping protocol would yield a SIPS-URI which would allow an >emergency call to be completed using IP end-to-end (via the >Internet). However, securing the signaling path may cause unwanted >failures, therefore a SIP URI map be the best attainable in some >situations. If a tel:url is returned, this will require either prior >knowledge of where to route this message, or to do an additional >translation to a routable SIP or SIPS URI to forward towards the PSAP >directly, or to the ESGW for non-IP-enabled PSAPs." > >At 03:56 PM 12/5/2005 -0800, Roger Marshall wrote: > >NOTE: prior issue tracker url was wrong - should be: > >http://www.ietf-ecrit.org:8080/ecrit-req/ > > > >Brian: > > > >Issue 28 talks about some new proposed text to be placed at the end of > >the Introduction section. I've changed the text slightly from what you > >originally had, and is listed below: > > > >PROPOSED NEW TEXT (at end of Introduction): > >Ideally, the mapping protocol would yield a URI which would allow an > >emergency call to be completed using IP end-to-end (via the Internet). > >However, not all PSAPs may have IP based connectivity. Thus the URI > >scheme cannot be fixed, and in fact may end up being a tel uri to allow > >calls to be completed over the PSTN. > > > >Editor's Comment: This seems to be consistent with the definition of > >"emergency address" (see Terminology section), which lists tel:uri as > >one potential uri scheme. > > > >Objections? Please send to the list, along with new proposed text. This > >issue will be marked resolved after 10 days if no comments are received. > > > > > > > >Roger Marshall > > > > > > >-----Original Message----- > > >From: Brian Rosen [mailto:br@brianrosen.net] > > >Sent: Tuesday, November 08, 2005 6:50 PM > > >To: Roger Marshall; ecrit@ietf.org > > >Subject: RE: [Ecrit] NENA Comments on > > >draft-ietf-ecrit-requirements-00 -Alternate Routes > > > > > >Consider adding the following paragraph to the introductory > > >text on mapping: > > > > > >Ideally, the mapping protocol would yield a URI which would > > >allow an emergency call to be completed on the Internet. > > >However, not all PSAPs may have IP based connectivity. Thus > > >the URI scheme cannot be fixed, and in fact may end up being a > > >tel uri to allow calls to be completed on the PSTN. > > > > > > > > >_______________________________________________ > >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 Tue Dec 06 15:30:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjjSV-0007a0-LM; Tue, 06 Dec 2005 15:30:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjjST-0007Zr-TY for ecrit@megatron.ietf.org; Tue, 06 Dec 2005 15:30:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18394 for ; Tue, 6 Dec 2005 15:29:50 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejjo2-0008Ry-QS for ecrit@ietf.org; Tue, 06 Dec 2005 15:52:59 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 06 Dec 2005 12:30:33 -0800 X-IronPort-AV: i="3.99,223,1131350400"; d="scan'208"; a="374780556:sNHT32389020" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB6KTqBr020066; Tue, 6 Dec 2005 12:30:30 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Dec 2005 12:30:26 -0800 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Dec 2005 12:30:26 -0800 From: "Marc Linsner" To: "'James M. Polk'" , , "'Roger Marshall'" , Subject: RE: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Date: Tue, 6 Dec 2005 15:30:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX6nbAHPJ3Mn+0eRDa3i6WwMjmrZQAA0OnA In-Reply-To: <4.3.2.7.2.20051206132818.031086c8@email.cisco.com> Message-ID: X-OriginalArrivalTime: 06 Dec 2005 20:30:26.0353 (UTC) FILETIME=[E41B3A10:01C5FAA3] X-Spam-Score: 1.1 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org In-line..... snip...... > > If a tel:uri is returned, we need to do more processing, like > convert this uri to a SIP URI to route the message *because* > we do not know if the next hop proxy is PSAP, and it might be > a intermediate proxy doing the final resolution of URI to IP > address, or AOR (or a state's emergency VSP) to contact > address (of a specific city's PSAP). > >From an ECRIT pov, I don't agree. Yes, the SIP proxy may perform different (including additional) steps in order to resolve a tel:uri, but ECRIT is complete at this point. A tel:uri is valid in the SIP domain so it should be valid in the ECRIT domain. > >All of them route a tel uri. Every VoIP system I know of does this > >seamlessly. Do we really need to say this in a requirements > document? > > > >Further, Roger's "not all PSAPs may have IP based connectivity" is > >useful to motivate why a tel uri may be returned. > > Movitvate? Why do we need motivation here? > > Whether my text is used or not, this requirement has the > ability to have a hierarchy of preferred options listed, and > my text gives that order for motivation to work towards the > most secure solution. It does not dismiss tel:uris, it just > says they are not preferred. The designer of the PSAP system will decide the architecture of the contact mechanism. Guidance may be offered in an architecture BCP, but I'm not sure it's proper for a requirements draft. I vote for Roger's text. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Dec 06 16:03:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejjxk-0003pU-OR; Tue, 06 Dec 2005 16:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejjxi-0003pO-PA for ecrit@megatron.ietf.org; Tue, 06 Dec 2005 16:02:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22045 for ; Tue, 6 Dec 2005 16:02:06 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjkJI-0001JS-2s for ecrit@ietf.org; Tue, 06 Dec 2005 16:25:16 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 06 Dec 2005 16:02:50 -0500 X-IronPort-AV: i="3.99,223,1131339600"; d="scan'208"; a="77249879:sNHT31621008" 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 jB6L1JUj020325; Tue, 6 Dec 2005 16:02:44 -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.211); Tue, 6 Dec 2005 16:02:33 -0500 Received: from jmpolk-wxp.cisco.com ([10.86.242.192]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Dec 2005 16:02:32 -0500 Message-Id: <4.3.2.7.2.20051206145317.0300c338@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Dec 2005 15:02:31 -0600 To: "Marc Linsner" , , "'Roger Marshall'" , From: "James M. Polk" Subject: RE: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes In-Reply-To: References: <4.3.2.7.2.20051206132818.031086c8@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 06 Dec 2005 21:02:33.0124 (UTC) FILETIME=[608D2640:01C5FAA8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org In-line At 03:30 PM 12/6/2005 -0500, Marc Linsner wrote: >In-line..... > >snip...... > > > > > If a tel:uri is returned, we need to do more processing, like > > convert this uri to a SIP URI to route the message *because* > > we do not know if the next hop proxy is PSAP, and it might be > > a intermediate proxy doing the final resolution of URI to IP > > address, or AOR (or a state's emergency VSP) to contact > > address (of a specific city's PSAP). > > > > From an ECRIT pov, I don't agree. Yes, the SIP proxy may perform different >(including additional) steps in order to resolve a tel:uri, but ECRIT is >complete at this point. A tel:uri is valid in the SIP domain so it should >be valid in the ECRIT domain. but it's not routable in the SIP domain, and the SIP specs state that conversion is necessary to make the message routable. This is an extra step that is less desired. > > >All of them route a tel uri. Every VoIP system I know of does this > > >seamlessly. Do we really need to say this in a requirements > > document? > > > > > >Further, Roger's "not all PSAPs may have IP based connectivity" is > > >useful to motivate why a tel uri may be returned. > > > > Movitvate? Why do we need motivation here? > > > > Whether my text is used or not, this requirement has the > > ability to have a hierarchy of preferred options listed, and > > my text gives that order for motivation to work towards the > > most secure solution. It does not dismiss tel:uris, it just > > says they are not preferred. > >The designer of the PSAP system will decide the architecture of the contact >mechanism. Guidance may be offered in an architecture BCP, but I'm not sure >it's proper for a requirements draft. This is a ridiculous statement. Of course requirements documents give preferential orders to mechanisms. The offered text here is not absolute, and does not say that a tel:uri is forbidden. >I vote for Roger's text. > >-Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Dec 06 18:03:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejlqa-000581-8P; Tue, 06 Dec 2005 18:03:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjlqZ-00057e-3T for ecrit@megatron.ietf.org; Tue, 06 Dec 2005 18:03:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04071 for ; Tue, 6 Dec 2005 18:02:51 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjmC7-0005AC-8m for ecrit@ietf.org; Tue, 06 Dec 2005 18:26:00 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Tue, 6 Dec 2005 18:03:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Date: Tue, 6 Dec 2005 15:03:20 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657503BCECF1@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Thread-Index: AcX6qG27Gg6uVQ7zTc+eBePMsAV+BgAAhXkw From: "Roger Marshall" To: "James M. Polk" , "Marc Linsner" , , X-Spam-Score: 2.6 (++) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James: It seems like we have agreement (I think) that tel:uri's shouldn't be excluded altogether. I also agree that there is a preference as to which uri scheme is to be used, (e.g. sip:uri over a tel:uri), so I've revised the text: PROPOSED (updated 12/06) TEXT: "Ideally, the mapping protocol would yield a URI (e.g. sip:uri,=20 sips:uri, etc.) which would allow an emergency call to be completed=20 using IP end-to-end (possibly, via the Internet). Though this is the=20 goal, not every PSAP will have IP based connectivity right away, so the=20 URI scheme is not fixed. Given these conditions, alternate URI schemes, such as tel:uri, are allowed in order to complete calls over the PSTN." Agreeable? Roger Marshall >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com]=20 >Sent: Tuesday, December 06, 2005 1:03 PM >To: Marc Linsner; br@brianrosen.net; Roger Marshall; ecrit@ietf.org >Subject: RE: [Ecrit] Issue 28: NENA Comments on=20 >draft-ietf-ecrit-requirements-00 -Alternate Routes > >In-line > >At 03:30 PM 12/6/2005 -0500, Marc Linsner wrote: >>In-line..... >> >>snip...... >> >> > >> > If a tel:uri is returned, we need to do more processing, like=20 >> > convert this uri to a SIP URI to route the message *because* we do=20 >> > not know if the next hop proxy is PSAP, and it might be a=20 >> > intermediate proxy doing the final resolution of URI to IP=20 >address,=20 >> > or AOR (or a state's emergency VSP) to contact address (of a=20 >> > specific city's PSAP). >> > >> >> From an ECRIT pov, I don't agree. Yes, the SIP proxy may perform=20 >>different (including additional) steps in order to resolve a tel:uri,=20 >>but ECRIT is complete at this point. A tel:uri is valid in the SIP=20 >>domain so it should be valid in the ECRIT domain. > >but it's not routable in the SIP domain, and the SIP specs=20 >state that conversion is necessary to make the message=20 >routable. This is an extra step that is less desired. > > >> > >All of them route a tel uri. Every VoIP system I know of=20 >does this=20 >> > >seamlessly. Do we really need to say this in a requirements >> > document? >> > > >> > >Further, Roger's "not all PSAPs may have IP based=20 >connectivity" is=20 >> > >useful to motivate why a tel uri may be returned. >> > >> > Movitvate? Why do we need motivation here? >> > >> > Whether my text is used or not, this requirement has the=20 >ability to=20 >> > have a hierarchy of preferred options listed, and my text=20 >gives that=20 >> > order for motivation to work towards the most secure solution. It=20 >> > does not dismiss tel:uris, it just says they are not preferred. >> >>The designer of the PSAP system will decide the architecture of the=20 >>contact mechanism. Guidance may be offered in an=20 >architecture BCP, but=20 >>I'm not sure it's proper for a requirements draft. > >This is a ridiculous statement. Of course requirements=20 >documents give preferential orders to mechanisms. The offered=20 >text here is not absolute, and does not say that a tel:uri is=20 >forbidden. > > >>I vote for Roger's text. >> >>-Marc- > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Dec 06 19:21:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejn4A-0005pD-42; Tue, 06 Dec 2005 19:21:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejn47-0005nr-Ou for ecrit@megatron.ietf.org; Tue, 06 Dec 2005 19:21:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11984 for ; Tue, 6 Dec 2005 19:20:56 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjnPi-0007st-MO for ecrit@ietf.org; Tue, 06 Dec 2005 19:44:07 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 06 Dec 2005 16:21:28 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,223,1131350400"; d="scan'208"; a="16737589:sNHT29908886772" 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 jB70KwUj009517; Tue, 6 Dec 2005 19:21:23 -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.211); Tue, 6 Dec 2005 19:21:18 -0500 Received: from jmpolk-wxp.cisco.com ([10.86.242.192]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Dec 2005 19:21:17 -0500 Message-Id: <4.3.2.7.2.20051206174016.02ccf018@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Dec 2005 18:21:15 -0600 To: "Roger Marshall" , "Marc Linsner" , , From: "James M. Polk" Subject: RE: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes In-Reply-To: <8C837214C95C864C9F34F3635C2A657503BCECF1@SEA-EXCHVS-2.tele comsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 07 Dec 2005 00:21:17.0424 (UTC) FILETIME=[23FCEF00:01C5FAC4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Roger I'll propose what you wrote with the appropriate MUSTs, SHOULDs and MAYs like most requirements should have: "Ideally, the mapping protocol SHOULD yield a URI (e.g. sip:uri, sips:uri, etc.) which would allow an emergency call to be routed using IP end-to-end (possibly, via the Internet). Though this is the goal, not every PSAP will have IP based connectivity right away, so the URI scheme MAY be different. Given these conditions, alternate URI schemes, such as tel:uri, MAY be used in order to complete calls over the PSTN." I don't know if we want to get into specifying that dialog generating SIP requests SHOULD have a SIP or SIPS URI. INVITE is such a request, whereas Rohan's XMPP scheme example would not be used to generate a dialog, so that wouldn't be a contradiction. Now for me scratching my head at the second sentence: I'm a bit vague as to how a tel:uri is going to solve the ESRP to ESGW communications route path. Generally, a tel:uri is what is entered at the endstation, and not what is the product of a mapping conversion at a SIP proxy *from* a SIP URI. In other words, tel:911 is what could be entered by an IP phone, and shows up as the Request-URI in the INVITE to a ESRP server. This ESRP needs to do a mapping function to determine which PSAP is going to get this call set-up message. Take this basic topology (apologies James for the ESGW reference, but this makes the most sense to some of us for this discussion): IP phone ==> ESRP ==> ESGW ==> SR ==> PSAP The IP Phone creates an INVITE such as this: INVITE tel:911 SIP/2.0 Via: SIP/2.0/UDP ipphone1.localdomain.com; branch=z9hG4bK776asdhs To: 911 From: Roger Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REGISTER, REFER, NOTIFY, UPDATE Call-ID: a84b4c76e66710@localdomain.com CSeq: 1 INVITE Contact: Content-Type: mulipart/mixed; boundary=--0a1 Content-length: ... --0a1 Content-Type: application/sdp (SDP) --0a1 Content-Type: pidf-lo+xml (PIDF-LO) --0a1-- Now, the ESRP receives this message, realizes this is an emergency call, knows to look for the location message body to ship off to a mapping server. This could be a local process, or use one of the various methods discussed on this list. I'm not playing favorites in that regard for now. The nut of this discussion is what the ESRP gets back from the mapping server. Is this, or can it be, a tel:uri? The way I read the requirement as written, even with my alteration above, is I think both are saying it's possible to use a tel:uri from the mapping server to replace the existing Request-URI (tel:911 here) with. What is this uri going to look like, and how exactly will this get the message towards the ESGW to ensure it meets the i2 requirement of getting to the Selective Router and towards the proper PSAP? Are we talking about keeping the Request-URI the same and adding a Route header of the ESGW? This isn't the mapping protocol function as I'm understanding it to be, although this could work, as long as the ESRP maintains dialog state and the Contact header remains the same in case there are issues involving redundancy with a callback situation. I don't see why a tel:uri has to stay as the Request-URI, or be swapped with another tel:uri. How is this tel:uri going to all of a sudden make the non-IP-enabled PSAP work? I should think that any ESGW receiving an INVITE from a ESRP with an agreeable emergency declaration should translate that INVITE into starting a call set-up to the Selective Router with the ANI of the user. How does a tel:uri scheme enable this, whereas a SIP URI would not? At 03:03 PM 12/6/2005 -0800, Roger Marshall wrote: >James: >It seems like we have agreement (I think) that tel:uri's shouldn't be >excluded altogether. I also agree that there is a preference as to >which uri scheme is to be used, (e.g. sip:uri over a tel:uri), so I've >revised the text: > >PROPOSED (updated 12/06) TEXT: >"Ideally, the mapping protocol would yield a URI (e.g. sip:uri, >sips:uri, etc.) which would allow an emergency call to be completed >using IP end-to-end (possibly, via the Internet). Though this is the >goal, not every PSAP will have IP based connectivity right away, so the >URI scheme is not fixed. Given these conditions, alternate URI schemes, > >such as tel:uri, are allowed in order to complete calls over the PSTN." > >Agreeable? > >Roger Marshall > > > >-----Original Message----- > >From: James M. Polk [mailto:jmpolk@cisco.com] > >Sent: Tuesday, December 06, 2005 1:03 PM > >To: Marc Linsner; br@brianrosen.net; Roger Marshall; ecrit@ietf.org > >Subject: RE: [Ecrit] Issue 28: NENA Comments on > >draft-ietf-ecrit-requirements-00 -Alternate Routes > > > >In-line > > > >At 03:30 PM 12/6/2005 -0500, Marc Linsner wrote: > >>In-line..... > >> > >>snip...... > >> > >> > > >> > If a tel:uri is returned, we need to do more processing, like > >> > convert this uri to a SIP URI to route the message *because* we do > >> > not know if the next hop proxy is PSAP, and it might be a > >> > intermediate proxy doing the final resolution of URI to IP > >address, > >> > or AOR (or a state's emergency VSP) to contact address (of a > >> > specific city's PSAP). > >> > > >> > >> From an ECRIT pov, I don't agree. Yes, the SIP proxy may perform > >>different (including additional) steps in order to resolve a tel:uri, > >>but ECRIT is complete at this point. A tel:uri is valid in the SIP > >>domain so it should be valid in the ECRIT domain. > > > >but it's not routable in the SIP domain, and the SIP specs > >state that conversion is necessary to make the message > >routable. This is an extra step that is less desired. > > > > > >> > >All of them route a tel uri. Every VoIP system I know of > >does this > >> > >seamlessly. Do we really need to say this in a requirements > >> > document? > >> > > > >> > >Further, Roger's "not all PSAPs may have IP based > >connectivity" is > >> > >useful to motivate why a tel uri may be returned. > >> > > >> > Movitvate? Why do we need motivation here? > >> > > >> > Whether my text is used or not, this requirement has the > >ability to > >> > have a hierarchy of preferred options listed, and my text > >gives that > >> > order for motivation to work towards the most secure solution. It > >> > does not dismiss tel:uris, it just says they are not preferred. > >> > >>The designer of the PSAP system will decide the architecture of the > >>contact mechanism. Guidance may be offered in an > >architecture BCP, but > >>I'm not sure it's proper for a requirements draft. > > > >This is a ridiculous statement. Of course requirements > >documents give preferential orders to mechanisms. The offered > >text here is not absolute, and does not say that a tel:uri is > >forbidden. > > > > > >>I vote for Roger's text. > >> > >>-Marc- > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Dec 06 19:37:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjnIs-000356-NY; Tue, 06 Dec 2005 19:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjnIq-00033O-Cs for ecrit@megatron.ietf.org; Tue, 06 Dec 2005 19:37:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13256 for ; Tue, 6 Dec 2005 19:36:09 -0500 (EST) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjneR-0008KQ-BF for ecrit@ietf.org; Tue, 06 Dec 2005 19:59:19 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jB70afLx030153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Dec 2005 16:36:42 -0800 Received: from [24.23.129.4] (carbuncle.qualcomm.com [129.46.225.16]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jB70adgu006285; Tue, 6 Dec 2005 16:36:40 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <4.3.2.7.2.20051206174016.02ccf018@email.cisco.com> References: <4.3.2.7.2.20051206174016.02ccf018@email.cisco.com> Date: Tue, 6 Dec 2005 16:36:37 -0800 To: "James M. Polk" , "Roger Marshall" , "Marc Linsner" , , From: Ted Hardie Subject: RE: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 6:21 PM -0600 12/6/05, James M. Polk wrote: >Roger > >I'll propose what you wrote with the appropriate MUSTs, SHOULDs and MAYs like most requirements should have: > >"Ideally, the mapping protocol SHOULD yield a URI (e.g. sip:uri, >sips:uri, etc.) which would allow an emergency call to be routed >using IP end-to-end (possibly, via the Internet). Though this is the >goal, not every PSAP will have IP based connectivity right away, so the >URI scheme MAY be different. Given these conditions, alternate URI schemes, >such as tel:uri, MAY be used in order to complete calls over the PSTN." Written this way, I would interpret this to mean that any URI scheme which mapped to a protocol that used IP end-to-end was in the preferred set, and that URI schemes like tel which required gateways or further mapping in this context were in a less preferred set. I am fine with this, since I think the choice of specific URI schemes (sip, sips) falls out pretty easily in operational reality, but I wanted to flag it in case James meant it to say "SHOULD yield a SIP or SIPS URI which would allow an emergency call to be routed" and to put non-SIP URI schemes in the same bucket whether they were IP end-to-end or not. To put this in another way, would a registered scheme of SMS be in the preferred set if it were possible to use it over IP without gateways? Also, I believe we said earlier that the mapping protocol would yield one or more URIs, with at most one per scheme. So you could have a SIP URI returned, as well as an SMS URI, with the preference order set by the client according to its capabilities. regards, Ted > > >I don't know if we want to get into specifying that dialog generating SIP requests SHOULD have a SIP or SIPS URI. INVITE is such a request, whereas Rohan's XMPP scheme example would not be used to generate a dialog, so that wouldn't be a contradiction. > >Now for me scratching my head at the second sentence: >I'm a bit vague as to how a tel:uri is going to solve the ESRP to ESGW communications route path. > >Generally, a tel:uri is what is entered at the endstation, and not what is the product of a mapping conversion at a SIP proxy *from* a SIP URI. > >In other words, tel:911 is what could be entered by an IP phone, and shows up as the Request-URI in the INVITE to a ESRP server. This ESRP needs to do a mapping function to determine which PSAP is going to get this call set-up message. Take this basic topology (apologies James for the ESGW reference, but this makes the most sense to some of us for this discussion): > >IP phone ==> ESRP ==> ESGW ==> SR ==> PSAP > >The IP Phone creates an INVITE such as this: > >INVITE tel:911 SIP/2.0 >Via: SIP/2.0/UDP ipphone1.localdomain.com; > branch=z9hG4bK776asdhs >To: 911 >From: Roger >Max-Forwards: 70 >Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REGISTER, > REFER, NOTIFY, UPDATE >Call-ID: a84b4c76e66710@localdomain.com >CSeq: 1 INVITE >Contact: >Content-Type: mulipart/mixed; boundary=--0a1 >Content-length: ... > >--0a1 >Content-Type: application/sdp >(SDP) >--0a1 >Content-Type: pidf-lo+xml >(PIDF-LO) >--0a1-- > >Now, the ESRP receives this message, realizes this is an emergency call, knows to look for the location message body to ship off to a mapping server. This could be a local process, or use one of the various methods discussed on this list. I'm not playing favorites in that regard for now. > >The nut of this discussion is what the ESRP gets back from the mapping server. > >Is this, or can it be, a tel:uri? > >The way I read the requirement as written, even with my alteration above, is I think both are saying it's possible to use a tel:uri from the mapping server to replace the existing Request-URI (tel:911 here) with. What is this uri going to look like, and how exactly will this get the message towards the ESGW to ensure it meets the i2 requirement of getting to the Selective Router and towards the proper PSAP? > >Are we talking about keeping the Request-URI the same and adding a Route header of the ESGW? This isn't the mapping protocol function as I'm understanding it to be, although this could work, as long as the ESRP maintains dialog state and the Contact header remains the same in case there are issues involving redundancy with a callback situation. > >I don't see why a tel:uri has to stay as the Request-URI, or be swapped with another tel:uri. How is this tel:uri going to all of a sudden make the non-IP-enabled PSAP work? > >I should think that any ESGW receiving an INVITE from a ESRP with an agreeable emergency declaration should translate that INVITE into starting a call set-up to the Selective Router with the ANI of the user. How does a tel:uri scheme enable this, whereas a SIP URI would not? > > > >At 03:03 PM 12/6/2005 -0800, Roger Marshall wrote: >>James: >>It seems like we have agreement (I think) that tel:uri's shouldn't be >>excluded altogether. I also agree that there is a preference as to >>which uri scheme is to be used, (e.g. sip:uri over a tel:uri), so I've >>revised the text: >> >>PROPOSED (updated 12/06) TEXT: >>"Ideally, the mapping protocol would yield a URI (e.g. sip:uri, >>sips:uri, etc.) which would allow an emergency call to be completed >>using IP end-to-end (possibly, via the Internet). Though this is the >>goal, not every PSAP will have IP based connectivity right away, so the >>URI scheme is not fixed. Given these conditions, alternate URI schemes, >> >>such as tel:uri, are allowed in order to complete calls over the PSTN." >> >>Agreeable? >> >>Roger Marshall >> >> >>>-----Original Message----- >>>From: James M. Polk [mailto:jmpolk@cisco.com] >>>Sent: Tuesday, December 06, 2005 1:03 PM >>>To: Marc Linsner; br@brianrosen.net; Roger Marshall; ecrit@ietf.org >>>Subject: RE: [Ecrit] Issue 28: NENA Comments on >>>draft-ietf-ecrit-requirements-00 -Alternate Routes >>> >>>In-line >>> >>>At 03:30 PM 12/6/2005 -0500, Marc Linsner wrote: >>>>In-line..... >>>> >>>>snip...... >>>> >>>> > >>>> > If a tel:uri is returned, we need to do more processing, like >>>> > convert this uri to a SIP URI to route the message *because* we do >>>> > not know if the next hop proxy is PSAP, and it might be a >>>> > intermediate proxy doing the final resolution of URI to IP >>>address, >>>> > or AOR (or a state's emergency VSP) to contact address (of a >>>> > specific city's PSAP). >>>> > >>>> >>>> From an ECRIT pov, I don't agree. Yes, the SIP proxy may perform >>>>different (including additional) steps in order to resolve a tel:uri, >>>>but ECRIT is complete at this point. A tel:uri is valid in the SIP >>>>domain so it should be valid in the ECRIT domain. >>> >>>but it's not routable in the SIP domain, and the SIP specs >>>state that conversion is necessary to make the message >>>routable. This is an extra step that is less desired. >>> >>> >>>> > >All of them route a tel uri. Every VoIP system I know of >>>does this >>>> > >seamlessly. Do we really need to say this in a requirements >>>> > document? >>>> > > >>>> > >Further, Roger's "not all PSAPs may have IP based >>>connectivity" is >>>> > >useful to motivate why a tel uri may be returned. >>>> > >>>> > Movitvate? Why do we need motivation here? >>>> > >>>> > Whether my text is used or not, this requirement has the >>>ability to >>>> > have a hierarchy of preferred options listed, and my text >>>gives that >>>> > order for motivation to work towards the most secure solution. It >>>> > does not dismiss tel:uris, it just says they are not preferred. >>>> >>>>The designer of the PSAP system will decide the architecture of the >>>>contact mechanism. Guidance may be offered in an >>>architecture BCP, but >>>>I'm not sure it's proper for a requirements draft. >>> >>>This is a ridiculous statement. Of course requirements >>>documents give preferential orders to mechanisms. The offered >>>text here is not absolute, and does not say that a tel:uri is >>>forbidden. >>> >>> >>>>I vote for Roger's text. >>>> >>>>-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 Tue Dec 06 19:46:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjnSQ-0007Lj-LL; Tue, 06 Dec 2005 19:46:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjnSO-0007LH-TN for ecrit@megatron.ietf.org; Tue, 06 Dec 2005 19:46:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14010 for ; Tue, 6 Dec 2005 19:46:01 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejnny-00009r-Nu for ecrit@ietf.org; Tue, 06 Dec 2005 20:09:12 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Tue, 6 Dec 2005 19:46:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Date: Tue, 6 Dec 2005 16:46:32 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657503BCEE1B@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Thread-Index: AcX6xDXCDCO74m4jQTGiVmXOMzzBQQAALj9A From: "Roger Marshall" To: "James M. Polk" , "Marc Linsner" , , X-Spam-Score: 2.6 (++) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James: Your explanation makes sense to me. Allow the use of tel:uri at the "edge" (e.g. UA-to-ESRP), but don't let it be used in std core SIP signaling. Did I understand this to be your point? Assuming this is the case, the inclusion of the MUST/MAY language would turn the paragraph into a real requirement, something that doesn't belong in the Intro section. Also, Rohan's suggestion of removing tel:uri from the "emergency address" defn makes more sense too, and I think is warranted, as "tel:uri" is used nowhere else in the document. Question remains, what should this paragraph say, is it still necessary as written, and if so, where do we place it. Roger Marshall >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com]=20 >Sent: Tuesday, December 06, 2005 4:21 PM >To: Roger Marshall; Marc Linsner; br@brianrosen.net; ecrit@ietf.org >Subject: RE: [Ecrit] Issue 28: NENA Comments on=20 >draft-ietf-ecrit-requirements-00 -Alternate Routes > >Roger > >I'll propose what you wrote with the appropriate MUSTs,=20 >SHOULDs and MAYs like most requirements should have: > >"Ideally, the mapping protocol SHOULD yield a URI (e.g.=20 >sip:uri, sips:uri, etc.) which would allow an emergency call=20 >to be routed using IP end-to-end (possibly, via the=20 >Internet). Though this is the goal, not every PSAP will have=20 >IP based connectivity right away, so the URI scheme MAY be=20 >different. Given these conditions, alternate URI schemes,=20 >such as tel:uri, MAY be used in order to complete calls over the PSTN." > >I don't know if we want to get into specifying that dialog=20 >generating SIP requests SHOULD have a SIP or SIPS URI. INVITE=20 >is such a request, whereas Rohan's XMPP scheme example would=20 >not be used to generate a dialog, so that wouldn't be a contradiction. > >Now for me scratching my head at the second sentence: >I'm a bit vague as to how a tel:uri is going to solve the ESRP=20 >to ESGW communications route path. > >Generally, a tel:uri is what is entered at the endstation, and=20 >not what is the product of a mapping conversion at a SIP proxy=20 >*from* a SIP URI. > >In other words, tel:911 is what could be entered by an IP=20 >phone, and shows up as the Request-URI in the INVITE to a ESRP=20 >server. This ESRP needs to do a mapping function to determine=20 >which PSAP is going to get this call set-up message. Take this=20 >basic topology (apologies James for the ESGW reference, but=20 >this makes the most sense to some of us for this discussion): > >IP phone =3D=3D> ESRP =3D=3D> ESGW =3D=3D> SR =3D=3D> PSAP > >The IP Phone creates an INVITE such as this: > >INVITE tel:911 SIP/2.0 >Via: SIP/2.0/UDP ipphone1.localdomain.com; > branch=3Dz9hG4bK776asdhs >To: 911 >From: Roger >Max-Forwards: 70 >Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REGISTER, > REFER, NOTIFY, UPDATE >Call-ID: a84b4c76e66710@localdomain.com >CSeq: 1 INVITE >Contact: >Content-Type: mulipart/mixed; boundary=3D--0a1 >Content-length: ... > >--0a1 >Content-Type: application/sdp >(SDP) >--0a1 >Content-Type: pidf-lo+xml >(PIDF-LO) >--0a1-- > >Now, the ESRP receives this message, realizes this is an=20 >emergency call, knows to look for the location message body to=20 >ship off to a mapping server. This could be a local process,=20 >or use one of the various methods discussed on this list. I'm=20 >not playing favorites in that regard for now. > >The nut of this discussion is what the ESRP gets back from the=20 >mapping server. > >Is this, or can it be, a tel:uri? > >The way I read the requirement as written, even with my=20 >alteration above, is I think both are saying it's possible to=20 >use a tel:uri from the mapping server to replace the existing=20 >Request-URI (tel:911 here) with. What is this uri going to=20 >look like, and how exactly will this get the message towards=20 >the ESGW to ensure it meets the i2 requirement of getting to=20 >the Selective Router and towards the proper PSAP? > >Are we talking about keeping the Request-URI the same and=20 >adding a Route header of the ESGW? This isn't the mapping=20 >protocol function as I'm understanding it to be, although this=20 >could work, as long as the ESRP maintains dialog state and the=20 >Contact header remains the same in case there are issues=20 >involving redundancy with a callback situation. > >I don't see why a tel:uri has to stay as the Request-URI, or=20 >be swapped with another tel:uri. How is this tel:uri going to=20 >all of a sudden make the non-IP-enabled PSAP work? > >I should think that any ESGW receiving an INVITE from a ESRP=20 >with an agreeable emergency declaration should translate that=20 >INVITE into starting a call set-up to the Selective Router=20 >with the ANI of the user. How does a tel:uri scheme enable=20 >this, whereas a SIP URI would not? > > > >At 03:03 PM 12/6/2005 -0800, Roger Marshall wrote: >>James: >>It seems like we have agreement (I think) that tel:uri's shouldn't be=20 >>excluded altogether. I also agree that there is a preference as to=20 >>which uri scheme is to be used, (e.g. sip:uri over a=20 >tel:uri), so I've=20 >>revised the text: >> >>PROPOSED (updated 12/06) TEXT: >>"Ideally, the mapping protocol would yield a URI (e.g. sip:uri,=20 >>sips:uri, etc.) which would allow an emergency call to be completed=20 >>using IP end-to-end (possibly, via the Internet). Though this is the=20 >>goal, not every PSAP will have IP based connectivity right=20 >away, so the=20 >>URI scheme is not fixed. Given these conditions, alternate URI=20 >>schemes, >> >>such as tel:uri, are allowed in order to complete calls over=20 >the PSTN." >> >>Agreeable? >> >>Roger Marshall >> >> >> >-----Original Message----- >> >From: James M. Polk [mailto:jmpolk@cisco.com] >> >Sent: Tuesday, December 06, 2005 1:03 PM >> >To: Marc Linsner; br@brianrosen.net; Roger Marshall; ecrit@ietf.org >> >Subject: RE: [Ecrit] Issue 28: NENA Comments on=20 >> >draft-ietf-ecrit-requirements-00 -Alternate Routes >> > >> >In-line >> > >> >At 03:30 PM 12/6/2005 -0500, Marc Linsner wrote: >> >>In-line..... >> >> >> >>snip...... >> >> >> >> > >> >> > If a tel:uri is returned, we need to do more processing, like=20 >> >> > convert this uri to a SIP URI to route the message *because* we=20 >> >> > do not know if the next hop proxy is PSAP, and it might be a=20 >> >> > intermediate proxy doing the final resolution of URI to IP >> >address, >> >> > or AOR (or a state's emergency VSP) to contact address (of a=20 >> >> > specific city's PSAP). >> >> > >> >> >> >> From an ECRIT pov, I don't agree. Yes, the SIP proxy may perform=20 >> >>different (including additional) steps in order to resolve a=20 >> >>tel:uri, but ECRIT is complete at this point. A tel:uri=20 >is valid in=20 >> >>the SIP domain so it should be valid in the ECRIT domain. >> > >> >but it's not routable in the SIP domain, and the SIP specs=20 >state that=20 >> >conversion is necessary to make the message routable. This is an=20 >> >extra step that is less desired. >> > >> > >> >> > >All of them route a tel uri. Every VoIP system I know of >> >does this >> >> > >seamlessly. Do we really need to say this in a requirements >> >> > document? >> >> > > >> >> > >Further, Roger's "not all PSAPs may have IP based >> >connectivity" is >> >> > >useful to motivate why a tel uri may be returned. >> >> > >> >> > Movitvate? Why do we need motivation here? >> >> > >> >> > Whether my text is used or not, this requirement has the >> >ability to >> >> > have a hierarchy of preferred options listed, and my text >> >gives that >> >> > order for motivation to work towards the most secure solution. =20 >> >> > It does not dismiss tel:uris, it just says they are not=20 >preferred. >> >> >> >>The designer of the PSAP system will decide the=20 >architecture of the=20 >> >>contact mechanism. Guidance may be offered in an >> >architecture BCP, but >> >>I'm not sure it's proper for a requirements draft. >> > >> >This is a ridiculous statement. Of course requirements=20 >documents give=20 >> >preferential orders to mechanisms. The offered text here is not=20 >> >absolute, and does not say that a tel:uri is forbidden. >> > >> > >> >>I vote for Roger's text. >> >> >> >>-Marc- >> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Dec 06 20:00:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejnfg-0003wf-2y; Tue, 06 Dec 2005 20:00:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejnfc-0003u2-JL for ecrit@megatron.ietf.org; Tue, 06 Dec 2005 20:00:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15371 for ; Tue, 6 Dec 2005 19:59:40 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejo1B-0000dP-VM for ecrit@ietf.org; Tue, 06 Dec 2005 20:22:51 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 06 Dec 2005 17:00:16 -0800 X-IronPort-AV: i="3.99,223,1131350400"; d="scan'208"; a="682171511:sNHT2782795142" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB70xrA0022244; Tue, 6 Dec 2005 17:00:13 -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.211); Tue, 6 Dec 2005 20:00:04 -0500 Received: from jmpolk-wxp.cisco.com ([10.86.242.192]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Dec 2005 20:00:03 -0500 Message-Id: <4.3.2.7.2.20051206185801.03239658@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Dec 2005 19:00:02 -0600 To: "Roger Marshall" , "Marc Linsner" , , From: "James M. Polk" Subject: RE: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes In-Reply-To: <8C837214C95C864C9F34F3635C2A657503BCEE1B@SEA-EXCHVS-2.tele comsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 07 Dec 2005 01:00:03.0784 (UTC) FILETIME=[8E9B4C80:01C5FAC9] X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Roger At 04:46 PM 12/6/2005 -0800, Roger Marshall wrote: >James: >Your explanation makes sense to me. Allow the use of tel:uri at the >"edge" (e.g. UA-to-ESRP), but don't let it be used in std core SIP >signaling. Did I understand this to be your point? yep >Assuming this is the case, the inclusion of the MUST/MAY language would >turn the paragraph into a real requirement, something that doesn't >belong in the Intro section. you're right, lower case all the requirements words then to keep the meaning. >Also, Rohan's suggestion of removing tel:uri from the "emergency >address" defn makes more sense too, and I think is warranted, as >"tel:uri" is used nowhere else in the document. > >Question remains, what should this paragraph say, is it still necessary >as written, and if so, where do we place it. I think so, but I haven't looked for a propoer place within the Intro yet. >Roger Marshall > > >-----Original Message----- > >From: James M. Polk [mailto:jmpolk@cisco.com] > >Sent: Tuesday, December 06, 2005 4:21 PM > >To: Roger Marshall; Marc Linsner; br@brianrosen.net; ecrit@ietf.org > >Subject: RE: [Ecrit] Issue 28: NENA Comments on > >draft-ietf-ecrit-requirements-00 -Alternate Routes > > > >Roger > > > >I'll propose what you wrote with the appropriate MUSTs, > >SHOULDs and MAYs like most requirements should have: > > > >"Ideally, the mapping protocol SHOULD yield a URI (e.g. > >sip:uri, sips:uri, etc.) which would allow an emergency call > >to be routed using IP end-to-end (possibly, via the > >Internet). Though this is the goal, not every PSAP will have > >IP based connectivity right away, so the URI scheme MAY be > >different. Given these conditions, alternate URI schemes, > >such as tel:uri, MAY be used in order to complete calls over the PSTN." > > > >I don't know if we want to get into specifying that dialog > >generating SIP requests SHOULD have a SIP or SIPS URI. INVITE > >is such a request, whereas Rohan's XMPP scheme example would > >not be used to generate a dialog, so that wouldn't be a contradiction. > > > >Now for me scratching my head at the second sentence: > >I'm a bit vague as to how a tel:uri is going to solve the ESRP > >to ESGW communications route path. > > > >Generally, a tel:uri is what is entered at the endstation, and > >not what is the product of a mapping conversion at a SIP proxy > >*from* a SIP URI. > > > >In other words, tel:911 is what could be entered by an IP > >phone, and shows up as the Request-URI in the INVITE to a ESRP > >server. This ESRP needs to do a mapping function to determine > >which PSAP is going to get this call set-up message. Take this > >basic topology (apologies James for the ESGW reference, but > >this makes the most sense to some of us for this discussion): > > > >IP phone ==> ESRP ==> ESGW ==> SR ==> PSAP > > > >The IP Phone creates an INVITE such as this: > > > >INVITE tel:911 SIP/2.0 > >Via: SIP/2.0/UDP ipphone1.localdomain.com; > > branch=z9hG4bK776asdhs > >To: 911 > >From: Roger > >Max-Forwards: 70 > >Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REGISTER, > > REFER, NOTIFY, UPDATE > >Call-ID: a84b4c76e66710@localdomain.com > >CSeq: 1 INVITE > >Contact: > >Content-Type: mulipart/mixed; boundary=--0a1 > >Content-length: ... > > > >--0a1 > >Content-Type: application/sdp > >(SDP) > >--0a1 > >Content-Type: pidf-lo+xml > >(PIDF-LO) > >--0a1-- > > > >Now, the ESRP receives this message, realizes this is an > >emergency call, knows to look for the location message body to > >ship off to a mapping server. This could be a local process, > >or use one of the various methods discussed on this list. I'm > >not playing favorites in that regard for now. > > > >The nut of this discussion is what the ESRP gets back from the > >mapping server. > > > >Is this, or can it be, a tel:uri? > > > >The way I read the requirement as written, even with my > >alteration above, is I think both are saying it's possible to > >use a tel:uri from the mapping server to replace the existing > >Request-URI (tel:911 here) with. What is this uri going to > >look like, and how exactly will this get the message towards > >the ESGW to ensure it meets the i2 requirement of getting to > >the Selective Router and towards the proper PSAP? > > > >Are we talking about keeping the Request-URI the same and > >adding a Route header of the ESGW? This isn't the mapping > >protocol function as I'm understanding it to be, although this > >could work, as long as the ESRP maintains dialog state and the > >Contact header remains the same in case there are issues > >involving redundancy with a callback situation. > > > >I don't see why a tel:uri has to stay as the Request-URI, or > >be swapped with another tel:uri. How is this tel:uri going to > >all of a sudden make the non-IP-enabled PSAP work? > > > >I should think that any ESGW receiving an INVITE from a ESRP > >with an agreeable emergency declaration should translate that > >INVITE into starting a call set-up to the Selective Router > >with the ANI of the user. How does a tel:uri scheme enable > >this, whereas a SIP URI would not? > > > > > > > >At 03:03 PM 12/6/2005 -0800, Roger Marshall wrote: > >>James: > >>It seems like we have agreement (I think) that tel:uri's shouldn't be > >>excluded altogether. I also agree that there is a preference as to > >>which uri scheme is to be used, (e.g. sip:uri over a > >tel:uri), so I've > >>revised the text: > >> > >>PROPOSED (updated 12/06) TEXT: > >>"Ideally, the mapping protocol would yield a URI (e.g. sip:uri, > >>sips:uri, etc.) which would allow an emergency call to be completed > >>using IP end-to-end (possibly, via the Internet). Though this is the > >>goal, not every PSAP will have IP based connectivity right > >away, so the > >>URI scheme is not fixed. Given these conditions, alternate URI > >>schemes, > >> > >>such as tel:uri, are allowed in order to complete calls over > >the PSTN." > >> > >>Agreeable? > >> > >>Roger Marshall > >> > >> > >> >-----Original Message----- > >> >From: James M. Polk [mailto:jmpolk@cisco.com] > >> >Sent: Tuesday, December 06, 2005 1:03 PM > >> >To: Marc Linsner; br@brianrosen.net; Roger Marshall; ecrit@ietf.org > >> >Subject: RE: [Ecrit] Issue 28: NENA Comments on > >> >draft-ietf-ecrit-requirements-00 -Alternate Routes > >> > > >> >In-line > >> > > >> >At 03:30 PM 12/6/2005 -0500, Marc Linsner wrote: > >> >>In-line..... > >> >> > >> >>snip...... > >> >> > >> >> > > >> >> > If a tel:uri is returned, we need to do more processing, like > >> >> > convert this uri to a SIP URI to route the message *because* we > >> >> > do not know if the next hop proxy is PSAP, and it might be a > >> >> > intermediate proxy doing the final resolution of URI to IP > >> >address, > >> >> > or AOR (or a state's emergency VSP) to contact address (of a > >> >> > specific city's PSAP). > >> >> > > >> >> > >> >> From an ECRIT pov, I don't agree. Yes, the SIP proxy may perform > >> >>different (including additional) steps in order to resolve a > >> >>tel:uri, but ECRIT is complete at this point. A tel:uri > >is valid in > >> >>the SIP domain so it should be valid in the ECRIT domain. > >> > > >> >but it's not routable in the SIP domain, and the SIP specs > >state that > >> >conversion is necessary to make the message routable. This is an > >> >extra step that is less desired. > >> > > >> > > >> >> > >All of them route a tel uri. Every VoIP system I know of > >> >does this > >> >> > >seamlessly. Do we really need to say this in a requirements > >> >> > document? > >> >> > > > >> >> > >Further, Roger's "not all PSAPs may have IP based > >> >connectivity" is > >> >> > >useful to motivate why a tel uri may be returned. > >> >> > > >> >> > Movitvate? Why do we need motivation here? > >> >> > > >> >> > Whether my text is used or not, this requirement has the > >> >ability to > >> >> > have a hierarchy of preferred options listed, and my text > >> >gives that > >> >> > order for motivation to work towards the most secure solution. > >> >> > It does not dismiss tel:uris, it just says they are not > >preferred. > >> >> > >> >>The designer of the PSAP system will decide the > >architecture of the > >> >>contact mechanism. Guidance may be offered in an > >> >architecture BCP, but > >> >>I'm not sure it's proper for a requirements draft. > >> > > >> >This is a ridiculous statement. Of course requirements > >documents give > >> >preferential orders to mechanisms. The offered text here is not > >> >absolute, and does not say that a tel:uri is forbidden. > >> > > >> > > >> >>I vote for Roger's text. > >> >> > >> >>-Marc- > >> > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Dec 06 20:25:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejo3O-0005EK-Jw; Tue, 06 Dec 2005 20:25:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejo3M-0005D4-SV for ecrit@megatron.ietf.org; Tue, 06 Dec 2005 20:25:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18086 for ; Tue, 6 Dec 2005 20:24:12 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjoOx-0001VA-FD for ecrit@ietf.org; Tue, 06 Dec 2005 20:47:24 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Tue, 6 Dec 2005 20:24:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Date: Tue, 6 Dec 2005 17:24:53 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657503BCEE54@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Thread-Index: AcX6xlcTWOj5mlhsQpChc7pBanzbJAAAVn0Q From: "Roger Marshall" To: "Ted Hardie" , "James M. Polk" , "Marc Linsner" , , X-Spam-Score: 2.6 (++) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Ted: See inline... >-----Original Message----- >From: Ted Hardie [mailto:hardie@qualcomm.com]=20 >Sent: Tuesday, December 06, 2005 4:37 PM >To: James M. Polk; Roger Marshall; Marc Linsner;=20 >br@brianrosen.net; ecrit@ietf.org >Subject: RE: [Ecrit] Issue 28: NENA Comments on=20 >draft-ietf-ecrit-requirements-00 -Alternate Routes > >At 6:21 PM -0600 12/6/05, James M. Polk wrote: >>Roger >> >>I'll propose what you wrote with the appropriate MUSTs,=20 >SHOULDs and MAYs like most requirements should have: >> >>"Ideally, the mapping protocol SHOULD yield a URI (e.g. sip:uri,=20 >>sips:uri, etc.) which would allow an emergency call to be=20 >routed using=20 >>IP end-to-end (possibly, via the Internet). Though this is=20 >the goal,=20 >>not every PSAP will have IP based connectivity right away, so the URI=20 >>scheme MAY be different. Given these conditions, alternate=20 >URI schemes,=20 >>such as tel:uri, MAY be used in order to complete calls over=20 >the PSTN." > >Written this way, I would interpret this to mean that any URI=20 >scheme which mapped to a protocol that used IP end-to-end was=20 >in the preferred set, and that URI schemes like tel which=20 >required gateways or further mapping >in this context were in a less preferred set. I am fine=20 >with this, since I think >the choice of specific URI schemes (sip, sips) falls out=20 >pretty easily in operational reality, but I wanted to flag it=20 >in case James meant it to say "SHOULD yield a SIP or SIPS URI=20 >which would allow an emergency call to be routed" and to put=20 >non-SIP URI schemes in the same bucket whether they were IP=20 >end-to-end or not. To put this in another way, would a=20 >registered scheme of SMS be in the preferred set if it were=20 >possible to use it over IP without gateways? I like the idea of a "preferred set" of uri's. That is something that the current doc DOES NOT currently mention. Is there text that's needed? > >Also, I believe we said earlier that the mapping protocol=20 >would yield one or more URIs, with at most one per scheme. So=20 >you could have a SIP URI returned, as well as an SMS URI, with=20 >the preference order set by the client according to its capabilities. I'm glad you brought this up, since we currently DON'T yet have the "with at most one per scheme" qualification. I think we should, but we need to be careful, since there are a number of multiple uri scenarios mentioned. Here are the four: 1. The mapping server returns two solutions for a given request and location... Mapping Client: A Mapping Client interacts with the=20 Mapping Server to learn one or multiple URIs for a given location. 2. Though I'm not sure this is Id2's original intent, since there are various service types are mentioned, could this take the form of sip:psap1@domain.net vs. hazmat.psap1@domain.net vs. amber.psap1@domain.net (or some other combi) that could be provided from a mapping server? Id2. Universal Identifier Resolution: Where multiple=20 emergency service types exist, it MUST be possible to treat each=20 emergency identifier separately, based on the specific type of=20 emergency help requested. 3. The following requirement says nothing of scheme limits. Ma5. The mapping protocol MUST allow a response to carry multiple URIs. 4. Here, in fact the scheme would likely be the same, just with two separate user parts of the PSAP emergency address. Ma7. Multiple PSAP URI's:"> The mapping protocol MUST=20 be able to return multiple URIs for different PSAPs that cover the same=20 area. SUMMARY: Number 3 above seems to be the place where such a qualification needs to live. Do others agree? PROPOSED CHANGE to Ma5: Ma5'. The mapping protocol MUST allow a response to carry multiple URIs, and to include the same emergency address if differentiated by uri scheme. Motivation: There may be two URIs returned, both an SMS URI and a SIP URI, which the client can select by choice, based on it's capability and/or preference setting. Roger Marshall. > regards, > Ted > > > >> >> >>I don't know if we want to get into specifying that dialog=20 >generating SIP requests SHOULD have a SIP or SIPS URI. INVITE=20 >is such a request, whereas Rohan's XMPP scheme example would=20 >not be used to generate a dialog, so that wouldn't be a contradiction. >> >>Now for me scratching my head at the second sentence: >>I'm a bit vague as to how a tel:uri is going to solve the=20 >ESRP to ESGW communications route path. >> >>Generally, a tel:uri is what is entered at the endstation,=20 >and not what is the product of a mapping conversion at a SIP=20 >proxy *from* a SIP URI. >> >>In other words, tel:911 is what could be entered by an IP=20 >phone, and shows up as the Request-URI in the INVITE to a ESRP=20 >server. This ESRP needs to do a mapping function to determine=20 >which PSAP is going to get this call set-up message. Take this=20 >basic topology (apologies James for the ESGW reference, but=20 >this makes the most sense to some of us for this discussion): >> >>IP phone =3D=3D> ESRP =3D=3D> ESGW =3D=3D> SR =3D=3D> PSAP >> >>The IP Phone creates an INVITE such as this: >> >>INVITE tel:911 SIP/2.0 >>Via: SIP/2.0/UDP ipphone1.localdomain.com; >> branch=3Dz9hG4bK776asdhs >>To: 911 >>From: Roger >>Max-Forwards: 70 >>Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REGISTER, >> REFER, NOTIFY, UPDATE >>Call-ID: a84b4c76e66710@localdomain.com >>CSeq: 1 INVITE >>Contact: >>Content-Type: mulipart/mixed; boundary=3D--0a1 >>Content-length: ... >> >>--0a1 >>Content-Type: application/sdp >>(SDP) >>--0a1 >>Content-Type: pidf-lo+xml >>(PIDF-LO) >>--0a1-- >> >>Now, the ESRP receives this message, realizes this is an=20 >emergency call, knows to look for the location message body to=20 >ship off to a mapping server. This could be a local process,=20 >or use one of the various methods discussed on this list. I'm=20 >not playing favorites in that regard for now. >> >>The nut of this discussion is what the ESRP gets back from=20 >the mapping server. >> >>Is this, or can it be, a tel:uri? >> >>The way I read the requirement as written, even with my=20 >alteration above, is I think both are saying it's possible to=20 >use a tel:uri from the mapping server to replace the existing=20 >Request-URI (tel:911 here) with. What is this uri going to=20 >look like, and how exactly will this get the message towards=20 >the ESGW to ensure it meets the i2 requirement of getting to=20 >the Selective Router and towards the proper PSAP? >> >>Are we talking about keeping the Request-URI the same and=20 >adding a Route header of the ESGW? This isn't the mapping=20 >protocol function as I'm understanding it to be, although this=20 >could work, as long as the ESRP maintains dialog state and the=20 >Contact header remains the same in case there are issues=20 >involving redundancy with a callback situation. >> >>I don't see why a tel:uri has to stay as the Request-URI, or=20 >be swapped with another tel:uri. How is this tel:uri going to=20 >all of a sudden make the non-IP-enabled PSAP work? >> >>I should think that any ESGW receiving an INVITE from a ESRP=20 >with an agreeable emergency declaration should translate that=20 >INVITE into starting a call set-up to the Selective Router=20 >with the ANI of the user. How does a tel:uri scheme enable=20 >this, whereas a SIP URI would not? >> >> >> >>At 03:03 PM 12/6/2005 -0800, Roger Marshall wrote: >>>James: >>>It seems like we have agreement (I think) that tel:uri's=20 >shouldn't be=20 >>>excluded altogether. I also agree that there is a preference as to=20 >>>which uri scheme is to be used, (e.g. sip:uri over a=20 >tel:uri), so I've=20 >>>revised the text: >>> >>>PROPOSED (updated 12/06) TEXT: >>>"Ideally, the mapping protocol would yield a URI (e.g. sip:uri,=20 >>>sips:uri, etc.) which would allow an emergency call to be completed=20 >>>using IP end-to-end (possibly, via the Internet). Though=20 >this is the=20 >>>goal, not every PSAP will have IP based connectivity right away, so=20 >>>the URI scheme is not fixed. Given these conditions, alternate URI=20 >>>schemes, >>> >>>such as tel:uri, are allowed in order to complete calls over=20 >the PSTN." >>> >>>Agreeable? >>> >>>Roger Marshall >>> >>> >>>>-----Original Message----- >>>>From: James M. Polk [mailto:jmpolk@cisco.com] >>>>Sent: Tuesday, December 06, 2005 1:03 PM >>>>To: Marc Linsner; br@brianrosen.net; Roger Marshall; ecrit@ietf.org >>>>Subject: RE: [Ecrit] Issue 28: NENA Comments on=20 >>>>draft-ietf-ecrit-requirements-00 -Alternate Routes >>>> >>>>In-line >>>> >>>>At 03:30 PM 12/6/2005 -0500, Marc Linsner wrote: >>>>>In-line..... >>>>> >>>>>snip...... >>>>> >>>>> > >>>>> > If a tel:uri is returned, we need to do more processing, like=20 >>>>> > convert this uri to a SIP URI to route the message *because* we=20 >>>>> > do not know if the next hop proxy is PSAP, and it might be a=20 >>>>> > intermediate proxy doing the final resolution of URI to IP >>>>address, >>>>> > or AOR (or a state's emergency VSP) to contact address (of a=20 >>>>> > specific city's PSAP). >>>>> > >>>>> >>>>> From an ECRIT pov, I don't agree. Yes, the SIP proxy may perform=20 >>>>>different (including additional) steps in order to resolve a=20 >>>>>tel:uri, but ECRIT is complete at this point. A tel:uri=20 >is valid in=20 >>>>>the SIP domain so it should be valid in the ECRIT domain. >>>> >>>>but it's not routable in the SIP domain, and the SIP specs=20 >state that=20 >>>>conversion is necessary to make the message routable. This is an=20 >>>>extra step that is less desired. >>>> >>>> >>>>> > >All of them route a tel uri. Every VoIP system I know of >>>>does this >>>>> > >seamlessly. Do we really need to say this in a requirements >>>>> > document? >>>>> > > >>>>> > >Further, Roger's "not all PSAPs may have IP based >>>>connectivity" is >>>>> > >useful to motivate why a tel uri may be returned. >>>>> > >>>>> > Movitvate? Why do we need motivation here? >>>>> > >>>>> > Whether my text is used or not, this requirement has the >>>>ability to >>>>> > have a hierarchy of preferred options listed, and my text >>>>gives that >>>>> > order for motivation to work towards the most secure solution. =20 >>>>> > It does not dismiss tel:uris, it just says they are not=20 >preferred. >>>>> >>>>>The designer of the PSAP system will decide the=20 >architecture of the=20 >>>>>contact mechanism. Guidance may be offered in an >>>>architecture BCP, but >>>>>I'm not sure it's proper for a requirements draft. >>>> >>>>This is a ridiculous statement. Of course requirements=20 >documents give=20 >>>>preferential orders to mechanisms. The offered text here is not=20 >>>>absolute, and does not say that a tel:uri is forbidden. >>>> >>>> >>>>>I vote for Roger's text. >>>>> >>>>>-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 Dec 07 13:07:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek3h5-0002rW-9k; Wed, 07 Dec 2005 13:07:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek3h3-0002rN-Mw for ecrit@megatron.ietf.org; Wed, 07 Dec 2005 13:07:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07177 for ; Wed, 7 Dec 2005 13:06:14 -0500 (EST) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek42k-00014w-Nw for ecrit@ietf.org; Wed, 07 Dec 2005 13:29:34 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jB7I6hLx007698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 7 Dec 2005 10:06:44 -0800 Received: from [67.188.157.106] (vpn-10-50-0-29.qualcomm.com [10.50.0.29]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jB7I6bYg003811; Wed, 7 Dec 2005 10:06:40 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <8C837214C95C864C9F34F3635C2A657503BCEE54@SEA-EXCHVS-2.telecomsys.com> References: <8C837214C95C864C9F34F3635C2A657503BCEE54@SEA-EXCHVS-2.telecomsys.com> Date: Wed, 7 Dec 2005 10:06:36 -0800 To: "Roger Marshall" , "James M. Polk" , "Marc Linsner" , , From: Ted Hardie Subject: RE: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 5:24 PM -0800 12/6/05, Roger Marshall wrote: >I'm glad you brought this up, since we currently DON'T yet have the >"with at most one per scheme" qualification. I think we should, but we >need to be careful, since there are a number of multiple uri scenarios >mentioned. Here are the four: I believe it was Henning who brought this up initially. His logic, if I remember correctly, was that we didn't want the client to have to order multiple responses for the same URI scheme; the service should return the best/correct answer for that scheme and any forwarding or redirection that occurred should take place in the protocol processing for the scheme. In the SIP example, the processing would return something like "sips:psap1@dallas-erc.tx.us"; if that psap were not available, it would be the SIP mechanisms, not the mapping protocol, that handle the traffic moving to sips:psap2@dallas-erc.tx.us . I personally agree with this logic, and I hope others do as well. >1. The mapping server returns two solutions for a given request and >location... > >Mapping Client: A Mapping Client interacts with the >Mapping Server to learn one or multiple URIs for a given location. > >2. Though I'm not sure this is Id2's original intent, since there are >various service types are mentioned, could this take the form of >sip:psap1@domain.net vs. hazmat.psap1@domain.net vs. >amber.psap1@domain.net (or some other combi) that could be provided from >a mapping server? > >Id2. Universal Identifier Resolution: Where multiple >emergency service types exist, it MUST be possible to treat each >emergency identifier separately, based on the specific type of >emergency help requested. > >3. The following requirement says nothing of scheme limits. > >Ma5. The mapping protocol MUST allow a response to carry multiple URIs. I would add it here, as "It SHOULD return at most one URI for each scheme it supports, in order to avoid shifting the burden of discovery back to the client". I think SHOULD is the right level here, just to allow for special cases where multiple URIs are unavoidable or where the scheme has no provision for forwarding/redirection. That might, though, cause us to say whether a return set containing multiple URIs in a single scheme is ordered or unordered. I also would have no real heartburn if we said MUST, and let people draw the conclusion that anything that has no redirection/ redundancy/forwarding might be a bad choice for this use. regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 07 19:45:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek9v4-0006zw-2a; Wed, 07 Dec 2005 19:45:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek9v2-0006zo-NC for ecrit@megatron.ietf.org; Wed, 07 Dec 2005 19:45:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02257 for ; Wed, 7 Dec 2005 19:45:04 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkAGp-00029Z-5s for ecrit@ietf.org; Wed, 07 Dec 2005 20:08:27 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 7 Dec 2005 19:45:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Date: Wed, 7 Dec 2005 16:45:37 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657503BCF72B@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Thread-Index: AcX7WrAj2N+mXyDbQ8iNlnkSqAbdbQAMRZvQ From: "Roger Marshall" To: X-Spam-Score: 2.7 (++) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Based on Ted's response (ref. below thread) ... I propose to insert the following new (Ma5x) requirement in order to try to address the issue of same scheme avoidance when it comes to multiple URIs returned: NEW (PROPOSED) REQUIREMENT: Ma5x. When multiple URIs are returned, the mapping protocol=20 SHOULD differentiate multiple URIs by use of different URI=20 schemes. Motivation: There may be two URIs returned, both an SMS URI=20 and a SIP URI, which the client can select by choice, based=20 on it's capability and/or preference setting. Are the other (existing) requirements sufficient to address use cases where same schemas might be returned if unavoidable?=20 Please comment if objectionable. Thanks. Roger Marshall >-----Original Message----- >From: Ted Hardie [mailto:hardie@qualcomm.com]=20 >Sent: Wednesday, December 07, 2005 10:07 AM >To: Roger Marshall; James M. Polk; Marc Linsner;=20 >br@brianrosen.net; ecrit@ietf.org >Subject: RE: [Ecrit] Issue 28: NENA Comments on=20 >draft-ietf-ecrit-requirements-00 -Alternate Routes > >At 5:24 PM -0800 12/6/05, Roger Marshall wrote: >>I'm glad you brought this up, since we currently DON'T yet have the=20 >>"with at most one per scheme" qualification. I think we=20 >should, but we=20 >>need to be careful, since there are a number of multiple uri=20 >scenarios=20 >>mentioned. Here are the four: > >I believe it was Henning who brought this up initially. His=20 >logic, if I remember correctly, was that we didn't want the=20 >client to have to order multiple responses for the same URI=20 >scheme; the service should return the best/correct answer for=20 >that scheme and any forwarding or redirection that occurred=20 >should take place in the protocol processing for the scheme. =20 >In the SIP example, the processing would return something like=20 >"sips:psap1@dallas-erc.tx.us"; if that psap were not=20 >available, it would be the SIP mechanisms, not the mapping=20 >protocol, that handle the traffic moving to=20 >sips:psap2@dallas-erc.tx.us . > >I personally agree with this logic, and I hope others do as well. > > >>1. The mapping server returns two solutions for a given request and=20 >>location... >> >>Mapping Client: A Mapping Client interacts with the Mapping Server to=20 >>learn one or multiple URIs for a given location. >> >>2. Though I'm not sure this is Id2's original intent, since there are=20 >>various service types are mentioned, could this take the form of=20 >>sip:psap1@domain.net vs. hazmat.psap1@domain.net vs. >>amber.psap1@domain.net (or some other combi) that could be provided=20 >>from a mapping server? >> >>Id2. Universal Identifier Resolution: Where multiple=20 >emergency service=20 >>types exist, it MUST be possible to treat each emergency identifier=20 >>separately, based on the specific type of emergency help requested. >> >>3. The following requirement says nothing of scheme limits. >> >>Ma5. The mapping protocol MUST allow a response to carry=20 >multiple URIs. > >I would add it here, as "It SHOULD return at most one URI for=20 >each scheme it supports, in order to avoid shifting the burden=20 >of discovery back to the client". > >I think SHOULD is the right level here, just to allow for=20 >special cases where multiple URIs are unavoidable or where the=20 >scheme has no provision for forwarding/redirection. That=20 >might, though, cause us to say whether a return set containing=20 >multiple URIs in a single scheme is ordered or >unordered. I also would have no real heartburn if we said MUST, >and let people draw the conclusion that anything that has no=20 >redirection/ redundancy/forwarding might be a bad choice for this use. > > regards, > Ted Hardie > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 07 20:01:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkA9i-0001o3-H7; Wed, 07 Dec 2005 20:01:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkA9g-0001nv-Si for ecrit@megatron.ietf.org; Wed, 07 Dec 2005 20:01:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04059 for ; Wed, 7 Dec 2005 20:00:13 -0500 (EST) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkAVU-0002hv-Rd for ecrit@ietf.org; Wed, 07 Dec 2005 20:23:37 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jB810iul011214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 7 Dec 2005 17:00:44 -0800 Received: from [67.188.157.106] (vpn-10-50-0-29.qualcomm.com [10.50.0.29]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jB810fgu000344; Wed, 7 Dec 2005 17:00:42 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <8C837214C95C864C9F34F3635C2A657503BCF72B@SEA-EXCHVS-2.telecomsys.com> References: <8C837214C95C864C9F34F3635C2A657503BCF72B@SEA-EXCHVS-2.telecomsys.com> Date: Wed, 7 Dec 2005 17:00:40 -0800 To: "Roger Marshall" , From: Ted Hardie Subject: RE: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 4:45 PM -0800 12/7/05, Roger Marshall wrote: > >NEW (PROPOSED) REQUIREMENT: > >Ma5x. When multiple URIs are returned, the mapping protocol >SHOULD differentiate multiple URIs by use of different URI >schemes. Sorry, but I think this doesn't quite capture it. This sounds like a server wanting to return multiple URIs should differentiate them by scheme (e.g. assign one to sip and one to sips), where what we want to say is that servers may return multiple URIs when the PSAP supports multiple contact protocols, but should return only one per protocol, to avoid the client getting muddled. Proposed replacement text: Ma5x. The mapping protocol MAY return multiple URIs. It SHOULD return only one URI per scheme, so that clients are not required to select among different targets for the same contact protocol. Motivation: There may be two or more URIs returned when multiple contact protocols are available (e.g. SIP and SMS). The client may select among multiple contact protocols based on its capabilities, preference settings, or availability. Does this replacement text work for you? regards, Ted >Motivation: There may be two URIs returned, both an SMS URI >and a SIP URI, which the client can select by choice, based >on it's capability and/or preference setting. > >Are the other (existing) requirements sufficient to address use cases >where same schemas might be returned if unavoidable? > >Please comment if objectionable. > > >Thanks. > >Roger Marshall > > > >>-----Original Message----- >>From: Ted Hardie [mailto:hardie@qualcomm.com] >>Sent: Wednesday, December 07, 2005 10:07 AM >>To: Roger Marshall; James M. Polk; Marc Linsner; >>br@brianrosen.net; ecrit@ietf.org >>Subject: RE: [Ecrit] Issue 28: NENA Comments on >>draft-ietf-ecrit-requirements-00 -Alternate Routes >> >>At 5:24 PM -0800 12/6/05, Roger Marshall wrote: >>>I'm glad you brought this up, since we currently DON'T yet have the >>>"with at most one per scheme" qualification. I think we >>should, but we >>>need to be careful, since there are a number of multiple uri >>scenarios >>>mentioned. Here are the four: >> >>I believe it was Henning who brought this up initially. His >>logic, if I remember correctly, was that we didn't want the >>client to have to order multiple responses for the same URI >>scheme; the service should return the best/correct answer for >>that scheme and any forwarding or redirection that occurred >>should take place in the protocol processing for the scheme. >>In the SIP example, the processing would return something like >>"sips:psap1@dallas-erc.tx.us"; if that psap were not >>available, it would be the SIP mechanisms, not the mapping >>protocol, that handle the traffic moving to >>sips:psap2@dallas-erc.tx.us . >> >>I personally agree with this logic, and I hope others do as well. >> >> >>>1. The mapping server returns two solutions for a given request and >>>location... >>> >>>Mapping Client: A Mapping Client interacts with the Mapping Server to >>>learn one or multiple URIs for a given location. >>> >>>2. Though I'm not sure this is Id2's original intent, since there are >>>various service types are mentioned, could this take the form of >>>sip:psap1@domain.net vs. hazmat.psap1@domain.net vs. >>>amber.psap1@domain.net (or some other combi) that could be provided >>>from a mapping server? >>> >>>Id2. Universal Identifier Resolution: Where multiple >>emergency service >>>types exist, it MUST be possible to treat each emergency identifier >>>separately, based on the specific type of emergency help requested. >>> >>>3. The following requirement says nothing of scheme limits. >>> >>>Ma5. The mapping protocol MUST allow a response to carry >>multiple URIs. >> >>I would add it here, as "It SHOULD return at most one URI for >>each scheme it supports, in order to avoid shifting the burden >>of discovery back to the client". >> >>I think SHOULD is the right level here, just to allow for > >special cases where multiple URIs are unavoidable or where the >>scheme has no provision for forwarding/redirection. That >>might, though, cause us to say whether a return set containing >>multiple URIs in a single scheme is ordered or >>unordered. I also would have no real heartburn if we said MUST, >>and let people draw the conclusion that anything that has no >>redirection/ redundancy/forwarding might be a bad choice for this use. >> >> regards, >> Ted Hardie >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 07 20:10:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkAIK-0004KS-C8; Wed, 07 Dec 2005 20:10:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkAIJ-0004KF-Bi for ecrit@megatron.ietf.org; Wed, 07 Dec 2005 20:09:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04885 for ; Wed, 7 Dec 2005 20:09:07 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkAe7-0002wI-5L for ecrit@ietf.org; Wed, 07 Dec 2005 20:32:31 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 7 Dec 2005 20:09:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Date: Wed, 7 Dec 2005 17:09:48 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657503BCF767@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Thread-Index: AcX6xlcTWOj5mlhsQpChc7pBanzbJAAys9zg From: "Roger Marshall" To: "Ted Hardie" , "James M. Polk" , "Marc Linsner" , , X-Spam-Score: 2.6 (++) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org So, (to me) it sounds like we're all more or less in agreement on the last paragraph to the Intro section. Here it is again, with some wording changes, taking into account some of the thoughts discussed: Introduction ... (at end) "Ideally, the mapping protocol would yield a URI from a preferred=20 set of URIs (e.g. sips:uri; sip:uri), which would allow an=20 emergency call to be completed using IP end-to-end (possibly via=20 the Internet). Despite this goal, some PSAPs may not immediately=20 have IP based connectivity, and therefore it is imperative that the=20 URI scheme not be fixed, in order to ensure support for a less=20 preferred set of URIs, such as a TEL URI which may be used to=20 Complete a call over the PSTN." Objections? Thanks. Roger Marshall >-----Original Message----- >From: Ted Hardie [mailto:hardie@qualcomm.com]=20 >Sent: Tuesday, December 06, 2005 4:37 PM >To: James M. Polk; Roger Marshall; Marc Linsner;=20 >br@brianrosen.net; ecrit@ietf.org >Subject: RE: [Ecrit] Issue 28: NENA Comments on=20 >draft-ietf-ecrit-requirements-00 -Alternate Routes > >At 6:21 PM -0600 12/6/05, James M. Polk wrote: >>Roger >> >>I'll propose what you wrote with the appropriate MUSTs,=20 >SHOULDs and MAYs like most requirements should have: >> >>"Ideally, the mapping protocol SHOULD yield a URI (e.g. sip:uri,=20 >>sips:uri, etc.) which would allow an emergency call to be=20 >routed using=20 >>IP end-to-end (possibly, via the Internet). Though this is=20 >the goal,=20 >>not every PSAP will have IP based connectivity right away, so the URI=20 >>scheme MAY be different. Given these conditions, alternate=20 >URI schemes,=20 >>such as tel:uri, MAY be used in order to complete calls over=20 >the PSTN." > >Written this way, I would interpret this to mean that any URI=20 >scheme which mapped to a protocol that used IP end-to-end was=20 >in the preferred set, and that URI schemes like tel which=20 >required gateways or further mapping >in this context were in a less preferred set. I am fine=20 >with this, since I think >the choice of specific URI schemes (sip, sips) falls out=20 >pretty easily in operational reality, but I wanted to flag it=20 >in case James meant it to say "SHOULD yield a SIP or SIPS URI=20 >which would allow an emergency call to be routed" and to put=20 >non-SIP URI schemes in the same bucket whether they were IP=20 >end-to-end or not. To put this in another way, would a=20 >registered scheme of SMS be in the preferred set if it were=20 >possible to use it over IP without gateways? > >Also, I believe we said earlier that the mapping protocol=20 >would yield one or more URIs, with at most one per scheme. So=20 >you could have a SIP URI returned, as well as an SMS URI, with=20 >the preference order set by the client according to its capabilities. > regards, > Ted > > > >> >> >>I don't know if we want to get into specifying that dialog=20 >generating SIP requests SHOULD have a SIP or SIPS URI. INVITE=20 >is such a request, whereas Rohan's XMPP scheme example would=20 >not be used to generate a dialog, so that wouldn't be a contradiction. >> >>Now for me scratching my head at the second sentence: >>I'm a bit vague as to how a tel:uri is going to solve the=20 >ESRP to ESGW communications route path. >> >>Generally, a tel:uri is what is entered at the endstation,=20 >and not what is the product of a mapping conversion at a SIP=20 >proxy *from* a SIP URI. >> >>In other words, tel:911 is what could be entered by an IP=20 >phone, and shows up as the Request-URI in the INVITE to a ESRP=20 >server. This ESRP needs to do a mapping function to determine=20 >which PSAP is going to get this call set-up message. Take this=20 >basic topology (apologies James for the ESGW reference, but=20 >this makes the most sense to some of us for this discussion): >> >>IP phone =3D=3D> ESRP =3D=3D> ESGW =3D=3D> SR =3D=3D> PSAP >> >>The IP Phone creates an INVITE such as this: >> >>INVITE tel:911 SIP/2.0 >>Via: SIP/2.0/UDP ipphone1.localdomain.com; >> branch=3Dz9hG4bK776asdhs >>To: 911 >>From: Roger >>Max-Forwards: 70 >>Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REGISTER, >> REFER, NOTIFY, UPDATE >>Call-ID: a84b4c76e66710@localdomain.com >>CSeq: 1 INVITE >>Contact: >>Content-Type: mulipart/mixed; boundary=3D--0a1 >>Content-length: ... >> >>--0a1 >>Content-Type: application/sdp >>(SDP) >>--0a1 >>Content-Type: pidf-lo+xml >>(PIDF-LO) >>--0a1-- >> >>Now, the ESRP receives this message, realizes this is an=20 >emergency call, knows to look for the location message body to=20 >ship off to a mapping server. This could be a local process,=20 >or use one of the various methods discussed on this list. I'm=20 >not playing favorites in that regard for now. >> >>The nut of this discussion is what the ESRP gets back from=20 >the mapping server. >> >>Is this, or can it be, a tel:uri? >> >>The way I read the requirement as written, even with my=20 >alteration above, is I think both are saying it's possible to=20 >use a tel:uri from the mapping server to replace the existing=20 >Request-URI (tel:911 here) with. What is this uri going to=20 >look like, and how exactly will this get the message towards=20 >the ESGW to ensure it meets the i2 requirement of getting to=20 >the Selective Router and towards the proper PSAP? >> >>Are we talking about keeping the Request-URI the same and=20 >adding a Route header of the ESGW? This isn't the mapping=20 >protocol function as I'm understanding it to be, although this=20 >could work, as long as the ESRP maintains dialog state and the=20 >Contact header remains the same in case there are issues=20 >involving redundancy with a callback situation. >> >>I don't see why a tel:uri has to stay as the Request-URI, or=20 >be swapped with another tel:uri. How is this tel:uri going to=20 >all of a sudden make the non-IP-enabled PSAP work? >> >>I should think that any ESGW receiving an INVITE from a ESRP=20 >with an agreeable emergency declaration should translate that=20 >INVITE into starting a call set-up to the Selective Router=20 >with the ANI of the user. How does a tel:uri scheme enable=20 >this, whereas a SIP URI would not? >> >> >> >>At 03:03 PM 12/6/2005 -0800, Roger Marshall wrote: >>>James: >>>It seems like we have agreement (I think) that tel:uri's=20 >shouldn't be=20 >>>excluded altogether. I also agree that there is a preference as to=20 >>>which uri scheme is to be used, (e.g. sip:uri over a=20 >tel:uri), so I've=20 >>>revised the text: >>> >>>PROPOSED (updated 12/06) TEXT: >>>"Ideally, the mapping protocol would yield a URI (e.g. sip:uri,=20 >>>sips:uri, etc.) which would allow an emergency call to be completed=20 >>>using IP end-to-end (possibly, via the Internet). Though=20 >this is the=20 >>>goal, not every PSAP will have IP based connectivity right away, so=20 >>>the URI scheme is not fixed. Given these conditions, alternate URI=20 >>>schemes, >>> >>>such as tel:uri, are allowed in order to complete calls over=20 >the PSTN." >>> >>>Agreeable? >>> >>>Roger Marshall >>> >>> >>>>-----Original Message----- >>>>From: James M. Polk [mailto:jmpolk@cisco.com] >>>>Sent: Tuesday, December 06, 2005 1:03 PM >>>>To: Marc Linsner; br@brianrosen.net; Roger Marshall; ecrit@ietf.org >>>>Subject: RE: [Ecrit] Issue 28: NENA Comments on=20 >>>>draft-ietf-ecrit-requirements-00 -Alternate Routes >>>> >>>>In-line >>>> >>>>At 03:30 PM 12/6/2005 -0500, Marc Linsner wrote: >>>>>In-line..... >>>>> >>>>>snip...... >>>>> >>>>> > >>>>> > If a tel:uri is returned, we need to do more processing, like=20 >>>>> > convert this uri to a SIP URI to route the message *because* we=20 >>>>> > do not know if the next hop proxy is PSAP, and it might be a=20 >>>>> > intermediate proxy doing the final resolution of URI to IP >>>>address, >>>>> > or AOR (or a state's emergency VSP) to contact address (of a=20 >>>>> > specific city's PSAP). >>>>> > >>>>> >>>>> From an ECRIT pov, I don't agree. Yes, the SIP proxy may perform=20 >>>>>different (including additional) steps in order to resolve a=20 >>>>>tel:uri, but ECRIT is complete at this point. A tel:uri=20 >is valid in=20 >>>>>the SIP domain so it should be valid in the ECRIT domain. >>>> >>>>but it's not routable in the SIP domain, and the SIP specs=20 >state that=20 >>>>conversion is necessary to make the message routable. This is an=20 >>>>extra step that is less desired. >>>> >>>> >>>>> > >All of them route a tel uri. Every VoIP system I know of >>>>does this >>>>> > >seamlessly. Do we really need to say this in a requirements >>>>> > document? >>>>> > > >>>>> > >Further, Roger's "not all PSAPs may have IP based >>>>connectivity" is >>>>> > >useful to motivate why a tel uri may be returned. >>>>> > >>>>> > Movitvate? Why do we need motivation here? >>>>> > >>>>> > Whether my text is used or not, this requirement has the >>>>ability to >>>>> > have a hierarchy of preferred options listed, and my text >>>>gives that >>>>> > order for motivation to work towards the most secure solution. =20 >>>>> > It does not dismiss tel:uris, it just says they are not=20 >preferred. >>>>> >>>>>The designer of the PSAP system will decide the=20 >architecture of the=20 >>>>>contact mechanism. Guidance may be offered in an >>>>architecture BCP, but >>>>>I'm not sure it's proper for a requirements draft. >>>> >>>>This is a ridiculous statement. Of course requirements=20 >documents give=20 >>>>preferential orders to mechanisms. The offered text here is not=20 >>>>absolute, and does not say that a tel:uri is forbidden. >>>> >>>> >>>>>I vote for Roger's text. >>>>> >>>>>-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 Dec 07 20:18:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkAQP-00062B-Tn; Wed, 07 Dec 2005 20:18:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkAQN-00060q-KI for ecrit@megatron.ietf.org; Wed, 07 Dec 2005 20:18:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05443 for ; Wed, 7 Dec 2005 20:17:27 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkAmB-00038P-GN for ecrit@ietf.org; Wed, 07 Dec 2005 20:40:52 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 7 Dec 2005 20:18:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Date: Wed, 7 Dec 2005 17:18:08 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657503BCF772@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Thread-Index: AcX7kt7KY+7Aj/xWSgybH/wKRDwe1QAAkg8g From: "Roger Marshall" To: "Ted Hardie" , X-Spam-Score: 2.6 (++) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Works for me. Thanks. Roger. >-----Original Message----- >From: Ted Hardie [mailto:hardie@qualcomm.com]=20 >Sent: Wednesday, December 07, 2005 5:01 PM >To: Roger Marshall; ecrit@ietf.org >Subject: RE: [Ecrit] Issue 28: NENA Comments on=20 >draft-ietf-ecrit-requirements-00 -Alternate Routes > >At 4:45 PM -0800 12/7/05, Roger Marshall wrote: >> >>NEW (PROPOSED) REQUIREMENT: >> >>Ma5x. When multiple URIs are returned, the mapping protocol SHOULD=20 >>differentiate multiple URIs by use of different URI schemes. > >Sorry, but I think this doesn't quite capture it. This sounds=20 >like a server wanting to return multiple URIs should=20 >differentiate them by scheme (e.g. assign one to sip and one=20 >to sips), where what we want to say is that servers may return=20 >multiple URIs when the PSAP supports multiple contact=20 >protocols, but should return only one per protocol, to avoid=20 >the client getting muddled.=20 >Proposed replacement text: > >Ma5x. The mapping protocol MAY return multiple URIs. It=20 >SHOULD return only one URI per scheme, so that clients are not=20 >required to select among different targets for the same=20 >contact protocol. > >Motivation: There may be two or more URIs returned when=20 >multiple contact protocols are available (e.g. SIP and SMS). >The client may select among multiple contact protocols based=20 >on its capabilities, preference settings, or availability. > >Does this replacement text work for you? > regards, > Ted > >>Motivation: There may be two URIs returned, both an SMS URI and a SIP=20 >>URI, which the client can select by choice, based on it's capability=20 >>and/or preference setting. >> >>Are the other (existing) requirements sufficient to address use cases=20 >>where same schemas might be returned if unavoidable? >> >>Please comment if objectionable. >> >> >>Thanks. >> >>Roger Marshall >> >> >> >>>-----Original Message----- >>>From: Ted Hardie [mailto:hardie@qualcomm.com] >>>Sent: Wednesday, December 07, 2005 10:07 AM >>>To: Roger Marshall; James M. Polk; Marc Linsner; br@brianrosen.net;=20 >>>ecrit@ietf.org >>>Subject: RE: [Ecrit] Issue 28: NENA Comments on=20 >>>draft-ietf-ecrit-requirements-00 -Alternate Routes >>> >>>At 5:24 PM -0800 12/6/05, Roger Marshall wrote: >>>>I'm glad you brought this up, since we currently DON'T yet have the=20 >>>>"with at most one per scheme" qualification. I think we >>>should, but we >>>>need to be careful, since there are a number of multiple uri >>>scenarios >>>>mentioned. Here are the four: >>> >>>I believe it was Henning who brought this up initially. His=20 >logic, if=20 >>>I remember correctly, was that we didn't want the client to have to=20 >>>order multiple responses for the same URI scheme; the service should=20 >>>return the best/correct answer for that scheme and any forwarding or=20 >>>redirection that occurred should take place in the protocol=20 >processing=20 >>>for the scheme. >>>In the SIP example, the processing would return something like=20 >>>"sips:psap1@dallas-erc.tx.us"; if that psap were not available, it=20 >>>would be the SIP mechanisms, not the mapping protocol, that=20 >handle the=20 >>>traffic moving to sips:psap2@dallas-erc.tx.us . >>> >>>I personally agree with this logic, and I hope others do as well. >>> >>> >>>>1. The mapping server returns two solutions for a given request and=20 >>>>location... >>>> >>>>Mapping Client: A Mapping Client interacts with the Mapping=20 >Server to=20 >>>>learn one or multiple URIs for a given location. >>>> >>>>2. Though I'm not sure this is Id2's original intent, since=20 >there are=20 >>>>various service types are mentioned, could this take the form of=20 >>>>sip:psap1@domain.net vs. hazmat.psap1@domain.net vs. >>>>amber.psap1@domain.net (or some other combi) that could be provided=20 >>>>from a mapping server? >>>> >>>>Id2. Universal Identifier Resolution: Where multiple >>>emergency service >>>>types exist, it MUST be possible to treat each emergency identifier=20 >>>>separately, based on the specific type of emergency help requested. >>>> >>>>3. The following requirement says nothing of scheme limits. >>>> >>>>Ma5. The mapping protocol MUST allow a response to carry >>>multiple URIs. >>> >>>I would add it here, as "It SHOULD return at most one URI for each=20 >>>scheme it supports, in order to avoid shifting the burden of=20 >discovery=20 >>>back to the client". >>> >>>I think SHOULD is the right level here, just to allow for >> >special cases where multiple URIs are unavoidable or where the >>>scheme has no provision for forwarding/redirection. That might,=20 >>>though, cause us to say whether a return set containing=20 >multiple URIs=20 >>>in a single scheme is ordered or >>>unordered. I also would have no real heartburn if we said MUST, >>>and let people draw the conclusion that anything that has no=20 >>>redirection/ redundancy/forwarding might be a bad choice for=20 >this use. >>> >>> regards, >>> Ted Hardie >>> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 07 21:34:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkBcA-0006RC-Hj; Wed, 07 Dec 2005 21:34:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkBc8-0006Qv-MA for ecrit@megatron.ietf.org; Wed, 07 Dec 2005 21:34:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12075 for ; Wed, 7 Dec 2005 21:33:40 -0500 (EST) 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 1EkBxv-0005He-Vv for ecrit@ietf.org; Wed, 07 Dec 2005 21:57:05 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 07 Dec 2005 18:34:22 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB82Y8BN018120; Wed, 7 Dec 2005 18:34:15 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Dec 2005 18:34:15 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.88.254]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Dec 2005 18:34:14 -0800 Message-Id: <4.3.2.7.2.20051207203324.02b4f7f8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Dec 2005 20:34:13 -0600 To: Ted Hardie , "Roger Marshall" , From: "James M. Polk" Subject: RE: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes In-Reply-To: References: <8C837214C95C864C9F34F3635C2A657503BCF72B@SEA-EXCHVS-2.telecomsys.com> <8C837214C95C864C9F34F3635C2A657503BCF72B@SEA-EXCHVS-2.telecomsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 08 Dec 2005 02:34:14.0605 (UTC) FILETIME=[E12BE7D0:01C5FB9F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This text is good At 05:00 PM 12/7/2005 -0800, Ted Hardie wrote: >At 4:45 PM -0800 12/7/05, Roger Marshall wrote: > >Ma5x. The mapping protocol MAY return multiple URIs. It SHOULD >return only one URI per scheme, so that clients are not required >to select among different targets for the same contact protocol. > >Motivation: There may be two or more URIs returned when >multiple contact protocols are available (e.g. SIP and SMS). >The client may select among multiple contact protocols based >on its capabilities, preference settings, or availability. > >Does this replacement text work for you? > regards, > Ted > > > > >Thanks. > > > >Roger Marshall > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 07 21:38:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkBfz-0007Y5-UP; Wed, 07 Dec 2005 21:38:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkBfy-0007Xu-BY for ecrit@megatron.ietf.org; Wed, 07 Dec 2005 21:38:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12303 for ; Wed, 7 Dec 2005 21:37:38 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkC1m-0005OM-FH for ecrit@ietf.org; Wed, 07 Dec 2005 22:01:03 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 07 Dec 2005 18:38:19 -0800 X-IronPort-AV: i="3.99,227,1131350400"; d="scan'208"; a="375482216:sNHT37520116" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB82bnAA014611; Wed, 7 Dec 2005 18:38:17 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Dec 2005 18:38:12 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.88.254]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Dec 2005 18:38:12 -0800 Message-Id: <4.3.2.7.2.20051207203525.02dd9d48@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Dec 2005 20:38:11 -0600 To: "Roger Marshall" , "Ted Hardie" , "Marc Linsner" , , From: "James M. Polk" Subject: RE: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes In-Reply-To: <8C837214C95C864C9F34F3635C2A657503BCF767@SEA-EXCHVS-2.tele comsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 08 Dec 2005 02:38:12.0277 (UTC) FILETIME=[6ED5C650:01C5FBA0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Where does it say that a tel:uri is acceptable between an endpoint and the ESRP, and not a mapping protocol response *to* a ESRP? I.e. I don't want the tel:uri to be an answer in the mapping protocol. Once this is clear, I'm cool on this. At 05:09 PM 12/7/2005 -0800, Roger Marshall wrote: >So, (to me) it sounds like we're all more or less in agreement on the >last paragraph to the Intro section. Here it is again, with some >wording changes, taking into account some of the thoughts discussed: > >Introduction >... (at end) >"Ideally, the mapping protocol would yield a URI from a preferred >set of URIs (e.g. sips:uri; sip:uri), which would allow an >emergency call to be completed using IP end-to-end (possibly via >the Internet). Despite this goal, some PSAPs may not immediately >have IP based connectivity, and therefore it is imperative that the >URI scheme not be fixed, in order to ensure support for a less >preferred set of URIs, such as a TEL URI which may be used to >Complete a call over the PSTN." > >Objections? > > >Thanks. > >Roger Marshall > > > >-----Original Message----- > >From: Ted Hardie [mailto:hardie@qualcomm.com] > >Sent: Tuesday, December 06, 2005 4:37 PM > >To: James M. Polk; Roger Marshall; Marc Linsner; > >br@brianrosen.net; ecrit@ietf.org > >Subject: RE: [Ecrit] Issue 28: NENA Comments on > >draft-ietf-ecrit-requirements-00 -Alternate Routes > > > >At 6:21 PM -0600 12/6/05, James M. Polk wrote: > >>Roger > >> > >>I'll propose what you wrote with the appropriate MUSTs, > >SHOULDs and MAYs like most requirements should have: > >> > >>"Ideally, the mapping protocol SHOULD yield a URI (e.g. sip:uri, > >>sips:uri, etc.) which would allow an emergency call to be > >routed using > >>IP end-to-end (possibly, via the Internet). Though this is > >the goal, > >>not every PSAP will have IP based connectivity right away, so the URI > >>scheme MAY be different. Given these conditions, alternate > >URI schemes, > >>such as tel:uri, MAY be used in order to complete calls over > >the PSTN." > > > >Written this way, I would interpret this to mean that any URI > >scheme which mapped to a protocol that used IP end-to-end was > >in the preferred set, and that URI schemes like tel which > >required gateways or further mapping > >in this context were in a less preferred set. I am fine > >with this, since I think > >the choice of specific URI schemes (sip, sips) falls out > >pretty easily in operational reality, but I wanted to flag it > >in case James meant it to say "SHOULD yield a SIP or SIPS URI > >which would allow an emergency call to be routed" and to put > >non-SIP URI schemes in the same bucket whether they were IP > >end-to-end or not. To put this in another way, would a > >registered scheme of SMS be in the preferred set if it were > >possible to use it over IP without gateways? > > > >Also, I believe we said earlier that the mapping protocol > >would yield one or more URIs, with at most one per scheme. So > >you could have a SIP URI returned, as well as an SMS URI, with > >the preference order set by the client according to its capabilities. > > regards, > > Ted > > > > > > > >> > >> > >>I don't know if we want to get into specifying that dialog > >generating SIP requests SHOULD have a SIP or SIPS URI. INVITE > >is such a request, whereas Rohan's XMPP scheme example would > >not be used to generate a dialog, so that wouldn't be a contradiction. > >> > >>Now for me scratching my head at the second sentence: > >>I'm a bit vague as to how a tel:uri is going to solve the > >ESRP to ESGW communications route path. > >> > >>Generally, a tel:uri is what is entered at the endstation, > >and not what is the product of a mapping conversion at a SIP > >proxy *from* a SIP URI. > >> > >>In other words, tel:911 is what could be entered by an IP > >phone, and shows up as the Request-URI in the INVITE to a ESRP > >server. This ESRP needs to do a mapping function to determine > >which PSAP is going to get this call set-up message. Take this > >basic topology (apologies James for the ESGW reference, but > >this makes the most sense to some of us for this discussion): > >> > >>IP phone ==> ESRP ==> ESGW ==> SR ==> PSAP > >> > >>The IP Phone creates an INVITE such as this: > >> > >>INVITE tel:911 SIP/2.0 > >>Via: SIP/2.0/UDP ipphone1.localdomain.com; > >> branch=z9hG4bK776asdhs > >>To: 911 > >>From: Roger > >>Max-Forwards: 70 > >>Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REGISTER, > >> REFER, NOTIFY, UPDATE > >>Call-ID: a84b4c76e66710@localdomain.com > >>CSeq: 1 INVITE > >>Contact: > >>Content-Type: mulipart/mixed; boundary=--0a1 > >>Content-length: ... > >> > >>--0a1 > >>Content-Type: application/sdp > >>(SDP) > >>--0a1 > >>Content-Type: pidf-lo+xml > >>(PIDF-LO) > >>--0a1-- > >> > >>Now, the ESRP receives this message, realizes this is an > >emergency call, knows to look for the location message body to > >ship off to a mapping server. This could be a local process, > >or use one of the various methods discussed on this list. I'm > >not playing favorites in that regard for now. > >> > >>The nut of this discussion is what the ESRP gets back from > >the mapping server. > >> > >>Is this, or can it be, a tel:uri? > >> > >>The way I read the requirement as written, even with my > >alteration above, is I think both are saying it's possible to > >use a tel:uri from the mapping server to replace the existing > >Request-URI (tel:911 here) with. What is this uri going to > >look like, and how exactly will this get the message towards > >the ESGW to ensure it meets the i2 requirement of getting to > >the Selective Router and towards the proper PSAP? > >> > >>Are we talking about keeping the Request-URI the same and > >adding a Route header of the ESGW? This isn't the mapping > >protocol function as I'm understanding it to be, although this > >could work, as long as the ESRP maintains dialog state and the > >Contact header remains the same in case there are issues > >involving redundancy with a callback situation. > >> > >>I don't see why a tel:uri has to stay as the Request-URI, or > >be swapped with another tel:uri. How is this tel:uri going to > >all of a sudden make the non-IP-enabled PSAP work? > >> > >>I should think that any ESGW receiving an INVITE from a ESRP > >with an agreeable emergency declaration should translate that > >INVITE into starting a call set-up to the Selective Router > >with the ANI of the user. How does a tel:uri scheme enable > >this, whereas a SIP URI would not? > >> > >> > >> > >>At 03:03 PM 12/6/2005 -0800, Roger Marshall wrote: > >>>James: > >>>It seems like we have agreement (I think) that tel:uri's > >shouldn't be > >>>excluded altogether. I also agree that there is a preference as to > >>>which uri scheme is to be used, (e.g. sip:uri over a > >tel:uri), so I've > >>>revised the text: > >>> > >>>PROPOSED (updated 12/06) TEXT: > >>>"Ideally, the mapping protocol would yield a URI (e.g. sip:uri, > >>>sips:uri, etc.) which would allow an emergency call to be completed > >>>using IP end-to-end (possibly, via the Internet). Though > >this is the > >>>goal, not every PSAP will have IP based connectivity right away, so > >>>the URI scheme is not fixed. Given these conditions, alternate URI > >>>schemes, > >>> > >>>such as tel:uri, are allowed in order to complete calls over > >the PSTN." > >>> > >>>Agreeable? > >>> > >>>Roger Marshall > >>> > >>> > >>>>-----Original Message----- > >>>>From: James M. Polk [mailto:jmpolk@cisco.com] > >>>>Sent: Tuesday, December 06, 2005 1:03 PM > >>>>To: Marc Linsner; br@brianrosen.net; Roger Marshall; ecrit@ietf.org > >>>>Subject: RE: [Ecrit] Issue 28: NENA Comments on > >>>>draft-ietf-ecrit-requirements-00 -Alternate Routes > >>>> > >>>>In-line > >>>> > >>>>At 03:30 PM 12/6/2005 -0500, Marc Linsner wrote: > >>>>>In-line..... > >>>>> > >>>>>snip...... > >>>>> > >>>>> > > >>>>> > If a tel:uri is returned, we need to do more processing, like > >>>>> > convert this uri to a SIP URI to route the message *because* we > >>>>> > do not know if the next hop proxy is PSAP, and it might be a > >>>>> > intermediate proxy doing the final resolution of URI to IP > >>>>address, > >>>>> > or AOR (or a state's emergency VSP) to contact address (of a > >>>>> > specific city's PSAP). > >>>>> > > >>>>> > >>>>> From an ECRIT pov, I don't agree. Yes, the SIP proxy may perform > >>>>>different (including additional) steps in order to resolve a > >>>>>tel:uri, but ECRIT is complete at this point. A tel:uri > >is valid in > >>>>>the SIP domain so it should be valid in the ECRIT domain. > >>>> > >>>>but it's not routable in the SIP domain, and the SIP specs > >state that > >>>>conversion is necessary to make the message routable. This is an > >>>>extra step that is less desired. > >>>> > >>>> > >>>>> > >All of them route a tel uri. Every VoIP system I know of > >>>>does this > >>>>> > >seamlessly. Do we really need to say this in a requirements > >>>>> > document? > >>>>> > > > >>>>> > >Further, Roger's "not all PSAPs may have IP based > >>>>connectivity" is > >>>>> > >useful to motivate why a tel uri may be returned. > >>>>> > > >>>>> > Movitvate? Why do we need motivation here? > >>>>> > > >>>>> > Whether my text is used or not, this requirement has the > >>>>ability to > >>>>> > have a hierarchy of preferred options listed, and my text > >>>>gives that > >>>>> > order for motivation to work towards the most secure solution. > >>>>> > It does not dismiss tel:uris, it just says they are not > >preferred. > >>>>> > >>>>>The designer of the PSAP system will decide the > >architecture of the > >>>>>contact mechanism. Guidance may be offered in an > >>>>architecture BCP, but > >>>>>I'm not sure it's proper for a requirements draft. > >>>> > >>>>This is a ridiculous statement. Of course requirements > >documents give > >>>>preferential orders to mechanisms. The offered text here is not > >>>>absolute, and does not say that a tel:uri is forbidden. > >>>> > >>>> > >>>>>I vote for Roger's text. > >>>>> > >>>>>-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 Thu Dec 08 08:27:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkLnc-0002FM-QJ; Thu, 08 Dec 2005 08:27:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkLnb-0002Cw-GG for ecrit@megatron.ietf.org; Thu, 08 Dec 2005 08:27:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13779 for ; Thu, 8 Dec 2005 08:26:11 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkLna-0008U2-KT for ecrit@ietf.org; Thu, 08 Dec 2005 08:27:03 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 08 Dec 2005 05:26:54 -0800 X-IronPort-AV: i="3.99,230,1131350400"; d="scan'208"; a="375653526:sNHT36840996" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB8DQm9k026611; Thu, 8 Dec 2005 05:26:49 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 05:26:48 -0800 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 05:26:47 -0800 From: "Marc Linsner" To: "'James M. Polk'" , "'Roger Marshall'" , "'Ted Hardie'" , , Subject: RE: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Date: Thu, 8 Dec 2005 08:26:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX7oG9EbgOUip5XS7ObZxd7zqGEugAWPKrw In-Reply-To: <4.3.2.7.2.20051207203525.02dd9d48@email.cisco.com> Message-ID: X-OriginalArrivalTime: 08 Dec 2005 13:26:47.0872 (UTC) FILETIME=[0A565400:01C5FBFB] X-Spam-Score: 1.1 (+) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James, I'm confused. If a PSAP loads the mapping db (ecrit) with a tel:uri why is this not acceptable? If the UA launched the mapping query and is returned a tel:uri, the UA will submit this to it's proxy for further routing (unless the UA has an on-board route/dial plan). Admittedly, a tel:uri will/may cause additional work by the proxy vs. a sip:uri, but tel:uri is something the proxy is suppose to be able to handle. Are you worried about the proxy not equipped to handle tel:uri? -Marc- > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Wednesday, December 07, 2005 9:38 PM > To: Roger Marshall; Ted Hardie; Marc Linsner; > br@brianrosen.net; ecrit@ietf.org > Subject: RE: [Ecrit] Issue 28: NENA Comments on > draft-ietf-ecrit-requirements-00 -Alternate Routes > > Where does it say that a tel:uri is acceptable between an > endpoint and the ESRP, and not a mapping protocol response > *to* a ESRP? I.e. I don't want the tel:uri to be an answer > in the mapping protocol. > > Once this is clear, I'm cool on this. > > At 05:09 PM 12/7/2005 -0800, Roger Marshall wrote: > >So, (to me) it sounds like we're all more or less in > agreement on the > >last paragraph to the Intro section. Here it is again, with some > >wording changes, taking into account some of the thoughts discussed: > > > >Introduction > >... (at end) > >"Ideally, the mapping protocol would yield a URI from a > preferred set > >of URIs (e.g. sips:uri; sip:uri), which would allow an > emergency call > >to be completed using IP end-to-end (possibly via the Internet). > >Despite this goal, some PSAPs may not immediately have IP based > >connectivity, and therefore it is imperative that the URI > scheme not be > >fixed, in order to ensure support for a less preferred set of URIs, > >such as a TEL URI which may be used to Complete a call over > the PSTN." > > > >Objections? > > > > > >Thanks. > > > >Roger Marshall > > > > > > >-----Original Message----- > > >From: Ted Hardie [mailto:hardie@qualcomm.com] > > >Sent: Tuesday, December 06, 2005 4:37 PM > > >To: James M. Polk; Roger Marshall; Marc Linsner; > br@brianrosen.net; > > >ecrit@ietf.org > > >Subject: RE: [Ecrit] Issue 28: NENA Comments on > > >draft-ietf-ecrit-requirements-00 -Alternate Routes > > > > > >At 6:21 PM -0600 12/6/05, James M. Polk wrote: > > >>Roger > > >> > > >>I'll propose what you wrote with the appropriate MUSTs, > > >SHOULDs and MAYs like most requirements should have: > > >> > > >>"Ideally, the mapping protocol SHOULD yield a URI (e.g. sip:uri, > > >>sips:uri, etc.) which would allow an emergency call to be > > >routed using > > >>IP end-to-end (possibly, via the Internet). Though this is > > >the goal, > > >>not every PSAP will have IP based connectivity right away, so the > > >>URI scheme MAY be different. Given these conditions, alternate > > >URI schemes, > > >>such as tel:uri, MAY be used in order to complete calls over > > >the PSTN." > > > > > >Written this way, I would interpret this to mean that any > URI scheme > > >which mapped to a protocol that used IP end-to-end was in the > > >preferred set, and that URI schemes like tel which > required gateways > > >or further mapping > > >in this context were in a less preferred set. I am fine > > >with this, since I think > > >the choice of specific URI schemes (sip, sips) falls out pretty > > >easily in operational reality, but I wanted to flag it in > case James > > >meant it to say "SHOULD yield a SIP or SIPS URI which > would allow an > > >emergency call to be routed" and to put non-SIP URI schemes in the > > >same bucket whether they were IP end-to-end or not. To > put this in > > >another way, would a registered scheme of SMS be in the > preferred set > > >if it were possible to use it over IP without gateways? > > > > > >Also, I believe we said earlier that the mapping protocol > would yield > > >one or more URIs, with at most one per scheme. So you > could have a > > >SIP URI returned, as well as an SMS URI, with the preference order > > >set by the client according to its capabilities. > > > regards, > > > Ted > > > > > > > > > > > >> > > >> > > >>I don't know if we want to get into specifying that dialog > > >generating SIP requests SHOULD have a SIP or SIPS URI. INVITE is > > >such a request, whereas Rohan's XMPP scheme example would > not be used > > >to generate a dialog, so that wouldn't be a contradiction. > > >> > > >>Now for me scratching my head at the second sentence: > > >>I'm a bit vague as to how a tel:uri is going to solve the > > >ESRP to ESGW communications route path. > > >> > > >>Generally, a tel:uri is what is entered at the endstation, > > >and not what is the product of a mapping conversion at a SIP proxy > > >*from* a SIP URI. > > >> > > >>In other words, tel:911 is what could be entered by an IP > > >phone, and shows up as the Request-URI in the INVITE to a ESRP > > >server. This ESRP needs to do a mapping function to > determine which > > >PSAP is going to get this call set-up message. Take this basic > > >topology (apologies James for the ESGW reference, but this > makes the > > >most sense to some of us for this discussion): > > >> > > >>IP phone ==> ESRP ==> ESGW ==> SR ==> PSAP > > >> > > >>The IP Phone creates an INVITE such as this: > > >> > > >>INVITE tel:911 SIP/2.0 > > >>Via: SIP/2.0/UDP ipphone1.localdomain.com; > > >> branch=z9hG4bK776asdhs > > >>To: 911 > > >>From: Roger > > >>Max-Forwards: 70 > > >>Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REGISTER, > > >> REFER, NOTIFY, UPDATE > > >>Call-ID: a84b4c76e66710@localdomain.com > > >>CSeq: 1 INVITE > > >>Contact: > > >>Content-Type: mulipart/mixed; boundary=--0a1 > > >>Content-length: ... > > >> > > >>--0a1 > > >>Content-Type: application/sdp > > >>(SDP) > > >>--0a1 > > >>Content-Type: pidf-lo+xml > > >>(PIDF-LO) > > >>--0a1-- > > >> > > >>Now, the ESRP receives this message, realizes this is an > > >emergency call, knows to look for the location message > body to ship > > >off to a mapping server. This could be a local process, > or use one > > >of the various methods discussed on this list. I'm not playing > > >favorites in that regard for now. > > >> > > >>The nut of this discussion is what the ESRP gets back from > > >the mapping server. > > >> > > >>Is this, or can it be, a tel:uri? > > >> > > >>The way I read the requirement as written, even with my > > >alteration above, is I think both are saying it's possible > to use a > > >tel:uri from the mapping server to replace the existing > Request-URI > > >(tel:911 here) with. What is this uri going to look like, and how > > >exactly will this get the message towards the ESGW to > ensure it meets > > >the i2 requirement of getting to the Selective Router and > towards the > > >proper PSAP? > > >> > > >>Are we talking about keeping the Request-URI the same and > > >adding a Route header of the ESGW? This isn't the mapping protocol > > >function as I'm understanding it to be, although this > could work, as > > >long as the ESRP maintains dialog state and the Contact header > > >remains the same in case there are issues involving > redundancy with a > > >callback situation. > > >> > > >>I don't see why a tel:uri has to stay as the Request-URI, or > > >be swapped with another tel:uri. How is this tel:uri > going to all of > > >a sudden make the non-IP-enabled PSAP work? > > >> > > >>I should think that any ESGW receiving an INVITE from a ESRP > > >with an agreeable emergency declaration should translate > that INVITE > > >into starting a call set-up to the Selective Router with > the ANI of > > >the user. How does a tel:uri scheme enable this, whereas a SIP URI > > >would not? > > >> > > >> > > >> > > >>At 03:03 PM 12/6/2005 -0800, Roger Marshall wrote: > > >>>James: > > >>>It seems like we have agreement (I think) that tel:uri's > > >shouldn't be > > >>>excluded altogether. I also agree that there is a > preference as to > > >>>which uri scheme is to be used, (e.g. sip:uri over a > > >tel:uri), so I've > > >>>revised the text: > > >>> > > >>>PROPOSED (updated 12/06) TEXT: > > >>>"Ideally, the mapping protocol would yield a URI (e.g. sip:uri, > > >>>sips:uri, etc.) which would allow an emergency call to > be completed > > >>>using IP end-to-end (possibly, via the Internet). Though > > >this is the > > >>>goal, not every PSAP will have IP based connectivity > right away, so > > >>>the URI scheme is not fixed. Given these conditions, > alternate URI > > >>>schemes, > > >>> > > >>>such as tel:uri, are allowed in order to complete calls over > > >the PSTN." > > >>> > > >>>Agreeable? > > >>> > > >>>Roger Marshall > > >>> > > >>> > > >>>>-----Original Message----- > > >>>>From: James M. Polk [mailto:jmpolk@cisco.com] > > >>>>Sent: Tuesday, December 06, 2005 1:03 PM > > >>>>To: Marc Linsner; br@brianrosen.net; Roger Marshall; > > >>>>ecrit@ietf.org > > >>>>Subject: RE: [Ecrit] Issue 28: NENA Comments on > > >>>>draft-ietf-ecrit-requirements-00 -Alternate Routes > > >>>> > > >>>>In-line > > >>>> > > >>>>At 03:30 PM 12/6/2005 -0500, Marc Linsner wrote: > > >>>>>In-line..... > > >>>>> > > >>>>>snip...... > > >>>>> > > >>>>> > > > >>>>> > If a tel:uri is returned, we need to do more > processing, like > > >>>>> > convert this uri to a SIP URI to route the message > *because* > > >>>>> > we do not know if the next hop proxy is PSAP, and > it might be > > >>>>> > a intermediate proxy doing the final resolution of URI to IP > > >>>>address, > > >>>>> > or AOR (or a state's emergency VSP) to contact > address (of a > > >>>>> > specific city's PSAP). > > >>>>> > > > >>>>> > > >>>>> From an ECRIT pov, I don't agree. Yes, the SIP proxy may > > >>>>>perform different (including additional) steps in order to > > >>>>>resolve a tel:uri, but ECRIT is complete at this point. A > > >>>>>tel:uri > > >is valid in > > >>>>>the SIP domain so it should be valid in the ECRIT domain. > > >>>> > > >>>>but it's not routable in the SIP domain, and the SIP specs > > >state that > > >>>>conversion is necessary to make the message routable. > This is an > > >>>>extra step that is less desired. > > >>>> > > >>>> > > >>>>> > >All of them route a tel uri. Every VoIP system I know of > > >>>>does this > > >>>>> > >seamlessly. Do we really need to say this in a > requirements > > >>>>> > document? > > >>>>> > > > > >>>>> > >Further, Roger's "not all PSAPs may have IP based > > >>>>connectivity" is > > >>>>> > >useful to motivate why a tel uri may be returned. > > >>>>> > > > >>>>> > Movitvate? Why do we need motivation here? > > >>>>> > > > >>>>> > Whether my text is used or not, this requirement has the > > >>>>ability to > > >>>>> > have a hierarchy of preferred options listed, and my text > > >>>>gives that > > >>>>> > order for motivation to work towards the most > secure solution. > > >>>>> > It does not dismiss tel:uris, it just says they are not > > >preferred. > > >>>>> > > >>>>>The designer of the PSAP system will decide the > > >architecture of the > > >>>>>contact mechanism. Guidance may be offered in an > > >>>>architecture BCP, but > > >>>>>I'm not sure it's proper for a requirements draft. > > >>>> > > >>>>This is a ridiculous statement. Of course requirements > > >documents give > > >>>>preferential orders to mechanisms. The offered text here is not > > >>>>absolute, and does not say that a tel:uri is forbidden. > > >>>> > > >>>> > > >>>>>I vote for Roger's text. > > >>>>> > > >>>>>-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 Thu Dec 08 13:43:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkQk4-00081c-RS; Thu, 08 Dec 2005 13:43:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkQk1-0007xD-Ur for ecrit@megatron.ietf.org; Thu, 08 Dec 2005 13:43:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22651 for ; Thu, 8 Dec 2005 13:42:49 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkQk0-0003kq-ST for ecrit@ietf.org; Thu, 08 Dec 2005 13:43:43 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 08 Dec 2005 10:43:29 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB8Ih8A2024499; Thu, 8 Dec 2005 10:43:27 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 10:43:25 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.98.118]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 10:43:24 -0800 Message-Id: <4.3.2.7.2.20051208120345.02aaa8e8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Dec 2005 12:43:23 -0600 To: "Marc Linsner" , "'Roger Marshall'" , "'Ted Hardie'" , , From: "James M. Polk" Subject: RE: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes In-Reply-To: References: <4.3.2.7.2.20051207203525.02dd9d48@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 08 Dec 2005 18:43:25.0073 (UTC) FILETIME=[458D2810:01C5FC27] X-Spam-Score: 0.0 (/) X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 08:26 AM 12/8/2005 -0500, Marc Linsner wrote: >James, > >I'm confused. If a PSAP loads the mapping db (ecrit) with a tel:uri why is >this not acceptable? If the UA launched the mapping query and is returned a >tel:uri, the UA will submit this to it's proxy for further routing (unless >the UA has an on-board route/dial plan). Admittedly, a tel:uri will/may >cause additional work by the proxy vs. a sip:uri, but tel:uri is something >the proxy is suppose to be able to handle. Are you worried about the proxy >not equipped to handle tel:uri? A tel:uri of "tel:911" isn't going anywhere, is it? This is what a phone might give an ESRP to figure out where to send a request. But the tel:uri needs further work to find its destination from some sort of look-up server/service, because it is not routable without there being a static route, which won't work because that ESRP may not be in the jurisdiction of the UAC making the emergency call. So yeah, I'm worried about the additional work, because this is another mapping function ( "tel:911" = "" ) that should have been done in the first place, and is another function which could fail. So, how do you distinguish these two tel:uris 1) tel:911 = , from 2) tel:911 = What indication in the INVITE is there to determine which psap this tel:911 call goes to? If you say the PIDF-LO (if by-value) in the message, then I ask what purpose did the first mapping protocol serve? We're not going to come up with a solution here such as this: UAC -> ESRP INVITE tel:911 SIP/2.0 (message body = Dallas, Texas) ESRP (mapping query) -> Mapping server (of whatever kind) "look up Dallas, Texas, give me the URI to the PSAP" Mapping server (of whatever kind) -> ESRP (mapping answer) tel:uri = +12145551212 ESRP then is forced to do TRIP or ENUM or "what" to convert "tel:+12145551212" into something that has a domain side of the uri scheme to route the message to the PSAP, or provide the actual IP address of the PSAP to put in the Request-URI field. Or is it being thought about that every ESRP will have a static entry for every tel:uri string that's associated with a PSAP in a country or the entire world? In other words, will either of these be close to what could occur at the ESRP *after* receiving the first mapping protocol answer: a) ESRP -> Dallas PSAP1 INVITE tel:+12145551212 SIP/2.0 Route: (message body = Dallas, Texas) where this ESRP understands that "+12145551212" = "psap1@dallas.tx.us" in its static configuration file(s) or b) ESRP -> ENUM Server "please convert +12145551212 to a SIP URI" in which there is a necessary 2nd mapping function performed to get to a routable URI scheme. From this discussion, I think a new requirement is necessary in this doc: Req X, It MUST NOT be assumed that an ESRP will be the adjacent SIP element to the emergency services PSAP SIP element during an emergency call routing process. Motivation: An ESRP cannot maintain the IP address of all emergency services ingress points for each potential request message transmission, therefore intermediate SIP server may assist in message routing to the destination ingress to the emergency services network. >-Marc- > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Wednesday, December 07, 2005 9:38 PM > > To: Roger Marshall; Ted Hardie; Marc Linsner; > > br@brianrosen.net; ecrit@ietf.org > > Subject: RE: [Ecrit] Issue 28: NENA Comments on > > draft-ietf-ecrit-requirements-00 -Alternate Routes > > > > Where does it say that a tel:uri is acceptable between an > > endpoint and the ESRP, and not a mapping protocol response > > *to* a ESRP? I.e. I don't want the tel:uri to be an answer > > in the mapping protocol. > > > > Once this is clear, I'm cool on this. > > > > At 05:09 PM 12/7/2005 -0800, Roger Marshall wrote: > > >So, (to me) it sounds like we're all more or less in > > agreement on the > > >last paragraph to the Intro section. Here it is again, with some > > >wording changes, taking into account some of the thoughts discussed: > > > > > >Introduction > > >... (at end) > > >"Ideally, the mapping protocol would yield a URI from a > > preferred set > > >of URIs (e.g. sips:uri; sip:uri), which would allow an > > emergency call > > >to be completed using IP end-to-end (possibly via the Internet). > > >Despite this goal, some PSAPs may not immediately have IP based > > >connectivity, and therefore it is imperative that the URI > > scheme not be > > >fixed, in order to ensure support for a less preferred set of URIs, > > >such as a TEL URI which may be used to Complete a call over > > the PSTN." > > > > > >Objections? > > > > > > > > >Thanks. > > > > > >Roger Marshall > > > > > > > > > >-----Original Message----- > > > >From: Ted Hardie [mailto:hardie@qualcomm.com] > > > >Sent: Tuesday, December 06, 2005 4:37 PM > > > >To: James M. Polk; Roger Marshall; Marc Linsner; > > br@brianrosen.net; > > > >ecrit@ietf.org > > > >Subject: RE: [Ecrit] Issue 28: NENA Comments on > > > >draft-ietf-ecrit-requirements-00 -Alternate Routes > > > > > > > >At 6:21 PM -0600 12/6/05, James M. Polk wrote: > > > >>Roger > > > >> > > > >>I'll propose what you wrote with the appropriate MUSTs, > > > >SHOULDs and MAYs like most requirements should have: > > > >> > > > >>"Ideally, the mapping protocol SHOULD yield a URI (e.g. sip:uri, > > > >>sips:uri, etc.) which would allow an emergency call to be > > > >routed using > > > >>IP end-to-end (possibly, via the Internet). Though this is > > > >the goal, > > > >>not every PSAP will have IP based connectivity right away, so the > > > >>URI scheme MAY be different. Given these conditions, alternate > > > >URI schemes, > > > >>such as tel:uri, MAY be used in order to complete calls over > > > >the PSTN." > > > > > > > >Written this way, I would interpret this to mean that any > > URI scheme > > > >which mapped to a protocol that used IP end-to-end was in the > > > >preferred set, and that URI schemes like tel which > > required gateways > > > >or further mapping > > > >in this context were in a less preferred set. I am fine > > > >with this, since I think > > > >the choice of specific URI schemes (sip, sips) falls out pretty > > > >easily in operational reality, but I wanted to flag it in > > case James > > > >meant it to say "SHOULD yield a SIP or SIPS URI which > > would allow an > > > >emergency call to be routed" and to put non-SIP URI schemes in the > > > >same bucket whether they were IP end-to-end or not. To > > put this in > > > >another way, would a registered scheme of SMS be in the > > preferred set > > > >if it were possible to use it over IP without gateways? > > > > > > > >Also, I believe we said earlier that the mapping protocol > > would yield > > > >one or more URIs, with at most one per scheme. So you > > could have a > > > >SIP URI returned, as well as an SMS URI, with the preference order > > > >set by the client according to its capabilities. > > > > regards, > > > > Ted > > > > > > > > > > > > > > > >> > > > >> > > > >>I don't know if we want to get into specifying that dialog > > > >generating SIP requests SHOULD have a SIP or SIPS URI. INVITE is > > > >such a request, whereas Rohan's XMPP scheme example would > > not be used > > > >to generate a dialog, so that wouldn't be a contradiction. > > > >> > > > >>Now for me scratching my head at the second sentence: > > > >>I'm a bit vague as to how a tel:uri is going to solve the > > > >ESRP to ESGW communications route path. > > > >> > > > >>Generally, a tel:uri is what is entered at the endstation, > > > >and not what is the product of a mapping conversion at a SIP proxy > > > >*from* a SIP URI. > > > >> > > > >>In other words, tel:911 is what could be entered by an IP > > > >phone, and shows up as the Request-URI in the INVITE to a ESRP > > > >server. This ESRP needs to do a mapping function to > > determine which > > > >PSAP is going to get this call set-up message. Take this basic > > > >topology (apologies James for the ESGW reference, but this > > makes the > > > >most sense to some of us for this discussion): > > > >> > > > >>IP phone ==> ESRP ==> ESGW ==> SR ==> PSAP > > > >> > > > >>The IP Phone creates an INVITE such as this: > > > >> > > > >>INVITE tel:911 SIP/2.0 > > > >>Via: SIP/2.0/UDP ipphone1.localdomain.com; > > > >> branch=z9hG4bK776asdhs > > > >>To: 911 > > > >>From: Roger > > > >>Max-Forwards: 70 > > > >>Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REGISTER, > > > >> REFER, NOTIFY, UPDATE > > > >>Call-ID: a84b4c76e66710@localdomain.com > > > >>CSeq: 1 INVITE > > > >>Contact: > > > >>Content-Type: mulipart/mixed; boundary=--0a1 > > > >>Content-length: ... > > > >> > > > >>--0a1 > > > >>Content-Type: application/sdp > > > >>(SDP) > > > >>--0a1 > > > >>Content-Type: pidf-lo+xml > > > >>(PIDF-LO) > > > >>--0a1-- > > > >> > > > >>Now, the ESRP receives this message, realizes this is an > > > >emergency call, knows to look for the location message > > body to ship > > > >off to a mapping server. This could be a local process, > > or use one > > > >of the various methods discussed on this list. I'm not playing > > > >favorites in that regard for now. > > > >> > > > >>The nut of this discussion is what the ESRP gets back from > > > >the mapping server. > > > >> > > > >>Is this, or can it be, a tel:uri? > > > >> > > > >>The way I read the requirement as written, even with my > > > >alteration above, is I think both are saying it's possible > > to use a > > > >tel:uri from the mapping server to replace the existing > > Request-URI > > > >(tel:911 here) with. What is this uri going to look like, and how > > > >exactly will this get the message towards the ESGW to > > ensure it meets > > > >the i2 requirement of getting to the Selective Router and > > towards the > > > >proper PSAP? > > > >> > > > >>Are we talking about keeping the Request-URI the same and > > > >adding a Route header of the ESGW? This isn't the mapping protocol > > > >function as I'm understanding it to be, although this > > could work, as > > > >long as the ESRP maintains dialog state and the Contact header > > > >remains the same in case there are issues involving > > redundancy with a > > > >callback situation. > > > >> > > > >>I don't see why a tel:uri has to stay as the Request-URI, or > > > >be swapped with another tel:uri. How is this tel:uri > > going to all of > > > >a sudden make the non-IP-enabled PSAP work? > > > >> > > > >>I should think that any ESGW receiving an INVITE from a ESRP > > > >with an agreeable emergency declaration should translate > > that INVITE > > > >into starting a call set-up to the Selective Router with > > the ANI of > > > >the user. How does a tel:uri scheme enable this, whereas a SIP URI > > > >would not? > > > >> > > > >> > > > >> > > > >>At 03:03 PM 12/6/2005 -0800, Roger Marshall wrote: > > > >>>James: > > > >>>It seems like we have agreement (I think) that tel:uri's > > > >shouldn't be > > > >>>excluded altogether. I also agree that there is a > > preference as to > > > >>>which uri scheme is to be used, (e.g. sip:uri over a > > > >tel:uri), so I've > > > >>>revised the text: > > > >>> > > > >>>PROPOSED (updated 12/06) TEXT: > > > >>>"Ideally, the mapping protocol would yield a URI (e.g. sip:uri, > > > >>>sips:uri, etc.) which would allow an emergency call to > > be completed > > > >>>using IP end-to-end (possibly, via the Internet). Though > > > >this is the > > > >>>goal, not every PSAP will have IP based connectivity > > right away, so > > > >>>the URI scheme is not fixed. Given these conditions, > > alternate URI > > > >>>schemes, > > > >>> > > > >>>such as tel:uri, are allowed in order to complete calls over > > > >the PSTN." > > > >>> > > > >>>Agreeable? > > > >>> > > > >>>Roger Marshall > > > >>> > > > >>> > > > >>>>-----Original Message----- > > > >>>>From: James M. Polk [mailto:jmpolk@cisco.com] > > > >>>>Sent: Tuesday, December 06, 2005 1:03 PM > > > >>>>To: Marc Linsner; br@brianrosen.net; Roger Marshall; > > > >>>>ecrit@ietf.org > > > >>>>Subject: RE: [Ecrit] Issue 28: NENA Comments on > > > >>>>draft-ietf-ecrit-requirements-00 -Alternate Routes > > > >>>> > > > >>>>In-line > > > >>>> > > > >>>>At 03:30 PM 12/6/2005 -0500, Marc Linsner wrote: > > > >>>>>In-line..... > > > >>>>> > > > >>>>>snip...... > > > >>>>> > > > >>>>> > > > > >>>>> > If a tel:uri is returned, we need to do more > > processing, like > > > >>>>> > convert this uri to a SIP URI to route the message > > *because* > > > >>>>> > we do not know if the next hop proxy is PSAP, and > > it might be > > > >>>>> > a intermediate proxy doing the final resolution of URI to IP > > > >>>>address, > > > >>>>> > or AOR (or a state's emergency VSP) to contact > > address (of a > > > >>>>> > specific city's PSAP). > > > >>>>> > > > > >>>>> > > > >>>>> From an ECRIT pov, I don't agree. Yes, the SIP proxy may > > > >>>>>perform different (including additional) steps in order to > > > >>>>>resolve a tel:uri, but ECRIT is complete at this point. A > > > >>>>>tel:uri > > > >is valid in > > > >>>>>the SIP domain so it should be valid in the ECRIT domain. > > > >>>> > > > >>>>but it's not routable in the SIP domain, and the SIP specs > > > >state that > > > >>>>conversion is necessary to make the message routable. > > This is an > > > >>>>extra step that is less desired. > > > >>>> > > > >>>> > > > >>>>> > >All of them route a tel uri. Every VoIP system I know of > > > >>>>does this > > > >>>>> > >seamlessly. Do we really need to say this in a > > requirements > > > >>>>> > document? > > > >>>>> > > > > > >>>>> > >Further, Roger's "not all PSAPs may have IP based > > > >>>>connectivity" is > > > >>>>> > >useful to motivate why a tel uri may be returned. > > > >>>>> > > > > >>>>> > Movitvate? Why do we need motivation here? > > > >>>>> > > > > >>>>> > Whether my text is used or not, this requirement has the > > > >>>>ability to > > > >>>>> > have a hierarchy of preferred options listed, and my text > > > >>>>gives that > > > >>>>> > order for motivation to work towards the most > > secure solution. > > > >>>>> > It does not dismiss tel:uris, it just says they are not > > > >preferred. > > > >>>>> > > > >>>>>The designer of the PSAP system will decide the > > > >architecture of the > > > >>>>>contact mechanism. Guidance may be offered in an > > > >>>>architecture BCP, but > > > >>>>>I'm not sure it's proper for a requirements draft. > > > >>>> > > > >>>>This is a ridiculous statement. Of course requirements > > > >documents give > > > >>>>preferential orders to mechanisms. The offered text here is not > > > >>>>absolute, and does not say that a tel:uri is forbidden. > > > >>>> > > > >>>> > > > >>>>>I vote for Roger's text. > > > >>>>> > > > >>>>>-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 Thu Dec 08 13:49:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkQpJ-0001VI-KP; Thu, 08 Dec 2005 13:49:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkQpI-0001UN-2Z for ecrit@megatron.ietf.org; Thu, 08 Dec 2005 13:49:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23434 for ; Thu, 8 Dec 2005 13:48:07 -0500 (EST) 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 1EkQpB-0003y3-7y for ecrit@ietf.org; Thu, 08 Dec 2005 13:49:02 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 08 Dec 2005 10:48:50 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB8ImhBL013589 for ; Thu, 8 Dec 2005 10:48:48 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 10:48:43 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.98.118]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 10:48:42 -0800 Message-Id: <4.3.2.7.2.20051208124337.02ab7f58@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Dec 2005 12:48:41 -0600 To: From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 08 Dec 2005 18:48:42.0855 (UTC) FILETIME=[02F6D770:01C5FC28] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm unclear why some one us think a tel:uri scheme will aid an emergency INVITE message in getting to a PSAP that isn't IP enabled? How does the tel:uri help the tradictional infrastructure? This is analogous to the NENA i2 solution, in which the Selective Router and PSAP do not have to have any modifications in order for an IP based phone/device to be able to call said PSAP with a nationally generic emergency number sequence (like "911"). How will a tel:uri accomplish something in this scenario that a SIP or SIPS URI doesn't? This is related to the current thread on Issue #28. cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Dec 08 14:09:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkR8W-00054s-O7; Thu, 08 Dec 2005 14:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkR8V-00053O-OJ for ecrit@megatron.ietf.org; Thu, 08 Dec 2005 14:08:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25978 for ; Thu, 8 Dec 2005 14:07:49 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkR8E-0004gw-VZ for ecrit@ietf.org; Thu, 08 Dec 2005 14:08:44 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jB8J8Hu17225; Thu, 8 Dec 2005 14:08:17 -0500 (EST) Received: from zcarhxs1.corp.nortel.com ([47.129.230.89]) by zrc2hxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 13:08:12 -0600 Received: from [127.0.0.1] ([47.130.16.237] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 14:08:11 -0500 Message-ID: <43988496.70009@nortel.com> Date: Thu, 08 Dec 2005 14:08:06 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? References: <4.3.2.7.2.20051208124337.02ab7f58@email.cisco.com> In-Reply-To: <4.3.2.7.2.20051208124337.02ab7f58@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Dec 2005 19:08:11.0636 (UTC) FILETIME=[BB9CAB40:01C5FC2A] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org You are totally convincing when you say that it is pointless for the mapping protocol to return "tel:911". But I cannot see why there should be a problem with needing a second mapping for an E.164 number or even an enterprise emergency centre number suitably constrained by "phone-context". The "P" in "ESRP" stands for "Proxy", and it's an ordinary part of a Proxy's job description to perform such routings (subject, of course, to operator policy). The need for a separate mapping operation is a separate issue from whether it is possible to use an ordinary telephone number to reach the desired PSAP. Maybe it's this latter concern that has you so upset. James M. Polk wrote: > I'm unclear why some one us think a tel:uri scheme will aid an emergency > INVITE message in getting to a PSAP that isn't IP enabled? How does the > tel:uri help the tradictional infrastructure? > > This is analogous to the NENA i2 solution, in which the Selective Router > and PSAP do not have to have any modifications in order for an IP based > phone/device to be able to call said PSAP with a nationally generic > emergency number sequence (like "911"). > > How will a tel:uri accomplish something in this scenario that a SIP or > SIPS URI doesn't? > > This is related to the current thread on Issue #28. > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented. > > _______________________________________________ > 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 Dec 08 14:20:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkRJM-00024q-5v; Thu, 08 Dec 2005 14:20:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkRJK-00024R-UA for ecrit@megatron.ietf.org; Thu, 08 Dec 2005 14:20:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27872 for ; Thu, 8 Dec 2005 14:19:14 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EkRJH-0005Hi-LR for ecrit@ietf.org; Thu, 08 Dec 2005 14:20:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? Date: Thu, 8 Dec 2005 20:23:35 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4706@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? Thread-Index: AcX8KVpS4NtQ77cSRpejCTidi73HDwAAeiFr From: "Stastny Richard" To: "James M. Polk" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James, I have to apologize not to follow the thread on issue #28,=20 but my attention was reased by your ref and so synced =20 We will nedd the tel URI IN ADDITION. =20 You are correct that tel URIs are only required for i2 solutions and this is the reason why we need the tel URI IN ADDITION to the SIP URI in the response of the database query: =20 We are planning the folloowing: For migration scenarios: a query to the mapping database will return always a SIP URI (and in addition sometimes a tel URI). Normal clients or servers will NEVER look at this Tel URI because of the special context (see below) The SIP URI will either point to the PSAP or to a=20 national ESRP. The national ESRP may either query a national datebase, but it may also query the global database again and now look for the tel URI. =20 The tel URI is NOT a global (E.164 number), it has always a national context, or even a context only usable and to be interpreted by the national ESRP(s).=20 so the tel URI will look e.g. tel:01133;phone-context=3Desrp.at =20 This Tel URI will be used by the ESRP to feed the emergency call into the national emergency system, depending on how it works. =20 regards Richard =20 =20 ________________________________ Von: ecrit-bounces@ietf.org im Auftrag von James M. Polk Gesendet: Do 08.12.2005 19:48 An: ecrit@ietf.org Betreff: [Ecrit] Unclear about tel:uris solving old PSAP = connectivity...? I'm unclear why some one us think a tel:uri scheme will aid an emergency INVITE message in getting to a PSAP that isn't IP enabled? How does the tel:uri help the tradictional infrastructure? This is analogous to the NENA i2 solution, in which the Selective Router and PSAP do not have to have any modifications in order for an IP based phone/device to be able to call said PSAP with a nationally generic emergency number sequence (like "911"). How will a tel:uri accomplish something in this scenario that a SIP or = SIPS URI doesn't? This is related to the current thread on Issue #28. cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ 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 Dec 08 14:31:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkRUg-0006BU-Vx; Thu, 08 Dec 2005 14:31:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkRUa-00062g-Uv for ecrit@megatron.ietf.org; Thu, 08 Dec 2005 14:31:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29646 for ; Thu, 8 Dec 2005 14:30:47 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkRUS-0005qJ-4C for ecrit@ietf.org; Thu, 08 Dec 2005 14:31:42 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 8 Dec 2005 14:31:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Unclear about tel:uris solving old PSAP connectivity...? Date: Thu, 8 Dec 2005 11:31:18 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657503BCFBCF@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? Thread-Index: AcX8K1b1GZeKNBthRuOvO0ESscFRFgAAXbrw From: "Roger Marshall" To: "Tom-PT Taylor" , "James M. Polk" X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James: Based on both Marc & Tom's responses, while I agree that the (Intro) paragraph doesn't address your extended concern, I think the text is valuable in saying that a TEL URI CAN be used. However, I'm not so eager to stipulate exactly HOW (or HOW NOT) to use a TEL URI at this time. Anybody else? Please weigh in if so. Roger. >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Tom-PT Taylor >Sent: Thursday, December 08, 2005 11:08 AM >To: James M. Polk >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] Unclear about tel:uris solving old PSAP=20 >connectivity...? > >You are totally convincing when you say that it is pointless=20 >for the mapping protocol to return "tel:911". But I cannot see=20 >why there should be a problem with needing a second mapping=20 >for an E.164 number or even an enterprise emergency centre=20 >number suitably constrained by "phone-context". The "P" in=20 >"ESRP" stands for "Proxy", and it's an ordinary part of a=20 >Proxy's job description to perform such routings (subject, of=20 >course, to operator policy). > >The need for a separate mapping operation is a separate issue=20 >from whether it is possible to use an ordinary telephone=20 >number to reach the desired PSAP. Maybe it's this latter=20 >concern that has you so upset. > >James M. Polk wrote: >> I'm unclear why some one us think a tel:uri scheme will aid an=20 >> emergency INVITE message in getting to a PSAP that isn't IP=20 >enabled? =20 >> How does the tel:uri help the tradictional infrastructure? >>=20 >> This is analogous to the NENA i2 solution, in which the Selective=20 >> Router and PSAP do not have to have any modifications in=20 >order for an=20 >> IP based phone/device to be able to call said PSAP with a nationally=20 >> generic emergency number sequence (like "911"). >>=20 >> How will a tel:uri accomplish something in this scenario=20 >that a SIP or=20 >> SIPS URI doesn't? >>=20 >> This is related to the current thread on Issue #28. >>=20 >>=20 >> cheers, >> James >>=20 >> ******************* >> Truth is not to be argued... it is to be presented. >>=20 >> _______________________________________________ >> 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 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Dec 08 14:55:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkRr3-0007XD-Nf; Thu, 08 Dec 2005 14:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkRqy-0007Vy-36 for ecrit@megatron.ietf.org; Thu, 08 Dec 2005 14:55:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03481 for ; Thu, 8 Dec 2005 14:53:55 -0500 (EST) 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 1EkRqs-00079B-TM for ecrit@ietf.org; Thu, 08 Dec 2005 14:54:51 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 08 Dec 2005 11:54:39 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB8JsLBV026243; Thu, 8 Dec 2005 11:54:36 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 11:54:36 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.98.118]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 11:54:35 -0800 Message-Id: <4.3.2.7.2.20051208134615.034692a0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Dec 2005 13:54:20 -0600 To: "Tom-PT Taylor" From: "James M. Polk" Subject: Re: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? In-Reply-To: <43988496.70009@nortel.com> References: <4.3.2.7.2.20051208124337.02ab7f58@email.cisco.com> <4.3.2.7.2.20051208124337.02ab7f58@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 08 Dec 2005 19:54:35.0808 (UTC) FILETIME=[371B9A00:01C5FC31] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Tom I'm not upset, I'm just focused on this issue at the moment, because I think several of us were assuming different pieces were also in play. I've been in enough discussions where ECRIT was going to produce the one true address to be routed to the PSAP, that if the ECRIT mapping protocol were to produce something that needs to be looked up a second time using a second procedure (likely ENUM), this will change many of those discussions. I am not opposd to the idea of the mapping protocol producing a "unique" E.164 for the destination PSAP, but I know not all (not many?) PSAPs have a unique E.164 number that's considered to be an emergency line. This number is more likely to be the PSAP's admin line that doesn't get preferential attention, doesn't tie into the MSAG, and doesn't produce the ALI-type location look-up that most want an emergency call to produce. This is the 'E' in E911 as far as North America is concerned. At 02:08 PM 12/8/2005 -0500, Tom-PT Taylor wrote: >You are totally convincing when you say that it is pointless for the >mapping protocol to return "tel:911". But I cannot see why there should be >a problem with needing a second mapping for an E.164 number or even an >enterprise emergency centre number suitably constrained by >"phone-context". The "P" in "ESRP" stands for "Proxy", and it's an >ordinary part of a Proxy's job description to perform such routings >(subject, of course, to operator policy). > >The need for a separate mapping operation is a separate issue from whether >it is possible to use an ordinary telephone number to reach the desired >PSAP. Maybe it's this latter concern that has you so upset. > >James M. Polk wrote: >>I'm unclear why some one us think a tel:uri scheme will aid an emergency >>INVITE message in getting to a PSAP that isn't IP enabled? How does the >>tel:uri help the tradictional infrastructure? >>This is analogous to the NENA i2 solution, in which the Selective Router >>and PSAP do not have to have any modifications in order for an IP based >>phone/device to be able to call said PSAP with a nationally generic >>emergency number sequence (like "911"). >>How will a tel:uri accomplish something in this scenario that a SIP or >>SIPS URI doesn't? >>This is related to the current thread on Issue #28. >> >>cheers, >>James >> ******************* >> Truth is not to be argued... it is to be presented. >>_______________________________________________ >>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 Dec 08 15:30:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkSPh-0000a4-2L; Thu, 08 Dec 2005 15:30:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkSPR-0000S5-1k for ecrit@megatron.ietf.org; Thu, 08 Dec 2005 15:30:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07568 for ; Thu, 8 Dec 2005 15:29:22 -0500 (EST) Received: from ns2.sccx.com ([209.108.197.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkSPA-0008Rx-JS for ecrit@ietf.org; Thu, 08 Dec 2005 15:30:18 -0500 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] Unclear about tel:uris solving old PSAP connectivity...? X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 8 Dec 2005 14:29:48 -0600 Message-ID: <422D410BD61FC04185076AD99AA7207A013A83FF@inilmx01.lgmt.trdo> Thread-Topic: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? Thread-Index: AcX8K1b1GZeKNBthRuOvO0ESscFRFgAAXbrwAAJJhpA= From: "McCalmont, Patti" To: "Roger Marshall" , "Tom-PT Taylor" , "James M. Polk" X-OriginalArrivalTime: 08 Dec 2005 20:29:50.0999 (UTC) FILETIME=[23DC2270:01C5FC36] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I agree with Roger's statement and am in agreement on how the paragraph that Roger sent out many emails ago. Patti -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Thursday, December 08, 2005 1:31 PM To: Tom-PT Taylor; James M. Polk Cc: ecrit@ietf.org Subject: RE: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? James: Based on both Marc & Tom's responses, while I agree that the (Intro) paragraph doesn't address your extended concern, I think the text is valuable in saying that a TEL URI CAN be used. However, I'm not so eager to stipulate exactly HOW (or HOW NOT) to use a TEL URI at this time. Anybody else? Please weigh in if so. Roger. >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Tom-PT Taylor >Sent: Thursday, December 08, 2005 11:08 AM >To: James M. Polk >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] Unclear about tel:uris solving old PSAP=20 >connectivity...? > >You are totally convincing when you say that it is pointless=20 >for the mapping protocol to return "tel:911". But I cannot see=20 >why there should be a problem with needing a second mapping=20 >for an E.164 number or even an enterprise emergency centre=20 >number suitably constrained by "phone-context". The "P" in=20 >"ESRP" stands for "Proxy", and it's an ordinary part of a=20 >Proxy's job description to perform such routings (subject, of=20 >course, to operator policy). > >The need for a separate mapping operation is a separate issue=20 >from whether it is possible to use an ordinary telephone=20 >number to reach the desired PSAP. Maybe it's this latter=20 >concern that has you so upset. > >James M. Polk wrote: >> I'm unclear why some one us think a tel:uri scheme will aid an=20 >> emergency INVITE message in getting to a PSAP that isn't IP=20 >enabled? =20 >> How does the tel:uri help the tradictional infrastructure? >>=20 >> This is analogous to the NENA i2 solution, in which the Selective=20 >> Router and PSAP do not have to have any modifications in=20 >order for an=20 >> IP based phone/device to be able to call said PSAP with a nationally=20 >> generic emergency number sequence (like "911"). >>=20 >> How will a tel:uri accomplish something in this scenario=20 >that a SIP or=20 >> SIPS URI doesn't? >>=20 >> This is related to the current thread on Issue #28. >>=20 >>=20 >> cheers, >> James >>=20 >> ******************* >> Truth is not to be argued... it is to be presented. >>=20 >> _______________________________________________ >> 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 > _______________________________________________ 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 Dec 08 15:54:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkSmb-0008B4-3Z; Thu, 08 Dec 2005 15:54:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkSmX-0008AA-FW for ecrit@megatron.ietf.org; Thu, 08 Dec 2005 15:54:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09790 for ; Thu, 8 Dec 2005 15:53:24 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkSmS-0000uu-Gk for ecrit@ietf.org; Thu, 08 Dec 2005 15:54:21 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 08 Dec 2005 12:54:07 -0800 X-IronPort-AV: i="3.99,231,1131350400"; d="scan'208"; a="375820699:sNHT32847932" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jB8Ks2QM003973; Thu, 8 Dec 2005 12:54:05 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 12:54:03 -0800 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 12:54:02 -0800 From: "Marc Linsner" To: "'James M. Polk'" , "'Tom-PT Taylor'" Subject: RE: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? Date: Thu, 8 Dec 2005 15:54:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX8MinQRyvJYAHIQUyC1KCVs97Z4gAATCsA In-Reply-To: <4.3.2.7.2.20051208134615.034692a0@email.cisco.com> Message-ID: X-OriginalArrivalTime: 08 Dec 2005 20:54:03.0027 (UTC) FILETIME=[85560630:01C5FC39] X-Spam-Score: 1.1 (+) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The purpose of ecrit is to solve a 'mapping' function from a pidf-lo to a uri such that a VoIP (and other contexts) device can continue with it's intended process of determining the routing for session setup. With this said, IMO, any uri that is valid for route processing, should be allowed within the ecrit mapping architecture. In reading rfc2806, a tel:uri specifically identifies a destination in the PSTN (I think the rfc says 'phone network'). A tel:uri can include global (unique on earth) e.164 identifiers as well as locally significant (unique within domain) identifiers. We all imagine that an ecrit mapping system will be implemented on a public/global scale, but IMO we must also assume enterprise scale systems for handling campus type environments. Hence, IMO, a tel:uri that is unique within the intended domain should be (ecrit) valid. So, within an enterprise domain, tel:911 should be a perfectly valid response to a ecrit mapping query. This would tell the VoIP routing device to utilize it's preprogrammed gateway mechanism to reach the intended e.164 identifier on the PSTN. If the domain is global/public, since tel:911 would not be unique, words covering the obvious may be warranted. Just another opinion.... -Marc- > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of James M. Polk > Sent: Thursday, December 08, 2005 2:54 PM > To: Tom-PT Taylor > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Unclear about tel:uris solving old PSAP > connectivity...? > > Tom > > I'm not upset, I'm just focused on this issue at the moment, > because I think several of us were assuming different pieces > were also in play. > > I've been in enough discussions where ECRIT was going to > produce the one true address to be routed to the PSAP, that > if the ECRIT mapping protocol were to produce something that > needs to be looked up a second time using a second procedure > (likely ENUM), this will change many of those discussions. > > I am not opposd to the idea of the mapping protocol producing > a "unique" > E.164 for the destination PSAP, but I know not all (not > many?) PSAPs have a unique E.164 number that's considered to > be an emergency line. This number is more likely to be the > PSAP's admin line that doesn't get preferential attention, > doesn't tie into the MSAG, and doesn't produce the ALI-type > location look-up that most want an emergency call to produce. > This is the 'E' in E911 as far as North America is concerned. > > At 02:08 PM 12/8/2005 -0500, Tom-PT Taylor wrote: > >You are totally convincing when you say that it is pointless for the > >mapping protocol to return "tel:911". But I cannot see why > there should > >be a problem with needing a second mapping for an E.164 > number or even > >an enterprise emergency centre number suitably constrained by > >"phone-context". The "P" in "ESRP" stands for "Proxy", and it's an > >ordinary part of a Proxy's job description to perform such routings > >(subject, of course, to operator policy). > > > >The need for a separate mapping operation is a separate issue from > >whether it is possible to use an ordinary telephone number > to reach the > >desired PSAP. Maybe it's this latter concern that has you so upset. > > > >James M. Polk wrote: > >>I'm unclear why some one us think a tel:uri scheme will aid an > >>emergency INVITE message in getting to a PSAP that isn't IP > enabled? > >>How does the tel:uri help the tradictional infrastructure? > >>This is analogous to the NENA i2 solution, in which the Selective > >>Router and PSAP do not have to have any modifications in > order for an > >>IP based phone/device to be able to call said PSAP with a > nationally > >>generic emergency number sequence (like "911"). > >>How will a tel:uri accomplish something in this scenario > that a SIP or > >>SIPS URI doesn't? > >>This is related to the current thread on Issue #28. > >> > >>cheers, > >>James > >> ******************* > >> Truth is not to be argued... it is to be presented. > >>_______________________________________________ > >>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 Dec 08 16:37:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkTSL-00047i-Im; Thu, 08 Dec 2005 16:37:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkTSI-00044e-1v for ecrit@megatron.ietf.org; Thu, 08 Dec 2005 16:37:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20473 for ; Thu, 8 Dec 2005 16:36:32 -0500 (EST) 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 1EkTSC-0004pQ-2W for ecrit@ietf.org; Thu, 08 Dec 2005 16:37:29 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 08 Dec 2005 13:37:15 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jB8LagQk000227; Thu, 8 Dec 2005 13:37:13 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 13:37:11 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.98.118]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 13:37:10 -0800 Message-Id: <4.3.2.7.2.20051208153556.036d13e0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Dec 2005 15:37:09 -0600 To: "Marc Linsner" , "'Tom-PT Taylor'" From: "James M. Polk" Subject: RE: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? In-Reply-To: References: <4.3.2.7.2.20051208134615.034692a0@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 08 Dec 2005 21:37:10.0620 (UTC) FILETIME=[8BA961C0:01C5FC3F] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 03:54 PM 12/8/2005 -0500, Marc Linsner wrote: >Hence, IMO, a tel:uri that is unique within the intended domain should be >(ecrit) valid. So, within an enterprise domain, tel:911 should be a >perfectly valid response to a ecrit mapping query. This would tell the VoIP >routing device to utilize it's preprogrammed gateway mechanism to reach the >intended e.164 identifier on the PSTN. If the domain is global/public, >since tel:911 would not be unique, words covering the obvious may be >warranted. > >Just another opinion.... one I agree with, with this scoping included. >-Marc- > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of James M. Polk > > Sent: Thursday, December 08, 2005 2:54 PM > > To: Tom-PT Taylor > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] Unclear about tel:uris solving old PSAP > > connectivity...? > > > > Tom > > > > I'm not upset, I'm just focused on this issue at the moment, > > because I think several of us were assuming different pieces > > were also in play. > > > > I've been in enough discussions where ECRIT was going to > > produce the one true address to be routed to the PSAP, that > > if the ECRIT mapping protocol were to produce something that > > needs to be looked up a second time using a second procedure > > (likely ENUM), this will change many of those discussions. > > > > I am not opposd to the idea of the mapping protocol producing > > a "unique" > > E.164 for the destination PSAP, but I know not all (not > > many?) PSAPs have a unique E.164 number that's considered to > > be an emergency line. This number is more likely to be the > > PSAP's admin line that doesn't get preferential attention, > > doesn't tie into the MSAG, and doesn't produce the ALI-type > > location look-up that most want an emergency call to produce. > > This is the 'E' in E911 as far as North America is concerned. > > > > At 02:08 PM 12/8/2005 -0500, Tom-PT Taylor wrote: > > >You are totally convincing when you say that it is pointless for the > > >mapping protocol to return "tel:911". But I cannot see why > > there should > > >be a problem with needing a second mapping for an E.164 > > number or even > > >an enterprise emergency centre number suitably constrained by > > >"phone-context". The "P" in "ESRP" stands for "Proxy", and it's an > > >ordinary part of a Proxy's job description to perform such routings > > >(subject, of course, to operator policy). > > > > > >The need for a separate mapping operation is a separate issue from > > >whether it is possible to use an ordinary telephone number > > to reach the > > >desired PSAP. Maybe it's this latter concern that has you so upset. > > > > > >James M. Polk wrote: > > >>I'm unclear why some one us think a tel:uri scheme will aid an > > >>emergency INVITE message in getting to a PSAP that isn't IP > > enabled? > > >>How does the tel:uri help the tradictional infrastructure? > > >>This is analogous to the NENA i2 solution, in which the Selective > > >>Router and PSAP do not have to have any modifications in > > order for an > > >>IP based phone/device to be able to call said PSAP with a > > nationally > > >>generic emergency number sequence (like "911"). > > >>How will a tel:uri accomplish something in this scenario > > that a SIP or > > >>SIPS URI doesn't? > > >>This is related to the current thread on Issue #28. > > >> > > >>cheers, > > >>James > > >> ******************* > > >> Truth is not to be argued... it is to be presented. > > >>_______________________________________________ > > >>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 Dec 08 17:05:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkTtn-0007xm-Lk; Thu, 08 Dec 2005 17:05:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkTtn-0007xI-23 for ecrit@megatron.ietf.org; Thu, 08 Dec 2005 17:05:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27673 for ; Thu, 8 Dec 2005 17:04:57 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkTti-0007IU-1k for ecrit@ietf.org; Thu, 08 Dec 2005 17:05:55 -0500 Received: from lion.cs.columbia.edu (IDENT:WHUjAkbv2eqchV4CUilS4uo9UFRSe1NI@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jB8M5jiP000574 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 8 Dec 2005 17:05:45 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id jB8M5inE029192 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 8 Dec 2005 17:05:45 -0500 Message-ID: <4398ADD2.8080306@cs.columbia.edu> Date: Thu, 08 Dec 2005 17:04:02 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Two quick remarks on tel URIs: - Please note that 2806 has been obsoleted by RFC 3966. - In particular, tel:911 is *not* valid; you'd have to add a context label to that URI to make it a valid tel URI. Henning Marc Linsner wrote: > In reading rfc2806, a tel:uri specifically identifies a destination in the > PSTN (I think the rfc says 'phone network'). A tel:uri can include global > (unique on earth) e.164 identifiers as well as locally significant (unique > within domain) identifiers. > > Hence, IMO, a tel:uri that is unique within the intended domain should be > (ecrit) valid. So, within an enterprise domain, tel:911 should be a > perfectly valid response to a ecrit mapping query. This would tell the VoIP > routing device to utilize it's preprogrammed gateway mechanism to reach the > intended e.164 identifier on the PSTN. If the domain is global/public, > since tel:911 would not be unique, words covering the obvious may be > warranted. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Dec 08 17:25:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUD5-0000Jp-9K; Thu, 08 Dec 2005 17:25:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUD1-0000J8-Ah for ecrit@megatron.ietf.org; Thu, 08 Dec 2005 17:25:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29547 for ; Thu, 8 Dec 2005 17:24:49 -0500 (EST) 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 1EkUCu-0007x6-79 for ecrit@ietf.org; Thu, 08 Dec 2005 17:25:47 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 08 Dec 2005 14:25:31 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jB8MOnQs002925; Thu, 8 Dec 2005 14:25:23 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 14:25:15 -0800 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 14:25:15 -0800 From: "Marc Linsner" To: "'Henning Schulzrinne'" , Subject: RE: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? Date: Thu, 8 Dec 2005 17:25:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX8Q5MMUF6esFsHQImwElCNIpP0mAAAiQ3g In-Reply-To: <4398ADD2.8080306@cs.columbia.edu> Message-ID: X-OriginalArrivalTime: 08 Dec 2005 22:25:15.0267 (UTC) FILETIME=[430B9530:01C5FC46] X-Spam-Score: 1.1 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org So, it would be either: tel:+1-911 or tel:911;phone-context=example.com -Marc- > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, December 08, 2005 5:04 PM > To: Marc Linsner > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Unclear about tel:uris solving old PSAP > connectivity...? > > Two quick remarks on tel URIs: > > - Please note that 2806 has been obsoleted by RFC 3966. > > - In particular, tel:911 is *not* valid; you'd have to add a > context label to that URI to make it a valid tel URI. > > Henning > > Marc Linsner wrote: > > > In reading rfc2806, a tel:uri specifically identifies a > destination in > > the PSTN (I think the rfc says 'phone network'). A tel:uri can > > include global (unique on earth) e.164 identifiers as well > as locally > > significant (unique within domain) identifiers. > > > > Hence, IMO, a tel:uri that is unique within the intended > domain should > > be > > (ecrit) valid. So, within an enterprise domain, tel:911 > should be a > > perfectly valid response to a ecrit mapping query. This would tell > > the VoIP routing device to utilize it's preprogrammed gateway > > mechanism to reach the intended e.164 identifier on the > PSTN. If the > > domain is global/public, since tel:911 would not be unique, words > > covering the obvious may be warranted. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Dec 08 17:28:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUFQ-0001K0-FP; Thu, 08 Dec 2005 17:28:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUFP-0001Ju-KE for ecrit@megatron.ietf.org; Thu, 08 Dec 2005 17:28:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29885 for ; Thu, 8 Dec 2005 17:27:26 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkUFS-00082E-C8 for ecrit@ietf.org; Thu, 08 Dec 2005 17:28:23 -0500 Received: from lion.cs.columbia.edu (IDENT:XH7MdZ1qpood7y0U4hh0Vanp0+2C4kKt@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jB8MSDiP005989 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 8 Dec 2005 17:28:14 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id jB8MSDnE030445 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 8 Dec 2005 17:28:13 -0500 Message-ID: <4398B317.4020206@cs.columbia.edu> Date: Thu, 08 Dec 2005 17:26:31 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The former is not an E.164 number since you can't dial it from anywhere else except the US. Marc Linsner wrote: > So, it would be either: > > tel:+1-911 > > or > > tel:911;phone-context=example.com > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Dec 08 17:31:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUIZ-00020A-8R; Thu, 08 Dec 2005 17:31:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUIY-0001zy-Jm for ecrit@megatron.ietf.org; Thu, 08 Dec 2005 17:31:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00315 for ; Thu, 8 Dec 2005 17:30:32 -0500 (EST) 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 1EkUIT-00088d-JI for ecrit@ietf.org; Thu, 08 Dec 2005 17:31:30 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 08 Dec 2005 14:31:16 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB8MUdBn004103; Thu, 8 Dec 2005 14:31:14 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 14:31:06 -0800 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 14:31:05 -0800 From: "Marc Linsner" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? Date: Thu, 8 Dec 2005 17:31:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX8RrhOU+gwiZomQa+0NUNbm0OTcgAAEoRQ In-Reply-To: <4398B317.4020206@cs.columbia.edu> Message-ID: X-OriginalArrivalTime: 08 Dec 2005 22:31:05.0902 (UTC) FILETIME=[140A3CE0:01C5FC47] X-Spam-Score: 1.1 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org But it is a valid nanpa number.....interesting... -Marc- > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, December 08, 2005 5:27 PM > To: Marc Linsner > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Unclear about tel:uris solving old PSAP > connectivity...? > > The former is not an E.164 number since you can't dial it > from anywhere else except the US. > > Marc Linsner wrote: > > So, it would be either: > > > > tel:+1-911 > > > > or > > > > tel:911;phone-context=example.com > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Dec 08 17:38:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUPW-0004nq-02; Thu, 08 Dec 2005 17:38:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUPU-0004lu-8I for ecrit@megatron.ietf.org; Thu, 08 Dec 2005 17:38:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01064 for ; Thu, 8 Dec 2005 17:37:49 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkUPW-0008OK-4A for ecrit@ietf.org; Thu, 08 Dec 2005 17:38:47 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 16:38:28 -0600 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 08 Dec 2005 16:38:28 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 16:38:27 -0600 Message-ID: From: "Thomson, Martin" To: "Marc Linsner" , "Henning Schulzrinne" Date: Thu, 8 Dec 2005 16:37:45 -0600 Subject: RE: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 08 Dec 2005 22:38:27.0748 (UTC) FILETIME=[1B669640:01C5FC48] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? Thread-Index: AcX8RrhOU+gwiZomQa+0NUNbm0OTcgAAEoRQAAApziA= X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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="===============1386483574==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============1386483574== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message Content-Transfer-Encoding: base64 RS4xNjQgbnVtYmVycyBhbGwgaGF2ZSAxNSBkaWdpdHMsIGJlZ2lubmluZyB3aXRoIGEgY291bnRy eSBjb2RlLiAgVGhlIGZpcnN0IHRlbDogdXJpIGlzIHRoZXJlZm9yZSBpbmNvbXBsZXRlLg0KNA0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGVjcml0LWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gTWFy YyBMaW5zbmVyDQo+IFNlbnQ6IEZyaWRheSwgOSBEZWNlbWJlciAyMDA1IDk6MzEgQU0NCj4gVG86 ICdIZW5uaW5nIFNjaHVsenJpbm5lJw0KPiBDYzogZWNyaXRAaWV0Zi5vcmcNCj4gU3ViamVjdDog UkU6IFtFY3JpdF0gVW5jbGVhciBhYm91dCB0ZWw6dXJpcyBzb2x2aW5nIG9sZCBQU0FQDQo+IGNv bm5lY3Rpdml0eS4uLj8NCj4gDQo+IEJ1dCBpdCBpcyBhIHZhbGlkIG5hbnBhIG51bWJlci4uLi4u aW50ZXJlc3RpbmcuLi4NCj4gDQo+IC1NYXJjLQ0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+IEZyb206IEhlbm5pbmcgU2NodWx6cmlubmUgW21haWx0bzpoZ3NAY3MuY29s dW1iaWEuZWR1XQ0KPiA+IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAwOCwgMjAwNSA1OjI3IFBN DQo+ID4gVG86IE1hcmMgTGluc25lcg0KPiA+IENjOiBlY3JpdEBpZXRmLm9yZw0KPiA+IFN1Ympl Y3Q6IFJlOiBbRWNyaXRdIFVuY2xlYXIgYWJvdXQgdGVsOnVyaXMgc29sdmluZyBvbGQgUFNBUA0K PiA+IGNvbm5lY3Rpdml0eS4uLj8NCj4gPg0KPiA+IFRoZSBmb3JtZXIgaXMgbm90IGFuIEUuMTY0 IG51bWJlciBzaW5jZSB5b3UgY2FuJ3QgZGlhbCBpdA0KPiA+IGZyb20gYW55d2hlcmUgZWxzZSBl eGNlcHQgdGhlIFVTLg0KPiA+DQo+ID4gTWFyYyBMaW5zbmVyIHdyb3RlOg0KPiA+ID4gU28sIGl0 IHdvdWxkIGJlIGVpdGhlcjoNCj4gPiA+DQo+ID4gPiB0ZWw6KzEtOTExDQo+ID4gPg0KPiA+ID4g b3INCj4gPiA+DQo+ID4gPiB0ZWw6OTExO3Bob25lLWNvbnRleHQ9ZXhhbXBsZS5jb20NCj4gPiA+ DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lw aWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90 aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRl IHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHBy b2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJd --===============1386483574== 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 --===============1386483574==-- From ecrit-bounces@ietf.org Thu Dec 08 17:47:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUXi-0008S0-TL; Thu, 08 Dec 2005 17:47:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUXa-0008Gy-Ui for ecrit@megatron.ietf.org; Thu, 08 Dec 2005 17:47:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02161 for ; Thu, 8 Dec 2005 17:46:06 -0500 (EST) Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkUXX-0000Hd-DF for ecrit@ietf.org; Thu, 08 Dec 2005 17:47:04 -0500 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Thu, 08 Dec 2005 17:46:21 -0500 id 0158805F.4398B7BE.0000773E In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? Date: Thu, 8 Dec 2005 17:46:38 -0500 To: Marc Linsner , Stastny Richard X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Based on these two quotes: On Dec 8, 2005, at 2:23 PM, Stastny Richard wrote: > You are correct that tel URIs are only required for i2 solutions > and this is the reason why we need the tel URI IN ADDITION > to the SIP URI in the response of the database query On Dec 8, 2005, at 3:54 PM, Marc Linsner wrote: > So, within an enterprise domain, tel:911 should be a > perfectly valid response to a ecrit mapping query. This would tell > the VoIP > routing device to utilize it's preprogrammed gateway mechanism to > reach the > intended e.164 identifier on the PSTN. If the domain is global/ > public, > since tel:911 would not be unique, words covering the obvious may be > warranted. It would seem that this is not a protocol requirements issue but a deployment considerations issue. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Dec 08 17:56:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUgY-0003EK-3W; Thu, 08 Dec 2005 17:56:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUgX-0003Cm-5J for ecrit@megatron.ietf.org; Thu, 08 Dec 2005 17:56:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02943 for ; Thu, 8 Dec 2005 17:55:19 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkUgR-0000av-Jv for ecrit@ietf.org; Thu, 08 Dec 2005 17:56:18 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 08 Dec 2005 14:55:57 -0800 X-IronPort-AV: i="3.99,232,1131350400"; d="scan'208"; a="375876208:sNHT33176426" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB8Mtn9o003217; Thu, 8 Dec 2005 14:55:54 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 14:55:52 -0800 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 14:55:51 -0800 From: "Marc Linsner" To: "'Andrew Newton'" , "'Stastny Richard'" Subject: RE: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? Date: Thu, 8 Dec 2005 17:55:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX8SU8cOTD9luWdQci8kCcAbATYJQAASx/g In-Reply-To: Message-ID: X-OriginalArrivalTime: 08 Dec 2005 22:55:52.0032 (UTC) FILETIME=[89D7AE00:01C5FC4A] X-Spam-Score: 1.1 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > Based on these two quotes: > > On Dec 8, 2005, at 2:23 PM, Stastny Richard wrote: > > You are correct that tel URIs are only required for i2 > solutions and > > this is the reason why we need the tel URI IN ADDITION to > the SIP URI > > in the response of the database query > > > On Dec 8, 2005, at 3:54 PM, Marc Linsner wrote: > > So, within an enterprise domain, tel:911 should be a > perfectly valid > > response to a ecrit mapping query. This would tell the > VoIP routing > > device to utilize it's preprogrammed gateway mechanism to reach the > > intended e.164 identifier on the PSTN. If the domain is global/ > > public, since tel:911 would not be unique, words covering > the obvious > > may be warranted. > > It would seem that this is not a protocol requirements issue > but a deployment considerations issue. That's the way I see it.... -Marc- > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Dec 08 18:00:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUkS-00052O-Hn; Thu, 08 Dec 2005 18:00:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUkR-00051a-G1 for ecrit@megatron.ietf.org; Thu, 08 Dec 2005 18:00:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03204 for ; Thu, 8 Dec 2005 17:59:17 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EkUkI-0000h9-Ih for ecrit@ietf.org; Thu, 08 Dec 2005 18:00:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? Date: Fri, 9 Dec 2005 00:02:36 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C470A@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? Thread-Index: AcX8Sc0XDgHf9S5gSyOYUH+YhVfpZQAAa2ny From: "Stastny Richard" To: "Andrew Newton" , "Marc Linsner" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org >It would seem that this is not a protocol requirements issue but a=20 >deployment considerations issue. The protocol requirement is simly that tel URIs are allowed Richard ________________________________ Von: Andrew Newton [mailto:andy@hxr.us] Gesendet: Do 08.12.2005 23:46 An: Marc Linsner; Stastny Richard Cc: ECRIT Betreff: Re: [Ecrit] Unclear about tel:uris solving old PSAP = connectivity...? Based on these two quotes: On Dec 8, 2005, at 2:23 PM, Stastny Richard wrote: > You are correct that tel URIs are only required for i2 solutions > and this is the reason why we need the tel URI IN ADDITION > to the SIP URI in the response of the database query On Dec 8, 2005, at 3:54 PM, Marc Linsner wrote: > So, within an enterprise domain, tel:911 should be a > perfectly valid response to a ecrit mapping query. This would tell=20 > the VoIP > routing device to utilize it's preprogrammed gateway mechanism to=20 > reach the > intended e.164 identifier on the PSTN. If the domain is global/ > public, > since tel:911 would not be unique, words covering the obvious may be > warranted. It would seem that this is not a protocol requirements issue but a=20 deployment considerations issue. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Dec 08 18:00:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUkU-00054Q-Qp; Thu, 08 Dec 2005 18:00:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUkR-00051f-SJ for ecrit@megatron.ietf.org; Thu, 08 Dec 2005 18:00:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03212 for ; Thu, 8 Dec 2005 17:59:22 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkUkN-0000hi-FS for ecrit@ietf.org; Thu, 08 Dec 2005 18:00:20 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 08 Dec 2005 15:00:05 -0800 X-IronPort-AV: i="3.99,232,1131350400"; d="scan'208"; a="238945214:sNHT32243228" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB8MxnBT019635; Thu, 8 Dec 2005 15:00:03 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 14:59:58 -0800 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 14:59:57 -0800 From: "Marc Linsner" To: "'Thomson, Martin'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? Date: Thu, 8 Dec 2005 17:59:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX8RrhOU+gwiZomQa+0NUNbm0OTcgAAEoRQAAApziAAAMUe4A== In-Reply-To: Message-ID: X-OriginalArrivalTime: 08 Dec 2005 22:59:57.0980 (UTC) FILETIME=[1C705DC0:01C5FC4B] X-Spam-Score: 1.1 (+) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org 15 'maximum' digits, not required. -Marc- > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Thursday, December 08, 2005 5:38 PM > To: Marc Linsner; Henning Schulzrinne > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Unclear about tel:uris solving old PSAP > connectivity...? > > E.164 numbers all have 15 digits, beginning with a country > code. The first tel: uri is therefore incomplete. > 4 > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Marc Linsner > > Sent: Friday, 9 December 2005 9:31 AM > > To: 'Henning Schulzrinne' > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Unclear about tel:uris solving old PSAP > > connectivity...? > > > > But it is a valid nanpa number.....interesting... > > > > -Marc- > > > > > -----Original Message----- > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > Sent: Thursday, December 08, 2005 5:27 PM > > > To: Marc Linsner > > > Cc: ecrit@ietf.org > > > Subject: Re: [Ecrit] Unclear about tel:uris solving old PSAP > > > connectivity...? > > > > > > The former is not an E.164 number since you can't dial it from > > > anywhere else except the US. > > > > > > Marc Linsner wrote: > > > > So, it would be either: > > > > > > > > tel:+1-911 > > > > > > > > or > > > > > > > > tel:911;phone-context=example.com > > > > > > > > _______________________________________________ > > 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 Thu Dec 08 18:01:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUlq-00066g-GX; Thu, 08 Dec 2005 18:01:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUlo-00066Q-G1 for ecrit@megatron.ietf.org; Thu, 08 Dec 2005 18:01:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03283 for ; Thu, 8 Dec 2005 18:00:51 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EkUlp-0000lL-7x for ecrit@ietf.org; Thu, 08 Dec 2005 18:01:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? Date: Fri, 9 Dec 2005 00:03:56 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C470B@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? Thread-Index: AcX8RrhOU+gwiZomQa+0NUNbm0OTcgAAEoRQAAApziAAAQBRUQ== From: "Stastny Richard" To: "Thomson, Martin" , "Marc Linsner" , "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org >E.164 numbers all have 15 digits, beginning with a country code. The = first tel: uri is therefore incomplete. Huh? max 15 digits an US E.164 number has only 11 digits +1 222 333 4444 Richard ________________________________ Von: ecrit-bounces@ietf.org im Auftrag von Thomson, Martin Gesendet: Do 08.12.2005 23:37 An: Marc Linsner; Henning Schulzrinne Cc: ecrit@ietf.org Betreff: RE: [Ecrit] Unclear about tel:uris solving old PSAP = connectivity...? E.164 numbers all have 15 digits, beginning with a country code. The = first tel: uri is therefore incomplete. 4 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of > Marc Linsner > Sent: Friday, 9 December 2005 9:31 AM > To: 'Henning Schulzrinne' > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Unclear about tel:uris solving old PSAP > connectivity...? > > But it is a valid nanpa number.....interesting... > > -Marc- > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Thursday, December 08, 2005 5:27 PM > > To: Marc Linsner > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] Unclear about tel:uris solving old PSAP > > connectivity...? > > > > The former is not an E.164 number since you can't dial it > > from anywhere else except the US. > > > > Marc Linsner wrote: > > > So, it would be either: > > > > > > tel:+1-911 > > > > > > or > > > > > > tel:911;phone-context=3Dexample.com > > > > > _______________________________________________ > 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.=20 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]=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Dec 08 18:37:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkVKb-0002r5-Iw; Thu, 08 Dec 2005 18:37:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkVKa-0002nM-HS for ecrit@megatron.ietf.org; Thu, 08 Dec 2005 18:37:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06585 for ; Thu, 8 Dec 2005 18:36:50 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkVKd-0001u7-Ad for ecrit@ietf.org; Thu, 08 Dec 2005 18:37:49 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 08 Dec 2005 15:37:34 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,232,1131350400"; d="scan'208"; a="16889583:sNHT22995264" 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 jB8Na9Uj016494; Thu, 8 Dec 2005 18:37:31 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 18:36:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Unclear about tel:uris solving old PSAP connectivity...? Date: Thu, 8 Dec 2005 18:36:28 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA0C8A@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...? Thread-Index: AcX8RrhOU+gwiZomQa+0NUNbm0OTcgAAEoRQAAF6xGA= From: "Michael Hammer \(mhammer\)" To: "Marc Linsner \(mlinsner\)" , "Henning Schulzrinne" X-OriginalArrivalTime: 08 Dec 2005 23:36:29.0155 (UTC) FILETIME=[367B2330:01C5FC50] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org From: http://www.nanpa.com/number_resource_info/n11_codes.html "N11 codes, more formally known as service codes, are used to provide three-digit dialing access to special services." Probably good to make a distinction between a service code and a telephone number. Closer to speed dialing that gets translated to a real telephone number. If tel: starts with "+" it better be an E.164 number. If not, then must have a phone-context. So for NANP, all numbers have the form: tel:+1-xxx-xxx-xxxx Keep in mind the NANP also accounts for prefix digits in dial strings. Mike > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Marc Linsner (mlinsner) > Sent: Thursday, December 08, 2005 5:31 PM > To: 'Henning Schulzrinne' > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Unclear about tel:uris solving old PSAP=20 > connectivity...? >=20 > But it is a valid nanpa number.....interesting... >=20 > -Marc-=20 >=20 > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Thursday, December 08, 2005 5:27 PM > > To: Marc Linsner > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] Unclear about tel:uris solving old PSAP=20 > > connectivity...? > >=20 > > The former is not an E.164 number since you can't dial it from=20 > > anywhere else except the US. > >=20 > > Marc Linsner wrote: > > > So, it would be either: > > >=20 > > > tel:+1-911 > > >=20 > > > or > > >=20 > > > tel:911;phone-context=3Dexample.com > > >=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 Thu Dec 08 19:00:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkVgp-0001uu-I6; Thu, 08 Dec 2005 19:00:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkVgn-0001rX-0L for ecrit@megatron.ietf.org; Thu, 08 Dec 2005 19:00:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08761 for ; Thu, 8 Dec 2005 18:59:43 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkVgn-0002aZ-CQ for ecrit@ietf.org; Thu, 08 Dec 2005 19:00:42 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id for ; Thu, 8 Dec 2005 19:00:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Dec 2005 16:00:18 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657503C17659@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: Issue 5: Recognition of every Universal Identifier Thread-Index: AcX8Q7XBn/kAmsmPQjGcev7ki+MfgAAA0t6Q From: "Roger Marshall" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Issue 5: Recognition of every Universal Identifier 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org =20 >From Issue 5 of the issue tracker, (ref. www.ietf-ecrit.org issues) Requirements A1a (Id1) and A1b (Id2) specify a universal identifier. Both requirements=20 specify "one or more" but there are no requirements regarding protocol actions=20 when more than one is used. If there are to be more than one universal=20 identifier, do all network elements have to recognize all of them? I don't think Andy's question was ever answered... If this were clarified within a new requirement, it might read as: "Idx. Universal identifier(s), MUST be universally recognizable by any network element which supports the ECRIT protocol." Here are the referred to requirements from the draft, for reference: Id1. Universal Identifier - Setup: One or more universal emergency identifiers MUST be recognized by any device or network=20 element for call setup purposes. Motivation: There must be some way for any device or element to=20 recognize an emergency call throughout the call setup. This is=20 regardless of the device location, the application (voice) service=20 provider used (if any at all), or of any other factor. Examples of these=20 might include: 911, 112, and sos.*. Id2. Universal Identifier Resolution: Where multiple=20 emergency service types exist, it MUST be possible to treat each=20 emergency identifier separately, based on the specific type of=20 emergency help requested. Motivation: Some jurisdictions may have multiple types of emergency=20 services available at the same level, (e.g. fire, police, ambulance), in which case it is important that any one could be selected directly. Roger Marshall. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Dec 08 19:55:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkWY7-0005oE-Re; Thu, 08 Dec 2005 19:55:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkWY5-0005kl-PQ for ecrit@megatron.ietf.org; Thu, 08 Dec 2005 19:55:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14267 for ; Thu, 8 Dec 2005 19:54:52 -0500 (EST) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkWY9-0004IW-1M for ecrit@ietf.org; Thu, 08 Dec 2005 19:55:50 -0500 Received: from [192.168.0.31] (pool-138-89-45-113.mad.east.verizon.net [138.89.45.113]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB90tbeW021101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Dec 2005 19:55:39 -0500 (EST) Message-ID: <4398D60E.7030802@cs.columbia.edu> Date: Thu, 08 Dec 2005 19:55:42 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] Issue 5: Recognition of every Universal Identifier References: <8C837214C95C864C9F34F3635C2A657503C17659@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A657503C17659@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 1.3 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Roger Marshall wrote: > >>From Issue 5 of the issue tracker, (ref. www.ietf-ecrit.org issues) > > Requirements A1a (Id1) and A1b (Id2) specify a universal identifier. > Both requirements > specify "one or more" but there are no requirements regarding protocol > actions > when more than one is used. If there are to be more than one universal > identifier, do all network elements have to recognize all of them? > > I don't think Andy's question was ever answered... > > If this were clarified within a new requirement, it might read as: > > "Idx. Universal identifier(s), MUST be universally recognizable by any > network element which supports the ECRIT protocol." Since we want to build robust systems, and since calls will get routed to strange places on occasion, I have a hard time seeing why we would want to encourage diversity or, worse, have identifiers that are recognizable in some places or not in others. I don't see any advantage to this "flexibility". There is a related requirement, namely that one should be able to recognize a request as an emergency call even if one cannot recognize the specific emergency service requested. The motivation is, again, robustness and the ability to deploy new services incrementally, while still maintaining a fallback capability. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Dec 09 16:46:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekq4h-0004cL-Ox; Fri, 09 Dec 2005 16:46:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekq4f-0004Rm-Pj for ecrit@megatron.ietf.org; Fri, 09 Dec 2005 16:46:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15656 for ; Fri, 9 Dec 2005 16:45:35 -0500 (EST) Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ekq4i-0008CW-8P for ecrit@ietf.org; Fri, 09 Dec 2005 16:46:45 -0500 Received: (qmail invoked by alias); 09 Dec 2005 21:46:16 -0000 Received: from p54987DBA.dip.t-dialin.net (EHLO [192.168.2.102]) [84.152.125.186] by mail.gmx.net (mp010) with SMTP; 09 Dec 2005 22:46:16 +0100 X-Authenticated: #29516787 Message-ID: <4399FB25.3010700@gmx.net> Date: Fri, 09 Dec 2005 22:46:13 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@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: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Ecrit] Please review meeting minutes 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all, please review the meeting minutes. you can find them at: http://www3.ietf.org/proceedings/05nov/minutes/ecrit.txt Corrections to submissions cut off date: December 26, 2005 ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Dec 13 17:05:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmIHM-0000QE-3e; Tue, 13 Dec 2005 17:05:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmIHK-0000Q9-Hc for ecrit@megatron.ietf.org; Tue, 13 Dec 2005 17:05:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05746 for ; Tue, 13 Dec 2005 17:04:48 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmIIM-0004fE-Os for ecrit@ietf.org; Tue, 13 Dec 2005 17:06:53 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Tue, 13 Dec 2005 17:05:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Issue 5: Recognition of every Universal Identifier Date: Tue, 13 Dec 2005 14:05:25 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657503C829E4@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Issue 5: Recognition of every Universal Identifier Thread-Index: AcX8XhxdtABGL/rvQ7aEoZt+amj7OwDyRNqQ From: "Roger Marshall" To: "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Henning: Less "flex"... I agree in this case. So, in are you in support of=20 limiting flexibility via use of the following new requirement as written,=20 or leaving it out? 1st, earlier proposed requirement: "Idx. Universal identifier(s), MUST be universally recognizable by=20 any network element which supports the ECRIT protocol." Additionally, to your follow-on point (below), I've included a stab at=20 an additional second new requirement. Does this come close? 2nd Proposed requirement: "Idxx. A call MUST be recognized as emergency call even if the specific emergency service requested is not recognized." "Motivation: In order to have a robust system that supports incremental=20 Service deployment while still maintaining a fallback capability." Comments please. Thanks. Roger. >-----Original Message----- >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 >Sent: Thursday, December 08, 2005 4:56 PM >To: Roger Marshall >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] Issue 5: Recognition of every Universal Identifier > >Roger Marshall wrote: >> =20 >>>From Issue 5 of the issue tracker, (ref. www.ietf-ecrit.org issues) >>=20 >> Requirements A1a (Id1) and A1b (Id2) specify a universal identifier. >> Both requirements >> specify "one or more" but there are no requirements=20 >regarding protocol=20 >> actions when more than one is used. If there are to be more=20 >than one=20 >> universal identifier, do all network elements have to=20 >recognize all of=20 >> them? >>=20 >> I don't think Andy's question was ever answered... >>=20 >> If this were clarified within a new requirement, it might read as: >>=20 >> "Idx. Universal identifier(s), MUST be universally recognizable by=20 >> any network element which supports the ECRIT protocol." > >Since we want to build robust systems, and since calls will=20 >get routed to strange places on occasion, I have a hard time=20 >seeing why we would want to encourage diversity or, worse,=20 >have identifiers that are recognizable in some places or not=20 >in others. I don't see any advantage to this "flexibility". > >There is a related requirement, namely that one should be able=20 >to recognize a request as an emergency call even if one cannot=20 >recognize the specific emergency service requested. The=20 >motivation is, again, robustness and the ability to deploy new=20 >services incrementally, while still maintaining a fallback capability. > >Henning > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Dec 13 17:11:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmIMc-0001aE-9e; Tue, 13 Dec 2005 17:11:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmIMb-0001ZB-14 for ecrit@megatron.ietf.org; Tue, 13 Dec 2005 17:11:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06397 for ; Tue, 13 Dec 2005 17:10:07 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmINW-0004ps-M7 for ecrit@ietf.org; Tue, 13 Dec 2005 17:12:12 -0500 Received: from lion.cs.columbia.edu (IDENT:jisMtLIYEnR+wE0rOTbSw1KZxpDa2/f4@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jBDMAxQw020518 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 13 Dec 2005 17:10:59 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id jBDMAunE004168 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 13 Dec 2005 17:10:59 -0500 Message-ID: <439F4686.7050507@cs.columbia.edu> Date: Tue, 13 Dec 2005 17:09:10 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] Issue 5: Recognition of every Universal Identifier References: <8C837214C95C864C9F34F3635C2A657503C829E4@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A657503C829E4@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Roger Marshall wrote: > Henning: > > Less "flex"... I agree in this case. So, in are you in support of > limiting flexibility via use of the following new requirement as > written, > or leaving it out? > > 1st, earlier proposed requirement: > "Idx. Universal identifier(s), MUST be universally recognizable by > any network element which supports the ECRIT protocol." Yes - short and to the point... > > Additionally, to your follow-on point (below), I've included a stab at > an additional second new requirement. Does this come close? > > 2nd Proposed requirement: > "Idxx. A call MUST be recognized as emergency call even if the specific > > emergency service requested is not recognized." This indeed captures my concern. > > "Motivation: In order to have a robust system that supports incremental > Service deployment while still maintaining a fallback capability." > > Comments please. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 21 10:15:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep5gL-0003dT-7y; Wed, 21 Dec 2005 10:15:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep5gK-0003dJ-67 for ecrit@megatron.ietf.org; Wed, 21 Dec 2005 10:15:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28384 for ; Wed, 21 Dec 2005 10:14:03 -0500 (EST) Received: from zcars04f.nortel.com ([47.129.242.57] helo=zcars04f.nortelnetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ep5ix-0000sY-41 for ecrit@ietf.org; Wed, 21 Dec 2005 10:17:52 -0500 Received: from zcp4hxm0.corp.nortel.com (zcp4hxm0.corp.nortel.com [47.152.152.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jBLFEjb09088 for ; Wed, 21 Dec 2005 10:14:45 -0500 (EST) Received: from zcarhxs1.corp.nortel.com ([47.129.230.89]) by zcp4hxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Dec 2005 23:14:32 +0800 Received: from [127.0.0.1] ([47.130.24.33] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Dec 2005 10:14:29 -0500 Message-ID: <43A97150.9080904@nortel.com> Date: Wed, 21 Dec 2005 10:14:24 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Dec 2005 15:14:29.0635 (UTC) FILETIME=[3D37DD30:01C60641] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Subject: [Ecrit] re: I-D ACTION:draft-taylor-ecrit-security-threats-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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The subject draft has been completely rewritten based on comments and advice from Stephen Kent of the Security Area Directorate. Stephen took the trouble to provide detailed comments not only on the previous version, but also on an interim version of the present draft. You should find that the focus is much more tightly directed toward the ECRIT mandate. Despite that, we've come up with a number of requirements. There are also a couple of open issues around acquisition and safeguarding of the address of the Location Server and Mapping Server. Tom Taylor ............ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Security Threats and Requirements for Emergency Calling Author(s) : H. Schulzrinne, et al. Filename : draft-taylor-ecrit-security-threats-01.txt Pages : 24 Date : 2005-12-20 This document reviews the security threats to routing of emergency calls through the IP network to Public Safety Answering Points (PSAPs). It establishes a set of security requirements for the entities and processes involved in performing this call routing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-taylor-ecrit-security-threats-01.txt ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 21 10:38:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep62b-0003of-3v; Wed, 21 Dec 2005 10:38:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep62a-0003oX-Jt for ecrit@megatron.ietf.org; Wed, 21 Dec 2005 10:38:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02270 for ; Wed, 21 Dec 2005 10:37:03 -0500 (EST) Received: from zcars04e.nortel.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ep65D-0001xB-NG for ecrit@ietf.org; Wed, 21 Dec 2005 10:40:53 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id jBLFYVH05637 for ; Wed, 21 Dec 2005 10:34:31 -0500 (EST) Received: from zcarhxs1.corp.nortel.com ([47.129.230.89]) by zcarhxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Dec 2005 10:37:54 -0500 Received: from [127.0.0.1] ([47.130.24.33] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Dec 2005 10:37:54 -0500 Message-ID: <43A976CE.4060609@nortel.com> Date: Wed, 21 Dec 2005 10:37:50 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Dec 2005 15:37:54.0579 (UTC) FILETIME=[82A14E30:01C60644] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Ecrit] How to verify that the call is addressed to a PSAP? 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org There is a requirement (too lazy to look up the number) that a call routing element (e.g. SIP proxy) handling a call with an emergency identifier must ensure that it is directed to a PSAP. We've refined this slightly in the security draft to say that this is necessary only if the call routing element would normally authenticate the caller for billing or authorization, but doesn't because it's an emergency call. Anyway, this raises the question: how does such a verification take place? Do we think of this as a different type of query on the mapping database: is this destination URI one of the ones you map to? Tom Taylor _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 21 11:06:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep6UE-0001u0-5J; Wed, 21 Dec 2005 11:06:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep6UD-0001tI-8n for ecrit@megatron.ietf.org; Wed, 21 Dec 2005 11:06:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07410 for ; Wed, 21 Dec 2005 11:05:36 -0500 (EST) From: steve.norreys@bt.com Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ep6Wq-0003Mz-Gu for ecrit@ietf.org; Wed, 21 Dec 2005 11:09:25 -0500 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Dec 2005 16:06:27 +0000 Received: from i2km08-ukbr.domain1.systemhost.net ([193.113.197.82]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Dec 2005 16:06:27 +0000 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] How to verify that the call is addressed to a PSAP? Date: Wed, 21 Dec 2005 16:06:27 -0000 Message-ID: <9D598A34672DF24F89FF4F851A41619515EA57B0@i2km08-ukbr.domain1.systemhost.net> Thread-Topic: [Ecrit] How to verify that the call is addressed to a PSAP? Thread-Index: AcYGRTse5QD0t2UdSEu0Golyw6dyrwAAaf1w To: , X-OriginalArrivalTime: 21 Dec 2005 16:06:27.0781 (UTC) FILETIME=[7FC72F50:01C60648] X-Spam-Score: 2.5 (++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Tom My understanding is that is not that authentication should not happen it just that this procedure for an emergency 'call' should not hold up the setting up of this 'call'.=20 So the normal authentication of the call can still happen and then there is no special verification query which I would hope would keep the costs of supporting emergency sessions down to a minimum. This would of course raises the problem of what happens if the authentication 'fails', how is the 'call' handled? For this I would pass this information to the PSAP and let them deal with it and do nothing with the 'call'. Regards Steve -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tom-PT Taylor Sent: 21 December 2005 15:38 To: ECRIT Subject: [Ecrit] How to verify that the call is addressed to a PSAP? There is a requirement (too lazy to look up the number) that a call=20 routing element (e.g. SIP proxy) handling a call with an emergency=20 identifier must ensure that it is directed to a PSAP. We've refined=20 this slightly in the security draft to say that this is necessary only=20 if the call routing element would normally authenticate the caller for=20 billing or authorization, but doesn't because it's an emergency call. Anyway, this raises the question: how does such a verification take=20 place? Do we think of this as a different type of query on the mapping=20 database: is this destination URI one of the ones you map to? Tom Taylor _______________________________________________ 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 Dec 21 11:08:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep6Vn-0002Xn-4z; Wed, 21 Dec 2005 11:08:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep6Vl-0002Wi-AG for ecrit@megatron.ietf.org; Wed, 21 Dec 2005 11:08:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07682 for ; Wed, 21 Dec 2005 11:07:12 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ep6YP-0003QI-Ce for ecrit@ietf.org; Wed, 21 Dec 2005 11:11:01 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Ep6VW-0000qW-FG; Wed, 21 Dec 2005 10:08:03 -0600 From: "Brian Rosen" To: "'Tom-PT Taylor'" , "'ECRIT'" Subject: RE: [Ecrit] How to verify that the call is addressed to a PSAP? Date: Wed, 21 Dec 2005 11:07:00 -0500 Message-ID: <066001c60648$9526fc90$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 In-Reply-To: <43A976CE.4060609@nortel.com> Thread-Index: AcYGRSf8/27mUHPDSA6dkzWzCB7bWwAAmhSQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm sorry, I can't follow this. Are you talking about a proxy that IS NOT doing the mapping? If it is doing mapping, then I don't see any issue; the mapping tells you where to send the call. If it's not mapping then we have two cases: Before the map After the map Before the map proxies are responsible to forward the call to a proxy that does the mapping. That should be clear and simple The circumstance you seem to be describing is a routing proxy that is handling a call after it is mapped, before it gets to the PSAP. This would include, I guess, an ESRP. Are you suggesting that it somehow queries the mapping database to see that this is one of the legal URIs for that kind of emergency? That seems pretty pointless. I think it should route the call to the Request URI specified, period. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tom-PT Taylor Sent: Wednesday, December 21, 2005 10:38 AM To: ECRIT Subject: [Ecrit] How to verify that the call is addressed to a PSAP? There is a requirement (too lazy to look up the number) that a call routing element (e.g. SIP proxy) handling a call with an emergency identifier must ensure that it is directed to a PSAP. We've refined this slightly in the security draft to say that this is necessary only if the call routing element would normally authenticate the caller for billing or authorization, but doesn't because it's an emergency call. Anyway, this raises the question: how does such a verification take place? Do we think of this as a different type of query on the mapping database: is this destination URI one of the ones you map to? Tom Taylor _______________________________________________ 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 Dec 21 11:35:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep6vv-0005Qw-Pu; Wed, 21 Dec 2005 11:35:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep6vu-0005Qo-Eu for ecrit@megatron.ietf.org; Wed, 21 Dec 2005 11:35:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11804 for ; Wed, 21 Dec 2005 11:34:13 -0500 (EST) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ep6yY-0004NW-1D for ecrit@ietf.org; Wed, 21 Dec 2005 11:38:03 -0500 Received: from zrtphxm0.corp.nortel.com (zrtphxm0.corp.nortel.com [47.140.202.49]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jBLGYtU27316; Wed, 21 Dec 2005 11:34:55 -0500 (EST) Received: from zcarhxs1.corp.nortel.com ([47.129.230.89]) by zrtphxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Dec 2005 11:34:54 -0500 Received: from [127.0.0.1] ([47.130.24.33] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Dec 2005 11:34:53 -0500 Message-ID: <43A98428.8050207@nortel.com> Date: Wed, 21 Dec 2005 11:34:48 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: br@brianrosen.net Subject: Re: [Ecrit] How to verify that the call is addressed to a PSAP? References: <066001c60648$9526fc90$640fa8c0@cis.neustar.com> In-Reply-To: <066001c60648$9526fc90$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Dec 2005 16:34:53.0354 (UTC) FILETIME=[7860F8A0:01C6064C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Here's the scenario I'm concerned about: -- the system assumes that mapping is done in the emergency caller's device -- the caller hacks his device to mark the call as emergency but send it to a destination of his own choosing -- this gets around the ordinary billing procedures, so the caller gets services for free. Brian Rosen wrote: > I'm sorry, I can't follow this. > > Are you talking about a proxy that IS NOT doing the mapping? > If it is doing mapping, then I don't see any issue; the mapping tells you > where to send the call. > > If it's not mapping then we have two cases: > Before the map > After the map > > Before the map proxies are responsible to forward the call to a proxy that > does the mapping. That should be clear and simple > > The circumstance you seem to be describing is a routing proxy that is > handling a call after it is mapped, before it gets to the PSAP. This would > include, I guess, an ESRP. Are you suggesting that it somehow queries the > mapping database to see that this is one of the legal URIs for that kind of > emergency? That seems pretty pointless. I think it should route the call > to the Request URI specified, period. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Tom-PT Taylor > Sent: Wednesday, December 21, 2005 10:38 AM > To: ECRIT > Subject: [Ecrit] How to verify that the call is addressed to a PSAP? > > There is a requirement (too lazy to look up the number) that a call > routing element (e.g. SIP proxy) handling a call with an emergency > identifier must ensure that it is directed to a PSAP. We've refined > this slightly in the security draft to say that this is necessary only > if the call routing element would normally authenticate the caller for > billing or authorization, but doesn't because it's an emergency call. > > Anyway, this raises the question: how does such a verification take > place? Do we think of this as a different type of query on the mapping > database: is this destination URI one of the ones you map to? > > Tom Taylor > > > _______________________________________________ > 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 Dec 22 17:21:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpYox-0000s5-0v; Thu, 22 Dec 2005 17:21:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpYov-0000s0-P0 for ecrit@megatron.ietf.org; Thu, 22 Dec 2005 17:21:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11770 for ; Thu, 22 Dec 2005 17:20:51 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpYrm-000425-I8 for ecrit@ietf.org; Thu, 22 Dec 2005 17:24:58 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 22 Dec 2005 17:21:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Issue 22: 3D of location Date: Thu, 22 Dec 2005 14:21:32 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657503D83DBD@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Issue 22: 3D of location Thread-Index: AcX1MN3L8UdljbHNT3G2nOj2UZOPngR+aFgw From: "Roger Marshall" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Issue 22: Missing requirement for 3D in location. Rohan added this point to the tracker, based on the last IETF mtg.=20 ...from the issue tracker: http://www.ietf-ecrit.org:8080/ecrit-req/ 22. Author: rohan Date: 2005-11-07.22:21:27 =20 Sometimes 2D location information is insufficient to send help (for example, ina large office building). Where provided in civic or geo formats, there is a requirement to get 3D information in some locations. Also in the terminology section the definition of "location" is 2D-limited. Rohan brings up a valid point, so consider the following suggested text, in order to try to satisfy the proposed requirement: NEW REQUIREMENT: Lo-x. 3D Location: The third dimension of a location MAY be included (e.g. altitude, floor, etc.) within the mapping protocol, in addition to its base (two dimensional georaphic, or civic street-type) location information. =20 Motivation: This may be helpful for emergency responders when an emergency request is made from an upper floor, tower, or subterranean position. If everyone likes this, then we should also change the definition (slightly) in the case of the term, location, in order to include 3D examples (as is shown in the text below): location: A geographic identification assigned to a region=20 or feature based on a specific coordinate system, or by other precise=20 information such as a street number and name (and possibly, floor). In=20 the geocoding process, the location is defined with an x,y (and=20 potentially, z) coordinate value according to the distance north or=20 south of the equator and east or west of the prime meridian. Please comment if objectionable. Roger Marshall. =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Dec 22 18:16:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpZg2-0000tl-IE; Thu, 22 Dec 2005 18:16:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpZg1-0000pT-O8 for ecrit@megatron.ietf.org; Thu, 22 Dec 2005 18:16:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17180 for ; Thu, 22 Dec 2005 18:15:41 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpZit-0005nQ-AJ for ecrit@ietf.org; Thu, 22 Dec 2005 18:19:48 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id for ; Thu, 22 Dec 2005 18:16:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Issue Date: Thu, 22 Dec 2005 15:16:32 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657503D83E75@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Issue Thread-Index: AcX1MN3L8UdljbHNT3G2nOj2UZOPngR+aFgwAAdmRwA= From: "Roger Marshall" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Bringing this one back up for discussion in order to resolve the logged issue. Issue 15: Validation of civic location Currently written as: Lo1. Validation of civic location: It MUST be possible to=20 validate a civic location prior to its use in an actual emergency call. Motivation: Location validation provides an opportunity to=20 help assure ahead of time, whether successful mapping to the=20 appropriate PSAP will likely occur when it is required. Validation may=20 also help to avoid delays during emergency call setup due to invalid=20 locations. The following questions were raised from the list, but never resolved... "Is this a protocol requirement or an architecture requirement? When should this validation take place?" My comment: This requirement doesn't really say anything about the mapping protocol. We know that all kinds of things are possible prior to an emergency call. Additionally, we know that the mapping protocol should have a valid location as input to the mapping function in order to be successful. Nevertheless, I contend that it is not the job of the MP to specify this. If a "non-valid" address is used, it will either map or not map to a URI, in which case an error will result. One person's architecture may take advantage of this fact, always employ validation, and become more robust than next guy's. I say that we should delete this requirement, Lo1. Other comments? Roger Marshall. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Dec 22 18:24:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpZnT-0002m8-TO; Thu, 22 Dec 2005 18:24:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpZnT-0002m0-38 for ecrit@megatron.ietf.org; Thu, 22 Dec 2005 18:24:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17683 for ; Thu, 22 Dec 2005 18:23:25 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpZqM-00062X-Uh for ecrit@ietf.org; Thu, 22 Dec 2005 18:27:32 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Dec 2005 17:24:18 -0600 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 22 Dec 2005 17:24:18 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Dec 2005 17:24:18 -0600 Message-ID: From: "Winterbottom, James" To: "Roger Marshall" , Date: Thu, 22 Dec 2005 17:24:17 -0600 Subject: RE: [Ecrit] Issue MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 22 Dec 2005 23:24:18.0437 (UTC) FILETIME=[D4B8EB50:01C6074E] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Issue Thread-Index: AcX1MN3L8UdljbHNT3G2nOj2UZOPngR+aFgwAAdmRwAAAaxnwA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I completely agree with this assessment. This is a provisioning requirement. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Roger Marshall > Sent: Friday, 23 December 2005 10:17 AM > To: ecrit@ietf.org > Subject: RE: [Ecrit] Issue >=20 > Bringing this one back up for discussion in order to resolve the logged > issue. >=20 > Issue 15: Validation of civic location >=20 > Currently written as: > Lo1. Validation of civic location: It MUST be possible to > validate a civic location prior to its use in an actual emergency call. >=20 > Motivation: Location validation provides an opportunity to > help assure ahead of time, whether successful mapping to the > appropriate PSAP will likely occur when it is required. Validation may > also help to avoid delays during emergency call setup due to invalid > locations. >=20 > The following questions were raised from the list, but never resolved... > "Is this a protocol requirement or an architecture requirement? When > should this validation take place?" >=20 > My comment: > This requirement doesn't really say anything about the mapping protocol. > We know that all kinds of things are possible prior to an emergency > call. Additionally, we know that the mapping protocol should have a > valid location as input to the mapping function in order to be > successful. Nevertheless, I contend that it is not the job of the MP to > specify this. If a "non-valid" address is used, it will either map or > not map to a URI, in which case an error will result. One person's > architecture may take advantage of this fact, always employ validation, > and become more robust than next guy's. >=20 >=20 > I say that we should delete this requirement, Lo1. Other comments? >=20 >=20 > Roger Marshall. >=20 >=20 > _______________________________________________ > 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. =20 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 Thu Dec 22 19:32:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EparR-0005y4-B9; Thu, 22 Dec 2005 19:32:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EparP-0005xr-Nt for ecrit@megatron.ietf.org; Thu, 22 Dec 2005 19:32:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23111 for ; Thu, 22 Dec 2005 19:31:33 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpauG-00080O-QB for ecrit@ietf.org; Thu, 22 Dec 2005 19:35:38 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 22 Dec 2005 16:32:25 -0800 X-IronPort-AV: i="3.99,285,1131350400"; d="scan'208"; a="244240607:sNHT89818772" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jBN0VmQm028619; Thu, 22 Dec 2005 16:32:23 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Dec 2005 16:32:18 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.96.20]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Dec 2005 16:32:17 -0800 Message-Id: <4.3.2.7.2.20051222180755.03813258@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Dec 2005 18:32:16 -0600 To: "Roger Marshall" From: "James M. Polk" Subject: RE: [Ecrit] Issue 22: 3D of location In-Reply-To: <8C837214C95C864C9F34F3635C2A657503D83DBD@SEA-EXCHVS-2.tele comsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 23 Dec 2005 00:32:17.0919 (UTC) FILETIME=[544878F0:01C60758] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Roger I'm glad you brought this up. I agree that the altitude dimension should be addressed. I think we ought to consider that any x.y is only as good as it's datum. I think this applies to the z coordinate as well. So, just as you define latitude and longitude (N/S of equator or E/W from prime meridian), we might want to state Altitude is above or below what is considered zero altitude, knowing this may be different in many situations. There's: - mean sea level - mean low tide - mean lowest low tide - mean high tide - pressure altitude (flight level) - absolute altitude (above a ground reference point) - true altitude (above mean sea level - which doesn't really work inland) I don't mean to make this complicated, but we can say that altitude is above or below some "known reference", be it the ground, or mean sea level, or whatever. I also agree that this ought to be a "...MAY be included..." - which means a recipient must be prepared to receive this information, even if not acting on it. At 02:21 PM 12/22/2005 -0800, Roger Marshall wrote: >Issue 22: Missing requirement for 3D in location. > >Rohan added this point to the tracker, based on the last IETF mtg. > >...from the issue tracker: http://www.ietf-ecrit.org:8080/ecrit-req/ > >22. Author: rohan Date: 2005-11-07.22:21:27 >Sometimes 2D location information is insufficient to send help (for >example, ina >large office building). Where provided in civic or geo formats, there >is a >requirement to get 3D information in some locations. Also in the >terminology >section the definition of "location" is 2D-limited. > >Rohan brings up a valid point, so consider the following suggested text, >in order to try to satisfy the proposed requirement: > > >NEW REQUIREMENT: >Lo-x. 3D Location: The third dimension of a location MAY be included >(e.g. altitude, floor, etc.) within the mapping protocol, in addition to >its base (two dimensional georaphic, or civic street-type) location >information. > >Motivation: This may be helpful for emergency responders when an >emergency request is made from an upper floor, tower, or subterranean >position. > > >If everyone likes this, then we should also change the definition >(slightly) in the case of the term, location, in order to include 3D >examples (as is shown in the text below): > >location: A geographic identification assigned to a region >or feature based on a specific coordinate system, or by other precise >information such as a street number and name (and possibly, floor). In >the geocoding process, the location is defined with an x,y (and >potentially, z) coordinate value according to the distance north or >south of the equator and east or west of the prime meridian. > > >Please comment if objectionable. > >Roger Marshall. > > > > > >_______________________________________________ >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 Dec 22 19:35:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epau1-0006bc-Jf; Thu, 22 Dec 2005 19:35:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epatz-0006aW-7j for ecrit@megatron.ietf.org; Thu, 22 Dec 2005 19:35:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23259 for ; Thu, 22 Dec 2005 19:34:12 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Epawt-00085C-Ma for ecrit@ietf.org; Thu, 22 Dec 2005 19:38:21 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 22 Dec 2005 16:35:08 -0800 X-IronPort-AV: i="3.99,286,1131350400"; d="scan'208"; a="382336437:sNHT32710984" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBN0Ym7C010328; Thu, 22 Dec 2005 16:35:03 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Dec 2005 16:35:02 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.96.20]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Dec 2005 16:35:01 -0800 Message-Id: <4.3.2.7.2.20051222183405.0384dcb8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Dec 2005 18:35:00 -0600 To: "Winterbottom, James" , "Roger Marshall" , From: "James M. Polk" Subject: RE: [Ecrit] Issue In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 23 Dec 2005 00:35:01.0982 (UTC) FILETIME=[B6127FE0:01C60758] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 05:24 PM 12/22/2005 -0600, Winterbottom, James wrote: >I completely agree with this assessment. >This is a provisioning requirement. I agree with James > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >Of > > Roger Marshall > > Sent: Friday, 23 December 2005 10:17 AM > > To: ecrit@ietf.org > > Subject: RE: [Ecrit] Issue > > > > Bringing this one back up for discussion in order to resolve the >logged > > issue. > > > > Issue 15: Validation of civic location > > > > Currently written as: > > Lo1. Validation of civic location: It MUST be possible to > > validate a civic location prior to its use in an actual emergency >call. > > > > Motivation: Location validation provides an opportunity to > > help assure ahead of time, whether successful mapping to the > > appropriate PSAP will likely occur when it is required. Validation >may > > also help to avoid delays during emergency call setup due to invalid > > locations. > > > > The following questions were raised from the list, but never >resolved... > > "Is this a protocol requirement or an architecture requirement? When > > should this validation take place?" > > > > My comment: > > This requirement doesn't really say anything about the mapping >protocol. > > We know that all kinds of things are possible prior to an emergency > > call. Additionally, we know that the mapping protocol should have a > > valid location as input to the mapping function in order to be > > successful. Nevertheless, I contend that it is not the job of the MP >to > > specify this. If a "non-valid" address is used, it will either map or > > not map to a URI, in which case an error will result. One person's > > architecture may take advantage of this fact, always employ >validation, > > and become more robust than next guy's. > > > > > > I say that we should delete this requirement, Lo1. Other comments? > > > > > > Roger Marshall. > > > > > > _______________________________________________ > > 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 Dec 22 19:52:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpbAR-0004uy-Rk; Thu, 22 Dec 2005 19:52:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpbAP-0004uX-Eb for ecrit@megatron.ietf.org; Thu, 22 Dec 2005 19:52:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28140 for ; Thu, 22 Dec 2005 19:51:10 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpbDI-0001NC-Vp for ecrit@ietf.org; Thu, 22 Dec 2005 19:55:17 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Dec 2005 18:52:05 -0600 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 22 Dec 2005 18:52:05 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Dec 2005 18:52:04 -0600 Message-ID: From: "Winterbottom, James" To: "James M. Polk" , "Roger Marshall" Date: Thu, 22 Dec 2005 18:52:02 -0600 Subject: RE: [Ecrit] Issue 22: 3D of location MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 23 Dec 2005 00:52:04.0388 (UTC) FILETIME=[17794640:01C6075B] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Issue 22: 3D of location Thread-Index: AcYHWKG3JxJZGL3sRJm3GeLqx0VCWQAAjgLw X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I was under the impression that WGS-84 had already been agreed to as the MUST be supported CRS. This includes what an altitude is. To my understanding there is no way to express what you are talking about below in a civic representation, so I am wondering how you plan to express it in the forms that we currently have. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > James M. Polk > Sent: Friday, 23 December 2005 11:32 AM > To: Roger Marshall > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Issue 22: 3D of location >=20 > Roger >=20 > I'm glad you brought this up. I agree that the altitude dimension should > be > addressed. I think we ought to consider that any x.y is only as good as > it's datum. I think this applies to the z coordinate as well. >=20 > So, just as you define latitude and longitude (N/S of equator or E/W from > prime meridian), we might want to state Altitude is above or below what is > considered zero altitude, knowing this may be different in many > situations. >=20 > There's: >=20 > - mean sea level > - mean low tide > - mean lowest low tide > - mean high tide > - pressure altitude (flight level) > - absolute altitude (above a ground reference point) > - true altitude (above mean sea level - which doesn't really work inland) >=20 > I don't mean to make this complicated, but we can say that altitude is > above or below some "known reference", be it the ground, or mean sea > level, > or whatever. >=20 > I also agree that this ought to be a "...MAY be included..." - which means > a recipient must be prepared to receive this information, even if not > acting on it. >=20 >=20 > At 02:21 PM 12/22/2005 -0800, Roger Marshall wrote: > >Issue 22: Missing requirement for 3D in location. > > > >Rohan added this point to the tracker, based on the last IETF mtg. > > > >...from the issue tracker: http://www.ietf-ecrit.org:8080/ecrit-req/ > > > >22. Author: rohan Date: 2005-11-07.22:21:27 > >Sometimes 2D location information is insufficient to send help (for > >example, ina > >large office building). Where provided in civic or geo formats, there > >is a > >requirement to get 3D information in some locations. Also in the > >terminology > >section the definition of "location" is 2D-limited. > > > >Rohan brings up a valid point, so consider the following suggested text, > >in order to try to satisfy the proposed requirement: > > > > > >NEW REQUIREMENT: > >Lo-x. 3D Location: The third dimension of a location MAY be included > >(e.g. altitude, floor, etc.) within the mapping protocol, in addition to > >its base (two dimensional georaphic, or civic street-type) location > >information. > > > >Motivation: This may be helpful for emergency responders when an > >emergency request is made from an upper floor, tower, or subterranean > >position. > > > > > >If everyone likes this, then we should also change the definition > >(slightly) in the case of the term, location, in order to include 3D > >examples (as is shown in the text below): > > > >location: A geographic identification assigned to a region > >or feature based on a specific coordinate system, or by other precise > >information such as a street number and name (and possibly, floor). In > >the geocoding process, the location is defined with an x,y (and > >potentially, z) coordinate value according to the distance north or > >south of the equator and east or west of the prime meridian. > > > > > >Please comment if objectionable. > > > >Roger Marshall. > > > > > > > > > > > >_______________________________________________ > >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 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 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 Thu Dec 22 21:40:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpcrY-0006qJ-D1; Thu, 22 Dec 2005 21:40:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpcrU-0006mu-9A for ecrit@megatron.ietf.org; Thu, 22 Dec 2005 21:40:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12643 for ; Thu, 22 Dec 2005 21:39:46 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpcuQ-0006Zq-Ha for ecrit@ietf.org; Thu, 22 Dec 2005 21:43:54 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EpcrC-00044q-RP; Thu, 22 Dec 2005 20:40:35 -0600 From: "Brian Rosen" To: "'James M. Polk'" , "'Winterbottom, James'" , "'Roger Marshall'" , Subject: RE: [Ecrit] Issue Date: Thu, 22 Dec 2005 21:38:28 -0500 Message-ID: <094f01c60769$f77a5d70$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 In-Reply-To: <4.3.2.7.2.20051222183405.0384dcb8@email.cisco.com> Thread-Index: AcYHWkyWiLjWsMdGQMq78RgfQSputwADJYew X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I do not agree, and I'm pretty sure there are a lot of folks who have experience with emergency calls who would be consider it a fundamental characteristic of an emergency call system. You MUST know, before you make a call, that the location you report can be used to get you help. That has two uses: a) that you can find a valid mapping, which will get your call to the proper PSAP b) that the PSAP can dispatch a responder such that the responder can find you To do so, it is required that you validate location before you make the call. This is a mechanism requirement, or, if you like, a mechanism design constraint. An acceptable mechanism is to allow one to determine prior to a call that a valid mapping exists. If the locations used to determine a valid mapping are those needed for valid dispatch, for which the data may be reasonably made consistent, and you can do the mapping any time (not just when an emergency call is placed), that will be minimally acceptable. Clearly, it would be possible to design the mapping mechanism such that it could only be used in the process of routing a call. That would be unacceptable. The requirement is necessary to make sure the mechanism can be used to validate location prior to a call. The validation is the requirement. Allowing mapping at any time, and using dispatch-quality data for mapping input is a solution. We have found it advantageous to provide for additional capability that is specific to validation. For example, it is convenient to allow the validation function to return multiple valid alternatives when queried with an invalid location. So, if you queried for 100 Main Street, there was no 100 Main St, but there was a 100 North Main and a 100 South Main, then we would like to return both the alternatives when doing validation. That kind of response is generally not appreciated when routing a call. It takes a human to decide which of the alternatives, if any, is the actual location. There are some other desirable functions that could differentiate a validation request from a mapping request. There are also operational differences; one typically re-validates periodically, and every location is validated. This means the volume of operations for validation dwarfs the volume of actual emergency calls. However, mapping does not have the same latency or the same reliability constraints. This may, or may not, be relevant, depending on the mechanism chosen. However, North America, and specifically NENA, has a firm requirement for validation. It is a current capability. There is a valid and important reason for it. It's clearly implementable. For those reasons, I believe it must stand. We could reword the requirement and the motivation if that would help. First, let us see if we can get rough consensus on existence of a validation requirement. Then we can work on the wording. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James M. Polk Sent: Thursday, December 22, 2005 7:35 PM To: Winterbottom, James; Roger Marshall; ecrit@ietf.org Subject: RE: [Ecrit] Issue At 05:24 PM 12/22/2005 -0600, Winterbottom, James wrote: >I completely agree with this assessment. >This is a provisioning requirement. I agree with James > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >Of > > Roger Marshall > > Sent: Friday, 23 December 2005 10:17 AM > > To: ecrit@ietf.org > > Subject: RE: [Ecrit] Issue > > > > Bringing this one back up for discussion in order to resolve the >logged > > issue. > > > > Issue 15: Validation of civic location > > > > Currently written as: > > Lo1. Validation of civic location: It MUST be possible to > > validate a civic location prior to its use in an actual emergency >call. > > > > Motivation: Location validation provides an opportunity to > > help assure ahead of time, whether successful mapping to the > > appropriate PSAP will likely occur when it is required. Validation >may > > also help to avoid delays during emergency call setup due to invalid > > locations. > > > > The following questions were raised from the list, but never >resolved... > > "Is this a protocol requirement or an architecture requirement? When > > should this validation take place?" > > > > My comment: > > This requirement doesn't really say anything about the mapping >protocol. > > We know that all kinds of things are possible prior to an emergency > > call. Additionally, we know that the mapping protocol should have a > > valid location as input to the mapping function in order to be > > successful. Nevertheless, I contend that it is not the job of the MP >to > > specify this. If a "non-valid" address is used, it will either map or > > not map to a URI, in which case an error will result. One person's > > architecture may take advantage of this fact, always employ >validation, > > and become more robust than next guy's. > > > > > > I say that we should delete this requirement, Lo1. Other comments? > > > > > > Roger Marshall. > > > > > > _______________________________________________ > > 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 Dec 22 21:43:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpcuI-0007Ru-GR; Thu, 22 Dec 2005 21:43:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpcuE-0007PJ-RW for ecrit@megatron.ietf.org; Thu, 22 Dec 2005 21:43:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12805 for ; Thu, 22 Dec 2005 21:42:37 -0500 (EST) Received: from smail1.az.gov ([159.87.179.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Epcx9-0006ex-2I for ecrit@ietf.org; Thu, 22 Dec 2005 21:46:45 -0500 Received: from adoanet.ad.state.az.us (mithril@localhost) by smail1.az.gov with ESMTP id jBN2hSt29119 for ; Thu, 22 Dec 2005 19:43:28 -0700 (MST) (envelope-from Mailer-Daemon@SAN05.AD.STATE.AZ.US) Received: from SAN05.AD.STATE.AZ.US (adoanet.ad.state.az.us [159.87.173.119]) by smail1.az.gov ([159.87.179.136]); 22 Dec 2005 19:43:28 -0700 (MST) Received: from ADOADOM-MTA by SAN05.AD.STATE.AZ.US with Novell_GroupWise; Thu, 22 Dec 2005 19:43:18 -0700 X-Mailer: Novell GroupWise Internet Agent 6.5.5 Beta From: "Adam Iten" To: ecrit@ietf.org Date: Thu, 22 Dec 2005 19:42:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/plain; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: QUOTED-PRINTABLE X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: QUOTED-PRINTABLE Subject: [Ecrit] Re: Ecrit Digest, Vol 11, Issue 15 (Out of the Office) 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I will be out of the office starting Thursday, December 22. I will return = on Tuesday, January 2 and will respond to your email(s) at that time. Happy Holidays, Adam _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Dec 23 00:02:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epf4J-0004p7-LW; Fri, 23 Dec 2005 00:02:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epf4H-0004or-EW for ecrit@megatron.ietf.org; Fri, 23 Dec 2005 00:02:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25006 for ; Fri, 23 Dec 2005 00:01:07 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Epf7E-0002ib-UN for ecrit@ietf.org; Fri, 23 Dec 2005 00:05:17 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Dec 2005 23:02:01 -0600 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 22 Dec 2005 23:02:00 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Dec 2005 23:01:59 -0600 Message-ID: From: "Winterbottom, James" To: , "James M. Polk" , "Roger Marshall" , Date: Thu, 22 Dec 2005 23:01:56 -0600 Subject: RE: [Ecrit] Issue MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 23 Dec 2005 05:01:59.0848 (UTC) FILETIME=[0176E280:01C6077E] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Issue Thread-Index: AcYHWkyWiLjWsMdGQMq78RgfQSputwADJYewAAXCCyA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, No one is arguing that this needs to be done ahead of time. This is why it is a provisioning issue and not a call routing issue. So it is out of scope. > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, 23 December 2005 1:38 PM > To: 'James M. Polk'; Winterbottom, James; 'Roger Marshall'; ecrit@ietf.org > Subject: RE: [Ecrit] Issue >=20 > I do not agree, and I'm pretty sure there are a lot of folks who have > experience with emergency calls who would be consider it a fundamental > characteristic of an emergency call system. >=20 > You MUST know, before you make a call, that the location you report can be > used to get you help. That has two uses: > a) that you can find a valid mapping, which will get your call to > the proper PSAP > b) that the PSAP can dispatch a responder such that the responder > can find you >=20 > To do so, it is required that you validate location before you make the > call. This is a mechanism requirement, or, if you like, a mechanism > design > constraint. >=20 > An acceptable mechanism is to allow one to determine prior to a call that > a > valid mapping exists. If the locations used to determine a valid mapping > are those needed for valid dispatch, for which the data may be reasonably > made consistent, and you can do the mapping any time (not just when an > emergency call is placed), that will be minimally acceptable. >=20 > Clearly, it would be possible to design the mapping mechanism such that it > could only be used in the process of routing a call. That would be > unacceptable. The requirement is necessary to make sure the mechanism can > be used to validate location prior to a call. >=20 > The validation is the requirement. >=20 > Allowing mapping at any time, and using dispatch-quality data for mapping > input is a solution. >=20 > We have found it advantageous to provide for additional capability that is > specific to validation. For example, it is convenient to allow the > validation function to return multiple valid alternatives when queried > with > an invalid location. So, if you queried for 100 Main Street, there was no > 100 Main St, but there was a 100 North Main and a 100 South Main, then we > would like to return both the alternatives when doing validation. That > kind > of response is generally not appreciated when routing a call. It takes a > human to decide which of the alternatives, if any, is the actual location. >=20 > There are some other desirable functions that could differentiate a > validation request from a mapping request. There are also operational > differences; one typically re-validates periodically, and every location > is > validated. This means the volume of operations for validation dwarfs the > volume of actual emergency calls. However, mapping does not have the same > latency or the same reliability constraints. This may, or may not, be > relevant, depending on the mechanism chosen. >=20 > However, North America, and specifically NENA, has a firm requirement for > validation. It is a current capability. There is a valid and important > reason for it. It's clearly implementable. >=20 > For those reasons, I believe it must stand. We could reword the > requirement > and the motivation if that would help. >=20 > First, let us see if we can get rough consensus on existence of a > validation > requirement. Then we can work on the wording. >=20 > Brian >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > James M. Polk > Sent: Thursday, December 22, 2005 7:35 PM > To: Winterbottom, James; Roger Marshall; ecrit@ietf.org > Subject: RE: [Ecrit] Issue >=20 > At 05:24 PM 12/22/2005 -0600, Winterbottom, James wrote: > >I completely agree with this assessment. > >This is a provisioning requirement. >=20 > I agree with James >=20 >=20 >=20 > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > >Of > > > Roger Marshall > > > Sent: Friday, 23 December 2005 10:17 AM > > > To: ecrit@ietf.org > > > Subject: RE: [Ecrit] Issue > > > > > > Bringing this one back up for discussion in order to resolve the > >logged > > > issue. > > > > > > Issue 15: Validation of civic location > > > > > > Currently written as: > > > Lo1. Validation of civic location: It MUST be possible to > > > validate a civic location prior to its use in an actual emergency > >call. > > > > > > Motivation: Location validation provides an opportunity to > > > help assure ahead of time, whether successful mapping to the > > > appropriate PSAP will likely occur when it is required. Validation > >may > > > also help to avoid delays during emergency call setup due to invalid > > > locations. > > > > > > The following questions were raised from the list, but never > >resolved... > > > "Is this a protocol requirement or an architecture requirement? When > > > should this validation take place?" > > > > > > My comment: > > > This requirement doesn't really say anything about the mapping > >protocol. > > > We know that all kinds of things are possible prior to an emergency > > > call. Additionally, we know that the mapping protocol should have a > > > valid location as input to the mapping function in order to be > > > successful. Nevertheless, I contend that it is not the job of the MP > >to > > > specify this. If a "non-valid" address is used, it will either map or > > > not map to a URI, in which case an error will result. One person's > > > architecture may take advantage of this fact, always employ > >validation, > > > and become more robust than next guy's. > > > > > > > > > I say that we should delete this requirement, Lo1. Other comments? > > > > > > > > > Roger Marshall. > > > > > > > > > _______________________________________________ > > > 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 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 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 Fri Dec 23 03:04:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ephv1-0006LG-Qs; Fri, 23 Dec 2005 03:04:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ephuz-0006L6-TW for ecrit@megatron.ietf.org; Fri, 23 Dec 2005 03:04:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09658 for ; Fri, 23 Dec 2005 03:03:42 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ephxv-0007zZ-Sg for ecrit@ietf.org; Fri, 23 Dec 2005 03:07:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] Issue Date: Fri, 23 Dec 2005 09:08:20 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4747@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Issue Thread-Index: AcYHWkyWiLjWsMdGQMq78RgfQSputwADJYewAAXCCyAABle98w== From: "Stastny Richard" To: "Winterbottom, James" , , "James M. Polk" , "Roger Marshall" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James, =20 I agree with Brian that this is requirement of the protocol and/or = behaviour of the mapping database, as he explained. Especially the part on responding with valifd alternatives and different latency. =20 We cannot design a database protocol without having all requirements on the table. =20 If this is out of scope, we have a problem with the scope and not a requirement out of scope =20 Richard =20 =20 ________________________________ Von: ecrit-bounces@ietf.org im Auftrag von Winterbottom, James Gesendet: Fr 23.12.2005 06:01 An: br@brianrosen.net; James M. Polk; Roger Marshall; ecrit@ietf.org Betreff: RE: [Ecrit] Issue=20 Brian, No one is arguing that this needs to be done ahead of time. This is why it is a provisioning issue and not a call routing issue. So it is out of scope. > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, 23 December 2005 1:38 PM > To: 'James M. Polk'; Winterbottom, James; 'Roger Marshall'; ecrit@ietf.org > Subject: RE: [Ecrit] Issue > > I do not agree, and I'm pretty sure there are a lot of folks who have > experience with emergency calls who would be consider it a fundamental > characteristic of an emergency call system. > > You MUST know, before you make a call, that the location you report can be > used to get you help. That has two uses: > a) that you can find a valid mapping, which will get your call to > the proper PSAP > b) that the PSAP can dispatch a responder such that the responder > can find you > > To do so, it is required that you validate location before you make the > call. This is a mechanism requirement, or, if you like, a mechanism > design > constraint. > > An acceptable mechanism is to allow one to determine prior to a call that > a > valid mapping exists. If the locations used to determine a valid mapping > are those needed for valid dispatch, for which the data may be reasonably > made consistent, and you can do the mapping any time (not just when an > emergency call is placed), that will be minimally acceptable. > > Clearly, it would be possible to design the mapping mechanism such that it > could only be used in the process of routing a call. That would be > unacceptable. The requirement is necessary to make sure the mechanism can > be used to validate location prior to a call. > > The validation is the requirement. > > Allowing mapping at any time, and using dispatch-quality data for mapping > input is a solution. > > We have found it advantageous to provide for additional capability that is > specific to validation. For example, it is convenient to allow the > validation function to return multiple valid alternatives when queried > with > an invalid location. So, if you queried for 100 Main Street, there was no > 100 Main St, but there was a 100 North Main and a 100 South Main, then we > would like to return both the alternatives when doing validation. That > kind > of response is generally not appreciated when routing a call. It takes a > human to decide which of the alternatives, if any, is the actual location. > > There are some other desirable functions that could differentiate a > validation request from a mapping request. There are also operational > differences; one typically re-validates periodically, and every location > is > validated. This means the volume of operations for validation dwarfs the > volume of actual emergency calls. However, mapping does not have the same > latency or the same reliability constraints. This may, or may not, be > relevant, depending on the mechanism chosen. > > However, North America, and specifically NENA, has a firm requirement for > validation. It is a current capability. There is a valid and important > reason for it. It's clearly implementable. > > For those reasons, I believe it must stand. We could reword the > requirement > and the motivation if that would help. > > First, let us see if we can get rough consensus on existence of a > validation > requirement. Then we can work on the wording. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > James M. Polk > Sent: Thursday, December 22, 2005 7:35 PM > To: Winterbottom, James; Roger Marshall; ecrit@ietf.org > Subject: RE: [Ecrit] Issue > > At 05:24 PM 12/22/2005 -0600, Winterbottom, James wrote: > >I completely agree with this assessment. > >This is a provisioning requirement. > > I agree with James > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > >Of > > > Roger Marshall > > > Sent: Friday, 23 December 2005 10:17 AM > > > To: ecrit@ietf.org > > > Subject: RE: [Ecrit] Issue > > > > > > Bringing this one back up for discussion in order to resolve the > >logged > > > issue. > > > > > > Issue 15: Validation of civic location > > > > > > Currently written as: > > > Lo1. Validation of civic location: It MUST be possible to > > > validate a civic location prior to its use in an actual emergency > >call. > > > > > > Motivation: Location validation provides an opportunity to > > > help assure ahead of time, whether successful mapping to the > > > appropriate PSAP will likely occur when it is required. Validation > >may > > > also help to avoid delays during emergency call setup due to invalid > > > locations. > > > > > > The following questions were raised from the list, but never > >resolved... > > > "Is this a protocol requirement or an architecture requirement? When > > > should this validation take place?" > > > > > > My comment: > > > This requirement doesn't really say anything about the mapping > >protocol. > > > We know that all kinds of things are possible prior to an emergency > > > call. Additionally, we know that the mapping protocol should have a > > > valid location as input to the mapping function in order to be > > > successful. Nevertheless, I contend that it is not the job of the MP > >to > > > specify this. If a "non-valid" address is used, it will either map or > > > not map to a URI, in which case an error will result. One person's > > > architecture may take advantage of this fact, always employ > >validation, > > > and become more robust than next guy's. > > > > > > > > > I say that we should delete this requirement, Lo1. Other comments? > > > > > > > > > Roger Marshall. > > > > > > > > > _______________________________________________ > > > 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 > > -------------------------------------------------------------------------= ----------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information.=20 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 Fri Dec 23 03:30:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpiJS-0004hC-KL; Fri, 23 Dec 2005 03:30:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpiJP-0004gS-7m for ecrit@megatron.ietf.org; Fri, 23 Dec 2005 03:30:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11469 for ; Fri, 23 Dec 2005 03:28:58 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpiMN-0000GG-Uw for ecrit@ietf.org; Fri, 23 Dec 2005 03:33:09 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 23 Dec 2005 00:29:52 -0800 X-IronPort-AV: i="3.99,286,1131350400"; d="scan'208"; a="382434023:sNHT35865376" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jBN8TlQM018325; Fri, 23 Dec 2005 00:29:50 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Dec 2005 00:29:49 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.96.20]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Dec 2005 00:29:48 -0800 Message-Id: <4.3.2.7.2.20051223021106.037fb320@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 23 Dec 2005 02:29:47 -0600 To: From: "James M. Polk" Subject: RE: [Ecrit] Issue In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 23 Dec 2005 08:29:49.0102 (UTC) FILETIME=[09B80CE0:01C6079B] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 11:01 PM 12/22/2005 -0600, Winterbottom, James wrote: >Brian, > >No one is arguing that this needs to be done ahead of time. This is why >it is a provisioning issue and not a call routing issue. So it is out of >scope. Brian I agree with James here. You (Brian) use the word "you" too many times below for me to figure out who "you" is in what you (Brian) mean. You pose the scenario in which I do (not can, but do) a query for my location to determine *if* my emergency call, *if* I ever make one, *will* go to the proper PSAP. I don't believe 99% of us will walk off a plane and check this piece of information *every time* any one of us walks off a plane; and we're dealing with emergency communications. This is *not* part of today's societal behavior to validate a location in their phone will reach an appropriate PSAP, and I'm believing it will never be. Just think about Letterman tapping an assistant asking a series of people on a major NYC street "do you know what PSAP is your correct PSAP where you are standing now?" or "Do you know the correct PSAP for your home?" How many of those people do you think will get that answer right, and how would they know they're right or wrong? Is the network that's giving them false information going to tell them it's false all the time? Pick a Application SP (for lack of a better term) and ask them what a user of their network does *if* their IP phone points at a PSAP that is not correct? Who does that user call? The App SP? How many people will be employed to do this work? What's the size of that call center? How profitable will that department be? How long will a person wait on hold before they giving up and not bothering to correct the problem? Someone needs to do in the background all that can be done to ensure an emergency call is routed correctly, but this is based on information that was delivered or configured in the endpoint. It was not interactively checked by the human user before proceeding. This is an operational requirement, which is out of scope for ECRIT > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, 23 December 2005 1:38 PM > > To: 'James M. Polk'; Winterbottom, James; 'Roger Marshall'; >ecrit@ietf.org > > Subject: RE: [Ecrit] Issue > > > > I do not agree, and I'm pretty sure there are a lot of folks who have > > experience with emergency calls who would be consider it a fundamental > > characteristic of an emergency call system. > > > > You MUST know, before you make a call, that the location you report >can be > > used to get you help. That has two uses: > > a) that you can find a valid mapping, which will get your call >to > > the proper PSAP > > b) that the PSAP can dispatch a responder such that the >responder > > can find you > > > > To do so, it is required that you validate location before you make >the > > call. This is a mechanism requirement, or, if you like, a mechanism > > design > > constraint. > > > > An acceptable mechanism is to allow one to determine prior to a call >that > > a > > valid mapping exists. If the locations used to determine a valid >mapping > > are those needed for valid dispatch, for which the data may be >reasonably > > made consistent, and you can do the mapping any time (not just when an > > emergency call is placed), that will be minimally acceptable. > > > > Clearly, it would be possible to design the mapping mechanism such >that it > > could only be used in the process of routing a call. That would be > > unacceptable. The requirement is necessary to make sure the mechanism >can > > be used to validate location prior to a call. > > > > The validation is the requirement. > > > > Allowing mapping at any time, and using dispatch-quality data for >mapping > > input is a solution. > > > > We have found it advantageous to provide for additional capability >that is > > specific to validation. For example, it is convenient to allow the > > validation function to return multiple valid alternatives when queried > > with > > an invalid location. So, if you queried for 100 Main Street, there >was no > > 100 Main St, but there was a 100 North Main and a 100 South Main, then >we > > would like to return both the alternatives when doing validation. >That > > kind > > of response is generally not appreciated when routing a call. It >takes a > > human to decide which of the alternatives, if any, is the actual >location. > > > > There are some other desirable functions that could differentiate a > > validation request from a mapping request. There are also operational > > differences; one typically re-validates periodically, and every >location > > is > > validated. This means the volume of operations for validation dwarfs >the > > volume of actual emergency calls. However, mapping does not have the >same > > latency or the same reliability constraints. This may, or may not, be > > relevant, depending on the mechanism chosen. > > > > However, North America, and specifically NENA, has a firm requirement >for > > validation. It is a current capability. There is a valid and >important > > reason for it. It's clearly implementable. > > > > For those reasons, I believe it must stand. We could reword the > > requirement > > and the motivation if that would help. > > > > First, let us see if we can get rough consensus on existence of a > > validation > > requirement. Then we can work on the wording. > > > > Brian > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >Of > > James M. Polk > > Sent: Thursday, December 22, 2005 7:35 PM > > To: Winterbottom, James; Roger Marshall; ecrit@ietf.org > > Subject: RE: [Ecrit] Issue > > > > At 05:24 PM 12/22/2005 -0600, Winterbottom, James wrote: > > >I completely agree with this assessment. > > >This is a provisioning requirement. > > > > I agree with James > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >Behalf > > >Of > > > > Roger Marshall > > > > Sent: Friday, 23 December 2005 10:17 AM > > > > To: ecrit@ietf.org > > > > Subject: RE: [Ecrit] Issue > > > > > > > > Bringing this one back up for discussion in order to resolve the > > >logged > > > > issue. > > > > > > > > Issue 15: Validation of civic location > > > > > > > > Currently written as: > > > > Lo1. Validation of civic location: It MUST be possible to > > > > validate a civic location prior to its use in an actual emergency > > >call. > > > > > > > > Motivation: Location validation provides an opportunity to > > > > help assure ahead of time, whether successful mapping to the > > > > appropriate PSAP will likely occur when it is required. >Validation > > >may > > > > also help to avoid delays during emergency call setup due to >invalid > > > > locations. > > > > > > > > The following questions were raised from the list, but never > > >resolved... > > > > "Is this a protocol requirement or an architecture requirement? >When > > > > should this validation take place?" > > > > > > > > My comment: > > > > This requirement doesn't really say anything about the mapping > > >protocol. > > > > We know that all kinds of things are possible prior to an >emergency > > > > call. Additionally, we know that the mapping protocol should have >a > > > > valid location as input to the mapping function in order to be > > > > successful. Nevertheless, I contend that it is not the job of the >MP > > >to > > > > specify this. If a "non-valid" address is used, it will either >map or > > > > not map to a URI, in which case an error will result. One >person's > > > > architecture may take advantage of this fact, always employ > > >validation, > > > > and become more robust than next guy's. > > > > > > > > > > > > I say that we should delete this requirement, Lo1. Other >comments? > > > > > > > > > > > > Roger Marshall. > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > >------------------------------------------------------------------------------------------------ >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 Fri Dec 23 03:37:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpiR4-0006ya-4O; Fri, 23 Dec 2005 03:37:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpiR2-0006yN-GG for ecrit@megatron.ietf.org; Fri, 23 Dec 2005 03:37:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12329 for ; Fri, 23 Dec 2005 03:36:51 -0500 (EST) 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 1EpiU0-0000WH-Ii for ecrit@ietf.org; Fri, 23 Dec 2005 03:41:02 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 23 Dec 2005 00:37:46 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jBN8bjQg020636; Fri, 23 Dec 2005 00:37:45 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Dec 2005 00:37:45 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.96.20]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Dec 2005 00:37:44 -0800 Message-Id: <4.3.2.7.2.20051223023128.03588498@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 23 Dec 2005 02:37:43 -0600 To: "Stastny Richard" From: "James M. Polk" Subject: Validation in scope or not (was Re: [Ecrit] Issue) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4747@oefeg-s04.oefeg.loc > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 23 Dec 2005 08:37:44.0337 (UTC) FILETIME=[24FB2810:01C6079C] X-Spam-Score: 0.0 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Richard I do not know how a mapping protocol will deal with the interactivity you want if the location provided is invalid (during the emergency call). This is obviously an error condition. So what type of SIP error is send from the ESRP to the UAC to tell them that the location in their INVITE was not valid, and therefore the call will not be placed? Is this a regular error message like a 424 (Bad Location) message (as proposed for a different use in http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-01.txt Do you want UAs to be configured with code to allow for an interactive, almost negotiation, to occur between the mapping server (what the ESRP communicates with when using whatever mapping protocol ECRIT decides on) and the user to figure out where the user really is (before the emergency call is routed further into the network)? At 09:08 AM 12/23/2005 +0100, Stastny Richard wrote: >James, > >I agree with Brian that this is requirement of the protocol and/or >behaviour of >the mapping database, as he explained. Especially the part on responding >with valifd alternatives and different latency. > >We cannot design a database protocol without having all requirements >on the table. > >If this is out of scope, we have a problem with the scope and not >a requirement out of scope > >Richard > > > >________________________________ > >Von: ecrit-bounces@ietf.org im Auftrag von Winterbottom, James >Gesendet: Fr 23.12.2005 06:01 >An: br@brianrosen.net; James M. Polk; Roger Marshall; ecrit@ietf.org >Betreff: RE: [Ecrit] Issue > > > >Brian, > >No one is arguing that this needs to be done ahead of time. This is why >it is a provisioning issue and not a call routing issue. So it is out of >scope. > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, 23 December 2005 1:38 PM > > To: 'James M. Polk'; Winterbottom, James; 'Roger Marshall'; >ecrit@ietf.org > > Subject: RE: [Ecrit] Issue > > > > I do not agree, and I'm pretty sure there are a lot of folks who have > > experience with emergency calls who would be consider it a fundamental > > characteristic of an emergency call system. > > > > You MUST know, before you make a call, that the location you report >can be > > used to get you help. That has two uses: > > a) that you can find a valid mapping, which will get your call >to > > the proper PSAP > > b) that the PSAP can dispatch a responder such that the >responder > > can find you > > > > To do so, it is required that you validate location before you make >the > > call. This is a mechanism requirement, or, if you like, a mechanism > > design > > constraint. > > > > An acceptable mechanism is to allow one to determine prior to a call >that > > a > > valid mapping exists. If the locations used to determine a valid >mapping > > are those needed for valid dispatch, for which the data may be >reasonably > > made consistent, and you can do the mapping any time (not just when an > > emergency call is placed), that will be minimally acceptable. > > > > Clearly, it would be possible to design the mapping mechanism such >that it > > could only be used in the process of routing a call. That would be > > unacceptable. The requirement is necessary to make sure the mechanism >can > > be used to validate location prior to a call. > > > > The validation is the requirement. > > > > Allowing mapping at any time, and using dispatch-quality data for >mapping > > input is a solution. > > > > We have found it advantageous to provide for additional capability >that is > > specific to validation. For example, it is convenient to allow the > > validation function to return multiple valid alternatives when queried > > with > > an invalid location. So, if you queried for 100 Main Street, there >was no > > 100 Main St, but there was a 100 North Main and a 100 South Main, then >we > > would like to return both the alternatives when doing validation. >That > > kind > > of response is generally not appreciated when routing a call. It >takes a > > human to decide which of the alternatives, if any, is the actual >location. > > > > There are some other desirable functions that could differentiate a > > validation request from a mapping request. There are also operational > > differences; one typically re-validates periodically, and every >location > > is > > validated. This means the volume of operations for validation dwarfs >the > > volume of actual emergency calls. However, mapping does not have the >same > > latency or the same reliability constraints. This may, or may not, be > > relevant, depending on the mechanism chosen. > > > > However, North America, and specifically NENA, has a firm requirement >for > > validation. It is a current capability. There is a valid and >important > > reason for it. It's clearly implementable. > > > > For those reasons, I believe it must stand. We could reword the > > requirement > > and the motivation if that would help. > > > > First, let us see if we can get rough consensus on existence of a > > validation > > requirement. Then we can work on the wording. > > > > Brian > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >Of > > James M. Polk > > Sent: Thursday, December 22, 2005 7:35 PM > > To: Winterbottom, James; Roger Marshall; ecrit@ietf.org > > Subject: RE: [Ecrit] Issue > > > > At 05:24 PM 12/22/2005 -0600, Winterbottom, James wrote: > > >I completely agree with this assessment. > > >This is a provisioning requirement. > > > > I agree with James > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >Behalf > > >Of > > > > Roger Marshall > > > > Sent: Friday, 23 December 2005 10:17 AM > > > > To: ecrit@ietf.org > > > > Subject: RE: [Ecrit] Issue > > > > > > > > Bringing this one back up for discussion in order to resolve the > > >logged > > > > issue. > > > > > > > > Issue 15: Validation of civic location > > > > > > > > Currently written as: > > > > Lo1. Validation of civic location: It MUST be possible to > > > > validate a civic location prior to its use in an actual emergency > > >call. > > > > > > > > Motivation: Location validation provides an opportunity to > > > > help assure ahead of time, whether successful mapping to the > > > > appropriate PSAP will likely occur when it is required. >Validation > > >may > > > > also help to avoid delays during emergency call setup due to >invalid > > > > locations. > > > > > > > > The following questions were raised from the list, but never > > >resolved... > > > > "Is this a protocol requirement or an architecture requirement? >When > > > > should this validation take place?" > > > > > > > > My comment: > > > > This requirement doesn't really say anything about the mapping > > >protocol. > > > > We know that all kinds of things are possible prior to an >emergency > > > > call. Additionally, we know that the mapping protocol should have >a > > > > valid location as input to the mapping function in order to be > > > > successful. Nevertheless, I contend that it is not the job of the >MP > > >to > > > > specify this. If a "non-valid" address is used, it will either >map or > > > > not map to a URI, in which case an error will result. One >person's > > > > architecture may take advantage of this fact, always employ > > >validation, > > > > and become more robust than next guy's. > > > > > > > > > > > > I say that we should delete this requirement, Lo1. Other >comments? > > > > > > > > > > > > Roger Marshall. > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > >------------------------------------------------------------------------------------------------ >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 Fri Dec 23 06:55:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EplVo-0004fA-UX; Fri, 23 Dec 2005 06:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EplVm-0004eN-JK for ecrit@megatron.ietf.org; Fri, 23 Dec 2005 06:55:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01361 for ; Fri, 23 Dec 2005 06:53:56 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EplYn-0006kS-Pj for ecrit@ietf.org; Fri, 23 Dec 2005 06:58:10 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jBNBssQw013645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Dec 2005 06:54:55 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id jBNBsjuk008360; Fri, 23 Dec 2005 06:54:53 -0500 Message-ID: <43ABE587.1060707@cs.columbia.edu> Date: Fri, 23 Dec 2005 12:54:47 +0100 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: br@brianrosen.net Subject: Re: [Ecrit] Issue References: <094f01c60769$f77a5d70$640fa8c0@cis.neustar.com> In-Reply-To: <094f01c60769$f77a5d70$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I find this discussion rather confusing, given the (I hope) generally agreed-upon division of labor between the various protocols. As far as I can tell, the mapping protocol can't tell whether it is being invoked immediately as part of a 'real' emergency, after the user dials 9-1-1, or just for testing or ahead of a real emergency, e.g., when the end system detects a change of location. (This is different for call signaling, where one clearly needs to have a "only testing" mechanism to avoid causing grief to the PSAP.) I hope we also agree that the mapping protocol should return good indications of what is going wrong, including an indication "address does not exist" or "coordinates invalid" or maybe even "warning: you're in the open ocean - check that you didn't exchange longitude and latitude; here's the coast guard URL". Since civic-address validation is mainly relevant for stationary and nomadic devices, I thought we had also agreed that it's a good design to have the device ask for a mapping whenever it changes network attachment points and thus possibly change location. In that case, there is no real difference between validation and "really" asking. We had a discussion that there might be some validation mode that provides additional error indications. I think this just complicates the protocol and introduces possible errors. It's always best to use the real thing ahead of an emergency, rather than approximation. Unless we want to revive this discussion, there is no requirement item here. Thus, this whole discussion seems to have a flavor of angels-on-a-pin since the traditional distinction between MSAG validation and lookup in an PSTN MSAG-style environment just doesn't make sense in our architecture. There's a separate, but presumably out-of-scope, discussion as to how the operator of a mapping service ensures the validity of its database. Maybe we're not all that far apart if we get away from just throwing around old terms like validation and define what we really mean in our environment. I suspect part of the disagreement stems from having different pictures in mind of how the whole system works. I've said this before... Henning Brian Rosen wrote: > I do not agree, and I'm pretty sure there are a lot of folks who have > experience with emergency calls who would be consider it a fundamental > characteristic of an emergency call system. > > You MUST know, before you make a call, that the location you report can be > used to get you help. That has two uses: > a) that you can find a valid mapping, which will get your call to > the proper PSAP > b) that the PSAP can dispatch a responder such that the responder > can find you > > To do so, it is required that you validate location before you make the > call. This is a mechanism requirement, or, if you like, a mechanism design > constraint. > > An acceptable mechanism is to allow one to determine prior to a call that a > valid mapping exists. If the locations used to determine a valid mapping > are those needed for valid dispatch, for which the data may be reasonably > made consistent, and you can do the mapping any time (not just when an > emergency call is placed), that will be minimally acceptable. > > Clearly, it would be possible to design the mapping mechanism such that it > could only be used in the process of routing a call. That would be > unacceptable. The requirement is necessary to make sure the mechanism can > be used to validate location prior to a call. > > The validation is the requirement. > > Allowing mapping at any time, and using dispatch-quality data for mapping > input is a solution. > > We have found it advantageous to provide for additional capability that is > specific to validation. For example, it is convenient to allow the > validation function to return multiple valid alternatives when queried with > an invalid location. So, if you queried for 100 Main Street, there was no > 100 Main St, but there was a 100 North Main and a 100 South Main, then we > would like to return both the alternatives when doing validation. That kind > of response is generally not appreciated when routing a call. It takes a > human to decide which of the alternatives, if any, is the actual location. > > There are some other desirable functions that could differentiate a > validation request from a mapping request. There are also operational > differences; one typically re-validates periodically, and every location is > validated. This means the volume of operations for validation dwarfs the > volume of actual emergency calls. However, mapping does not have the same > latency or the same reliability constraints. This may, or may not, be > relevant, depending on the mechanism chosen. > > However, North America, and specifically NENA, has a firm requirement for > validation. It is a current capability. There is a valid and important > reason for it. It's clearly implementable. > > For those reasons, I believe it must stand. We could reword the requirement > and the motivation if that would help. > > First, let us see if we can get rough consensus on existence of a validation > requirement. Then we can work on the wording. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > James M. Polk > Sent: Thursday, December 22, 2005 7:35 PM > To: Winterbottom, James; Roger Marshall; ecrit@ietf.org > Subject: RE: [Ecrit] Issue > > At 05:24 PM 12/22/2005 -0600, Winterbottom, James wrote: >> I completely agree with this assessment. >> This is a provisioning requirement. > > I agree with James > > > >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of >>> Roger Marshall >>> Sent: Friday, 23 December 2005 10:17 AM >>> To: ecrit@ietf.org >>> Subject: RE: [Ecrit] Issue >>> >>> Bringing this one back up for discussion in order to resolve the >> logged >>> issue. >>> >>> Issue 15: Validation of civic location >>> >>> Currently written as: >>> Lo1. Validation of civic location: It MUST be possible to >>> validate a civic location prior to its use in an actual emergency >> call. >>> Motivation: Location validation provides an opportunity to >>> help assure ahead of time, whether successful mapping to the >>> appropriate PSAP will likely occur when it is required. Validation >> may >>> also help to avoid delays during emergency call setup due to invalid >>> locations. >>> >>> The following questions were raised from the list, but never >> resolved... >>> "Is this a protocol requirement or an architecture requirement? When >>> should this validation take place?" >>> >>> My comment: >>> This requirement doesn't really say anything about the mapping >> protocol. >>> We know that all kinds of things are possible prior to an emergency >>> call. Additionally, we know that the mapping protocol should have a >>> valid location as input to the mapping function in order to be >>> successful. Nevertheless, I contend that it is not the job of the MP >> to >>> specify this. If a "non-valid" address is used, it will either map or >>> not map to a URI, in which case an error will result. One person's >>> architecture may take advantage of this fact, always employ >> validation, >>> and become more robust than next guy's. >>> >>> >>> I say that we should delete this requirement, Lo1. Other comments? >>> >>> >>> Roger Marshall. >>> >>> >>> _______________________________________________ >>> 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 Fri Dec 23 08:24:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epmtv-0005QA-8z; Fri, 23 Dec 2005 08:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epmtt-0005Q0-4u for ecrit@megatron.ietf.org; Fri, 23 Dec 2005 08:24:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10350 for ; Fri, 23 Dec 2005 08:22:54 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Epmwv-0001BL-6u for ecrit@ietf.org; Fri, 23 Dec 2005 08:27:09 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Epmth-0001oT-P9; Fri, 23 Dec 2005 07:23:50 -0600 From: "Brian Rosen" To: "'Winterbottom, James'" , "'James M. Polk'" , "'Roger Marshall'" , Subject: RE: [Ecrit] Issue Date: Fri, 23 Dec 2005 08:22:07 -0500 Message-ID: <099f01c607c3$e1fe14a0$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 In-Reply-To: Thread-Index: AcYHWkyWiLjWsMdGQMq78RgfQSputwADJYewAAXCCyAAEUftUA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is not a provisioning issue, at least not a provisioning issue for the mapping database. In some circumstances, it's a provisioning issue for a LIS, but with respect to the mapping protocol, it's an operational requirement. Repeating myself, the requirement is that ecrit provides a mechanism to confirm the validity of an address. Validity in this case means: If the address was to be used for an emergency call, it would be recognized in the database and a valid mapping would be returned If the address was used for dispatch, it is an address that the responders would recognize and be able to send help We can meet the requirement, minimally, by permitting mapping at any time, and by control of the data used for mapping. It is desirable, but not essential, to do more. Brian -----Original Message----- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Friday, December 23, 2005 12:02 AM To: br@brianrosen.net; James M. Polk; Roger Marshall; ecrit@ietf.org Subject: RE: [Ecrit] Issue Brian, No one is arguing that this needs to be done ahead of time. This is why it is a provisioning issue and not a call routing issue. So it is out of scope. > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, 23 December 2005 1:38 PM > To: 'James M. Polk'; Winterbottom, James; 'Roger Marshall'; ecrit@ietf.org > Subject: RE: [Ecrit] Issue > > I do not agree, and I'm pretty sure there are a lot of folks who have > experience with emergency calls who would be consider it a fundamental > characteristic of an emergency call system. > > You MUST know, before you make a call, that the location you report can be > used to get you help. That has two uses: > a) that you can find a valid mapping, which will get your call to > the proper PSAP > b) that the PSAP can dispatch a responder such that the responder > can find you > > To do so, it is required that you validate location before you make the > call. This is a mechanism requirement, or, if you like, a mechanism > design > constraint. > > An acceptable mechanism is to allow one to determine prior to a call that > a > valid mapping exists. If the locations used to determine a valid mapping > are those needed for valid dispatch, for which the data may be reasonably > made consistent, and you can do the mapping any time (not just when an > emergency call is placed), that will be minimally acceptable. > > Clearly, it would be possible to design the mapping mechanism such that it > could only be used in the process of routing a call. That would be > unacceptable. The requirement is necessary to make sure the mechanism can > be used to validate location prior to a call. > > The validation is the requirement. > > Allowing mapping at any time, and using dispatch-quality data for mapping > input is a solution. > > We have found it advantageous to provide for additional capability that is > specific to validation. For example, it is convenient to allow the > validation function to return multiple valid alternatives when queried > with > an invalid location. So, if you queried for 100 Main Street, there was no > 100 Main St, but there was a 100 North Main and a 100 South Main, then we > would like to return both the alternatives when doing validation. That > kind > of response is generally not appreciated when routing a call. It takes a > human to decide which of the alternatives, if any, is the actual location. > > There are some other desirable functions that could differentiate a > validation request from a mapping request. There are also operational > differences; one typically re-validates periodically, and every location > is > validated. This means the volume of operations for validation dwarfs the > volume of actual emergency calls. However, mapping does not have the same > latency or the same reliability constraints. This may, or may not, be > relevant, depending on the mechanism chosen. > > However, North America, and specifically NENA, has a firm requirement for > validation. It is a current capability. There is a valid and important > reason for it. It's clearly implementable. > > For those reasons, I believe it must stand. We could reword the > requirement > and the motivation if that would help. > > First, let us see if we can get rough consensus on existence of a > validation > requirement. Then we can work on the wording. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > James M. Polk > Sent: Thursday, December 22, 2005 7:35 PM > To: Winterbottom, James; Roger Marshall; ecrit@ietf.org > Subject: RE: [Ecrit] Issue > > At 05:24 PM 12/22/2005 -0600, Winterbottom, James wrote: > >I completely agree with this assessment. > >This is a provisioning requirement. > > I agree with James > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > >Of > > > Roger Marshall > > > Sent: Friday, 23 December 2005 10:17 AM > > > To: ecrit@ietf.org > > > Subject: RE: [Ecrit] Issue > > > > > > Bringing this one back up for discussion in order to resolve the > >logged > > > issue. > > > > > > Issue 15: Validation of civic location > > > > > > Currently written as: > > > Lo1. Validation of civic location: It MUST be possible to > > > validate a civic location prior to its use in an actual emergency > >call. > > > > > > Motivation: Location validation provides an opportunity to > > > help assure ahead of time, whether successful mapping to the > > > appropriate PSAP will likely occur when it is required. Validation > >may > > > also help to avoid delays during emergency call setup due to invalid > > > locations. > > > > > > The following questions were raised from the list, but never > >resolved... > > > "Is this a protocol requirement or an architecture requirement? When > > > should this validation take place?" > > > > > > My comment: > > > This requirement doesn't really say anything about the mapping > >protocol. > > > We know that all kinds of things are possible prior to an emergency > > > call. Additionally, we know that the mapping protocol should have a > > > valid location as input to the mapping function in order to be > > > successful. Nevertheless, I contend that it is not the job of the MP > >to > > > specify this. If a "non-valid" address is used, it will either map or > > > not map to a URI, in which case an error will result. One person's > > > architecture may take advantage of this fact, always employ > >validation, > > > and become more robust than next guy's. > > > > > > > > > I say that we should delete this requirement, Lo1. Other comments? > > > > > > > > > Roger Marshall. > > > > > > > > > _______________________________________________ > > > 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 > > ---------------------------------------------------------------------------- -------------------- 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 Fri Dec 23 08:35:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epn4l-0008PX-5n; Fri, 23 Dec 2005 08:35:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epn4k-0008P3-7q for ecrit@megatron.ietf.org; Fri, 23 Dec 2005 08:35:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11931 for ; Fri, 23 Dec 2005 08:34:07 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Epn7m-0001dO-A4 for ecrit@ietf.org; Fri, 23 Dec 2005 08:38:22 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Epn4d-0002qg-SL; Fri, 23 Dec 2005 07:35:08 -0600 From: "Brian Rosen" To: "'James M. Polk'" Subject: RE: [Ecrit] Issue Date: Fri, 23 Dec 2005 08:33:24 -0500 Message-ID: <09a001c607c5$74e5b240$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 In-Reply-To: <4.3.2.7.2.20051223021106.037fb320@email.cisco.com> Thread-Index: AcYHmwrZmFaZVx+6S7af7m+q3+ZVDQAKNqLw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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-Spam-Score: 0.0 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org You (James) are slightly confused. I assure you that there are indeed many people with enough experience with the emergency call system, both in North America, and elsewhere, who would like the ability to test to see if a call will work before they make it. However, that's not the major use of validation. The major use of validation is for LIS operators. Before an entry is put in the LIS, it is validated. Now, what we have today for VoIP is self reporting. The LIS is run by the VoIP operator, and the human that puts the address in is a subscriber. The LIS validates the entry when the subscriber types it in, and the LIS let's the subscriber know if he has given it a bad address. What we want to get to is automatic location, where the access network supplies location. In this case, the validation is done as part of provisioning the LIS. When the entry to the LIS (which is usually some association of a service address and a circuit ID) is made, validation is required. In this case it's usually part of some service order processing at an access carrier. Now, that may be provisioning to the LIS, but it's an operational query to the mapping system. To the mapping system, these queries are run time operations. Depending on how we implement mapping, they may be indistinguishable from actual emergency call routing queries. The query comes from an entity that is different (in most cases) from the entity running the mapping service. It requires a real time response. That seems like a clear requirement, and it's in scope. Brian -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Friday, December 23, 2005 3:30 AM To: br@brianrosen.net Cc: Winterbottom, James; Roger Marshall; ecrit@ietf.org Subject: RE: [Ecrit] Issue At 11:01 PM 12/22/2005 -0600, Winterbottom, James wrote: >Brian, > >No one is arguing that this needs to be done ahead of time. This is why >it is a provisioning issue and not a call routing issue. So it is out of >scope. Brian I agree with James here. You (Brian) use the word "you" too many times below for me to figure out who "you" is in what you (Brian) mean. You pose the scenario in which I do (not can, but do) a query for my location to determine *if* my emergency call, *if* I ever make one, *will* go to the proper PSAP. I don't believe 99% of us will walk off a plane and check this piece of information *every time* any one of us walks off a plane; and we're dealing with emergency communications. This is *not* part of today's societal behavior to validate a location in their phone will reach an appropriate PSAP, and I'm believing it will never be. Just think about Letterman tapping an assistant asking a series of people on a major NYC street "do you know what PSAP is your correct PSAP where you are standing now?" or "Do you know the correct PSAP for your home?" How many of those people do you think will get that answer right, and how would they know they're right or wrong? Is the network that's giving them false information going to tell them it's false all the time? Pick a Application SP (for lack of a better term) and ask them what a user of their network does *if* their IP phone points at a PSAP that is not correct? Who does that user call? The App SP? How many people will be employed to do this work? What's the size of that call center? How profitable will that department be? How long will a person wait on hold before they giving up and not bothering to correct the problem? Someone needs to do in the background all that can be done to ensure an emergency call is routed correctly, but this is based on information that was delivered or configured in the endpoint. It was not interactively checked by the human user before proceeding. This is an operational requirement, which is out of scope for ECRIT > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, 23 December 2005 1:38 PM > > To: 'James M. Polk'; Winterbottom, James; 'Roger Marshall'; >ecrit@ietf.org > > Subject: RE: [Ecrit] Issue > > > > I do not agree, and I'm pretty sure there are a lot of folks who have > > experience with emergency calls who would be consider it a fundamental > > characteristic of an emergency call system. > > > > You MUST know, before you make a call, that the location you report >can be > > used to get you help. That has two uses: > > a) that you can find a valid mapping, which will get your call >to > > the proper PSAP > > b) that the PSAP can dispatch a responder such that the >responder > > can find you > > > > To do so, it is required that you validate location before you make >the > > call. This is a mechanism requirement, or, if you like, a mechanism > > design > > constraint. > > > > An acceptable mechanism is to allow one to determine prior to a call >that > > a > > valid mapping exists. If the locations used to determine a valid >mapping > > are those needed for valid dispatch, for which the data may be >reasonably > > made consistent, and you can do the mapping any time (not just when an > > emergency call is placed), that will be minimally acceptable. > > > > Clearly, it would be possible to design the mapping mechanism such >that it > > could only be used in the process of routing a call. That would be > > unacceptable. The requirement is necessary to make sure the mechanism >can > > be used to validate location prior to a call. > > > > The validation is the requirement. > > > > Allowing mapping at any time, and using dispatch-quality data for >mapping > > input is a solution. > > > > We have found it advantageous to provide for additional capability >that is > > specific to validation. For example, it is convenient to allow the > > validation function to return multiple valid alternatives when queried > > with > > an invalid location. So, if you queried for 100 Main Street, there >was no > > 100 Main St, but there was a 100 North Main and a 100 South Main, then >we > > would like to return both the alternatives when doing validation. >That > > kind > > of response is generally not appreciated when routing a call. It >takes a > > human to decide which of the alternatives, if any, is the actual >location. > > > > There are some other desirable functions that could differentiate a > > validation request from a mapping request. There are also operational > > differences; one typically re-validates periodically, and every >location > > is > > validated. This means the volume of operations for validation dwarfs >the > > volume of actual emergency calls. However, mapping does not have the >same > > latency or the same reliability constraints. This may, or may not, be > > relevant, depending on the mechanism chosen. > > > > However, North America, and specifically NENA, has a firm requirement >for > > validation. It is a current capability. There is a valid and >important > > reason for it. It's clearly implementable. > > > > For those reasons, I believe it must stand. We could reword the > > requirement > > and the motivation if that would help. > > > > First, let us see if we can get rough consensus on existence of a > > validation > > requirement. Then we can work on the wording. > > > > Brian > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >Of > > James M. Polk > > Sent: Thursday, December 22, 2005 7:35 PM > > To: Winterbottom, James; Roger Marshall; ecrit@ietf.org > > Subject: RE: [Ecrit] Issue > > > > At 05:24 PM 12/22/2005 -0600, Winterbottom, James wrote: > > >I completely agree with this assessment. > > >This is a provisioning requirement. > > > > I agree with James > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >Behalf > > >Of > > > > Roger Marshall > > > > Sent: Friday, 23 December 2005 10:17 AM > > > > To: ecrit@ietf.org > > > > Subject: RE: [Ecrit] Issue > > > > > > > > Bringing this one back up for discussion in order to resolve the > > >logged > > > > issue. > > > > > > > > Issue 15: Validation of civic location > > > > > > > > Currently written as: > > > > Lo1. Validation of civic location: It MUST be possible to > > > > validate a civic location prior to its use in an actual emergency > > >call. > > > > > > > > Motivation: Location validation provides an opportunity to > > > > help assure ahead of time, whether successful mapping to the > > > > appropriate PSAP will likely occur when it is required. >Validation > > >may > > > > also help to avoid delays during emergency call setup due to >invalid > > > > locations. > > > > > > > > The following questions were raised from the list, but never > > >resolved... > > > > "Is this a protocol requirement or an architecture requirement? >When > > > > should this validation take place?" > > > > > > > > My comment: > > > > This requirement doesn't really say anything about the mapping > > >protocol. > > > > We know that all kinds of things are possible prior to an >emergency > > > > call. Additionally, we know that the mapping protocol should have >a > > > > valid location as input to the mapping function in order to be > > > > successful. Nevertheless, I contend that it is not the job of the >MP > > >to > > > > specify this. If a "non-valid" address is used, it will either >map or > > > > not map to a URI, in which case an error will result. One >person's > > > > architecture may take advantage of this fact, always employ > > >validation, > > > > and become more robust than next guy's. > > > > > > > > > > > > I say that we should delete this requirement, Lo1. Other >comments? > > > > > > > > > > > > Roger Marshall. > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > >--------------------------------------------------------------------------- --------------------- >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 Fri Dec 23 08:51:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpnKg-0005bw-JD; Fri, 23 Dec 2005 08:51:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpnKe-0005bo-V9 for ecrit@megatron.ietf.org; Fri, 23 Dec 2005 08:51:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13876 for ; Fri, 23 Dec 2005 08:50:33 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpnNh-0002BM-4G for ecrit@ietf.org; Fri, 23 Dec 2005 08:54:49 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EpnKY-0003ww-C4; Fri, 23 Dec 2005 07:51:35 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] Issue Date: Fri, 23 Dec 2005 08:49:48 -0500 Message-ID: <09a301c607c7$bf660b60$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 In-Reply-To: <43ABE587.1060707@cs.columbia.edu> Thread-Index: AcYHt7HMvwh2T7WjT9iMxkxqP6+YKAADcOwg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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-Spam-Score: 0.0 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Henning The problem with your response is that it assumes a particular solution to the existing requirements. It may indeed be that the mapping protocol we select can meet the requirements with no additional work. If so, great. However, it is easy to see how you could design the system so that, for example, mapping could only be done when an emergency call was placed. I know your proposal, and indeed all the current proposals, don't do this. However, the requirement remains a requirement, even if all the proposed solutions meet it. With respect to the desirable characteristics of validation to return alternatives when presented with a bad address, I disagree. First of all, it would not be a large problem if the system always presented alternatives when presented with a bad address. It is clearly the case that when you make an emergency call, you don't want the system to start giving you errors and asking for decisions, but consider the alternative. If you make an emergency call, and there was a bad address, there are only a couple of possible results: The call is dropped - never a real option The call is routed to some kind of default call center The system presents you with alternatives and you choose We're probably going to use the middle one, but we could try the last one if we had information. Consider how the call center tries to help you. First of all, the call center could be in an entirely different part of the world than you are. The address is bad; the default is a default for the service provider or other entity who attempts the mapping. That could be half way around the world. Specifically, if the database is distributed, there is no reasonable way the operator of the call center has access to the data in the mapping database. What they could do is query it. They could figure out that the address is Main, but you meant North Main, but only if they could do a query to the mapping database that returned the alternatives. To route the call, the call center must be able to access the database in exactly the same way I'm proposing. It's exactly the same problem the LIS operator or subscriber has, and the solution is exactly the same. The thing is, this is a database. There are standard queries to databases that get you the kind of alternatives we are talking about. The only way to provide alternatives if the mapping protocol doesn't supply them is to build another protocol to the same database. It could be a copy of the database, and if that's the way someone wants to implement it, fine. I just don't see any reason NOT to allow a query where a failure gets you alternatives, since we need something like it when validation fails. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Friday, December 23, 2005 6:55 AM To: br@brianrosen.net Cc: ecrit@ietf.org Subject: Re: [Ecrit] Issue I find this discussion rather confusing, given the (I hope) generally agreed-upon division of labor between the various protocols. As far as I can tell, the mapping protocol can't tell whether it is being invoked immediately as part of a 'real' emergency, after the user dials 9-1-1, or just for testing or ahead of a real emergency, e.g., when the end system detects a change of location. (This is different for call signaling, where one clearly needs to have a "only testing" mechanism to avoid causing grief to the PSAP.) I hope we also agree that the mapping protocol should return good indications of what is going wrong, including an indication "address does not exist" or "coordinates invalid" or maybe even "warning: you're in the open ocean - check that you didn't exchange longitude and latitude; here's the coast guard URL". Since civic-address validation is mainly relevant for stationary and nomadic devices, I thought we had also agreed that it's a good design to have the device ask for a mapping whenever it changes network attachment points and thus possibly change location. In that case, there is no real difference between validation and "really" asking. We had a discussion that there might be some validation mode that provides additional error indications. I think this just complicates the protocol and introduces possible errors. It's always best to use the real thing ahead of an emergency, rather than approximation. Unless we want to revive this discussion, there is no requirement item here. Thus, this whole discussion seems to have a flavor of angels-on-a-pin since the traditional distinction between MSAG validation and lookup in an PSTN MSAG-style environment just doesn't make sense in our architecture. There's a separate, but presumably out-of-scope, discussion as to how the operator of a mapping service ensures the validity of its database. Maybe we're not all that far apart if we get away from just throwing around old terms like validation and define what we really mean in our environment. I suspect part of the disagreement stems from having different pictures in mind of how the whole system works. I've said this before... Henning Brian Rosen wrote: > I do not agree, and I'm pretty sure there are a lot of folks who have > experience with emergency calls who would be consider it a fundamental > characteristic of an emergency call system. > > You MUST know, before you make a call, that the location you report can be > used to get you help. That has two uses: > a) that you can find a valid mapping, which will get your call to > the proper PSAP > b) that the PSAP can dispatch a responder such that the responder > can find you > > To do so, it is required that you validate location before you make the > call. This is a mechanism requirement, or, if you like, a mechanism design > constraint. > > An acceptable mechanism is to allow one to determine prior to a call that a > valid mapping exists. If the locations used to determine a valid mapping > are those needed for valid dispatch, for which the data may be reasonably > made consistent, and you can do the mapping any time (not just when an > emergency call is placed), that will be minimally acceptable. > > Clearly, it would be possible to design the mapping mechanism such that it > could only be used in the process of routing a call. That would be > unacceptable. The requirement is necessary to make sure the mechanism can > be used to validate location prior to a call. > > The validation is the requirement. > > Allowing mapping at any time, and using dispatch-quality data for mapping > input is a solution. > > We have found it advantageous to provide for additional capability that is > specific to validation. For example, it is convenient to allow the > validation function to return multiple valid alternatives when queried with > an invalid location. So, if you queried for 100 Main Street, there was no > 100 Main St, but there was a 100 North Main and a 100 South Main, then we > would like to return both the alternatives when doing validation. That kind > of response is generally not appreciated when routing a call. It takes a > human to decide which of the alternatives, if any, is the actual location. > > There are some other desirable functions that could differentiate a > validation request from a mapping request. There are also operational > differences; one typically re-validates periodically, and every location is > validated. This means the volume of operations for validation dwarfs the > volume of actual emergency calls. However, mapping does not have the same > latency or the same reliability constraints. This may, or may not, be > relevant, depending on the mechanism chosen. > > However, North America, and specifically NENA, has a firm requirement for > validation. It is a current capability. There is a valid and important > reason for it. It's clearly implementable. > > For those reasons, I believe it must stand. We could reword the requirement > and the motivation if that would help. > > First, let us see if we can get rough consensus on existence of a validation > requirement. Then we can work on the wording. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > James M. Polk > Sent: Thursday, December 22, 2005 7:35 PM > To: Winterbottom, James; Roger Marshall; ecrit@ietf.org > Subject: RE: [Ecrit] Issue > > At 05:24 PM 12/22/2005 -0600, Winterbottom, James wrote: >> I completely agree with this assessment. >> This is a provisioning requirement. > > I agree with James > > > >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of >>> Roger Marshall >>> Sent: Friday, 23 December 2005 10:17 AM >>> To: ecrit@ietf.org >>> Subject: RE: [Ecrit] Issue >>> >>> Bringing this one back up for discussion in order to resolve the >> logged >>> issue. >>> >>> Issue 15: Validation of civic location >>> >>> Currently written as: >>> Lo1. Validation of civic location: It MUST be possible to >>> validate a civic location prior to its use in an actual emergency >> call. >>> Motivation: Location validation provides an opportunity to >>> help assure ahead of time, whether successful mapping to the >>> appropriate PSAP will likely occur when it is required. Validation >> may >>> also help to avoid delays during emergency call setup due to invalid >>> locations. >>> >>> The following questions were raised from the list, but never >> resolved... >>> "Is this a protocol requirement or an architecture requirement? When >>> should this validation take place?" >>> >>> My comment: >>> This requirement doesn't really say anything about the mapping >> protocol. >>> We know that all kinds of things are possible prior to an emergency >>> call. Additionally, we know that the mapping protocol should have a >>> valid location as input to the mapping function in order to be >>> successful. Nevertheless, I contend that it is not the job of the MP >> to >>> specify this. If a "non-valid" address is used, it will either map or >>> not map to a URI, in which case an error will result. One person's >>> architecture may take advantage of this fact, always employ >> validation, >>> and become more robust than next guy's. >>> >>> >>> I say that we should delete this requirement, Lo1. Other comments? >>> >>> >>> Roger Marshall. >>> >>> >>> _______________________________________________ >>> 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 Fri Dec 23 09:40:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epo64-0002NB-J0; Fri, 23 Dec 2005 09:40:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epo63-0002LG-1l for ecrit@megatron.ietf.org; Fri, 23 Dec 2005 09:40:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19699 for ; Fri, 23 Dec 2005 09:39:33 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Epo94-0003q6-Ri for ecrit@ietf.org; Fri, 23 Dec 2005 09:43:48 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jBNEeNQw012804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Dec 2005 09:40:31 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id jBNEeJvC008745; Fri, 23 Dec 2005 09:40:22 -0500 Message-ID: <43AC0C55.9070306@cs.columbia.edu> Date: Fri, 23 Dec 2005 15:40:21 +0100 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: br@brianrosen.net Subject: Re: [Ecrit] Issue References: <09a301c607c7$bf660b60$640fa8c0@cis.neustar.com> In-Reply-To: <09a301c607c7$bf660b60$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, I'm not sure how useful it is to write requirements for solutions that none of us are working on and we probably can't even envision. I don't think the agreement of the three solutions is an accident, but rather a consequence of the architectural separation we have assumed. If we have the requirement that we allow pre-call lookup, it is a fairly obvious consequence to return as much error information as possible. I don't think we're disagreeing on the second issue. I also believe that a reasonable mapping protocol should return both "use this URL if you have to do something, this is my best guess given the information you gave me" (national or global or regional call center) and "here's a list of alternatives that might be better but probably requires human intervention to figure out" (Main, North Main, South Main, Maine Street). I think there is a requirement lurking in your message, namely that a third party, such as your global last-hope call center needs to be able to issue the same query as the caller even if it is far away from the caller. This is because we have no other reasonable way to get these alternatives to the call center, as we probably wouldn't want to stick those into the signaling protocol. Henning Brian Rosen wrote: > Henning > > The problem with your response is that it assumes a particular solution to > the existing requirements. It may indeed be that the mapping protocol we > select can meet the requirements with no additional work. If so, great. > However, it is easy to see how you could design the system so that, for > example, mapping could only be done when an emergency call was placed. I > know your proposal, and indeed all the current proposals, don't do this. > However, the requirement remains a requirement, even if all the proposed > solutions meet it. > > With respect to the desirable characteristics of validation to return > alternatives when presented with a bad address, I disagree. > > First of all, it would not be a large problem if the system always presented > alternatives when presented with a bad address. It is clearly the case that > when you make an emergency call, you don't want the system to start giving > you errors and asking for decisions, but consider the alternative. If you > make an emergency call, and there was a bad address, there are only a couple > of possible results: > The call is dropped - never a real option > The call is routed to some kind of default call center > The system presents you with alternatives and you choose > > We're probably going to use the middle one, but we could try the last one if > we had information. Consider how the call center tries to help you. First > of all, the call center could be in an entirely different part of the world > than you are. The address is bad; the default is a default for the service > provider or other entity who attempts the mapping. That could be half way > around the world. Specifically, if the database is distributed, there is no > reasonable way the operator of the call center has access to the data in the > mapping database. What they could do is query it. They could figure out > that the address is Main, but you meant North Main, but only if they could > do a query to the mapping database that returned the alternatives. To route > the call, the call center must be able to access the database in exactly the > same way I'm proposing. It's exactly the same problem the LIS operator or > subscriber has, and the solution is exactly the same. > > The thing is, this is a database. There are standard queries to databases > that get you the kind of alternatives we are talking about. The only way to > provide alternatives if the mapping protocol doesn't supply them is to build > another protocol to the same database. It could be a copy of the database, > and if that's the way someone wants to implement it, fine. I just don't see > any reason NOT to allow a query where a failure gets you alternatives, since > we need something like it when validation fails. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Dec 23 10:13:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epobk-0003fj-Db; Fri, 23 Dec 2005 10:13:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epobi-0003fe-FR for ecrit@megatron.ietf.org; Fri, 23 Dec 2005 10:13:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22883 for ; Fri, 23 Dec 2005 10:12:16 -0500 (EST) Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Epoek-0004wX-CN for ecrit@ietf.org; Fri, 23 Dec 2005 10:16:31 -0500 Received: from [10.0.1.105] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 23 Dec 2005 10:12:36 -0500 id 015880C5.43AC13E4.00003CCB In-Reply-To: <43ABE587.1060707@cs.columbia.edu> References: <094f01c60769$f77a5d70$640fa8c0@cis.neustar.com> <43ABE587.1060707@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <10398ABC-CAC0-4AA0-90EF-83F09743B81D@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Issue Date: Fri, 23 Dec 2005 10:12:51 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Dec 23, 2005, at 6:54 AM, Henning Schulzrinne wrote: > I find this discussion rather confusing, given the (I hope) > generally agreed-upon division of labor between the various protocols. So long as validation does not impose upon the real work of doing mapping during an emergency call (or any pre-routing or whatever), I see no problem with having this. > As far as I can tell, the mapping protocol can't tell whether it is > being invoked immediately as part of a 'real' emergency, after the > user dials 9-1-1, or just for testing or ahead of a real emergency, > e.g., when the end system detects a change of location. (This is > different for call signaling, where one clearly needs to have a > "only testing" mechanism to avoid causing grief to the PSAP.) If the mapping protocol allows for a "this is a test" flag in the query, then it can detect the difference. > I hope we also agree that the mapping protocol should return good > indications of what is going wrong, including an indication > "address does not exist" or "coordinates invalid" or maybe even > "warning: you're in the open ocean - check that you didn't exchange > longitude and latitude; here's the coast guard URL". First, I thought this was about validation of civic addresses. Validation of geographical coordinates doesn't seem to be fruitful. Just how a mapping server would know that a seeker is truly not in the middle of the ocean is beyond me, unless you are suggesting that emergencies from water craft are not part of the system. There certainly could be differences in a query doing validation and a query for an emergency call. During an emergency call, returning an error is absolutely not helpful. During an emergency, if an address is not in a system, I hope a URL to a best guess or a default would be returned. But during validation, errors are meaningful. As Brian has pointed out, I could well imagine a LIS or VSP doing audits to make sure customers are able to get the best emergency call routing service as possible. > We had a discussion that there might be some validation mode that > provides additional error indications. I think this just > complicates the protocol and introduces possible errors. It's > always best to use the real thing ahead of an emergency, rather > than approximation. Unless we want to revive this discussion, there > is no requirement item here. There is a difference between pre-routing and validation. And if something as simple as a validation flag in the query is going to complicate the protocol to the point of non-interoperability, then we might as well give up now because the act of doing any mapping is orders of magnitude more complicated. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Dec 23 15:38:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eptgf-0003lt-Mq; Fri, 23 Dec 2005 15:38:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eptgb-0003ht-75 for ecrit@megatron.ietf.org; Fri, 23 Dec 2005 15:38:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03633 for ; Fri, 23 Dec 2005 15:37:39 -0500 (EST) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eptje-0007v7-3c for ecrit@ietf.org; Fri, 23 Dec 2005 15:41:57 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jBNKcJof025833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 23 Dec 2005 12:38:20 -0800 Received: from [10.0.1.3] (vpn-10-50-0-148.qualcomm.com [10.50.0.148]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jBNKcAgu014073; Fri, 23 Dec 2005 12:38:18 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <099f01c607c3$e1fe14a0$640fa8c0@cis.neustar.com> References: <099f01c607c3$e1fe14a0$640fa8c0@cis.neustar.com> Date: Fri, 23 Dec 2005 12:37:51 -0800 To: br@brianrosen.net, "'Winterbottom, James'" , "'James M. Polk'" , "'Roger Marshall'" , From: Ted Hardie Subject: RE: [Ecrit] Issue Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 8:22 AM -0500 12/23/05, Brian Rosen wrote: >This is not a provisioning issue, at least not a provisioning issue for the >mapping database. In some circumstances, it's a provisioning issue for a >LIS, but with respect to the mapping protocol, it's an operational >requirement. > >Repeating myself, the requirement is that ecrit provides a mechanism to >confirm the validity of an address. Validity in this case means: > If the address was to be used for an emergency call, it would be >recognized in the database and a valid mapping would be returned > If the address was used for dispatch, it is an address that the >responders would recognize and be able to send help Thanks for very clearly separating those two out. The first actually breaks into two cases: 1) there is enough data provide a mapping, but the data are incomplete or incorrect in some way known to the system; 2) the data are correct and complete and in some way known. How often case one happens depends a lot on the way in which the locality has organized its PSAPs. If a municipality has a single PSAP, a correct mapping can be returned if there is a municipality in the location object, even if no other data is present. There are lots of other cases where partial information or partially correct information can still be sufficient to generate a good mapping; as long as you do not presume that the query is hamstrung to be exact-match only, good results can come from incomplete data in non-trivial numbers of cases. What you want to return to a query in the case of "available mapping, but a location object that is incomplete" depends on whether the query is associated with an actual emergency or is specific to validation. If the query being made is specifically a validation query, it should return the mapping and an indication that the data is not complete (or elements are not correct); if the query is an emergency query, it should simply return the mapping. Distinguishing between the two cases with a query flag is an obvious choice, and I think most of us believe that's a good thing to do. Going beyond that to your second case, there is a question about whether what validation query is testing against is the address's correctness/completeness for dispatch. I think it is logical to assume it is. I *think* then, what the requirement boils down to is that the error results for negative returns to validation queries should distinguish among location objects that are too incomplete for dispatch, those that are complete but appear to have data that is not in the database, and those in which the data are known to be wrong (cites a floor in a building higher than is possible, for example). We could go beyond that, to citing which data elements are known to be wrong, and there are cases where we might be able to cite which data elements are missing (though this gets complicated fast, as you will run into lots of "Must include either municipality or county name with a street address). I personally suspect punting that level of specificity to a free text field is okay; you'll only get it when validating an address, and the most valuable data may actually be who to call to work out the problem (rather than possibly difficult to interpret data). regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Dec 27 18:37:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErOOE-0000xx-09; Tue, 27 Dec 2005 18:37:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErOOC-0000xs-I4 for ecrit@megatron.ietf.org; Tue, 27 Dec 2005 18:37:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05502 for ; Tue, 27 Dec 2005 18:36:46 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErOS8-0001OK-7m for ecrit@ietf.org; Tue, 27 Dec 2005 18:42:00 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Tue, 27 Dec 2005 18:37:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Issue 22: 3D of location Date: Tue, 27 Dec 2005 15:37:32 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657503DD6AB7@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Issue 22: 3D of location Thread-Index: AcYHWKG3JxJZGL3sRJm3GeLqx0VCWQAAjgLwAPhjG/A= From: "Roger Marshall" To: "Winterbottom, James" , "James M. Polk" X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James (W):=20 Indeed we have a requirement for WG84, and it reads:=20 "Lo3. Reference Datum: The mapping server MUST=20 understand WGS-84 coordinate reference system and may=20 understand other reference systems." Making reference to WGS-84 alone doesn't imply 3D to the implementer of the mapping protocol. Proof of that is today's current wireless, which refers to surveyed points as wgs-84, but almost never includes the third coordinate in a resultant position set. What is not explicity mentioned already in the req. draft is the language that states that sending 3-D is OK (as is sending 2-D without having the third dimension). In order to say that each form is acceptable (2D or 3D for either civic or geo, despite which CRS used), I have suggested the added requirement:=20 "Lo-x. 3D Location: The third dimension of a location MAY=20 be included (e.g. altitude, floor, etc.) within the mapping protocol, in addition to its base (two dimensional geographic, or civic street-type)=20 location information." Comments, anyone? Roger Marshall. >-----Original Message----- >From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 >Sent: Thursday, December 22, 2005 4:52 PM >To: James M. Polk; Roger Marshall >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] Issue 22: 3D of location > >I was under the impression that WGS-84 had already been agreed=20 >to as the MUST be supported CRS. This includes what an=20 >altitude is. To my understanding there is no way to express=20 >what you are talking about below in a civic representation, so=20 >I am wondering how you plan to express it in the forms that we=20 >currently have. > >Cheers >James > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf >Of >> James M. Polk >> Sent: Friday, 23 December 2005 11:32 AM >> To: Roger Marshall >> Cc: ecrit@ietf.org >> Subject: RE: [Ecrit] Issue 22: 3D of location >>=20 >> Roger >>=20 >> I'm glad you brought this up. I agree that the altitude dimension >should >> be >> addressed. I think we ought to consider that any x.y is only as good >as >> it's datum. I think this applies to the z coordinate as well. >>=20 >> So, just as you define latitude and longitude (N/S of equator or E/W >from >> prime meridian), we might want to state Altitude is above or below >what is >> considered zero altitude, knowing this may be different in many=20 >> situations. >>=20 >> There's: >>=20 >> - mean sea level >> - mean low tide >> - mean lowest low tide >> - mean high tide >> - pressure altitude (flight level) >> - absolute altitude (above a ground reference point) >> - true altitude (above mean sea level - which doesn't really work >inland) >>=20 >> I don't mean to make this complicated, but we can say that=20 >altitude is=20 >> above or below some "known reference", be it the ground, or mean sea=20 >> level, or whatever. >>=20 >> I also agree that this ought to be a "...MAY be included..." - which >means >> a recipient must be prepared to receive this information,=20 >even if not=20 >> acting on it. >>=20 >>=20 >> At 02:21 PM 12/22/2005 -0800, Roger Marshall wrote: >> >Issue 22: Missing requirement for 3D in location. >> > >> >Rohan added this point to the tracker, based on the last IETF mtg. >> > >> >...from the issue tracker: http://www.ietf-ecrit.org:8080/ecrit-req/ >> > >> >22. Author: rohan Date: 2005-11-07.22:21:27 Sometimes 2D location=20 >> >information is insufficient to send help (for example, ina large=20 >> >office building). Where provided in civic or geo formats, >there >> >is a >> >requirement to get 3D information in some locations. Also in the=20 >> >terminology section the definition of "location" is 2D-limited. >> > >> >Rohan brings up a valid point, so consider the following suggested >text, >> >in order to try to satisfy the proposed requirement: >> > >> > >> >NEW REQUIREMENT: >> >Lo-x. 3D Location: The third dimension of a location MAY=20 >be included=20 >> >(e.g. altitude, floor, etc.) within the mapping protocol,=20 >in addition >to >> >its base (two dimensional georaphic, or civic street-type) location=20 >> >information. >> > >> >Motivation: This may be helpful for emergency responders when an=20 >> >emergency request is made from an upper floor, tower, or=20 >subterranean=20 >> >position. >> > >> > >> >If everyone likes this, then we should also change the definition >> >(slightly) in the case of the term, location, in order to=20 >include 3D=20 >> >examples (as is shown in the text below): >> > >> >location: A geographic identification assigned to a region=20 >or feature=20 >> >based on a specific coordinate system, or by other precise=20 >> >information such as a street number and name (and possibly, floor). >In >> >the geocoding process, the location is defined with an x,y (and=20 >> >potentially, z) coordinate value according to the distance north or=20 >> >south of the equator and east or west of the prime meridian. >> > >> > >> >Please comment if objectionable. >> > >> >Roger Marshall. >> > >> > >> > >> > >> > >> >_______________________________________________ >> >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 > >--------------------------------------------------------------- >--------------------------------- >This message is for the designated recipient only and may=20 >contain privileged, proprietary, or otherwise private information. =20 >If you have received it in error, please notify the sender=20 >immediately and delete the original. Any unauthorized use of=20 >this email is prohibited. >--------------------------------------------------------------- >--------------------------------- >[mf2] > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 28 10:08:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ercun-00031B-V6; Wed, 28 Dec 2005 10:08:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ercum-00030u-KT for ecrit@megatron.ietf.org; Wed, 28 Dec 2005 10:08:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16353 for ; Wed, 28 Dec 2005 10:07:22 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ercyq-0002Kh-3n for ecrit@ietf.org; Wed, 28 Dec 2005 10:12:44 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Ercuq-0006Dy-Nc; Wed, 28 Dec 2005 09:08:37 -0600 From: "Brian Rosen" To: "'Roger Marshall'" , "'Winterbottom, James'" , "'James M. Polk'" Subject: RE: [Ecrit] Issue 22: 3D of location Date: Wed, 28 Dec 2005 10:05:32 -0500 Message-ID: <014701c60bc0$296b92e0$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 In-Reply-To: <8C837214C95C864C9F34F3635C2A657503DD6AB7@SEA-EXCHVS-2.telecomsys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYHWKG3JxJZGL3sRJm3GeLqx0VCWQAAjgLwAPhjG/AAIKmBMA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Saying "may be included" is not sufficient. The behavior of the protocol has to be defined to be 3D (that is, you may get a different mapping with one "height" value, than you do with another), and the protocol has to define what happens if you omit the 3rd dimension on a query. So: The mapping protocol must be defined to be a 3D sensitive mapping. The protocol must accept a 2D or 3D mapping request and return a reasonable result when only 2 dimensions are presented. The protocol provisioning systems must accept both 2D and 3D data. When a 3D request is presented to an area only defined by 2D data, the mapping result shall be the same as if the height/altitude dimension was omitted on the request. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Tuesday, December 27, 2005 6:38 PM To: Winterbottom, James; James M. Polk Cc: ecrit@ietf.org Subject: RE: [Ecrit] Issue 22: 3D of location James (W): Indeed we have a requirement for WG84, and it reads: "Lo3. Reference Datum: The mapping server MUST understand WGS-84 coordinate reference system and may understand other reference systems." Making reference to WGS-84 alone doesn't imply 3D to the implementer of the mapping protocol. Proof of that is today's current wireless, which refers to surveyed points as wgs-84, but almost never includes the third coordinate in a resultant position set. What is not explicity mentioned already in the req. draft is the language that states that sending 3-D is OK (as is sending 2-D without having the third dimension). In order to say that each form is acceptable (2D or 3D for either civic or geo, despite which CRS used), I have suggested the added requirement: "Lo-x. 3D Location: The third dimension of a location MAY be included (e.g. altitude, floor, etc.) within the mapping protocol, in addition to its base (two dimensional geographic, or civic street-type) location information." Comments, anyone? Roger Marshall. >-----Original Message----- >From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] >Sent: Thursday, December 22, 2005 4:52 PM >To: James M. Polk; Roger Marshall >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] Issue 22: 3D of location > >I was under the impression that WGS-84 had already been agreed >to as the MUST be supported CRS. This includes what an >altitude is. To my understanding there is no way to express >what you are talking about below in a civic representation, so >I am wondering how you plan to express it in the forms that we >currently have. > >Cheers >James > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >Of >> James M. Polk >> Sent: Friday, 23 December 2005 11:32 AM >> To: Roger Marshall >> Cc: ecrit@ietf.org >> Subject: RE: [Ecrit] Issue 22: 3D of location >> >> Roger >> >> I'm glad you brought this up. I agree that the altitude dimension >should >> be >> addressed. I think we ought to consider that any x.y is only as good >as >> it's datum. I think this applies to the z coordinate as well. >> >> So, just as you define latitude and longitude (N/S of equator or E/W >from >> prime meridian), we might want to state Altitude is above or below >what is >> considered zero altitude, knowing this may be different in many >> situations. >> >> There's: >> >> - mean sea level >> - mean low tide >> - mean lowest low tide >> - mean high tide >> - pressure altitude (flight level) >> - absolute altitude (above a ground reference point) >> - true altitude (above mean sea level - which doesn't really work >inland) >> >> I don't mean to make this complicated, but we can say that >altitude is >> above or below some "known reference", be it the ground, or mean sea >> level, or whatever. >> >> I also agree that this ought to be a "...MAY be included..." - which >means >> a recipient must be prepared to receive this information, >even if not >> acting on it. >> >> >> At 02:21 PM 12/22/2005 -0800, Roger Marshall wrote: >> >Issue 22: Missing requirement for 3D in location. >> > >> >Rohan added this point to the tracker, based on the last IETF mtg. >> > >> >...from the issue tracker: http://www.ietf-ecrit.org:8080/ecrit-req/ >> > >> >22. Author: rohan Date: 2005-11-07.22:21:27 Sometimes 2D location >> >information is insufficient to send help (for example, ina large >> >office building). Where provided in civic or geo formats, >there >> >is a >> >requirement to get 3D information in some locations. Also in the >> >terminology section the definition of "location" is 2D-limited. >> > >> >Rohan brings up a valid point, so consider the following suggested >text, >> >in order to try to satisfy the proposed requirement: >> > >> > >> >NEW REQUIREMENT: >> >Lo-x. 3D Location: The third dimension of a location MAY >be included >> >(e.g. altitude, floor, etc.) within the mapping protocol, >in addition >to >> >its base (two dimensional georaphic, or civic street-type) location >> >information. >> > >> >Motivation: This may be helpful for emergency responders when an >> >emergency request is made from an upper floor, tower, or >subterranean >> >position. >> > >> > >> >If everyone likes this, then we should also change the definition >> >(slightly) in the case of the term, location, in order to >include 3D >> >examples (as is shown in the text below): >> > >> >location: A geographic identification assigned to a region >or feature >> >based on a specific coordinate system, or by other precise >> >information such as a street number and name (and possibly, floor). >In >> >the geocoding process, the location is defined with an x,y (and >> >potentially, z) coordinate value according to the distance north or >> >south of the equator and east or west of the prime meridian. >> > >> > >> >Please comment if objectionable. >> > >> >Roger Marshall. >> > >> > >> > >> > >> > >> >_______________________________________________ >> >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 > >--------------------------------------------------------------- >--------------------------------- >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 Dec 28 14:20:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ergqq-0005we-8K; Wed, 28 Dec 2005 14:20:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ergql-0005wM-Ny for ecrit@megatron.ietf.org; Wed, 28 Dec 2005 14:20:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28210 for ; Wed, 28 Dec 2005 14:19:28 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ergup-0007Ha-En for ecrit@ietf.org; Wed, 28 Dec 2005 14:24:54 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 28 Dec 2005 14:20:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Issue 22: 3D of location Date: Wed, 28 Dec 2005 11:20:18 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657503DD6E18@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Issue 22: 3D of location Thread-Index: AcYHWKG3JxJZGL3sRJm3GeLqx0VCWQAAjgLwAPhjG/AAIKmBMAAIwZmA From: "Roger Marshall" To: , "Winterbottom, James" , "James M. Polk" X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian: I like the ideas you've conveyed below. I've included some replacement text below, in which I've tried to capture your thoughts: Change FROM: "Lo-x. 3D Location: The third dimension of a location MAY be=20 included (e.g. altitude, floor, etc.) within the mapping protocol, in=20 addition to its base (two dimensional geographic, or civic=20 street-type) location information." Change TO: "Lo-x. 3D Sensitive Mapping: The mapping protocol MUST accept=20 either a 2D or 3D mapping request, and return an appropriate=20 result, based on which type of input is used." "Motivation: It is expected that provisioning systems will accept=20 both 2D and 3D data. When a 3D request is presented to an area=20 only defined by 2D data, the mapping result would be the same as=20 if the height/altitude dimension was omitted on the request." Roger Marshall. >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net]=20 >Sent: Wednesday, December 28, 2005 7:06 AM >To: Roger Marshall; 'Winterbottom, James'; 'James M. Polk' >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] Issue 22: 3D of location > >Saying "may be included" is not sufficient. The behavior of=20 >the protocol has to be defined to be 3D (that is, you may get=20 >a different mapping with one "height" value, than you do with=20 >another), and the protocol has to define what happens if you=20 >omit the 3rd dimension on a query. > >So: >The mapping protocol must be defined to be a 3D sensitive mapping. =20 > >The protocol must accept a 2D or 3D mapping request and return=20 >a reasonable result when only 2 dimensions are presented. > >The protocol provisioning systems must accept both 2D and 3D=20 >data. When a 3D request is presented to an area only defined=20 >by 2D data, the mapping result shall be the same as if the=20 >height/altitude dimension was omitted on the request.=20 > > > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Roger Marshall >Sent: Tuesday, December 27, 2005 6:38 PM >To: Winterbottom, James; James M. Polk >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] Issue 22: 3D of location > >James (W):=20 >Indeed we have a requirement for WG84, and it reads:=20 > >"Lo3. Reference Datum: The mapping server MUST understand=20 >WGS-84 coordinate reference system and may understand other=20 >reference systems." > >Making reference to WGS-84 alone doesn't imply 3D to the=20 >implementer of the mapping protocol. Proof of that is today's=20 >current wireless, which refers to surveyed points as wgs-84,=20 >but almost never includes the third coordinate in a resultant=20 >position set. What is not explicity mentioned already in the=20 >req. draft is the language that states that sending 3-D is OK=20 >(as is sending 2-D without having the third dimension). In=20 >order to say that each form is acceptable (2D or 3D for either=20 >civic or geo, despite which CRS used), I have suggested the=20 >added requirement:=20 > >"Lo-x. 3D Location: The third dimension of a location MAY be=20 >included (e.g. altitude, floor, etc.) within the mapping protocol, in > >addition to its base (two dimensional geographic, or civic=20 >street-type) location information." > >Comments, anyone? > >Roger Marshall. > > > > >>-----Original Message----- >>From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] >>Sent: Thursday, December 22, 2005 4:52 PM >>To: James M. Polk; Roger Marshall >>Cc: ecrit@ietf.org >>Subject: RE: [Ecrit] Issue 22: 3D of location >> >>I was under the impression that WGS-84 had already been agreed to as=20 >>the MUST be supported CRS. This includes what an altitude is. To my=20 >>understanding there is no way to express what you are talking about=20 >>below in a civic representation, so I am wondering how you plan to=20 >>express it in the forms that we currently have. >> >>Cheers >>James >> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>On Behalf >>Of >>> James M. Polk >>> Sent: Friday, 23 December 2005 11:32 AM >>> To: Roger Marshall >>> Cc: ecrit@ietf.org >>> Subject: RE: [Ecrit] Issue 22: 3D of location >>>=20 >>> Roger >>>=20 >>> I'm glad you brought this up. I agree that the altitude dimension >>should >>> be >>> addressed. I think we ought to consider that any x.y is only as good >>as >>> it's datum. I think this applies to the z coordinate as well. >>>=20 >>> So, just as you define latitude and longitude (N/S of equator or E/W >>from >>> prime meridian), we might want to state Altitude is above or below >>what is >>> considered zero altitude, knowing this may be different in many=20 >>> situations. >>>=20 >>> There's: >>>=20 >>> - mean sea level >>> - mean low tide >>> - mean lowest low tide >>> - mean high tide >>> - pressure altitude (flight level) >>> - absolute altitude (above a ground reference point) >>> - true altitude (above mean sea level - which doesn't really work >>inland) >>>=20 >>> I don't mean to make this complicated, but we can say that >>altitude is >>> above or below some "known reference", be it the ground, or=20 >mean sea=20 >>> level, or whatever. >>>=20 >>> I also agree that this ought to be a "...MAY be included..." - which >>means >>> a recipient must be prepared to receive this information, >>even if not >>> acting on it. >>>=20 >>>=20 >>> At 02:21 PM 12/22/2005 -0800, Roger Marshall wrote: >>> >Issue 22: Missing requirement for 3D in location. >>> > >>> >Rohan added this point to the tracker, based on the last IETF mtg. >>> > >>> >...from the issue tracker:=20 >http://www.ietf-ecrit.org:8080/ecrit-req/ >>> > >>> >22. Author: rohan Date: 2005-11-07.22:21:27 Sometimes 2D location=20 >>> >information is insufficient to send help (for example, ina large=20 >>> >office building). Where provided in civic or geo formats, >>there >>> >is a >>> >requirement to get 3D information in some locations. Also in the=20 >>> >terminology section the definition of "location" is 2D-limited. >>> > >>> >Rohan brings up a valid point, so consider the following suggested >>text, >>> >in order to try to satisfy the proposed requirement: >>> > >>> > >>> >NEW REQUIREMENT: >>> >Lo-x. 3D Location: The third dimension of a location MAY >>be included >>> >(e.g. altitude, floor, etc.) within the mapping protocol, >>in addition >>to >>> >its base (two dimensional georaphic, or civic street-type)=20 >location=20 >>> >information. >>> > >>> >Motivation: This may be helpful for emergency responders when an=20 >>> >emergency request is made from an upper floor, tower, or >>subterranean >>> >position. >>> > >>> > >>> >If everyone likes this, then we should also change the definition >>> >(slightly) in the case of the term, location, in order to >>include 3D >>> >examples (as is shown in the text below): >>> > >>> >location: A geographic identification assigned to a region >>or feature >>> >based on a specific coordinate system, or by other precise=20 >>> >information such as a street number and name (and possibly, floor). >>In >>> >the geocoding process, the location is defined with an x,y (and=20 >>> >potentially, z) coordinate value according to the distance=20 >north or=20 >>> >south of the equator and east or west of the prime meridian. >>> > >>> > >>> >Please comment if objectionable. >>> > >>> >Roger Marshall. >>> > >>> > >>> > >>> > >>> > >>> >_______________________________________________ >>> >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 >> >>--------------------------------------------------------------- >>--------------------------------- >>This message is for the designated recipient only and may contain=20 >>privileged, proprietary, or otherwise private information. >>If you have received it in error, please notify the sender=20 >immediately=20 >>and delete the original. Any unauthorized use of this email is=20 >>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 Dec 28 14:33:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erh2w-0000TU-7q; Wed, 28 Dec 2005 14:33:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erh2u-0000TP-AE for ecrit@megatron.ietf.org; Wed, 28 Dec 2005 14:33:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29590 for ; Wed, 28 Dec 2005 14:32:00 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Erh6y-0007jG-4x for ecrit@ietf.org; Wed, 28 Dec 2005 14:37:26 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Erh2u-0004hc-9f; Wed, 28 Dec 2005 13:33:12 -0600 From: "Brian Rosen" To: "'Roger Marshall'" , "'Winterbottom, James'" , "'James M. Polk'" Subject: RE: [Ecrit] Issue 22: 3D of location Date: Wed, 28 Dec 2005 14:31:12 -0500 Message-ID: <023301c60be5$45687dd0$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 In-Reply-To: <8C837214C95C864C9F34F3635C2A657503DD6E18@SEA-EXCHVS-2.telecomsys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYHWKG3JxJZGL3sRJm3GeLqx0VCWQAAjgLwAPhjG/AAIKmBMAAIwZmAAAC9RVA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Well, generally I don't like the motivation defining requirements (provisioning system accepts both 2D and 3D), but it's okay. Certainly, anyone reading it will understand the intent completely, and that is what matters. Brian -----Original Message----- From: Roger Marshall [mailto:RMarshall@telecomsys.com] Sent: Wednesday, December 28, 2005 2:20 PM To: br@brianrosen.net; Winterbottom, James; James M. Polk Cc: ecrit@ietf.org Subject: RE: [Ecrit] Issue 22: 3D of location Brian: I like the ideas you've conveyed below. I've included some replacement text below, in which I've tried to capture your thoughts: Change FROM: "Lo-x. 3D Location: The third dimension of a location MAY be included (e.g. altitude, floor, etc.) within the mapping protocol, in addition to its base (two dimensional geographic, or civic street-type) location information." Change TO: "Lo-x. 3D Sensitive Mapping: The mapping protocol MUST accept either a 2D or 3D mapping request, and return an appropriate result, based on which type of input is used." "Motivation: It is expected that provisioning systems will accept both 2D and 3D data. When a 3D request is presented to an area only defined by 2D data, the mapping result would be the same as if the height/altitude dimension was omitted on the request." Roger Marshall. >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net] >Sent: Wednesday, December 28, 2005 7:06 AM >To: Roger Marshall; 'Winterbottom, James'; 'James M. Polk' >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] Issue 22: 3D of location > >Saying "may be included" is not sufficient. The behavior of >the protocol has to be defined to be 3D (that is, you may get >a different mapping with one "height" value, than you do with >another), and the protocol has to define what happens if you >omit the 3rd dimension on a query. > >So: >The mapping protocol must be defined to be a 3D sensitive mapping. > >The protocol must accept a 2D or 3D mapping request and return >a reasonable result when only 2 dimensions are presented. > >The protocol provisioning systems must accept both 2D and 3D >data. When a 3D request is presented to an area only defined >by 2D data, the mapping result shall be the same as if the >height/altitude dimension was omitted on the request. > > > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Roger Marshall >Sent: Tuesday, December 27, 2005 6:38 PM >To: Winterbottom, James; James M. Polk >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] Issue 22: 3D of location > >James (W): >Indeed we have a requirement for WG84, and it reads: > >"Lo3. Reference Datum: The mapping server MUST understand >WGS-84 coordinate reference system and may understand other >reference systems." > >Making reference to WGS-84 alone doesn't imply 3D to the >implementer of the mapping protocol. Proof of that is today's >current wireless, which refers to surveyed points as wgs-84, >but almost never includes the third coordinate in a resultant >position set. What is not explicity mentioned already in the >req. draft is the language that states that sending 3-D is OK >(as is sending 2-D without having the third dimension). In >order to say that each form is acceptable (2D or 3D for either >civic or geo, despite which CRS used), I have suggested the >added requirement: > >"Lo-x. 3D Location: The third dimension of a location MAY be >included (e.g. altitude, floor, etc.) within the mapping protocol, in > >addition to its base (two dimensional geographic, or civic >street-type) location information." > >Comments, anyone? > >Roger Marshall. > > > > >>-----Original Message----- >>From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] >>Sent: Thursday, December 22, 2005 4:52 PM >>To: James M. Polk; Roger Marshall >>Cc: ecrit@ietf.org >>Subject: RE: [Ecrit] Issue 22: 3D of location >> >>I was under the impression that WGS-84 had already been agreed to as >>the MUST be supported CRS. This includes what an altitude is. To my >>understanding there is no way to express what you are talking about >>below in a civic representation, so I am wondering how you plan to >>express it in the forms that we currently have. >> >>Cheers >>James >> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>On Behalf >>Of >>> James M. Polk >>> Sent: Friday, 23 December 2005 11:32 AM >>> To: Roger Marshall >>> Cc: ecrit@ietf.org >>> Subject: RE: [Ecrit] Issue 22: 3D of location >>> >>> Roger >>> >>> I'm glad you brought this up. I agree that the altitude dimension >>should >>> be >>> addressed. I think we ought to consider that any x.y is only as good >>as >>> it's datum. I think this applies to the z coordinate as well. >>> >>> So, just as you define latitude and longitude (N/S of equator or E/W >>from >>> prime meridian), we might want to state Altitude is above or below >>what is >>> considered zero altitude, knowing this may be different in many >>> situations. >>> >>> There's: >>> >>> - mean sea level >>> - mean low tide >>> - mean lowest low tide >>> - mean high tide >>> - pressure altitude (flight level) >>> - absolute altitude (above a ground reference point) >>> - true altitude (above mean sea level - which doesn't really work >>inland) >>> >>> I don't mean to make this complicated, but we can say that >>altitude is >>> above or below some "known reference", be it the ground, or >mean sea >>> level, or whatever. >>> >>> I also agree that this ought to be a "...MAY be included..." - which >>means >>> a recipient must be prepared to receive this information, >>even if not >>> acting on it. >>> >>> >>> At 02:21 PM 12/22/2005 -0800, Roger Marshall wrote: >>> >Issue 22: Missing requirement for 3D in location. >>> > >>> >Rohan added this point to the tracker, based on the last IETF mtg. >>> > >>> >...from the issue tracker: >http://www.ietf-ecrit.org:8080/ecrit-req/ >>> > >>> >22. Author: rohan Date: 2005-11-07.22:21:27 Sometimes 2D location >>> >information is insufficient to send help (for example, ina large >>> >office building). Where provided in civic or geo formats, >>there >>> >is a >>> >requirement to get 3D information in some locations. Also in the >>> >terminology section the definition of "location" is 2D-limited. >>> > >>> >Rohan brings up a valid point, so consider the following suggested >>text, >>> >in order to try to satisfy the proposed requirement: >>> > >>> > >>> >NEW REQUIREMENT: >>> >Lo-x. 3D Location: The third dimension of a location MAY >>be included >>> >(e.g. altitude, floor, etc.) within the mapping protocol, >>in addition >>to >>> >its base (two dimensional georaphic, or civic street-type) >location >>> >information. >>> > >>> >Motivation: This may be helpful for emergency responders when an >>> >emergency request is made from an upper floor, tower, or >>subterranean >>> >position. >>> > >>> > >>> >If everyone likes this, then we should also change the definition >>> >(slightly) in the case of the term, location, in order to >>include 3D >>> >examples (as is shown in the text below): >>> > >>> >location: A geographic identification assigned to a region >>or feature >>> >based on a specific coordinate system, or by other precise >>> >information such as a street number and name (and possibly, floor). >>In >>> >the geocoding process, the location is defined with an x,y (and >>> >potentially, z) coordinate value according to the distance >north or >>> >south of the equator and east or west of the prime meridian. >>> > >>> > >>> >Please comment if objectionable. >>> > >>> >Roger Marshall. >>> > >>> > >>> > >>> > >>> > >>> >_______________________________________________ >>> >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 >> >>--------------------------------------------------------------- >>--------------------------------- >>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 Dec 28 14:38:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erh7v-0001Ll-Uz; Wed, 28 Dec 2005 14:38:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erh7u-0001KM-9A for ecrit@megatron.ietf.org; Wed, 28 Dec 2005 14:38:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29899 for ; Wed, 28 Dec 2005 14:37:11 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErhC0-0007sL-BY for ecrit@ietf.org; Wed, 28 Dec 2005 14:42:37 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 28 Dec 2005 14:38:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Issue 22: 3D of location Date: Wed, 28 Dec 2005 11:38:11 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657503DD6E48@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Issue 22: 3D of location Thread-Index: AcYHWKG3JxJZGL3sRJm3GeLqx0VCWQAAjgLwAPhjG/AAIKmBMAAIwZmAAAC9RVAAACei0A== From: "Roger Marshall" To: , "Winterbottom, James" , "James M. Polk" X-Spam-Score: 0.0 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org That's right. It's the reason why I reworded your text to read "expected that", but doesn't say "MUST provision", etc. Roger. >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net]=20 >Sent: Wednesday, December 28, 2005 11:31 AM >To: Roger Marshall; 'Winterbottom, James'; 'James M. Polk' >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] Issue 22: 3D of location > >Well, generally I don't like the motivation defining=20 >requirements (provisioning system accepts both 2D and 3D), but=20 >it's okay. Certainly, anyone reading it will understand the=20 >intent completely, and that is what matters. > >Brian > >-----Original Message----- >From: Roger Marshall [mailto:RMarshall@telecomsys.com] >Sent: Wednesday, December 28, 2005 2:20 PM >To: br@brianrosen.net; Winterbottom, James; James M. Polk >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] Issue 22: 3D of location > >Brian: >I like the ideas you've conveyed below. I've included some=20 >replacement text below, in which I've tried to capture your thoughts: > >Change FROM: >"Lo-x. 3D Location: The third dimension of a location MAY be=20 >included (e.g. altitude, floor, etc.) within the mapping=20 >protocol, in addition to its base (two dimensional geographic, or civic >street-type) location information." > >Change TO: >"Lo-x. 3D Sensitive Mapping: The mapping protocol MUST=20 >accept either a 2D or 3D mapping request, and return an=20 >appropriate result, based on which type of input is used." > >"Motivation: It is expected that provisioning systems will=20 >accept both 2D and 3D data. When a 3D request is presented to=20 >an area only defined by 2D data, the mapping result would be=20 >the same as if the height/altitude dimension was omitted on=20 >the request." > > >Roger Marshall. > >>-----Original Message----- >>From: Brian Rosen [mailto:br@brianrosen.net] >>Sent: Wednesday, December 28, 2005 7:06 AM >>To: Roger Marshall; 'Winterbottom, James'; 'James M. Polk' >>Cc: ecrit@ietf.org >>Subject: RE: [Ecrit] Issue 22: 3D of location >> >>Saying "may be included" is not sufficient. The behavior of the=20 >>protocol has to be defined to be 3D (that is, you may get a different=20 >>mapping with one "height" value, than you do with another), and the=20 >>protocol has to define what happens if you omit the 3rd=20 >dimension on a=20 >>query. >> >>So: >>The mapping protocol must be defined to be a 3D sensitive mapping. =20 >> >>The protocol must accept a 2D or 3D mapping request and return a=20 >>reasonable result when only 2 dimensions are presented. >> >>The protocol provisioning systems must accept both 2D and 3D data. =20 >>When a 3D request is presented to an area only defined by 2D=20 >data, the=20 >>mapping result shall be the same as if the height/altitude dimension=20 >>was omitted on the request. >> >> >> >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf=20 >>Of Roger Marshall >>Sent: Tuesday, December 27, 2005 6:38 PM >>To: Winterbottom, James; James M. Polk >>Cc: ecrit@ietf.org >>Subject: RE: [Ecrit] Issue 22: 3D of location >> >>James (W):=20 >>Indeed we have a requirement for WG84, and it reads:=20 >> >>"Lo3. Reference Datum: The mapping server MUST understand >>WGS-84 coordinate reference system and may understand other reference=20 >>systems." >> >>Making reference to WGS-84 alone doesn't imply 3D to the=20 >implementer of=20 >>the mapping protocol. Proof of that is today's current=20 >wireless, which=20 >>refers to surveyed points as wgs-84, but almost never includes the=20 >>third coordinate in a resultant position set. What is not explicity=20 >>mentioned already in the req. draft is the language that states that=20 >>sending 3-D is OK (as is sending 2-D without having the third=20 >>dimension). In order to say that each form is acceptable (2D=20 >or 3D for=20 >>either civic or geo, despite which CRS used), I have suggested the=20 >>added requirement: >> >>"Lo-x. 3D Location: The third dimension of a location MAY=20 >be included=20 >>(e.g. altitude, floor, etc.) within the mapping protocol, in >> >>addition to its base (two dimensional geographic, or civic >>street-type) location information." >> >>Comments, anyone? >> >>Roger Marshall. >> >> >> >> >>>-----Original Message----- >>>From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] >>>Sent: Thursday, December 22, 2005 4:52 PM >>>To: James M. Polk; Roger Marshall >>>Cc: ecrit@ietf.org >>>Subject: RE: [Ecrit] Issue 22: 3D of location >>> >>>I was under the impression that WGS-84 had already been agreed to as=20 >>>the MUST be supported CRS. This includes what an altitude is. To my=20 >>>understanding there is no way to express what you are talking about=20 >>>below in a civic representation, so I am wondering how you plan to=20 >>>express it in the forms that we currently have. >>> >>>Cheers >>>James >>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>On Behalf >>>Of >>>> James M. Polk >>>> Sent: Friday, 23 December 2005 11:32 AM >>>> To: Roger Marshall >>>> Cc: ecrit@ietf.org >>>> Subject: RE: [Ecrit] Issue 22: 3D of location >>>>=20 >>>> Roger >>>>=20 >>>> I'm glad you brought this up. I agree that the altitude dimension >>>should >>>> be >>>> addressed. I think we ought to consider that any x.y is=20 >only as good >>>as >>>> it's datum. I think this applies to the z coordinate as well. >>>>=20 >>>> So, just as you define latitude and longitude (N/S of=20 >equator or E/W >>>from >>>> prime meridian), we might want to state Altitude is above or below >>>what is >>>> considered zero altitude, knowing this may be different in many=20 >>>> situations. >>>>=20 >>>> There's: >>>>=20 >>>> - mean sea level >>>> - mean low tide >>>> - mean lowest low tide >>>> - mean high tide >>>> - pressure altitude (flight level) >>>> - absolute altitude (above a ground reference point) >>>> - true altitude (above mean sea level - which doesn't really work >>>inland) >>>>=20 >>>> I don't mean to make this complicated, but we can say that >>>altitude is >>>> above or below some "known reference", be it the ground, or >>mean sea >>>> level, or whatever. >>>>=20 >>>> I also agree that this ought to be a "...MAY be=20 >included..." - which >>>means >>>> a recipient must be prepared to receive this information, >>>even if not >>>> acting on it. >>>>=20 >>>>=20 >>>> At 02:21 PM 12/22/2005 -0800, Roger Marshall wrote: >>>> >Issue 22: Missing requirement for 3D in location. >>>> > >>>> >Rohan added this point to the tracker, based on the last IETF mtg. >>>> > >>>> >...from the issue tracker:=20 >>http://www.ietf-ecrit.org:8080/ecrit-req/ >>>> > >>>> >22. Author: rohan Date: 2005-11-07.22:21:27 Sometimes 2D location=20 >>>> >information is insufficient to send help (for example, ina large=20 >>>> >office building). Where provided in civic or geo formats, >>>there >>>> >is a >>>> >requirement to get 3D information in some locations. Also in the=20 >>>> >terminology section the definition of "location" is 2D-limited. >>>> > >>>> >Rohan brings up a valid point, so consider the following suggested >>>text, >>>> >in order to try to satisfy the proposed requirement: >>>> > >>>> > >>>> >NEW REQUIREMENT: >>>> >Lo-x. 3D Location: The third dimension of a location MAY >>>be included >>>> >(e.g. altitude, floor, etc.) within the mapping protocol, >>>in addition >>>to >>>> >its base (two dimensional georaphic, or civic street-type) >>location >>>> >information. >>>> > >>>> >Motivation: This may be helpful for emergency responders when an=20 >>>> >emergency request is made from an upper floor, tower, or >>>subterranean >>>> >position. >>>> > >>>> > >>>> >If everyone likes this, then we should also change the definition >>>> >(slightly) in the case of the term, location, in order to >>>include 3D >>>> >examples (as is shown in the text below): >>>> > >>>> >location: A geographic identification assigned to a region >>>or feature >>>> >based on a specific coordinate system, or by other precise=20 >>>> >information such as a street number and name (and=20 >possibly, floor). >>>In >>>> >the geocoding process, the location is defined with an x,y (and=20 >>>> >potentially, z) coordinate value according to the distance >>north or >>>> >south of the equator and east or west of the prime meridian. >>>> > >>>> > >>>> >Please comment if objectionable. >>>> > >>>> >Roger Marshall. >>>> > >>>> > >>>> > >>>> > >>>> > >>>> >_______________________________________________ >>>> >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 >>> >>>--------------------------------------------------------------- >>>--------------------------------- >>>This message is for the designated recipient only and may contain=20 >>>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=20 >>>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 Dec 28 19:20:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErlWr-00047c-3E; Wed, 28 Dec 2005 19:20:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErlWp-00047L-4J for ecrit@megatron.ietf.org; Wed, 28 Dec 2005 19:20:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09839 for ; Wed, 28 Dec 2005 19:19:11 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Erlat-00041o-Bz for ecrit@ietf.org; Wed, 28 Dec 2005 19:24:36 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 28 Dec 2005 19:20:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Issue 10: Design of Non-Emergency Components Date: Wed, 28 Dec 2005 16:20:00 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657503DD7125@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Issue 10: Design of Non-Emergency Components Thread-Index: AcYHWKG3JxJZGL3sRJm3GeLqx0VCWQAAjgLwAPhjG/AAIKmBMAAJXmCA From: "Roger Marshall" To: "Andrew Newton" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Andy: Issue 10: Design of Non-Emergency Components (http://www.ietf-ecrit.org:8080/ecrit-req/issue10) "There are no requirements regarding the resilience of the emergency call routing=20 process as it relates to inputs that have not been designed for the purpose of=20 emergency call routing." I'm not exactly sure what this issue is getting at... a couple of thoughts,=20 1. are we talking about resilience against inadvertant or on-purpose mis-use, (in which case it seems like a security concern), or=20 2. do you mean, that the MP should be resilient in order to support other types of use, besides just emergency use? Thanks. Roger Marshall. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 28 19:39:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erlp9-00025a-8X; Wed, 28 Dec 2005 19:39:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erlp7-00025V-Pa for ecrit@megatron.ietf.org; Wed, 28 Dec 2005 19:39:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11511 for ; Wed, 28 Dec 2005 19:38:06 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErltF-0004Zk-Kt for ecrit@ietf.org; Wed, 28 Dec 2005 19:43:35 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 28 Dec 2005 19:39:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Dec 2005 16:39:06 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657503DD714F@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [issue21] Re7 (Relays): Propose eliminating relays by requiring PSAP to support all reasonable modes Thread-Index: AcXj6FvEgh68So4TR4yCFunKpbCUfAoJyxGA From: "Roger Marshall" To: , "Rohan Mahy" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating relays by requiring PSAP to support all reasonable modes 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Rohan: Currently, we've still got the following requirement, but no discussion that I've seen on the request to delete it, nor any other discussion of how this would work. "Re7. Relay Services: It SHOULD be possible to involve=20 relay services in the call for translation between different modes." "Motivation: It should be possible to connect the relay service so that=20 the direct flow of media to the emergency service is maintained. In=20 addition, it should be possible to convey telemetry data, such as data=20 from automobile crash sensors." Is there any objection (comments from the list) to removing this requirement as suggested? Roger Marshall >-----Original Message----- >From: Rohan Mahy [mailto:hannes.tschofenig@siemens.com]=20 >Sent: Monday, November 07, 2005 2:09 PM >To: Roger Marshall >Subject: [issue21] Re7 (Relays): Propose eliminating relays by=20 >requiring PSAP to support all reasonable modes > > >New submission from Rohan Mahy : > >Relays are required in Re7, but not really well motivated. If=20 >the PSAP needs to accept "calls" in all the modes listed=20 >(voice, video, text chat, and IM), then I don't think we need=20 >relays. Eliminating relays would simplify the architecture,=20 >especially wrt to security. > >---------- >assignedto: roger >messages: 34 >nosy: roger, rohan >priority: urgent >status: unread >title: Re7 (Relays): Propose eliminating relays by requiring=20 >PSAP to support all reasonable modes > >________________________________________________________ >ECRIT Requirements Draft =20 > >________________________________________________________ > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 28 19:46:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erlvv-00042j-VX; Wed, 28 Dec 2005 19:46:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erlvu-00042b-Dn for ecrit@megatron.ietf.org; Wed, 28 Dec 2005 19:46:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12297 for ; Wed, 28 Dec 2005 19:45:07 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Erm03-0004oN-L3 for ecrit@ietf.org; Wed, 28 Dec 2005 19:50:35 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Dec 2005 18:45:59 -0600 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 28 Dec 2005 18:45:58 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Dec 2005 18:45:57 -0600 Message-ID: From: "Winterbottom, James" To: "Roger Marshall" , , "Rohan Mahy" Date: Wed, 28 Dec 2005 18:45:55 -0600 Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating relays byrequiring PSAP to support all reasonable modes MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 29 Dec 2005 00:45:57.0910 (UTC) FILETIME=[3B83AB60:01C60C11] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating relays byrequiring PSAP to support all reasonable modes thread-index: AcXj6FvEgh68So4TR4yCFunKpbCUfAoJyxGAAABUpSA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I am not sure why this has to be a relay function. Surely the motivation is more: " It should be possible to establish a direct flow of media to the emergency service. In addition, it should be possible to convey telemetry data, such as data from automobile crash sensors." Relay implies an architectural solution. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Roger Marshall > Sent: Thursday, 29 December 2005 11:39 AM > To: ecrit@ietf.org; Rohan Mahy > Subject: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating relays > byrequiring PSAP to support all reasonable modes >=20 > Rohan: > Currently, we've still got the following requirement, but no discussion > that I've seen on the request to delete it, nor any other discussion of > how this would work. >=20 > "Re7. Relay Services: It SHOULD be possible to involve > relay services in the call for translation between different modes." >=20 > "Motivation: It should be possible to connect the relay service so that > the direct flow of media to the emergency service is maintained. In > addition, it should be possible to convey telemetry data, such as data > from automobile crash sensors." >=20 > Is there any objection (comments from the list) to removing this > requirement as suggested? >=20 >=20 > Roger Marshall >=20 >=20 > >-----Original Message----- > >From: Rohan Mahy [mailto:hannes.tschofenig@siemens.com] > >Sent: Monday, November 07, 2005 2:09 PM > >To: Roger Marshall > >Subject: [issue21] Re7 (Relays): Propose eliminating relays by > >requiring PSAP to support all reasonable modes > > > > > >New submission from Rohan Mahy : > > > >Relays are required in Re7, but not really well motivated. If > >the PSAP needs to accept "calls" in all the modes listed > >(voice, video, text chat, and IM), then I don't think we need > >relays. Eliminating relays would simplify the architecture, > >especially wrt to security. > > > >---------- > >assignedto: roger > >messages: 34 > >nosy: roger, rohan > >priority: urgent > >status: unread > >title: Re7 (Relays): Propose eliminating relays by requiring > >PSAP to support all reasonable modes > > > >________________________________________________________ > >ECRIT Requirements Draft > > > >________________________________________________________ > > >=20 > _______________________________________________ > 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. =20 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 Dec 28 22:01:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ero2I-0007v6-ED; Wed, 28 Dec 2005 22:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ero2E-0007sk-1f for ecrit@megatron.ietf.org; Wed, 28 Dec 2005 22:01:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25563 for ; Wed, 28 Dec 2005 21:59:48 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ero6O-0000q9-Dr for ecrit@ietf.org; Wed, 28 Dec 2005 22:05:16 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Ero2I-0005v1-Cw; Wed, 28 Dec 2005 21:01:02 -0600 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Roger Marshall'" , , "'Rohan Mahy'" Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating relaysbyrequiring PSAP to support all reasonable modes Date: Wed, 28 Dec 2005 21:58:25 -0500 Message-ID: <02dc01c60c23$bf056bb0$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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXj6FvEgh68So4TR4yCFunKpbCUfAoJyxGAAABUpSAABHOGgA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org No, relays are a reality. Support for them may be required in an emergency call scenario involving a hearing impaired person. The only impact this has on routing is that a relay service may have to get a call routed on behalf of a caller to the relay service. This is an instance of 3rd party origination. An entity (which a relay service is an example, others include a telematics call center and a central alarm monitoring service) routes an emergency call where the location is that of its client, not the service. When a 3rd party originated call is connected to the emergency service, the desired media effect is a conference all among the person needing assistance, the service company and the PSAP. That is clearly beyond the ecrit charter, but has to be dealt with somewhere. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James Sent: Wednesday, December 28, 2005 7:46 PM To: Roger Marshall; ecrit@ietf.org; Rohan Mahy Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating relaysbyrequiring PSAP to support all reasonable modes I am not sure why this has to be a relay function. Surely the motivation is more: " It should be possible to establish a direct flow of media to the emergency service. In addition, it should be possible to convey telemetry data, such as data from automobile crash sensors." Relay implies an architectural solution. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Roger Marshall > Sent: Thursday, 29 December 2005 11:39 AM > To: ecrit@ietf.org; Rohan Mahy > Subject: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating relays > byrequiring PSAP to support all reasonable modes > > Rohan: > Currently, we've still got the following requirement, but no discussion > that I've seen on the request to delete it, nor any other discussion of > how this would work. > > "Re7. Relay Services: It SHOULD be possible to involve > relay services in the call for translation between different modes." > > "Motivation: It should be possible to connect the relay service so that > the direct flow of media to the emergency service is maintained. In > addition, it should be possible to convey telemetry data, such as data > from automobile crash sensors." > > Is there any objection (comments from the list) to removing this > requirement as suggested? > > > Roger Marshall > > > >-----Original Message----- > >From: Rohan Mahy [mailto:hannes.tschofenig@siemens.com] > >Sent: Monday, November 07, 2005 2:09 PM > >To: Roger Marshall > >Subject: [issue21] Re7 (Relays): Propose eliminating relays by > >requiring PSAP to support all reasonable modes > > > > > >New submission from Rohan Mahy : > > > >Relays are required in Re7, but not really well motivated. If > >the PSAP needs to accept "calls" in all the modes listed > >(voice, video, text chat, and IM), then I don't think we need > >relays. Eliminating relays would simplify the architecture, > >especially wrt to security. > > > >---------- > >assignedto: roger > >messages: 34 > >nosy: roger, rohan > >priority: urgent > >status: unread > >title: Re7 (Relays): Propose eliminating relays by requiring > >PSAP to support all reasonable modes > > > >________________________________________________________ > >ECRIT Requirements Draft > > > >________________________________________________________ > > > > _______________________________________________ > 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 Dec 28 22:08:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ero9e-00015R-5N; Wed, 28 Dec 2005 22:08:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ero9V-00015B-DX for ecrit@megatron.ietf.org; Wed, 28 Dec 2005 22:08:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26231 for ; Wed, 28 Dec 2005 22:07:19 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EroDe-000130-Df for ecrit@ietf.org; Wed, 28 Dec 2005 22:12:47 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Dec 2005 21:08:16 -0600 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 28 Dec 2005 21:08:15 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Dec 2005 21:08:14 -0600 Message-ID: From: "Winterbottom, James" To: , "Roger Marshall" , , "Rohan Mahy" Date: Wed, 28 Dec 2005 21:08:12 -0600 Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating relaysbyrequiring PSAP to support all reasonable modes MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 29 Dec 2005 03:08:14.0936 (UTC) FILETIME=[1BFA7580:01C60C25] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating relaysbyrequiring PSAP to support all reasonable modes thread-index: AcXj6FvEgh68So4TR4yCFunKpbCUfAoJyxGAAABUpSAABHOGgAAAmcQg X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org So you are talking implementation then Brian? I just wanted to be sure > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, 29 December 2005 1:58 PM > To: Winterbottom, James; 'Roger Marshall'; ecrit@ietf.org; 'Rohan Mahy' > Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating > relaysbyrequiring PSAP to support all reasonable modes >=20 > No, relays are a reality. Support for them may be required in an > emergency > call scenario involving a hearing impaired person. >=20 > The only impact this has on routing is that a relay service may have to > get > a call routed on behalf of a caller to the relay service. This is an > instance of 3rd party origination. An entity (which a relay service is an > example, others include a telematics call center and a central alarm > monitoring service) routes an emergency call where the location is that of > its client, not the service. >=20 > When a 3rd party originated call is connected to the emergency service, > the > desired media effect is a conference all among the person needing > assistance, the service company and the PSAP. That is clearly beyond the > ecrit charter, but has to be dealt with somewhere. >=20 > Brian >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Winterbottom, James > Sent: Wednesday, December 28, 2005 7:46 PM > To: Roger Marshall; ecrit@ietf.org; Rohan Mahy > Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating > relaysbyrequiring PSAP to support all reasonable modes >=20 > I am not sure why this has to be a relay function. > Surely the motivation is more: >=20 > " It should be possible to establish a direct flow of media to the > emergency service. In addition, it should be possible to convey > telemetry data, such as data from automobile crash sensors." >=20 > Relay implies an architectural solution. >=20 > Cheers > James >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Roger Marshall > > Sent: Thursday, 29 December 2005 11:39 AM > > To: ecrit@ietf.org; Rohan Mahy > > Subject: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating > relays > > byrequiring PSAP to support all reasonable modes > > > > Rohan: > > Currently, we've still got the following requirement, but no > discussion > > that I've seen on the request to delete it, nor any other discussion > of > > how this would work. > > > > "Re7. Relay Services: It SHOULD be possible to involve > > relay services in the call for translation between different modes." > > > > "Motivation: It should be possible to connect the relay service so > that > > the direct flow of media to the emergency service is maintained. In > > addition, it should be possible to convey telemetry data, such as data > > from automobile crash sensors." > > > > Is there any objection (comments from the list) to removing this > > requirement as suggested? > > > > > > Roger Marshall > > > > > > >-----Original Message----- > > >From: Rohan Mahy [mailto:hannes.tschofenig@siemens.com] > > >Sent: Monday, November 07, 2005 2:09 PM > > >To: Roger Marshall > > >Subject: [issue21] Re7 (Relays): Propose eliminating relays by > > >requiring PSAP to support all reasonable modes > > > > > > > > >New submission from Rohan Mahy : > > > > > >Relays are required in Re7, but not really well motivated. If > > >the PSAP needs to accept "calls" in all the modes listed > > >(voice, video, text chat, and IM), then I don't think we need > > >relays. Eliminating relays would simplify the architecture, > > >especially wrt to security. > > > > > >---------- > > >assignedto: roger > > >messages: 34 > > >nosy: roger, rohan > > >priority: urgent > > >status: unread > > >title: Re7 (Relays): Propose eliminating relays by requiring > > >PSAP to support all reasonable modes > > > > > >________________________________________________________ > > >ECRIT Requirements Draft > > > > > >________________________________________________________ > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 > ------------------------------------------------------------------------ -- > -- > -------------------- > 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] >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 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 Dec 28 22:34:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EroYR-0008RC-Rp; Wed, 28 Dec 2005 22:34:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EroYO-0008OW-HV for ecrit@megatron.ietf.org; Wed, 28 Dec 2005 22:34:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28624 for ; Wed, 28 Dec 2005 22:33:02 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErocZ-0001y8-4F for ecrit@ietf.org; Wed, 28 Dec 2005 22:38:31 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EroYX-0007VR-Kp; Wed, 28 Dec 2005 21:34:22 -0600 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Roger Marshall'" , , "'Rohan Mahy'" Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating relaysbyrequiring PSAP to support all reasonable modes Date: Wed, 28 Dec 2005 22:31:27 -0500 Message-ID: <02e401c60c28$5bc79730$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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXj6FvEgh68So4TR4yCFunKpbCUfAoJyxGAAABUpSAABHOGgAAAmcQgAACdObA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Huh? Supporting relays is a requirement in the general sense. A relay is not an implementation detail, relay's exist, and must be taken into account within the requirements. The relevant requirement is that the mapping function work for 3rd party origination, where routing is dependent on the location of the person in need, rather than the entity (the 3rd party) that actually places the call. A relay service is among the many entities who may have to invoke mapping. There is a requirement about media (that the caller, the 3rd party, and the PSAP) be connected so everyone knows about, and can converse with each other, but that is not an ecrit requirement given its charter. There are some other requirements for support of relays that are also outside the current charter. Where is the implementation part? Brian -----Original Message----- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Wednesday, December 28, 2005 10:08 PM To: br@brianrosen.net; Roger Marshall; ecrit@ietf.org; Rohan Mahy Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating relaysbyrequiring PSAP to support all reasonable modes So you are talking implementation then Brian? I just wanted to be sure > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, 29 December 2005 1:58 PM > To: Winterbottom, James; 'Roger Marshall'; ecrit@ietf.org; 'Rohan Mahy' > Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating > relaysbyrequiring PSAP to support all reasonable modes > > No, relays are a reality. Support for them may be required in an > emergency > call scenario involving a hearing impaired person. > > The only impact this has on routing is that a relay service may have to > get > a call routed on behalf of a caller to the relay service. This is an > instance of 3rd party origination. An entity (which a relay service is an > example, others include a telematics call center and a central alarm > monitoring service) routes an emergency call where the location is that of > its client, not the service. > > When a 3rd party originated call is connected to the emergency service, > the > desired media effect is a conference all among the person needing > assistance, the service company and the PSAP. That is clearly beyond the > ecrit charter, but has to be dealt with somewhere. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Winterbottom, James > Sent: Wednesday, December 28, 2005 7:46 PM > To: Roger Marshall; ecrit@ietf.org; Rohan Mahy > Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating > relaysbyrequiring PSAP to support all reasonable modes > > I am not sure why this has to be a relay function. > Surely the motivation is more: > > " It should be possible to establish a direct flow of media to the > emergency service. In addition, it should be possible to convey > telemetry data, such as data from automobile crash sensors." > > Relay implies an architectural solution. > > Cheers > James > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Roger Marshall > > Sent: Thursday, 29 December 2005 11:39 AM > > To: ecrit@ietf.org; Rohan Mahy > > Subject: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating > relays > > byrequiring PSAP to support all reasonable modes > > > > Rohan: > > Currently, we've still got the following requirement, but no > discussion > > that I've seen on the request to delete it, nor any other discussion > of > > how this would work. > > > > "Re7. Relay Services: It SHOULD be possible to involve > > relay services in the call for translation between different modes." > > > > "Motivation: It should be possible to connect the relay service so > that > > the direct flow of media to the emergency service is maintained. In > > addition, it should be possible to convey telemetry data, such as data > > from automobile crash sensors." > > > > Is there any objection (comments from the list) to removing this > > requirement as suggested? > > > > > > Roger Marshall > > > > > > >-----Original Message----- > > >From: Rohan Mahy [mailto:hannes.tschofenig@siemens.com] > > >Sent: Monday, November 07, 2005 2:09 PM > > >To: Roger Marshall > > >Subject: [issue21] Re7 (Relays): Propose eliminating relays by > > >requiring PSAP to support all reasonable modes > > > > > > > > >New submission from Rohan Mahy : > > > > > >Relays are required in Re7, but not really well motivated. If > > >the PSAP needs to accept "calls" in all the modes listed > > >(voice, video, text chat, and IM), then I don't think we need > > >relays. Eliminating relays would simplify the architecture, > > >especially wrt to security. > > > > > >---------- > > >assignedto: roger > > >messages: 34 > > >nosy: roger, rohan > > >priority: urgent > > >status: unread > > >title: Re7 (Relays): Propose eliminating relays by requiring > > >PSAP to support all reasonable modes > > > > > >________________________________________________________ > > >ECRIT Requirements Draft > > > > > >________________________________________________________ > > > > > > > _______________________________________________ > > 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 > > ---------------------------------------------------------------------------- -------------------- 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 Dec 28 23:37:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErpXo-0008OT-Gc; Wed, 28 Dec 2005 23:37:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErpXn-0008O9-1S for ecrit@megatron.ietf.org; Wed, 28 Dec 2005 23:37:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03168 for ; Wed, 28 Dec 2005 23:36:28 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Erpbx-0003fk-RM for ecrit@ietf.org; Wed, 28 Dec 2005 23:41:58 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Dec 2005 22:37:29 -0600 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 28 Dec 2005 22:37:28 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Dec 2005 22:37:27 -0600 Message-ID: From: "Winterbottom, James" To: , "Roger Marshall" , , "Rohan Mahy" Date: Wed, 28 Dec 2005 22:37:25 -0600 Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating relaysbyrequiring PSAP to support all reasonable modes MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 29 Dec 2005 04:37:27.0991 (UTC) FILETIME=[92A5D470:01C60C31] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating relaysbyrequiring PSAP to support all reasonable modes thread-index: AcXj6FvEgh68So4TR4yCFunKpbCUfAoJyxGAAABUpSAABHOGgAAAmcQgAACdObAAAl82sA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is where the problem comes in. The mapping function MUST NOT know the identity of the caller, otherwise the by-value vs by-reference argument is moot. This being the case, please explain how the mapping function will know the difference as to who or what is requesting mapping?=20 The requirement is that the mapping function provide a mapping when a location is asserted to it, not whether that entity is a 3rd party or not. In fact if it knows the difference then it is probably violating the privacy requirement. So I re-assert my question. Are you talking about implementation because I believe you are. =20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, 29 December 2005 2:31 PM > To: Winterbottom, James; 'Roger Marshall'; ecrit@ietf.org; 'Rohan Mahy' > Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating > relaysbyrequiring PSAP to support all reasonable modes >=20 > Huh? >=20 > Supporting relays is a requirement in the general sense. A relay is not > an > implementation detail, relay's exist, and must be taken into account > within > the requirements. >=20 > The relevant requirement is that the mapping function work for 3rd party > origination, where routing is dependent on the location of the person in > need, rather than the entity (the 3rd party) that actually places the > call. > A relay service is among the many entities who may have to invoke mapping. >=20 > There is a requirement about media (that the caller, the 3rd party, and > the > PSAP) be connected so everyone knows about, and can converse with each > other, but that is not an ecrit requirement given its charter. >=20 > There are some other requirements for support of relays that are also > outside the current charter. >=20 > Where is the implementation part? >=20 > Brian >=20 >=20 > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Wednesday, December 28, 2005 10:08 PM > To: br@brianrosen.net; Roger Marshall; ecrit@ietf.org; Rohan Mahy > Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating > relaysbyrequiring PSAP to support all reasonable modes >=20 > So you are talking implementation then Brian? > I just wanted to be sure >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, 29 December 2005 1:58 PM > > To: Winterbottom, James; 'Roger Marshall'; ecrit@ietf.org; 'Rohan > Mahy' > > Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating > > relaysbyrequiring PSAP to support all reasonable modes > > > > No, relays are a reality. Support for them may be required in an > > emergency > > call scenario involving a hearing impaired person. > > > > The only impact this has on routing is that a relay service may have > to > > get > > a call routed on behalf of a caller to the relay service. This is an > > instance of 3rd party origination. An entity (which a relay service > is an > > example, others include a telematics call center and a central alarm > > monitoring service) routes an emergency call where the location is > that of > > its client, not the service. > > > > When a 3rd party originated call is connected to the emergency > service, > > the > > desired media effect is a conference all among the person needing > > assistance, the service company and the PSAP. That is clearly beyond > the > > ecrit charter, but has to be dealt with somewhere. > > > > Brian > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Winterbottom, James > > Sent: Wednesday, December 28, 2005 7:46 PM > > To: Roger Marshall; ecrit@ietf.org; Rohan Mahy > > Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating > > relaysbyrequiring PSAP to support all reasonable modes > > > > I am not sure why this has to be a relay function. > > Surely the motivation is more: > > > > " It should be possible to establish a direct flow of media to the > > emergency service. In addition, it should be possible to convey > > telemetry data, such as data from automobile crash sensors." > > > > Relay implies an architectural solution. > > > > Cheers > > James > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > > Of > > > Roger Marshall > > > Sent: Thursday, 29 December 2005 11:39 AM > > > To: ecrit@ietf.org; Rohan Mahy > > > Subject: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating > > relays > > > byrequiring PSAP to support all reasonable modes > > > > > > Rohan: > > > Currently, we've still got the following requirement, but no > > discussion > > > that I've seen on the request to delete it, nor any other discussion > > of > > > how this would work. > > > > > > "Re7. Relay Services: It SHOULD be possible to involve > > > relay services in the call for translation between different modes." > > > > > > "Motivation: It should be possible to connect the relay service so > > that > > > the direct flow of media to the emergency service is maintained. In > > > addition, it should be possible to convey telemetry data, such as > data > > > from automobile crash sensors." > > > > > > Is there any objection (comments from the list) to removing this > > > requirement as suggested? > > > > > > > > > Roger Marshall > > > > > > > > > >-----Original Message----- > > > >From: Rohan Mahy [mailto:hannes.tschofenig@siemens.com] > > > >Sent: Monday, November 07, 2005 2:09 PM > > > >To: Roger Marshall > > > >Subject: [issue21] Re7 (Relays): Propose eliminating relays by > > > >requiring PSAP to support all reasonable modes > > > > > > > > > > > >New submission from Rohan Mahy : > > > > > > > >Relays are required in Re7, but not really well motivated. If > > > >the PSAP needs to accept "calls" in all the modes listed > > > >(voice, video, text chat, and IM), then I don't think we need > > > >relays. Eliminating relays would simplify the architecture, > > > >especially wrt to security. > > > > > > > >---------- > > > >assignedto: roger > > > >messages: 34 > > > >nosy: roger, rohan > > > >priority: urgent > > > >status: unread > > > >title: Re7 (Relays): Propose eliminating relays by requiring > > > >PSAP to support all reasonable modes > > > > > > > >________________________________________________________ > > > >ECRIT Requirements Draft > > > > > > > >________________________________________________________ > > > > > > > > > > _______________________________________________ > > > 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 > > > > >=20 > ------------------------------------------------------------------------ -- > -- > -------------------- > 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] >=20 >=20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 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 Thu Dec 29 01:53:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Errfd-0003UK-74; Thu, 29 Dec 2005 01:53:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Errfb-0003Tx-NQ for ecrit@megatron.ietf.org; Thu, 29 Dec 2005 01:53:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12396 for ; Thu, 29 Dec 2005 01:52:40 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Errjn-0007FE-My for ecrit@ietf.org; Thu, 29 Dec 2005 01:58:12 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 28 Dec 2005 22:53:42 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jBT6rfYW000191; Wed, 28 Dec 2005 22:53:41 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Dec 2005 22:53:41 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.145.118]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Dec 2005 22:53:40 -0800 Message-Id: <4.3.2.7.2.20051229004902.02a5a920@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Dec 2005 00:53:39 -0600 To: "Roger Marshall" , "Andrew Newton" , From: "James M. Polk" Subject: RE: [Ecrit] Issue 10: Design of Non-Emergency Components In-Reply-To: <8C837214C95C864C9F34F3635C2A657503DD7125@SEA-EXCHVS-2.tele comsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 29 Dec 2005 06:53:40.0972 (UTC) FILETIME=[9A1FC2C0:01C60C44] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Roger I think I remember this being something purposely around the motherhood and apple-pie idea of stating "this will be robust", but not mandate anything about robustness or reliability or resiliancy or that this WG cannot control... Didn't the come out of the Interim? At 04:20 PM 12/28/2005 -0800, Roger Marshall wrote: >Andy: > >Issue 10: Design of Non-Emergency Components >(http://www.ietf-ecrit.org:8080/ecrit-req/issue10) > >"There are no requirements regarding the resilience of the emergency >call routing >process as it relates to inputs that have not been designed for the >purpose of >emergency call routing." > >I'm not exactly sure what this issue is getting at... a couple of >thoughts, >1. are we talking about resilience against inadvertant or on-purpose >mis-use, (in which case it seems like a security concern), or >2. do you mean, that the MP should be resilient in order to support >other types of use, besides just emergency use? > >Thanks. > >Roger Marshall. > > > >_______________________________________________ >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 Dec 29 05:40:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErvCg-0001o3-TK; Thu, 29 Dec 2005 05:40:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErvCe-0001nq-VU for ecrit@megatron.ietf.org; Thu, 29 Dec 2005 05:40:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03849 for ; Thu, 29 Dec 2005 05:39:02 -0500 (EST) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErvGr-0006Oi-6I for ecrit@ietf.org; Thu, 29 Dec 2005 05:44:35 -0500 Received: from CarstenSR40 (pop-ls-18-2-dialup-203.freesurf.ch [194.230.187.203]) (user=hgs10 mech=LOGIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jBTAdlh3005009 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Dec 2005 05:39:54 -0500 (EST) Message-ID: <002d01c60c64$3b031b00$cbbbe6c2@CarstenSR40> From: "Henning" To: , "'Winterbottom, James'" , "'Roger Marshall'" , , "'Rohan Mahy'" References: <02dc01c60c23$bf056bb0$640fa8c0@cis.neustar.com> Subject: Re: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminatingrelaysbyrequiring PSAP to support all reasonable modes Date: Thu, 29 Dec 2005 11:39:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.1 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I agree that conferencing and media relaying are important considerations for any viable IP-based emergency calling system, but I'm confused as to why this impacts call routing and in particular the mapping protocol. Clearly, a node anywhere needs to be able to obtain a mapping for any other geographic location, including those far away, but that doesn't seem to be the issue. ----- Original Message ----- From: "Brian Rosen" To: "'Winterbottom, James'" ; "'Roger Marshall'" ; ; "'Rohan Mahy'" Sent: Thursday, December 29, 2005 3:58 AM Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminatingrelaysbyrequiring PSAP to support all reasonable modes > No, relays are a reality. Support for them may be required in an > emergency > call scenario involving a hearing impaired person. > > The only impact this has on routing is that a relay service may have to > get > a call routed on behalf of a caller to the relay service. This is an > instance of 3rd party origination. An entity (which a relay service is an > example, others include a telematics call center and a central alarm > monitoring service) routes an emergency call where the location is that of > its client, not the service. > > When a 3rd party originated call is connected to the emergency service, > the > desired media effect is a conference all among the person needing > assistance, the service company and the PSAP. That is clearly beyond the > ecrit charter, but has to be dealt with somewhere. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Winterbottom, James > Sent: Wednesday, December 28, 2005 7:46 PM > To: Roger Marshall; ecrit@ietf.org; Rohan Mahy > Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating > relaysbyrequiring PSAP to support all reasonable modes > > I am not sure why this has to be a relay function. > Surely the motivation is more: > > " It should be possible to establish a direct flow of media to the > emergency service. In addition, it should be possible to convey > telemetry data, such as data from automobile crash sensors." > > Relay implies an architectural solution. > > Cheers > James > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of >> Roger Marshall >> Sent: Thursday, 29 December 2005 11:39 AM >> To: ecrit@ietf.org; Rohan Mahy >> Subject: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating > relays >> byrequiring PSAP to support all reasonable modes >> >> Rohan: >> Currently, we've still got the following requirement, but no > discussion >> that I've seen on the request to delete it, nor any other discussion > of >> how this would work. >> >> "Re7. Relay Services: It SHOULD be possible to involve >> relay services in the call for translation between different modes." >> >> "Motivation: It should be possible to connect the relay service so > that >> the direct flow of media to the emergency service is maintained. In >> addition, it should be possible to convey telemetry data, such as data >> from automobile crash sensors." >> >> Is there any objection (comments from the list) to removing this >> requirement as suggested? >> >> >> Roger Marshall >> >> >> >-----Original Message----- >> >From: Rohan Mahy [mailto:hannes.tschofenig@siemens.com] >> >Sent: Monday, November 07, 2005 2:09 PM >> >To: Roger Marshall >> >Subject: [issue21] Re7 (Relays): Propose eliminating relays by >> >requiring PSAP to support all reasonable modes >> > >> > >> >New submission from Rohan Mahy : >> > >> >Relays are required in Re7, but not really well motivated. If >> >the PSAP needs to accept "calls" in all the modes listed >> >(voice, video, text chat, and IM), then I don't think we need >> >relays. Eliminating relays would simplify the architecture, >> >especially wrt to security. >> > >> >---------- >> >assignedto: roger >> >messages: 34 >> >nosy: roger, rohan >> >priority: urgent >> >status: unread >> >title: Re7 (Relays): Propose eliminating relays by requiring >> >PSAP to support all reasonable modes >> > >> >________________________________________________________ >> >ECRIT Requirements Draft >> > >> >________________________________________________________ >> > >> >> _______________________________________________ >> 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 Dec 29 09:15:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EryYd-0007IU-KL; Thu, 29 Dec 2005 09:15:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EryYb-0007Hr-PS for ecrit@megatron.ietf.org; Thu, 29 Dec 2005 09:15:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29252 for ; Thu, 29 Dec 2005 09:13:53 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Erycr-0006QQ-KM for ecrit@ietf.org; Thu, 29 Dec 2005 09:19:30 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EryYf-0000bv-SA; Thu, 29 Dec 2005 08:15:10 -0600 From: "Brian Rosen" To: "'Henning'" , "'Winterbottom, James'" , "'Roger Marshall'" , , "'Rohan Mahy'" Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminatingrelaysbyrequiring PSAP to support all reasonable modes Date: Thu, 29 Dec 2005 09:12:38 -0500 Message-ID: <034901c60c81$eeba5060$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 In-Reply-To: <002d01c60c64$3b031b00$cbbbe6c2@CarstenSR40> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYMZEH8rYt77TUQSCurcCZYDYxZHAAGUSMA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I have just looked through the current draft. No where is there a requirement that mapping can be done by any entity, using anyone's notion of location. While I believe any entity along a path from a caller to the PSAP must be able to map, it's not absolutely necessary to broaden that to any entity at all. Similarly, location can come from the caller (directly or indirectly) or from an authorized third party (as in a telematics call), but it isn't necessary that it come from just any entity. If you want to make the requirements broad, by saying explicitly that mapping can be accomplished by any entity regardless of their relationship to an emergency caller, and that any location can be used for mapping, then that would cover the relay and other 3rd party call originatos. However, the requirements, as currently expressed in the draft, are insufficient. You could have some problems with very broad language because it could open the door to more abuse. Lack of an overall architecture is again causing problems. Brian -----Original Message----- From: Henning [mailto:hgs@cs.columbia.edu] Sent: Thursday, December 29, 2005 5:40 AM To: br@brianrosen.net; 'Winterbottom, James'; 'Roger Marshall'; ecrit@ietf.org; 'Rohan Mahy' Subject: Re: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminatingrelaysbyrequiring PSAP to support all reasonable modes I agree that conferencing and media relaying are important considerations for any viable IP-based emergency calling system, but I'm confused as to why this impacts call routing and in particular the mapping protocol. Clearly, a node anywhere needs to be able to obtain a mapping for any other geographic location, including those far away, but that doesn't seem to be the issue. ----- Original Message ----- From: "Brian Rosen" To: "'Winterbottom, James'" ; "'Roger Marshall'" ; ; "'Rohan Mahy'" Sent: Thursday, December 29, 2005 3:58 AM Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminatingrelaysbyrequiring PSAP to support all reasonable modes > No, relays are a reality. Support for them may be required in an > emergency > call scenario involving a hearing impaired person. > > The only impact this has on routing is that a relay service may have to > get > a call routed on behalf of a caller to the relay service. This is an > instance of 3rd party origination. An entity (which a relay service is an > example, others include a telematics call center and a central alarm > monitoring service) routes an emergency call where the location is that of > its client, not the service. > > When a 3rd party originated call is connected to the emergency service, > the > desired media effect is a conference all among the person needing > assistance, the service company and the PSAP. That is clearly beyond the > ecrit charter, but has to be dealt with somewhere. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Winterbottom, James > Sent: Wednesday, December 28, 2005 7:46 PM > To: Roger Marshall; ecrit@ietf.org; Rohan Mahy > Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating > relaysbyrequiring PSAP to support all reasonable modes > > I am not sure why this has to be a relay function. > Surely the motivation is more: > > " It should be possible to establish a direct flow of media to the > emergency service. In addition, it should be possible to convey > telemetry data, such as data from automobile crash sensors." > > Relay implies an architectural solution. > > Cheers > James > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of >> Roger Marshall >> Sent: Thursday, 29 December 2005 11:39 AM >> To: ecrit@ietf.org; Rohan Mahy >> Subject: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminating > relays >> byrequiring PSAP to support all reasonable modes >> >> Rohan: >> Currently, we've still got the following requirement, but no > discussion >> that I've seen on the request to delete it, nor any other discussion > of >> how this would work. >> >> "Re7. Relay Services: It SHOULD be possible to involve >> relay services in the call for translation between different modes." >> >> "Motivation: It should be possible to connect the relay service so > that >> the direct flow of media to the emergency service is maintained. In >> addition, it should be possible to convey telemetry data, such as data >> from automobile crash sensors." >> >> Is there any objection (comments from the list) to removing this >> requirement as suggested? >> >> >> Roger Marshall >> >> >> >-----Original Message----- >> >From: Rohan Mahy [mailto:hannes.tschofenig@siemens.com] >> >Sent: Monday, November 07, 2005 2:09 PM >> >To: Roger Marshall >> >Subject: [issue21] Re7 (Relays): Propose eliminating relays by >> >requiring PSAP to support all reasonable modes >> > >> > >> >New submission from Rohan Mahy : >> > >> >Relays are required in Re7, but not really well motivated. If >> >the PSAP needs to accept "calls" in all the modes listed >> >(voice, video, text chat, and IM), then I don't think we need >> >relays. Eliminating relays would simplify the architecture, >> >especially wrt to security. >> > >> >---------- >> >assignedto: roger >> >messages: 34 >> >nosy: roger, rohan >> >priority: urgent >> >status: unread >> >title: Re7 (Relays): Propose eliminating relays by requiring >> >PSAP to support all reasonable modes >> > >> >________________________________________________________ >> >ECRIT Requirements Draft >> > >> >________________________________________________________ >> > >> >> _______________________________________________ >> 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 Dec 29 09:25:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eryiu-0001V2-I3; Thu, 29 Dec 2005 09:25:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eryio-0001U2-E0 for ecrit@megatron.ietf.org; Thu, 29 Dec 2005 09:25:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00604 for ; Thu, 29 Dec 2005 09:24:26 -0500 (EST) Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eryn3-0006nW-Ng for ecrit@ietf.org; Thu, 29 Dec 2005 09:30:02 -0500 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Thu, 29 Dec 2005 09:24:50 -0500 id 01588021.43B3F1B2.00006980 In-Reply-To: <8C837214C95C864C9F34F3635C2A657503DD7125@SEA-EXCHVS-2.telecomsys.com> References: <8C837214C95C864C9F34F3635C2A657503DD7125@SEA-EXCHVS-2.telecomsys.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <65AE6542-FB1A-4315-9EDA-5890BCDFB81E@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Issue 10: Design of Non-Emergency Components Date: Thu, 29 Dec 2005 09:25:14 -0500 To: Roger Marshall X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Dec 28, 2005, at 7:20 PM, Roger Marshall wrote: > Andy: > > Issue 10: Design of Non-Emergency Components > (http://www.ietf-ecrit.org:8080/ecrit-req/issue10) > > "There are no requirements regarding the resilience of the emergency > call routing > process as it relates to inputs that have not been designed for the > purpose of > emergency call routing." > > I'm not exactly sure what this issue is getting at... a couple of > thoughts, > 1. are we talking about resilience against inadvertant or on-purpose > mis-use, (in which case it seems like a security concern), or > 2. do you mean, that the MP should be resilient in order to support > other types of use, besides just emergency use? I think I just need to completely restate the concern. Location information services and sighting services will be present in the network for more than just emergency services, such as the much talked about "Where is the nearest Starbucks?" service. While the mapping service may only be used and present for emergency call routing, these location information services it relies upon have multiple uses. Therefore, the mapping protocol should not require addresses in these services to be contorted or transmogrified in any way that would reasonably conflict with these other services. Thinking this through, perhaps this only applies to civic addresses as geo-spatial addresses can be algorithmically converted from one format to another. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Dec 29 15:20:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es4GD-0006AG-9M; Thu, 29 Dec 2005 15:20:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es4GC-0006AB-7U for ecrit@megatron.ietf.org; Thu, 29 Dec 2005 15:20:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09614 for ; Thu, 29 Dec 2005 15:19:16 -0500 (EST) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Es4KV-0001gx-Gc for ecrit@ietf.org; Thu, 29 Dec 2005 15:24:55 -0500 Received: from CarstenSR40 (pop-mu-9-2-dialup-51.freesurf.ch [194.230.146.51]) (user=hgs10 mech=LOGIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jBTKJfiv022026 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Dec 2005 15:20:07 -0500 (EST) Message-ID: <01aa01c60cb5$496b71f0$3392e6c2@CarstenSR40> From: "Henning" To: , References: <034901c60c81$eeba5060$640fa8c0@cis.neustar.com> Subject: Re: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminatingrelaysbyrequiring PSAP to support all reasonable modes Date: Thu, 29 Dec 2005 21:19:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org While there may be administrative and policy reasons that a particular server will not answer queries from a particular region or querier, it seems to be rather difficult to anticipate these in a protocol design. Thus, from a protocol design perspective, the protocol should make it possible to allow queries from anywhere. It is easy to picture scenarios where this is needed, for example when delayed location availability causes the call to be routed to some default location and that call center then needs to lookup the right PSAP when the location information shows up later. The number of such places is essentially unbounded, as it could be one for each VSP (including corporations). Therefore, I think there is a need to state as a protocol design objective that queries can indeed come from anywhere. ----- Original Message ----- From: "Brian Rosen" To: "'Henning'" ; "'Winterbottom, James'" ; "'Roger Marshall'" ; ; "'Rohan Mahy'" Sent: Thursday, December 29, 2005 3:12 PM Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminatingrelaysbyrequiring PSAP to support all reasonable modes >I have just looked through the current draft. No where is there a > requirement that mapping can be done by any entity, using anyone's notion > of > location. > > While I believe any entity along a path from a caller to the PSAP must be > able to map, it's not absolutely necessary to broaden that to any entity > at > all. Similarly, location can come from the caller (directly or > indirectly) > or from an authorized third party (as in a telematics call), but it isn't > necessary that it come from just any entity. > > If you want to make the requirements broad, by saying explicitly that > mapping can be accomplished by any entity regardless of their relationship > to an emergency caller, and that any location can be used for mapping, > then > that would cover the relay and other 3rd party call originatos. However, > the requirements, as currently expressed in the draft, are insufficient. > > You could have some problems with very broad language because it could > open > the door to more abuse. > > Lack of an overall architecture is again causing problems. > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Dec 29 15:21:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es4Gj-0006He-PS; Thu, 29 Dec 2005 15:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es4Gi-0006Gc-N0 for ecrit@megatron.ietf.org; Thu, 29 Dec 2005 15:21:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09717 for ; Thu, 29 Dec 2005 15:19:48 -0500 (EST) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Es4Kz-0001iP-SP for ecrit@ietf.org; Thu, 29 Dec 2005 15:25:28 -0500 Received: from CarstenSR40 (pop-mu-9-2-dialup-51.freesurf.ch [194.230.146.51]) (user=hgs10 mech=LOGIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jBTKKY4O028770 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Dec 2005 15:20:51 -0500 (EST) Message-ID: <01ab01c60cb5$612fe320$3392e6c2@CarstenSR40> From: "Henning" To: , References: <034901c60c81$eeba5060$640fa8c0@cis.neustar.com> Subject: Re: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminatingrelaysbyrequiring PSAP to support all reasonable modes Date: Thu, 29 Dec 2005 21:19:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org While there may be administrative and policy reasons that a particular server will not answer queries from a particular region or querier, it seems to be rather difficult to anticipate these in a protocol design. Thus, from a protocol design perspective, the protocol should make it possible to allow queries from anywhere. It is easy to picture scenarios where this is needed, for example when delayed location availability causes the call to be routed to some default location and that call center then needs to lookup the right PSAP when the location information shows up later. The number of such places is essentially unbounded, as it could be one for each VSP (including corporations). Therefore, I think there is a need to state as a protocol design objective that queries can indeed come from anywhere. ----- Original Message ----- From: "Brian Rosen" To: "'Henning'" ; "'Winterbottom, James'" ; "'Roger Marshall'" ; ; "'Rohan Mahy'" Sent: Thursday, December 29, 2005 3:12 PM Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose eliminatingrelaysbyrequiring PSAP to support all reasonable modes >I have just looked through the current draft. No where is there a > requirement that mapping can be done by any entity, using anyone's notion > of > location. > > While I believe any entity along a path from a caller to the PSAP must be > able to map, it's not absolutely necessary to broaden that to any entity > at > all. Similarly, location can come from the caller (directly or > indirectly) > or from an authorized third party (as in a telematics call), but it isn't > necessary that it come from just any entity. > > If you want to make the requirements broad, by saying explicitly that > mapping can be accomplished by any entity regardless of their relationship > to an emergency caller, and that any location can be used for mapping, > then > that would cover the relay and other 3rd party call originatos. However, > the requirements, as currently expressed in the draft, are insufficient. > > You could have some problems with very broad language because it could > open > the door to more abuse. > > Lack of an overall architecture is again causing problems. > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Dec 30 13:11:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsOj2-00075K-A8; Fri, 30 Dec 2005 13:11:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsOiz-00075F-5r for ecrit@megatron.ietf.org; Fri, 30 Dec 2005 13:11:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22269 for ; Fri, 30 Dec 2005 13:10:19 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsOnQ-0003vb-NI for ecrit@ietf.org; Fri, 30 Dec 2005 13:16:10 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Fri, 30 Dec 2005 13:11:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] RE: [issue21] Re7 (Relays): Proposeeliminatingrelaysbyrequiring PSAP to support all reasonable modes Date: Fri, 30 Dec 2005 10:11:09 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657503E54351@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] RE: [issue21] Re7 (Relays): Proposeeliminatingrelaysbyrequiring PSAP to support all reasonable modes Thread-Index: AcYMteu1u91BHsj0QE6fSXW/Tp+XdQAs2LuA From: "Roger Marshall" To: "Henning" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Based on this discussion, I agree that the requirement (Re7) around Relays is at it's foundation, architectural, and not really part of the mapping function per se. Also, this original requirement discussed conveyance of data through (or maybe despite) a Relay's presence, which doesn't really seem to me to be a mapping protocol function.=20 So, I have replaced Re7 (existence of Relays), with what seems to be the better discussion, that of initiating mapping from anywhere, anytime. =20 Change FROM: Re7. DirectRelay Services: It SHOULD be possible to involve=20 relay services in the call for translation between different modes. Motivation: It should be possible to connect the relay service so that=20 the direct flow of media to the emergency service is maintained. In=20 addition, it should be possible to convey telemetry data, such as data=20 from automobile crash sensors. Change TO: Re7. Ubiquiteous Triggering: It MUST be possible to invoke=20 the mapping protocol at any time, from any location, by any=20 client which supports the mapping protocol. Motivation: While end devices are the typical initiators of=20 mapping service requests, it is also expected that other=20 mapping clients, such as relays, 3rd party devices, PSAPs,=20 etc. may also trigger a mapping request. (Also, since I'm not thrilled with my own choice of the tag, "Ubiquitous Triggering", I'm accepting offers for a better one.) Roger Marshall =20 >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Henning >Sent: Thursday, December 29, 2005 12:20 PM >To: br@brianrosen.net; ecrit@ietf.org >Subject: Re: [Ecrit] RE: [issue21] Re7 (Relays):=20 >Proposeeliminatingrelaysbyrequiring PSAP to support all=20 >reasonable modes > >While there may be administrative and policy reasons that a=20 >particular server will not answer queries from a particular=20 >region or querier, it seems to be rather difficult to=20 >anticipate these in a protocol design. Thus, from a protocol=20 >design perspective, the protocol should make it possible to=20 >allow queries from anywhere. It is easy to picture scenarios=20 >where this is needed, for example when delayed location=20 >availability causes the call to be routed to some default=20 >location and that call center then needs to lookup the right=20 >PSAP when the location information shows up later. The number=20 >of such places is essentially unbounded, as it could be one=20 >for each VSP (including corporations). > >Therefore, I think there is a need to state as a protocol=20 >design objective that queries can indeed come from anywhere. > > >----- Original Message -----=20 >From: "Brian Rosen" >To: "'Henning'" ; "'Winterbottom, James'"=20 >; "'Roger Marshall'"=20 >; ; "'Rohan Mahy'"=20 > >Sent: Thursday, December 29, 2005 3:12 PM >Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose=20 >eliminatingrelaysbyrequiring PSAP to support all reasonable modes > > >>I have just looked through the current draft. No where is there a >> requirement that mapping can be done by any entity, using=20 >anyone's notion=20 >> of >> location. >> >> While I believe any entity along a path from a caller to the=20 >PSAP must be >> able to map, it's not absolutely necessary to broaden that=20 >to any entity=20 >> at >> all. Similarly, location can come from the caller (directly or=20 >> indirectly) >> or from an authorized third party (as in a telematics call),=20 >but it isn't >> necessary that it come from just any entity. >> >> If you want to make the requirements broad, by saying explicitly that >> mapping can be accomplished by any entity regardless of=20 >their relationship >> to an emergency caller, and that any location can be used=20 >for mapping,=20 >> then >> that would cover the relay and other 3rd party call=20 >originatos. However, >> the requirements, as currently expressed in the draft, are=20 >insufficient. >> >> You could have some problems with very broad language=20 >because it could=20 >> open >> the door to more abuse. >> >> Lack of an overall architecture is again causing problems. >> >> Brian >> > > >_______________________________________________ >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 Dec 30 14:12:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsPg1-0007aS-9X; Fri, 30 Dec 2005 14:12:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsPfy-0007a9-UR for ecrit@megatron.ietf.org; Fri, 30 Dec 2005 14:12:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28707 for ; Fri, 30 Dec 2005 14:11:18 -0500 (EST) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsPkT-00060p-1l for ecrit@ietf.org; Fri, 30 Dec 2005 14:17:10 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id jBUJCJ48022345 for ; Fri, 30 Dec 2005 20:12:20 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id jBUJCJO9007515 for ; Fri, 30 Dec 2005 20:12:19 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Dec 2005 20:12:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Dec 2005 20:11:31 +0100 Message-ID: Thread-Topic: Updated Draft: "Requirements for Emergency Context Resolution with Internet Technologies" Thread-Index: AcVR0qTi/GpuYYSrSCO1++3T/JBMqwAoqA0QDGIxMYAiXDF4gAABX8Ng From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 30 Dec 2005 19:12:19.0264 (UTC) FILETIME=[F44C3400:01C60D74] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Updated Draft: "Requirements for Emergency Context Resolution with Internet Technologies" 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 =20 please find the updated requirements draft at=20 http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-02.txt before it appears.=20 thank you roger for the editing work. happy reading and happy new year.=20 ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Dec 30 14:12:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsPg1-0007au-JS; Fri, 30 Dec 2005 14:12:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsPg0-0007aN-UV for ecrit@megatron.ietf.org; Fri, 30 Dec 2005 14:12:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28718 for ; Fri, 30 Dec 2005 14:11:20 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsPkV-000612-MF for ecrit@ietf.org; Fri, 30 Dec 2005 14:17:12 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id jBUJCMFx029036 for ; Fri, 30 Dec 2005 20:12:22 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id jBUJCMCS029111 for ; Fri, 30 Dec 2005 20:12:22 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Dec 2005 20:12:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Dec 2005 20:12:21 +0100 Message-ID: Thread-Topic: ECRIT Interim Meeting Thread-Index: AcYNUKarbgJAnMVYQYyVJe9DRAzrEAAIiOCg From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 30 Dec 2005 19:12:21.0936 (UTC) FILETIME=[F5E3EB00:01C60D74] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] WG: ECRIT Interim Meeting 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org you can find the latest information (e.g., draft updates) about the = ecrit interim meeting at=20 =20 http://www.ietf-ecrit.org/Interim2006/ecrit-interim.txt ciao hannes -----Urspr=FCngliche Nachricht----- Von: ietf-announce-bounces@ietf.org = [mailto:ietf-announce-bounces@ietf.org] Im Auftrag von Tschofenig, = Hannes Gesendet: Freitag, 30. Dezember 2005 01:13 An: IETF Announcement list Betreff: ECRIT Interim Meeting=20 The ECRIT working group will be holding an interim meeting. When: 2006 Feb. 1 08:30-18:00 2006 Feb. 2 08:30-18:00 Where: NETWORK RELIABILITY & SECURITY OFFICE (NRSO) CONFERENCE CENTER 1100 New York Avenue, Suite 620 W Washington, DC 20005 Directions: http://www.ietf-ecrit.org/Interim2006/directions.doc http://www.ietf-ecrit.org/Interim2006/directions.pdf Hotels: http://www.ietf-ecrit.org/Interim2006/hotels.doc http://www.ietf-ecrit.org/Interim2006/hotels.pdf Our Host: Lucent Proposed Agenda: 1) Requirements for ECRIT ------------------------- http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-01.txt Issue tracker: http://www.ietf-ecrit.org:8080/ecrit-req/ 2) Security Threats and Requirements for Emergency Calling ---------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-taylor-ecrit-security-threats- 01.txt 3) Mapping Protocols -------------------- DNS-SOS: http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-03.txt LUMP: http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-lump-01.txt ECON: http://www.ietf.org/internet-drafts/draft-hardie-ecrit-iris-03.txt 4) Emergency Identifiers ------------------------ A Uniform Resource Name (URN) for Services http://www.ietf.org/internet-drafts/draft-schulzrinne-sipping-service-01 .txt Emergency Services URI for the Session Initiation Protocol http://www.ietf.org/internet-drafts/draft-ietf-sipping-sos-01.txt 5) Architectural Aspects ------------------------ Location-to-URL Mapping Architecture and Framework http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-mapping-arch -00.txt Emergency Context Routing of Internet Technologies Architecture Considerations http://www.ietf.org/internet-drafts/draft-polk-newton-ecrit-arch-conside rations-01.txt Please send us a mail asap if you plan to attend. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Dec 30 22:18:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsXGX-000445-QU; Fri, 30 Dec 2005 22:18:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsXGV-000440-6r for ecrit@megatron.ietf.org; Fri, 30 Dec 2005 22:18:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19846 for ; Fri, 30 Dec 2005 22:17:30 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsXL2-0005e4-Qp for ecrit@ietf.org; Fri, 30 Dec 2005 22:23:27 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Dec 2005 21:18:21 -0600 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Fri, 30 Dec 2005 21:18:21 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Dec 2005 21:18:21 -0600 Message-ID: From: "Winterbottom, James" To: "Roger Marshall" , "Henning" , , Date: Fri, 30 Dec 2005 21:18:18 -0600 Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays):Proposeeliminatingrelaysbyrequiring PSAP to support allreasonable modes MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 31 Dec 2005 03:18:21.0086 (UTC) FILETIME=[DA191BE0:01C60DB8] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] RE: [issue21] Re7 (Relays):Proposeeliminatingrelaysbyrequiring PSAP to support allreasonable modes thread-index: AcYMteu1u91BHsj0QE6fSXW/Tp+XdQAs2LuAABOnyMA= X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Roger, I would prefer to change the motivation a bit as I think that assuming that the end-point request the mapping has quite a strong "tethered-terminal" centric view, something that I think will date very quickly. I think it unlikely that mobile device, for example, will operate in this manner. I would prefer something like: Motivate: While end device may be the initiators of mapping service request, Other mapping clients, such as relays, 3rd party devices, PSAPs, etc. may also trigger mapping requests." Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Roger Marshall > Sent: Saturday, 31 December 2005 5:11 AM > To: Henning; br@brianrosen.net; ecrit@ietf.org > Subject: RE: [Ecrit] RE: [issue21] Re7 > (Relays):Proposeeliminatingrelaysbyrequiring PSAP to support allreasonable > modes >=20 >=20 > Based on this discussion, I agree that the requirement (Re7) around > Relays is at it's foundation, architectural, and not really part of the > mapping function per se. Also, this original requirement discussed > conveyance of data through (or maybe despite) a Relay's presence, which > doesn't really seem to me to be a mapping protocol function. >=20 > So, I have replaced Re7 (existence of Relays), with what seems to be the > better discussion, that of initiating mapping from anywhere, anytime. >=20 > Change FROM: > Re7. DirectRelay Services: It SHOULD be possible to involve > relay services in the call for translation between different modes. >=20 > Motivation: It should be possible to connect the relay service so that > the direct flow of media to the emergency service is maintained. In > addition, it should be possible to convey telemetry data, such as data > from automobile crash sensors. >=20 > Change TO: > Re7. Ubiquiteous Triggering: It MUST be possible to invoke > the mapping protocol at any time, from any location, by any > client which supports the mapping protocol. >=20 > Motivation: While end devices are the typical initiators of > mapping service requests, it is also expected that other > mapping clients, such as relays, 3rd party devices, PSAPs, > etc. may also trigger a mapping request. >=20 >=20 > (Also, since I'm not thrilled with my own choice of the tag, "Ubiquitous > Triggering", I'm accepting offers for a better one.) >=20 > Roger Marshall >=20 >=20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 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