From ecrit-bounces@ietf.org Tue May 02 04:22:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faq9H-0006Nq-Ij; Tue, 02 May 2006 04:22:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faq9F-0006Lc-Ip for ecrit@ietf.org; Tue, 02 May 2006 04:22:21 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Faq9E-0006DT-59 for ecrit@ietf.org; Tue, 02 May 2006 04:22:21 -0400 Received: (qmail invoked by alias); 02 May 2006 08:22:18 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp043) with SMTP; 02 May 2006 10:22:18 +0200 X-Authenticated: #29516787 Message-ID: <445716BA.7090601@gmx.net> Date: Tue, 02 May 2006 04:22:18 -0400 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: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [Ecrit] Rechartering (Update) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, here is the latest list of milesontes: ----------- March 2006 Informational RFC containing terminology definitions and the requirements (Draft: "Requirements for Emergency Context Resolution with Internet Technologies"; draft-ietf-ecrit-requirements-*) May 2006 An Informational document describing the threats and security considerations (Example document: "Security Threats and Requirements for Emergency Call Marking and Mapping"; draft-ietf-ecrit-security-threats-*) March 2006 A Standards Track RFC describing how to identify a session set-up request is to an emergency response center (Draft: "A Uniform Resource Name (URN) for Services"; draft-ietf-ecrit-service-urn-*) Nov 2006 A Standards Track RFC describing how to route an emergency call based on location information (Example document: "LoST: A Location-to-Service Translation Protocol"; draft-ietf-ecrit-lost-*) August 2006 An Informational document describing the Mapping Protocol Architecture (Example document: "Location-to-URL Mapping Architecture and Framework"; draft-schulzrinne-ecrit-mapping-arch-*) December 2006 An Informational document describing the ECRIT Framework (Example documents are draft-schulzrinne-sipping-emergency-arch-02.txt and draft-polk-newton-ecrit-arch-considerations-02.txt) February 2006 A BCP document describing the emergency call support for devices. (Example document: "Best Current Practice for Communications Services in support of Emergency Calling"; draft-rosen-ecrit-phonebcp-*) --------- Comments? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 02 14:20:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FazTl-00041P-RA; Tue, 02 May 2006 14:20:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FazTk-00041E-VP for ecrit@ietf.org; Tue, 02 May 2006 14:20:08 -0400 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 1FazTk-0007xX-L4 for ecrit@ietf.org; Tue, 02 May 2006 14:20:08 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 02 May 2006 11:20:08 -0700 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 k42IK7RV010465; Tue, 2 May 2006 11:20:08 -0700 (PDT) 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); Tue, 2 May 2006 11:20:06 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.16.114]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 May 2006 11:20:06 -0700 Message-Id: <4.3.2.7.2.20060502131931.02921220@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 02 May 2006 13:20:05 -0500 To: Hannes Tschofenig , ecrit@ietf.org From: "James M. Polk" Subject: Re: [Ecrit] Rechartering (Update) In-Reply-To: <445716BA.7090601@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 02 May 2006 18:20:06.0483 (UTC) FILETIME=[09D30230:01C66E15] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org We've already missed the first and third dates, right? At 04:22 AM 5/2/2006 -0400, Hannes Tschofenig wrote: >Hi all, > >here is the latest list of milesontes: > >----------- > >March 2006 Informational RFC containing terminology >definitions and the requirements > >(Draft: "Requirements for Emergency Context Resolution with Internet >Technologies"; draft-ietf-ecrit-requirements-*) > >May 2006 An Informational document describing the threats >and security considerations > >(Example document: "Security Threats and Requirements for Emergency Call >Marking and Mapping"; draft-ietf-ecrit-security-threats-*) > >March 2006 A Standards Track RFC describing how to identify >a session set-up request is to an emergency response center > >(Draft: "A Uniform Resource Name (URN) for Services"; >draft-ietf-ecrit-service-urn-*) > >Nov 2006 A Standards Track RFC describing how to route an >emergency call based on location information > >(Example document: "LoST: A Location-to-Service Translation Protocol"; >draft-ietf-ecrit-lost-*) > >August 2006 An Informational document describing the Mapping >Protocol Architecture > >(Example document: "Location-to-URL Mapping Architecture and Framework"; >draft-schulzrinne-ecrit-mapping-arch-*) > >December 2006 An Informational document describing the ECRIT >Framework > >(Example documents are draft-schulzrinne-sipping-emergency-arch-02.txt and >draft-polk-newton-ecrit-arch-considerations-02.txt) > >February 2006 A BCP document describing the emergency call >support for devices. > >(Example document: "Best Current Practice for Communications Services in >support of Emergency Calling"; draft-rosen-ecrit-phonebcp-*) > >--------- > >Comments? > > >Ciao >Hannes > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 03 04:04:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbCLi-0007pO-7w; Wed, 03 May 2006 04:04:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbCLh-0007pJ-HJ for ecrit@ietf.org; Wed, 03 May 2006 04:04:41 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FbCLf-0002sX-2Y for ecrit@ietf.org; Wed, 03 May 2006 04:04:41 -0400 Received: (qmail invoked by alias); 03 May 2006 08:04:34 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp010) with SMTP; 03 May 2006 10:04:34 +0200 X-Authenticated: #29516787 Message-ID: <44586410.8080409@gmx.net> Date: Wed, 03 May 2006 10:04:32 +0200 From: Hannes Tschofenig 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] Rechartering (Update) References: <4.3.2.7.2.20060502131931.02921220@email.cisco.com> In-Reply-To: <4.3.2.7.2.20060502131931.02921220@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 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: , Errors-To: ecrit-bounces@ietf.org Hi James, you are certainly right that the requirements and the service URN document need to be finalized very soon. This was our estimate in February. We are obviously always too optimistic or not good enough to finalize the final bits of our documents. The requirements draft is pending on the validation issue. The security draft is waiting for reviews. We also need a draft update for the service URN draft. Ciao Hannes James M. Polk wrote: > We've already missed the first and third dates, right? > > At 04:22 AM 5/2/2006 -0400, Hannes Tschofenig wrote: > >> Hi all, >> >> here is the latest list of milesontes: >> >> ----------- >> >> March 2006 Informational RFC containing terminology >> definitions and the requirements >> >> (Draft: "Requirements for Emergency Context Resolution with Internet >> Technologies"; draft-ietf-ecrit-requirements-*) >> >> May 2006 An Informational document describing the threats >> and security considerations >> >> (Example document: "Security Threats and Requirements for Emergency >> Call Marking and Mapping"; draft-ietf-ecrit-security-threats-*) >> >> March 2006 A Standards Track RFC describing how to identify >> a session set-up request is to an emergency response center >> >> (Draft: "A Uniform Resource Name (URN) for Services"; >> draft-ietf-ecrit-service-urn-*) >> >> Nov 2006 A Standards Track RFC describing how to route an >> emergency call based on location information >> >> (Example document: "LoST: A Location-to-Service Translation Protocol"; >> draft-ietf-ecrit-lost-*) >> >> August 2006 An Informational document describing the Mapping >> Protocol Architecture >> >> (Example document: "Location-to-URL Mapping Architecture and Framework"; >> draft-schulzrinne-ecrit-mapping-arch-*) >> >> December 2006 An Informational document describing the ECRIT >> Framework >> >> (Example documents are draft-schulzrinne-sipping-emergency-arch-02.txt >> and draft-polk-newton-ecrit-arch-considerations-02.txt) >> >> February 2006 A BCP document describing the emergency call >> support for devices. >> >> (Example document: "Best Current Practice for Communications Services >> in support of Emergency Calling"; draft-rosen-ecrit-phonebcp-*) >> >> --------- >> >> Comments? >> >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 03 04:15:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbCVk-0003m9-TR; Wed, 03 May 2006 04:15:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbCVj-0003m4-Md for ecrit@ietf.org; Wed, 03 May 2006 04:15:03 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbCVh-00034i-4w for ecrit@ietf.org; Wed, 03 May 2006 04:15:03 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k438F0su004863 for ; Wed, 3 May 2006 10:15:00 +0200 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 k438ExUS000902 for ; Wed, 3 May 2006 10:15:00 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 May 2006 10:14:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 May 2006 10:10:22 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Update: Requirements Draft Thread-Index: AcZuiQadWVQmxEVGTQ+W1FL731HM2w== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 03 May 2006 08:14:59.0526 (UTC) FILETIME=[AB9AC660:01C66E89] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ecrit] Draft Update: Requirements Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, Roger compiled another version of the requirements draft. =20 http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-08.txt=20 PLEASE review the document; we want to finish it.=20 Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 03 11:23:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbJCP-0007dZ-Od; Wed, 03 May 2006 11:23:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbJCO-0007bh-Nv for ecrit@ietf.org; Wed, 03 May 2006 11:23:32 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FbJCM-0004Kk-AN for ecrit@ietf.org; Wed, 03 May 2006 11:23:32 -0400 Received: (qmail invoked by alias); 03 May 2006 15:23:28 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp020) with SMTP; 03 May 2006 17:23:28 +0200 X-Authenticated: #29516787 Message-ID: <4458CAEB.10303@gmx.net> Date: Wed, 03 May 2006 17:23:23 +0200 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, kamran.aquil@mitretek.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Subject: [Ecrit] Review comments on security doc X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, Kamran provided a review of the ECRIT security threats draft. Thank you Kamran! Ciao Hannes ------ Hannes below are my the comments as per reviewing the Security Doc _ http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-security-threats-01.txt . I have indicated the page and section number below to locate my findings. Rest of the document is well written and easily understood. Rgds.. Kamran Aquil Mitretek Systems. --------------------- Page 1 - Section Abstract I would recommend to elaborate the scope of the document in the Abstract section. It can be best done by bulletizing the two work items, instead of leaving it meshed among words of the Abstract Paragraph. The two work items considered in the Security document are - The Marking of signalling messages to indicate that they are related to an emergency - The Process of mapping location to Universal Resource identifiers (URI) pointing to public safety Answering points (PSAPs) ------------------------------------------------------------------------ -------------------- Page 3 - Section Introduction Attacks against the PSTN (most often focusing on free calling) have taken place for decades. The sentence in the Brackets - "most often focusing on free calling" needs to be explained further or eliminated. Seems out of context and may not be clear to the reader. ------------------------------------------------------------------------ ---------------------- Page 5 - Section Objective of attacker Third Bullet item - "No attacks affecting the ECRIT working group's decisions on the emergency identifier and mapping protocol have been identified that achieve this objective" The sentence structure does not convey the message. Please rewrite this sentence to make it understandable. Need clarity and be more concise. ------------------------------------------------------------------------ --------------------- Page 6 - Section 5.1 Item b is not clear and needs to be rewritten and restructured to make it clear and concise. Item c can be rewritten as C. The call enters the domain of a service provider by applying normal procedures for authentication and authorization because the signalling carries the emergency identifiers. ------------------------------------------------------------------------ ------------------------- Page 7 - Section 5.2.1 The heading should be "Attacks against Emergency mapping system" ------------------------------------------------------------------ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 03 12:47:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbKVm-0002Sn-GX; Wed, 03 May 2006 12:47:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbKVl-0002Si-92 for ecrit@ietf.org; Wed, 03 May 2006 12:47:37 -0400 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 1FbKVi-0007vL-Vs for ecrit@ietf.org; Wed, 03 May 2006 12:47:37 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 03 May 2006 09:47:36 -0700 X-IronPort-AV: i="4.05,85,1146466800"; d="scan'208"; a="321532188:sNHT28792786" 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 k43GlYh0000568; Wed, 3 May 2006 09:47:34 -0700 (PDT) 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); Wed, 3 May 2006 09:47:34 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.20.45]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 May 2006 09:47:30 -0700 Message-Id: <4.3.2.7.2.20060503114638.03908f08@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 03 May 2006 11:47:30 -0500 To: Hannes Tschofenig From: "James M. Polk" Subject: Re: [Ecrit] Rechartering (Update) In-Reply-To: <44586410.8080409@gmx.net> References: <4.3.2.7.2.20060502131931.02921220@email.cisco.com> <4.3.2.7.2.20060502131931.02921220@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 03 May 2006 16:47:31.0267 (UTC) FILETIME=[45121130:01C66ED1] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 10:04 AM 5/3/2006 +0200, Hannes Tschofenig wrote: >Hi James, > >you are certainly right that the requirements and the service URN document >need to be finalized very soon. This was our estimate in February. oh... I didn't read that what you had sent was past tense. sorry >We are obviously always too optimistic or not good enough to finalize the >final bits of our documents. > >The requirements draft is pending on the validation issue. >The security draft is waiting for reviews. >We also need a draft update for the service URN draft. > >Ciao >Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 03 12:53:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbKbA-0005G3-JQ; Wed, 03 May 2006 12:53:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbKb9-0005Fv-FJ for ecrit@ietf.org; Wed, 03 May 2006 12:53:11 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbKb7-0008FL-3L for ecrit@ietf.org; Wed, 03 May 2006 12:53:11 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 3 May 2006 09:53:07 -0700 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: [Ecrit] New requirements draft -08 available Date: Wed, 3 May 2006 09:53:07 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657504D646E9@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] New requirements draft -08 available Thread-Index: AcZjHoDHs0ywPyz2ToyZkOt5wehbuwAmhpYQAAImwPAAL1+Y4AAESMAwAmxcSiA= From: "Roger Marshall" To: , "Tschofenig, Hannes" , "Marc Linsner" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org As Hannes has already mentioned, I have submitted a new edition of the ECRIT requirements draft to the I-D editor. Until it appears in the archives, you can find it at the following link: http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-08.txt This version contains only a few changes, generally described below: Issues referred to are logged in the tracker (http://www.ietf-ecrit.org:8080/ecrit-req/index): A. Several issues had changes which were incorporated already into draft -07, but which I marked "Resolved" since there were no objections raised on the list. Issues which I have left open are:=20 38 yesterday Ma5. URI alternate contact =20 39 yesterday Ma6. URL properties =20 33 yesterday Location-dependent emergency dial string =20 36 4 weeks ago Id3 - Emergency identifier marking =20 (I will also mark these as "Resolved" within a few days from this email msg., assuming no objections come up on the list.) B. Additional issues have been addressed in draft -08, such as: 35 Location Validation (contains 3 NEW (proposed) requirements) 52 protocol specific - end devices out of scope=20 C. Bob Natale's text edits made it in this time (ref. email 3/19). Comments welcomed. Roger Marshall. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 03 15:50:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbNMI-0001FT-Fz; Wed, 03 May 2006 15:50:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbNMH-0001Ey-St; Wed, 03 May 2006 15:50:01 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbNMH-0007I2-LD; Wed, 03 May 2006 15:50:01 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k43Jo19W026399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FbNMH-0000rM-Ec; Wed, 03 May 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 03 May 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-requirements-08.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Requirements for Emergency Context Resolution with Internet Technologies Author(s) : H. Schulzrinne, R. Marshall Filename : draft-ietf-ecrit-requirements-08.txt Pages : 30 Date : 2006-5-3 This document enumerates requirements for the context resolution of emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-requirements-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-requirements-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-3145334.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-requirements-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-requirements-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-3145334.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Thu May 04 18:11:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbm2c-0001Hz-C9; Thu, 04 May 2006 18:11:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbm2b-0001ER-Lq for ecrit@ietf.org; Thu, 04 May 2006 18:11:21 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fbm2b-00018m-34 for ecrit@ietf.org; Thu, 04 May 2006 18:11:21 -0400 Received: (qmail invoked by alias); 04 May 2006 22:11:18 -0000 Received: from p54985C8A.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.92.138] by mail.gmx.net (mp039) with SMTP; 05 May 2006 00:11:18 +0200 X-Authenticated: #29516787 Message-ID: <445A7C03.2070407@gmx.net> Date: Fri, 05 May 2006 00:11:15 +0200 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, Tom-PT Taylor , "Shanmugam, Murugaraj" , Henning Schulzrinne 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: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: Subject: [Ecrit] Review of draft-ietf-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: , Errors-To: ecrit-bounces@ietf.org Hi all, here are some review comments for the draft-ietf-ecrit-security-threats-01.txt document. * Avoid mentioning the working group name in the text. For example, Change from: " This document reviews the security threats associated with the two current work items of the ECRIT Working Group. The first is the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ marking of signalling messages to indicate that they are related to an emergency. The second is the process of mapping from locations to Universal Resource Identifiers (URIs) pointing to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network. Based on the threats, this document establishes a set of security requirements for the the mapping protocol and for the handling of emergency-marked calls. " to: " This document reviews the security threats associated with marking of signalling messages to indicate that they are related to an emergency and the process of mapping from locations to Universal Resource Identifiers (URIs) pointing to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network. Based on the threats, this document establishes a set of security requirements for the the mapping protocol and for the handling of emergency-marked calls. " Additional examples: Section 4 describes some motivations of attackers in the context of ECRIT, ^^^^^^ Section 5 describes and illustrates the attacks that might be used, and Section 6 lists the security-related requirements that must be met if these attacks are to be mitigated. Section 3: The ECRIT Working Group has two work items relating to the routing of ^^^^^^^^^^^^^^^^^^^^ emergency calls to their proper destination. The first is to enable entities along the signalling path to recognize that a particular signalling message is associated with an emergency call. The ECRIT ^^^^^^ Working Group is defining content that can be added to the signalling ^^^^^^^^^^^^^^ messages, an emergency identifier, for this purpose. Signalling containing the emergency identifier may be given priority treatment, special processing, and/or special routing. The first goal of emergency call routing is to ensure that any emergency call is routed to a PSAP. Preferably the call is routed to the PSAP responsible for the caller's location, since misrouting consumes valuable time while the call taker locates and forwards the call to the right PSAP. As described in [I-D.ecrit-requirements], mapping, the second ECRIT work item, is part of the process of ^^^^^^^^^^^^^^^^^^^^^^ achieving this preferable outcome. Section 4: o to divert emergency responders to non-emergency sites. No attacks affecting the ECRIT Working Group's decisions on the emergency ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ identifier and mapping protocol have been identified that achieve this objective 6. Security requirements relating to ECRIT work items ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ delete Reason: The working group name is meaningless after some time. Furthermore, it does not make sense to refer to work items of the working group. * Technical Section 5.2.1: In an impersonation attack, the attacker induces the mapping client to direct its queries to a host under the attacker's control rather than the real mapping server. Impersonation itself is an issue for mapping server discovery rather than for the mapping protocol directly. Well, I am not sure. Authentication of the mapping server to the mapping client would help to detect whether you talk to a mapping server. Consider the HTTP protocol as an example. The FQDN -> IP address resolution using DNS is almost never secured (using DNSSEC). However, you often use server-to-client authentication as part of HTTPS. Hence, I suggest to rewrite the sentence in such a way that it points to both aspects: " Impersonation of the server towards the client is an issue for mapping server discovery as well as for the security mechanisms provided by the mapping protocol. " * Technical: Section 5.2.1: This section considers attacks intended to reduce the effectiveness of the emergency response system for all callers in a given area. If the mapping operation is disabled, the immediate effect is to increase the probability that emergency calls are routed to the wrong PSAP. If the mapping client cannot contact the mapping server then the it might not have a PSAP URI to start with unless we specify some failure handling mechanisms. Hence, I suggest to rewrite the sentence to: " If the mapping operation is disabled, then the emergency caller's device might not have the correct PSAP URI. As a consequence, the probability that emergency calls are routed to the wrong PSAP is increased. In the worst case the emergency caller's device might not be able to obtain a PSAP URI at all. " * Repetition: Section 5.2.3: The attacker may be seeking the location of the caller (e.g., to effect a criminal attack). The attacker may be seeking information that could be used to link an individual (the caller or someone else involved in the emergency) with embarrassing information related to the emergency (e.g., "Who did the police take away just now?"). I suggest to delete the first sentence. * Wording: 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119], with the qualification that unless otherwise stated they apply to the design of the mapping protocol, not its implementation or application. replace with 'usage' ^^^^^^^^^^^^^ * Section titles: The RFC editor expects the initials of each word in the title to be written with capital letters. A few examples: 3. Marking, Mapping, and the Emergency Call Routing Process 4. Objectives of Attackers 5. Potential Attacks 5.1. Attacks Involving the Emergency Identifier 5.2. Attacks Against or Using the Mapping Process etc. Furthermore, I think the editor would appreciate the following changes in Section 6: Change from: " Attack: insertion of interfering messages. ^ " to: " Attack: Insertion of interfering messages. ^ " etc. * Section 5.2.1: Editorial The other possible attack is one where the the mapping server is ^^^^ remove one 'the' tricked into sending responses to the target of the attack through spoofing of the source address in the query. * Abstract: Editorial: Based on the threats, this document establishes a set of security requirements for the the mapping protocol and for the handling of emergency-marked ^^^ delete calls. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu May 04 21:34:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbpCd-0003pZ-Gq; Thu, 04 May 2006 21:33:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbpCc-0003pU-V6 for ecrit@ietf.org; Thu, 04 May 2006 21:33:54 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbpCb-0000kE-JR for ecrit@ietf.org; Thu, 04 May 2006 21:33:54 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k451XnM13621; Thu, 4 May 2006 21:33:50 -0400 (EDT) Received: from [127.0.0.1] ([47.130.25.113] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 May 2006 21:33:49 -0400 Message-ID: <445AAB70.5060505@nortel.com> Date: Thu, 04 May 2006 21:33:36 -0400 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Hannes Tschofenig References: <445A7C03.2070407@gmx.net> In-Reply-To: <445A7C03.2070407@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 May 2006 01:33:49.0521 (UTC) FILETIME=[F596FC10:01C66FE3] X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: ecrit@ietf.org, "Shanmugam, Murugaraj" Subject: [Ecrit] Re: Review of draft-ietf-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: , Errors-To: ecrit-bounces@ietf.org Thanks for your careful review. A couple of responses inline. Hannes Tschofenig wrote: > Hi all, > > here are some review comments for the > draft-ietf-ecrit-security-threats-01.txt document. > > * Avoid mentioning the working group name in the text. For example, > ... [PTT] OK > > * Technical > > Section 5.2.1: > > In an impersonation attack, the attacker induces the mapping client > to direct its queries to a host under the attacker's control rather > than the real mapping server. Impersonation itself is an issue for > mapping server discovery rather than for the mapping protocol > directly. > > Well, I am not sure. Authentication of the mapping server to the mapping > client would help to detect whether you talk to a mapping server. > Consider the HTTP protocol as an example. The FQDN -> IP address > resolution using DNS is almost never secured (using DNSSEC). However, > you often use server-to-client authentication as part of HTTPS. > > Hence, I suggest to rewrite the sentence in such a way that it points to > both aspects: > " > Impersonation of the server towards the client is an issue for mapping > server discovery as well as for the security mechanisms provided by the > mapping protocol. > " [PTT] Guess it's a matter of point of view. I see discovery as the primary issue, but being able to detect impersonation is essential for any recovery to be possible, and may also discourage the attack. What I suggest I do is generalize the next sentence beyond your quotation. It currently reads: "However, the mapping protocol may help to protect against acceptance of responses from an impersonating entity." Perhaps it should read: "However, the mapping protocol may allow impersonation to be detected, thereby preventing acceptance of responses from an impersonating entity and possibly triggering a more secure discovery procedure." > > * Technical: > > Section 5.2.1: > > This section considers attacks intended to reduce the effectiveness > of the emergency response system for all callers in a given area. If > the mapping operation is disabled, the immediate effect is to > increase the probability that emergency calls are routed to the wrong > PSAP. > > If the mapping client cannot contact the mapping server then the it > might not have a PSAP URI to start with unless we specify some failure > handling mechanisms. Hence, I suggest to rewrite the sentence to: > > " > If > the mapping operation is disabled, then the emergency caller's > device might not have the correct PSAP URI. As a consequence, the > probability that emergency calls are routed to the wrong PSAP is > increased. In the worst case the emergency caller's device might not be > able to obtain a PSAP URI at all. " > [PTT] OK > > * Repetition: > > Section 5.2.3: > > The attacker may be seeking the location of the caller > (e.g., to effect a criminal attack). The attacker may be seeking > information that could be used to link an individual (the caller or > someone else involved in the emergency) with embarrassing information > related to the emergency (e.g., "Who did the police take away just > now?"). > > I suggest to delete the first sentence. [PTT] The first sentence describes a different motivation from the rest. Think of a victim of attempted rape who has escaped her attacker and is calling for help, while the attacker searches for her. The rest of the paragraph describes a moderately less nasty situation. > > * Wording: > > 2. Terminology > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119], with the > qualification that unless otherwise stated they apply to the design > of the mapping protocol, not its implementation or application. > replace with 'usage' ^^^^^^^^^^^^^ > [PTT] OK > * Section titles: The RFC editor expects the initials of each word in > the title to be written with capital letters. > [PTT] OK, never noticed before. Differs from the convention in another SDO I edit for. ... > Furthermore, I think the editor would appreciate the following changes > in Section 6: > > Change from: > " > Attack: insertion of interfering messages. > ^ > " > to: > " > Attack: Insertion of interfering messages. > ^ > " [PTT] That bothers me -- a colon separates parts of a sentence -- it doesn't begin a new one. I just finished telling someone else to use small letters in their I-D in this situation. > etc. > > > * Section 5.2.1: Editorial > OK to the rest ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 05 03:06:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbuOW-0004Re-IY; Fri, 05 May 2006 03:06:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbuOV-0004Qo-JC for ecrit@ietf.org; Fri, 05 May 2006 03:06:31 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FbuOV-0004P6-1G for ecrit@ietf.org; Fri, 05 May 2006 03:06:31 -0400 Received: (qmail invoked by alias); 05 May 2006 07:06:29 -0000 Received: from p54985C8A.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.92.138] by mail.gmx.net (mp009) with SMTP; 05 May 2006 09:06:29 +0200 X-Authenticated: #29516787 Message-ID: <445AF96D.9060500@gmx.net> Date: Fri, 05 May 2006 09:06:21 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom-PT Taylor References: <445A7C03.2070407@gmx.net> <445AAB70.5060505@nortel.com> In-Reply-To: <445AAB70.5060505@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: ecrit@ietf.org, "Shanmugam, Murugaraj" Subject: [Ecrit] Re: Review of draft-ietf-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: , Errors-To: ecrit-bounces@ietf.org Hi Tom, thanks for your quick response. Tom-PT Taylor wrote: > Thanks for your careful review. A couple of responses inline. > > Hannes Tschofenig wrote: > >> Hi all, >> >> here are some review comments for the >> draft-ietf-ecrit-security-threats-01.txt document. >> >> * Avoid mentioning the working group name in the text. For example, >> > ... > > [PTT] OK > >> >> * Technical >> >> Section 5.2.1: >> >> In an impersonation attack, the attacker induces the mapping client >> to direct its queries to a host under the attacker's control rather >> than the real mapping server. Impersonation itself is an issue for >> mapping server discovery rather than for the mapping protocol >> directly. >> >> Well, I am not sure. Authentication of the mapping server to the >> mapping client would help to detect whether you talk to a mapping >> server. Consider the HTTP protocol as an example. The FQDN -> IP >> address resolution using DNS is almost never secured (using DNSSEC). >> However, you often use server-to-client authentication as part of HTTPS. >> >> Hence, I suggest to rewrite the sentence in such a way that it points >> to both aspects: >> " >> Impersonation of the server towards the client is an issue for mapping >> server discovery as well as for the security mechanisms provided by >> the mapping protocol. >> " > > > [PTT] Guess it's a matter of point of view. I see discovery as the > primary issue, but being able to detect impersonation is essential for > any recovery to be possible, and may also discourage the attack. What I > suggest I do is generalize the next sentence beyond your quotation. It > currently reads: > > "However, the mapping protocol may help to protect against > acceptance of responses from an impersonating entity." > > Perhaps it should read: > > "However, the mapping protocol may allow impersonation to be detected, > thereby preventing acceptance of responses from an impersonating entity > and possibly triggering a more secure discovery procedure." Sounds good to me. > >> >> * Technical: >> >> Section 5.2.1: >> >> This section considers attacks intended to reduce the effectiveness >> of the emergency response system for all callers in a given area. If >> the mapping operation is disabled, the immediate effect is to >> increase the probability that emergency calls are routed to the wrong >> PSAP. >> >> If the mapping client cannot contact the mapping server then the it >> might not have a PSAP URI to start with unless we specify some failure >> handling mechanisms. Hence, I suggest to rewrite the sentence to: >> >> " >> If >> the mapping operation is disabled, then the emergency caller's >> device might not have the correct PSAP URI. As a consequence, the >> probability that emergency calls are routed to the wrong PSAP is >> increased. In the worst case the emergency caller's device might not >> be able to obtain a PSAP URI at all. " >> > [PTT] OK > >> >> * Repetition: >> >> Section 5.2.3: >> >> The attacker may be seeking the location of the caller >> (e.g., to effect a criminal attack). The attacker may be seeking >> information that could be used to link an individual (the caller or >> someone else involved in the emergency) with embarrassing information >> related to the emergency (e.g., "Who did the police take away just >> now?"). >> >> I suggest to delete the first sentence. > > > [PTT] The first sentence describes a different motivation from the rest. > Think of a victim of attempted rape who has escaped her attacker and is > calling for help, while the attacker searches for her. The rest of the > paragraph describes a moderately less nasty situation. Hmmm. That's not obvious from the first sentence. I slightly changed the beginning of the second sentence to make it look different. " The attacker may be seeking the location of the caller (e.g., to effect a criminal attack). Additionally, the adversary might want to collect information that could be used to link an individual ..... " > >> >> * Wording: >> >> 2. Terminology >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in [RFC2119], with the >> qualification that unless otherwise stated they apply to the design >> of the mapping protocol, not its implementation or application. >> replace with 'usage' ^^^^^^^^^^^^^ >> > [PTT] OK > >> * Section titles: The RFC editor expects the initials of each word in >> the title to be written with capital letters. >> > [PTT] OK, never noticed before. Differs from the convention in another > SDO I edit for. I bet it is different. I noticed this aspect with past documents and I think we should make the job of the editor easier. Additionally, we might want to check the punctuation since this is also a source of a lot of editing bugs. I am, however, not the best person todo that. > > ... > >> Furthermore, I think the editor would appreciate the following changes >> in Section 6: >> >> Change from: >> " >> Attack: insertion of interfering messages. >> ^ >> " >> to: >> " >> Attack: Insertion of interfering messages. >> ^ >> " > > [PTT] That bothers me -- a colon separates parts of a sentence -- it > doesn't begin a new one. I just finished telling someone else to use > small letters in their I-D in this situation. OK. Let us see what the editor thinks. Ciao Hannes > >> etc. >> >> >> * Section 5.2.1: Editorial >> > OK to the rest > ... > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 05 08:22:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbzK8-00023I-QW; Fri, 05 May 2006 08:22:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbzK8-00023D-07 for ecrit@ietf.org; Fri, 05 May 2006 08:22:20 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FbzK7-0001Gj-3z for ecrit@ietf.org; Fri, 05 May 2006 08:22:19 -0400 Received: (qmail invoked by alias); 05 May 2006 12:21:58 -0000 Received: from p54985930.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.89.48] by mail.gmx.net (mp039) with SMTP; 05 May 2006 14:21:58 +0200 X-Authenticated: #29516787 Message-ID: <445B4362.2070408@gmx.net> Date: Fri, 05 May 2006 14:21:54 +0200 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, Henning Schulzrinne , Roger Marshall 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: 916029c14bdb340aa234d3ec4cd24f52 Cc: Subject: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, here is a review of draft-ietf-ecrit-requirements-08.txt. The document is getting much better. Still, I have a few comments: * Introduction: I would delete this paragraph since it is a bit confusing at this point: As used in this document, validation of location does not require that we ascertain as to whether or not the location actually exists. For example, validation might only check that the house number in a civic address falls within the assigned range, not whether a building, known by a specific building number, exists at that location. However, such higher precision validation is desirable. This might be relevant in subsequent sections. Identification of the caller, while not incompatible with the requirements for messaging outlined within this document, is considered to be outside the scope of the ECRIT charter. ^^^^^^^^^^^^^^^^^^ Don't mention the working group name in the document. Write "... is outside the scope of this document." 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, for example, a TEL URI which may be used to complete a call via the PSTN. I am not sure about this paragraph. Where do we provide such a functionality? * Terminology I would cluster the terms. For example, you might want to keep - (Location-dependent) emergency dial string - Home emergency dial string - Visited emergency dial string together to make the terminology easier to read. There is no requirement to list the terms alphabetically. Emergency address: The URI (e.g., SIP:URI, SIPS:URI, XMPP:URI, IM: ^^^^^^^ change to identifier URI, etc.) which represents the address of the PSAP useful for the completion of an emergency call. Emergency call routing support: An intermediary function which assists in the routing of an emergency call via IP. An ESRP is an example of an Emergency call routing support entity. ^^^^^^^^^ emergency Delete the following paragraph: Codes: "caller" or "emergency caller" refers to the person placing an emergency call or sending an emergency instant message (IM). AND move the text over to this term: Emergency caller: The user or user device entity which sends his/her location to another entity in the network. As such, it would read: (Emergency) caller: The term "caller" or "emergency caller" refer to the person placing an emergency call or sending an emergency instant message (IM). In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1], with the qualification that unless otherwise stated these words apply to the design of the mapping protocol, not its implementation or application. ^^^^^^^^^^^ usage With the suggested change from "Emergency address" to "Emergency identifer" we have the term 'emergency identifier' appearing twice: Emergency identifier: An identifier that marks a call as an emergency call. I suggest to delete this definition or to merge it with the previous one. In the text we should always use small letters for terms like 'mapping servers' or 'mapping clients'. For example, Mapping client: A mapping client interacts with the Mapping Server to ^^^^^^^^^^^^^^ learn one or more PSAP URIs for a given location. Mapping server: The Mapping Server holds information about the ^^^^^^^^^^^^^^ location-to-PSAP URI mapping. Change from: " PSAP URI: PSAP URI is a general term, used to refer to the output of the mapping protocol, and represents either the actual PSAP IP address, or the IP address of some other intermediary, e.g., an ESRP, which points to the actual PSAP. " to: " PSAP URI: The term 'PSAP URI' refers to a URI that identifiers a PSAP. We use this term to denote the reponse of a mapping protocol query. " * Section 3. Basic Actors In order to support emergency services covering a large physical area, various infrastructure elements are necessary, including: Internet Attachment Providers (IAPs), Application/Voice Service Providers (ASP/VSPs), PSAPs as endpoints for emergency calls, mapping ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ delete this part; the PSAP is only one endpoint of the communciation. services or other infrastructure elements that assist during the call ^^^ and routing. o How is location information provided to the end host? It might either be known to the end host itself via manual configuration, provided via GPS, or obtained via a third party method. Even if location information is known to the network it might be made available to the end host via DHCP (RFC 3825 [2]) or some other mechanism. Alternatively, location information is used as part of call routing and inserted by intermediaries. Change paragraph to: o How is location information provided to the end host? It might either be known to the end host itself via manual configuration, provided via GPS, made available via DHCP (see RFC 3825 [2]) or some other mechanisms. Alternatively, location information is used as part of call routing and inserted by intermediaries. (5) Location Information is used by emergency call routing entities ^^^^^^^^^^^ information for subsequent mapping requests. 4. High-Level Requirements Re1. Application/Voice service provider existence: The initiation of an IP-based emergency call SHOULD NOT assume the existence of an Application/Voice Service Provider (ASP/VSP). Motivation: The caller may not have an application/voice service provider. For example, a residence may have its own DNS domain and run its own SIP proxy server for that domain. On a larger scale, a university might provide voice services to its students and staff, but not be a telecommunication provider. ^ add "might" 5. Identifying the Caller's Location Location can either be provided directly, or by reference, and represents either a civic location, or as a geographic location. ^^ and geospatial location information. How does the location (or location reference) become associated with the call? change last sentence to: "An important question is how and when to attach location information to the VoIP emergency signaling." In general, we can distinguish three modes of operation of how a location is associated with an emergency call: Change from: UA-inserted: The caller's user agent inserts the location information into the call signaling message. The location information is derived from sources such as GPS, DHCP (RFC 3825 [2]) and I-D.ietf-geopriv-dhcp-civil [7]) or utilizing the Link Layer Discovery Protocol (LLDP) [see IEEE8021AB]. to: UA-inserted: The caller's user agent inserts the location information into the call signaling message. The location information is derived from sources such as GPS, DHCP (see [2] for geospatial location information and [7] for civic location information) or utilizing the Link Layer Discovery Protocol (LLDP) (see [IEEE8021AB]). UA-referenced: The caller's user agent provides a pointer (i.e., a location reference), via a permanent or temporary identifier, to the location which is stored by a location service somewhere else ^^^^^^^ server delete the 'somewhere else' part. and then retrieved by the PSAP, ESRP, or other authorized service entity. Lo2. Location object/info preservation: The mapping protocol MUST retain any location information which is provided to it, even after mapping is performed. Motivation: The ESRP and the PSAP use the same location information object, but for a different purpose. Therefore, it is imperative that the mapping protocol not remove location ^ does Information so that the PSAP can still receive the caller ^^^^^^^^^^^ information location. Lo5. Validation of civic location: The mapping protocol MUST support location validation for civic location (street addresses), prior to initiating an emergency call. delete the ", prior to initiating an emergency call." part. Motivation: Location validation provides an opportunity to help assure ahead of time, whether or not successful mapping to the ^ add 'a' appropriate PSAP will likely occur when it is required. Validation may also help to avoid delays during emergency call setup due to invalid locations. Isn't Lo7 similar to L10? Isn't Lo6 similar to Lo11? Lo9. 3D sensitive mapping: The mapping protocol MUST implement support for both 2D and 3D location information, and may accept either a 2D or 3D mapping request as input. Motivation: It is expected that provisioning systems will accept ^^^^^^^^^^^^^^^^^^^^ what is that? 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 in the request. 6. Emergency Identifier Id1. Emergency identifier support: The mapping protocol MUST support one or more emergency identifiers for delivery back to mapping clients to be used for call setup purposes. I guess this requirement should say: " Emergency identifier support: The mapping protocol MUST be able to return one or multiple emergency identifiers in response to a query. " Id2. Emergency identifier resolution: Where multiple emergency identifiers exist, the mapping protocol MUST be able to differentiate between identifiers based on the specific type of emergency help requested. Motivation: Some jurisdictions may have multiple types of emergency services available, (e.g., fire, police, ambulance), in which case, it is important that any one could be selected directly. There is a terminology confusion here: I think you refer to 'sos Service Types' here rather than multiple emergency identifers. You might want to double-check with http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-02.txt (and in particular with Section 4.3). This terminology issue impacts also requirement Id5. Id4. Prevention of fraud: If a call is identified as an emergency call, the mapping protocol MUST support that call being successfully routed to a PSAP. Motivation: This prevents use of the emergency call indication to gain access to call features or authentication override for non- emergency purposes. This requirement is covered in the security document. Requirement Id6, Id7, Id8, Id9, Id10 start with "The mapping protocol MUST/SHOULD support " but I think that these requirements do not necessarily address the mapping protocol. I think a "There MUST be support for...." 7. Mapping Protocol There are two basic approaches to invoking a mapping service. We ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ invoke the mapping protocol. refer to these as caller-based and mediated. In each case, the mapping client initiates a request to a mapping server via a mapping protocol. A proposed mapping protocol is outlined in the document I-D.hardie-ecrit-lost [6]. For caller-based resolution, the caller's user agent invokes a ^ the mapping service to determine the appropriate PSAP based on the ^^^^^^^ protocol location provided. The resolution may take place well before the actual emergency call is placed, or at the time of the call. For mediated resolution, a call signaling server, such as a SIP ^^^^^^^^^^^^^^^^^^^^^^^ an emergency call routing support entity (outbound) proxy or redirect server invokes the mapping service. Ma5. URI alternate contact: In addition to returning a primary contact, the mapping protocol MUST support the return of a URI or contact method explicitly marked as an alternate contact. Motivation: In response to a mapping request, the mapping server may return an alternate URI. Implementation details to be described within an operational document. I am not quite sure about Ma6 and Ma8. Ma8 tells me that the mapping protocol provides a URL for error reporting. Isn't Ma6 similar? Ma6. URL properties: The mapping protocol MUST support the ability ^^^ URI to provide ancillary information about a contact or URI that ^^^^^^ delete allows the mapping client to determine relevant properties of the URL. ^^^^ URI? Motivation: In some cases, the same geographic area is served by several PSAPs, for example, a corporate campus might be served by both a corporate security department and the municipal PSAP. The mapping protocol should then return URLs for both, with ^^^^ URIs information allowing the querying entity to choose one or the other. This determination could be made by either an ESRP, based on local policy, or by direct user choice, in the case of caller- based methods. Ma7. Traceable resolution: The mapping protocol SHOULD support the ability of the mapping client to be able to determine the entity or entities which provided the emergency address resolution ^^^^^ that information. Motivation: It is important for public safety reasons, that there is a method to provide operational traceability in case of errors. Ma8. URI for error reporting: The mapping protocol MUST support the ^^^^ URL return of a URI that can be used to report a suspected or known ^^^^^^^^^^^^^^^ the ability to return a URL error within the mapping database. Motivation: If an error is returned, for example, there needs to be a URI which points to a resource which can explain or ^^^^ URL potentially help resolve the error. Ma16. Multiple PSAP URIs: The mapping protocol MUST support a method to receive multiple PSAP URIs which cover the same geographic ^^^^^^^ return area. Motivation: Two different mapping servers may cover the same geographic area, and therefore have the same set of coverage information. Isn't this requirement very similar to Ma4? * 8. Security Considerations Security considerations are discussed in the ECRIT security document I-D.ietf-ecrit-security-threats [4] . Write: " Threats and security requirements are discussed in a separate document, see [4]. " * Add an IANA section. " 9. IANA Considerations This document does not require actions by the IANA. " Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 05 08:52:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbznI-0007gy-Vb; Fri, 05 May 2006 08:52:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbznH-0007gt-98 for ecrit@ietf.org; Fri, 05 May 2006 08:52:27 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbznG-0002lp-Jx for ecrit@ietf.org; Fri, 05 May 2006 08:52:27 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k45ClOC22122; Fri, 5 May 2006 08:47:24 -0400 (EDT) Received: from [127.0.0.1] ([47.130.16.43] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 08:52:07 -0400 Message-ID: <445B4A71.50006@nortel.com> Date: Fri, 05 May 2006 08:52:01 -0400 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt References: <445B4362.2070408@gmx.net> In-Reply-To: <445B4362.2070408@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 May 2006 12:52:07.0299 (UTC) FILETIME=[B75B1530:01C67042] X-Spam-Score: 0.0 (/) X-Scan-Signature: 231d7929942febf3be8fd5be2903302f Cc: Roger Marshall , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org There is a functional distinction between something that identifies the call as an emergency call (and must be present even after mapping has been performed so that downstream elements are aware of the nature of the call) and something that says where the call should be directed. By calling them both 'identifier' you lose this distinction. I think it is important that we keep it. Hannes Tschofenig wrote: > Hi all, > > here is a review of draft-ietf-ecrit-requirements-08.txt. The document > is getting much better. Still, I have a few comments: > > * Introduction: > > > I would delete this paragraph since it is a bit confusing at this point: > > As used in this document, validation of location does not require > that we ascertain as to whether or not the location actually exists. > For example, validation might only check that the house number in a > civic address falls within the assigned range, not whether a > building, known by a specific building number, exists at that > location. However, such higher precision validation is desirable. > > This might be relevant in subsequent sections. > > > > Identification of the caller, while not incompatible with the > requirements for messaging outlined within this document, is > considered to be outside the scope of the ECRIT charter. > ^^^^^^^^^^^^^^^^^^ > > Don't mention the working group name in the document. > > Write "... is outside the scope of this document." > > > 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, for example, a TEL > URI which may be used to complete a call via the PSTN. > > I am not sure about this paragraph. Where do we provide such a > functionality? > > * Terminology > > I would cluster the terms. For example, you might want to keep > - (Location-dependent) emergency dial string > - Home emergency dial string > - Visited emergency dial string > together to make the terminology easier to read. > > There is no requirement to list the terms alphabetically. > > > Emergency address: The URI (e.g., SIP:URI, SIPS:URI, XMPP:URI, IM: > ^^^^^^^ change to identifier > URI, etc.) which represents the address of the PSAP useful for the > completion of an emergency call. > > Emergency call routing support: An intermediary function which > assists in the routing of an emergency call via IP. An ESRP is an > example of an Emergency call routing support entity. > ^^^^^^^^^ emergency > > > Delete the following paragraph: > > Codes: "caller" or "emergency caller" refers to the person placing an > emergency call or sending an emergency instant message (IM). > > AND move the text over to this term: > > Emergency caller: The user or user device entity which sends his/her > location to another entity in the network. > > As such, it would read: > > (Emergency) caller: The term "caller" or "emergency caller" refer to > the person placing an emergency call or sending an emergency instant > message (IM). > > > > In this document, the key words "MUST", "MUST NOT", "REQUIRED", > "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", > and "OPTIONAL" are to be interpreted as described in RFC 2119 [1], > with the qualification that unless otherwise stated these words apply > to the design of the mapping protocol, not its implementation or > application. > ^^^^^^^^^^^ usage > > > With the suggested change from "Emergency address" to "Emergency > identifer" we have the term 'emergency identifier' appearing twice: > > Emergency identifier: An identifier that marks a call as an emergency > call. > > I suggest to delete this definition or to merge it with the previous one. > > In the text we should always use small letters for terms like 'mapping > servers' or 'mapping clients'. For example, > > Mapping client: A mapping client interacts with the Mapping Server to > ^^^^^^^^^^^^^^ > learn one or more PSAP URIs for a given location. > > > Mapping server: The Mapping Server holds information about the > ^^^^^^^^^^^^^^ > location-to-PSAP URI mapping. > > > Change from: > > " > PSAP URI: PSAP URI is a general term, used to refer to the output of > the mapping protocol, and represents either the actual PSAP IP > address, or the IP address of some other intermediary, e.g., an > ESRP, which points to the actual PSAP. > " > > to: > > " > PSAP URI: The term 'PSAP URI' refers to a URI that identifiers a > PSAP. We use this term to denote the reponse of a mapping protocol query. > " > > * Section 3. Basic Actors > > In order to support emergency services covering a large physical > area, various infrastructure elements are necessary, including: > Internet Attachment Providers (IAPs), Application/Voice Service > Providers (ASP/VSPs), PSAPs as endpoints for emergency calls, mapping > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ delete > this part; the PSAP is only one endpoint of the communciation. > > services or other infrastructure elements that assist during the call > ^^^ and > routing. > > > o How is location information provided to the end host? It might > either be known to the end host itself via manual configuration, > provided via GPS, or obtained via a third party method. Even if > location information is known to the network it might be made > available to the end host via DHCP (RFC 3825 [2]) or some other > mechanism. Alternatively, location information is used as part of > call routing and inserted by intermediaries. > > > Change paragraph to: > > o How is location information provided to the end host? It might > either be known to the end host itself via manual configuration, > provided via GPS, made > available via DHCP (see RFC 3825 [2]) or some other > mechanisms. Alternatively, location information is used as part of > call routing and inserted by intermediaries. > > > (5) Location Information is used by emergency call routing entities > ^^^^^^^^^^^ information > for subsequent mapping requests. > > 4. High-Level Requirements > > Re1. Application/Voice service provider existence: The initiation of > an IP-based emergency call SHOULD NOT assume the existence of an > Application/Voice Service Provider (ASP/VSP). > > Motivation: The caller may not have an application/voice service > provider. For example, a residence may have its own DNS domain > and run its own SIP proxy server for that domain. On a larger > scale, a university might provide voice services to its students > and staff, but not be a telecommunication provider. > ^ add "might" > > > 5. Identifying the Caller's Location > > Location can either be provided directly, or by reference, and > represents either a civic location, or as a geographic location. > ^^ and geospatial location > information. > > How > does the location (or location reference) become associated with the > call? > > change last sentence to: > > "An important question is how and when to attach location information to > the VoIP emergency signaling." > > In general, we can distinguish three modes of operation of how > a location is associated with an emergency call: > > Change from: > > UA-inserted: The caller's user agent inserts the location information > into the call signaling message. The location information is > derived from sources such as GPS, DHCP (RFC 3825 [2]) and > I-D.ietf-geopriv-dhcp-civil [7]) or utilizing the Link Layer > Discovery Protocol (LLDP) [see IEEE8021AB]. > > > to: > > > UA-inserted: The caller's user agent inserts the location information > into the call signaling message. The location information is > derived from sources such as GPS, DHCP (see [2] for geospatial > location information and [7] for civic location information) or > utilizing the Link Layer > Discovery Protocol (LLDP) (see [IEEE8021AB]). > > > UA-referenced: The caller's user agent provides a pointer (i.e., a > location reference), via a permanent or temporary identifier, to > the location which is stored by a location service somewhere else > ^^^^^^^ server > delete the 'somewhere else' part. > and then retrieved by the PSAP, ESRP, or other authorized service > entity. > > Lo2. Location object/info preservation: The mapping protocol MUST > retain any location information which is provided to it, even > after mapping is performed. > > Motivation: The ESRP and the PSAP use the same location > information object, but for a different purpose. Therefore, it is > imperative that the mapping protocol not remove location > ^ does > Information so that the PSAP can still receive the caller > ^^^^^^^^^^^ information > location. > > > Lo5. Validation of civic location: The mapping protocol MUST support > location validation for civic location (street addresses), prior > to initiating an emergency call. > > delete the ", prior to initiating an emergency call." part. > > Motivation: Location validation provides an opportunity to help > assure ahead of time, whether or not successful mapping to the > ^ add 'a' > appropriate PSAP will likely occur when it is required. > Validation may also help to avoid delays during emergency call > setup due to invalid locations. > > > Isn't Lo7 similar to L10? > Isn't Lo6 similar to Lo11? > > > Lo9. 3D sensitive mapping: The mapping protocol MUST implement > support for both 2D and 3D location information, and may accept > either a 2D or 3D mapping request as input. > > Motivation: It is expected that provisioning systems will accept > ^^^^^^^^^^^^^^^^^^^^ what is that? > > 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 in the request. > > > 6. Emergency Identifier > > Id1. Emergency identifier support: The mapping protocol MUST support > one or more emergency identifiers for delivery back to mapping > clients to be used for call setup purposes. > > I guess this requirement should say: > > " > Emergency identifier support: The mapping protocol MUST be able to > return one or multiple emergency identifiers in response to a query. > " > > > > Id2. Emergency identifier resolution: Where multiple emergency > identifiers exist, the mapping protocol MUST be able to > differentiate between identifiers based on the specific type of > emergency help requested. > > Motivation: Some jurisdictions may have multiple types of > emergency services available, (e.g., fire, police, ambulance), in > which case, it is important that any one could be selected > directly. > > There is a terminology confusion here: > I think you refer to 'sos Service Types' here rather than multiple > emergency identifers. You might want to double-check with > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-02.txt > (and in particular with Section 4.3). > > This terminology issue impacts also requirement Id5. > > Id4. Prevention of fraud: If a call is identified as an emergency > call, the mapping protocol MUST support that call being > successfully routed to a PSAP. > > Motivation: This prevents use of the emergency call indication to > gain access to call features or authentication override for non- > emergency purposes. > > This requirement is covered in the security document. > > > Requirement Id6, Id7, Id8, Id9, Id10 start with "The mapping protocol > MUST/SHOULD support " but I think that these requirements do not > necessarily address the mapping protocol. I think a "There MUST be > support for...." > > > 7. Mapping Protocol > > There are two basic approaches to invoking a mapping service. We > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > invoke the mapping protocol. > > refer to these as caller-based and mediated. In each case, the > mapping client initiates a request to a mapping server via a mapping > protocol. A proposed mapping protocol is outlined in the document > I-D.hardie-ecrit-lost [6]. > > For caller-based resolution, the caller's user agent invokes a > ^ the > mapping service to determine the appropriate PSAP based on the > ^^^^^^^ protocol > location provided. The resolution may take place well before the > actual emergency call is placed, or at the time of the call. > > For mediated resolution, a call signaling server, such as a SIP > ^^^^^^^^^^^^^^^^^^^^^^^ > an emergency call routing support entity > > (outbound) proxy or redirect server invokes the mapping service. > > > Ma5. URI alternate contact: In addition to returning a primary > contact, the mapping protocol MUST support the return of a URI or > contact method explicitly marked as an alternate contact. > > Motivation: In response to a mapping request, the mapping server > may return an alternate URI. Implementation details to be > described within an operational document. > > > I am not quite sure about Ma6 and Ma8. Ma8 tells me that the mapping > protocol provides a URL for error reporting. Isn't Ma6 similar? > > > Ma6. URL properties: The mapping protocol MUST support the ability > ^^^ URI > > to provide ancillary information about a contact or URI that > ^^^^^^ delete > allows the mapping client to determine relevant properties of the > URL. > ^^^^ URI? > > > Motivation: In some cases, the same geographic area is served by > several PSAPs, for example, a corporate campus might be served by > both a corporate security department and the municipal PSAP. The > mapping protocol should then return URLs for both, with > ^^^^ URIs > information allowing the querying entity to choose one or the > other. This determination could be made by either an ESRP, based > on local policy, or by direct user choice, in the case of caller- > based methods. > > Ma7. Traceable resolution: The mapping protocol SHOULD support the > ability of the mapping client to be able to determine the entity > or entities which provided the emergency address resolution > ^^^^^ that > information. > > Motivation: It is important for public safety reasons, that there > is a method to provide operational traceability in case of errors. > > Ma8. URI for error reporting: The mapping protocol MUST support the > ^^^^ URL > > return of a URI that can be used to report a suspected or known > ^^^^^^^^^^^^^^^ the ability to return a URL > > error within the mapping database. > > Motivation: If an error is returned, for example, there needs to > be a URI which points to a resource which can explain or > ^^^^ URL > > potentially help resolve the error. > > > Ma16. Multiple PSAP URIs: The mapping protocol MUST support a method > to receive multiple PSAP URIs which cover the same geographic > ^^^^^^^ return > area. > > Motivation: Two different mapping servers may cover the same > geographic area, and therefore have the same set of coverage > information. > > Isn't this requirement very similar to Ma4? > > > > > * 8. Security Considerations > > Security considerations are discussed in the ECRIT security document > I-D.ietf-ecrit-security-threats [4] . > > Write: > > " > Threats and security requirements are discussed in a separate document, > see [4]. > " > > * Add an IANA section. > " > 9. IANA Considerations > > This document does not require actions by the IANA. > " > > > Ciao > Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 05 11:07:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc1u1-0002yQ-4B; Fri, 05 May 2006 11:07:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc1u0-0002yL-3s for ecrit@ietf.org; Fri, 05 May 2006 11:07:32 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fc1tz-0007we-5M for ecrit@ietf.org; Fri, 05 May 2006 11:07:32 -0400 Received: (qmail invoked by alias); 05 May 2006 15:07:28 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp032) with SMTP; 05 May 2006 17:07:28 +0200 X-Authenticated: #29516787 Message-ID: <445B6A27.5020007@gmx.net> Date: Fri, 05 May 2006 17:07:19 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom-PT Taylor Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt References: <445B4362.2070408@gmx.net> <445B4A71.50006@nortel.com> In-Reply-To: <445B4A71.50006@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 94902b99ee6852833c9a2b680a1de4d3 Cc: Roger Marshall , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Tom, I guess you refer to the distinction between 'emgerency identifier' and 'emergency address'. We have used 'emergency identifier' for what we call 'emergency address' in this document. You might remember the extremely long discussion regarding the 'emergency identifier' vs. 'emergency dial strings'. Now, I agree that it is necessary to have some form of emergency call marking. That's also in the requirements document listed as a requirement. There is no need to use a separate term for it, particularly when it conflicts with something else. Actually, I haven't come accross such a emergency call marking in one of our solution specific documents. Shouldn't that be in Henning's Service URN document? I want to review the latest version (after resubmitted it). Ciao Hannes Tom-PT Taylor wrote: > There is a functional distinction between something that identifies the > call as an emergency call (and must be present even after mapping has > been performed so that downstream elements are aware of the nature of > the call) and something that says where the call should be directed. By > calling them both 'identifier' you lose this distinction. I think it is > important that we keep it. > > Hannes Tschofenig wrote: > >> Hi all, >> >> here is a review of draft-ietf-ecrit-requirements-08.txt. The document >> is getting much better. Still, I have a few comments: >> >> * Introduction: >> >> >> I would delete this paragraph since it is a bit confusing at this point: >> >> As used in this document, validation of location does not require >> that we ascertain as to whether or not the location actually exists. >> For example, validation might only check that the house number in a >> civic address falls within the assigned range, not whether a >> building, known by a specific building number, exists at that >> location. However, such higher precision validation is desirable. >> >> This might be relevant in subsequent sections. >> >> >> >> Identification of the caller, while not incompatible with the >> requirements for messaging outlined within this document, is >> considered to be outside the scope of the ECRIT charter. >> ^^^^^^^^^^^^^^^^^^ >> >> Don't mention the working group name in the document. >> >> Write "... is outside the scope of this document." >> >> >> 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, for example, a TEL >> URI which may be used to complete a call via the PSTN. >> >> I am not sure about this paragraph. Where do we provide such a >> functionality? >> >> * Terminology >> >> I would cluster the terms. For example, you might want to keep >> - (Location-dependent) emergency dial string >> - Home emergency dial string >> - Visited emergency dial string >> together to make the terminology easier to read. >> >> There is no requirement to list the terms alphabetically. >> >> >> Emergency address: The URI (e.g., SIP:URI, SIPS:URI, XMPP:URI, IM: >> ^^^^^^^ change to identifier >> URI, etc.) which represents the address of the PSAP useful for the >> completion of an emergency call. >> >> Emergency call routing support: An intermediary function which >> assists in the routing of an emergency call via IP. An ESRP is an >> example of an Emergency call routing support entity. >> ^^^^^^^^^ emergency >> >> >> Delete the following paragraph: >> >> Codes: "caller" or "emergency caller" refers to the person placing an >> emergency call or sending an emergency instant message (IM). >> >> AND move the text over to this term: >> >> Emergency caller: The user or user device entity which sends his/her >> location to another entity in the network. >> >> As such, it would read: >> >> (Emergency) caller: The term "caller" or "emergency caller" refer >> to the person placing an emergency call or sending an emergency instant >> message (IM). >> >> >> >> In this document, the key words "MUST", "MUST NOT", "REQUIRED", >> "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", >> and "OPTIONAL" are to be interpreted as described in RFC 2119 [1], >> with the qualification that unless otherwise stated these words apply >> to the design of the mapping protocol, not its implementation or >> application. >> ^^^^^^^^^^^ usage >> >> >> With the suggested change from "Emergency address" to "Emergency >> identifer" we have the term 'emergency identifier' appearing twice: >> >> Emergency identifier: An identifier that marks a call as an emergency >> call. >> >> I suggest to delete this definition or to merge it with the previous one. >> >> In the text we should always use small letters for terms like 'mapping >> servers' or 'mapping clients'. For example, >> >> Mapping client: A mapping client interacts with the Mapping Server to >> ^^^^^^^^^^^^^^ >> learn one or more PSAP URIs for a given location. >> >> >> Mapping server: The Mapping Server holds information about the >> ^^^^^^^^^^^^^^ >> location-to-PSAP URI mapping. >> >> >> Change from: >> >> " >> PSAP URI: PSAP URI is a general term, used to refer to the output of >> the mapping protocol, and represents either the actual PSAP IP >> address, or the IP address of some other intermediary, e.g., an >> ESRP, which points to the actual PSAP. >> " >> >> to: >> >> " >> PSAP URI: The term 'PSAP URI' refers to a URI that identifiers a >> PSAP. We use this term to denote the reponse of a mapping protocol query. >> " >> >> * Section 3. Basic Actors >> >> In order to support emergency services covering a large physical >> area, various infrastructure elements are necessary, including: >> Internet Attachment Providers (IAPs), Application/Voice Service >> Providers (ASP/VSPs), PSAPs as endpoints for emergency calls, mapping >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ delete >> this part; the PSAP is only one endpoint of the communciation. >> >> services or other infrastructure elements that assist during the call >> ^^^ and >> routing. >> >> >> o How is location information provided to the end host? It might >> either be known to the end host itself via manual configuration, >> provided via GPS, or obtained via a third party method. Even if >> location information is known to the network it might be made >> available to the end host via DHCP (RFC 3825 [2]) or some other >> mechanism. Alternatively, location information is used as part of >> call routing and inserted by intermediaries. >> >> >> Change paragraph to: >> >> o How is location information provided to the end host? It might >> either be known to the end host itself via manual configuration, >> provided via GPS, made >> available via DHCP (see RFC 3825 [2]) or some other >> mechanisms. Alternatively, location information is used as part of >> call routing and inserted by intermediaries. >> >> >> (5) Location Information is used by emergency call routing entities >> ^^^^^^^^^^^ information >> for subsequent mapping requests. >> >> 4. High-Level Requirements >> >> Re1. Application/Voice service provider existence: The initiation of >> an IP-based emergency call SHOULD NOT assume the existence of an >> Application/Voice Service Provider (ASP/VSP). >> >> Motivation: The caller may not have an application/voice service >> provider. For example, a residence may have its own DNS domain >> and run its own SIP proxy server for that domain. On a larger >> scale, a university might provide voice services to its students >> and staff, but not be a telecommunication provider. >> ^ add "might" >> >> >> 5. Identifying the Caller's Location >> >> Location can either be provided directly, or by reference, and >> represents either a civic location, or as a geographic location. >> ^^ and geospatial location >> information. >> >> How >> does the location (or location reference) become associated with the >> call? >> >> change last sentence to: >> >> "An important question is how and when to attach location information >> to the VoIP emergency signaling." >> >> In general, we can distinguish three modes of operation of how >> a location is associated with an emergency call: >> >> Change from: >> >> UA-inserted: The caller's user agent inserts the location information >> into the call signaling message. The location information is >> derived from sources such as GPS, DHCP (RFC 3825 [2]) and >> I-D.ietf-geopriv-dhcp-civil [7]) or utilizing the Link Layer >> Discovery Protocol (LLDP) [see IEEE8021AB]. >> >> >> to: >> >> >> UA-inserted: The caller's user agent inserts the location information >> into the call signaling message. The location information is >> derived from sources such as GPS, DHCP (see [2] for geospatial >> location information and [7] for civic location information) or >> utilizing the Link Layer >> Discovery Protocol (LLDP) (see [IEEE8021AB]). >> >> >> UA-referenced: The caller's user agent provides a pointer (i.e., a >> location reference), via a permanent or temporary identifier, to >> the location which is stored by a location service somewhere else >> ^^^^^^^ server >> delete the 'somewhere else' part. >> and then retrieved by the PSAP, ESRP, or other authorized service >> entity. >> >> Lo2. Location object/info preservation: The mapping protocol MUST >> retain any location information which is provided to it, even >> after mapping is performed. >> >> Motivation: The ESRP and the PSAP use the same location >> information object, but for a different purpose. Therefore, it is >> imperative that the mapping protocol not remove location >> ^ does >> Information so that the PSAP can still receive the caller >> ^^^^^^^^^^^ information >> location. >> >> >> Lo5. Validation of civic location: The mapping protocol MUST support >> location validation for civic location (street addresses), prior >> to initiating an emergency call. >> >> delete the ", prior to initiating an emergency call." part. >> >> Motivation: Location validation provides an opportunity to help >> assure ahead of time, whether or not successful mapping to the >> ^ add 'a' >> appropriate PSAP will likely occur when it is required. >> Validation may also help to avoid delays during emergency call >> setup due to invalid locations. >> >> >> Isn't Lo7 similar to L10? >> Isn't Lo6 similar to Lo11? >> >> >> Lo9. 3D sensitive mapping: The mapping protocol MUST implement >> support for both 2D and 3D location information, and may accept >> either a 2D or 3D mapping request as input. >> >> Motivation: It is expected that provisioning systems will accept >> ^^^^^^^^^^^^^^^^^^^^ what is that? >> >> 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 in the request. >> >> >> 6. Emergency Identifier >> >> Id1. Emergency identifier support: The mapping protocol MUST support >> one or more emergency identifiers for delivery back to mapping >> clients to be used for call setup purposes. >> >> I guess this requirement should say: >> >> " >> Emergency identifier support: The mapping protocol MUST be able to >> return one or multiple emergency identifiers in response to a query. >> " >> >> >> >> Id2. Emergency identifier resolution: Where multiple emergency >> identifiers exist, the mapping protocol MUST be able to >> differentiate between identifiers based on the specific type of >> emergency help requested. >> >> Motivation: Some jurisdictions may have multiple types of >> emergency services available, (e.g., fire, police, ambulance), in >> which case, it is important that any one could be selected >> directly. >> >> There is a terminology confusion here: >> I think you refer to 'sos Service Types' here rather than multiple >> emergency identifers. You might want to double-check with >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-02.txt >> (and in particular with Section 4.3). >> >> This terminology issue impacts also requirement Id5. >> >> Id4. Prevention of fraud: If a call is identified as an emergency >> call, the mapping protocol MUST support that call being >> successfully routed to a PSAP. >> >> Motivation: This prevents use of the emergency call indication to >> gain access to call features or authentication override for non- >> emergency purposes. >> >> This requirement is covered in the security document. >> >> >> Requirement Id6, Id7, Id8, Id9, Id10 start with "The mapping protocol >> MUST/SHOULD support " but I think that these requirements do not >> necessarily address the mapping protocol. I think a "There MUST be >> support for...." >> >> >> 7. Mapping Protocol >> >> There are two basic approaches to invoking a mapping service. We >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> invoke the mapping protocol. >> >> refer to these as caller-based and mediated. In each case, the >> mapping client initiates a request to a mapping server via a mapping >> protocol. A proposed mapping protocol is outlined in the document >> I-D.hardie-ecrit-lost [6]. >> >> For caller-based resolution, the caller's user agent invokes a >> ^ the >> mapping service to determine the appropriate PSAP based on the >> ^^^^^^^ protocol >> location provided. The resolution may take place well before the >> actual emergency call is placed, or at the time of the call. >> >> For mediated resolution, a call signaling server, such as a SIP >> ^^^^^^^^^^^^^^^^^^^^^^^ >> an emergency call routing support entity >> >> (outbound) proxy or redirect server invokes the mapping service. >> >> >> Ma5. URI alternate contact: In addition to returning a primary >> contact, the mapping protocol MUST support the return of a URI or >> contact method explicitly marked as an alternate contact. >> >> Motivation: In response to a mapping request, the mapping server >> may return an alternate URI. Implementation details to be >> described within an operational document. >> >> >> I am not quite sure about Ma6 and Ma8. Ma8 tells me that the mapping >> protocol provides a URL for error reporting. Isn't Ma6 similar? >> >> >> Ma6. URL properties: The mapping protocol MUST support the ability >> ^^^ URI >> >> to provide ancillary information about a contact or URI that >> ^^^^^^ delete >> allows the mapping client to determine relevant properties of the >> URL. >> ^^^^ URI? >> >> >> Motivation: In some cases, the same geographic area is served by >> several PSAPs, for example, a corporate campus might be served by >> both a corporate security department and the municipal PSAP. The >> mapping protocol should then return URLs for both, with >> ^^^^ URIs >> information allowing the querying entity to choose one or the >> other. This determination could be made by either an ESRP, based >> on local policy, or by direct user choice, in the case of caller- >> based methods. >> >> Ma7. Traceable resolution: The mapping protocol SHOULD support the >> ability of the mapping client to be able to determine the entity >> or entities which provided the emergency address resolution >> ^^^^^ that >> information. >> >> Motivation: It is important for public safety reasons, that there >> is a method to provide operational traceability in case of errors. >> >> Ma8. URI for error reporting: The mapping protocol MUST support the >> ^^^^ URL >> >> return of a URI that can be used to report a suspected or known >> ^^^^^^^^^^^^^^^ the ability to return a URL >> >> error within the mapping database. >> >> Motivation: If an error is returned, for example, there needs to >> be a URI which points to a resource which can explain or >> ^^^^ URL >> >> potentially help resolve the error. >> >> >> Ma16. Multiple PSAP URIs: The mapping protocol MUST support a method >> to receive multiple PSAP URIs which cover the same geographic >> ^^^^^^^ return >> area. >> >> Motivation: Two different mapping servers may cover the same >> geographic area, and therefore have the same set of coverage >> information. >> >> Isn't this requirement very similar to Ma4? >> >> >> >> >> * 8. Security Considerations >> >> Security considerations are discussed in the ECRIT security document >> I-D.ietf-ecrit-security-threats [4] . >> >> Write: >> >> " >> Threats and security requirements are discussed in a separate >> document, see [4]. >> " >> >> * Add an IANA section. >> " >> 9. IANA Considerations >> >> This document does not require actions by the IANA. >> " >> >> >> Ciao >> Hannes >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 05 13:34:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc4Bl-0005tL-BZ; Fri, 05 May 2006 13:34:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc4Bj-0005tG-QD for ecrit@ietf.org; Fri, 05 May 2006 13:33:59 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc4Bh-0005M7-Db for ecrit@ietf.org; Fri, 05 May 2006 13:33:59 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k45HXif10906; Fri, 5 May 2006 13:33:44 -0400 (EDT) Received: from [127.0.0.1] ([47.130.16.43] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 13:33:44 -0400 Message-ID: <445B8C75.1090203@nortel.com> Date: Fri, 05 May 2006 13:33:41 -0400 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt References: <445B4362.2070408@gmx.net> <445B4A71.50006@nortel.com> <445B6A27.5020007@gmx.net> In-Reply-To: <445B6A27.5020007@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 May 2006 17:33:44.0319 (UTC) FILETIME=[0EC3B8F0:01C6706A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Roger Marshall , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org My security I-D uses definitions from the requirements document. These definitions and terms have changed. I may be forced to create definitions of my own as a result. Hannes Tschofenig wrote: > Hi Tom, > > I guess you refer to the distinction between 'emgerency identifier' and > 'emergency address'. We have used 'emergency identifier' for what we > call 'emergency address' in this document. You might remember the > extremely long discussion regarding the 'emergency identifier' vs. > 'emergency dial strings'. > > Now, I agree that it is necessary to have some form of emergency call > marking. That's also in the requirements document listed as a > requirement. There is no need to use a separate term for it, > particularly when it conflicts with something else. Actually, I haven't > come accross such a emergency call marking in one of our solution > specific documents. Shouldn't that be in Henning's Service URN document? > I want to review the latest version (after resubmitted it). > > Ciao > Hannes > Tom-PT Taylor wrote: >> There is a functional distinction between something that identifies the >> call as an emergency call (and must be present even after mapping has >> been performed so that downstream elements are aware of the nature of >> the call) and something that says where the call should be directed. By >> calling them both 'identifier' you lose this distinction. I think it is >> important that we keep it. >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 05 16:28:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc6ue-0000TD-MU; Fri, 05 May 2006 16:28:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc6Q2-0004Zh-Sb for ecrit@ietf.org; Fri, 05 May 2006 15:56:55 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc5k3-0001UX-J8 for ecrit@ietf.org; Fri, 05 May 2006 15:13:31 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fc5WC-00060q-5F for ecrit@ietf.org; Fri, 05 May 2006 14:59:14 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Fri, 5 May 2006 11:59:10 -0700 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] Review of draft-ietf-ecrit-requirements-08.txt Date: Fri, 5 May 2006 11:59:10 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657504DB6993@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Thread-Index: AcZwaiK626mnYrgxTKu2WPMoS7f20QACHM5Q From: "Roger Marshall" To: "Tom-PT Taylor" , "Hannes Tschofenig" X-Spam-Score: -2.1 (--) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think our intention for the requirements draft to describe the following set: Emergency dial string (e.g., "9-1-1", "1-1-2") Emergency identifiers (e.g., "service:urn:sos") Emergency address (e.g., a PSAP URI, which resolves to an IP address) PSAP:URI (e.g., "psapA@anycounty.st.gov", "esrpB@essvcprovider.com") Since this is not what the draft actually says, I propose changing the following: CHANGE FROM: Emergency address: The URI (e.g., SIP:URI, SIPS:URI,=20 XMPP:URI, IM:URI, etc.) which represents the address of the PSAP=20 useful for the completion of an emergency call. CHANGE TO: Emergency address: The PSAP URI (e.g., SIP:URI, SIPS:URI,=20 XMPP:URI, IM:URI, etc.) which represents the IP address of the PSAP=20 useful for the completion of an emergency call. I'll do a consistency check in addition to other comments received. Thanks. -roger. >-----Original Message----- >From: Tom-PT Taylor [mailto:taylor@nortel.com]=20 >Sent: Friday, May 05, 2006 10:34 AM >To: Hannes Tschofenig >Cc: Roger Marshall; ecrit@ietf.org >Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt > >My security I-D uses definitions from the requirements=20 >document. These definitions and terms have changed. I may be=20 >forced to create definitions of my own as a result. > >Hannes Tschofenig wrote: >> Hi Tom, >>=20 >> I guess you refer to the distinction between 'emgerency identifier'=20 >> and 'emergency address'. We have used 'emergency identifier'=20 >for what=20 >> we call 'emergency address' in this document. You might remember the=20 >> extremely long discussion regarding the 'emergency identifier' vs. >> 'emergency dial strings'. >>=20 >> Now, I agree that it is necessary to have some form of=20 >emergency call=20 >> marking. That's also in the requirements document listed as a=20 >> requirement. There is no need to use a separate term for it,=20 >> particularly when it conflicts with something else. Actually, I=20 >> haven't come accross such a emergency call marking in one of our=20 >> solution specific documents. Shouldn't that be in Henning's=20 >Service URN document? >> I want to review the latest version (after resubmitted it). >>=20 >> Ciao >> Hannes >> Tom-PT Taylor wrote: >>> There is a functional distinction between something that identifies=20 >>> the call as an emergency call (and must be present even=20 >after mapping=20 >>> has been performed so that downstream elements are aware of the=20 >>> nature of the call) and something that says where the call=20 >should be=20 >>> directed. By calling them both 'identifier' you lose this=20 >>> distinction. I think it is important that we keep it. >>> > > >_______________________________________________ >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 May 05 16:31:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc6xl-0005vB-6h; Fri, 05 May 2006 16:31:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc6xk-0005v6-FF for ecrit@ietf.org; Fri, 05 May 2006 16:31:44 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fc6xj-0000BG-VQ for ecrit@ietf.org; Fri, 05 May 2006 16:31:44 -0400 Received: (qmail invoked by alias); 05 May 2006 20:31:41 -0000 Received: from p54986501.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.101.1] by mail.gmx.net (mp010) with SMTP; 05 May 2006 22:31:41 +0200 X-Authenticated: #29516787 Message-ID: <445BB62B.1000705@gmx.net> Date: Fri, 05 May 2006 22:31:39 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt References: <8C837214C95C864C9F34F3635C2A657504DB6993@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A657504DB6993@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Roger, Roger Marshall wrote: > I think our intention for the requirements draft to describe the > following set: > > Emergency dial string (e.g., "9-1-1", "1-1-2") fine. > Emergency identifiers (e.g., "service:urn:sos") fine. > Emergency address (e.g., a PSAP URI, which resolves to an IP address) > PSAP:URI (e.g., "psapA@anycounty.st.gov", "esrpB@essvcprovider.com") We use the term PSAP URI for this purpose. We don't need the emergency address terminology. > > Since this is not what the draft actually says, I propose changing the > following: > > CHANGE FROM: > Emergency address: The URI (e.g., SIP:URI, SIPS:URI, > XMPP:URI, IM:URI, etc.) which represents the address of the PSAP > useful for the completion of an emergency call. > > CHANGE TO: > Emergency address: The PSAP URI (e.g., SIP:URI, SIPS:URI, > XMPP:URI, IM:URI, etc.) which represents the IP address of the PSAP > useful for the completion of an emergency call. A URI cannot represent an IP address. A URI can be resolved to an IP address. Ciao Hannes > > I'll do a consistency check in addition to other comments received. > > Thanks. > > -roger. > > >>-----Original Message----- >>From: Tom-PT Taylor [mailto:taylor@nortel.com] >>Sent: Friday, May 05, 2006 10:34 AM >>To: Hannes Tschofenig >>Cc: Roger Marshall; ecrit@ietf.org >>Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt >> >>My security I-D uses definitions from the requirements >>document. These definitions and terms have changed. I may be >>forced to create definitions of my own as a result. >> >>Hannes Tschofenig wrote: >> >>>Hi Tom, >>> >>>I guess you refer to the distinction between 'emgerency identifier' >>>and 'emergency address'. We have used 'emergency identifier' >> >>for what >> >>>we call 'emergency address' in this document. You might remember the >>>extremely long discussion regarding the 'emergency identifier' vs. >>>'emergency dial strings'. >>> >>>Now, I agree that it is necessary to have some form of >> >>emergency call >> >>>marking. That's also in the requirements document listed as a >>>requirement. There is no need to use a separate term for it, >>>particularly when it conflicts with something else. Actually, I >>>haven't come accross such a emergency call marking in one of our >>>solution specific documents. Shouldn't that be in Henning's >> >>Service URN document? >> >>>I want to review the latest version (after resubmitted it). >>> >>>Ciao >>>Hannes >>>Tom-PT Taylor wrote: >>> >>>>There is a functional distinction between something that identifies >>>>the call as an emergency call (and must be present even >> >>after mapping >> >>>>has been performed so that downstream elements are aware of the >>>>nature of the call) and something that says where the call >> >>should be >> >>>>directed. By calling them both 'identifier' you lose this >>>>distinction. I think it is important that we keep it. >>>> >> >> >>_______________________________________________ >>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 May 05 16:40:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc75v-0005W7-Kf; Fri, 05 May 2006 16:40:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc75u-0005W2-6H for ecrit@ietf.org; Fri, 05 May 2006 16:40:10 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc75t-0000cj-0B for ecrit@ietf.org; Fri, 05 May 2006 16:40:10 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Fri, 05 May 2006 16:40:48 -0400 id 0158801F.445BB850.0000244B Message-ID: <445BB828.2090605@hxr.us> Date: Fri, 05 May 2006 16:40:08 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt References: <8C837214C95C864C9F34F3635C2A657504DB6993@SEA-EXCHVS-2.telecomsys.com> <445BB62B.1000705@gmx.net> In-Reply-To: <445BB62B.1000705@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) 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: , Errors-To: ecrit-bounces@ietf.org Hannes Tschofenig wrote: >> Since this is not what the draft actually says, I propose changing the >> following: >> >> CHANGE FROM: >> Emergency address: The URI (e.g., SIP:URI, SIPS:URI, XMPP:URI, IM:URI, >> etc.) which represents the address of the PSAP useful for the >> completion of an emergency call. >> >> CHANGE TO: >> Emergency address: The PSAP URI (e.g., SIP:URI, SIPS:URI, XMPP:URI, >> IM:URI, etc.) which represents the IP address of the PSAP useful for >> the completion of an emergency call. > > A URI cannot represent an IP address. A URI can be resolved to an IP > address. Uh, what!? What about http://192.138.228.1? I think using the terminology, "resolves to" is what is being sought here. I also don't understand this SIPS:URI stuff. How about: Emergency address: The PSAP URI (e.g., SIP URI, SIPS URI, XMPP URI, IM URI, etc...) which resolves to the communication end point of a PSAP. BTW, what protocol is the IM scheme? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 05 16:54:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc7Jt-0005fE-K6; Fri, 05 May 2006 16:54:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc7Js-0005f1-EA for ecrit@ietf.org; Fri, 05 May 2006 16:54:36 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc7Jr-0001If-48 for ecrit@ietf.org; Fri, 05 May 2006 16:54:36 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k45KsUuH006326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 5 May 2006 13:54:31 -0700 Received: from [65.112.8.52] (vpn-10-50-0-146.qualcomm.com [10.50.0.146]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k45KsSrA002637; Fri, 5 May 2006 13:54:29 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <445BB62B.1000705@gmx.net> References: <8C837214C95C864C9F34F3635C2A657504DB6993@SEA-EXCHVS-2.telecomsys.com> <445BB62B.1000705@gmx.net> Date: Fri, 5 May 2006 13:54:28 -0700 To: Hannes Tschofenig , Roger Marshall From: Ted Hardie Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 10:31 PM +0200 5/5/06, Hannes Tschofenig wrote: >>CHANGE FROM: >>Emergency address: The URI (e.g., SIP:URI, SIPS:URI, XMPP:URI, IM:URI, etc.) which represents the address of the PSAP useful for the completion of an emergency call. >> >>CHANGE TO: >>Emergency address: The PSAP URI (e.g., SIP:URI, SIPS:URI, XMPP:URI, IM:URI, etc.) which represents the IP address of the PSAP useful for the completion of an emergency call. > >A URI cannot represent an IP address. A URI can be resolved to an IP address. > >Ciao >Hannes I believe we may mean: "Emergency address: The URI (e.g. , SIP:URI, SIPS:URI, XMPP:URI, IM:URI, etc.) at which the PSAP may be contacted with an emergency call." The URI contains information about the protocol used (encoded in the scheme), so a focus on the IP address is not appropriate. There are even cases where the SIP:URI and the IM:URI might not point to the same box. regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 05 16:57:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc7MA-0005pI-VG; Fri, 05 May 2006 16:56:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc7M9-0005nj-8V for ecrit@ietf.org; Fri, 05 May 2006 16:56:57 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fc7M8-0001Md-Rm for ecrit@ietf.org; Fri, 05 May 2006 16:56:57 -0400 Received: (qmail invoked by alias); 05 May 2006 20:56:55 -0000 Received: from p54986501.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.101.1] by mail.gmx.net (mp013) with SMTP; 05 May 2006 22:56:55 +0200 X-Authenticated: #29516787 Message-ID: <445BBC11.3060606@gmx.net> Date: Fri, 05 May 2006 22:56:49 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt References: <8C837214C95C864C9F34F3635C2A657504DB6993@SEA-EXCHVS-2.telecomsys.com> <445BB62B.1000705@gmx.net> <445BB828.2090605@hxr.us> In-Reply-To: <445BB828.2090605@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Andy, Hi Roger, I was wrong with my previous statement. I should rephrase my statement: You cannot write "The URI which represents the IP address of the PSAP." Let us look where this term is actually used in the document: Id3. Emergency identifier marking: The mapping protocol MUST include an emergency identifier with the signaling, if one does not exist, for the purpose of marking the call as an emergency call. Motivation: Marking ensures proper handling as an emergency call by downstream elements that may not recognize, for example, a local variant of a logical emergency address, etc. # What is a "local variant of a logical emergency address"? This marking mechanism is assumed to be different than a QoS marking mechanism. Id8. Emergency dial string replacement: The mapping protocol SHOULD support replacement of the original dial string with a reserved emergency identifier for each signaling protocol used for an emergency call. This replacement of the original dial string should be based on local conventions, regulations, or preference (e.g., as in the case of an enterprise). Motivation: Any signaling protocol requires the use of some identifier to indicate the called party, and the user terminal may lack the capability to determine the actual emergency address (PSAP URI). # We could just use the term PSAP URI instead of the emergency address here. The use of local conventions may be required as a transition mechanism. Note: Such use complicates international movement of the user terminal. Evolution to a standardized emergency identifier or set of identifiers is preferred. Ma7. Traceable resolution: The mapping protocol SHOULD support the ability of the mapping client to be able to determine the entity or entities which provided the emergency address resolution information. # Here it would actually be better to write: "... determine the entity or entities that computed the mapping." Motivation: It is important for public safety reasons, that there is a method to provide operational traceability in case of errors. The term is used three times in the document and in all these cases it is not needed. Ciao Hannes Andrew Newton wrote: > Hannes Tschofenig wrote: > >>> Since this is not what the draft actually says, I propose changing the >>> following: >>> >>> CHANGE FROM: >>> Emergency address: The URI (e.g., SIP:URI, SIPS:URI, XMPP:URI, >>> IM:URI, etc.) which represents the address of the PSAP useful for the >>> completion of an emergency call. >>> >>> CHANGE TO: >>> Emergency address: The PSAP URI (e.g., SIP:URI, SIPS:URI, XMPP:URI, >>> IM:URI, etc.) which represents the IP address of the PSAP useful for >>> the completion of an emergency call. >> >> >> A URI cannot represent an IP address. A URI can be resolved to an IP >> address. > > > Uh, what!? What about http://192.138.228.1? I think using the > terminology, "resolves to" is what is being sought here. I also don't > understand this SIPS:URI stuff. > > How about: > > Emergency address: The PSAP URI (e.g., SIP URI, SIPS URI, XMPP URI, IM > URI, etc...) which resolves to the communication end point of a PSAP. > > BTW, what protocol is the IM scheme? > > -andy > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 05 17:14:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc7dF-0005wa-W2; Fri, 05 May 2006 17:14:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc7dF-0005wV-6A for ecrit@ietf.org; Fri, 05 May 2006 17:14:37 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fc7dE-0001gh-Py for ecrit@ietf.org; Fri, 05 May 2006 17:14:37 -0400 Received: (qmail invoked by alias); 05 May 2006 21:14:35 -0000 Received: from p54986501.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.101.1] by mail.gmx.net (mp043) with SMTP; 05 May 2006 23:14:35 +0200 X-Authenticated: #29516787 Message-ID: <445BC038.2090000@gmx.net> Date: Fri, 05 May 2006 23:14:32 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt References: <445B4362.2070408@gmx.net> In-Reply-To: <445B4362.2070408@gmx.net> 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: 7bac9cb154eb5790ae3b2913587a40de Cc: Roger Marshall , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I took a look at my review comment regarding the emergency address and I have to realize that I was a bit confused when I wrote my review. It is totally wrong to change the term 'emergency address' to 'emergency identifier'. > Emergency address: The URI (e.g., SIP:URI, SIPS:URI, XMPP:URI, IM: > ^^^^^^^ change to identifier > URI, etc.) which represents the address of the PSAP useful for the > completion of an emergency call. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 05 17:25:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc7nH-00074L-17; Fri, 05 May 2006 17:24:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc7nF-000745-3W for ecrit@ietf.org; Fri, 05 May 2006 17:24:57 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fc7nE-0001qZ-Nr for ecrit@ietf.org; Fri, 05 May 2006 17:24:57 -0400 Received: (qmail invoked by alias); 05 May 2006 21:24:55 -0000 Received: from p54986501.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.101.1] by mail.gmx.net (mp031) with SMTP; 05 May 2006 23:24:55 +0200 X-Authenticated: #29516787 Message-ID: <445BC2A2.6090608@gmx.net> Date: Fri, 05 May 2006 23:24:50 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt References: <8C837214C95C864C9F34F3635C2A657504DB6993@SEA-EXCHVS-2.telecomsys.com> <445BB62B.1000705@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I like your definition, Ted. Now, we just need to make sure that it is used at the right places in the draft. Btw, I think that it might be good to add the term 'sos service type' to draft-ietf-ecrit-requirements-08.txt as used in draft-ietf-ecrit-service-urn-02.txt. draft-ietf-ecrit-service-urn-02.txt denotes each of the following strings as sos service types (at least I think so): urn:service:sos urn:service:sos.ambulance urn:service:sos.animal-control .... urn:service:sos.mental-health To have a generic term for all these identifiers the term 'emergency identifier' seems to be appropriate. Ciao Hannes PS: Let me know if I got totally confused. Ted Hardie wrote: > At 10:31 PM +0200 5/5/06, Hannes Tschofenig wrote: > >>>CHANGE FROM: >>>Emergency address: The URI (e.g., SIP:URI, SIPS:URI, XMPP:URI, IM:URI, etc.) which represents the address of the PSAP useful for the completion of an emergency call. >>> >>>CHANGE TO: >>>Emergency address: The PSAP URI (e.g., SIP:URI, SIPS:URI, XMPP:URI, IM:URI, etc.) which represents the IP address of the PSAP useful for the completion of an emergency call. >> >>A URI cannot represent an IP address. A URI can be resolved to an IP address. >> >>Ciao >>Hannes > > > I believe we may mean: > > "Emergency address: The URI (e.g. , SIP:URI, SIPS:URI, XMPP:URI, IM:URI, etc.) at > which the PSAP may be contacted with an emergency call." > > The URI contains information about the protocol used (encoded in the scheme), so > a focus on the IP address is not appropriate. There are even cases where the SIP:URI and > the IM:URI might not point to the same box. > regards, > Ted Hardie > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 05 19:34:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc9og-0004PP-9n; Fri, 05 May 2006 19:34:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc9of-0004PK-BU for ecrit@ietf.org; Fri, 05 May 2006 19:34:33 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc9od-0007Sm-Uz for ecrit@ietf.org; Fri, 05 May 2006 19:34:33 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Fri, 5 May 2006 16:34:30 -0700 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] Review of draft-ietf-ecrit-requirements-08.txt Date: Fri, 5 May 2006 16:34:29 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657504DB6C34@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Thread-Index: AcZwilwmz6Uu7HLSQrCeFKMItPt1jgAEDlCQ From: "Roger Marshall" To: "Hannes Tschofenig" , "Ted Hardie" X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Ted, Hannes: I've merged the two defn's (Emergency Address & PSAP URI) together, and given XMPP, removed IM reference:, (Andy's comment). =20 See if you can live with the result. CHANGE FROM: PSAP URI: PSAP URI is a general term, used to refer to=20 the output of the mapping protocol, and represents either the actual=20 PSAP IP address, or the IP address of some other intermediary, e.g., an=20 ESRP, which points to the actual PSAP. CHANGE TO: PSAP URI: The URI (e.g., SIP:URI, SIPS:URI, XMPP:URI,=20 etc.) at which the PSAP may be contacted with an emergency call. This=20 contact could be done directly, or via an intermediary, (e.g., ESRP). The=20 URI contains information about the protocol used (encoded in the scheme),=20 so that a focus on the IP address that it may resolve to is not appropriate.=20 There are even cases where the SIP:URI and the XMPP:URI for the same=20 PSAP might not point to the same box.=20 -roger. >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 >Sent: Friday, May 05, 2006 2:25 PM >To: Ted Hardie >Cc: Roger Marshall; ecrit@ietf.org >Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt > >I like your definition, Ted. Now, we just need to make sure=20 >that it is used at the right places in the draft. > >Btw, I think that it might be good to add the term 'sos=20 >service type' to draft-ietf-ecrit-requirements-08.txt as used=20 >in draft-ietf-ecrit-service-urn-02.txt. > >draft-ietf-ecrit-service-urn-02.txt denotes each of the=20 >following strings as sos service types (at least I think so): > >urn:service:sos >urn:service:sos.ambulance >urn:service:sos.animal-control >.... >urn:service:sos.mental-health > >To have a generic term for all these identifiers the term=20 >'emergency identifier' seems to be appropriate. > >Ciao >Hannes > >PS: Let me know if I got totally confused. > > >Ted Hardie wrote: >> At 10:31 PM +0200 5/5/06, Hannes Tschofenig wrote: >>=20 >>>>CHANGE FROM: >>>>Emergency address: The URI (e.g., SIP:URI, SIPS:URI,=20 >XMPP:URI, IM:URI, etc.) which represents the address of the=20 >PSAP useful for the completion of an emergency call. >>>> >>>>CHANGE TO: >>>>Emergency address: The PSAP URI (e.g., SIP:URI, SIPS:URI,=20 >XMPP:URI, IM:URI, etc.) which represents the IP address of the=20 >PSAP useful for the completion of an emergency call. >>> >>>A URI cannot represent an IP address. A URI can be resolved=20 >to an IP address. >>> >>>Ciao >>>Hannes >>=20 >>=20 >> I believe we may mean: >>=20 >> "Emergency address: The URI (e.g. , SIP:URI, SIPS:URI, XMPP:URI,=20 >> IM:URI, etc.) at which the PSAP may be contacted with an=20 >emergency call." >>=20 >> The URI contains information about the protocol used (encoded in the=20 >> scheme), so a focus on the IP address is not appropriate. There are=20 >> even cases where the SIP:URI and the IM:URI might not point=20 >to the same box. >> regards, >> Ted Hardie >>=20 >>=20 > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 06 08:49:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcMDa-0000Gx-6f; Sat, 06 May 2006 08:49:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcMDY-0000Gs-Ny for ecrit@ietf.org; Sat, 06 May 2006 08:49:04 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcMDX-00075b-Dx for ecrit@ietf.org; Sat, 06 May 2006 08:49:04 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k46CmvUc008078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 6 May 2006 05:48:57 -0700 Received: from [65.112.8.52] (vpn-10-50-16-1.qualcomm.com [10.50.16.1]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k46CmspD006705; Sat, 6 May 2006 05:48:56 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <8C837214C95C864C9F34F3635C2A657504DB6C34@SEA-EXCHVS-2.telecomsys.com> References: <8C837214C95C864C9F34F3635C2A657504DB6C34@SEA-EXCHVS-2.telecomsys.com> Date: Sat, 6 May 2006 05:48:55 -0700 To: "Roger Marshall" , "Hannes Tschofenig" From: Ted Hardie Subject: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 4:34 PM -0700 5/5/06, Roger Marshall wrote: >The >URI contains information about the protocol used (encoded in the >scheme), >so that a focus on the IP address that it may resolve to is not >appropriate. >There are even cases where the SIP:URI and the XMPP:URI for the same >PSAP might not point to the same box. I hadn't actually intended for the lines above to be included; I meant them as further information about the URI for the group. If people think that it is valuable to include it, though, I would elide "so that a focus on the IP address that it may resolve to is not appropriate.". regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 06 12:22:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcPYG-0000hL-Bl; Sat, 06 May 2006 12:22:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcPYF-0000h9-DA for ecrit@ietf.org; Sat, 06 May 2006 12:22:39 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FcPYE-0006cO-TM for ecrit@ietf.org; Sat, 06 May 2006 12:22:39 -0400 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] Review of draft-ietf-ecrit-requirements-08.txt Date: Sat, 6 May 2006 18:26:38 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C49EE@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Thread-Index: AcZwilwmz6Uu7HLSQrCeFKMItPt1jgAEDlCQACOg5gE= From: "Stastny Richard" To: "Roger Marshall" , "Hannes Tschofenig" , "Ted Hardie" X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org >I've merged the two defn's (Emergency Address & PSAP URI) together, and >given XMPP, removed IM reference:, (Andy's comment).=20 Fine, in catching up on the list I just wanted to propose to drop = emergency address and only use PSAP URI (if even Hannes gets confused ;-) >See if you can live with the result. >CHANGE FROM: >PSAP URI: PSAP URI is a general term, used to refer to >the output of the mapping protocol, and represents either the actual >PSAP IP address, or the IP address of some other intermediary, e.g., an >ESRP, which points to the actual PSAP. >CHANGE TO: >PSAP URI: The URI (e.g., SIP:URI, SIPS:URI, XMPP:URI, >etc.) at which the PSAP may be contacted with an emergency call. This >contact could be done directly, or via an intermediary, (e.g., ESRP). OK >The >URI contains information about the protocol used (encoded in the >scheme), >so that a focus on the IP address that it may resolve to is not >appropriate. =20 I am not sure we need this tutorial >There are even cases where the SIP:URI and the XMPP:URI for the same >PSAP might not point to the same box. =20 This should be a note (without the "even" =20 Just a question for clicification: the URI may also be a TEL:URI. if it = is pointing to a PSAP only on the PSTN. Shouldn't this be included also? =20 Richard -roger. >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >Sent: Friday, May 05, 2006 2:25 PM >To: Ted Hardie >Cc: Roger Marshall; ecrit@ietf.org >Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt > >I like your definition, Ted. Now, we just need to make sure >that it is used at the right places in the draft. > >Btw, I think that it might be good to add the term 'sos >service type' to draft-ietf-ecrit-requirements-08.txt as used >in draft-ietf-ecrit-service-urn-02.txt. > >draft-ietf-ecrit-service-urn-02.txt denotes each of the >following strings as sos service types (at least I think so): > >urn:service:sos >urn:service:sos.ambulance >urn:service:sos.animal-control >.... >urn:service:sos.mental-health > >To have a generic term for all these identifiers the term >'emergency identifier' seems to be appropriate. > >Ciao >Hannes > >PS: Let me know if I got totally confused. > > >Ted Hardie wrote: >> At 10:31 PM +0200 5/5/06, Hannes Tschofenig wrote: >> >>>>CHANGE FROM: >>>>Emergency address: The URI (e.g., SIP:URI, SIPS:URI, >XMPP:URI, IM:URI, etc.) which represents the address of the >PSAP useful for the completion of an emergency call. >>>> >>>>CHANGE TO: >>>>Emergency address: The PSAP URI (e.g., SIP:URI, SIPS:URI, >XMPP:URI, IM:URI, etc.) which represents the IP address of the >PSAP useful for the completion of an emergency call. >>> >>>A URI cannot represent an IP address. A URI can be resolved >to an IP address. >>> >>>Ciao >>>Hannes >> >> >> I believe we may mean: >> >> "Emergency address: The URI (e.g. , SIP:URI, SIPS:URI, XMPP:URI, >> IM:URI, etc.) at which the PSAP may be contacted with an >emergency call." >> >> The URI contains information about the protocol used (encoded in the >> scheme), so a focus on the IP address is not appropriate. There are >> even cases where the SIP:URI and the IM:URI might not point >to the same box. >> regards, >> Ted Hardie >> >> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 06 12:47:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcPwF-00019y-V2; Sat, 06 May 2006 12:47:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcPwE-00019t-O3 for ecrit@ietf.org; Sat, 06 May 2006 12:47:26 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FcPwD-0007Tw-Ae for ecrit@ietf.org; Sat, 06 May 2006 12:47:26 -0400 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] Review of draft-ietf-ecrit-requirements-08.txt Date: Sat, 6 May 2006 18:51:29 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C49EF@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Thread-Index: AcZwPyb0rfghPrt0QyOG0K6mtR0ZzAA7SuU5 From: "Stastny Richard" To: "Hannes Tschofenig" , , "Henning Schulzrinne" , "Roger Marshall" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Folks, =20 I am a bit confused with: =20 Id3. Emergency identifier marking: The mapping protocol MUST include an emergency identifier with the signaling, if one does not exist, for the purpose of marking the call as an emergency call. =20 I have some questions here: =20 the mapping protocol cannot include by itself something in signalling. =20 so is the intention the following (derived from motivation)?: (wording = to be improved) the mapping protocol MUST return an emergency identifier that MUST be=20 included by the (downstream) signalling protocol for the purpose of marking the call as an emergency call. =20 =20 Motivation: Marking ensures proper handling as an emergency call by downstream elements that may not recognize, for example, a local variant of a logical emergency address, etc. This marking mechanism is assumed to be different than a QoS marking mechanism. =20 Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 06 12:51:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcPzd-0003un-B5; Sat, 06 May 2006 12:50:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcPzc-0003ui-FZ for ecrit@ietf.org; Sat, 06 May 2006 12:50:56 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FcPzb-0007df-1m for ecrit@ietf.org; Sat, 06 May 2006 12:50:56 -0400 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] Review of draft-ietf-ecrit-requirements-08.txt Date: Sat, 6 May 2006 18:53:50 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C49F0@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Thread-Index: AcZwPyb0rfghPrt0QyOG0K6mtR0ZzAA7SuU5AABU4VI= From: "Stastny Richard" To: "Stastny Richard" , "Hannes Tschofenig" , , "Henning Schulzrinne" , "Roger Marshall" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org For a better understanding of this issue it may also be helpful to place Id3 after Id8 =20 Richard ________________________________ Von: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Gesendet: Sa 06.05.2006 18:51 An: Hannes Tschofenig; ecrit@ietf.org; Henning Schulzrinne; Roger = Marshall Betreff: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Folks, I am a bit confused with: Id3. Emergency identifier marking: The mapping protocol MUST include an emergency identifier with the signaling, if one does not exist, for the purpose of marking the call as an emergency call. I have some questions here: the mapping protocol cannot include by itself something in signalling. so is the intention the following (derived from motivation)?: (wording = to be improved) the mapping protocol MUST return an emergency identifier that MUST be included by the (downstream) signalling protocol for the purpose of marking the call as an emergency call. Motivation: Marking ensures proper handling as an emergency call by downstream elements that may not recognize, for example, a local variant of a logical emergency address, etc. This marking mechanism is assumed to be different than a QoS marking mechanism. Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 06 13:05:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcQDL-0007ee-PK; Sat, 06 May 2006 13:05:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcQDK-0007eZ-OG for ecrit@ietf.org; Sat, 06 May 2006 13:05:06 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FcQDJ-0008Ml-8J for ecrit@ietf.org; Sat, 06 May 2006 13:05:06 -0400 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] Review of draft-ietf-ecrit-requirements-08.txt Date: Sat, 6 May 2006 19:09:08 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C49F1@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Thread-Index: AcZwPyb0rfghPrt0QyOG0K6mtR0ZzAA7SuU5AABU4VIAAE9U2Q== From: "Stastny Richard" To: "Hannes Tschofenig" , , "Henning Schulzrinne" , "Roger Marshall" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org IMHO there is a contradiction, (espeially between Ma6 and Ma17) or at = least this is very confusing. I do not know now if multiple URIs for the same = contact protocol are allowed or not) =20 In one requirement the client needs to the select among differnt = protocols, in the other not =20 Richard =20 Ma4. Multiple response URIs: The mapping protocol MUST support the possible inclusion of multiple URIs in a mapping response. Motivation: Multiple URIs may be available from the mapping server. =20 Ma5. URI alternate contact: In addition to returning a primary contact, the mapping protocol MUST support the return of a URI or contact method explicitly marked as an alternate contact. Motivation: In response to a mapping request, the mapping server may return an alternate URI. Implementation details to be described within an operational document. =20 Ma6. URL properties: The mapping protocol MUST support the ability to provide ancillary information about a contact or URI that allows the mapping client to determine relevant properties of the URL. Motivation: In some cases, the same geographic area is served by several PSAPs, for example, a corporate campus might be served by both a corporate security department and the municipal PSAP. The mapping protocol should then return URLs for both, with information allowing the querying entity to choose one or the other. This determination could be made by either an ESRP, based on local policy, or by direct user choice, in the case of caller- based methods. Ma17. Single URI per contact protocol: Though the mapping protocol supports the return of multiple URIs, it SHOULD return only one URI per contact protocol, 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. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 06 13:56:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcR0q-0002dD-Um; Sat, 06 May 2006 13:56:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcR0p-0002d5-0d for ecrit@ietf.org; Sat, 06 May 2006 13:56:15 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FcR0o-0001uV-2D for ecrit@ietf.org; Sat, 06 May 2006 13:56:14 -0400 Received: (qmail invoked by alias); 06 May 2006 17:56:07 -0000 Received: from p549879BC.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.121.188] by mail.gmx.net (mp041) with SMTP; 06 May 2006 19:56:07 +0200 X-Authenticated: #29516787 Message-ID: <445CE333.30904@gmx.net> Date: Sat, 06 May 2006 19:56:03 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt References: <445B4362.2070408@gmx.net> In-Reply-To: <445B4362.2070408@gmx.net> 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: f251f249fc9a04067ce354aa0943ab98 Cc: Roger Marshall , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Another tiny issue: The normative reference section should only contain [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. I would move the following references to the informative reference section to avoid creating unnecessary dependencies. [2] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004. [3] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [5] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", draft-ietf-ecrit-service-urn-02 (work in progress), April 2006. [6] Hardie, T., "LoST: A Location-to-Service Translation Protocol", draft-hardie-ecrit-lost-00 (work in progress), March 2006. [7] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", draft-ietf-geopriv-dhcp-civil-09 (work in progress), January 2006. I am not sure about the reference to the security threats document. Since it will hopefully be completed at the same time it does not really matter whether you put it into the normative or the informative part of the references section. [4] Taylor, T., "Security Threats and Requirements for Emergency Call Marking and Mapping", draft-ietf-ecrit-security-threats-01 (work in progress), April 2006. Ciao Hannes Hannes Tschofenig wrote: > Hi all, > > here is a review of draft-ietf-ecrit-requirements-08.txt. The document > is getting much better. Still, I have a few comments: > > * Introduction: > > > I would delete this paragraph since it is a bit confusing at this point: > > As used in this document, validation of location does not require > that we ascertain as to whether or not the location actually exists. > For example, validation might only check that the house number in a > civic address falls within the assigned range, not whether a > building, known by a specific building number, exists at that > location. However, such higher precision validation is desirable. > > This might be relevant in subsequent sections. > > > > Identification of the caller, while not incompatible with the > requirements for messaging outlined within this document, is > considered to be outside the scope of the ECRIT charter. > ^^^^^^^^^^^^^^^^^^ > > Don't mention the working group name in the document. > > Write "... is outside the scope of this document." > > > 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, for example, a TEL > URI which may be used to complete a call via the PSTN. > > I am not sure about this paragraph. Where do we provide such a > functionality? > > * Terminology > > I would cluster the terms. For example, you might want to keep > - (Location-dependent) emergency dial string > - Home emergency dial string > - Visited emergency dial string > together to make the terminology easier to read. > > There is no requirement to list the terms alphabetically. > > > Emergency address: The URI (e.g., SIP:URI, SIPS:URI, XMPP:URI, IM: > ^^^^^^^ change to identifier > URI, etc.) which represents the address of the PSAP useful for the > completion of an emergency call. > > Emergency call routing support: An intermediary function which > assists in the routing of an emergency call via IP. An ESRP is an > example of an Emergency call routing support entity. > ^^^^^^^^^ emergency > > > Delete the following paragraph: > > Codes: "caller" or "emergency caller" refers to the person placing an > emergency call or sending an emergency instant message (IM). > > AND move the text over to this term: > > Emergency caller: The user or user device entity which sends his/her > location to another entity in the network. > > As such, it would read: > > (Emergency) caller: The term "caller" or "emergency caller" refer to > the person placing an emergency call or sending an emergency instant > message (IM). > > > > In this document, the key words "MUST", "MUST NOT", "REQUIRED", > "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", > and "OPTIONAL" are to be interpreted as described in RFC 2119 [1], > with the qualification that unless otherwise stated these words apply > to the design of the mapping protocol, not its implementation or > application. > ^^^^^^^^^^^ usage > > > With the suggested change from "Emergency address" to "Emergency > identifer" we have the term 'emergency identifier' appearing twice: > > Emergency identifier: An identifier that marks a call as an emergency > call. > > I suggest to delete this definition or to merge it with the previous one. > > In the text we should always use small letters for terms like 'mapping > servers' or 'mapping clients'. For example, > > Mapping client: A mapping client interacts with the Mapping Server to > ^^^^^^^^^^^^^^ > learn one or more PSAP URIs for a given location. > > > Mapping server: The Mapping Server holds information about the > ^^^^^^^^^^^^^^ > location-to-PSAP URI mapping. > > > Change from: > > " > PSAP URI: PSAP URI is a general term, used to refer to the output of > the mapping protocol, and represents either the actual PSAP IP > address, or the IP address of some other intermediary, e.g., an > ESRP, which points to the actual PSAP. > " > > to: > > " > PSAP URI: The term 'PSAP URI' refers to a URI that identifiers a > PSAP. We use this term to denote the reponse of a mapping protocol query. > " > > * Section 3. Basic Actors > > In order to support emergency services covering a large physical > area, various infrastructure elements are necessary, including: > Internet Attachment Providers (IAPs), Application/Voice Service > Providers (ASP/VSPs), PSAPs as endpoints for emergency calls, mapping > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ delete > this part; the PSAP is only one endpoint of the communciation. > > services or other infrastructure elements that assist during the call > ^^^ and > routing. > > > o How is location information provided to the end host? It might > either be known to the end host itself via manual configuration, > provided via GPS, or obtained via a third party method. Even if > location information is known to the network it might be made > available to the end host via DHCP (RFC 3825 [2]) or some other > mechanism. Alternatively, location information is used as part of > call routing and inserted by intermediaries. > > > Change paragraph to: > > o How is location information provided to the end host? It might > either be known to the end host itself via manual configuration, > provided via GPS, made > available via DHCP (see RFC 3825 [2]) or some other > mechanisms. Alternatively, location information is used as part of > call routing and inserted by intermediaries. > > > (5) Location Information is used by emergency call routing entities > ^^^^^^^^^^^ information > for subsequent mapping requests. > > 4. High-Level Requirements > > Re1. Application/Voice service provider existence: The initiation of > an IP-based emergency call SHOULD NOT assume the existence of an > Application/Voice Service Provider (ASP/VSP). > > Motivation: The caller may not have an application/voice service > provider. For example, a residence may have its own DNS domain > and run its own SIP proxy server for that domain. On a larger > scale, a university might provide voice services to its students > and staff, but not be a telecommunication provider. > ^ add "might" > > > 5. Identifying the Caller's Location > > Location can either be provided directly, or by reference, and > represents either a civic location, or as a geographic location. > ^^ and geospatial location > information. > > How > does the location (or location reference) become associated with the > call? > > change last sentence to: > > "An important question is how and when to attach location information to > the VoIP emergency signaling." > > In general, we can distinguish three modes of operation of how > a location is associated with an emergency call: > > Change from: > > UA-inserted: The caller's user agent inserts the location information > into the call signaling message. The location information is > derived from sources such as GPS, DHCP (RFC 3825 [2]) and > I-D.ietf-geopriv-dhcp-civil [7]) or utilizing the Link Layer > Discovery Protocol (LLDP) [see IEEE8021AB]. > > > to: > > > UA-inserted: The caller's user agent inserts the location information > into the call signaling message. The location information is > derived from sources such as GPS, DHCP (see [2] for geospatial > location information and [7] for civic location information) or > utilizing the Link Layer > Discovery Protocol (LLDP) (see [IEEE8021AB]). > > > UA-referenced: The caller's user agent provides a pointer (i.e., a > location reference), via a permanent or temporary identifier, to > the location which is stored by a location service somewhere else > ^^^^^^^ server > delete the 'somewhere else' part. > and then retrieved by the PSAP, ESRP, or other authorized service > entity. > > Lo2. Location object/info preservation: The mapping protocol MUST > retain any location information which is provided to it, even > after mapping is performed. > > Motivation: The ESRP and the PSAP use the same location > information object, but for a different purpose. Therefore, it is > imperative that the mapping protocol not remove location > ^ does > Information so that the PSAP can still receive the caller > ^^^^^^^^^^^ information > location. > > > Lo5. Validation of civic location: The mapping protocol MUST support > location validation for civic location (street addresses), prior > to initiating an emergency call. > > delete the ", prior to initiating an emergency call." part. > > Motivation: Location validation provides an opportunity to help > assure ahead of time, whether or not successful mapping to the > ^ add 'a' > appropriate PSAP will likely occur when it is required. > Validation may also help to avoid delays during emergency call > setup due to invalid locations. > > > Isn't Lo7 similar to L10? > Isn't Lo6 similar to Lo11? > > > Lo9. 3D sensitive mapping: The mapping protocol MUST implement > support for both 2D and 3D location information, and may accept > either a 2D or 3D mapping request as input. > > Motivation: It is expected that provisioning systems will accept > ^^^^^^^^^^^^^^^^^^^^ what is that? > > 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 in the request. > > > 6. Emergency Identifier > > Id1. Emergency identifier support: The mapping protocol MUST support > one or more emergency identifiers for delivery back to mapping > clients to be used for call setup purposes. > > I guess this requirement should say: > > " > Emergency identifier support: The mapping protocol MUST be able to > return one or multiple emergency identifiers in response to a query. > " > > > > Id2. Emergency identifier resolution: Where multiple emergency > identifiers exist, the mapping protocol MUST be able to > differentiate between identifiers based on the specific type of > emergency help requested. > > Motivation: Some jurisdictions may have multiple types of > emergency services available, (e.g., fire, police, ambulance), in > which case, it is important that any one could be selected > directly. > > There is a terminology confusion here: > I think you refer to 'sos Service Types' here rather than multiple > emergency identifers. You might want to double-check with > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-02.txt > (and in particular with Section 4.3). > > This terminology issue impacts also requirement Id5. > > Id4. Prevention of fraud: If a call is identified as an emergency > call, the mapping protocol MUST support that call being > successfully routed to a PSAP. > > Motivation: This prevents use of the emergency call indication to > gain access to call features or authentication override for non- > emergency purposes. > > This requirement is covered in the security document. > > > Requirement Id6, Id7, Id8, Id9, Id10 start with "The mapping protocol > MUST/SHOULD support " but I think that these requirements do not > necessarily address the mapping protocol. I think a "There MUST be > support for...." > > > 7. Mapping Protocol > > There are two basic approaches to invoking a mapping service. We > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > invoke the mapping protocol. > > refer to these as caller-based and mediated. In each case, the > mapping client initiates a request to a mapping server via a mapping > protocol. A proposed mapping protocol is outlined in the document > I-D.hardie-ecrit-lost [6]. > > For caller-based resolution, the caller's user agent invokes a > ^ the > mapping service to determine the appropriate PSAP based on the > ^^^^^^^ protocol > location provided. The resolution may take place well before the > actual emergency call is placed, or at the time of the call. > > For mediated resolution, a call signaling server, such as a SIP > ^^^^^^^^^^^^^^^^^^^^^^^ > an emergency call routing support entity > > (outbound) proxy or redirect server invokes the mapping service. > > > Ma5. URI alternate contact: In addition to returning a primary > contact, the mapping protocol MUST support the return of a URI or > contact method explicitly marked as an alternate contact. > > Motivation: In response to a mapping request, the mapping server > may return an alternate URI. Implementation details to be > described within an operational document. > > > I am not quite sure about Ma6 and Ma8. Ma8 tells me that the mapping > protocol provides a URL for error reporting. Isn't Ma6 similar? > > > Ma6. URL properties: The mapping protocol MUST support the ability > ^^^ URI > > to provide ancillary information about a contact or URI that > ^^^^^^ delete > allows the mapping client to determine relevant properties of the > URL. > ^^^^ URI? > > > Motivation: In some cases, the same geographic area is served by > several PSAPs, for example, a corporate campus might be served by > both a corporate security department and the municipal PSAP. The > mapping protocol should then return URLs for both, with > ^^^^ URIs > information allowing the querying entity to choose one or the > other. This determination could be made by either an ESRP, based > on local policy, or by direct user choice, in the case of caller- > based methods. > > Ma7. Traceable resolution: The mapping protocol SHOULD support the > ability of the mapping client to be able to determine the entity > or entities which provided the emergency address resolution > ^^^^^ that > information. > > Motivation: It is important for public safety reasons, that there > is a method to provide operational traceability in case of errors. > > Ma8. URI for error reporting: The mapping protocol MUST support the > ^^^^ URL > > return of a URI that can be used to report a suspected or known > ^^^^^^^^^^^^^^^ the ability to return a URL > > error within the mapping database. > > Motivation: If an error is returned, for example, there needs to > be a URI which points to a resource which can explain or > ^^^^ URL > > potentially help resolve the error. > > > Ma16. Multiple PSAP URIs: The mapping protocol MUST support a method > to receive multiple PSAP URIs which cover the same geographic > ^^^^^^^ return > area. > > Motivation: Two different mapping servers may cover the same > geographic area, and therefore have the same set of coverage > information. > > Isn't this requirement very similar to Ma4? > > > > > * 8. Security Considerations > > Security considerations are discussed in the ECRIT security document > I-D.ietf-ecrit-security-threats [4] . > > Write: > > " > Threats and security requirements are discussed in a separate document, > see [4]. > " > > * Add an IANA section. > " > 9. IANA Considerations > > This document does not require actions by the IANA. > " > > > Ciao > Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 06 15:14:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcSEf-0007oS-SP; Sat, 06 May 2006 15:14:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcSEe-0007oN-Nq for ecrit@ietf.org; Sat, 06 May 2006 15:14:36 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcSEe-00057i-Bh for ecrit@ietf.org; Sat, 06 May 2006 15:14:36 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k46JECLS021372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 6 May 2006 12:14:13 -0700 Received: from [65.112.8.52] (vpn-10-50-0-127.qualcomm.com [10.50.0.127]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k46JE67W020846; Sat, 6 May 2006 12:14:11 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C49F1@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C49F1@oefeg-s04.oefeg.loc> Date: Sat, 6 May 2006 12:14:08 -0700 To: "Stastny Richard" , "Hannes Tschofenig" , , "Henning Schulzrinne" , "Roger Marshall" From: Ted Hardie Subject: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 7:09 PM +0200 5/6/06, Stastny Richard wrote: >IMHO there is a contradiction, (espeially between Ma6 and Ma17) or at least >this is very confusing. I do not know now if multiple URIs for the same contact >protocol are allowed or not) > >In one requirement the client needs to the select among differnt protocols, in the other not > >Richard I agree that this is a bit confusing, largely because Ma17 occurs after the others. I think if we moved it forward, it would make more sense, as it would then imply that the multiple URIs in Ma4 were each from a different scheme. The reason we did not want to return multiple contact URIs for a single scheme in a standard response was that we didn't want the client to have to worry about which of the returned URIs to pick (e.g., if I gave you six SIP URIs, which one should be selected?). The alternate contact field allowed you to handle the need for explicit indication of a fallback, but with the understanding that the client didn't need to determine an ordering in the response--the fallback was there only when the first contact was not available. That's my memory of how we got there. To make that clear, I suggest we move Ma17 up to be before Ma4, and we change "URI alternate contact" to say "explicitly marked as an alternate contact for use when a fallback contact is needed". regards, Ted > >Ma4. Multiple response URIs: The mapping protocol MUST support the > possible inclusion of multiple URIs in a mapping response. > Motivation: Multiple URIs may be available from the mapping > server. > > Ma5. URI alternate contact: In addition to returning a primary > contact, the mapping protocol MUST support the return of a URI or > contact method explicitly marked as an alternate contact. > Motivation: In response to a mapping request, the mapping server > may return an alternate URI. Implementation details to be > described within an operational document. > > Ma6. URL properties: The mapping protocol MUST support the ability > to provide ancillary information about a contact or URI that > allows the mapping client to determine relevant properties of the > URL. > Motivation: In some cases, the same geographic area is served by > several PSAPs, for example, a corporate campus might be served by > both a corporate security department and the municipal PSAP. The > mapping protocol should then return URLs for both, with > information allowing the querying entity to choose one or the > other. This determination could be made by either an ESRP, based > on local policy, or by direct user choice, in the case of caller- > based methods. > > Ma17. Single URI per contact protocol: Though the mapping protocol > supports the return of multiple URIs, it SHOULD return only one > URI per contact protocol, 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. > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 06 15:53:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcSqB-0002fx-HI; Sat, 06 May 2006 15:53:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcSqA-0002fr-5y for ecrit@ietf.org; Sat, 06 May 2006 15:53:22 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FcSq8-0006yG-Eb for ecrit@ietf.org; Sat, 06 May 2006 15:53:22 -0400 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] Review of draft-ietf-ecrit-requirements-08.txt Date: Sat, 6 May 2006 21:54:30 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C49F2@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Thread-Index: AcZxQeQkKb/tlBeVTmyfiSeTdkFTzgABP92i From: "Stastny Richard" To: "Ted Hardie" , "Hannes Tschofenig" , , "Henning Schulzrinne" , "Roger Marshall" X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org >To make that clear, I suggest >we move Ma17 up to be before Ma4, and we change "URI alternate >contact" to say "explicitly marked as an alternate contact for use when >a fallback contact is needed". Yes, thank you for the clarification, this would clarify the issue =20 Richard ________________________________ Von: Ted Hardie [mailto:hardie@qualcomm.com] Gesendet: Sa 06.05.2006 21:14 An: Stastny Richard; Hannes Tschofenig; ecrit@ietf.org; Henning = Schulzrinne; Roger Marshall Betreff: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt At 7:09 PM +0200 5/6/06, Stastny Richard wrote: >IMHO there is a contradiction, (espeially between Ma6 and Ma17) or at = least >this is very confusing. I do not know now if multiple URIs for the same = contact >protocol are allowed or not) > >In one requirement the client needs to the select among differnt = protocols, in the other not > >Richard I agree that this is a bit confusing, largely because Ma17 occurs after = the others. I think if we moved it forward, it would make more sense, as it would then imply that the multiple URIs in Ma4 were each from a = different scheme. The reason we did not want to return multiple contact URIs for a single = scheme in a standard response was that we didn't want the client to have to = worry about which of the returned URIs to pick (e.g., if I gave you six SIP = URIs, which one should be selected?). The alternate contact field allowed you to handle the need for explicit indication of a fallback, but with the understanding that the client = didn't need to determine an ordering in the response--the fallback was there = only when the first contact was not available. That's my memory of how we got there. To make that clear, I suggest we move Ma17 up to be before Ma4, and we change "URI alternate contact" to say "explicitly marked as an alternate contact for use when a fallback contact is needed". regards, Ted > >Ma4. Multiple response URIs: The mapping protocol MUST support the > possible inclusion of multiple URIs in a mapping response. > Motivation: Multiple URIs may be available from the mapping > server. > > Ma5. URI alternate contact: In addition to returning a primary > contact, the mapping protocol MUST support the return of a URI or > contact method explicitly marked as an alternate contact. > Motivation: In response to a mapping request, the mapping server > may return an alternate URI. Implementation details to be > described within an operational document. > > Ma6. URL properties: The mapping protocol MUST support the ability > to provide ancillary information about a contact or URI that > allows the mapping client to determine relevant properties of the > URL. > Motivation: In some cases, the same geographic area is served by > several PSAPs, for example, a corporate campus might be served by > both a corporate security department and the municipal PSAP. The > mapping protocol should then return URLs for both, with > information allowing the querying entity to choose one or the > other. This determination could be made by either an ESRP, based > on local policy, or by direct user choice, in the case of caller- > based methods. > > Ma17. Single URI per contact protocol: Though the mapping protocol > supports the return of multiple URIs, it SHOULD return only one > URI per contact protocol, 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. > >_______________________________________________ >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 May 08 18:52:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdEas-0000c7-Rg; Mon, 08 May 2006 18:52:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdEaq-0000bw-OU for ecrit@ietf.org; Mon, 08 May 2006 18:52:44 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdEap-0006FA-D8 for ecrit@ietf.org; Mon, 08 May 2006 18:52:44 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Mon, 8 May 2006 15:52:35 -0700 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] Review of draft-ietf-ecrit-requirements-08.txt Date: Mon, 8 May 2006 15:52:34 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657504E2E872@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Thread-Index: AcZxC3YmkX+rFQuVTiObeB3efeagdQB5lBTA From: "Roger Marshall" To: "Ted Hardie" , "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Ted: I'm glad you clarified, since I admit struggling some over that last text! Anyway, I think it reads better with even less text: PSAP URI: The URI (e.g., SIP:URI, SIPS:URI, XMPP:URI,=20 etc.) at which the PSAP may be contacted with an emergency call. This=20 contact could be done directly, or via an intermediary, (e.g., ESRP). -roger. >-----Original Message----- >From: Ted Hardie [mailto:hardie@qualcomm.com]=20 >Sent: Saturday, May 06, 2006 5:49 AM >To: Roger Marshall; Hannes Tschofenig >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt > >At 4:34 PM -0700 5/5/06, Roger Marshall wrote: >>The >>URI contains information about the protocol used (encoded in the=20 >>scheme), so that a focus on the IP address that it may resolve to is=20 >>not appropriate. >>There are even cases where the SIP:URI and the XMPP:URI for the same=20 >>PSAP might not point to the same box. > >I hadn't actually intended for the lines above to be included;=20 >I meant them as further information about the URI for the=20 >group. If people think that it is valuable to include it,=20 >though, I would elide "so that a focus on the IP address that=20 >it may resolve to is not appropriate.". > regards, > Ted Hardie > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 08 19:01:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdEj1-00076W-2x; Mon, 08 May 2006 19:01:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdEj0-00076R-16 for ecrit@ietf.org; Mon, 08 May 2006 19:01:10 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdEiy-00076z-LG for ecrit@ietf.org; Mon, 08 May 2006 19:01:10 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k48N14kq022191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 May 2006 16:01:05 -0700 Received: from [10.0.1.4] (vpn-10-50-0-165.qualcomm.com [10.50.0.165]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k48N11ag012978; Mon, 8 May 2006 16:01:02 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <8C837214C95C864C9F34F3635C2A657504E2E872@SEA-EXCHVS-2.telecomsys.com> References: <8C837214C95C864C9F34F3635C2A657504E2E872@SEA-EXCHVS-2.telecomsys.com> Date: Mon, 8 May 2006 16:00:57 -0700 To: "Roger Marshall" , "Hannes Tschofenig" From: Ted Hardie Subject: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 3:52 PM -0700 5/8/06, Roger Marshall wrote: >Ted: >I'm glad you clarified, since I admit struggling some over that last >text! > >Anyway, I think it reads better with even less text: > >PSAP URI: The URI (e.g., SIP:URI, SIPS:URI, XMPP:URI, >etc.) at which the PSAP may be contacted with an emergency call. This >contact could be done directly, or via an intermediary, (e.g., ESRP). > >-roger. That certainly works for me. Ted > >-----Original Message----- >>From: Ted Hardie [mailto:hardie@qualcomm.com] >>Sent: Saturday, May 06, 2006 5:49 AM >>To: Roger Marshall; Hannes Tschofenig >>Cc: ecrit@ietf.org >>Subject: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt >> >>At 4:34 PM -0700 5/5/06, Roger Marshall wrote: >>>The >>>URI contains information about the protocol used (encoded in the >>>scheme), so that a focus on the IP address that it may resolve to is >>>not appropriate. >>>There are even cases where the SIP:URI and the XMPP:URI for the same >>>PSAP might not point to the same box. >> >>I hadn't actually intended for the lines above to be included; >>I meant them as further information about the URI for the >>group. If people think that it is valuable to include it, >>though, I would elide "so that a focus on the IP address that >>it may resolve to is not appropriate.". >> regards, >> Ted Hardie >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 08 19:29:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdFAa-00069B-7O; Mon, 08 May 2006 19:29:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdFAZ-000696-H1 for ecrit@ietf.org; Mon, 08 May 2006 19:29:39 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdFAZ-0008WB-0u for ecrit@ietf.org; Mon, 08 May 2006 19:29:39 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Mon, 8 May 2006 16:29:36 -0700 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] Review of draft-ietf-ecrit-requirements-08.txt Date: Mon, 8 May 2006 16:29:36 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657504E2E8D0@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Thread-Index: AcZxQeQkKb/tlBeVTmyfiSeTdkFTzgABP92iAGvauRA= From: "Roger Marshall" To: "Stastny Richard" , "Ted Hardie" , "Hannes Tschofenig" , , "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Ok, based on the points Richard made, and Ted's suggestions, and other than some slight ordering changes (Ma4 still first, then Ma17, since the latter has a referenced qualification pointing to the former), and some minor rewording for read-ability, here's the resulting clump of requirements which we were talking about: ... Ma4. Multiple response URIs: The mapping protocol=20 MUST allow multiple URIs to be inclued in a mapping response. Motivation: Multiple URIs may be available from the mapping server. Ma17. Single URI per contact protocol: Though there is=20 support for multiple URIs being returned, the mapping protocol SHOULD=20 return only one URI per contact protocol used, so that clients are not=20 required to select among different targets for the same contact protocol. Motivation: There may be two or more URIs returned when multiple=20 contact protocols are available (e.g., SIP and SMS). The client may=20 select among multiple contact protocols based on its capabilities,=20 preference settings, or availability. Ma5. URI alternate contact: In addition to returning a=20 primary contact, the mapping protocol MUST support the return of a URI=20 or contact method explicitly marked as an alternate contact for use when a fallback contact is needed. Motivation: In response to a mapping request, the mapping server=20 may return an alternate URI. Implementation details to be described=20 within an operational document. Ma6. URL properties:"> The mapping protocol MUST=20 support the ability to provide ancillary information about a contact or URI=20 that allows the mapping client to determine relevant properties of the=20 URL. Motivation: In some cases, the same geographic area is served by=20 several PSAPs, for example, a corporate campus might be served by=20 both a corporate security department and the municipal PSAP. The=20 mapping protocol should then return URLs for both, with information=20 allowing the querying entity to choose one or the other. This=20 determination could be made by either an ESRP, based on local policy,=20 or by direct user choice, in the case of caller-based methods. ... Out-of-order numbering left for reference. These will be renumbered in next draft vers. -roger. >-----Original Message----- >From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 >Sent: Saturday, May 06, 2006 12:55 PM >To: Ted Hardie; Hannes Tschofenig; ecrit@ietf.org; Henning=20 >Schulzrinne; Roger Marshall >Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt > >>To make that clear, I suggest >>we move Ma17 up to be before Ma4, and we change "URI=20 >alternate contact"=20 >>to say "explicitly marked as an alternate contact for use when a=20 >>fallback contact is needed". > >Yes, thank you for the clarification, this would clarify the issue >=20 >Richard > > >________________________________ > >Von: Ted Hardie [mailto:hardie@qualcomm.com] >Gesendet: Sa 06.05.2006 21:14 >An: Stastny Richard; Hannes Tschofenig; ecrit@ietf.org;=20 >Henning Schulzrinne; Roger Marshall >Betreff: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt > > > >At 7:09 PM +0200 5/6/06, Stastny Richard wrote: >>IMHO there is a contradiction, (espeially between Ma6 and =20 >Ma17) or at=20 >>least this is very confusing. I do not know now if multiple URIs for=20 >>the same contact protocol are allowed or not) >> >>In one requirement the client needs to the select among differnt=20 >>protocols, in the other not >> >>Richard > >I agree that this is a bit confusing, largely because Ma17=20 >occurs after the others. I think if we moved it forward, it=20 >would make more sense, as it would then imply that the=20 >multiple URIs in Ma4 were each from a different scheme. > >The reason we did not want to return multiple contact URIs for=20 >a single scheme in a standard response was that we didn't want=20 >the client to have to worry about which of the returned URIs=20 >to pick (e.g., if I gave you six SIP URIs, which one should be=20 >selected?). > >The alternate contact field allowed you to handle the need for=20 >explicit indication of a fallback, but with the understanding=20 >that the client didn't need to determine an ordering in the=20 >response--the fallback was there only when the first contact=20 >was not available. > >That's my memory of how we got there. To make that clear, I suggest >we move Ma17 up to be before Ma4, and we change "URI alternate=20 >contact" to say "explicitly marked as an alternate contact for=20 >use when a fallback contact is needed". > regards, > Ted > > >> >>Ma4. Multiple response URIs: The mapping protocol MUST support the >> possible inclusion of multiple URIs in a mapping response. >> Motivation: Multiple URIs may be available from the mapping >> server. >> >> Ma5. URI alternate contact: In addition to returning a primary >> contact, the mapping protocol MUST support the return=20 >of a URI or >> contact method explicitly marked as an alternate contact. >> Motivation: In response to a mapping request, the mapping server >> may return an alternate URI. Implementation details to be >> described within an operational document. >> >> Ma6. URL properties: The mapping protocol MUST support the ability >> to provide ancillary information about a contact or URI that >> allows the mapping client to determine relevant=20 >properties of the >> URL. >> Motivation: In some cases, the same geographic area is served by >> several PSAPs, for example, a corporate campus might be=20 >served by >> both a corporate security department and the municipal=20 >PSAP. The >> mapping protocol should then return URLs for both, with >> information allowing the querying entity to choose one or the >> other. This determination could be made by either an=20 >ESRP, based >> on local policy, or by direct user choice, in the case=20 >of caller- >> based methods. >> >> Ma17. Single URI per contact protocol: Though the mapping protocol >> supports the return of multiple URIs, it SHOULD return only one >> URI per contact protocol, 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. >> >>_______________________________________________ >>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 May 08 20:28:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdG4v-0006uJ-PG; Mon, 08 May 2006 20:27:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdG4u-0006tY-M3 for ecrit@ietf.org; Mon, 08 May 2006 20:27:52 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdFKM-0000W6-2l for ecrit@ietf.org; Mon, 08 May 2006 19:39:46 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FdFDO-0006N0-QA for ecrit@ietf.org; Mon, 08 May 2006 19:32:38 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Mon, 8 May 2006 16:32:31 -0700 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] Review of draft-ietf-ecrit-requirements-08.txt Date: Mon, 8 May 2006 16:32:30 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657504E2E8D5@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Thread-Index: AcZxNlz3OygiTefgRyOcXmpD9BZ2EwBwRwtg From: "Roger Marshall" To: "Hannes Tschofenig" X-Spam-Score: -1.9 (-) X-Scan-Signature: 559439f19b20fd64c5cd872aef84c6f3 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Ok, references relocated as suggested. Pushed security draft into Info section as well. -roger. >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 >Sent: Saturday, May 06, 2006 10:56 AM >To: Hannes Tschofenig >Cc: ecrit@ietf.org; Henning Schulzrinne; Roger Marshall >Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt > >Another tiny issue: > >The normative reference section should only contain > > [1] Bradner, S., "Key words for use in RFCs to Indicate=20 >Requirement > Levels", BCP 14, RFC 2119, March 1997. > >I would move the following references to the informative=20 >reference section to avoid creating unnecessary dependencies. > > [2] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host > Configuration Protocol Option for Coordinate-based Location > Configuration Information", RFC 3825, July 2004. > > [3] Peterson, J., "A Presence-based GEOPRIV Location=20 >Object Format", > RFC 4119, December 2005. > [5] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", > draft-ietf-ecrit-service-urn-02 (work in progress),=20 >April 2006. > > [6] Hardie, T., "LoST: A Location-to-Service Translation=20 >Protocol", > draft-hardie-ecrit-lost-00 (work in progress), March 2006. > > [7] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 > and DHCPv6) Option for Civic Addresses Configuration > Information", draft-ietf-geopriv-dhcp-civil-09 (work in > progress), January 2006. > >I am not sure about the reference to the security threats document.=20 >Since it will hopefully be completed at the same time it does=20 >not really matter whether you put it into the normative or the=20 >informative part of the references section. > > [4] Taylor, T., "Security Threats and Requirements for Emergency > Call Marking and Mapping",=20 >draft-ietf-ecrit-security-threats-01 > (work in progress), April 2006. > > >Ciao >Hannes > > > >Hannes Tschofenig wrote: >> Hi all, >>=20 >> here is a review of draft-ietf-ecrit-requirements-08.txt.=20 >The document=20 >> is getting much better. Still, I have a few comments: >>=20 >> * Introduction: >>=20 >>=20 >> I would delete this paragraph since it is a bit confusing at=20 >this point: >>=20 >> As used in this document, validation of location does not require >> that we ascertain as to whether or not the location=20 >actually exists. >> For example, validation might only check that the house=20 >number in a >> civic address falls within the assigned range, not whether a >> building, known by a specific building number, exists at that >> location. However, such higher precision validation is desirable. >>=20 >> This might be relevant in subsequent sections. >>=20 >>=20 >>=20 >> Identification of the caller, while not incompatible with the >> requirements for messaging outlined within this document, is >> considered to be outside the scope of the ECRIT charter. >> ^^^^^^^^^^^^^^^^^^ >>=20 >> Don't mention the working group name in the document. >>=20 >> Write "... is outside the scope of this document." >>=20 >>=20 >> Despite this goal, some PSAPs >> may not immediately have IP based connectivity, and=20 >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, for=20 >example, a TEL >> URI which may be used to complete a call via the PSTN. >>=20 >> I am not sure about this paragraph. Where do we provide such a=20 >> functionality? >>=20 >> * Terminology >>=20 >> I would cluster the terms. For example, you might want to keep >> - (Location-dependent) emergency dial string >> - Home emergency dial string >> - Visited emergency dial string >> together to make the terminology easier to read. >>=20 >> There is no requirement to list the terms alphabetically. >>=20 >>=20 >> Emergency address: The URI (e.g., SIP:URI, SIPS:URI, XMPP:URI, IM: >> ^^^^^^^ change to identifier >> URI, etc.) which represents the address of the PSAP=20 >useful for the >> completion of an emergency call. >>=20 >> Emergency call routing support: An intermediary function which >> assists in the routing of an emergency call via IP. =20 >An ESRP is an >> example of an Emergency call routing support entity. >> ^^^^^^^^^ emergency >>=20 >>=20 >> Delete the following paragraph: >>=20 >> Codes: "caller" or "emergency caller" refers to the=20 >person placing an >> emergency call or sending an emergency instant message (IM). >>=20 >> AND move the text over to this term: >>=20 >> Emergency caller: The user or user device entity which=20 >sends his/her >> location to another entity in the network. >>=20 >> As such, it would read: >>=20 >> (Emergency) caller: The term "caller" or "emergency caller" refer=20 >> to the person placing an emergency call or sending an emergency=20 >> instant message (IM). >>=20 >>=20 >>=20 >> In this document, the key words "MUST", "MUST NOT", "REQUIRED", >> "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",=20 >"RECOMMENDED", "MAY", >> and "OPTIONAL" are to be interpreted as described in RFC 2119 [1], >> with the qualification that unless otherwise stated these=20 >words apply >> to the design of the mapping protocol, not its implementation or >> application. >> ^^^^^^^^^^^ usage >>=20 >>=20 >> With the suggested change from "Emergency address" to "Emergency=20 >> identifer" we have the term 'emergency identifier' appearing twice: >>=20 >> Emergency identifier: An identifier that marks a call as=20 >an emergency >> call. >>=20 >> I suggest to delete this definition or to merge it with the=20 >previous one. >>=20 >> In the text we should always use small letters for terms=20 >like 'mapping=20 >> servers' or 'mapping clients'. For example, >>=20 >> Mapping client: A mapping client interacts with the=20 >Mapping Server to >> ^^^^^^^^^^^^^^ >> learn one or more PSAP URIs for a given location. >>=20 >>=20 >> Mapping server: The Mapping Server holds information about the >> ^^^^^^^^^^^^^^ >> location-to-PSAP URI mapping. >>=20 >>=20 >> Change from: >>=20 >> " >> PSAP URI: PSAP URI is a general term, used to refer to=20 >the output of >> the mapping protocol, and represents either the actual PSAP IP >> address, or the IP address of some other intermediary, e.g., an >> ESRP, which points to the actual PSAP. >> " >>=20 >> to: >>=20 >> " >> PSAP URI: The term 'PSAP URI' refers to a URI that identifiers a=20 >> PSAP. We use this term to denote the reponse of a mapping=20 >protocol query. >> " >>=20 >> * Section 3. Basic Actors >>=20 >> In order to support emergency services covering a large physical >> area, various infrastructure elements are necessary, including: >> Internet Attachment Providers (IAPs), Application/Voice Service >> Providers (ASP/VSPs), PSAPs as endpoints for emergency=20 >calls, mapping >> =20 >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ delete=20 >> this part; the PSAP is only one endpoint of the communciation. >>=20 >> services or other infrastructure elements that assist=20 >during the call >> ^^^ and >> routing. >>=20 >>=20 >> o How is location information provided to the end=20 >host? It might >> either be known to the end host itself via manual configuration, >> provided via GPS, or obtained via a third party method. Even if >> location information is known to the network it might be made >> available to the end host via DHCP (RFC 3825 [2]) or some other >> mechanism. Alternatively, location information is used as part of >> call routing and inserted by intermediaries. >>=20 >>=20 >> Change paragraph to: >>=20 >> o How is location information provided to the end host? It might >> either be known to the end host itself via manual configuration, >> provided via GPS, made >> available via DHCP (see RFC 3825 [2]) or some other >> mechanisms. Alternatively, location information is used=20 >as part of >> call routing and inserted by intermediaries. >>=20 >>=20 >> (5) Location Information is used by emergency call=20 >routing entities >> ^^^^^^^^^^^ information >> for subsequent mapping requests. >>=20 >> 4. High-Level Requirements >>=20 >> Re1. Application/Voice service provider existence: The=20 >initiation of >> an IP-based emergency call SHOULD NOT assume the=20 >existence of an >> Application/Voice Service Provider (ASP/VSP). >>=20 >> Motivation: The caller may not have an=20 >application/voice service >> provider. For example, a residence may have its own DNS domain >> and run its own SIP proxy server for that domain. On a larger >> scale, a university might provide voice services to=20 >its students >> and staff, but not be a telecommunication provider. >> ^ add "might" >>=20 >>=20 >> 5. Identifying the Caller's Location >>=20 >> Location can either be provided directly, or by reference, and >> represents either a civic location, or as a geographic location. >> ^^ and geospatial location=20 >> information. >>=20 >> How >> does the location (or location reference) become=20 >associated with the >> call? >>=20 >> change last sentence to: >>=20 >> "An important question is how and when to attach location=20 >information=20 >> to the VoIP emergency signaling." >>=20 >> In general, we can distinguish three modes of operation of how >> a location is associated with an emergency call: >>=20 >> Change from: >>=20 >> UA-inserted: The caller's user agent inserts the location=20 >information >> into the call signaling message. The location information is >> derived from sources such as GPS, DHCP (RFC 3825 [2]) and >> I-D.ietf-geopriv-dhcp-civil [7]) or utilizing the Link Layer >> Discovery Protocol (LLDP) [see IEEE8021AB]. >>=20 >>=20 >> to: >>=20 >>=20 >> UA-inserted: The caller's user agent inserts the location=20 >information >> into the call signaling message. The location information is >> derived from sources such as GPS, DHCP (see [2] for geospatial=20 >> location information and [7] for civic location information) or=20 >> utilizing the Link Layer >> Discovery Protocol (LLDP) (see [IEEE8021AB]). >>=20 >>=20 >> UA-referenced: The caller's user agent provides a pointer (i.e., a >> location reference), via a permanent or temporary=20 >identifier, to >> the location which is stored by a location service=20 >somewhere else >> ^^^^^^^=20 >server delete=20 >> the 'somewhere else' part. >> and then retrieved by the PSAP, ESRP, or other=20 >authorized service >> entity. >>=20 >> Lo2. Location object/info preservation: The mapping protocol MUST >> retain any location information which is provided to it, even >> after mapping is performed. >>=20 >> Motivation: The ESRP and the PSAP use the same location >> information object, but for a different purpose. =20 >Therefore, it is >> imperative that the mapping protocol not remove location >> ^ does >> Information so that the PSAP can still receive the caller >> ^^^^^^^^^^^ information >> location. >>=20 >>=20 >> Lo5. Validation of civic location: The mapping protocol=20 >MUST support >> location validation for civic location (street=20 >addresses), prior >> to initiating an emergency call. >>=20 >> delete the ", prior to initiating an emergency call." part. >>=20 >> Motivation: Location validation provides an opportunity to help >> assure ahead of time, whether or not successful mapping to the >> ^ add 'a' >> 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 >>=20 >> Isn't Lo7 similar to L10? >> Isn't Lo6 similar to Lo11? >>=20 >>=20 >> Lo9. 3D sensitive mapping: The mapping protocol MUST implement >> support for both 2D and 3D location information, and may accept >> either a 2D or 3D mapping request as input. >>=20 >> Motivation: It is expected that provisioning systems=20 >will accept >> ^^^^^^^^^^^^^^^^^^^^=20 >what is that? >>=20 >> both 2D and 3D data. When a 3D request is presented to an area >> only defined by 2D data, the mapping result would be=20 >the same as >> if the height/altitude dimension was omitted in the request. >>=20 >>=20 >> 6. Emergency Identifier >>=20 >> Id1. Emergency identifier support: The mapping protocol=20 >MUST support >> one or more emergency identifiers for delivery back to mapping >> clients to be used for call setup purposes. >>=20 >> I guess this requirement should say: >>=20 >> " >> Emergency identifier support: The mapping protocol MUST be able to=20 >> return one or multiple emergency identifiers in response to a query. >> " >>=20 >>=20 >>=20 >> Id2. Emergency identifier resolution: Where multiple emergency >> identifiers exist, the mapping protocol MUST be able to >> differentiate between identifiers based on the specific type of >> emergency help requested. >>=20 >> Motivation: Some jurisdictions may have multiple types of >> emergency services available, (e.g., fire, police,=20 >ambulance), in >> which case, it is important that any one could be selected >> directly. >>=20 >> There is a terminology confusion here: >> I think you refer to 'sos Service Types' here rather than multiple=20 >> emergency identifers. You might want to double-check with=20 >>=20 >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-02.tx >> t >> (and in particular with Section 4.3). >>=20 >> This terminology issue impacts also requirement Id5. >>=20 >> Id4. Prevention of fraud: If a call is identified as an emergency >> call, the mapping protocol MUST support that call being >> successfully routed to a PSAP. >>=20 >> Motivation: This prevents use of the emergency call=20 >indication to >> gain access to call features or authentication=20 >override for non- >> emergency purposes. >>=20 >> This requirement is covered in the security document. >>=20 >>=20 >> Requirement Id6, Id7, Id8, Id9, Id10 start with "The mapping=20 >protocol=20 >> MUST/SHOULD support " but I think that these requirements do not=20 >> necessarily address the mapping protocol. I think a "There MUST be=20 >> support for...." >>=20 >>=20 >> 7. Mapping Protocol >>=20 >> There are two basic approaches to invoking a mapping service. We >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> invoke the mapping protocol. >>=20 >> refer to these as caller-based and mediated. In each case, the >> mapping client initiates a request to a mapping server=20 >via a mapping >> protocol. A proposed mapping protocol is outlined in the document >> I-D.hardie-ecrit-lost [6]. >>=20 >> For caller-based resolution, the caller's user agent invokes a >> ^ the >> mapping service to determine the appropriate PSAP based on the >> ^^^^^^^ protocol >> location provided. The resolution may take place well before the >> actual emergency call is placed, or at the time of the call. >>=20 >> For mediated resolution, a call signaling server, such as a SIP >> ^^^^^^^^^^^^^^^^^^^^^^^ >> an emergency call routing support entity >>=20 >> (outbound) proxy or redirect server invokes the mapping service. >>=20 >>=20 >> Ma5. URI alternate contact: In addition to returning a primary >> contact, the mapping protocol MUST support the return=20 >of a URI or >> contact method explicitly marked as an alternate contact. >>=20 >> Motivation: In response to a mapping request, the=20 >mapping server >> may return an alternate URI. Implementation details to be >> described within an operational document. >>=20 >>=20 >> I am not quite sure about Ma6 and Ma8. Ma8 tells me that the mapping=20 >> protocol provides a URL for error reporting. Isn't Ma6 similar? >>=20 >>=20 >> Ma6. URL properties: The mapping protocol MUST support=20 >the ability >> ^^^ URI >>=20 >> to provide ancillary information about a contact or URI that >> ^^^^^^ delete >> allows the mapping client to determine relevant=20 >properties of the >> URL. >> ^^^^ URI? >>=20 >>=20 >> Motivation: In some cases, the same geographic area is=20 >served by >> several PSAPs, for example, a corporate campus might=20 >be served by >> both a corporate security department and the municipal=20 >PSAP. The >> mapping protocol should then return URLs for both, with >> ^^^^ URIs >> information allowing the querying entity to choose one or the >> other. This determination could be made by either an=20 >ESRP, based >> on local policy, or by direct user choice, in the case=20 >of caller- >> based methods. >>=20 >> Ma7. Traceable resolution: The mapping protocol SHOULD=20 >support the >> ability of the mapping client to be able to determine=20 >the entity >> or entities which provided the emergency address resolution >> ^^^^^ that >> information. >>=20 >> Motivation: It is important for public safety reasons,=20 >that there >> is a method to provide operational traceability in=20 >case of errors. >>=20 >> Ma8. URI for error reporting: The mapping protocol MUST=20 >support the >> ^^^^ URL >>=20 >> return of a URI that can be used to report a suspected or known >> ^^^^^^^^^^^^^^^ the ability to return a URL >>=20 >> error within the mapping database. >>=20 >> Motivation: If an error is returned, for example,=20 >there needs to >> be a URI which points to a resource which can explain or >> ^^^^ URL >>=20 >> potentially help resolve the error. >>=20 >>=20 >> Ma16. Multiple PSAP URIs: The mapping protocol MUST=20 >support a method >> to receive multiple PSAP URIs which cover the same geographic >> ^^^^^^^ return >> area. >>=20 >> Motivation: Two different mapping servers may cover the same >> geographic area, and therefore have the same set of coverage >> information. >>=20 >> Isn't this requirement very similar to Ma4? >>=20 >>=20 >>=20 >>=20 >> * 8. Security Considerations >>=20 >> Security considerations are discussed in the ECRIT=20 >security document >> I-D.ietf-ecrit-security-threats [4] . >>=20 >> Write: >>=20 >> " >> Threats and security requirements are discussed in a separate=20 >> document, see [4]. >> " >>=20 >> * Add an IANA section. >> " >> 9. IANA Considerations >>=20 >> This document does not require actions by the IANA. >> " >>=20 >>=20 >> Ciao >> Hannes >>=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 From ecrit-bounces@ietf.org Tue May 09 03:08:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdMKW-0007n5-PF; Tue, 09 May 2006 03:08:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdMKV-0007Zj-F7 for ecrit@ietf.org; Tue, 09 May 2006 03:08:23 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FdMKU-0007EG-M5 for ecrit@ietf.org; Tue, 09 May 2006 03:08:23 -0400 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] Review of draft-ietf-ecrit-requirements-08.txt Date: Tue, 9 May 2006 09:12:20 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C49FE@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Thread-Index: AcZxQeQkKb/tlBeVTmyfiSeTdkFTzgABP92iAGvauRAAEBZAvQ== From: "Stastny Richard" To: "Roger Marshall" , "Ted Hardie" , "Hannes Tschofenig" , , "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Roger, =20 this is much better now. =20 IMHO the issue could still be slightly improved: =20 In Ma5 we are talking about an alternate contact and a primary contact =20 It should be clearly stated in Ma17 that we talk here about the primary = contact: =20 Sugestion: Change Ma17 from: =20 Ma17. Single URI per contact protocol: Though there is support for multiple URIs being returned, the mapping protocol SHOULD return only one URI per contact protocol used, so that clients are not required to select among different targets for the same contact protocol =20 to: =20 Ma17. Single primary URI per contact protocol: Though there is support for multiple URIs being returned, the mapping protocol SHOULD return only one explicitely marked primary URI per contact protocol = used,=20 so that clients are not required to select among different targets for the same contact protocol =20 regards Richard ________________________________ Von: Roger Marshall [mailto:RMarshall@telecomsys.com] Gesendet: Di 09.05.2006 01:29 An: Stastny Richard; Ted Hardie; Hannes Tschofenig; ecrit@ietf.org; = Henning Schulzrinne Betreff: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Ok, based on the points Richard made, and Ted's suggestions, and other than some slight ordering changes (Ma4 still first, then Ma17, since the latter has a referenced qualification pointing to the former), and some minor rewording for read-ability, here's the resulting clump of requirements which we were talking about: ... Ma4. Multiple response URIs: The mapping protocol MUST allow multiple URIs to be inclued in a mapping response. Motivation: Multiple URIs may be available from the mapping server. Ma17. Single URI per contact protocol: Though there is support for multiple URIs being returned, the mapping protocol SHOULD return only one URI per contact protocol used, 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. Ma5. URI alternate contact: In addition to returning a primary contact, the mapping protocol MUST support the return of a URI or contact method explicitly marked as an alternate contact for use when a fallback contact is needed. Motivation: In response to a mapping request, the mapping server may return an alternate URI. Implementation details to be described within an operational document. Ma6. URL properties:"> The mapping protocol MUST support the ability to provide ancillary information about a contact or URI that allows the mapping client to determine relevant properties of the URL. Motivation: In some cases, the same geographic area is served by several PSAPs, for example, a corporate campus might be served by both a corporate security department and the municipal PSAP. The mapping protocol should then return URLs for both, with information allowing the querying entity to choose one or the other. This determination could be made by either an ESRP, based on local policy, or by direct user choice, in the case of caller-based methods. ... Out-of-order numbering left for reference. These will be renumbered in next draft vers. -roger. >-----Original Message----- >From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] >Sent: Saturday, May 06, 2006 12:55 PM >To: Ted Hardie; Hannes Tschofenig; ecrit@ietf.org; Henning >Schulzrinne; Roger Marshall >Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt > >>To make that clear, I suggest >>we move Ma17 up to be before Ma4, and we change "URI >alternate contact" >>to say "explicitly marked as an alternate contact for use when a >>fallback contact is needed". > >Yes, thank you for the clarification, this would clarify the issue > >Richard > > >________________________________ > >Von: Ted Hardie [mailto:hardie@qualcomm.com] >Gesendet: Sa 06.05.2006 21:14 >An: Stastny Richard; Hannes Tschofenig; ecrit@ietf.org; >Henning Schulzrinne; Roger Marshall >Betreff: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt > > > >At 7:09 PM +0200 5/6/06, Stastny Richard wrote: >>IMHO there is a contradiction, (espeially between Ma6 and=20 >Ma17) or at >>least this is very confusing. I do not know now if multiple URIs for >>the same contact protocol are allowed or not) >> >>In one requirement the client needs to the select among differnt >>protocols, in the other not >> >>Richard > >I agree that this is a bit confusing, largely because Ma17 >occurs after the others. I think if we moved it forward, it >would make more sense, as it would then imply that the >multiple URIs in Ma4 were each from a different scheme. > >The reason we did not want to return multiple contact URIs for >a single scheme in a standard response was that we didn't want >the client to have to worry about which of the returned URIs >to pick (e.g., if I gave you six SIP URIs, which one should be >selected?). > >The alternate contact field allowed you to handle the need for >explicit indication of a fallback, but with the understanding >that the client didn't need to determine an ordering in the >response--the fallback was there only when the first contact >was not available. > >That's my memory of how we got there. To make that clear, I suggest >we move Ma17 up to be before Ma4, and we change "URI alternate >contact" to say "explicitly marked as an alternate contact for >use when a fallback contact is needed". > regards, > Ted > > >> >>Ma4. Multiple response URIs: The mapping protocol MUST support the >> possible inclusion of multiple URIs in a mapping response. >> Motivation: Multiple URIs may be available from the mapping >> server. >> >> Ma5. URI alternate contact: In addition to returning a primary >> contact, the mapping protocol MUST support the return >of a URI or >> contact method explicitly marked as an alternate contact. >> Motivation: In response to a mapping request, the mapping server >> may return an alternate URI. Implementation details to be >> described within an operational document. >> >> Ma6. URL properties: The mapping protocol MUST support the ability >> to provide ancillary information about a contact or URI that >> allows the mapping client to determine relevant >properties of the >> URL. >> Motivation: In some cases, the same geographic area is served by >> several PSAPs, for example, a corporate campus might be >served by >> both a corporate security department and the municipal >PSAP. The >> mapping protocol should then return URLs for both, with >> information allowing the querying entity to choose one or the >> other. This determination could be made by either an >ESRP, based >> on local policy, or by direct user choice, in the case >of caller- >> based methods. >> >> Ma17. Single URI per contact protocol: Though the mapping protocol >> supports the return of multiple URIs, it SHOULD return only one >> URI per contact protocol, 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. >> >>_______________________________________________ >>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 May 09 10:04:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdSoK-0000gi-Q6; Tue, 09 May 2006 10:03:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdSoK-0000gd-DU for ecrit@ietf.org; Tue, 09 May 2006 10:03:36 -0400 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 1FdSoJ-0002II-Mv for ecrit@ietf.org; Tue, 09 May 2006 10:03:36 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 09 May 2006 07:03:36 -0700 X-IronPort-AV: i="4.05,106,1146466800"; d="scan'208"; a="426888028:sNHT35378616" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k49E3IZG000865; Tue, 9 May 2006 07:03:32 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 May 2006 10:03:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Date: Tue, 9 May 2006 10:03:30 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301703E8C@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Thread-Index: AcZxQeQkKb/tlBeVTmyfiSeTdkFTzgABP92iAGvauRAAEBZAvQAORAWQ From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "Roger Marshall" , "Ted Hardie" , "Hannes Tschofenig" , , "Henning Schulzrinne" X-OriginalArrivalTime: 09 May 2006 14:03:32.0072 (UTC) FILETIME=[5AEE8E80:01C67371] X-Spam-Score: 0.0 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org >From the peanut gallery: Ma17 and Ma5 still seem to be in conflict. If my contact protocol is SIP, how many SIP contacts will be provided overall? Ma17 says 1. Ma5 says there can be primary and alternate, that is 2. So, is it 1 or 2, or perhaps more if there are multiple overlapping police forces? Another thing. SIP has a Contact header. Is contact and Contact the same thing? It seems like this is saying: Multiple URIs may be returned because there are multiple agencies to target. Each agency may use multiple protocols. For each protocol an agency might use, there may be a primary and an alternate URI. Each URI may contain ancillary properties to provide information on its usage. It not, I can't tell from the words what is intended. Mike > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Tuesday, May 09, 2006 3:12 AM > To: Roger Marshall; Ted Hardie; Hannes Tschofenig;=20 > ecrit@ietf.org; Henning Schulzrinne > Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt >=20 > Roger, > =20 > this is much better now. > =20 > IMHO the issue could still be slightly improved: > =20 > In Ma5 we are talking about an alternate contact and a primary contact > =20 > It should be clearly stated in Ma17 that we talk here about=20 > the primary contact: > =20 > Sugestion: Change Ma17 from: > =20 > Ma17. Single URI per contact protocol: Though there is=20 > support for multiple URIs being returned, the mapping=20 > protocol SHOULD return only one URI per contact protocol=20 > used, so that clients are not required to select among=20 > different targets for the same contact protocol > =20 > to: > =20 > Ma17. Single primary URI per contact protocol: Though there=20 > is support for multiple URIs being returned, the mapping=20 > protocol SHOULD return only one explicitely marked primary=20 > URI per contact protocol used, so that clients are not=20 > required to select among different targets for the same=20 > contact protocol > =20 > regards > Richard >=20 > ________________________________ >=20 > Von: Roger Marshall [mailto:RMarshall@telecomsys.com] > Gesendet: Di 09.05.2006 01:29 > An: Stastny Richard; Ted Hardie; Hannes Tschofenig;=20 > ecrit@ietf.org; Henning Schulzrinne > Betreff: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt >=20 >=20 >=20 > Ok, based on the points Richard made, and Ted's suggestions,=20 > and other than some slight ordering changes (Ma4 still first,=20 > then Ma17, since the latter has a referenced qualification=20 > pointing to the former), and some minor rewording for=20 > read-ability, here's the resulting clump of requirements=20 > which we were talking about: >=20 > ... >=20 > Ma4. Multiple response URIs: The mapping protocol MUST allow=20 > multiple URIs to be inclued in a mapping response. >=20 > Motivation: Multiple URIs may be available from the mapping server. >=20 > Ma17. Single URI per contact protocol: Though there is=20 > support for multiple URIs being returned, the mapping=20 > protocol SHOULD return only one URI per contact protocol=20 > used, so that clients are not required to select among=20 > different targets for the same contact protocol. >=20 > Motivation: There may be two or more URIs returned when=20 > multiple contact protocols are available (e.g., SIP and SMS).=20 > The client may select among multiple contact protocols based=20 > on its capabilities, preference settings, or availability. >=20 > Ma5. URI alternate contact: In addition to returning a=20 > primary contact, the mapping protocol MUST support the return=20 > of a URI or contact method explicitly marked as an alternate=20 > contact for use when >=20 > a fallback contact is needed. >=20 > Motivation: In response to a mapping request, the mapping=20 > server may return an alternate URI. Implementation details=20 > to be described within an operational document. >=20 > Ma6. URL properties:"> The mapping protocol MUST support the=20 > ability to provide ancillary information about a contact or=20 > URI that allows the mapping client to determine relevant=20 > properties of the URL. >=20 > Motivation: In some cases, the same geographic area is served=20 > by several PSAPs, for example, a corporate campus might be=20 > served by both a corporate security department and the=20 > municipal PSAP. The mapping protocol should then return URLs=20 > for both, with information allowing the querying entity to=20 > choose one or the other. This determination could be made by=20 > either an ESRP, based on local policy, or by direct user=20 > choice, in the case of caller-based methods. >=20 > ... >=20 > Out-of-order numbering left for reference. These will be=20 > renumbered in next draft vers. >=20 > -roger. >=20 >=20 > >-----Original Message----- > >From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > >Sent: Saturday, May 06, 2006 12:55 PM > >To: Ted Hardie; Hannes Tschofenig; ecrit@ietf.org; Henning=20 > Schulzrinne;=20 > >Roger Marshall > >Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt > > > >>To make that clear, I suggest > >>we move Ma17 up to be before Ma4, and we change "URI > >alternate contact" > >>to say "explicitly marked as an alternate contact for use when a=20 > >>fallback contact is needed". > > > >Yes, thank you for the clarification, this would clarify the issue > > > >Richard > > > > > >________________________________ > > > >Von: Ted Hardie [mailto:hardie@qualcomm.com] > >Gesendet: Sa 06.05.2006 21:14 > >An: Stastny Richard; Hannes Tschofenig; ecrit@ietf.org; Henning=20 > >Schulzrinne; Roger Marshall > >Betreff: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt > > > > > > > >At 7:09 PM +0200 5/6/06, Stastny Richard wrote: > >>IMHO there is a contradiction, (espeially between Ma6 and > >Ma17) or at > >>least this is very confusing. I do not know now if multiple=20 > URIs for=20 > >>the same contact protocol are allowed or not) > >> > >>In one requirement the client needs to the select among differnt=20 > >>protocols, in the other not > >> > >>Richard > > > >I agree that this is a bit confusing, largely because Ma17=20 > occurs after=20 > >the others. I think if we moved it forward, it would make=20 > more sense,=20 > >as it would then imply that the multiple URIs in Ma4 were=20 > each from a=20 > >different scheme. > > > >The reason we did not want to return multiple contact URIs=20 > for a single=20 > >scheme in a standard response was that we didn't want the client to=20 > >have to worry about which of the returned URIs to pick=20 > (e.g., if I gave=20 > >you six SIP URIs, which one should be selected?). > > > >The alternate contact field allowed you to handle the need=20 > for explicit=20 > >indication of a fallback, but with the understanding that the client=20 > >didn't need to determine an ordering in the response--the=20 > fallback was=20 > >there only when the first contact was not available. > > > >That's my memory of how we got there. To make that clear, I suggest > >we move Ma17 up to be before Ma4, and we change "URI=20 > alternate contact"=20 > >to say "explicitly marked as an alternate contact for use when a=20 > >fallback contact is needed". > > regards, > > Ted > > > > > >> > >>Ma4. Multiple response URIs: The mapping protocol MUST support the > >> possible inclusion of multiple URIs in a mapping response. > >> Motivation: Multiple URIs may be available from the mapping > >> server. > >> > >> Ma5. URI alternate contact: In addition to returning a primary > >> contact, the mapping protocol MUST support the return > >of a URI or > >> contact method explicitly marked as an alternate contact. > >> Motivation: In response to a mapping request, the=20 > mapping server > >> may return an alternate URI. Implementation details to be > >> described within an operational document. > >> > >> Ma6. URL properties: The mapping protocol MUST support=20 > the ability > >> to provide ancillary information about a contact or URI that > >> allows the mapping client to determine relevant > >properties of the > >> URL. > >> Motivation: In some cases, the same geographic area=20 > is served by > >> several PSAPs, for example, a corporate campus might be > >served by > >> both a corporate security department and the municipal > >PSAP. The > >> mapping protocol should then return URLs for both, with > >> information allowing the querying entity to choose one or the > >> other. This determination could be made by either an > >ESRP, based > >> on local policy, or by direct user choice, in the case > >of caller- > >> based methods. > >> > >> Ma17. Single URI per contact protocol: Though the=20 > mapping protocol > >> supports the return of multiple URIs, it SHOULD=20 > return only one > >> URI per contact protocol, 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=20 > when multiple > >> contact protocols are available (e.g., SIP and SMS). =20 > The client > >> may select among multiple contact protocols based on its > >> capabilities, preference settings, or availability. > >> > >>_______________________________________________ > >>Ecrit mailing list > >>Ecrit@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 09 10:15:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdT07-0005zP-Ti; Tue, 09 May 2006 10:15:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdT06-0005zK-QS for ecrit@ietf.org; Tue, 09 May 2006 10:15:46 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdT04-0002fT-Ej for ecrit@ietf.org; Tue, 09 May 2006 10:15:46 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k49EFZC26239; Tue, 9 May 2006 10:15:35 -0400 (EDT) Received: from [127.0.0.1] ([47.130.18.239] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 May 2006 10:15:32 -0400 Message-ID: <4460A401.8090803@nortel.com> Date: Tue, 09 May 2006 10:15:29 -0400 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Marc Linsner , Hannes Tschofenig Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt References: <8C837214C95C864C9F34F3635C2A657504E2E872@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A657504E2E872@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 May 2006 14:15:32.0926 (UTC) FILETIME=[089825E0:01C67373] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Just for the record: I'll have to update the Security I-D to use this new terminology. Roger Marshall wrote: > Ted: > I'm glad you clarified, since I admit struggling some over that last > text! > > Anyway, I think it reads better with even less text: > > PSAP URI: The URI (e.g., SIP:URI, SIPS:URI, XMPP:URI, > etc.) at which the PSAP may be contacted with an emergency call. This > contact could be done directly, or via an intermediary, (e.g., ESRP). > > -roger. > >> -----Original Message----- >> From: Ted Hardie [mailto:hardie@qualcomm.com] >> Sent: Saturday, May 06, 2006 5:49 AM >> To: Roger Marshall; Hannes Tschofenig >> Cc: ecrit@ietf.org >> Subject: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt >> >> At 4:34 PM -0700 5/5/06, Roger Marshall wrote: >>> The >>> URI contains information about the protocol used (encoded in the >>> scheme), so that a focus on the IP address that it may resolve to is >>> not appropriate. >>> There are even cases where the SIP:URI and the XMPP:URI for the same >>> PSAP might not point to the same box. >> I hadn't actually intended for the lines above to be included; >> I meant them as further information about the URI for the >> group. If people think that it is valuable to include it, >> though, I would elide "so that a focus on the IP address that >> it may resolve to is not appropriate.". >> regards, >> Ted Hardie >> > > _______________________________________________ > 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 May 09 11:30:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdUAc-0004O3-AI; Tue, 09 May 2006 11:30:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdUAb-0004Ny-U2 for ecrit@ietf.org; Tue, 09 May 2006 11:30:41 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdUAZ-0006L7-IH for ecrit@ietf.org; Tue, 09 May 2006 11:30:41 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k49FUMoD015834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 9 May 2006 08:30:22 -0700 Received: from [10.0.1.5] (vpn-10-50-0-28.qualcomm.com [10.50.0.28]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k49FUIGY025362; Tue, 9 May 2006 08:30:21 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301703E8C@xmb-rtp-20b.amer.cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E301703E8C@xmb-rtp-20b.amer.cisco.com> Date: Tue, 9 May 2006 08:30:16 -0700 To: "Michael Hammer \(mhammer\)" , "Stastny Richard" , "Roger Marshall" , "Hannes Tschofenig" , , "Henning Schulzrinne" From: Ted Hardie Subject: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 10:03 AM -0400 5/9/06, Michael Hammer \(mhammer\) wrote: > >From the peanut gallery: > >Ma17 and Ma5 still seem to be in conflict. If my contact protocol is >SIP, how many SIP contacts will be provided overall? Ma17 says 1. Ma5 >says there can be primary and alternate, that is 2. So, is it 1 or 2, >or perhaps more if there are multiple overlapping police forces? I think you're making this harder than you need to. If I send a query requesting the contact URIs for a specific service based on my location, I get back one URI per scheme. I may also get back a URI explicitly marked as a fallback, for use only if I cannot use the usual contact URIs received (or if I try them and they fail). So you might get one geographically appropriate SIP URI, one geographically appropriate SMS URI, and one geographically appropriate XMPP URI. The fallback SIP URI (if present) is not necessarily as geographically appropriate; it might point to something like a state-wide response center. Frankly, I think we've wordsmithed this enough. Much more effort will not produce better instructions to the protocol designers. regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 09 11:54:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdUX3-0007Rc-Hb; Tue, 09 May 2006 11:53:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdUX1-0007RS-K0 for ecrit@ietf.org; Tue, 09 May 2006 11:53:51 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdUWz-0007hZ-A0 for ecrit@ietf.org; Tue, 09 May 2006 11:53:51 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FdUWo-0000f0-Uo; Tue, 09 May 2006 10:53:39 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Michael Hammer \(mhammer\)'" , "'Stastny Richard'" , "'Roger Marshall'" , "'Hannes Tschofenig'" , , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Date: Tue, 9 May 2006 11:53:40 -0400 Message-ID: <041d01c67380$c0532380$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: AcZzfY4sWwss/BbdRaqyo5G6EBHRFAAAx2Dg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Huh, I would have thought that you could get a fallback URI per scheme -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com] Sent: Tuesday, May 09, 2006 11:30 AM To: Michael Hammer (mhammer); Stastny Richard; Roger Marshall; Hannes Tschofenig; ecrit@ietf.org; Henning Schulzrinne Subject: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt At 10:03 AM -0400 5/9/06, Michael Hammer \(mhammer\) wrote: > >From the peanut gallery: > >Ma17 and Ma5 still seem to be in conflict. If my contact protocol is >SIP, how many SIP contacts will be provided overall? Ma17 says 1. Ma5 >says there can be primary and alternate, that is 2. So, is it 1 or 2, >or perhaps more if there are multiple overlapping police forces? I think you're making this harder than you need to. If I send a query requesting the contact URIs for a specific service based on my location, I get back one URI per scheme. I may also get back a URI explicitly marked as a fallback, for use only if I cannot use the usual contact URIs received (or if I try them and they fail). So you might get one geographically appropriate SIP URI, one geographically appropriate SMS URI, and one geographically appropriate XMPP URI. The fallback SIP URI (if present) is not necessarily as geographically appropriate; it might point to something like a state-wide response center. Frankly, I think we've wordsmithed this enough. Much more effort will not produce better instructions to the protocol designers. regards, Ted Hardie _______________________________________________ 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 May 09 12:02:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdUfD-0002dm-Qr; Tue, 09 May 2006 12:02:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdUfD-0002dh-7I for ecrit@ietf.org; Tue, 09 May 2006 12:02:19 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdUfA-0008E8-Vj for ecrit@ietf.org; Tue, 09 May 2006 12:02:19 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 09 May 2006 12:02:17 -0400 X-IronPort-AV: i="4.05,106,1146456000"; d="scan'208"; a="88194474:sNHT32667642" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k49G2DTL023496; Tue, 9 May 2006 12:02:14 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 May 2006 12:02:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Date: Tue, 9 May 2006 12:02:12 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301703F34@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Thread-Index: AcZzfYzLIYqYRCsTQZ2rlCKgcJCKDwABDvwQ From: "Michael Hammer \(mhammer\)" To: "Ted Hardie" , "Stastny Richard" , "Roger Marshall" , "Hannes Tschofenig" , , "Henning Schulzrinne" X-OriginalArrivalTime: 09 May 2006 16:02:13.0621 (UTC) FILETIME=[EFB4B250:01C67381] 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: , Errors-To: ecrit-bounces@ietf.org Ted, I am just telling you that I read the words and they appeared self-contradictory to me. Mike =20 > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com]=20 > Sent: Tuesday, May 09, 2006 11:30 AM > To: Michael Hammer (mhammer); Stastny Richard; Roger=20 > Marshall; Hannes Tschofenig; ecrit@ietf.org; Henning Schulzrinne > Subject: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt >=20 > At 10:03 AM -0400 5/9/06, Michael Hammer \(mhammer\) wrote: > > >From the peanut gallery: > > > >Ma17 and Ma5 still seem to be in conflict. If my contact=20 > protocol is=20 > >SIP, how many SIP contacts will be provided overall? Ma17=20 > says 1. Ma5=20 > >says there can be primary and alternate, that is 2. So, is=20 > it 1 or 2,=20 > >or perhaps more if there are multiple overlapping police forces? >=20 > I think you're making this harder than you need to. If I=20 > send a query requesting the contact URIs for a specific=20 > service based on my location, I get back one URI per scheme. =20 > I may also get back a URI explicitly marked as a fallback,=20 > for use only if I cannot use the usual contact URIs received=20 > (or if I try them and they fail). > So you might get one geographically appropriate SIP URI, one=20 > geographically appropriate SMS URI, and one geographically=20 > appropriate XMPP URI. > The fallback SIP URI (if present) is not necessarily as=20 > geographically appropriate; it might point to something like=20 > a state-wide response center. >=20 > Frankly, I think we've wordsmithed this enough. Much more=20 > effort will not produce better instructions to the protocol designers. > regards, > Ted Hardie >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 12 11:15:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeZM8-0008J1-06; Fri, 12 May 2006 11:15:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeZM6-0008Iu-VH for ecrit@ietf.org; Fri, 12 May 2006 11:15:02 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FeZM3-0000su-3C for ecrit@ietf.org; Fri, 12 May 2006 11:15:02 -0400 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, 12 May 2006 17:18:57 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A2D@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Commments I.D-ecrit-service-urn-03 Child helpline Thread-Index: AcZr9YcDBJ49y+6dQaaRkAN9gRk4DAJ3l1Kv From: "Stastny Richard" To: "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: ecrit@ietf.org Subject: [Ecrit] Commments I.D-ecrit-service-urn-03 Child helpline X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning, all, =20 >I've updated some of the draft text in my working draft at > = = http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service- = urn-03.html I can remember that in on older version was also a sos.child (as I proposed because we have such a help-line under our emergency services in Austria) This has now vanished in the latest definitions in section 4.3 sos service types I bring this to your attention because at the SG2 Meeting this week in Geneva a request for numbering resources was brought=20 forward to Q1 by Child Helpline International. For your information I copy the relevant text of the Q1 Report below. As you see from the text, a draft circular was created to request information by ITU TSB from member states on this issue and also on a emergency numbers in general. Since this is also for interest for ECRIT, I copy also the draft circular below. You should keep in mind that this is only a draft and will be modified by TSB before sent out officially. The results of this survey will also prove useful for the further work of ECRIT. best regards Richard Stastny --------------------------------------------------------- Citation from SG2 Q1 Report 3.5 Request for Numbering Resources TD GEN 194 (TSB on behalf of Child Helpline International) requested the = assignment of a toll free, easy to remember number for children. To = facilitate this, CHI signed an MoU with ITU at WSIS. In order to = achieve this goal by May 17th 2007, CHI encourages regulators to support = the allocation of a local toll free, easy to remember, 3-4 digit number = for each helpline in every country; a regional toll free, easy to = remember, 3-4 digit number for all help lines in that region; and one = global toll free, easy to remember, 3-4 digit number for all help lines = in the world. Q1/2 supports the need for children to have a short, easy to remember = number to call for help and agreed to begin a study on this topic. = During the discussion on the topic it was suggested it would be = beneficial to identify what is being done in individual countries and on = a regional basis regarding the use of child help line numbers. Based on = this discussion it was agreed to form an Ad-Hoc to develop a draft = Circular to collect the information. The initial draft Circular is = contained in TD PLEN 19. During the introduction of this draft Circular = additional comments were accepted to be incorporated and the revision = version is contained in TD PLEN 19 Rev2. The Q1 participants agreed that = a Circular should be sent but could reach no consensus regarding the = number of digits that constitute a short number. Therefore, this issue = will be discussed at the closing plenary of SG2. =20 Draft Circular TD PLEN 19r2 ------------------------------------------------------------------ Notes & material for circular/survey to Member States. Agreed timeframe Target May 17th 2007 (World Telecoms Day designated to youth and = children). =3D> Responses must be addressed during the January 2007 = meeting. Deadline for responses - to be determined, no later than September 2006, = prior to the Plenipotentiary conference in Antalya in November 2006.=20 Recipients are Member States (for action) and Sector Members (for = information). Goals: - Investigate the feasibility of a single (as a target) = three-digit toll free[1] short number for emergency services - possibly = a limited set of numbers. This survey is intended to investigate such = possibility at the regional, national regional, and international = levels. - Investigate the feasibility of a single (as a target) = mnemonic toll free[2] short number between 3 and 6 digits for a = children's helpline (which may or may not qualify as an emergency = service) - possibly a limited set of numbers. This survey is intended to = investigate such possibility at the regional, national, regional and = international levels. - To this purpose review the current deployment and possible = future availability of national, toll-free, resources ("short numbers") = on 3 to 6 digits for such purpose o specify the number or numbering space dedicated to such = services, if any.=20 Note: all the aspects related to the children's helpline number being = the main focus of the circular, these should appear first.=20 Questions for the survey: National toll-free number 1. Does your country have one or more emergency numbers (e.g. 911 = in the USA)?=20 a. If so, is it one or more numbers and what are these national = numbers? b. If more than one emergency numbers is provided, what are their = purposes? c. Is it or are they toll free numbers? d. Could you specify the consequence of its being an emergency = number (e.g. the emergency number must be provided by all operators = according to the national regulatory framework). e. What spare numbering resources would you have for such a = number, if it were felt desirable to agree on a single world-wide = number, or a short list of numbers that would be implemented in all = countries. 2. Does your country have a child helpline for children?=20 a. If so, what is this national number? b. Is it toll free number? c. Does it qualify as some form of emergency service? Could you = specify the consequence of this qualification (e.g. the emergency number = must be provided by all operators according to the national regulatory = framework, whereas it may not be the case for a child helpline). 3. Child Helpline International would like to promote the use of a = toll free, 3 - 6 digit national number or at least a limited set of = national numbers throughout the world (as short as possible, 6 digits = being the maximum length of the dialled string). a. If your country does not have a national, short, toll-free child = helpline number, will your country be willing to implement one? i. = What spare national numbering resources would you have for such a = service?=20 b. If your country has child helpline number, considering that the = current number in use would not have to be changed, are there spare = national numbering resources that could be used a second access number = for such a children's helpline service?=20 4. What would the process of implementation for such number be? For = example: a. Is there a specific category for such national numbers,=20 b. Would this service qualify as a "emergency service", which would = have to meet specific requirements? c. Please provide any additional information that you may consider = helpful.=20 5. Could your country commit to a national implementation process?=20 =20 Global / International number 1. Would your country be committed to supporting one international, = easy to remember, toll free child helpline number? For example, by = promoting the access to such a number through national service provider. = This number may for example, be a Universal International Freephone = Number (UIFN) - ie an international freephone E.164 number accessible = free of charge for the caller (generally dialled using the international = prefix followed by the number eg. 00800... or 011800...).=20 2. What would the process for this be? a. Is there a mandatory means that would permit the opening up of the = global UIFN? =20 Background:=20 - Reproduce WSIS text on this topic - Possibly refer to www.childhelplineinternational.org = for more information. - = For more information on Child Helpline International and its = helpline members, please refer to "Connecting to Children" at = http://www.childhelplineinternational.org/downloads/CTC_screen.pdf.=20 - attach to circular the MoU between ITU & Child Helpline = International and elements developed in TD 194 (GEN/2). And in = particular for item 1. of: In order to help and protect children, CHI requests endorsement for a = toll free, easy to remember, 3-6 digit number for children. To = facilitate this, CHI signed an MoU with ITU at WSIS. In order to = achieve this goal by May 17th 2007, CHI encourages regulators to support = the allocation of: 1. A national toll free, easy to remember, 3-6 digit number for each = helpline in every country. 2. Finally, one global toll free, easy to remember, number for all = helplines in the world. - Also note that the service may be provided nationally while = the number is agreed upon internationally: in particular the goal is not = to change the current national provisioning of such services but to = introduce more facility for accessing the child helpline service by a = common number (or limited set of numbers) to prevent children = trafficking.=20 =20 ________________________________ [1] A toll free number is a number that is free of charge.=20 [2] A toll free number is a number that is free of charge.=20 =20 =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 12 20:25:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FehwO-000788-IB; Fri, 12 May 2006 20:25:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FehwN-000783-Fw for ecrit@ietf.org; Fri, 12 May 2006 20:25:03 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FehwM-0004tK-GF for ecrit@ietf.org; Fri, 12 May 2006 20:25:03 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Fri, 12 May 2006 17:24:55 -0700 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, 12 May 2006 17:24:53 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657504EBFDAA@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-ecrit-requirements-08.txt Thread-Index: AcZwPoUj/BsvJ+NiSzyOaaeCs75XOwATVgeQ From: "Roger Marshall" To: "Hannes Tschofenig" , , "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: cb592aae7f4601895f35714165597859 Cc: Subject: [Ecrit] RE: Review of draft-ietf-ecrit-requirements-08.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes: Thanks very much for your comments to the -08 draft. A new version, w/the changes incorporated, will be published soon. See changes/responses in-line: -roger. >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 >Sent: Friday, May 05, 2006 5:22 AM >To: ecrit@ietf.org; Henning Schulzrinne; Roger Marshall >Subject: Review of draft-ietf-ecrit-requirements-08.txt > >Hi all, > >here is a review of draft-ietf-ecrit-requirements-08.txt. The=20 >document is getting much better. Still, I have a few comments: > >* Introduction: > > >I would delete this paragraph since it is a bit confusing at=20 >this point: > > As used in this document, validation of location does not require > that we ascertain as to whether or not the location=20 >actually exists. > For example, validation might only check that the house number in a > civic address falls within the assigned range, not whether a > building, known by a specific building number, exists at that > location. However, such higher precision validation is desirable. > >This might be relevant in subsequent sections. Agreed, deleted above paragraph. Concept is already referred to in the term defn, "Location validation". > > > > Identification of the caller, while not incompatible with the > requirements for messaging outlined within this document, is > considered to be outside the scope of the ECRIT charter. > ^^^^^^^^^^^^^^^^^^ > >Don't mention the working group name in the document. The reference to ECRIT has been removed throughout document. > >Write "... is outside the scope of this document." Agreed. Done. > > > 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, for=20 >example, a TEL > URI which may be used to complete a call via the PSTN. > >I am not sure about this paragraph. Where do we provide such a=20 >functionality? Agree that there is no existing requirement to which this paragraph refers to, so I've reworded the paragraph, and have added a NEW requirement as written below: CHANGE FROM: Ideally, the mapping protocol would yield a URI from a preferred set of=20 URIs (e.g., SIP:URI, SIPS:URI) which would allow an emergency call to be completed using IP end-to-end. Despite this goal, some PSAPs may not=20 immediately have IP based connectivity, and therefore it is imperative that=20 the URI scheme not be fixed, in order to ensure support for a less=20 preferred set of URIs such as, for example, a TEL URI which may be=20 used to complete a call via the PSTN. CHANGE TO: The intent of the mapping protocol is to produce a PSAP URI (from a=20 preferred set of URIs, e.g., SIP:URI, SIPS:URI) based on a location input,=20 to facilitate the IP end-to-end completion of an emergency call. Since not=20 every PSAP will immediately support IP, it may be necessary to also=20 support less preferred URI schemes, such as a TEL URI in order to=20 complete an emergency call via the PSTN. ADDED: Ma18. Non-preferred URI schemes: The mapping=20 protocol MAY support the return of a less preferred URI scheme,=20 (e.g., TEL URI). Motivation: In order to provide incremental support to non-IP=20 PSAPs it may be necessary to be able to complete an emergency=20 call via the PSTN. > >* Terminology > >I would cluster the terms. For example, you might want to keep > - (Location-dependent) emergency dial string > - Home emergency dial string > - Visited emergency dial string >together to make the terminology easier to read. > >There is no requirement to list the terms alphabetically. Agreed. Terms have been reordered and clumped together. > > > Emergency address: The URI (e.g., SIP:URI, SIPS:URI, XMPP:URI, IM: > ^^^^^^^ change to identifier > URI, etc.) which represents the address of the PSAP=20 >useful for the > completion of an emergency call. > > Emergency call routing support: An intermediary function which > assists in the routing of an emergency call via IP. An=20 >ESRP is an > example of an Emergency call routing support entity. > ^^^^^^^^^ emergency > Conflated the two terms, "Emergency address" and "PSAP URI", into one entry under PSAP URI. > >Delete the following paragraph: > > Codes: "caller" or "emergency caller" refers to the person=20 >placing an > emergency call or sending an emergency instant message (IM). > >AND move the text over to this term: > > Emergency caller: The user or user device entity which=20 >sends his/her > location to another entity in the network. > >As such, it would read: > > (Emergency) caller: The term "caller" or "emergency=20 >caller" refer to the person placing an emergency call or=20 >sending an emergency instant message (IM). Agreed. Changes made to draft. > > > > In this document, the key words "MUST", "MUST NOT", "REQUIRED", > "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", > and "OPTIONAL" are to be interpreted as described in RFC 2119 [1], > with the qualification that unless otherwise stated these=20 >words apply > to the design of the mapping protocol, not its implementation or > application. > ^^^^^^^^^^^ usage Modification made. > > >With the suggested change from "Emergency address" to "Emergency=20 >identifer" we have the term 'emergency identifier' appearing twice: > > Emergency identifier: An identifier that marks a call as=20 >an emergency > call. > >I suggest to delete this definition or to merge it with the=20 >previous one. No changes made here, subject to list discussions/clarfications. We end up with two terms, having different usage, "emergency identifier", and "PSAP URI". > >In the text we should always use small letters for terms like 'mapping=20 >servers' or 'mapping clients'. For example, > > Mapping client: A mapping client interacts with the=20 >Mapping Server to > ^^^^^^^^^^^^^^ > learn one or more PSAP URIs for a given location. > > > Mapping server: The Mapping Server holds information about the > ^^^^^^^^^^^^^^ > location-to-PSAP URI mapping. Agreed. Low-case changes made. > > >Change from: > >" > PSAP URI: PSAP URI is a general term, used to refer to the=20 >output of > the mapping protocol, and represents either the actual PSAP IP > address, or the IP address of some other intermediary, e.g., an > ESRP, which points to the actual PSAP. >" > >to: > >" > PSAP URI: The term 'PSAP URI' refers to a URI that identifiers a=20 >PSAP. We use this term to denote the reponse of a mapping=20 >protocol query. Change NOT made, since we have renamed emergency address to PSAP URI, and so have the result: PSAP URI: The URI (e.g., SIP:URI, SIPS:URI, XMPP:URI,=20 etc.) at which the PSAP may be contacted with an emergency call. This=20 contact could be done directly, or via an intermediary, (e.g., ESRP). >" > >* Section 3. Basic Actors > > In order to support emergency services covering a large physical > area, various infrastructure elements are necessary, including: > Internet Attachment Providers (IAPs), Application/Voice Service > Providers (ASP/VSPs), PSAPs as endpoints for emergency=20 >calls, mapping > =20 >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ delete=20 >this part; the PSAP is only one endpoint of the communciation. > > services or other infrastructure elements that assist=20 >during the call > ^^^ and > routing. Changed text to read: In order to support emergency services covering a large physical=20 area, various infrastructure elements are necessary, including: Internet Attachment Providers (IAPs), Application/Voice Service Providers=20 (ASP/VSPs), Emergency Call Routing Support (ECRS) providers,=20 mapping service providers, and PSAPs. > > > o How is location information provided to the end host?=20 > It might > either be known to the end host itself via manual configuration, > provided via GPS, or obtained via a third party method. Even if > location information is known to the network it might be made > available to the end host via DHCP (RFC 3825 [2]) or some other > mechanism. Alternatively, location information is used as part of > call routing and inserted by intermediaries. > > >Change paragraph to: > > o How is location information provided to the end host? It might > either be known to the end host itself via manual configuration, > provided via GPS, made > available via DHCP (see RFC 3825 [2]) or some other > mechanisms. Alternatively, location information is used as part of > call routing and inserted by intermediaries. Changed text as suggested. > > > (5) Location Information is used by emergency call routing entities > ^^^^^^^^^^^ information > for subsequent mapping requests. Corrected text to low-case. > >4. High-Level Requirements > > Re1. Application/Voice service provider existence: The=20 >initiation of > an IP-based emergency call SHOULD NOT assume the existence of an > Application/Voice Service Provider (ASP/VSP). > > Motivation: The caller may not have an application/voice service > provider. For example, a residence may have its own DNS domain > and run its own SIP proxy server for that domain. On a larger > scale, a university might provide voice services to its students > and staff, but not be a telecommunication provider. > ^ add "might" Inserted word "might". > > >5. Identifying the Caller's Location > > Location can either be provided directly, or by reference, and > represents either a civic location, or as a geographic location. > ^^ and geospatial location=20 >information. Changed text as suggested. > > How > does the location (or location reference) become=20 >associated with the > call? > >change last sentence to: > >"An important question is how and when to attach location=20 >information to=20 >the VoIP emergency signaling." Changed text as suggested. > > In general, we can distinguish three modes of operation of how > a location is associated with an emergency call: > >Change from: > > UA-inserted: The caller's user agent inserts the location=20 >information > into the call signaling message. The location information is > derived from sources such as GPS, DHCP (RFC 3825 [2]) and > I-D.ietf-geopriv-dhcp-civil [7]) or utilizing the Link Layer > Discovery Protocol (LLDP) [see IEEE8021AB]. > > >to: > > > UA-inserted: The caller's user agent inserts the location=20 >information > into the call signaling message. The location information is > derived from sources such as GPS, DHCP (see [2] for geospatial=20 >location information and [7] for civic location information) or=20 >utilizing the Link Layer > Discovery Protocol (LLDP) (see [IEEE8021AB]). Changed text as suggested. > > > UA-referenced: The caller's user agent provides a pointer (i.e., a > location reference), via a permanent or temporary identifier, to > the location which is stored by a location service=20 >somewhere else > ^^^^^^^ server >delete the 'somewhere else' part. > and then retrieved by the PSAP, ESRP, or other=20 >authorized service > entity. Changed "service" to "server". > > Lo2. Location object/info preservation: The mapping protocol MUST > retain any location information which is provided to it, even > after mapping is performed. > > Motivation: The ESRP and the PSAP use the same location > information object, but for a different purpose. =20 >Therefore, it is > imperative that the mapping protocol not remove location > ^ does > Information so that the PSAP can still receive the caller > ^^^^^^^^^^^ information > location. Changed text to: Motivation: The ESRP and the PSAP use the same location=20 information object, but for a different purpose. Therefore, it is=20 imperative that the mapping protocol does not remove the =20 location information from the messaging, so that it can be provided=20 to the PSAP. > > > Lo5. Validation of civic location: The mapping protocol=20 >MUST support > location validation for civic location (street addresses), prior > to initiating an emergency call. > >delete the ", prior to initiating an emergency call." part. Removed text per suggestion. > > Motivation: Location validation provides an opportunity to help > assure ahead of time, whether or not successful mapping to the > ^ add 'a' > appropriate PSAP will likely occur when it is required. > Validation may also help to avoid delays during emergency call > setup due to invalid locations. Inserted "a" per suggestion. > > >Isn't Lo7 similar to L10? Agree that the two are similar in intent, therefore have removed Lo10. >Isn't Lo6 similar to Lo11? Not sure, but I do think that Lo11 is not general enough, so have removed Lo11. > > > Lo9. 3D sensitive mapping: The mapping protocol MUST implement > support for both 2D and 3D location information, and may accept > either a 2D or 3D mapping request as input. > > Motivation: It is expected that provisioning systems will accept > ^^^^^^^^^^^^^^^^^^^^=20 >what is that? > > 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 in the request. Reworded motivation paragraph to read as follows: Motivation: It is expected that end devices or location servers will=20 provide either 2D or 3D data. When a 3D request is presented within an=20 area only defined by 2D data within the mapping server, the mapping result=20 would be the same as if the height/altitude dimension was omitted in the request. > > >6. Emergency Identifier > > Id1. Emergency identifier support: The mapping protocol=20 >MUST support > one or more emergency identifiers for delivery back to mapping > clients to be used for call setup purposes. > >I guess this requirement should say: > >" > Emergency identifier support: The mapping protocol MUST be able to=20 >return one or multiple emergency identifiers in response to a query. Changed text to: Id1. Emergency identifier support: The mapping protocol=20 MUST be able to return one or multiple emergency identifiers in=20 response to a query. >" > > > > Id2. Emergency identifier resolution: Where multiple emergency > identifiers exist, the mapping protocol MUST be able to > differentiate between identifiers based on the specific type of > emergency help requested. > > Motivation: Some jurisdictions may have multiple types of > emergency services available, (e.g., fire, police,=20 >ambulance), in > which case, it is important that any one could be selected > directly. > >There is a terminology confusion here: >I think you refer to 'sos Service Types' here rather than multiple=20 >emergency identifers. You might want to double-check with=20 >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-ur >n-02.txt=20 >(and in particular with Section 4.3). > >This terminology issue impacts also requirement Id5. Pending. Not sure. Seeking clarification from Hannes on above items. > > Id4. Prevention of fraud: If a call is identified as an emergency > call, the mapping protocol MUST support that call being > successfully routed to a PSAP. > > Motivation: This prevents use of the emergency call=20 >indication to > gain access to call features or authentication override for non- > emergency purposes. > >This requirement is covered in the security document. Deleted Id4 as per suggestion. > > >Requirement Id6, Id7, Id8, Id9, Id10 start with "The mapping protocol=20 >MUST/SHOULD support " but I think that these requirements do not=20 >necessarily address the mapping protocol. I think a "There MUST be=20 >support for...." Changed requirements Id6, Id7, Id8, Id9, Id10, to now read "There MUST be support for...".=20 > > >7. Mapping Protocol > > There are two basic approaches to invoking a mapping service. We > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > invoke the mapping protocol. Changed wording. > > refer to these as caller-based and mediated. In each case, the > mapping client initiates a request to a mapping server via=20 >a mapping > protocol. A proposed mapping protocol is outlined in the document > I-D.hardie-ecrit-lost [6]. > > For caller-based resolution, the caller's user agent invokes a > ^ the > mapping service to determine the appropriate PSAP based on the > ^^^^^^^ protocol > location provided. The resolution may take place well before the > actual emergency call is placed, or at the time of the call. > > For mediated resolution, a call signaling server, such as a SIP > ^^^^^^^^^^^^^^^^^^^^^^^ > an emergency call routing support entity > > (outbound) proxy or redirect server invokes the mapping service. Changes made to draft. > > > Ma5. URI alternate contact: In addition to returning a primary > contact, the mapping protocol MUST support the return=20 >of a URI or > contact method explicitly marked as an alternate contact. > > Motivation: In response to a mapping request, the mapping server > may return an alternate URI. Implementation details to be > described within an operational document. > > >I am not quite sure about Ma6 and Ma8. Ma8 tells me that the mapping=20 >protocol provides a URL for error reporting. Isn't Ma6 similar? > > > Ma6. URL properties: The mapping protocol MUST support the ability > ^^^ URI > > to provide ancillary information about a contact or URI that > ^^^^^^ delete > allows the mapping client to determine relevant=20 >properties of the > URL. > ^^^^ URI? Modified text as per suggestion. > > > Motivation: In some cases, the same geographic area is served by > several PSAPs, for example, a corporate campus might be=20 >served by > both a corporate security department and the municipal=20 >PSAP. The > mapping protocol should then return URLs for both, with > ^^^^ URIs > information allowing the querying entity to choose one or the > other. This determination could be made by either an=20 >ESRP, based > on local policy, or by direct user choice, in the case=20 >of caller- > based methods. > > Ma7. Traceable resolution: The mapping protocol SHOULD support the > ability of the mapping client to be able to determine the entity > or entities which provided the emergency address resolution > ^^^^^ that > information. > > Motivation: It is important for public safety reasons,=20 >that there > is a method to provide operational traceability in case=20 >of errors. > > Ma8. URI for error reporting: The mapping protocol MUST=20 >support the > ^^^^ URL > > return of a URI that can be used to report a suspected or known > ^^^^^^^^^^^^^^^ the ability to return a URL > > error within the mapping database. > > Motivation: If an error is returned, for example, there needs to > be a URI which points to a resource which can explain or > ^^^^ URL > > potentially help resolve the error. Changed per suggestion. > > > Ma16. Multiple PSAP URIs: The mapping protocol MUST=20 >support a method > to receive multiple PSAP URIs which cover the same geographic > ^^^^^^^ return > area. > > Motivation: Two different mapping servers may cover the same > geographic area, and therefore have the same set of coverage > information. > >Isn't this requirement very similar to Ma4? Agreed that Ma4 & Ma16 are same. Deleted Ma4. > > > > >* 8. Security Considerations > > Security considerations are discussed in the ECRIT=20 >security document > I-D.ietf-ecrit-security-threats [4] . > >Write: > >" >Threats and security requirements are discussed in a separate=20 >document,=20 >see [4]. Changed text as per suggestion. >" > >* Add an IANA section. >" >9. IANA Considerations > > This document does not require actions by the IANA. >" Added new section as per suggestion. > > >Ciao >Hannes > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 13 12:21:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fewrq-0004Gd-Ss; Sat, 13 May 2006 12:21:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fewrp-0004GS-IH for ecrit@ietf.org; Sat, 13 May 2006 12:21:21 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fewro-0004wJ-AZ for ecrit@ietf.org; Sat, 13 May 2006 12:21:21 -0400 Received: from [192.168.0.41] (pool-138-89-20-236.mad.east.verizon.net [138.89.20.236]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k4DGL4Bb016661 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 13 May 2006 12:21:05 -0400 (EDT) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4A2D@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C4A2D@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9C83E4EE-88BB-475C-9FAA-AAEA9D41CB87@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Sat, 13 May 2006 12:21:04 -0400 To: Stastny Richard X-Mailer: Apple Mail (2.749.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ecrit@ietf.org Subject: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > I can remember that in on older version was also a sos.child > (as I proposed because we have such a help-line under our > emergency services in Austria) > I checked; while this might have been discussed at some point, it wasn't in the earlier versions or in sipping-sos. > This has now vanished in the latest definitions in section 4.3 > sos service types I'm happy to include it, but given the recent discussion about limiting sos.* to emergency, immediate-help situations, I want to make sure that there is consensus that this is appropriate. For example, in the US, this seems to be a counseling service for run- aways (http://1800runaway.org/), which could be considered an emergency, but also seems to be a general counseling service. I'm starting to wonder if it wouldn't make more sense to group all of these counseling services (mental health, run-away, drug and alcohol abuse, suicide prevention, etc.) into a new top category, such as "advice". One practical reason is that these services have somewhat different privacy and location needs compared to traditional fire/police/ ambulance emergency services. For example, I don't think it would make sense to mandate location and identity disclosure for these counseling services. Indeed, many of these services offer anonymity to encourage calls, even though 800 numbers in the US obviously allow the agency to see the calling number, even with CLID restrictions. The UA requirements draft will presumably mandate inclusion of location information in all sos.* calls; this does not seem appropriate for these crisis counseling services. Henning > > I bring this to your attention because at the SG2 Meeting this > week in Geneva a request for numbering resources was brought > forward to Q1 by Child Helpline International. For your information > I copy the relevant text of the Q1 Report below. > > As you see from the text, a draft circular was created > to request information by ITU TSB from member states on > this issue and also on a emergency numbers in general. > > Since this is also for interest for ECRIT, I copy also > the draft circular below. You should keep in mind that > this is only a draft and will be modified by TSB before > sent out officially. > > The results of this survey will also prove useful for > the further work of ECRIT. > > best regards > > Richard Stastny > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 13 16:58:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff1Bn-0004jV-TQ; Sat, 13 May 2006 16:58:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff1Bn-0004jQ-6n for ecrit@ietf.org; Sat, 13 May 2006 16:58:15 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ff1Bl-0002Qw-MI for ecrit@ietf.org; Sat, 13 May 2006 16:58:15 -0400 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: Sat, 13 May 2006 23:02:11 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A36@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Commments I.D-ecrit-service-urn-03 Child helpline Thread-Index: AcZ2qdkjrZiNzhk/Q5SRteePUzAYKwAJAlhD From: "Stastny Richard" To: "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ecrit@ietf.org Subject: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning, > I can remember that in on older version was also a sos.child > (as I proposed because we have such a help-line under our > emergency services in Austria) > I checked; while this might have been discussed at some point, it=20 wasn't in the earlier versions or in sipping-sos. > This has now vanished in the latest definitions in section 4.3 > sos service types I'm happy to include it, but given the recent discussion about=20 limiting sos.* to emergency, immediate-help situations, I want to=20 make sure that there is consensus that this is appropriate. [Richard] Thanks for checking, I could just remeber that I once posted all of our 9 (NINE) emergency services ;-) For example, in the US, this seems to be a counseling service for run- aways (http://1800runaway.org/), which could be considered an=20 emergency, but also seems to be a general counseling service. I'm starting to wonder if it wouldn't make more sense to group all of=20 these counseling services (mental health, run-away, drug and alcohol=20 abuse, suicide prevention, etc.) into a new top category, such as=20 "advice". [Richard] As you see from the request from Child Helpline International and also from the draft circular questionary, it is also unclear to them = and to SG2 if this should be an emergency service or a counseling service using toll = free numbers. =20 [Richard] Our problem is that we cannot decide in IETF what of these services is an emergency service, because this is a national matter. Also what is an conselling service and what other services might be there: e.g services for public interest, but not = toll free, e.g. car break down services. Directory services with additional charges services where location information MUST be provided, services where location information is only by user push, and services where location information and identity must be withheld, etc. etc =20 [Richard] IMHO we should try to define these types of services, but leave it to the national implementations to define in what box they put specific services. =20 regards Richard One practical reason is that these services have somewhat different=20 privacy and location needs compared to traditional fire/police/ ambulance emergency services. For example, I don't think it would=20 make sense to mandate location and identity disclosure for these=20 counseling services. Indeed, many of these services offer anonymity=20 to encourage calls, even though 800 numbers in the US obviously allow=20 the agency to see the calling number, even with CLID restrictions. The UA requirements draft will presumably mandate inclusion of=20 location information in all sos.* calls; this does not seem=20 appropriate for these crisis counseling services. Henning > > I bring this to your attention because at the SG2 Meeting this > week in Geneva a request for numbering resources was brought > forward to Q1 by Child Helpline International. For your information > I copy the relevant text of the Q1 Report below. > > As you see from the text, a draft circular was created > to request information by ITU TSB from member states on > this issue and also on a emergency numbers in general. > > Since this is also for interest for ECRIT, I copy also > the draft circular below. You should keep in mind that > this is only a draft and will be modified by TSB before > sent out officially. > > The results of this survey will also prove useful for > the further work of ECRIT. > > best regards > > Richard Stastny > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 13 17:32:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff1ib-0008Jk-MB; Sat, 13 May 2006 17:32:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff1ia-0008Jf-D0 for ecrit@ietf.org; Sat, 13 May 2006 17:32:08 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ff1iZ-0003vi-3X for ecrit@ietf.org; Sat, 13 May 2006 17:32:08 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k4DLVRQu009576; Sat, 13 May 2006 16:31:27 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 13 May 2006 22:31:27 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB012F29643@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Henning Schulzrinne , Stastny Richard Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Date: Sat, 13 May 2006 22:31:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org In the UK the equivalent is run by a charity, which has in the past made play that it is independent of any authority in promoting itself to its clients. So from a UK perspective, I would have no difficulty in seeing it grouped with other counselling services. If classed as an emergency service, I suspect that in the absence of a local provider, the routeing to a default PSAP that may well be the police would cause distress to some callers. regards Keith > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 13 May 2006 17:21 > To: Stastny Richard > Cc: ecrit@ietf.org > Subject: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline > > > > I can remember that in on older version was also a sos.child > > (as I proposed because we have such a help-line under our > > emergency services in Austria) > > > > I checked; while this might have been discussed at some point, it > wasn't in the earlier versions or in sipping-sos. > > > > This has now vanished in the latest definitions in section 4.3 > > sos service types > > I'm happy to include it, but given the recent discussion about > limiting sos.* to emergency, immediate-help situations, I want to > make sure that there is consensus that this is appropriate. > > For example, in the US, this seems to be a counseling service > for run- > aways (http://1800runaway.org/), which could be considered an > emergency, but also seems to be a general counseling service. > > I'm starting to wonder if it wouldn't make more sense to > group all of > these counseling services (mental health, run-away, drug and alcohol > abuse, suicide prevention, etc.) into a new top category, such as > "advice". > > One practical reason is that these services have somewhat different > privacy and location needs compared to traditional fire/police/ > ambulance emergency services. For example, I don't think it would > make sense to mandate location and identity disclosure for these > counseling services. Indeed, many of these services offer anonymity > to encourage calls, even though 800 numbers in the US > obviously allow > the agency to see the calling number, even with CLID restrictions. > > The UA requirements draft will presumably mandate inclusion of > location information in all sos.* calls; this does not seem > appropriate for these crisis counseling services. > > Henning > > > > > > I bring this to your attention because at the SG2 Meeting this > > week in Geneva a request for numbering resources was brought > > forward to Q1 by Child Helpline International. For your information > > I copy the relevant text of the Q1 Report below. > > > > As you see from the text, a draft circular was created > > to request information by ITU TSB from member states on > > this issue and also on a emergency numbers in general. > > > > Since this is also for interest for ECRIT, I copy also > > the draft circular below. You should keep in mind that > > this is only a draft and will be modified by TSB before > > sent out officially. > > > > The results of this survey will also prove useful for > > the further work of ECRIT. > > > > best regards > > > > Richard Stastny > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 13 17:33:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff1js-0008UT-00; Sat, 13 May 2006 17:33:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff1jq-0008TJ-Q2 for ecrit@ietf.org; Sat, 13 May 2006 17:33:26 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ff1jp-000412-In for ecrit@ietf.org; Sat, 13 May 2006 17:33:26 -0400 Received: from [192.168.0.41] (pool-138-89-20-236.mad.east.verizon.net [138.89.20.236]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k4DLXJqa007325 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 13 May 2006 17:33:20 -0400 (EDT) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4A36@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C4A36@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <17B88095-EF68-4282-AE10-CAFB74DCBAED@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Sat, 13 May 2006 17:33:17 -0400 To: "Stastny Richard" X-Mailer: Apple Mail (2.749.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ecrit@ietf.org Subject: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > Note to ECRIT participants: This issue raises a larger point, so even if you don't care about child helplines, take a look at the proposal at the bottom. > [Richard] As you see from the request from Child Helpline > International > and also from the draft circular questionary, it is also unclear to > them and to SG2 if > this should be an emergency service or a counseling service using > toll free numbers. > There seem to be at least three dimensions for such services, all of which are somewhat beyond the scope: - whether to allow non-registered and expired subscribers to use these services (true for 800# on payphones, but not from private residences, for example) - whether to mandate inclusion of location information - whether to use a regular number (800#, say) or a short three/four digit number, i.e., the dial string > [Richard] Our problem is that we cannot decide in IETF what of these > services is an emergency service, because this is a national matter. > Also what is an conselling service and what > other services might be there: e.g services for public interest, > but not toll free, > e.g. car break down services. Directory services with additional > charges > services where location information MUST be provided, services where > location information is only by user push, and services where location > information and identity must be withheld, etc. etc > > [Richard] IMHO we should try to define these types of services, > but leave it to the national implementations to define in what box > they put specific services. While we don't have to decide on dial strings and issues of network access (this can be done on a local basis or can be contained in LoST records), the inclusion of location information needs to be universal, not national UNLESS we also include this information in the LoST record, along with the dial string. My inclination would be to focus on the universally-agreed upon immediate-response-with-location-needed services in sos for now, but also define an attribute in the LoST schema that indicates location inclusion. > > regards Richard > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 13 17:36:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff1me-0001UD-QZ; Sat, 13 May 2006 17:36:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff1md-0001U8-Io for ecrit@ietf.org; Sat, 13 May 2006 17:36:19 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ff1md-00047l-9D for ecrit@ietf.org; Sat, 13 May 2006 17:36:19 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k4DLa7hf012902; Sat, 13 May 2006 16:36:07 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 13 May 2006 22:36:07 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB012F29644@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Henning Schulzrinne , Stastny Richard Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Date: Sat, 13 May 2006 22:36:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org By the way, in Henning's original mail, I note that he implied that emergency calls never have privacy. I understand Japan does require any privacy expressed by the caller in making the call to be honoured when delivered to the PSAP. Therefore calling identity privacy cannot be regarded as a distinguishing factor between these groupings of service. regards Keith > -----Original Message----- > From: Drage, Keith (Keith) > Sent: 13 May 2006 22:31 > To: 'Henning Schulzrinne'; Stastny Richard > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child > helpline > > > In the UK the equivalent is run by a charity, which has in > the past made play that it is independent of any authority in > promoting itself to its clients. > > So from a UK perspective, I would have no difficulty in > seeing it grouped with other counselling services. > > If classed as an emergency service, I suspect that in the > absence of a local provider, the routeing to a default PSAP > that may well be the police would cause distress to some callers. > > regards > > Keith > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: 13 May 2006 17:21 > > To: Stastny Richard > > Cc: ecrit@ietf.org > > Subject: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 > Child helpline > > > > > > > I can remember that in on older version was also a sos.child > > > (as I proposed because we have such a help-line under our > > > emergency services in Austria) > > > > > > > I checked; while this might have been discussed at some point, it > > wasn't in the earlier versions or in sipping-sos. > > > > > > > This has now vanished in the latest definitions in section 4.3 > > > sos service types > > > > I'm happy to include it, but given the recent discussion about > > limiting sos.* to emergency, immediate-help situations, I want to > > make sure that there is consensus that this is appropriate. > > > > For example, in the US, this seems to be a counseling service > > for run- > > aways (http://1800runaway.org/), which could be considered an > > emergency, but also seems to be a general counseling service. > > > > I'm starting to wonder if it wouldn't make more sense to > > group all of > > these counseling services (mental health, run-away, drug > and alcohol > > abuse, suicide prevention, etc.) into a new top category, such as > > "advice". > > > > One practical reason is that these services have somewhat > different > > privacy and location needs compared to traditional fire/police/ > > ambulance emergency services. For example, I don't think it would > > make sense to mandate location and identity disclosure for these > > counseling services. Indeed, many of these services offer > anonymity > > to encourage calls, even though 800 numbers in the US > > obviously allow > > the agency to see the calling number, even with CLID restrictions. > > > > The UA requirements draft will presumably mandate inclusion of > > location information in all sos.* calls; this does not seem > > appropriate for these crisis counseling services. > > > > Henning > > > > > > > > > > I bring this to your attention because at the SG2 Meeting this > > > week in Geneva a request for numbering resources was brought > > > forward to Q1 by Child Helpline International. For your > information > > > I copy the relevant text of the Q1 Report below. > > > > > > As you see from the text, a draft circular was created > > > to request information by ITU TSB from member states on > > > this issue and also on a emergency numbers in general. > > > > > > Since this is also for interest for ECRIT, I copy also > > > the draft circular below. You should keep in mind that > > > this is only a draft and will be modified by TSB before > > > sent out officially. > > > > > > The results of this survey will also prove useful for > > > the further work of ECRIT. > > > > > > best regards > > > > > > Richard Stastny > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 13 18:17:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff2Pj-0006Vq-O2; Sat, 13 May 2006 18:16:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff2Pi-0006PZ-Hh for ecrit@ietf.org; Sat, 13 May 2006 18:16:42 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ff2Pg-0006wx-3b for ecrit@ietf.org; Sat, 13 May 2006 18:16:42 -0400 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] Commments I.D-ecrit-service-urn-03 Child helpline Date: Sun, 14 May 2006 00:20:40 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A37@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Commments I.D-ecrit-service-urn-03 Child helpline Thread-Index: AcZ21UN9Yh9yYq9xRQ6gz6y5fN7NJAAA6yK4 From: "Stastny Richard" To: "Drage, Keith \(Keith\)" , "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Keith; >In the UK the equivalent is run by a charity, which has in the past = made play that it is independent of any authority in >promoting itself = to its clients. >So from a UK perspective, I would have no difficulty in seeing it = grouped with other counselling services. >If classed as an emergency service, I suspect that in the absence of a = local provider, the routeing to a default PSAP that >may well be the = police would cause distress to some callers. As I said, the issue is (currently) a national matter, in Austria it is = treated by ordinance as an emeregncy service. =20 OTOH, the issue has been taken now to a global (ie. political) level, = originally at the =20 "World Summit on Information Society (Tunis, 14-20 November 2005): = Article 92 states "We encourage countries, including all other = interested parties, to make available child helplines, taking into = account the need for mobilization of appropriate resources. For this = purpose, easy-to-remember numbers, accessible from all phones and free = of charge, should be made available." =20 This statement caused the input from Chile Helpline International, a = global network of helplines for children and young in 103 countries to ITU-T. There was strong = support by the member states for this, causing now the circular sent to all meber states. As you also see, the milestones are defined in such a way to get some = feedback already before the plenipot meeting in November in Antalya, where I suspect that = this issue will get some attention. And one also may assume that some decisions will be made to announce = some=20 success i-e commitment (I am now citing again from the input document to = ITU-T SG2:) =20 May 17th is World Telecoms Day. The theme for 2007 is children and = youth. This day celebrates children as key players in the information = society. It would therefore be an ideal opportunity to announce the = telecoms sector's commitment to a toll free, easy to remember, 3-4 digit = number for all children, so that every child in need of care and = protection knows that help is just a phone call away! =20 It would be nice if IETF could also contribute something to this = commitment of the telecoms sector in 2007 =20 This seems to be a very political issue. =20 regards Richard =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 13 19:34:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff3cd-0006Q9-JW; Sat, 13 May 2006 19:34:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff3cc-0006Q2-DI for ecrit@ietf.org; Sat, 13 May 2006 19:34:06 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ff3cb-0002uZ-W5 for ecrit@ietf.org; Sat, 13 May 2006 19:34:06 -0400 Received: (qmail invoked by alias); 13 May 2006 23:33:58 -0000 Received: from ip-80-226-199-65.vodafone-net.de (EHLO [10.226.221.82]) [80.226.199.65] by mail.gmx.net (mp027) with SMTP; 14 May 2006 01:33:58 +0200 X-Authenticated: #29516787 Message-ID: <44666CDF.4080703@gmx.net> Date: Sun, 14 May 2006 01:33:51 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline References: <32755D354E6B65498C3BD9FD496C7D462C4A36@oefeg-s04.oefeg.loc> <17B88095-EF68-4282-AE10-CAFB74DCBAED@cs.columbia.edu> In-Reply-To: <17B88095-EF68-4282-AE10-CAFB74DCBAED@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Stastny Richard , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Henning, it was foreseeable that the grouping would be difficult. I, however, agree with your proposal to focus on the immediate-response-with-location-needed services in the Service URN draft as part of the SOS branch. Some other services do not seem to that (a) very urgent or (b) may impose different authentication, authorization, location and charging requirements. It might be interesting to state in the IANA consideration section that the definition of new services need to investigate these aspects. Regarding the additional attribute in LoST to indicate the need to include location information: For the SOS services the inclusion of location info does not need to be explicit. It is obvious from the definition in the document. For other services it might be reasonable to argue that in some countries location info is required and in other countries it isn't. Hence, LoST could provide this info. Ciao Hannes Henning Schulzrinne wrote: >> > > Note to ECRIT participants: This issue raises a larger point, so even > if you don't care about child helplines, take a look at the proposal at > the bottom. > > >> [Richard] As you see from the request from Child Helpline International >> and also from the draft circular questionary, it is also unclear to >> them and to SG2 if >> this should be an emergency service or a counseling service using >> toll free numbers. >> > > There seem to be at least three dimensions for such services, all of > which are somewhat beyond the scope: > > - whether to allow non-registered and expired subscribers to use these > services (true for 800# on payphones, but not from private residences, > for example) > > - whether to mandate inclusion of location information > > - whether to use a regular number (800#, say) or a short three/four > digit number, i.e., the dial string > > >> [Richard] Our problem is that we cannot decide in IETF what of these >> services is an emergency service, because this is a national matter. >> Also what is an conselling service and what >> other services might be there: e.g services for public interest, but >> not toll free, >> e.g. car break down services. Directory services with additional charges >> services where location information MUST be provided, services where >> location information is only by user push, and services where location >> information and identity must be withheld, etc. etc >> >> [Richard] IMHO we should try to define these types of services, >> but leave it to the national implementations to define in what box >> they put specific services. > > > While we don't have to decide on dial strings and issues of network > access (this can be done on a local basis or can be contained in LoST > records), the inclusion of location information needs to be universal, > not national UNLESS we also include this information in the LoST > record, along with the dial string. > > My inclination would be to focus on the universally-agreed upon > immediate-response-with-location-needed services in sos for now, but > also define an attribute in the LoST schema that indicates location > inclusion. > > >> >> regards Richard >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 13 19:35:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff3dU-0006TU-1r; Sat, 13 May 2006 19:35:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff3dS-0006TP-TJ for ecrit@ietf.org; Sat, 13 May 2006 19:34:58 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ff3dR-0002xO-Rl for ecrit@ietf.org; Sat, 13 May 2006 19:34:58 -0400 Received: (qmail invoked by alias); 13 May 2006 23:34:53 -0000 Received: from ip-80-226-199-65.vodafone-net.de (EHLO [10.226.221.82]) [80.226.199.65] by mail.gmx.net (mp035) with SMTP; 14 May 2006 01:34:53 +0200 X-Authenticated: #29516787 Message-ID: <44666D13.3050005@gmx.net> Date: Sun, 14 May 2006 01:34:43 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Marshall References: <8C837214C95C864C9F34F3635C2A657504EBFDAA@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A657504EBFDAA@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 662324ecda47446db09bfd0a0092c4ba Cc: ecrit@ietf.org Subject: [Ecrit] Re: Review of draft-ietf-ecrit-requirements-08.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Roger, thanks for the quick response. You suggested changes look good. Ciao Hannes Roger Marshall wrote: > Hannes: > Thanks very much for your comments to the -08 draft. A new version, > w/the changes incorporated, will be published soon. > > See changes/responses in-line: > > -roger. > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: Friday, May 05, 2006 5:22 AM >>To: ecrit@ietf.org; Henning Schulzrinne; Roger Marshall >>Subject: Review of draft-ietf-ecrit-requirements-08.txt >> >>Hi all, >> >>here is a review of draft-ietf-ecrit-requirements-08.txt. The >>document is getting much better. Still, I have a few comments: >> >>* Introduction: >> >> >>I would delete this paragraph since it is a bit confusing at >>this point: >> >> As used in this document, validation of location does not require >> that we ascertain as to whether or not the location >>actually exists. >> For example, validation might only check that the house number in a >> civic address falls within the assigned range, not whether a >> building, known by a specific building number, exists at that >> location. However, such higher precision validation is desirable. >> >>This might be relevant in subsequent sections. > > > Agreed, deleted above paragraph. Concept is already referred to in the > term defn, "Location validation". > > >> >> >> Identification of the caller, while not incompatible with the >> requirements for messaging outlined within this document, is >> considered to be outside the scope of the ECRIT charter. >> ^^^^^^^^^^^^^^^^^^ >> >>Don't mention the working group name in the document. > > > The reference to ECRIT has been removed throughout document. > > >>Write "... is outside the scope of this document." > > > Agreed. Done. > > >> >> 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, for >>example, a TEL >> URI which may be used to complete a call via the PSTN. >> >>I am not sure about this paragraph. Where do we provide such a >>functionality? > > > Agree that there is no existing requirement to which this paragraph > refers to, so I've reworded the paragraph, and have added a NEW > requirement as written below: > > CHANGE FROM: > Ideally, the mapping protocol would yield a URI from a preferred set of > URIs (e.g., SIP:URI, SIPS:URI) which would allow an emergency call to be > > completed using IP end-to-end. 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, for example, a TEL URI which may be > used to complete a call via the PSTN. > > CHANGE TO: > The intent of the mapping protocol is to produce a PSAP URI (from a > preferred set of URIs, e.g., SIP:URI, SIPS:URI) based on a location > input, > to facilitate the IP end-to-end completion of an emergency call. Since > not > every PSAP will immediately support IP, it may be necessary to also > support less preferred URI schemes, such as a TEL URI in order to > complete an emergency call via the PSTN. > > ADDED: > Ma18. Non-preferred URI schemes: The mapping > protocol MAY support the return of a less preferred URI scheme, > (e.g., TEL URI). > > Motivation: In order to provide incremental support to non-IP > PSAPs it may be necessary to be able to complete an emergency > call via the PSTN. > > > >>* Terminology >> >>I would cluster the terms. For example, you might want to keep >> - (Location-dependent) emergency dial string >> - Home emergency dial string >> - Visited emergency dial string >>together to make the terminology easier to read. >> >>There is no requirement to list the terms alphabetically. > > > Agreed. Terms have been reordered and clumped together. > > >> >> Emergency address: The URI (e.g., SIP:URI, SIPS:URI, XMPP:URI, IM: >> ^^^^^^^ change to identifier >> URI, etc.) which represents the address of the PSAP >>useful for the >> completion of an emergency call. >> >> Emergency call routing support: An intermediary function which >> assists in the routing of an emergency call via IP. An >>ESRP is an >> example of an Emergency call routing support entity. >> ^^^^^^^^^ emergency >> > > > Conflated the two terms, "Emergency address" and "PSAP URI", into one > entry under PSAP URI. > > >>Delete the following paragraph: >> >> Codes: "caller" or "emergency caller" refers to the person >>placing an >> emergency call or sending an emergency instant message (IM). >> >>AND move the text over to this term: >> >> Emergency caller: The user or user device entity which >>sends his/her >> location to another entity in the network. >> >>As such, it would read: >> >> (Emergency) caller: The term "caller" or "emergency >>caller" refer to the person placing an emergency call or >>sending an emergency instant message (IM). > > > Agreed. Changes made to draft. > > >> >> >> In this document, the key words "MUST", "MUST NOT", "REQUIRED", >> "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", >> and "OPTIONAL" are to be interpreted as described in RFC 2119 [1], >> with the qualification that unless otherwise stated these >>words apply >> to the design of the mapping protocol, not its implementation or >> application. >> ^^^^^^^^^^^ usage > > > Modification made. > > >> >>With the suggested change from "Emergency address" to "Emergency >>identifer" we have the term 'emergency identifier' appearing twice: >> >> Emergency identifier: An identifier that marks a call as >>an emergency >> call. >> >>I suggest to delete this definition or to merge it with the >>previous one. > > > No changes made here, subject to list discussions/clarfications. We end > up with two terms, having different usage, "emergency identifier", and > "PSAP URI". > > >>In the text we should always use small letters for terms like 'mapping >>servers' or 'mapping clients'. For example, >> >> Mapping client: A mapping client interacts with the >>Mapping Server to >> ^^^^^^^^^^^^^^ >> learn one or more PSAP URIs for a given location. >> >> >> Mapping server: The Mapping Server holds information about the >> ^^^^^^^^^^^^^^ >> location-to-PSAP URI mapping. > > > Agreed. Low-case changes made. > > >> >>Change from: >> >>" >> PSAP URI: PSAP URI is a general term, used to refer to the >>output of >> the mapping protocol, and represents either the actual PSAP IP >> address, or the IP address of some other intermediary, e.g., an >> ESRP, which points to the actual PSAP. >>" >> >>to: >> >>" >> PSAP URI: The term 'PSAP URI' refers to a URI that identifiers a >>PSAP. We use this term to denote the reponse of a mapping >>protocol query. > > > Change NOT made, since we have renamed emergency address to PSAP URI, > and so have the result: > > PSAP URI: The URI (e.g., SIP:URI, SIPS:URI, XMPP:URI, > etc.) at which the PSAP may be contacted with an emergency call. This > contact could be done directly, or via an intermediary, (e.g., ESRP). > > > >>" >> >>* Section 3. Basic Actors >> >> In order to support emergency services covering a large physical >> area, various infrastructure elements are necessary, including: >> Internet Attachment Providers (IAPs), Application/Voice Service >> Providers (ASP/VSPs), PSAPs as endpoints for emergency >>calls, mapping >> >>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ delete >>this part; the PSAP is only one endpoint of the communciation. >> >> services or other infrastructure elements that assist >>during the call >> ^^^ and >> routing. > > > Changed text to read: > In order to support emergency services covering a large physical > area, various infrastructure elements are necessary, including: Internet > > Attachment Providers (IAPs), Application/Voice Service Providers > (ASP/VSPs), Emergency Call Routing Support (ECRS) providers, > mapping service providers, and PSAPs. > > >> >> o How is location information provided to the end host? >>It might >> either be known to the end host itself via manual configuration, >> provided via GPS, or obtained via a third party method. Even if >> location information is known to the network it might be made >> available to the end host via DHCP (RFC 3825 [2]) or some other >> mechanism. Alternatively, location information is used as part of >> call routing and inserted by intermediaries. >> >> >>Change paragraph to: >> >> o How is location information provided to the end host? It might >> either be known to the end host itself via manual configuration, >> provided via GPS, made >> available via DHCP (see RFC 3825 [2]) or some other >> mechanisms. Alternatively, location information is used as part of >> call routing and inserted by intermediaries. > > > Changed text as suggested. > > >> >> (5) Location Information is used by emergency call routing entities >> ^^^^^^^^^^^ information >> for subsequent mapping requests. > > > Corrected text to low-case. > > >>4. High-Level Requirements >> >> Re1. Application/Voice service provider existence: The >>initiation of >> an IP-based emergency call SHOULD NOT assume the existence of an >> Application/Voice Service Provider (ASP/VSP). >> >> Motivation: The caller may not have an application/voice service >> provider. For example, a residence may have its own DNS domain >> and run its own SIP proxy server for that domain. On a larger >> scale, a university might provide voice services to its students >> and staff, but not be a telecommunication provider. >> ^ add "might" > > > Inserted word "might". > > >> >>5. Identifying the Caller's Location >> >> Location can either be provided directly, or by reference, and >> represents either a civic location, or as a geographic location. >> ^^ and geospatial location >>information. > > > Changed text as suggested. > > >> How >> does the location (or location reference) become >>associated with the >> call? >> >>change last sentence to: >> >>"An important question is how and when to attach location >>information to >>the VoIP emergency signaling." > > > Changed text as suggested. > > >> In general, we can distinguish three modes of operation of how >> a location is associated with an emergency call: >> >>Change from: >> >> UA-inserted: The caller's user agent inserts the location >>information >> into the call signaling message. The location information is >> derived from sources such as GPS, DHCP (RFC 3825 [2]) and >> I-D.ietf-geopriv-dhcp-civil [7]) or utilizing the Link Layer >> Discovery Protocol (LLDP) [see IEEE8021AB]. >> >> >>to: >> >> >> UA-inserted: The caller's user agent inserts the location >>information >> into the call signaling message. The location information is >> derived from sources such as GPS, DHCP (see [2] for geospatial >>location information and [7] for civic location information) or >>utilizing the Link Layer >> Discovery Protocol (LLDP) (see [IEEE8021AB]). > > > Changed text as suggested. > > >> >> UA-referenced: The caller's user agent provides a pointer (i.e., a >> location reference), via a permanent or temporary identifier, to >> the location which is stored by a location service >>somewhere else >> ^^^^^^^ server >>delete the 'somewhere else' part. >> and then retrieved by the PSAP, ESRP, or other >>authorized service >> entity. > > > Changed "service" to "server". > > >> Lo2. Location object/info preservation: The mapping protocol MUST >> retain any location information which is provided to it, even >> after mapping is performed. >> >> Motivation: The ESRP and the PSAP use the same location >> information object, but for a different purpose. >>Therefore, it is >> imperative that the mapping protocol not remove location >> ^ does >> Information so that the PSAP can still receive the caller >> ^^^^^^^^^^^ information >> location. > > > Changed text to: > Motivation: The ESRP and the PSAP use the same location > information object, but for a different purpose. Therefore, it is > imperative that the mapping protocol does not remove the > location information from the messaging, so that it can be provided > to the PSAP. > > >> >> Lo5. Validation of civic location: The mapping protocol >>MUST support >> location validation for civic location (street addresses), prior >> to initiating an emergency call. >> >>delete the ", prior to initiating an emergency call." part. > > > Removed text per suggestion. > > >> Motivation: Location validation provides an opportunity to help >> assure ahead of time, whether or not successful mapping to the >> ^ add 'a' >> appropriate PSAP will likely occur when it is required. >> Validation may also help to avoid delays during emergency call >> setup due to invalid locations. > > > Inserted "a" per suggestion. > > >> >>Isn't Lo7 similar to L10? > > > Agree that the two are similar in intent, therefore have removed Lo10. > > >>Isn't Lo6 similar to Lo11? > > > Not sure, but I do think that Lo11 is not general enough, so have > removed Lo11. > > >> >> Lo9. 3D sensitive mapping: The mapping protocol MUST implement >> support for both 2D and 3D location information, and may accept >> either a 2D or 3D mapping request as input. >> >> Motivation: It is expected that provisioning systems will accept >> ^^^^^^^^^^^^^^^^^^^^ >>what is that? >> >> 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 in the request. > > > Reworded motivation paragraph to read as follows: > Motivation: It is expected that end devices or location servers will > provide either 2D or 3D data. When a 3D request is presented within an > area only defined by 2D data within the mapping server, the mapping > result > would be the same as if the height/altitude dimension was omitted in the > > request. > > >> >>6. Emergency Identifier >> >> Id1. Emergency identifier support: The mapping protocol >>MUST support >> one or more emergency identifiers for delivery back to mapping >> clients to be used for call setup purposes. >> >>I guess this requirement should say: >> >>" >> Emergency identifier support: The mapping protocol MUST be able to >>return one or multiple emergency identifiers in response to a query. > > > Changed text to: > Id1. Emergency identifier support: The mapping protocol > MUST be able to return one or multiple emergency identifiers in > response to a query. > > >>" >> >> >> >> Id2. Emergency identifier resolution: Where multiple emergency >> identifiers exist, the mapping protocol MUST be able to >> differentiate between identifiers based on the specific type of >> emergency help requested. >> >> Motivation: Some jurisdictions may have multiple types of >> emergency services available, (e.g., fire, police, >>ambulance), in >> which case, it is important that any one could be selected >> directly. >> >>There is a terminology confusion here: >>I think you refer to 'sos Service Types' here rather than multiple >>emergency identifers. You might want to double-check with >>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-ur >>n-02.txt >>(and in particular with Section 4.3). >> >>This terminology issue impacts also requirement Id5. > > > Pending. Not sure. Seeking clarification from Hannes on above items. > > >> Id4. Prevention of fraud: If a call is identified as an emergency >> call, the mapping protocol MUST support that call being >> successfully routed to a PSAP. >> >> Motivation: This prevents use of the emergency call >>indication to >> gain access to call features or authentication override for non- >> emergency purposes. >> >>This requirement is covered in the security document. > > > Deleted Id4 as per suggestion. > > >> >>Requirement Id6, Id7, Id8, Id9, Id10 start with "The mapping protocol >>MUST/SHOULD support " but I think that these requirements do not >>necessarily address the mapping protocol. I think a "There MUST be >>support for...." > > > Changed requirements Id6, Id7, Id8, Id9, Id10, to now read "There MUST > be support for...". > > >> >>7. Mapping Protocol >> >> There are two basic approaches to invoking a mapping service. We >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> invoke the mapping protocol. > > > Changed wording. > > >> refer to these as caller-based and mediated. In each case, the >> mapping client initiates a request to a mapping server via >>a mapping >> protocol. A proposed mapping protocol is outlined in the document >> I-D.hardie-ecrit-lost [6]. >> >> For caller-based resolution, the caller's user agent invokes a >> ^ the >> mapping service to determine the appropriate PSAP based on the >> ^^^^^^^ protocol >> location provided. The resolution may take place well before the >> actual emergency call is placed, or at the time of the call. >> >> For mediated resolution, a call signaling server, such as a SIP >> ^^^^^^^^^^^^^^^^^^^^^^^ >> an emergency call routing support entity >> >> (outbound) proxy or redirect server invokes the mapping service. > > > Changes made to draft. > > >> >> Ma5. URI alternate contact: In addition to returning a primary >> contact, the mapping protocol MUST support the return >>of a URI or >> contact method explicitly marked as an alternate contact. >> >> Motivation: In response to a mapping request, the mapping server >> may return an alternate URI. Implementation details to be >> described within an operational document. >> >> >>I am not quite sure about Ma6 and Ma8. Ma8 tells me that the mapping >>protocol provides a URL for error reporting. Isn't Ma6 similar? >> >> >> Ma6. URL properties: The mapping protocol MUST support the ability >> ^^^ URI >> >> to provide ancillary information about a contact or URI that >> ^^^^^^ delete >> allows the mapping client to determine relevant >>properties of the >> URL. >> ^^^^ URI? > > > Modified text as per suggestion. > > >> >> Motivation: In some cases, the same geographic area is served by >> several PSAPs, for example, a corporate campus might be >>served by >> both a corporate security department and the municipal >>PSAP. The >> mapping protocol should then return URLs for both, with >> ^^^^ URIs >> information allowing the querying entity to choose one or the >> other. This determination could be made by either an >>ESRP, based >> on local policy, or by direct user choice, in the case >>of caller- >> based methods. >> >> Ma7. Traceable resolution: The mapping protocol SHOULD support the >> ability of the mapping client to be able to determine the entity >> or entities which provided the emergency address resolution >> ^^^^^ that >> information. >> >> Motivation: It is important for public safety reasons, >>that there >> is a method to provide operational traceability in case >>of errors. >> >> Ma8. URI for error reporting: The mapping protocol MUST >>support the >> ^^^^ URL >> >> return of a URI that can be used to report a suspected or known >> ^^^^^^^^^^^^^^^ the ability to return a URL >> >> error within the mapping database. >> >> Motivation: If an error is returned, for example, there needs to >> be a URI which points to a resource which can explain or >> ^^^^ URL >> >> potentially help resolve the error. > > > Changed per suggestion. > > >> >> Ma16. Multiple PSAP URIs: The mapping protocol MUST >>support a method >> to receive multiple PSAP URIs which cover the same geographic >> ^^^^^^^ return >> area. >> >> Motivation: Two different mapping servers may cover the same >> geographic area, and therefore have the same set of coverage >> information. >> >>Isn't this requirement very similar to Ma4? > > > Agreed that Ma4 & Ma16 are same. Deleted Ma4. > > >> >> >> >>* 8. Security Considerations >> >> Security considerations are discussed in the ECRIT >>security document >> I-D.ietf-ecrit-security-threats [4] . >> >>Write: >> >>" >>Threats and security requirements are discussed in a separate >>document, >>see [4]. > > > Changed text as per suggestion. > > >>" >> >>* Add an IANA section. >>" >>9. IANA Considerations >> >> This document does not require actions by the IANA. >>" > > > Added new section as per suggestion. > > >> >>Ciao >>Hannes >> > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 13 20:00:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff42B-0007mY-3T; Sat, 13 May 2006 20:00:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff42A-0007mT-Bp for ecrit@ietf.org; Sat, 13 May 2006 20:00:30 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ff428-0004BT-53 for ecrit@ietf.org; Sat, 13 May 2006 20:00:30 -0400 Received: from [192.168.0.41] (pool-138-89-20-236.mad.east.verizon.net [138.89.20.236]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k4E00Liw017973 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 13 May 2006 20:00:24 -0400 (EDT) In-Reply-To: <44666CDF.4080703@gmx.net> References: <32755D354E6B65498C3BD9FD496C7D462C4A36@oefeg-s04.oefeg.loc> <17B88095-EF68-4282-AE10-CAFB74DCBAED@cs.columbia.edu> <44666CDF.4080703@gmx.net> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0164A860-3B72-4DE2-8B65-CF8E92BA5CC9@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Date: Sat, 13 May 2006 20:00:19 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.749.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Stastny Richard , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > For the SOS services the inclusion of location info does not need > to be explicit. It is obvious from the definition in the document. > For other services it might be reasonable to argue that in some > countries location info is required and in other countries it > isn't. Hence, LoST could provide this info. Well, according to recent messages, this doesn't even seem universally true for emergency calls (see the Japan example). Even within emergency services, this is, strictly speaking, not true. For example, in the US, poison control (1-800-222-2222) clearly doesn't expect location information and probably has no legal basis for demanding it. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 13 20:14:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff4Fb-0003uv-JT; Sat, 13 May 2006 20:14:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff4FZ-0003uq-EL for ecrit@ietf.org; Sat, 13 May 2006 20:14:21 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ff4FZ-0004rq-1S for ecrit@ietf.org; Sat, 13 May 2006 20:14:21 -0400 Received: (qmail invoked by alias); 14 May 2006 00:14:19 -0000 Received: from ip-80-226-199-65.vodafone-net.de (EHLO [10.226.221.82]) [80.226.199.65] by mail.gmx.net (mp040) with SMTP; 14 May 2006 02:14:19 +0200 X-Authenticated: #29516787 Message-ID: <44667653.9060100@gmx.net> Date: Sun, 14 May 2006 02:14:11 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline References: <32755D354E6B65498C3BD9FD496C7D462C4A36@oefeg-s04.oefeg.loc> <17B88095-EF68-4282-AE10-CAFB74DCBAED@cs.columbia.edu> <44666CDF.4080703@gmx.net> <0164A860-3B72-4DE2-8B65-CF8E92BA5CC9@cs.columbia.edu> In-Reply-To: <0164A860-3B72-4DE2-8B65-CF8E92BA5CC9@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Stastny Richard , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Henning, Henning Schulzrinne wrote: >> >> For the SOS services the inclusion of location info does not need to >> be explicit. It is obvious from the definition in the document. For >> other services it might be reasonable to argue that in some countries >> location info is required and in other countries it isn't. Hence, >> LoST could provide this info. > > > Well, according to recent messages, this doesn't even seem universally > true for emergency calls (see the Japan example). I guess you refer to Keith's message. He referred to identity privacy (if I understood him correctly). > Even within emergency > services, this is, strictly speaking, not true. For example, in the US, > poison control (1-800-222-2222) clearly doesn't expect location > information and probably has no legal basis for demanding it. This makes the classification not necessarily easier. It, however, demands an attribute that indicates to express whether location info is needed for a specific service identifier. Ciao Hannes > > Henning > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 13 20:22:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff4N7-0005vk-8Q; Sat, 13 May 2006 20:22:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff4N6-0005vf-5L for ecrit@ietf.org; Sat, 13 May 2006 20:22:08 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ff4N4-0005E7-R5 for ecrit@ietf.org; Sat, 13 May 2006 20:22:08 -0400 Received: from [192.168.0.41] (pool-138-89-20-236.mad.east.verizon.net [138.89.20.236]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k4E0M0gZ024292 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 13 May 2006 20:22:05 -0400 (EDT) In-Reply-To: <44667653.9060100@gmx.net> References: <32755D354E6B65498C3BD9FD496C7D462C4A36@oefeg-s04.oefeg.loc> <17B88095-EF68-4282-AE10-CAFB74DCBAED@cs.columbia.edu> <44666CDF.4080703@gmx.net> <0164A860-3B72-4DE2-8B65-CF8E92BA5CC9@cs.columbia.edu> <44667653.9060100@gmx.net> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <193434C0-BF6E-4A13-9E46-42B1F2B427E8@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Date: Sat, 13 May 2006 20:21:55 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.749.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Stastny Richard , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On May 13, 2006, at 8:14 PM, Hannes Tschofenig wrote: > Hi Henning, > > Henning Schulzrinne wrote: >>> >>> For the SOS services the inclusion of location info does not >>> need to be explicit. It is obvious from the definition in the >>> document. For other services it might be reasonable to argue >>> that in some countries location info is required and in other >>> countries it isn't. Hence, LoST could provide this info. >> Well, according to recent messages, this doesn't even seem >> universally true for emergency calls (see the Japan example). > > I guess you refer to Keith's message. He referred to identity > privacy (if I understood him correctly). Right, but those seem essentially the same, at least for fixed-line services. After all, getting the location from the phone number and vice versa is often fairly easy, particularly for a government agency. (See recent US headline news...) > > >> Even within emergency services, this is, strictly speaking, not >> true. For example, in the US, poison control (1-800-222-2222) >> clearly doesn't expect location information and probably has no >> legal basis for demanding it. > This makes the classification not necessarily easier. > > It, however, demands an attribute that indicates to express whether > location info is needed for a specific service identifier. > One pretty simple solution is to have a four-valued attribute: - required --> no service without it; you're legally obligated to provide it for this service - helpful --> the receiver would like to have this information, but isn't going to refuse the call and you're not legally obligated; if you route the call yourself, you don't need to include it in signaling - routing --> the receiver doesn't need it, but it's used to route the call - ignored --> the receiver will just ignore the location information and there's no location-based routing I suspect this can be split into two dimensions (routing and end system). > Ciao > Hannes > >> Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun May 14 11:28:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfIWH-0007b5-5e; Sun, 14 May 2006 11:28:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfIWF-0007b0-Td for ecrit@ietf.org; Sun, 14 May 2006 11:28:31 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FfIWE-0006bn-Go for ecrit@ietf.org; Sun, 14 May 2006 11:28:31 -0400 Received: (qmail invoked by alias); 14 May 2006 15:28:28 -0000 Received: from bl8-104-121.dsl.telepac.pt (EHLO [192.168.2.199]) [85.241.104.121] by mail.gmx.net (mp016) with SMTP; 14 May 2006 17:28:28 +0200 X-Authenticated: #29516787 Message-ID: <44674C91.5080701@gmx.net> Date: Sun, 14 May 2006 17:28:17 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline References: <32755D354E6B65498C3BD9FD496C7D462C4A36@oefeg-s04.oefeg.loc> <17B88095-EF68-4282-AE10-CAFB74DCBAED@cs.columbia.edu> <44666CDF.4080703@gmx.net> <0164A860-3B72-4DE2-8B65-CF8E92BA5CC9@cs.columbia.edu> <44667653.9060100@gmx.net> <193434C0-BF6E-4A13-9E46-42B1F2B427E8@cs.columbia.edu> In-Reply-To: <193434C0-BF6E-4A13-9E46-42B1F2B427E8@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Stastny Richard , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Henning, Henning Schulzrinne wrote: > > On May 13, 2006, at 8:14 PM, Hannes Tschofenig wrote: > >> Hi Henning, >> >> Henning Schulzrinne wrote: >> >>>> >>>> For the SOS services the inclusion of location info does not need >>>> to be explicit. It is obvious from the definition in the document. >>>> For other services it might be reasonable to argue that in some >>>> countries location info is required and in other countries it >>>> isn't. Hence, LoST could provide this info. >>> >>> Well, according to recent messages, this doesn't even seem >>> universally true for emergency calls (see the Japan example). >> >> >> I guess you refer to Keith's message. He referred to identity privacy >> (if I understood him correctly). > > > Right, but those seem essentially the same, at least for fixed-line > services. After all, getting the location from the phone number and > vice versa is often fairly easy, particularly for a government agency. > (See recent US headline news...) As a general statement it is, however, not true. > > >> >> >>> Even within emergency services, this is, strictly speaking, not >>> true. For example, in the US, poison control (1-800-222-2222) >>> clearly doesn't expect location information and probably has no >>> legal basis for demanding it. >> >> This makes the classification not necessarily easier. >> >> It, however, demands an attribute that indicates to express whether >> location info is needed for a specific service identifier. >> > > One pretty simple solution is to have a four-valued attribute: > > - required --> no service without it; you're legally obligated to > provide it for this service > - helpful --> the receiver would like to have this information, but > isn't going to refuse the call and you're not legally obligated; if you > route the call yourself, you don't need to include it in signaling > - routing --> the receiver doesn't need it, but it's used to route the > call > - ignored --> the receiver will just ignore the location information > and there's no location-based routing > > I suspect this can be split into two dimensions (routing and end system). > Does not sound like a bad idea. This assumes that these properties do not change on a regular basis or depend on parameters that cannot be provided by LoST (e.g., user specific properties). What do other people think? Ciao Hannes > >> Ciao >> Hannes >> >>> Henning > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun May 14 18:13:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfOpi-0001JX-4r; Sun, 14 May 2006 18:13:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfOph-0001JS-EZ for ecrit@ietf.org; Sun, 14 May 2006 18:13:01 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FfOpg-0001ax-1f for ecrit@ietf.org; Sun, 14 May 2006 18:13:01 -0400 Received: (qmail invoked by alias); 14 May 2006 22:12:57 -0000 Received: from bl8-104-121.dsl.telepac.pt (EHLO [192.168.2.199]) [85.241.104.121] by mail.gmx.net (mp039) with SMTP; 15 May 2006 00:12:57 +0200 X-Authenticated: #29516787 Message-ID: <4467AB66.40307@gmx.net> Date: Mon, 15 May 2006 00:12:54 +0200 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: e1b0e72ff1bbd457ceef31828f216a86 Subject: [Ecrit] Review of draft-ietf-ecrit-service-urn-02 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Henning, I took a quick look at the draft-ietf-ecrit-service-urn-02 draft. The document looks good! I only have a few editorial comments. * Abstract: The content of many communication services depend on the context, ^^^^^^^ depends * Introduction opportunities (211 in some regions of the United States),telephone ^^ blank * Introduction We discuss alternative approaches, and why they are unsatisfactory, in Appendix A. [hannes] reading throught the introduction you might want to say "We discuss alternative approaches for creating service identifiers...." since otherwise one might get the impression that you are talking about the previous section, i.e., about mapping protocols. * Missing terminology section. [hannes] You should add a terminology section here and point to the requirements draft. * Formatting issue: [hannes] If you put a after each item when you make the text easier to read. If you put a after the then it even looks better. This is also useful for Section 4.3. * Section 2: Relevant ancillary documentation: None Community considerations: The service URN is believe to be relevant ^^^^^^^ believed * Section 2: particular service in the user's current context, e.g., at his ^^^ its * Section 2: For example, a traveler will be able to use his ^^^^ its * Section 2: the local emergency number. ^^^^^^^^^^^^^^^^^^^^^^ [hannes] If I recall it correctly then we use the term visited emergency dial string in this context. * Section 4.3: sos Service Types We have discussed the usage of the term 'sos Service Types' terminology. It depends on Roger how to best align this document with the requirements draft. As you recall from the location types draft we got asked where the definitions come from. Where do the definitions in this document come from? * IDN Since the identifiers used in this document might also presented to the user do we have to mention IDN considerations somewhere. I bet we will get such a question. Maybe a short text could go into a 'Internationalization Considerations' section. * Appendix A You might want to restructure / reformat this section slightly to improve readability. You can either put each alternative as a subsection or you use the text Before listing all approaches (starting with '"sos" SIP URI' to 'Special domain:') you might want to write something like: "During the work on this document we considered a number of alternative approaches." Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 15 18:04:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FflBB-0007XA-3L; Mon, 15 May 2006 18:04:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FflBA-0007X5-7g for ecrit@ietf.org; Mon, 15 May 2006 18:04:40 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FflB9-0007bO-TX for ecrit@ietf.org; Mon, 15 May 2006 18:04:40 -0400 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.6.118]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k4FM47X29954; Mon, 15 May 2006 16:04:07 -0600 Message-ID: <4468FAD8.3050306@ntt-at.com> Date: Mon, 15 May 2006 15:04:08 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt References: <072C5B76F7CEAB488172C6F64B30B5E301703E8C@xmb-rtp-20b.amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: ecrit@ietf.org, Stastny Richard X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org It's good that one can obtain primary and backup URIs, and I personally think the text has really improved. It's not really related but this thread had made me think of a situation where there is a regional disaster or regional scale DoS attack and both primary and backup URIs given by LOST is not reachable? What would happen then? Until propagation is completed to change the data in the database that URIs in the region is not reachable, I am assuming that LOST will always provide the same URI A for the locations A. Thus client will not be able to reach the PSAPs. And because LOST is not stateful it will not provide client with different set of URIs on its second attempt. This might be a deployment/implementation matter and might not be a protocol requirement and I might be the only one concerned, but because LOST is decoupled from the signaling path, it might be good to have a way for LOST clients to request a URI with a list of URIs that it does not want to receive as a resolutions. example: Please provide me with URIs for service A given my location is A but don't provide me with URI A or URI B. Regards Shida Schubert Ted Hardie wrote: > At 10:03 AM -0400 5/9/06, Michael Hammer \(mhammer\) wrote: > >> >From the peanut gallery: >> >> Ma17 and Ma5 still seem to be in conflict. If my contact protocol is >> SIP, how many SIP contacts will be provided overall? Ma17 says 1. Ma5 >> says there can be primary and alternate, that is 2. So, is it 1 or 2, >> or perhaps more if there are multiple overlapping police forces? >> > > I think you're making this harder than you need to. If I send a > query requesting the contact URIs for a specific service based on > my location, I get back one URI per scheme. I may also get > back a URI explicitly marked as a fallback, for use only if I cannot > use the usual contact URIs received (or if I try them and they fail). > So you might get one geographically appropriate SIP URI, one geographically > appropriate SMS URI, and one geographically appropriate XMPP URI. > The fallback SIP URI (if present) is not necessarily as geographically > appropriate; it might point to something like a state-wide response > center. > > Frankly, I think we've wordsmithed this enough. Much more effort > will not produce better instructions to the protocol designers. > regards, > Ted Hardie > > > > > _______________________________________________ > 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 May 15 18:42:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfllQ-0004SB-1Z; Mon, 15 May 2006 18:42:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfllO-0004Ke-EO for ecrit@ietf.org; Mon, 15 May 2006 18:42:06 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfllO-0000zz-3h for ecrit@ietf.org; Mon, 15 May 2006 18:42:06 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FfllD-0007Xa-L1; Mon, 15 May 2006 17:41:56 -0500 From: "Brian Rosen" To: , "'Ted Hardie'" Subject: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Date: Mon, 15 May 2006 18:41:58 -0400 Message-ID: <064301c67870$c8273200$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 Thread-Index: AcZ4a5hhMAsLfNavR5Gk7XYXCY06+gABIpOg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <4468FAD8.3050306@ntt-at.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: 'Stastny Richard' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Please don't confuse the determination of the appropriate PSAP URI from the resolution of that URI. In most cases, it will probably be best to change the resolution of a URI rather than change the LoST database. I do think it is vital to be able to change the database on short notice, primarily because in disasters, things never go the way you expect, and thus not depending on mapping remaining constant is not a good idea. I do however think that changing the resolution of the URI is more likely to be used to recover from an "under attack" PSAP. I do think getting back a list of secondary URIs (with a q-value) could be useful, but I don't think it's an absolute requirement. I'm not thrilled with "these didn't work, have you got any more?" Brian -----Original Message----- From: Shida Schubert [mailto:shida@ntt-at.com] Sent: Monday, May 15, 2006 6:04 PM To: Ted Hardie Cc: ecrit@ietf.org; Stastny Richard Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt It's good that one can obtain primary and backup URIs, and I personally think the text has really improved. It's not really related but this thread had made me think of a situation where there is a regional disaster or regional scale DoS attack and both primary and backup URIs given by LOST is not reachable? What would happen then? Until propagation is completed to change the data in the database that URIs in the region is not reachable, I am assuming that LOST will always provide the same URI A for the locations A. Thus client will not be able to reach the PSAPs. And because LOST is not stateful it will not provide client with different set of URIs on its second attempt. This might be a deployment/implementation matter and might not be a protocol requirement and I might be the only one concerned, but because LOST is decoupled from the signaling path, it might be good to have a way for LOST clients to request a URI with a list of URIs that it does not want to receive as a resolutions. example: Please provide me with URIs for service A given my location is A but don't provide me with URI A or URI B. Regards Shida Schubert Ted Hardie wrote: > At 10:03 AM -0400 5/9/06, Michael Hammer \(mhammer\) wrote: > >> >From the peanut gallery: >> >> Ma17 and Ma5 still seem to be in conflict. If my contact protocol is >> SIP, how many SIP contacts will be provided overall? Ma17 says 1. Ma5 >> says there can be primary and alternate, that is 2. So, is it 1 or 2, >> or perhaps more if there are multiple overlapping police forces? >> > > I think you're making this harder than you need to. If I send a > query requesting the contact URIs for a specific service based on > my location, I get back one URI per scheme. I may also get > back a URI explicitly marked as a fallback, for use only if I cannot > use the usual contact URIs received (or if I try them and they fail). > So you might get one geographically appropriate SIP URI, one geographically > appropriate SMS URI, and one geographically appropriate XMPP URI. > The fallback SIP URI (if present) is not necessarily as geographically > appropriate; it might point to something like a state-wide response > center. > > Frankly, I think we've wordsmithed this enough. Much more effort > will not produce better instructions to the protocol designers. > regards, > Ted Hardie > > > > > _______________________________________________ > 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 Tue May 16 09:03:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzCC-0006az-NG; Tue, 16 May 2006 09:02:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzCC-0006au-5F for ecrit@ietf.org; Tue, 16 May 2006 09:02:40 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfzCA-0005G7-UW for ecrit@ietf.org; Tue, 16 May 2006 09:02:40 -0400 Received: from [192.168.0.41] (pool-138-89-20-236.mad.east.verizon.net [138.89.20.236]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k4GD2In4023204 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 16 May 2006 09:02:33 -0400 (EDT) In-Reply-To: <44674C91.5080701@gmx.net> References: <32755D354E6B65498C3BD9FD496C7D462C4A36@oefeg-s04.oefeg.loc> <17B88095-EF68-4282-AE10-CAFB74DCBAED@cs.columbia.edu> <44666CDF.4080703@gmx.net> <0164A860-3B72-4DE2-8B65-CF8E92BA5CC9@cs.columbia.edu> <44667653.9060100@gmx.net> <193434C0-BF6E-4A13-9E46-42B1F2B427E8@cs.columbia.edu> <44674C91.5080701@gmx.net> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3B55C5A5-54B6-4174-B648-932FF4CAAA97@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Date: Tue, 16 May 2006 09:02:14 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.749.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Stastny Richard , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org >> One pretty simple solution is to have a four-valued attribute: >> - required --> no service without it; you're legally obligated to >> provide it for this service >> - helpful --> the receiver would like to have this information, >> but isn't going to refuse the call and you're not legally >> obligated; if you route the call yourself, you don't need to >> include it in signaling >> - routing --> the receiver doesn't need it, but it's used to >> route the call >> - ignored --> the receiver will just ignore the location >> information and there's no location-based routing >> I suspect this can be split into two dimensions (routing and end >> system). > Does not sound like a bad idea. > This assumes that these properties do not change on a regular basis > or depend on parameters that cannot be provided by LoST (e.g., user > specific properties). > I suspect that these attributes would be governed by national or state laws and regulations, which presumably change slowly and with advance notice, well outside the anticipated caching intervals for LoST records. > What do other people think? > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 16 09:10:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzJI-0008L5-Vx; Tue, 16 May 2006 09:10:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzJH-0008Jo-SS for ecrit@ietf.org; Tue, 16 May 2006 09:09:59 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfzJE-0005cn-GT for ecrit@ietf.org; Tue, 16 May 2006 09:09:59 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k4GD4dK00819; Tue, 16 May 2006 09:04:39 -0400 (EDT) Received: from [127.0.0.1] ([47.130.17.95] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 09:09:38 -0400 Message-ID: <4469CF0E.2040408@nortel.com> Date: Tue, 16 May 2006 09:09:34 -0400 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline References: <32755D354E6B65498C3BD9FD496C7D462C4A36@oefeg-s04.oefeg.loc><17B88095-EF68-4282-AE10-CAFB74DCBAED@cs.columbia.edu><44666CDF.4080703@gmx.net><0164A860-3B72-4DE2-8B65-CF8E92BA5CC9@cs.columbia.edu><44667653.9060100@gmx.net><193434C0-BF6E-4A13-9E46-42B1F2B427E8@cs.columbia.edu><44674C91.5080701@gmx.net> <3B55C5A5-54B6-4174-B648-932FF4CAAA97@cs.columbia.edu> In-Reply-To: <3B55C5A5-54B6-4174-B648-932FF4CAAA97@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 13:09:38.0067 (UTC) FILETIME=[FC34CE30:01C678E9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Stastny Richard , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Let's back off a moment and consider what this is for. The purpose of the service URN, as far as ECRIT is concerned, is to provide an unambiguous indication that the call should be routed to a PSAP. It's all very well to have attributes whose treatment is defined by local policy, but what about the proxy half-way around the world that has to recognize an emergency call? Henning Schulzrinne wrote: >>> One pretty simple solution is to have a four-valued attribute: >>> - required --> no service without it; you're legally obligated to >>> provide it for this service >>> - helpful --> the receiver would like to have this information, >>> but isn't going to refuse the call and you're not legally >>> obligated; if you route the call yourself, you don't need to >>> include it in signaling >>> - routing --> the receiver doesn't need it, but it's used to >>> route the call >>> - ignored --> the receiver will just ignore the location >>> information and there's no location-based routing >>> I suspect this can be split into two dimensions (routing and end >>> system). >> Does not sound like a bad idea. >> This assumes that these properties do not change on a regular basis >> or depend on parameters that cannot be provided by LoST (e.g., user >> specific properties). >> > > I suspect that these attributes would be governed by national or > state laws and regulations, which presumably change slowly and with > advance notice, well outside the anticipated caching intervals for > LoST records. > > >> What do other people think? >> > > > _______________________________________________ > 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 May 16 09:25:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzYT-0003vu-89; Tue, 16 May 2006 09:25:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzYS-0003vo-7q for ecrit@ietf.org; Tue, 16 May 2006 09:25:40 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfzYP-0006Id-0S for ecrit@ietf.org; Tue, 16 May 2006 09:25:40 -0400 Received: from [192.168.0.41] (pool-138-89-20-236.mad.east.verizon.net [138.89.20.236]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k4GDPZp2007781 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 16 May 2006 09:25:36 -0400 (EDT) In-Reply-To: <4469CF0E.2040408@nortel.com> References: <32755D354E6B65498C3BD9FD496C7D462C4A36@oefeg-s04.oefeg.loc><17B88095-EF68-4282-AE10-CAFB74DCBAED@cs.columbia.edu><44666CDF.4080703@gmx.net><0164A860-3B72-4DE2-8B65-CF8E92BA5CC9@cs.columbia.edu><44667653.9060100@gmx.net><193434C0-BF6E-4A13-9E46-42B1F2B427E8@cs.columbia.edu><44674C91.5080701@gmx.net> <3B55C5A5-54B6-4174-B648-932FF4CAAA97@cs.columbia.edu> <4469CF0E.2040408@nortel.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <783DE65A-5ADB-4C4B-A10A-94D3F0F68592@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Date: Tue, 16 May 2006 09:25:32 -0400 To: "Tom-PT Taylor" X-Mailer: Apple Mail (2.749.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Service URNs indeed serve as identification, both in the end system and in points along the way to the destination. My goal is to hard- code as little as possible, so that we can adjust the system over time, without changing end systems and new protocol specs. The basic idea is that all entities along the way can look up identifiers and determine - what users should dial if they have a twelve-button phone - where to route the call (based on the identifier and location) - whether the call should contain location information - whether the location information should be (or can be) end-to-end encrypted Not all calls may end up in a PSAP (see poison control). On May 16, 2006, at 9:09 AM, Tom-PT Taylor wrote: > Let's back off a moment and consider what this is for. The purpose > of the service URN, as far as ECRIT is concerned, is to provide an > unambiguous indication that the call should be routed to a PSAP. > It's all very well to have attributes whose treatment is defined by > local policy, but what about the proxy half-way around the world > that has to recognize an emergency call? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 16 09:35:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffzi9-0006pf-9g; Tue, 16 May 2006 09:35:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffzi8-0006pa-JS for ecrit@ietf.org; Tue, 16 May 2006 09:35:40 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffzi6-0006kN-7z for ecrit@ietf.org; Tue, 16 May 2006 09:35:40 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Ffzi0-0006m0-Ds; Tue, 16 May 2006 08:35:32 -0500 From: "Brian Rosen" To: "'Tom-PT Taylor'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Date: Tue, 16 May 2006 09:35:33 -0400 Message-ID: <06e701c678ed$9d2ea560$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 Thread-Index: AcZ46hEHRKuP+gnYTa+rxYbuYSbL0AAAgVEg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <4469CF0E.2040408@nortel.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: 'Stastny Richard' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I would say that the service URN defines what service location based routing is needed for. I don't think it should be up to ecrit to define which services location based routing is needed. We're defining a mechanism: put in location and service type (URN) and get out URIs. That's enough for ecrit. We can try to make the organization of the service URN tree structure reflect some sort of common reality, but we are highly unlikely to be always right all of the time. I think it would be a mistake to try to infer any kind of policy decision by the shape of the "urn:service." tree. I don't think that matters. It can be a local policy (or maybe a policy that is associated with the dialstring that is mapped to the service URN) whether this is an "emergency", whether location is forwarded, etc at the location the call originates from. Brian -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortel.com] Sent: Tuesday, May 16, 2006 9:10 AM To: Henning Schulzrinne Cc: Stastny Richard; ecrit@ietf.org Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Let's back off a moment and consider what this is for. The purpose of the service URN, as far as ECRIT is concerned, is to provide an unambiguous indication that the call should be routed to a PSAP. It's all very well to have attributes whose treatment is defined by local policy, but what about the proxy half-way around the world that has to recognize an emergency call? Henning Schulzrinne wrote: >>> One pretty simple solution is to have a four-valued attribute: >>> - required --> no service without it; you're legally obligated to >>> provide it for this service >>> - helpful --> the receiver would like to have this information, >>> but isn't going to refuse the call and you're not legally >>> obligated; if you route the call yourself, you don't need to >>> include it in signaling >>> - routing --> the receiver doesn't need it, but it's used to >>> route the call >>> - ignored --> the receiver will just ignore the location >>> information and there's no location-based routing >>> I suspect this can be split into two dimensions (routing and end >>> system). >> Does not sound like a bad idea. >> This assumes that these properties do not change on a regular basis >> or depend on parameters that cannot be provided by LoST (e.g., user >> specific properties). >> > > I suspect that these attributes would be governed by national or > state laws and regulations, which presumably change slowly and with > advance notice, well outside the anticipated caching intervals for > LoST records. > > >> What do other people think? >> > > > _______________________________________________ > 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 Tue May 16 09:41:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffzne-0000iW-Jb; Tue, 16 May 2006 09:41:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffznd-0000iR-8V for ecrit@ietf.org; Tue, 16 May 2006 09:41:21 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffznc-00071Q-0W for ecrit@ietf.org; Tue, 16 May 2006 09:41:21 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Tue, 16 May 2006 09:41:01 -0400 id 01588015.4469D69C.00006231 Message-ID: <4469D645.2050601@hxr.us> Date: Tue, 16 May 2006 09:40:21 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline References: <06e701c678ed$9d2ea560$640fa8c0@cis.neustar.com> In-Reply-To: <06e701c678ed$9d2ea560$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: 'Stastny Richard' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: > > We can try to make the organization of the service URN tree structure > reflect some sort of common reality, but we are highly unlikely to be always > right all of the time. I think it would be a mistake to try to infer any > kind of policy decision by the shape of the "urn:service." tree. If that is true, then there is likely never a point-in-time when the tree will match reality. And since we are shooting for global interoperability here, perhaps we should just stop with sos. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 16 09:42:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffzof-0000vF-4o; Tue, 16 May 2006 09:42:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffzoe-0000vA-7O for ecrit@ietf.org; Tue, 16 May 2006 09:42:24 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffzoc-000772-US for ecrit@ietf.org; Tue, 16 May 2006 09:42:24 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k4GDgKM17455; Tue, 16 May 2006 09:42:20 -0400 (EDT) Received: from [127.0.0.1] ([47.130.17.95] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 09:42:19 -0400 Message-ID: <4469D6B7.1080304@nortel.com> Date: Tue, 16 May 2006 09:42:15 -0400 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline References: <32755D354E6B65498C3BD9FD496C7D462C4A36@oefeg-s04.oefeg.loc><17B88095-EF68-4282-AE10-CAFB74DCBAED@cs.columbia.edu><44666CDF.4080703@gmx.net><0164A860-3B72-4DE2-8B65-CF8E92BA5CC9@cs.columbia.edu><44667653.9060100@gmx.net><193434C0-BF6E-4A13-9E46-42B1F2B427E8@cs.columbia.edu><44674C91.5080701@gmx.net> <3B55C5A5-54B6-4174-B648-932FF4CAAA97@cs.columbia.edu> <4469CF0E.2040408@nortel.com> <783DE65A-5ADB-4C4B-A10A-94D3F0F68592@cs.columbia.edu> In-Reply-To: <783DE65A-5ADB-4C4B-A10A-94D3F0F68592@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 13:42:19.0174 (UTC) FILETIME=[8D1DFC60:01C678EE] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org My starting point is ECRIT's requirement, I thought. Originally that was for some way to mark a call to indicate that it was an emergency call. I just finished reading the first part of section 6 of the requirements document and can hardly recognize it. I can't quite understand the current intention. Is it: (a) that the client passes the identifier in the mapping request and gets back a URI appropriate to that identifier, so that the mapping database becomes more general-purpose than just to locate PSAPs; or (b) that the mapping response includes an identifier to be appended to the call; or (c) something else? Henning Schulzrinne wrote: > Service URNs indeed serve as identification, both in the end system > and in points along the way to the destination. My goal is to hard- > code as little as possible, so that we can adjust the system over > time, without changing end systems and new protocol specs. > > The basic idea is that all entities along the way can look up > identifiers and determine > > - what users should dial if they have a twelve-button phone > - where to route the call (based on the identifier and location) > - whether the call should contain location information > - whether the location information should be (or can be) end-to-end > encrypted > > Not all calls may end up in a PSAP (see poison control). > > On May 16, 2006, at 9:09 AM, Tom-PT Taylor wrote: > >> Let's back off a moment and consider what this is for. The purpose >> of the service URN, as far as ECRIT is concerned, is to provide an >> unambiguous indication that the call should be routed to a PSAP. >> It's all very well to have attributes whose treatment is defined by >> local policy, but what about the proxy half-way around the world >> that has to recognize an emergency call? > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 16 10:33:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0c6-00071U-SC; Tue, 16 May 2006 10:33:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0c5-00071P-Um for ecrit@ietf.org; Tue, 16 May 2006 10:33:29 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg0c4-0000u2-BQ for ecrit@ietf.org; Tue, 16 May 2006 10:33:29 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 16 May 2006 10:33:28 -0400 X-IronPort-AV: i="4.05,134,1146456000"; d="scan'208"; a="88662739:sNHT31525340" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4GEXRTL022197; Tue, 16 May 2006 10:33:27 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 10:33:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Date: Tue, 16 May 2006 10:33:26 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301769D6A@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Thread-Index: AcZ47pOK9tcWi+/KTmKKrM0E0W/rZwABqnVw From: "Michael Hammer \(mhammer\)" To: "Tom-PT Taylor" , "Henning Schulzrinne" X-OriginalArrivalTime: 16 May 2006 14:33:27.0712 (UTC) FILETIME=[B21BBA00:01C678F5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org BTW, is the URN intended to stay with the message all the way to the UAS (PSAP)? If so, how is that accomplished? Also, if there are B2BUA (e.g. SBC) along the way, how is this accomplished? =20 I don't think B2BUA behavior is specified anywhere. If not, nevermind. Mike=20 > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortel.com]=20 > Sent: Tuesday, May 16, 2006 9:42 AM > To: Henning Schulzrinne > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03=20 > Child helpline >=20 > My starting point is ECRIT's requirement, I thought.=20 > Originally that was for some way to mark a call to indicate=20 > that it was an emergency call. I just finished reading the=20 > first part of section 6 of the requirements document and can=20 > hardly recognize it. >=20 > I can't quite understand the current intention. Is it: >=20 > (a) that the client passes the identifier in the mapping=20 > request and gets back a URI appropriate to that identifier,=20 > so that the mapping database becomes more general-purpose=20 > than just to locate PSAPs; or >=20 > (b) that the mapping response includes an identifier to be=20 > appended to the call; or >=20 > (c) something else? >=20 > Henning Schulzrinne wrote: > > Service URNs indeed serve as identification, both in the end system=20 > > and in points along the way to the destination. My goal is to hard-=20 > > code as little as possible, so that we can adjust the system over=20 > > time, without changing end systems and new protocol specs. > >=20 > > The basic idea is that all entities along the way can look up=20 > > identifiers and determine > >=20 > > - what users should dial if they have a twelve-button phone > > - where to route the call (based on the identifier and location) > > - whether the call should contain location information > > - whether the location information should be (or can be) end-to-end=20 > > encrypted > >=20 > > Not all calls may end up in a PSAP (see poison control). > >=20 > > On May 16, 2006, at 9:09 AM, Tom-PT Taylor wrote: > >=20 > >> Let's back off a moment and consider what this is for. The=20 > purpose of=20 > >> the service URN, as far as ECRIT is concerned, is to provide an=20 > >> unambiguous indication that the call should be routed to a PSAP. > >> It's all very well to have attributes whose treatment is=20 > defined by=20 > >> local policy, but what about the proxy half-way around the=20 > world that=20 > >> has to recognize an emergency call? > >=20 > >=20 > >=20 >=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 Tue May 16 10:48:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0qS-0002PR-I9; Tue, 16 May 2006 10:48:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0qR-0002PM-L9 for ecrit@ietf.org; Tue, 16 May 2006 10:48:19 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg0qP-0001wE-D0 for ecrit@ietf.org; Tue, 16 May 2006 10:48:19 -0400 Received: from lion.cs.columbia.edu (IDENT:BW4lKOaQ/+Ym7FlK5jNgcGTTYmzbNCmm@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k4GEm7X6026068 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 16 May 2006 10:48:07 -0400 (EDT) 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 k4GEm3BB030401 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 16 May 2006 10:48:07 -0400 Message-ID: <4469E61E.4080107@cs.columbia.edu> Date: Tue, 16 May 2006 10:47:58 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline References: <06e701c678ed$9d2ea560$640fa8c0@cis.neustar.com> In-Reply-To: <06e701c678ed$9d2ea560$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='__CP_NAME_BODY 0, __CP_NAME_SUBJ 0, __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: cf4fa59384e76e63313391b70cd0dd25 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > We can try to make the organization of the service URN tree structure > reflect some sort of common reality, but we are highly unlikely to be always > right all of the time. I think it would be a mistake to try to infer any > kind of policy decision by the shape of the "urn:service." tree. > I think we're at least talking past each other. The whole point of my suggestion was to avoid "inferring any kind of policy decision by the shape of the ... tree". Rather, each party should be able to look up what the local provider of the service needs or wants (or feels legally entitled to), so that the client can make a choice whether and how to use the service. Consider this to be the policy equivalent of auto-configuration, rather than hard-configuring choices forever and everywhere. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 16 10:58:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0zt-0005Xd-9m; Tue, 16 May 2006 10:58:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0zs-0005XY-BO for ecrit@ietf.org; Tue, 16 May 2006 10:58:04 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg0zs-0002a8-43 for ecrit@ietf.org; Tue, 16 May 2006 10:58:04 -0400 Received: from lion.cs.columbia.edu (IDENT:Bdt8EATVwaQxRkqakX5dQKjVqtQ2nt+D@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k4GEw1X6028460 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 16 May 2006 10:58:01 -0400 (EDT) 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 k4GEw1BB031030 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 16 May 2006 10:58:01 -0400 Message-ID: <4469E873.6000304@cs.columbia.edu> Date: Tue, 16 May 2006 10:57:55 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Tom-PT Taylor Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline References: <32755D354E6B65498C3BD9FD496C7D462C4A36@oefeg-s04.oefeg.loc><17B88095-EF68-4282-AE10-CAFB74DCBAED@cs.columbia.edu><44666CDF.4080703@gmx.net><0164A860-3B72-4DE2-8B65-CF8E92BA5CC9@cs.columbia.edu><44667653.9060100@gmx.net><193434C0-BF6E-4A13-9E46-42B1F2B427E8@cs.columbia.edu><44674C91.5080701@gmx.net> <3B55C5A5-54B6-4174-B648-932FF4CAAA97@cs.columbia.edu> <4469CF0E.2040408@nortel.com> <783DE65A-5ADB-4C4B-A10A-94D3F0F68592@cs.columbia.edu> <4469D6B7.1080304@nortel.com> In-Reply-To: <4469D6B7.1080304@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_NAME_BODY 0, __CP_NAME_SUBJ 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_419_TINHORN 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: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Certainly (a). In addition, the SIP (or other protocol) request is marked with the identifier. How this is done obviously depends on the protocol, so the URN document is silent on this aspect. The idea is to use the Request-URI for the URN and Route headers for the PSAP. The URN would be inserted either by the UA or by the outbound proxy if the dial string is recognized by that outbound proxy. This would presumably also work with various B2BUAs. Henning Tom-PT Taylor wrote: > My starting point is ECRIT's requirement, I thought. Originally that was > for some way to mark a call to indicate that it was an emergency call. I > just finished reading the first part of section 6 of the requirements > document and can hardly recognize it. > > I can't quite understand the current intention. Is it: > > (a) that the client passes the identifier in the mapping request and > gets back a URI appropriate to that identifier, so that the mapping > database becomes more general-purpose than just to locate PSAPs; or > > (b) that the mapping response includes an identifier to be appended to > the call; or > > (c) something else? > > Henning Schulzrinne wrote: >> Service URNs indeed serve as identification, both in the end system >> and in points along the way to the destination. My goal is to hard- >> code as little as possible, so that we can adjust the system over >> time, without changing end systems and new protocol specs. >> >> The basic idea is that all entities along the way can look up >> identifiers and determine >> >> - what users should dial if they have a twelve-button phone >> - where to route the call (based on the identifier and location) >> - whether the call should contain location information >> - whether the location information should be (or can be) end-to-end >> encrypted >> >> Not all calls may end up in a PSAP (see poison control). >> >> On May 16, 2006, at 9:09 AM, Tom-PT Taylor wrote: >> >>> Let's back off a moment and consider what this is for. The purpose >>> of the service URN, as far as ECRIT is concerned, is to provide an >>> unambiguous indication that the call should be routed to a PSAP. >>> It's all very well to have attributes whose treatment is defined by >>> local policy, but what about the proxy half-way around the world >>> that has to recognize an emergency call? >> >> >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 16 10:59:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg114-0005p7-UP; Tue, 16 May 2006 10:59:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg114-0005p2-DX for ecrit@ietf.org; Tue, 16 May 2006 10:59:18 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg113-0002dO-2G for ecrit@ietf.org; Tue, 16 May 2006 10:59:18 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Fg10w-0004kx-6a; Tue, 16 May 2006 09:59:11 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Tom-PT Taylor'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Date: Tue, 16 May 2006 10:59:10 -0400 Message-ID: <070401c678f9$4c705d60$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 Thread-Index: AcZ47pOK9tcWi+/KTmKKrM0E0W/rZwABqnVwAAC5HkA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301769D6A@xmb-rtp-20b.amer.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Jonathan proposed that it be put in a Route header. It would stay in that Route header all the way to the PSAP. It may at some point, also be in a To: (but often it wouldn't; you would have a dialstring there), it may occur in a Request-URI (specifically, between the element that recognized the dialstring and turned it into the service urn and the element that does the LoST dip if those elements are different). Brian -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Tuesday, May 16, 2006 10:33 AM To: Tom-PT Taylor; Henning Schulzrinne Cc: ecrit@ietf.org Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline BTW, is the URN intended to stay with the message all the way to the UAS (PSAP)? If so, how is that accomplished? Also, if there are B2BUA (e.g. SBC) along the way, how is this accomplished? I don't think B2BUA behavior is specified anywhere. If not, nevermind. Mike > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortel.com] > Sent: Tuesday, May 16, 2006 9:42 AM > To: Henning Schulzrinne > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 > Child helpline > > My starting point is ECRIT's requirement, I thought. > Originally that was for some way to mark a call to indicate > that it was an emergency call. I just finished reading the > first part of section 6 of the requirements document and can > hardly recognize it. > > I can't quite understand the current intention. Is it: > > (a) that the client passes the identifier in the mapping > request and gets back a URI appropriate to that identifier, > so that the mapping database becomes more general-purpose > than just to locate PSAPs; or > > (b) that the mapping response includes an identifier to be > appended to the call; or > > (c) something else? > > Henning Schulzrinne wrote: > > Service URNs indeed serve as identification, both in the end system > > and in points along the way to the destination. My goal is to hard- > > code as little as possible, so that we can adjust the system over > > time, without changing end systems and new protocol specs. > > > > The basic idea is that all entities along the way can look up > > identifiers and determine > > > > - what users should dial if they have a twelve-button phone > > - where to route the call (based on the identifier and location) > > - whether the call should contain location information > > - whether the location information should be (or can be) end-to-end > > encrypted > > > > Not all calls may end up in a PSAP (see poison control). > > > > On May 16, 2006, at 9:09 AM, Tom-PT Taylor wrote: > > > >> Let's back off a moment and consider what this is for. The > purpose of > >> the service URN, as far as ECRIT is concerned, is to provide an > >> unambiguous indication that the call should be routed to a PSAP. > >> It's all very well to have attributes whose treatment is > defined by > >> local policy, but what about the proxy half-way around the > world that > >> has to recognize an emergency call? > > > > > > > > > _______________________________________________ > 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 Tue May 16 11:05:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg16f-000769-OG; Tue, 16 May 2006 11:05:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg16d-000764-UM for ecrit@ietf.org; Tue, 16 May 2006 11:05:03 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg16d-0002rW-Mz for ecrit@ietf.org; Tue, 16 May 2006 11:05:03 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Fg16W-0005tM-Tw; Tue, 16 May 2006 10:04:57 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Date: Tue, 16 May 2006 11:04:58 -0400 Message-ID: <070501c678fa$1b072cd0$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 Thread-Index: AcZ498EvntSKB7joTzuwaoeScQvtqwAAcO/Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <4469E61E.4080107@cs.columbia.edu> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Actually, I thought I was agreeing with you: > The basic idea is that all entities along the way can look up identifiers and determine I thought that meant the LoST operation that did dialstring to service URN for a location returned policy for that service at that location. I was asserting that trying to get policy out of where in the service tree you were was not a good idea, because Child Help may be an emergency (sos) in some parts of the world and human services, not an emergency in others. Whether it goes in service.sos or service.human shouldn't infer whether it's an emergency or not. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Tuesday, May 16, 2006 10:48 AM To: Brian Rosen Cc: ecrit@ietf.org Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline > We can try to make the organization of the service URN tree structure > reflect some sort of common reality, but we are highly unlikely to be always > right all of the time. I think it would be a mistake to try to infer any > kind of policy decision by the shape of the "urn:service." tree. > I think we're at least talking past each other. The whole point of my suggestion was to avoid "inferring any kind of policy decision by the shape of the ... tree". Rather, each party should be able to look up what the local provider of the service needs or wants (or feels legally entitled to), so that the client can make a choice whether and how to use the service. Consider this to be the policy equivalent of auto-configuration, rather than hard-configuring choices forever and everywhere. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 16 13:28:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg3Kv-0007lK-85; Tue, 16 May 2006 13:27:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg3Ku-0007lF-Fc for ecrit@ietf.org; Tue, 16 May 2006 13:27:56 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg3Kt-0002r3-7b for ecrit@ietf.org; Tue, 16 May 2006 13:27:56 -0400 Received: from lion.cs.columbia.edu (IDENT:k0b9cyDtC3RLcmxXGYYBqmPKdSACxKei@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k4GHRpX6011070 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 16 May 2006 13:27:51 -0400 (EDT) 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 k4GHRoBB010719 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 16 May 2006 13:27:51 -0400 Message-ID: <446A0B91.6080002@cs.columbia.edu> Date: Tue, 16 May 2006 13:27:45 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline References: <070501c678fa$1b072cd0$640fa8c0@cis.neustar.com> In-Reply-To: <070501c678fa$1b072cd0$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='__CP_NAME_BODY 0, __CP_NAME_SUBJ 0, __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: 8abaac9e10c826e8252866cbe6766464 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: > Actually, I thought I was agreeing with you: >> The basic idea is that all entities along the way can look up identifiers > and determine Glad to hear that; sorry I misunderstood. > > I thought that meant the LoST operation that did dialstring to service URN > for a location returned policy for that service at that location. Indeed. The LoST operation would presumably return policy either when looking up the dial string or when determining the destination. In almost all cases, these will be the same scopes and lifetimes, but one could theoretically imagine that they have separate scope ("By Vermont state law, you don't have to provide location information when dialing 911". Obviously made up). > > I was asserting that trying to get policy out of where in the service tree > you were was not a good idea, because Child Help may be an emergency (sos) > in some parts of the world and human services, not an emergency in others. > Whether it goes in service.sos or service.human shouldn't infer whether it's > an emergency or not. We're indeed in full agreement on this point. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 16 13:47:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg3dZ-0004da-M8; Tue, 16 May 2006 13:47:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg3dX-0004cG-QY for ecrit@ietf.org; Tue, 16 May 2006 13:47:11 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg3dW-0003wJ-H2 for ecrit@ietf.org; Tue, 16 May 2006 13:47:11 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k4GHl7M03272; Tue, 16 May 2006 13:47:07 -0400 (EDT) Received: from [127.0.0.1] ([47.130.17.95] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 13:47:06 -0400 Message-ID: <446A1014.4010203@nortel.com> Date: Tue, 16 May 2006 13:47:00 -0400 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline References: <070501c678fa$1b072cd0$640fa8c0@cis.neustar.com> In-Reply-To: <070501c678fa$1b072cd0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 17:47:07.0045 (UTC) FILETIME=[BFC53D50:01C67910] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I obviously haven't been paying attention. LoST is taking dial strings as arguments?? Brian Rosen wrote: ... > > I thought that meant the LoST operation that did dialstring to service URN > for a location returned policy for that service at that location. > ... > > Brian > ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 17 17:50:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgTuU-0003gY-Dx; Wed, 17 May 2006 17:50:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgTuT-0003eR-5Y for ecrit@ietf.org; Wed, 17 May 2006 17:50:25 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgTuQ-0005Gx-Tx for ecrit@ietf.org; Wed, 17 May 2006 17:50:25 -0400 Received: from s73602 (unknown[71.56.187.251]) by comcast.net (rwcrmhc11) with SMTP id <20060517215022m11009e4ire>; Wed, 17 May 2006 21:50:22 +0000 Message-ID: <087c01c679fb$e47d0ab0$6e087c0a@china.huawei.com> From: "Spencer Dawkins" To: References: <070501c678fa$1b072cd0$640fa8c0@cis.neustar.com> <446A1014.4010203@nortel.com> Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Date: Wed, 17 May 2006 16:50:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Having looked at this yesterday, "dialstring" is part of the LoST RESPONSE example in the current LoST draft, not part of the request, so I think we are confused here (which may be as simple as the LoST draft being out of phase with what people think, or may be something else)... Please check my math in draft-hardie-ecrit-lost-00.txt. Comments? It's "location *to* service translation", right? :-) Thanks, Spencer >I obviously haven't been paying attention. LoST is taking dial strings as >arguments?? > > Brian Rosen wrote: > ... >> >> I thought that meant the LoST operation that did dialstring to service >> URN >> for a location returned policy for that service at that location. >> > ... >> >> Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 17 17:56:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgU0G-0006Rg-S7; Wed, 17 May 2006 17:56:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgU0F-0006Rb-Pg for ecrit@ietf.org; Wed, 17 May 2006 17:56:23 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgU0E-0005dm-JR for ecrit@ietf.org; Wed, 17 May 2006 17:56:23 -0400 Received: from lion.cs.columbia.edu (IDENT:VJLBBmtA0OIWig/cuQOQ2UbFBbx/rA1F@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k4HLuKX6025421 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 17 May 2006 17:56:20 -0400 (EDT) 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 k4HLuJBB014776 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 17 May 2006 17:56:19 -0400 Message-ID: <446B9BFE.80209@cs.columbia.edu> Date: Wed, 17 May 2006 17:56:14 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Spencer Dawkins Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline References: <070501c678fa$1b072cd0$640fa8c0@cis.neustar.com> <446A1014.4010203@nortel.com> <087c01c679fb$e47d0ab0$6e087c0a@china.huawei.com> In-Reply-To: <087c01c679fb$e47d0ab0$6e087c0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_NAME_BODY 0, __CP_NAME_SUBJ 0, __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: cf4fa59384e76e63313391b70cd0dd25 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org LoST maps location and service URN to a set of answers. Thus, you have query to LoST: "I'm in Tokyo, Japan and interested in the fire brigade" response: "Your dialstring is XYZ and the PSAP URL is fire@emergency.tokyo.jp" Spencer Dawkins wrote: > Having looked at this yesterday, "dialstring" is part of the LoST > RESPONSE example in the current LoST draft, not part of the request, so > I think we are confused here (which may be as simple as the LoST draft > being out of phase with what people think, or may be something else)... > > Please check my math in draft-hardie-ecrit-lost-00.txt. > > Comments? It's "location *to* service translation", right? :-) _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 17 18:50:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUq6-00045C-5I; Wed, 17 May 2006 18:49:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUq4-000457-T5 for ecrit@ietf.org; Wed, 17 May 2006 18:49:56 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgUq3-0008RW-Ge for ecrit@ietf.org; Wed, 17 May 2006 18:49:56 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 17 May 2006 15:49:52 -0700 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: Commments I.D-ecrit-service-urn-03 Child helpline Date: Wed, 17 May 2006 15:49:51 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657504F2CBCE@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Thread-Index: AcZ5/OIFYZsLwYqsT4SOMmRKjMV9TAAAEeVw From: "Roger Marshall" To: "Henning Schulzrinne" , "Spencer Dawkins" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org As used for emergency services, I assume LoST produces the following outputs: A. ) given location as input, LoST returns service identifier (e.g. urn:service:sos) B. ) given location + service identifier as input, LoST returns PSAP URI C. ) given location + service identifier as input, LoST returns PSAP URI + dial string D. ) given location + service identifier as input, LoST returns PSAP URI + dial string + PSAP_preference_info Are there more cases? Roger Marshall >-----Original Message----- >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 >Sent: Wednesday, May 17, 2006 2:56 PM >To: Spencer Dawkins >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03=20 >Child helpline > >LoST maps location and service URN to a set of answers. Thus, you have > >query to LoST: "I'm in Tokyo, Japan and interested in the fire brigade" > >response: "Your dialstring is XYZ and the PSAP URL is=20 >fire@emergency.tokyo.jp" > >Spencer Dawkins wrote: >> Having looked at this yesterday, "dialstring" is part of the LoST=20 >> RESPONSE example in the current LoST draft, not part of the request,=20 >> so I think we are confused here (which may be as simple as the LoST=20 >> draft being out of phase with what people think, or may be=20 >something else)... >>=20 >> Please check my math in draft-hardie-ecrit-lost-00.txt. >>=20 >> Comments? It's "location *to* service translation", right? :-) > >_______________________________________________ >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 May 17 19:00:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgV0F-0008NB-KI; Wed, 17 May 2006 19:00:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgV0E-0008HR-9s for ecrit@ietf.org; Wed, 17 May 2006 19:00:26 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgV0D-0000bN-VA for ecrit@ietf.org; Wed, 17 May 2006 19:00:26 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4HN0Bb0030090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 May 2006 16:00:12 -0700 Received: from [129.46.225.88] (dhcp-campbell-28.qualcomm.com [129.46.225.88]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4HN08ll001793; Wed, 17 May 2006 16:00:09 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <8C837214C95C864C9F34F3635C2A657504F2CBCE@SEA-EXCHVS-2.telecomsys.com> References: <8C837214C95C864C9F34F3635C2A657504F2CBCE@SEA-EXCHVS-2.telecomsys.com> Date: Wed, 17 May 2006 16:00:04 -0700 To: "Roger Marshall" , "Henning Schulzrinne" , "Spencer Dawkins" From: Ted Hardie Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 3:49 PM -0700 5/17/06, Roger Marshall wrote: >As used for emergency services, I assume LoST produces the following >outputs: > >A. ) given location as input, LoST returns service identifier (e.g. >urn:service:sos) I don't think I understand this. You want the LoST server to return the supported service identifiers in response to a query containing only location? >B. ) given location + service identifier as input, LoST returns PSAP URI >C. ) given location + service identifier as input, LoST returns PSAP URI >+ dial string >D. ) given location + service identifier as input, LoST returns PSAP URI >+ dial string + PSAP_preference_info Is PSAP_preference_info the same as a fallback PSAP, or something else? >Are there more cases? > >Roger Marshall > >>-----Original Message----- >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>Sent: Wednesday, May 17, 2006 2:56 PM >>To: Spencer Dawkins >>Cc: ecrit@ietf.org >>Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 >>Child helpline >> >>LoST maps location and service URN to a set of answers. Thus, you have >> >>query to LoST: "I'm in Tokyo, Japan and interested in the fire brigade" >> >>response: "Your dialstring is XYZ and the PSAP URL is >>fire@emergency.tokyo.jp" >> >>Spencer Dawkins wrote: >>> Having looked at this yesterday, "dialstring" is part of the LoST >>> RESPONSE example in the current LoST draft, not part of the request, >>> so I think we are confused here (which may be as simple as the LoST >>> draft being out of phase with what people think, or may be >>something else)... >>> >>> Please check my math in draft-hardie-ecrit-lost-00.txt. >>> >>> Comments? It's "location *to* service translation", right? :-) >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >> > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 17 19:11:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVAx-0001bf-Of; Wed, 17 May 2006 19:11:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVAw-0001ba-WB for ecrit@ietf.org; Wed, 17 May 2006 19:11:31 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgVAw-0001Om-J8 for ecrit@ietf.org; Wed, 17 May 2006 19:11:30 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 17 May 2006 16:11:25 -0700 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: Commments I.D-ecrit-service-urn-03 Child helpline Date: Wed, 17 May 2006 16:11:24 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657504F2CC14@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Thread-Index: AcZ6BbESug2yRhKSTkKcawJ3Fs10YwAAEaqg From: "Roger Marshall" To: "Ted Hardie" , "Henning Schulzrinne" , "Spencer Dawkins" X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Ted: Please see my responses inline.=20 >-----Original Message----- >From: Ted Hardie [mailto:hardie@qualcomm.com]=20 >Sent: Wednesday, May 17, 2006 4:00 PM >To: Roger Marshall; Henning Schulzrinne; Spencer Dawkins >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03=20 >Child helpline > >At 3:49 PM -0700 5/17/06, Roger Marshall wrote: >>As used for emergency services, I assume LoST produces the following >>outputs: >> >>A. ) given location as input, LoST returns service identifier (e.g. >>urn:service:sos) > >I don't think I understand this. You want the LoST server to=20 >return the supported service identifiers in response to a=20 >query containing only location? > Yes. If location is all you've got, then why not? At the very least, LoST could return the universal emergency service identifier, "urn:service:sos". > > >>B. ) given location + service identifier as input, LoST returns PSAP=20 >>URI C. ) given location + service identifier as input, LoST returns=20 >>PSAP URI >>+ dial string >>D. ) given location + service identifier as input, LoST returns PSAP=20 >>URI >>+ dial string + PSAP_preference_info > >Is PSAP_preference_info the same as a fallback PSAP, or something else? I'm loosely referring to what has been discussed on the list recently, wrt the idea that some UAS' will_require/won't_require/won't_accept a location object to be provided with the call, for example. =20 -roger. > > >>Are there more cases? >> >>Roger Marshall >> >>>-----Original Message----- >>>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>Sent: Wednesday, May 17, 2006 2:56 PM >>>To: Spencer Dawkins >>>Cc: ecrit@ietf.org >>>Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child=20 >>>helpline >>> >>>LoST maps location and service URN to a set of answers.=20 >Thus, you have >>> >>>query to LoST: "I'm in Tokyo, Japan and interested in the=20 >fire brigade" >>> >>>response: "Your dialstring is XYZ and the PSAP URL is=20 >>>fire@emergency.tokyo.jp" >>> >>>Spencer Dawkins wrote: >>>> Having looked at this yesterday, "dialstring" is part of the LoST=20 >>>> RESPONSE example in the current LoST draft, not part of=20 >the request,=20 >>>> so I think we are confused here (which may be as simple as=20 >the LoST=20 >>>> draft being out of phase with what people think, or may be >>>something else)... >>>> >>>> Please check my math in draft-hardie-ecrit-lost-00.txt. >>>> >>>> Comments? It's "location *to* service translation", right? :-) >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ecrit >>> >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 17 19:18:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVHG-0004u8-AE; Wed, 17 May 2006 19:18:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVHF-0004u3-I8 for ecrit@ietf.org; Wed, 17 May 2006 19:18:01 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgVHD-0001cQ-7W for ecrit@ietf.org; Wed, 17 May 2006 19:18:01 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FgVH0-0005Dj-Ca; Wed, 17 May 2006 18:17:46 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Roger Marshall'" , "'Henning Schulzrinne'" , "'Spencer Dawkins'" Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Date: Wed, 17 May 2006 19:17:51 -0400 Message-ID: <029901c67a08$20c05340$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ6Bb2JiB4L3vUCSKqKOf9kOEpHAgAAhaLw In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I hadn't thought about it before, but it does make sense to return a list of all the service identifiers that LoST could return a URI for. I'm not so sure about PSAP preference info. Normally, I would expect to get that in the INVITE response. Is there something outside of that you think would be interesting? What? How is it represented? Brian -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com] Sent: Wednesday, May 17, 2006 7:00 PM To: Roger Marshall; Henning Schulzrinne; Spencer Dawkins Cc: ecrit@ietf.org Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline At 3:49 PM -0700 5/17/06, Roger Marshall wrote: >As used for emergency services, I assume LoST produces the following >outputs: > >A. ) given location as input, LoST returns service identifier (e.g. >urn:service:sos) I don't think I understand this. You want the LoST server to return the supported service identifiers in response to a query containing only location? >B. ) given location + service identifier as input, LoST returns PSAP URI >C. ) given location + service identifier as input, LoST returns PSAP URI >+ dial string >D. ) given location + service identifier as input, LoST returns PSAP URI >+ dial string + PSAP_preference_info Is PSAP_preference_info the same as a fallback PSAP, or something else? >Are there more cases? > >Roger Marshall > >>-----Original Message----- >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>Sent: Wednesday, May 17, 2006 2:56 PM >>To: Spencer Dawkins >>Cc: ecrit@ietf.org >>Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 >>Child helpline >> >>LoST maps location and service URN to a set of answers. Thus, you have >> >>query to LoST: "I'm in Tokyo, Japan and interested in the fire brigade" >> >>response: "Your dialstring is XYZ and the PSAP URL is >>fire@emergency.tokyo.jp" >> >>Spencer Dawkins wrote: >>> Having looked at this yesterday, "dialstring" is part of the LoST >>> RESPONSE example in the current LoST draft, not part of the request, >>> so I think we are confused here (which may be as simple as the LoST >>> draft being out of phase with what people think, or may be >>something else)... >>> >>> Please check my math in draft-hardie-ecrit-lost-00.txt. >>> >>> Comments? It's "location *to* service translation", right? :-) >> >>_______________________________________________ >>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 Wed May 17 19:24:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVN8-0008Ts-Di; Wed, 17 May 2006 19:24:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVN7-0008Tm-4a for ecrit@ietf.org; Wed, 17 May 2006 19:24:05 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgVN4-0001lB-SK for ecrit@ietf.org; Wed, 17 May 2006 19:24:05 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 18:24:14 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 17 May 2006 18:24:13 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 18:23:59 -0500 Message-ID: From: "Thomson, Martin" To: "Roger Marshall" , "Ted Hardie" , "Henning Schulzrinne" , "Spencer Dawkins" Date: Wed, 17 May 2006 18:23:30 -0500 Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 17 May 2006 23:23:59.0516 (UTC) FILETIME=[F9C14DC0:01C67A08] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <8C837214C95C864C9F34F3635C2A657504F2CC14@SEA-EXCHVS-2.telecomsys.com> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Thread-Index: AcZ6BbESug2yRhKSTkKcawJ3Fs10YwAAEaqgAAB/vHA= X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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="===============0699053453==" Errors-To: ecrit-bounces@ietf.org --===============0699053453== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message V2hlbiBkbyB5b3UgdGhpbmsgdGhhdCBhIExvU1QgY2xpZW50IHdpbGwgbm90IGtub3cgYWJvdXQg dXJuOnNlcnZpY2U6c29zPw0KDQpJJ2QgcmVjb21tZW5kIGFnYWluc3QgdGhpcy4gIEEgZGVjaXNp b24gd2FzIG1hZGUgaW4gRE5TIG5vdCB0byBwcm92aWRlIGEgd2F5IHRvIHF1ZXJ5IGZvciBpbmRl eGVzLiAgVGhpcyBpcyBzaW1pbGFyLiAgR2l2ZW4gYW4gYXJiaXRyYXJpbHkgbGFyZ2UgbnVtYmVy IG9mIHBvc3NpYmxlIHNlcnZpY2VzIHlvdSBlbmQgdXAgd2l0aCBhcmJpdHJhcmlseSBsYXJnZSBy ZXNwb25zZXMuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9nZXIg TWFyc2hhbGwgW21haWx0bzpSTWFyc2hhbGxAdGVsZWNvbXN5cy5jb21dDQo+IFNlbnQ6IFRodXJz ZGF5LCAxOCBNYXkgMjAwNiA5OjExIEFNDQo+IFRvOiBUZWQgSGFyZGllOyBIZW5uaW5nIFNjaHVs enJpbm5lOyBTcGVuY2VyIERhd2tpbnMNCj4gQ2M6IGVjcml0QGlldGYub3JnDQo+IFN1YmplY3Q6 IFJFOiBbRWNyaXRdIFJlOiBDb21tbWVudHMgSS5ELWVjcml0LXNlcnZpY2UtdXJuLTAzIENoaWxk IGhlbHBsaW5lDQo+IA0KPiBUZWQ6DQo+IFBsZWFzZSBzZWUgbXkgcmVzcG9uc2VzIGlubGluZS4N Cj4gDQo+ID4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+RnJvbTogVGVkIEhhcmRpZSBb bWFpbHRvOmhhcmRpZUBxdWFsY29tbS5jb21dDQo+ID5TZW50OiBXZWRuZXNkYXksIE1heSAxNywg MjAwNiA0OjAwIFBNDQo+ID5UbzogUm9nZXIgTWFyc2hhbGw7IEhlbm5pbmcgU2NodWx6cmlubmU7 IFNwZW5jZXIgRGF3a2lucw0KPiA+Q2M6IGVjcml0QGlldGYub3JnDQo+ID5TdWJqZWN0OiBSRTog W0Vjcml0XSBSZTogQ29tbW1lbnRzIEkuRC1lY3JpdC1zZXJ2aWNlLXVybi0wMw0KPiA+Q2hpbGQg aGVscGxpbmUNCj4gPg0KPiA+QXQgMzo0OSBQTSAtMDcwMCA1LzE3LzA2LCBSb2dlciBNYXJzaGFs bCB3cm90ZToNCj4gPj5BcyB1c2VkIGZvciBlbWVyZ2VuY3kgc2VydmljZXMsIEkgYXNzdW1lIExv U1QgcHJvZHVjZXMgdGhlIGZvbGxvd2luZw0KPiA+Pm91dHB1dHM6DQo+ID4+DQo+ID4+QS4gKSBn aXZlbiBsb2NhdGlvbiBhcyBpbnB1dCwgTG9TVCByZXR1cm5zIHNlcnZpY2UgaWRlbnRpZmllciAo ZS5nLg0KPiA+PnVybjpzZXJ2aWNlOnNvcykNCj4gPg0KPiA+SSBkb24ndCB0aGluayBJIHVuZGVy c3RhbmQgdGhpcy4gIFlvdSB3YW50IHRoZSBMb1NUIHNlcnZlciB0bw0KPiA+cmV0dXJuIHRoZSBz dXBwb3J0ZWQgc2VydmljZSBpZGVudGlmaWVycyBpbiByZXNwb25zZSB0byBhDQo+ID5xdWVyeSBj b250YWluaW5nIG9ubHkgbG9jYXRpb24/DQo+ID4NCj4gDQo+IFllcy4gIElmIGxvY2F0aW9uIGlz IGFsbCB5b3UndmUgZ290LCB0aGVuIHdoeSBub3Q/ICBBdCB0aGUgdmVyeSBsZWFzdCwNCj4gTG9T VCBjb3VsZCByZXR1cm4gdGhlIHVuaXZlcnNhbCBlbWVyZ2VuY3kgc2VydmljZSBpZGVudGlmaWVy LA0KPiAidXJuOnNlcnZpY2U6c29zIi4NCj4gDQo+ID4NCj4gPg0KPiA+PkIuICkgZ2l2ZW4gbG9j YXRpb24gKyBzZXJ2aWNlIGlkZW50aWZpZXIgYXMgaW5wdXQsIExvU1QgcmV0dXJucyBQU0FQDQo+ ID4+VVJJIEMuICkgZ2l2ZW4gbG9jYXRpb24gKyBzZXJ2aWNlIGlkZW50aWZpZXIgYXMgaW5wdXQs IExvU1QgcmV0dXJucw0KPiA+PlBTQVAgVVJJDQo+ID4+KyBkaWFsIHN0cmluZw0KPiA+PkQuICkg Z2l2ZW4gbG9jYXRpb24gKyBzZXJ2aWNlIGlkZW50aWZpZXIgYXMgaW5wdXQsIExvU1QgcmV0dXJu cyBQU0FQDQo+ID4+VVJJDQo+ID4+KyBkaWFsIHN0cmluZyArIFBTQVBfcHJlZmVyZW5jZV9pbmZv DQo+ID4NCj4gPklzIFBTQVBfcHJlZmVyZW5jZV9pbmZvIHRoZSBzYW1lIGFzIGEgZmFsbGJhY2sg UFNBUCwgb3Igc29tZXRoaW5nIGVsc2U/DQo+IA0KPiBJJ20gbG9vc2VseSByZWZlcnJpbmcgdG8g d2hhdCBoYXMgYmVlbiBkaXNjdXNzZWQgb24gdGhlIGxpc3QgcmVjZW50bHksDQo+IHdydCB0aGUg aWRlYSB0aGF0IHNvbWUgVUFTJyB3aWxsX3JlcXVpcmUvd29uJ3RfcmVxdWlyZS93b24ndF9hY2Nl cHQgYQ0KPiBsb2NhdGlvbiBvYmplY3QgdG8gYmUgcHJvdmlkZWQgd2l0aCB0aGUgY2FsbCwgZm9y IGV4YW1wbGUuDQo+IA0KPiAtcm9nZXIuDQo+IA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVu dCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVy d2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRo ZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hp Yml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJd --===============0699053453== 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 --===============0699053453==-- From ecrit-bounces@ietf.org Wed May 17 19:27:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVQS-0000xH-QG; Wed, 17 May 2006 19:27:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVQR-0000xC-Kf for ecrit@ietf.org; Wed, 17 May 2006 19:27:31 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgVQR-00020V-8Y for ecrit@ietf.org; Wed, 17 May 2006 19:27:31 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 17 May 2006 16:27:29 -0700 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] Review of draft-ietf-ecrit-requirements-08.txt Date: Wed, 17 May 2006 16:27:28 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657504F2CC49@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt Thread-Index: AcZzfYzLIYqYRCsTQZ2rlCKgcJCKDwABDvwQAaHUx0A= From: "Roger Marshall" To: "Michael Hammer \(mhammer\)" , "Ted Hardie" , "Stastny Richard" , "Hannes Tschofenig" , , "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Michael: I've done some minor rewording and some additional reordering, which may make this more clear. You'll see it in the next published version in the next couple days. The use of "contact" and "contact method" are not representative of the SIP Contact header. Thx. Roger Marshall. >-----Original Message----- >From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 >Sent: Tuesday, May 09, 2006 9:02 AM >To: Ted Hardie; Stastny Richard; Roger Marshall; Hannes=20 >Tschofenig; ecrit@ietf.org; Henning Schulzrinne >Subject: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt > >Ted, > >I am just telling you that I read the words and they appeared=20 >self-contradictory to me. > >Mike >=20 > >> -----Original Message----- >> From: Ted Hardie [mailto:hardie@qualcomm.com] >> Sent: Tuesday, May 09, 2006 11:30 AM >> To: Michael Hammer (mhammer); Stastny Richard; Roger=20 >Marshall; Hannes=20 >> Tschofenig; ecrit@ietf.org; Henning Schulzrinne >> Subject: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt >>=20 >> At 10:03 AM -0400 5/9/06, Michael Hammer \(mhammer\) wrote: >> > >From the peanut gallery: >> > >> >Ma17 and Ma5 still seem to be in conflict. If my contact >> protocol is >> >SIP, how many SIP contacts will be provided overall? Ma17 >> says 1. Ma5 >> >says there can be primary and alternate, that is 2. So, is >> it 1 or 2, >> >or perhaps more if there are multiple overlapping police forces? >>=20 >> I think you're making this harder than you need to. If I=20 >send a query=20 >> requesting the contact URIs for a specific service based on my=20 >> location, I get back one URI per scheme. >> I may also get back a URI explicitly marked as a fallback, for use=20 >> only if I cannot use the usual contact URIs received (or if=20 >I try them=20 >> and they fail). >> So you might get one geographically appropriate SIP URI, one=20 >> geographically appropriate SMS URI, and one geographically=20 >appropriate=20 >> XMPP URI. >> The fallback SIP URI (if present) is not necessarily as=20 >geographically=20 >> appropriate; it might point to something like a state-wide response=20 >> center. >>=20 >> Frankly, I think we've wordsmithed this enough. Much more=20 >effort will=20 >> not produce better instructions to the protocol designers. >> regards, >> Ted Hardie >>=20 >>=20 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 17 19:40:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVcj-0000No-Rk; Wed, 17 May 2006 19:40:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVcj-0000Nj-E0 for ecrit@ietf.org; Wed, 17 May 2006 19:40:13 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgVch-0002yV-3q for ecrit@ietf.org; Wed, 17 May 2006 19:40:13 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 17 May 2006 16:40:09 -0700 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: Commments I.D-ecrit-service-urn-03 Child helpline Date: Wed, 17 May 2006 16:40:09 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657504F2CC62@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Thread-Index: AcZ6Bb2JiB4L3vUCSKqKOf9kOEpHAgAAhaLwAABs3NA= From: "Roger Marshall" To: "Brian Rosen" , "Ted Hardie" , "Henning Schulzrinne" , "Spencer Dawkins" X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org PSAP_preference_info is likely to be more static than dynamic in nature. Not so much that this PSAP is 'dark' due to an outage, (though maybe we want think about this in terms beyond a single fallback PSAP), but more descriptive of how this PSAP differs from the next PSAP, for example: A classic case may be to differentiate between a user's predetermined desire to only invoke an emergency response from the Capital Police vs. the District police when in D.C., or a parent's want to avoid the Disney Security and instead get Orange County Police on the scene after a tragedy, etc. In cases like these, jurisdictional boundaries often blur. -roger. >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net]=20 >Sent: Wednesday, May 17, 2006 4:18 PM >To: 'Ted Hardie'; Roger Marshall; 'Henning Schulzrinne';=20 >'Spencer Dawkins' >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03=20 >Child helpline > >I hadn't thought about it before, but it does make sense to=20 >return a list of all the service identifiers that LoST could=20 >return a URI for. > >I'm not so sure about PSAP preference info. Normally, I would=20 >expect to get that in the INVITE response. Is there something=20 >outside of that you think would be interesting? What? How is=20 >it represented? > >Brian > >-----Original Message----- >From: Ted Hardie [mailto:hardie@qualcomm.com] >Sent: Wednesday, May 17, 2006 7:00 PM >To: Roger Marshall; Henning Schulzrinne; Spencer Dawkins >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03=20 >Child helpline > >At 3:49 PM -0700 5/17/06, Roger Marshall wrote: >>As used for emergency services, I assume LoST produces the following >>outputs: >> >>A. ) given location as input, LoST returns service identifier (e.g. >>urn:service:sos) > >I don't think I understand this. You want the LoST server to=20 >return the supported service identifiers in response to a=20 >query containing only location? > > > >>B. ) given location + service identifier as input, LoST returns PSAP=20 >>URI C. ) given location + service identifier as input, LoST returns=20 >>PSAP URI >>+ dial string >>D. ) given location + service identifier as input, LoST returns PSAP=20 >>URI >>+ dial string + PSAP_preference_info > >Is PSAP_preference_info the same as a fallback PSAP, or something else? > > >>Are there more cases? >> >>Roger Marshall >> >>>-----Original Message----- >>>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>Sent: Wednesday, May 17, 2006 2:56 PM >>>To: Spencer Dawkins >>>Cc: ecrit@ietf.org >>>Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child=20 >>>helpline >>> >>>LoST maps location and service URN to a set of answers.=20 >Thus, you have >>> >>>query to LoST: "I'm in Tokyo, Japan and interested in the=20 >fire brigade" >>> >>>response: "Your dialstring is XYZ and the PSAP URL is=20 >>>fire@emergency.tokyo.jp" >>> >>>Spencer Dawkins wrote: >>>> Having looked at this yesterday, "dialstring" is part of the LoST=20 >>>> RESPONSE example in the current LoST draft, not part of=20 >the request,=20 >>>> so I think we are confused here (which may be as simple as=20 >the LoST=20 >>>> draft being out of phase with what people think, or may be >>>something else)... >>>> >>>> Please check my math in draft-hardie-ecrit-lost-00.txt. >>>> >>>> Comments? It's "location *to* service translation", right? :-) >>> >>>_______________________________________________ >>>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 Wed May 17 19:52:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVnz-0005Bc-25; Wed, 17 May 2006 19:51:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVny-00057i-Bs for ecrit@ietf.org; Wed, 17 May 2006 19:51:50 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgVnx-0003d3-4t for ecrit@ietf.org; Wed, 17 May 2006 19:51:50 -0400 Received: from [192.168.0.41] (pool-138-89-20-236.mad.east.verizon.net [138.89.20.236]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k4HNpYOt025092 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 17 May 2006 19:51:37 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Date: Wed, 17 May 2006 19:51:29 -0400 To: "Thomson, Martin" X-Mailer: Apple Mail (2.749.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > I'd recommend against this. A decision was made in DNS not to > provide a way to query for indexes. This is similar. Given an > arbitrarily large number of possible services you end up with > arbitrarily large responses. And since LoST can be used beyond just urn:service:sos, the list of services could indeed be fairly large, depending on how the urn:service: hierarchy evolves. However, unlike DNS, the restrictions on query size aren't as relevant. It might be possible to have a more restricted listing, such as listing sub-services for a particular service, so that a client can automatically determine whether there are separate dial strings for fire and police, say. The alternative is that the client polls for every possible emergency service it knows about, which seems much worse and also makes adding services later very hard. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 17 19:52:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVp4-0005j6-G5; Wed, 17 May 2006 19:52:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVp2-0005j1-Ow for ecrit@ietf.org; Wed, 17 May 2006 19:52:56 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgVp2-0003hi-C0 for ecrit@ietf.org; Wed, 17 May 2006 19:52:56 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 17 May 2006 16:52:55 -0700 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: Commments I.D-ecrit-service-urn-03 Child helpline Date: Wed, 17 May 2006 16:52:54 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657504F2CC7F@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Thread-Index: AcZ6BbESug2yRhKSTkKcawJ3Fs10YwAAEaqgAAB/vHAAAN0VQA== From: "Roger Marshall" To: "Thomson, Martin" , "Ted Hardie" , "Henning Schulzrinne" , "Spencer Dawkins" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Right after the the end device is deployed, but right before the LoST server is deployed - that's one case... Agree that the universal case poses few problems, but what happens when the device crosses into a jurisdiction which handles service types differently? For example, a user invokes a setup routine, based on location (plus maybe something additional, like the string "fire"), LoST could return urn:service:sos.fire while visiting Japan, whereas returns urn:service:sos when back in the U.S.=20 Roger Marshall >-----Original Message----- >From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]=20 >Sent: Wednesday, May 17, 2006 4:24 PM >To: Roger Marshall; Ted Hardie; Henning Schulzrinne; Spencer Dawkins >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03=20 >Child helpline > >When do you think that a LoST client will not know about=20 >urn:service:sos? > >I'd recommend against this. A decision was made in DNS not to=20 >provide a way to query for indexes. This is similar. Given=20 >an arbitrarily large number of possible services you end up=20 >with arbitrarily large responses. > >> -----Original Message----- >> From: Roger Marshall [mailto:RMarshall@telecomsys.com] >> Sent: Thursday, 18 May 2006 9:11 AM >> To: Ted Hardie; Henning Schulzrinne; Spencer Dawkins >> Cc: ecrit@ietf.org >> Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child=20 >> helpline >>=20 >> Ted: >> Please see my responses inline. >>=20 >> >-----Original Message----- >> >From: Ted Hardie [mailto:hardie@qualcomm.com] >> >Sent: Wednesday, May 17, 2006 4:00 PM >> >To: Roger Marshall; Henning Schulzrinne; Spencer Dawkins >> >Cc: ecrit@ietf.org >> >Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child=20 >> >helpline >> > >> >At 3:49 PM -0700 5/17/06, Roger Marshall wrote: >> >>As used for emergency services, I assume LoST produces the=20 >following >> >>outputs: >> >> >> >>A. ) given location as input, LoST returns service identifier (e.g. >> >>urn:service:sos) >> > >> >I don't think I understand this. You want the LoST server=20 >to return=20 >> >the supported service identifiers in response to a query containing=20 >> >only location? >> > >>=20 >> Yes. If location is all you've got, then why not? At the=20 >very least,=20 >> LoST could return the universal emergency service identifier,=20 >> "urn:service:sos". >>=20 >> > >> > >> >>B. ) given location + service identifier as input, LoST=20 >returns PSAP=20 >> >>URI C. ) given location + service identifier as input,=20 >LoST returns=20 >> >>PSAP URI >> >>+ dial string >> >>D. ) given location + service identifier as input, LoST=20 >returns PSAP=20 >> >>URI >> >>+ dial string + PSAP_preference_info >> > >> >Is PSAP_preference_info the same as a fallback PSAP, or=20 >something else? >>=20 >> I'm loosely referring to what has been discussed on the list=20 >recently,=20 >> wrt the idea that some UAS'=20 >will_require/won't_require/won't_accept a=20 >> location object to be provided with the call, for example. >>=20 >> -roger. >>=20 >--------------------------------------------------------------- >--------------------------------- >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 May 17 20:05:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgW0v-0002RD-77; Wed, 17 May 2006 20:05:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgW0u-0002R8-CU for ecrit@ietf.org; Wed, 17 May 2006 20:05:12 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgW0s-0004Is-1G for ecrit@ietf.org; Wed, 17 May 2006 20:05:12 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4I04pNx004904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 May 2006 17:04:51 -0700 Received: from [129.46.225.88] (dhcp-campbell-28.qualcomm.com [129.46.225.88]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4I04mFU022535; Wed, 17 May 2006 17:04:49 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 17 May 2006 17:04:48 -0700 To: Henning Schulzrinne , "Thomson, Martin" From: Ted Hardie Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 7:51 PM -0400 5/17/06, Henning Schulzrinne wrote: >>I'd recommend against this. A decision was made in DNS not to provide a way to query for indexes. This is similar. Given an arbitrarily large number of possible services you end up with arbitrarily large responses. > >And since LoST can be used beyond just urn:service:sos, the list of services could indeed be fairly large, depending on how the urn:service: hierarchy evolves. However, unlike DNS, the restrictions on query size aren't as relevant. It might be possible to have a more restricted listing, such as listing sub-services for a particular service, so that a client can automatically determine whether there are separate dial strings for fire and police, say. The alternative is that the client polls for every possible emergency service it knows about, which seems much worse and also makes adding services later very hard. > >Henning If this functionality is desired at all, I feel strongly that it not be the result of sending a simple "location/no service" query. If someone sent a location with no urn, I would far rather that be sent the response for urn:service:sos, with the service urn populated in the response. To me, that's the "default response" for an emergency service lookup. Even that is broken--we should ensure that LoST clients know at least urn:service:sos, but it is the right "be liberal in what you accept" response to brokenness. At best, the returning of a list causes a round trip before the client selects a service to request, and I don't want additional round trips when my car is on fire. Assuming that it is not the default response, but is a query for "what URNs do you support", I would agree that having it as a protocol mechanism might be useful. But I would not in deployment, I would suggest that it be one of the first things turned off during a DoS or other attack indicator. And I wouldn't be upset at finding some service providers never turning it on. regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 17 20:05:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgW1S-0002mP-JX; Wed, 17 May 2006 20:05:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgW1Q-0002mK-VY for ecrit@ietf.org; Wed, 17 May 2006 20:05:44 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgW1P-0004JY-OA for ecrit@ietf.org; Wed, 17 May 2006 20:05:44 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 19:05:57 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 17 May 2006 19:05:56 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 19:05:41 -0500 Message-ID: From: "Thomson, Martin" To: "Henning Schulzrinne" Date: Wed, 17 May 2006 19:05:19 -0500 Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 18 May 2006 00:05:41.0864 (UTC) FILETIME=[CD454E80:01C67A0E] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Thread-Index: AcZ6DOWO6kZSGHg1SEyxxoGKx9KFSQAARGtA X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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="===============1041094999==" Errors-To: ecrit-bounces@ietf.org --===============1041094999== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message SSBkb24ndCBoYXZlIGEgcHJvYmxlbSB3aXRoIGFza2luZyBmb3Igc3ViLXNlcnZpY2VzLiAgRm9y IGluc3RhbmNlLCBJIGtub3cgYWJvdXQgdXJuOnNlcnZpY2U6bWFzc2FnZSwgYnV0IEkgbWlnaHQg bGlrZSB0byBrbm93IHRoYXQgdXJuOnNlcnZpY2U6bWFzc2FnZS5zd2VkaXNoIGV4aXN0cy4gIFRo YXQncyB2YWx1YWJsZS4NCg0KT2YgY291cnNlLCB0aGUgYWR2YW50YWdlIHdpdGggd2hhdCB3ZSBo YXZlIGN1cnJlbnRseSBpcyB0aGF0IHRoaXMgZmVhdHVyZSBjYW4gYmUgYWRkZWQgbGF0ZXIuICBJ ZiBpdCBpc24ndCBuZWNlc3NhcnksIHRoZW4gd2UgY2FuIGxlYXZlIGl0IHVudGlsIHdlIGRvbid0 IGhhdmUgbW9yZSBwcmVzc2luZyBwcm9ibGVtcyB0byBhZGRyZXNzLg0KDQpROiBJZiBJIHRyeSB0 byByZXNvbHZlIHVybjpzZXJ2aWNlOnNvcy5maXJlIGFuZCBpdCBkb2Vzbid0IGV4aXN0LCBjYW4g dGhlIExvU1Qgc2VydmVyIHVuaWxhdGVyYWxseSByZXR1cm4gdGhlIHJlc3VsdCBmb3IgdXJuOnNl cnZpY2U6c29zPw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEhlbm5p bmcgU2NodWx6cmlubmUgW21haWx0bzpoZ3NAY3MuY29sdW1iaWEuZWR1XQ0KPiBTZW50OiBUaHVy c2RheSwgMTggTWF5IDIwMDYgOTo1MSBBTQ0KPiBUbzogVGhvbXNvbiwgTWFydGluDQo+IENjOiBS b2dlciBNYXJzaGFsbDsgVGVkIEhhcmRpZTsgU3BlbmNlciBEYXdraW5zOyBlY3JpdEBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSZTogW0Vjcml0XSBSZTogQ29tbW1lbnRzIEkuRC1lY3JpdC1zZXJ2aWNl LXVybi0wMyBDaGlsZCBoZWxwbGluZQ0KPiANCj4gPg0KPiA+IEknZCByZWNvbW1lbmQgYWdhaW5z dCB0aGlzLiAgQSBkZWNpc2lvbiB3YXMgbWFkZSBpbiBETlMgbm90IHRvDQo+ID4gcHJvdmlkZSBh IHdheSB0byBxdWVyeSBmb3IgaW5kZXhlcy4gIFRoaXMgaXMgc2ltaWxhci4gIEdpdmVuIGFuDQo+ ID4gYXJiaXRyYXJpbHkgbGFyZ2UgbnVtYmVyIG9mIHBvc3NpYmxlIHNlcnZpY2VzIHlvdSBlbmQg dXAgd2l0aA0KPiA+IGFyYml0cmFyaWx5IGxhcmdlIHJlc3BvbnNlcy4NCj4gDQo+IEFuZCBzaW5j ZSBMb1NUIGNhbiBiZSB1c2VkIGJleW9uZCBqdXN0IHVybjpzZXJ2aWNlOnNvcywgdGhlIGxpc3Qg b2YNCj4gc2VydmljZXMgY291bGQgaW5kZWVkIGJlIGZhaXJseSBsYXJnZSwgZGVwZW5kaW5nIG9u IGhvdyB0aGUNCj4gdXJuOnNlcnZpY2U6IGhpZXJhcmNoeSBldm9sdmVzLiBIb3dldmVyLCB1bmxp a2UgRE5TLCB0aGUgcmVzdHJpY3Rpb25zDQo+IG9uIHF1ZXJ5IHNpemUgYXJlbid0IGFzIHJlbGV2 YW50LiBJdCBtaWdodCBiZSBwb3NzaWJsZSB0byBoYXZlIGEgbW9yZQ0KPiByZXN0cmljdGVkIGxp c3RpbmcsIHN1Y2ggYXMgbGlzdGluZyBzdWItc2VydmljZXMgZm9yIGEgcGFydGljdWxhcg0KPiBz ZXJ2aWNlLCBzbyB0aGF0IGEgY2xpZW50IGNhbiBhdXRvbWF0aWNhbGx5IGRldGVybWluZSB3aGV0 aGVyIHRoZXJlDQo+IGFyZSBzZXBhcmF0ZSBkaWFsIHN0cmluZ3MgZm9yIGZpcmUgYW5kIHBvbGlj ZSwgc2F5LiBUaGUgYWx0ZXJuYXRpdmUNCj4gaXMgdGhhdCB0aGUgY2xpZW50IHBvbGxzIGZvciBl dmVyeSBwb3NzaWJsZSBlbWVyZ2VuY3kgc2VydmljZSBpdA0KPiBrbm93cyBhYm91dCwgd2hpY2gg c2VlbXMgbXVjaCB3b3JzZSBhbmQgYWxzbyBtYWtlcyBhZGRpbmcgc2VydmljZXMNCj4gbGF0ZXIg dmVyeSBoYXJkLg0KPiANCj4gSGVubmluZw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50 IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3 aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhl IG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGli aXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0= --===============1041094999== 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 --===============1041094999==-- From ecrit-bounces@ietf.org Wed May 17 20:13:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgW8Z-00053c-6h; Wed, 17 May 2006 20:13:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgW8X-00053X-U3 for ecrit@ietf.org; Wed, 17 May 2006 20:13:05 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgW8V-0004fn-N7 for ecrit@ietf.org; Wed, 17 May 2006 20:13:05 -0400 Received: from [192.168.0.41] (pool-138-89-20-236.mad.east.verizon.net [138.89.20.236]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k4I0D2cK027140 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 17 May 2006 20:13:03 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5A3C112C-A68B-4296-9F7B-FE3F86004F05@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Date: Wed, 17 May 2006 20:12:01 -0400 To: "Thomson, Martin" X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On May 17, 2006, at 8:05 PM, Thomson, Martin wrote: > I don't have a problem with asking for sub-services. For instance, > I know about urn:service:massage, but I might like to know that > urn:service:massage.swedish exists. That's valuable. > > Of course, the advantage with what we have currently is that this > feature can be added later. If it isn't necessary, then we can > leave it until we don't have more pressing problems to address. Indeed - that's a separate query. > > Q: If I try to resolve urn:service:sos.fire and it doesn't exist, > can the LoST server unilaterally return the result for > urn:service:sos? I suppose, as a hint, although I'm a bit worried about the complexity once you generalize this. Imagine that we have more than two levels of service descriptions (urn:service:sos.fire.cats_in_trees). Should the result include the whole tree above the (non-existing) service? I think a better approach is to have the client do the "list subservices" query, and then query for those subservices. Less guesswork and special cases. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 17 20:33:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgWS0-0005HP-Ps; Wed, 17 May 2006 20:33:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgWRy-0005HJ-S4 for ecrit@ietf.org; Wed, 17 May 2006 20:33:10 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgWRx-0005St-Jn for ecrit@ietf.org; Wed, 17 May 2006 20:33:10 -0400 Received: from [192.168.0.41] (pool-138-89-20-236.mad.east.verizon.net [138.89.20.236]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k4I0X4er028838 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 17 May 2006 20:33:04 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Date: Wed, 17 May 2006 20:33:02 -0400 To: Ted Hardie X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ecrit@ietf.org, "Thomson, Martin" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > If this functionality is desired at all, I feel strongly that it > not be the result of > sending a simple "location/no service" query. If someone sent a > location with > Definitely - this should be a separate query. I don't believe in "let me guess what you meant and good luck figuring out what to do with the response" protocols. > no urn, I would far rather that be sent the response for > urn:service:sos, with > the service urn populated in the response. To me, that's the > "default response" > for an emergency service lookup. > > Even that is broken--we should ensure that LoST clients know at least > urn:service:sos, but it is the right "be liberal in what you > accept" response > to brokenness. At best, the returning of a list causes a round > trip before > the client selects a service to request, and I don't want > additional round > trips when my car is on fire. Any "list services" queries would be done on boot (when configuring dial strings and such), not when routing a call. > > Assuming that it is not the default response, but is a query for > "what URNs do you > support", I would agree that having it as a protocol mechanism > might be > useful. But I would not in deployment, I would suggest that it be > one of the first > things turned off during a DoS or other attack indicator. And I > wouldn't > be upset at finding some service providers never turning it on. > > regards, > Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu May 18 05:41:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgezt-0000cg-64; Thu, 18 May 2006 05:40:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgezr-0000cY-6f for ecrit@ietf.org; Thu, 18 May 2006 05:40:43 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fgezn-0003RK-Ln for ecrit@ietf.org; Thu, 18 May 2006 05:40:43 -0400 Received: (qmail invoked by alias); 18 May 2006 09:40:26 -0000 Received: from unknown (EHLO [10.75.119.218]) [212.247.138.166] by mail.gmx.net (mp035) with SMTP; 18 May 2006 11:40:26 +0200 X-Authenticated: #29516787 Message-ID: <446C410B.7040005@gmx.net> Date: Thu, 18 May 2006 11:40:27 +0200 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.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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: , Errors-To: ecrit-bounces@ietf.org Hi all, Roger compiled a new draft update. Please find it here: http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-09.txt Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu May 18 09:10:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgiGS-0006gt-3K; Thu, 18 May 2006 09:10:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgiGQ-0006go-PH for ecrit@ietf.org; Thu, 18 May 2006 09:10:02 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FgiGM-0000I4-9j for ecrit@ietf.org; Thu, 18 May 2006 09:10:02 -0400 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] Re: Commments I.D-ecrit-service-urn-03 Child helpline Date: Thu, 18 May 2006 15:09:18 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A4A@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Thread-Index: AcZ5/OIFYZsLwYqsT4SOMmRKjMV9TAAAEeVwAB/G5kI= From: "Stastny Richard" To: "Roger Marshall" , "Henning Schulzrinne" , "Spencer Dawkins" X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I like this approach some questions =20 In A.) it is service identifier(s) should not PSAP preference returned always? =20 The dial string should be a specific query =20 Richard ________________________________ Von: Roger Marshall [mailto:RMarshall@telecomsys.com] Gesendet: Do 18.05.2006 00:49 An: Henning Schulzrinne; Spencer Dawkins Cc: ecrit@ietf.org Betreff: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child = helpline As used for emergency services, I assume LoST produces the following outputs: A. ) given location as input, LoST returns service identifier (e.g. urn:service:sos) B. ) given location + service identifier as input, LoST returns PSAP URI C. ) given location + service identifier as input, LoST returns PSAP URI + dial string D. ) given location + service identifier as input, LoST returns PSAP URI + dial string + PSAP_preference_info Are there more cases? Roger Marshall >-----Original Message----- >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >Sent: Wednesday, May 17, 2006 2:56 PM >To: Spencer Dawkins >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 >Child helpline > >LoST maps location and service URN to a set of answers. Thus, you have > >query to LoST: "I'm in Tokyo, Japan and interested in the fire brigade" > >response: "Your dialstring is XYZ and the PSAP URL is >fire@emergency.tokyo.jp" > >Spencer Dawkins wrote: >> Having looked at this yesterday, "dialstring" is part of the LoST >> RESPONSE example in the current LoST draft, not part of the request, >> so I think we are confused here (which may be as simple as the LoST >> draft being out of phase with what people think, or may be >something else)... >> >> Please check my math in draft-hardie-ecrit-lost-00.txt. >> >> Comments? It's "location *to* service translation", right? :-) > >_______________________________________________ >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 May 18 14:21:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgn7H-0006I6-56; Thu, 18 May 2006 14:20:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgn7G-0006I0-IZ for ecrit@ietf.org; Thu, 18 May 2006 14:20:54 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgn7G-0001xK-9S for ecrit@ietf.org; Thu, 18 May 2006 14:20:54 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 18 May 2006 11:20:54 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,142,1146466800"; d="scan'208"; a="28331769:sNHT23534840" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4IIKlTL002120; Thu, 18 May 2006 14:20:47 -0400 (EDT) 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, 18 May 2006 14:20:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Date: Thu, 18 May 2006 14:20:45 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E58F4@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline Thread-Index: AcZ6ErVXN1olK+dbT4awLxcNLVT1lQAk5BcA From: "Michael Hammer \(mhammer\)" To: "Henning Schulzrinne" , "Ted Hardie" X-OriginalArrivalTime: 18 May 2006 18:20:46.0969 (UTC) FILETIME=[C890AE90:01C67AA7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ecrit@ietf.org, "Thomson, Martin" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Ummm... I don't boot my cell phone every time I cross an SP or jurisdictional boundary. There seems to be a potential danger here of too much success. What if a query without URN results in a phone book size list of service URNs? Much more than I might have configured memory for? Better maybe to have urn:service:sos as the default or let the first query be urn:service:top or * to fetch the next level below service. I also didn't understand the need for two RTT. If you tell me there is urn:service:sos why not also provide the PSAP URI at the same time? That is, options A-D collapse to one: Input: location + URN (default to urn:service:sos) Ouput: URN + [PSAP] URI/dialstring + preference info=20 If just intending to browse the tree: Input: location + "urn:service:*" Ouput: list of next level: URN + URI/dialstring + preference info=20 Mike > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > Sent: Wednesday, May 17, 2006 8:33 PM > To: Ted Hardie > Cc: ecrit@ietf.org; Thomson, Martin > Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03=20 > Child helpline >=20 > > > > If this functionality is desired at all, I feel strongly=20 > that it not=20 > > be the result of sending a simple "location/no service" query. If=20 > > someone sent a location with > > >=20 > Definitely - this should be a separate query. I don't believe=20 > in "let me guess what you meant and good luck figuring out=20 > what to do with the response" protocols. >=20 > > no urn, I would far rather that be sent the response for=20 > > urn:service:sos, with the service urn populated in the=20 > response. To=20 > > me, that's the "default response" > > for an emergency service lookup. > > > > Even that is broken--we should ensure that LoST clients=20 > know at least=20 > > urn:service:sos, but it is the right "be liberal in what=20 > you accept"=20 > > response to brokenness. At best, the returning of a list causes a=20 > > round trip before the client selects a service to request,=20 > and I don't=20 > > want additional round trips when my car is on fire. >=20 > Any "list services" queries would be done on boot (when=20 > configuring dial strings and such), not when routing a call. >=20 >=20 > > > > Assuming that it is not the default response, but is a=20 > query for "what=20 > > URNs do you support", I would agree that having it as a protocol=20 > > mechanism might be useful. But I would not in deployment, I would=20 > > suggest that it be one of the first things turned off=20 > during a DoS or=20 > > other attack indicator. And I wouldn't be upset at finding some=20 > > service providers never turning it on. > > > > regards, > > Ted Hardie >=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 May 18 15:59:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgoeP-0000Xs-1d; Thu, 18 May 2006 15:59:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgoeL-0000T9-4o; Thu, 18 May 2006 15:59:09 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgoVV-0000CS-Jk; Thu, 18 May 2006 15:50:01 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k4IJo11I030168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FgoVV-0008Fz-DO; Thu, 18 May 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 18 May 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-requirements-09.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Requirements for Emergency Context Resolution with Internet Technologies Author(s) : H. Schulzrinne, R. Marshall Filename : draft-ietf-ecrit-requirements-09.txt Pages : 31 Date : 2006-5-18 This document enumerates requirements for the context resolution of emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-requirements-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-requirements-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-18115308.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-requirements-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-requirements-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-18115308.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Thu May 18 16:28:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgp6J-0003Dv-1Q; Thu, 18 May 2006 16:28:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgp6H-0003CI-BX for ecrit@ietf.org; Thu, 18 May 2006 16:28:01 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgp6F-0003dh-Ts for ecrit@ietf.org; Thu, 18 May 2006 16:28:01 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 18 May 2006 13:27:56 -0700 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: [Ecrit] New requirements draft -09 available Date: Thu, 18 May 2006 13:27:55 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657504F2D16A@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] New requirements draft -09 available Thread-Index: AcZjHoDHs0ywPyz2ToyZkOt5wehbuwAmhpYQAAImwPAAL1+Y4AAESMAwAmxcSiADEJnqEA== From: "Roger Marshall" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Here's a summary of changes for the new edition of the ECRIT requirements draft, recently submitted to the I-D editor.=20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-09.txt A diff version of this is available at: http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-requirements/ This new version contains changes which are generally described below: A. Quite a bit of renumbering and reordering has been done with both the terminology section and the various requirements. B. Received review comments from Hannes (5/12) & a few others. Tried to incorporate all or respond with reasons why, if not. C. Rewording of Introduction section, paragraph 6, etc. talking about identifiers. D. Tried to clean up confusion around terminology. For example, replaced the term 'emergency identifier' with 'emergency service identifier'. E. In light of the ecrit-service-urn draft, added some new terms & defns, such as: Service identifier (examples include: urn:service:info or a tel URI, etc.) Service URN (an implementation of above, namely conforms to the example urn:service:*) Emergency service identifier ((ESI), from the set of service identifiers, context=3Demergency services only, with examples of urn:service:sos or a tel URI) Emergency service URN (an implementation of an ESI, example is urn:service:sos, urn:service:sos.fire, etc. - also sometimes referred to as an 'sos service URN') (In the last case of an emergency service URN, I don't like to have two names for the same thing, but felt that this name was preferable, rather than use 'sos service URN'.) F. Updated the issues in the issues tracker (http://www.ietf-ecrit.org:8080/ecrit-req/index): Only a few issues remain. Since some rewording changes we made, these are still left to age (i.e., time for comment). Issues which I have left open are:=20 #52 protocol specific, end devices out of scope - reworded to make more general/=20 #35 Location Validation - removed 1 existing, 2 of the new requirements, marked 'done'/=20 #38 Ma5. URI alternate contact - some rewording + renumbered now as Ma9, marked 'done'/=20 #39 Ma6. URL properties - replacement of URL with URI, renumbered as Ma11, marked 'done'/=20 #52 will be marked as "Resolved" after several days, assuming no objections arise from the list. G. No new issues have been logged. H. Removed requirements Id4, "Prevention of Fraud, based on review comment that it be covered within the security draft. I. Added IANA section to draft. Roger Marshall. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu May 18 17:26:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgq0c-0003n9-GC; Thu, 18 May 2006 17:26:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgq0a-0003mz-LE for ecrit@ietf.org; Thu, 18 May 2006 17:26:12 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgq0Z-0007gY-AV for ecrit@ietf.org; Thu, 18 May 2006 17:26:12 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Fgq0Q-0003FK-C3; Thu, 18 May 2006 16:26:02 -0500 From: "Brian Rosen" To: "'Roger Marshall'" , Subject: RE: [Ecrit] New requirements draft -09 available Date: Thu, 18 May 2006 17:26:06 -0400 Message-ID: <03ef01c67ac1$ae903140$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZjHoDHs0ywPyz2ToyZkOt5wehbuwAmhpYQAAImwPAAL1+Y4AAESMAwAmxcSiADEJnqEAAPXmqQ In-Reply-To: <8C837214C95C864C9F34F3635C2A657504F2D16A@SEA-EXCHVS-2.telecomsys.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Roger Thank you for all your work on this. Can we be done now? We are clearly over the line when we make a change to the requirements in light of a draft for the solution (service urn). We need to get this document out now, because we're not helping the solution, we're just polishing the apple. I respectfully ask that we complete WGLC, and any further comments be subject to a "does this REALLY matter now" test. The best quality requirements documents are always written after the product is in the market, but those don't help the implementation team much. Brian -----Original Message----- From: Roger Marshall [mailto:RMarshall@telecomsys.com] Sent: Thursday, May 18, 2006 4:28 PM To: ecrit@ietf.org Subject: [Ecrit] New requirements draft -09 available Here's a summary of changes for the new edition of the ECRIT requirements draft, recently submitted to the I-D editor. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-09.txt A diff version of this is available at: http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-requirements/ This new version contains changes which are generally described below: A. Quite a bit of renumbering and reordering has been done with both the terminology section and the various requirements. B. Received review comments from Hannes (5/12) & a few others. Tried to incorporate all or respond with reasons why, if not. C. Rewording of Introduction section, paragraph 6, etc. talking about identifiers. D. Tried to clean up confusion around terminology. For example, replaced the term 'emergency identifier' with 'emergency service identifier'. E. In light of the ecrit-service-urn draft, added some new terms & defns, such as: Service identifier (examples include: urn:service:info or a tel URI, etc.) Service URN (an implementation of above, namely conforms to the example urn:service:*) Emergency service identifier ((ESI), from the set of service identifiers, context=emergency services only, with examples of urn:service:sos or a tel URI) Emergency service URN (an implementation of an ESI, example is urn:service:sos, urn:service:sos.fire, etc. - also sometimes referred to as an 'sos service URN') (In the last case of an emergency service URN, I don't like to have two names for the same thing, but felt that this name was preferable, rather than use 'sos service URN'.) F. Updated the issues in the issues tracker (http://www.ietf-ecrit.org:8080/ecrit-req/index): Only a few issues remain. Since some rewording changes we made, these are still left to age (i.e., time for comment). Issues which I have left open are: #52 protocol specific, end devices out of scope - reworded to make more general/ #35 Location Validation - removed 1 existing, 2 of the new requirements, marked 'done'/ #38 Ma5. URI alternate contact - some rewording + renumbered now as Ma9, marked 'done'/ #39 Ma6. URL properties - replacement of URL with URI, renumbered as Ma11, marked 'done'/ #52 will be marked as "Resolved" after several days, assuming no objections arise from the list. G. No new issues have been logged. H. Removed requirements Id4, "Prevention of Fraud, based on review comment that it be covered within the security draft. I. Added IANA section to draft. 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 May 18 18:08:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgqfB-0005z6-Mh; Thu, 18 May 2006 18:08:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgqf9-0005yo-W6 for ecrit@ietf.org; Thu, 18 May 2006 18:08:07 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgqf8-00024X-FY for ecrit@ietf.org; Thu, 18 May 2006 18:08:07 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 18 May 2006 15:08:06 -0700 X-IronPort-AV: i="4.05,142,1146466800"; d="scan'208"; a="1808828936:sNHT32613068" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k4IM85nC031659; Thu, 18 May 2006 15:08:05 -0700 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 k4IM85Hc014794; Thu, 18 May 2006 15:08:05 -0700 (PDT) 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, 18 May 2006 15:08:05 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.20.46]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 May 2006 15:08:04 -0700 Message-Id: <4.3.2.7.2.20060518170652.03738b90@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 May 2006 17:08:04 -0500 To: "Brian Rosen" , "'Roger Marshall'" , From: "James M. Polk" Subject: RE: [Ecrit] New requirements draft -09 available In-Reply-To: <03ef01c67ac1$ae903140$640fa8c0@cis.neustar.com> References: <8C837214C95C864C9F34F3635C2A657504F2D16A@SEA-EXCHVS-2.telecomsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 18 May 2006 22:08:04.0980 (UTC) FILETIME=[89740340:01C67AC7] DKIM-Signature: a=rsa-sha1; q=dns; l=3843; t=1147990085; x=1148854085; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[Ecrit]=20New=20requirements=20draft=20-09=20available; X=v=3Dcisco.com=3B=20h=3DzG2tD9/Wm7Y2nDp/ebp8SPZ7gMA=3D; b=jQ/DaJHinPNgCLHZJOktMVH4faMO+e6h60YnsFWk6lTc/fXUuoKb1aqA6gcOjHEcA24qINc6 H50+U1wy1YjgN+ZfxLkWkshKwpbzKTTBpIxDaU2MnMyK0rLjPcnIGTyB; Authentication-Results: sj-dkim-2.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 05:26 PM 5/18/2006 -0400, Brian Rosen wrote: >Roger > >Thank you for all your work on this. > >Can we be done now? > >We are clearly over the line when we make a change to the requirements in >light of a draft for the solution (service urn). We need to get this >document out now, because we're not helping the solution, we're just >polishing the apple. > >I respectfully ask that we complete WGLC, and any further comments be >subject to a "does this REALLY matter now" test. I second this motion >The best quality requirements documents are always written after the product >is in the market, but those don't help the implementation team much. > >Brian > >-----Original Message----- >From: Roger Marshall [mailto:RMarshall@telecomsys.com] >Sent: Thursday, May 18, 2006 4:28 PM >To: ecrit@ietf.org >Subject: [Ecrit] New requirements draft -09 available > >Here's a summary of changes for the new edition of the ECRIT >requirements draft, recently submitted to the I-D editor. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-09.txt > >A diff version of this is available at: >http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-requirements/ > >This new version contains changes which are generally described below: > >A. Quite a bit of renumbering and reordering has been done with both >the terminology section and the various requirements. > >B. Received review comments from Hannes (5/12) & a few others. Tried >to incorporate all or respond with reasons why, if not. > >C. Rewording of Introduction section, paragraph 6, etc. talking about >identifiers. > >D. Tried to clean up confusion around terminology. For example, >replaced the term 'emergency identifier' with 'emergency service >identifier'. > >E. In light of the ecrit-service-urn draft, added some new terms & >defns, such as: > >Service identifier (examples include: urn:service:info or a tel URI, >etc.) >Service URN (an implementation of above, namely conforms to the example >urn:service:*) >Emergency service identifier ((ESI), from the set of service >identifiers, context=emergency services only, with examples of >urn:service:sos or a tel URI) >Emergency service URN (an implementation of an ESI, example is >urn:service:sos, urn:service:sos.fire, etc. - also sometimes referred to >as an 'sos service URN') > >(In the last case of an emergency service URN, I don't like to have two >names for the same thing, but felt that this name was preferable, rather >than use 'sos service URN'.) > >F. Updated the issues in the issues tracker >(http://www.ietf-ecrit.org:8080/ecrit-req/index): > >Only a few issues remain. Since some rewording changes we made, these >are still left to age (i.e., time for comment). > >Issues which I have left open are: >#52 protocol specific, end devices out of scope - reworded to make more >general/ >#35 Location Validation - removed 1 existing, 2 of the new requirements, >marked 'done'/ >#38 Ma5. URI alternate contact - some rewording + renumbered now as Ma9, >marked 'done'/ >#39 Ma6. URL properties - replacement of URL with URI, renumbered as >Ma11, marked 'done'/ > >#52 will be marked as "Resolved" after several days, assuming no >objections arise from the list. > >G. No new issues have been logged. > >H. Removed requirements Id4, "Prevention of Fraud, based on review >comment that it be covered within the security draft. > >I. Added IANA section to draft. > > >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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu May 18 18:45:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgrFG-0006yl-RT; Thu, 18 May 2006 18:45:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgrFF-0006yg-OH for ecrit@ietf.org; Thu, 18 May 2006 18:45:25 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgrFE-0004M4-9U for ecrit@ietf.org; Thu, 18 May 2006 18:45:25 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 18 May 2006 15:45:16 -0700 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] New requirements draft -09 available Date: Thu, 18 May 2006 15:45:16 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657504F2D2CC@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] New requirements draft -09 available Thread-Index: AcZ6x4uVt2CMPUIeTyK23FlHJylnlAABQl2w From: "Roger Marshall" To: "James M. Polk" , "Brian Rosen" , 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: , Errors-To: ecrit-bounces@ietf.org Sounds good to me. Hannes? Marc?=20 -roger. >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com]=20 >Sent: Thursday, May 18, 2006 3:08 PM >To: Brian Rosen; Roger Marshall; ecrit@ietf.org >Subject: RE: [Ecrit] New requirements draft -09 available > >At 05:26 PM 5/18/2006 -0400, Brian Rosen wrote: >>Roger >> >>Thank you for all your work on this. >> >>Can we be done now? >> >>We are clearly over the line when we make a change to the=20 >requirements=20 >>in light of a draft for the solution (service urn). We need to get=20 >>this document out now, because we're not helping the solution, we're=20 >>just polishing the apple. >> >>I respectfully ask that we complete WGLC, and any further comments be=20 >>subject to a "does this REALLY matter now" test. > >I second this motion > > >>The best quality requirements documents are always written after the=20 >>product is in the market, but those don't help the=20 >implementation team much. >> >>Brian >> >>-----Original Message----- >>From: Roger Marshall [mailto:RMarshall@telecomsys.com] >>Sent: Thursday, May 18, 2006 4:28 PM >>To: ecrit@ietf.org >>Subject: [Ecrit] New requirements draft -09 available >> >>Here's a summary of changes for the new edition of the ECRIT=20 >>requirements draft, recently submitted to the I-D editor. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requireme >nts-09.tx >>t >> >>A diff version of this is available at: >>http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-requirements/ >> >>This new version contains changes which are generally described below: >> >>A. Quite a bit of renumbering and reordering has been done with both=20 >>the terminology section and the various requirements. >> >>B. Received review comments from Hannes (5/12) & a few=20 >others. Tried=20 >>to incorporate all or respond with reasons why, if not. >> >>C. Rewording of Introduction section, paragraph 6, etc.=20 >talking about=20 >>identifiers. >> >>D. Tried to clean up confusion around terminology. For example,=20 >>replaced the term 'emergency identifier' with 'emergency service=20 >>identifier'. >> >>E. In light of the ecrit-service-urn draft, added some new terms &=20 >>defns, such as: >> >>Service identifier (examples include: urn:service:info or a tel URI, >>etc.) >>Service URN (an implementation of above, namely conforms to=20 >the example >>urn:service:*) >>Emergency service identifier ((ESI), from the set of service=20 >>identifiers, context=3Demergency services only, with examples of=20 >>urn:service:sos or a tel URI) Emergency service URN (an=20 >implementation=20 >>of an ESI, example is urn:service:sos, urn:service:sos.fire, etc. -=20 >>also sometimes referred to as an 'sos service URN') >> >>(In the last case of an emergency service URN, I don't like=20 >to have two=20 >>names for the same thing, but felt that this name was preferable,=20 >>rather than use 'sos service URN'.) >> >>F. Updated the issues in the issues tracker >>(http://www.ietf-ecrit.org:8080/ecrit-req/index): >> >>Only a few issues remain. Since some rewording changes we=20 >made, these=20 >>are still left to age (i.e., time for comment). >> >>Issues which I have left open are: >>#52 protocol specific, end devices out of scope - reworded to=20 >make more=20 >>general/ >>#35 Location Validation - removed 1 existing, 2 of the new=20 >>requirements, marked 'done'/ >>#38 Ma5. URI alternate contact - some rewording + renumbered now as=20 >>Ma9, marked 'done'/ >>#39 Ma6. URL properties - replacement of URL with URI, renumbered as=20 >>Ma11, marked 'done'/ >> >>#52 will be marked as "Resolved" after several days, assuming no=20 >>objections arise from the list. >> >>G. No new issues have been logged. >> >>H. Removed requirements Id4, "Prevention of Fraud, based on review=20 >>comment that it be covered within the security draft. >> >>I. Added IANA section to draft. >> >> >>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 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu May 18 23:14:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgvRk-0003cB-Se; Thu, 18 May 2006 23:14:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgvRj-0003c4-GJ for ecrit@ietf.org; Thu, 18 May 2006 23:14:35 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgvRg-0001QP-7r for ecrit@ietf.org; Thu, 18 May 2006 23:14:35 -0400 Received: from [192.168.0.41] (pool-138-89-20-236.mad.east.verizon.net [138.89.20.236]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k4J3EUnH021954 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 18 May 2006 23:14:30 -0400 (EDT) In-Reply-To: <4467AB66.40307@gmx.net> References: <4467AB66.40307@gmx.net> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7CF76387-1DA1-493C-9A89-EC00C9F080EA@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Review of draft-ietf-ecrit-service-urn-02 Date: Thu, 18 May 2006 23:14:26 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes, thanks for your comments. Only a few minor remarks: > > * Section 2: > > particular service in the user's current context, e.g., at his > ^^^ > its > > * Section 2: > > For example, a traveler will be able to use his > ^^^^ its > At least according to the style guides I have looked at, using "its" as the gender-neutral pronoun is frowned upon; if we want to be politically correct, it would have to be "he or she" or the plural. You can read http://en.wikipedia.org/wiki/Gender-neutral_pronoun for the finer points. I have rewritten the sentences to avoid gender bias. > * Section 2: > > the local emergency number. > ^^^^^^^^^^^^^^^^^^^^^^ > [hannes] If I recall it correctly then we use the term visited > emergency dial string in this context. As a side note, the term is probably not particularly fortuitous. After all, we're not visiting the emergency dial string. > > * Section 4.3: sos Service Types > > We have discussed the usage of the term 'sos Service Types' > terminology. It depends on Roger how to best align this document > with the requirements draft. In keeping with the grammar of the URN, sos sub-services is probably most precise. > > As you recall from the location types draft we got asked where the > definitions come from. Where do the definitions in this document > come from? Mostly made up, with some inspiration from Merriam-Webster and Wikipedia. If somebody has a more authoritative source, I'd appreciate if they could send a pointer. > > * IDN > > Since the identifiers used in this document might also presented to > the user do we have to mention IDN considerations somewhere. I bet > we will get such a question. > > Maybe a short text could go into a 'Internationalization > Considerations' section. I'm not so sure about that; currently, the section reads The service labels are protocol elements and not normally seen by users. Thus, the character set for these elements is restricted, as described in . I was hoping that LoST could provide a language-appropriate description if a listing of sub-services is supported. > > * Appendix A > > You might want to restructure / reformat this section slightly to > improve readability. Yes, that section is a cut-and-paste mess. I've updated the document and will submit it shortly. See http:// www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service- urn-03.html for a preview version. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 19 09:55:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh5Rh-0007jX-2j; Fri, 19 May 2006 09:55:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh5Rf-0007jR-9B for ecrit@ietf.org; Fri, 19 May 2006 09:55:11 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fh5Rd-0001RO-Sx for ecrit@ietf.org; Fri, 19 May 2006 09:55:11 -0400 Received: (qmail invoked by alias); 19 May 2006 13:55:08 -0000 Received: from ip-80-226-190-229.vodafone-net.de (EHLO [10.226.145.58]) [80.226.190.229] by mail.gmx.net (mp031) with SMTP; 19 May 2006 15:55:08 +0200 X-Authenticated: #29516787 Message-ID: <446DCE37.7020506@gmx.net> Date: Fri, 19 May 2006 15:55:03 +0200 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ecrit] How to get work done. X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, from time to time some of you indicate that we should make better progress with our charter items. That's a good idea BUT we all need todo something to accomplish our ambitious goals. Here are some hints what you could do to help us all to make better progress: * Review documents as early as possible. Review documents when we start a WGLC. (Note that we cannot send a document to the IESG that has obvious bugs.) * Send constructive feedback. This might, for example, include text proposals. * Organize discussions in a structured fashion. Make use of the issue tracker. Ciao Hannes PS: I would really, really like to see some progress on the ECRIT-Arch DT as well ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 19 10:28:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh5y4-0004il-G0; Fri, 19 May 2006 10:28:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh5y3-0004ig-Fd for ecrit@ietf.org; Fri, 19 May 2006 10:28:39 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fh5y1-00034l-W6 for ecrit@ietf.org; Fri, 19 May 2006 10:28:39 -0400 Received: (qmail invoked by alias); 19 May 2006 14:28:36 -0000 Received: from ip-80-226-209-133.vodafone-net.de (EHLO [10.226.216.206]) [80.226.209.133] by mail.gmx.net (mp029) with SMTP; 19 May 2006 16:28:36 +0200 X-Authenticated: #29516787 Message-ID: <446DD611.3040209@gmx.net> Date: Fri, 19 May 2006 16:28:33 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] New requirements draft -09 available References: <8C837214C95C864C9F34F3635C2A657504F2D2CC@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A657504F2D2CC@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org have you, Brian and James, read draft version -08 or -09? Are you OK with the -09 version? Ciao Hannes Roger Marshall wrote: > Sounds good to me. Hannes? Marc? > > -roger. > > >>-----Original Message----- >>From: James M. Polk [mailto:jmpolk@cisco.com] >>Sent: Thursday, May 18, 2006 3:08 PM >>To: Brian Rosen; Roger Marshall; ecrit@ietf.org >>Subject: RE: [Ecrit] New requirements draft -09 available >> >>At 05:26 PM 5/18/2006 -0400, Brian Rosen wrote: >> >>>Roger >>> >>>Thank you for all your work on this. >>> >>>Can we be done now? >>> >>>We are clearly over the line when we make a change to the >> >>requirements >> >>>in light of a draft for the solution (service urn). We need to get >>>this document out now, because we're not helping the solution, we're >>>just polishing the apple. >>> >>>I respectfully ask that we complete WGLC, and any further comments be >>>subject to a "does this REALLY matter now" test. >> >>I second this motion >> >> >> >>>The best quality requirements documents are always written after the >>>product is in the market, but those don't help the >> >>implementation team much. >> >>>Brian >>> >>>-----Original Message----- >>>From: Roger Marshall [mailto:RMarshall@telecomsys.com] >>>Sent: Thursday, May 18, 2006 4:28 PM >>>To: ecrit@ietf.org >>>Subject: [Ecrit] New requirements draft -09 available >>> >>>Here's a summary of changes for the new edition of the ECRIT >>>requirements draft, recently submitted to the I-D editor. >>> >>>A URL for this Internet-Draft is: >>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requireme >> >>nts-09.tx >> >>>t >>> >>>A diff version of this is available at: >>>http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-requirements/ >>> >>>This new version contains changes which are generally described below: >>> >>>A. Quite a bit of renumbering and reordering has been done with both >>>the terminology section and the various requirements. >>> >>>B. Received review comments from Hannes (5/12) & a few >> >>others. Tried >> >>>to incorporate all or respond with reasons why, if not. >>> >>>C. Rewording of Introduction section, paragraph 6, etc. >> >>talking about >> >>>identifiers. >>> >>>D. Tried to clean up confusion around terminology. For example, >>>replaced the term 'emergency identifier' with 'emergency service >>>identifier'. >>> >>>E. In light of the ecrit-service-urn draft, added some new terms & >>>defns, such as: >>> >>>Service identifier (examples include: urn:service:info or a tel URI, >>>etc.) >>>Service URN (an implementation of above, namely conforms to >> >>the example >> >>>urn:service:*) >>>Emergency service identifier ((ESI), from the set of service >>>identifiers, context=emergency services only, with examples of >>>urn:service:sos or a tel URI) Emergency service URN (an >> >>implementation >> >>>of an ESI, example is urn:service:sos, urn:service:sos.fire, etc. - >>>also sometimes referred to as an 'sos service URN') >>> >>>(In the last case of an emergency service URN, I don't like >> >>to have two >> >>>names for the same thing, but felt that this name was preferable, >>>rather than use 'sos service URN'.) >>> >>>F. Updated the issues in the issues tracker >>>(http://www.ietf-ecrit.org:8080/ecrit-req/index): >>> >>>Only a few issues remain. Since some rewording changes we >> >>made, these >> >>>are still left to age (i.e., time for comment). >>> >>>Issues which I have left open are: >>>#52 protocol specific, end devices out of scope - reworded to >> >>make more >> >>>general/ >>>#35 Location Validation - removed 1 existing, 2 of the new >>>requirements, marked 'done'/ >>>#38 Ma5. URI alternate contact - some rewording + renumbered now as >>>Ma9, marked 'done'/ >>>#39 Ma6. URL properties - replacement of URL with URI, renumbered as >>>Ma11, marked 'done'/ >>> >>>#52 will be marked as "Resolved" after several days, assuming no >>>objections arise from the list. >>> >>>G. No new issues have been logged. >>> >>>H. Removed requirements Id4, "Prevention of Fraud, based on review >>>comment that it be covered within the security draft. >>> >>>I. Added IANA section to draft. >>> >>> >>>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 >> > > _______________________________________________ > 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 May 19 10:43:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh6Cd-0002h0-Qh; Fri, 19 May 2006 10:43:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh6Cc-0002en-Jw for ecrit@ietf.org; Fri, 19 May 2006 10:43:42 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fh6Cb-0004TO-CG for ecrit@ietf.org; Fri, 19 May 2006 10:43:42 -0400 Received: (qmail invoked by alias); 19 May 2006 14:43:40 -0000 Received: from ip-80-226-209-133.vodafone-net.de (EHLO [10.226.216.206]) [80.226.209.133] by mail.gmx.net (mp030) with SMTP; 19 May 2006 16:43:40 +0200 X-Authenticated: #29516787 Message-ID: <446DD999.6090307@gmx.net> Date: Fri, 19 May 2006 16:43:37 +0200 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: 7aefe408d50e9c7c47615841cb314bed Subject: [Ecrit] ECRIT Security Threats Draft; Reviews needed X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, we need more reviews for the threats draft. Please post your review to the list to allow us moving it forward. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 19 10:44:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh6D2-0003NX-1N; Fri, 19 May 2006 10:44:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh6D1-0003NS-8x for ecrit@ietf.org; Fri, 19 May 2006 10:44:07 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fh6Cz-0004Tu-RV for ecrit@ietf.org; Fri, 19 May 2006 10:44:07 -0400 Received: (qmail invoked by alias); 19 May 2006 14:44:04 -0000 Received: from ip-80-226-209-133.vodafone-net.de (EHLO [10.226.216.206]) [80.226.209.133] by mail.gmx.net (mp031) with SMTP; 19 May 2006 16:44:04 +0200 X-Authenticated: #29516787 Message-ID: <446DD9B2.1020607@gmx.net> Date: Fri, 19 May 2006 16:44:02 +0200 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.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Ecrit] Summary of Recent Discussion X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, here is a short summary of the recent discussions: * LoST always requires a service identifier and location information as parameters of a query. A dialstring is not an input parameter for a LoST query. * Extensibility mechanism for LoST. Is a "capability discovery" for LoST in the form of a "Please return what services URIs you understand." useful? (Btw, we similar mechanisms with the policy work in Geopriv.) The degree of complexity introduced by the different proposals needs to be analysed. (This aspect does not need to be captured in the requirements document and is subject for discussion related to LoST.) * Various failure cases in LoST need to be carefully analysed. E.g., A person asks for "urn:service:sos.fire" but only ""urn:service:sos" is available. What would happen? This item and the last one are related to each other. * Henning suggested to extend LoST to return additional information regarding the service (e.g., location information needed). This discussion is relevant for LoST. I can see that there was support for his proposal. This aspect does not need to be captured in the requirements draft. * Child helpline Henning has already captured the child helpline service identifier after a discussion on the mailing list: http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service-urn-03.txt). (see urn:service:counseling.children) * Requirements draft Roger mentioned a few open issues with the document where he would appreciate input. A final review would help to finish the document. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 19 11:34:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh6zb-0000Uy-8D; Fri, 19 May 2006 11:34:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh6za-0000Ut-Ao for ecrit@ietf.org; Fri, 19 May 2006 11:34:18 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh6zY-0007y9-U0 for ecrit@ietf.org; Fri, 19 May 2006 11:34:18 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Fh6zP-0007bZ-NQ; Fri, 19 May 2006 10:34:08 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'Roger Marshall'" Subject: RE: [Ecrit] New requirements draft -09 available Date: Fri, 19 May 2006 11:34:08 -0400 Message-ID: <04b301c67b59$adfea390$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ7UIQR0CKx3CclSymItxVW9/fMOAACSTRA In-Reply-To: <446DD611.3040209@gmx.net> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I have now looked at -09 and I am happy with it. Brian -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Friday, May 19, 2006 10:29 AM To: Roger Marshall Cc: James M. Polk; Brian Rosen; ecrit@ietf.org Subject: Re: [Ecrit] New requirements draft -09 available have you, Brian and James, read draft version -08 or -09? Are you OK with the -09 version? Ciao Hannes Roger Marshall wrote: > Sounds good to me. Hannes? Marc? > > -roger. > > >>-----Original Message----- >>From: James M. Polk [mailto:jmpolk@cisco.com] >>Sent: Thursday, May 18, 2006 3:08 PM >>To: Brian Rosen; Roger Marshall; ecrit@ietf.org >>Subject: RE: [Ecrit] New requirements draft -09 available >> >>At 05:26 PM 5/18/2006 -0400, Brian Rosen wrote: >> >>>Roger >>> >>>Thank you for all your work on this. >>> >>>Can we be done now? >>> >>>We are clearly over the line when we make a change to the >> >>requirements >> >>>in light of a draft for the solution (service urn). We need to get >>>this document out now, because we're not helping the solution, we're >>>just polishing the apple. >>> >>>I respectfully ask that we complete WGLC, and any further comments be >>>subject to a "does this REALLY matter now" test. >> >>I second this motion >> >> >> >>>The best quality requirements documents are always written after the >>>product is in the market, but those don't help the >> >>implementation team much. >> >>>Brian >>> >>>-----Original Message----- >>>From: Roger Marshall [mailto:RMarshall@telecomsys.com] >>>Sent: Thursday, May 18, 2006 4:28 PM >>>To: ecrit@ietf.org >>>Subject: [Ecrit] New requirements draft -09 available >>> >>>Here's a summary of changes for the new edition of the ECRIT >>>requirements draft, recently submitted to the I-D editor. >>> >>>A URL for this Internet-Draft is: >>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requireme >> >>nts-09.tx >> >>>t >>> >>>A diff version of this is available at: >>>http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-requirements/ >>> >>>This new version contains changes which are generally described below: >>> >>>A. Quite a bit of renumbering and reordering has been done with both >>>the terminology section and the various requirements. >>> >>>B. Received review comments from Hannes (5/12) & a few >> >>others. Tried >> >>>to incorporate all or respond with reasons why, if not. >>> >>>C. Rewording of Introduction section, paragraph 6, etc. >> >>talking about >> >>>identifiers. >>> >>>D. Tried to clean up confusion around terminology. For example, >>>replaced the term 'emergency identifier' with 'emergency service >>>identifier'. >>> >>>E. In light of the ecrit-service-urn draft, added some new terms & >>>defns, such as: >>> >>>Service identifier (examples include: urn:service:info or a tel URI, >>>etc.) >>>Service URN (an implementation of above, namely conforms to >> >>the example >> >>>urn:service:*) >>>Emergency service identifier ((ESI), from the set of service >>>identifiers, context=emergency services only, with examples of >>>urn:service:sos or a tel URI) Emergency service URN (an >> >>implementation >> >>>of an ESI, example is urn:service:sos, urn:service:sos.fire, etc. - >>>also sometimes referred to as an 'sos service URN') >>> >>>(In the last case of an emergency service URN, I don't like >> >>to have two >> >>>names for the same thing, but felt that this name was preferable, >>>rather than use 'sos service URN'.) >>> >>>F. Updated the issues in the issues tracker >>>(http://www.ietf-ecrit.org:8080/ecrit-req/index): >>> >>>Only a few issues remain. Since some rewording changes we >> >>made, these >> >>>are still left to age (i.e., time for comment). >>> >>>Issues which I have left open are: >>>#52 protocol specific, end devices out of scope - reworded to >> >>make more >> >>>general/ >>>#35 Location Validation - removed 1 existing, 2 of the new >>>requirements, marked 'done'/ >>>#38 Ma5. URI alternate contact - some rewording + renumbered now as >>>Ma9, marked 'done'/ >>>#39 Ma6. URL properties - replacement of URL with URI, renumbered as >>>Ma11, marked 'done'/ >>> >>>#52 will be marked as "Resolved" after several days, assuming no >>>objections arise from the list. >>> >>>G. No new issues have been logged. >>> >>>H. Removed requirements Id4, "Prevention of Fraud, based on review >>>comment that it be covered within the security draft. >>> >>>I. Added IANA section to draft. >>> >>> >>>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 >> > > _______________________________________________ > 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 May 19 12:24:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh7m1-0003mu-0L; Fri, 19 May 2006 12:24:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh7lz-0003mm-Oq for ecrit@ietf.org; Fri, 19 May 2006 12:24:19 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh7lx-0001xh-Dg for ecrit@ietf.org; Fri, 19 May 2006 12:24:19 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Fri, 19 May 2006 12:24:35 -0400 id 0158801F.446DF143.00006C57 Message-ID: <446DF11B.8080005@hxr.us> Date: Fri, 19 May 2006 12:23:55 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Henning Schulzrinne Subject: List services use case (was Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline) References: <5A3C112C-A68B-4296-9F7B-FE3F86004F05@cs.columbia.edu> In-Reply-To: <5A3C112C-A68B-4296-9F7B-FE3F86004F05@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ecrit@ietf.org, "Thomson, Martin" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'm a little fuzzy as to what a phone is suppose to do with services it did not previously know about. Just what is it to do, present the user with a cryptic URN when they are in the throes of making an emergency phone call? So, is this optimization for the following reason: Phone has 3 sos services it knows about. The LoST service knows about 10 sos services. The phone wants to pre-populate its cache with the sip addresses of the 3 sos services it is configured to support. The other 7 will not be queried. Just to be clear, we aren't talking about the phone trying to understand services its software has never seen before, right? -andy Henning Schulzrinne wrote: > > On May 17, 2006, at 8:05 PM, Thomson, Martin wrote: > >> I don't have a problem with asking for sub-services. For instance, I >> know about urn:service:massage, but I might like to know that >> urn:service:massage.swedish exists. That's valuable. >> >> Of course, the advantage with what we have currently is that this >> feature can be added later. If it isn't necessary, then we can leave >> it until we don't have more pressing problems to address. > > Indeed - that's a separate query. > >> >> Q: If I try to resolve urn:service:sos.fire and it doesn't exist, can >> the LoST server unilaterally return the result for urn:service:sos? > > I suppose, as a hint, although I'm a bit worried about the complexity > once you generalize this. Imagine that we have more than two levels of > service descriptions (urn:service:sos.fire.cats_in_trees). Should the > result include the whole tree above the (non-existing) service? > > I think a better approach is to have the client do the "list > subservices" query, and then query for those subservices. Less guesswork > and special cases. > > Henning > > > _______________________________________________ > 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 May 19 12:41:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh82g-0005yC-H5; Fri, 19 May 2006 12:41:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh82e-0005y2-J9 for ecrit@ietf.org; Fri, 19 May 2006 12:41:32 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh82c-0003OT-8A for ecrit@ietf.org; Fri, 19 May 2006 12:41:32 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Fh82U-0007CF-Vn; Fri, 19 May 2006 11:41:23 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Henning Schulzrinne'" Subject: RE: List services use case (was Re: [Ecrit] Re: CommmentsI.D-ecrit-service-urn-03 Child helpline) Date: Fri, 19 May 2006 12:41:24 -0400 Message-ID: <04c101c67b63$136b5da0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ7YLYreOrxvOZ9SkWQen8W9m9Y0gAAidqg In-Reply-To: <446DF11B.8080005@hxr.us> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: ecrit@ietf.org, "'Thomson, Martin'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org While I can see some really smart phones trying to make sense out of the list, in my mind the purpose here is to develop a COMPLETE list of dial strings that need to be recognized and translated into service URNs. Brian -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Friday, May 19, 2006 12:24 PM To: Henning Schulzrinne Cc: ecrit@ietf.org; Thomson, Martin Subject: List services use case (was Re: [Ecrit] Re: CommmentsI.D-ecrit-service-urn-03 Child helpline) I'm a little fuzzy as to what a phone is suppose to do with services it did not previously know about. Just what is it to do, present the user with a cryptic URN when they are in the throes of making an emergency phone call? So, is this optimization for the following reason: Phone has 3 sos services it knows about. The LoST service knows about 10 sos services. The phone wants to pre-populate its cache with the sip addresses of the 3 sos services it is configured to support. The other 7 will not be queried. Just to be clear, we aren't talking about the phone trying to understand services its software has never seen before, right? -andy Henning Schulzrinne wrote: > > On May 17, 2006, at 8:05 PM, Thomson, Martin wrote: > >> I don't have a problem with asking for sub-services. For instance, I >> know about urn:service:massage, but I might like to know that >> urn:service:massage.swedish exists. That's valuable. >> >> Of course, the advantage with what we have currently is that this >> feature can be added later. If it isn't necessary, then we can leave >> it until we don't have more pressing problems to address. > > Indeed - that's a separate query. > >> >> Q: If I try to resolve urn:service:sos.fire and it doesn't exist, can >> the LoST server unilaterally return the result for urn:service:sos? > > I suppose, as a hint, although I'm a bit worried about the complexity > once you generalize this. Imagine that we have more than two levels of > service descriptions (urn:service:sos.fire.cats_in_trees). Should the > result include the whole tree above the (non-existing) service? > > I think a better approach is to have the client do the "list > subservices" query, and then query for those subservices. Less guesswork > and special cases. > > Henning > > > _______________________________________________ > 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 May 19 12:46:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh87Q-0000ML-W9; Fri, 19 May 2006 12:46:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh87P-0000LL-GN for ecrit@ietf.org; Fri, 19 May 2006 12:46:27 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh87N-0003gi-AN for ecrit@ietf.org; Fri, 19 May 2006 12:46:27 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Fri, 19 May 2006 12:46:59 -0400 id 0158801A.446DF684.0000707E Message-ID: <446DF65C.7050204@hxr.us> Date: Fri, 19 May 2006 12:46:20 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Brian Rosen Subject: Re: List services use case (was Re: [Ecrit] Re: CommmentsI.D-ecrit-service-urn-03 Child helpline) References: <04c101c67b63$136b5da0$640fa8c0@cis.neustar.com> In-Reply-To: <04c101c67b63$136b5da0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ecrit@ietf.org, "'Thomson, Martin'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: > While I can see some really smart phones trying to make sense out of the > list, in my mind the purpose here is to develop a COMPLETE list of dial > strings that need to be recognized and translated into service URNs. Exactly what "smart" thing would they do? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 19 12:51:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh8CC-0000rd-HG; Fri, 19 May 2006 12:51:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh8CB-0000rY-Bu for ecrit@ietf.org; Fri, 19 May 2006 12:51:23 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh8CB-00047s-5Q for ecrit@ietf.org; Fri, 19 May 2006 12:51:23 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Fh8C4-00081K-GQ; Fri, 19 May 2006 11:51:16 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: List services use case (was Re: [Ecrit] Re: CommmentsI.D-ecrit-service-urn-03 Child helpline) Date: Fri, 19 May 2006 12:51:18 -0400 Message-ID: <04c201c67b64$75359630$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ7Y8L9epu4lFBkREesW0IRpLxAUAAAHRYQ In-Reply-To: <446DF65C.7050204@hxr.us> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ecrit@ietf.org, "'Thomson, Martin'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I would imagine that there would be, somewhere, some kind of a "pretty print" description of what these services are. The phone would access this along with the list of service urns available at their location and offer an interesting GUI for what it finds. Brian -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Friday, May 19, 2006 12:46 PM To: Brian Rosen Cc: 'Henning Schulzrinne'; ecrit@ietf.org; 'Thomson, Martin' Subject: Re: List services use case (was Re: [Ecrit] Re: CommmentsI.D-ecrit-service-urn-03 Child helpline) Brian Rosen wrote: > While I can see some really smart phones trying to make sense out of the > list, in my mind the purpose here is to develop a COMPLETE list of dial > strings that need to be recognized and translated into service URNs. Exactly what "smart" thing would they do? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 19 13:00:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh8KR-0001sL-HW; Fri, 19 May 2006 12:59:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh8KQ-0001rL-CQ for ecrit@ietf.org; Fri, 19 May 2006 12:59:54 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh8KP-00059A-4l for ecrit@ietf.org; Fri, 19 May 2006 12:59:54 -0400 Received: from lion.cs.columbia.edu (IDENT:CcXJKgzmcEugndSFyuBqOaoOk5sL/G6S@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k4JGxDX6019999 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 19 May 2006 12:59:21 -0400 (EDT) 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 k4JGxCBB008846 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 19 May 2006 12:59:13 -0400 Message-ID: <446DF95B.9070400@cs.columbia.edu> Date: Fri, 19 May 2006 12:59:07 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Brian Rosen Subject: Re: List services use case (was Re: [Ecrit] Re: CommmentsI.D-ecrit-service-urn-03 Child helpline) References: <04c201c67b64$75359630$640fa8c0@cis.neustar.com> In-Reply-To: <04c201c67b64$75359630$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='__C230066_P3_1 0, __C230066_P5 0, __CP_NAME_BODY 0, __CP_NAME_SUBJ 0, __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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ecrit@ietf.org, "'Thomson, Martin'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I agree with Brian. It seems quite common for GSM phones to show a text message indicating "welcome to Teluristan; you can get concierge services at *311 and can talk to our sales rep at *411." when roaming into a new country or service area. The problem with these messages is that they are not structured, so there is no easy way for them to be integrated into the phone's address book, for example. With the service listing proposed, this would be fairly straightforward. Given the generic URN service names, it would also make it easy to have symbols or visitor-language descriptions on the phone. Thus, tourists could always easily access the local version of the poison control center, for example, even if they have no clue that they'd dial 1-800-222-1222 in the US for that. Henning Brian Rosen wrote: > I would imagine that there would be, somewhere, some kind of a "pretty > print" description of what these services are. The phone would access this > along with the list of service urns available at their location and offer an > interesting GUI for what it finds. > > Brian > > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Friday, May 19, 2006 12:46 PM > To: Brian Rosen > Cc: 'Henning Schulzrinne'; ecrit@ietf.org; 'Thomson, Martin' > Subject: Re: List services use case (was Re: [Ecrit] Re: > CommmentsI.D-ecrit-service-urn-03 Child helpline) > > Brian Rosen wrote: >> While I can see some really smart phones trying to make sense out of the >> list, in my mind the purpose here is to develop a COMPLETE list of dial >> strings that need to be recognized and translated into service URNs. > > Exactly what "smart" thing would they do? > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 19 13:05:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh8Q2-0007yN-4P; Fri, 19 May 2006 13:05:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh8Q1-0007yI-69 for ecrit@ietf.org; Fri, 19 May 2006 13:05:41 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh8Py-0005ur-P3 for ecrit@ietf.org; Fri, 19 May 2006 13:05:41 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 19 May 2006 10:05:37 -0700 X-IronPort-AV: i="4.05,147,1146466800"; d="scan'208"; a="1809340233:sNHT3452853852" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k4JH5a9A008113; Fri, 19 May 2006 10:05:36 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4JH5asF015401; Fri, 19 May 2006 10:05:36 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 May 2006 13:05:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: List services use case (was Re: [Ecrit] Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) Date: Fri, 19 May 2006 13:05:34 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E5C00@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: List services use case (was Re: [Ecrit] Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) Thread-Index: AcZ7Zdb7SZ2ZdNmQRvKX5Bn9Vt3/0QAAG1fw From: "Michael Hammer \(mhammer\)" To: "Henning Schulzrinne" , "Brian Rosen" X-OriginalArrivalTime: 19 May 2006 17:05:35.0987 (UTC) FILETIME=[72393430:01C67B66] DKIM-Signature: a=rsa-sha1; q=dns; l=2608; t=1148058336; x=1148922336; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20List=20services=20use=20case=20(was=20Re=3A=20[Ecrit]=20Re=3ACom mmentsI.D-ecrit-service-urn-03=20Child=20helpline); X=v=3Dcisco.com=3B=20h=3DXzP2aBSOS/QZSLTTN4282G3ktQo=3D; b=qnry0PSpOthyfXRPMU1UOx/gNOGQH7lqoNcAbxpFYvrnh07V2FjFuLHBTzaODfmG5uQvuh/H r3UbrTPYgC3guj5edmhIazSXQd97HXhA0bp7370R4CtjlZEpBjpHwAvU; Authentication-Results: sj-dkim-7.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ecrit@ietf.org, "Thomson, Martin" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org If I were French would I miss the difference between poison and poisson? There was a statement earlier that the urn's were protocol elements not visible to the end-user. =20 Is that true or not?=20 Mike > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > Sent: Friday, May 19, 2006 12:59 PM > To: Brian Rosen > Cc: ecrit@ietf.org; 'Thomson, Martin' > Subject: Re: List services use case (was Re: [Ecrit]=20 > Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) >=20 > I agree with Brian. >=20 > It seems quite common for GSM phones to show a text message=20 > indicating "welcome to Teluristan; you can get concierge=20 > services at *311 and can talk to our sales rep at *411." when=20 > roaming into a new country or service area. The problem with=20 > these messages is that they are not structured, so there is=20 > no easy way for them to be integrated into the phone's=20 > address book, for example. With the service listing proposed,=20 > this would be fairly straightforward. Given the generic URN=20 > service names, it would also make it easy to have symbols or=20 > visitor-language descriptions on the phone. Thus, tourists=20 > could always easily access the local version of the poison=20 > control center, for example, even if they have no clue that=20 > they'd dial 1-800-222-1222 in the US for that. >=20 > Henning >=20 > Brian Rosen wrote: > > I would imagine that there would be, somewhere, some kind=20 > of a "pretty=20 > > print" description of what these services are. The phone=20 > would access=20 > > this along with the list of service urns available at their=20 > location=20 > > and offer an interesting GUI for what it finds. > >=20 > > Brian > >=20 > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Friday, May 19, 2006 12:46 PM > > To: Brian Rosen > > Cc: 'Henning Schulzrinne'; ecrit@ietf.org; 'Thomson, Martin' > > Subject: Re: List services use case (was Re: [Ecrit] Re: > > CommmentsI.D-ecrit-service-urn-03 Child helpline) > >=20 > > Brian Rosen wrote: > >> While I can see some really smart phones trying to make=20 > sense out of=20 > >> the list, in my mind the purpose here is to develop a=20 > COMPLETE list=20 > >> of dial strings that need to be recognized and translated=20 > into service URNs. > >=20 > > Exactly what "smart" thing would they do? > >=20 > > -andy >=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 Fri May 19 13:23:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh8gx-0008IR-PH; Fri, 19 May 2006 13:23:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh8gv-0008IM-PS for ecrit@ietf.org; Fri, 19 May 2006 13:23:09 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh8gv-0006zm-Jz for ecrit@ietf.org; Fri, 19 May 2006 13:23:09 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Fri, 19 May 2006 13:23:43 -0400 id 0158801F.446DFF1F.0000763B Message-ID: <446DFEF7.80306@hxr.us> Date: Fri, 19 May 2006 13:23:03 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: List services use case (was Re: [Ecrit] Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) References: <072C5B76F7CEAB488172C6F64B30B5E3017E5C00@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3017E5C00@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ecrit@ietf.org, "Thomson, Martin" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Michael Hammer (mhammer) wrote: > If I were French would I miss the difference between poison and poisson? > > There was a statement earlier that the urn's were protocol elements not > visible to the end-user. > Is that true or not? > > Mike I agree with Mike on this. URNs are protocol elements and should not be shown to the user. And there can be no pretty form for localization if the phone as never encountered the URN before. I'm also a little dubious of any use case that has end users scrolling through a list of emergency services before they make an emergency call. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 19 13:26:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh8kS-00017h-9A; Fri, 19 May 2006 13:26:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh8kQ-00017c-UZ for ecrit@ietf.org; Fri, 19 May 2006 13:26:46 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh8kO-0007Ff-Ie for ecrit@ietf.org; Fri, 19 May 2006 13:26:46 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Fh8kH-0002hq-0t; Fri, 19 May 2006 12:26:37 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Henning Schulzrinne'" Subject: RE: List services use case (was Re: [Ecrit] Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) Date: Fri, 19 May 2006 13:26:39 -0400 Message-ID: <04c801c67b69$654b6420$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ7Zdb7SZ2ZdNmQRvKX5Bn9Vt3/0QAAG1fwAACnswA= In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3017E5C00@xmb-rtp-20b.amer.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: ecrit@ietf.org, "'Thomson, Martin'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Yes, that's why we don't really care about the "shape" of the tree. The URNs are protocol elements; the "name" is not designed to be shown to a user. That's why I think there is a database somewhere which has (localized) information on what these URNs mean. The LoST mechanism merely gives you the list of services available at the current location, which may be much smaller than the list of all possible service URNs. Brian -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Friday, May 19, 2006 1:06 PM To: Henning Schulzrinne; Brian Rosen Cc: ecrit@ietf.org; Thomson, Martin Subject: RE: List services use case (was Re: [Ecrit] Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) If I were French would I miss the difference between poison and poisson? There was a statement earlier that the urn's were protocol elements not visible to the end-user. Is that true or not? Mike > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, May 19, 2006 12:59 PM > To: Brian Rosen > Cc: ecrit@ietf.org; 'Thomson, Martin' > Subject: Re: List services use case (was Re: [Ecrit] > Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) > > I agree with Brian. > > It seems quite common for GSM phones to show a text message > indicating "welcome to Teluristan; you can get concierge > services at *311 and can talk to our sales rep at *411." when > roaming into a new country or service area. The problem with > these messages is that they are not structured, so there is > no easy way for them to be integrated into the phone's > address book, for example. With the service listing proposed, > this would be fairly straightforward. Given the generic URN > service names, it would also make it easy to have symbols or > visitor-language descriptions on the phone. Thus, tourists > could always easily access the local version of the poison > control center, for example, even if they have no clue that > they'd dial 1-800-222-1222 in the US for that. > > Henning > > Brian Rosen wrote: > > I would imagine that there would be, somewhere, some kind > of a "pretty > > print" description of what these services are. The phone > would access > > this along with the list of service urns available at their > location > > and offer an interesting GUI for what it finds. > > > > Brian > > > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Friday, May 19, 2006 12:46 PM > > To: Brian Rosen > > Cc: 'Henning Schulzrinne'; ecrit@ietf.org; 'Thomson, Martin' > > Subject: Re: List services use case (was Re: [Ecrit] Re: > > CommmentsI.D-ecrit-service-urn-03 Child helpline) > > > > Brian Rosen wrote: > >> While I can see some really smart phones trying to make > sense out of > >> the list, in my mind the purpose here is to develop a > COMPLETE list > >> of dial strings that need to be recognized and translated > into service URNs. > > > > Exactly what "smart" thing would they do? > > > > -andy > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 19 13:30:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh8nV-0001JJ-L4; Fri, 19 May 2006 13:29:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh8nU-0001JE-MG for ecrit@ietf.org; Fri, 19 May 2006 13:29:56 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh8nT-0007V1-F3 for ecrit@ietf.org; Fri, 19 May 2006 13:29:56 -0400 Received: from lion.cs.columbia.edu (IDENT:8WACwOahae0SKbrdwGswS/qU5E9yv4F8@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k4JHT7X6001763 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 19 May 2006 13:29:51 -0400 (EDT) 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 k4JHT7BB011261 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 19 May 2006 13:29:07 -0400 Message-ID: <446E005E.1030101@cs.columbia.edu> Date: Fri, 19 May 2006 13:29:02 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: List services use case (was Re: [Ecrit] Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) References: <072C5B76F7CEAB488172C6F64B30B5E3017E5C00@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3017E5C00@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_NAME_BODY 0, __CP_NAME_SUBJ 0, __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: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ecrit@ietf.org, "Thomson, Martin" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Michael Hammer (mhammer) wrote: > If I were French would I miss the difference between poison and poisson? > > There was a statement earlier that the urn's were protocol elements not > visible to the end-user. > Is that true or not? Yes, that's certainly true. The idea is as follows: The smart address book in your phone contains an entry for all the usual services, but not all of which will be available in the countries that you're visiting. Maybe the poison control service will have the requisite skull symbol on your phone or the appropriate label in your UI language of choice. When you are in a new area, the mobile device queries for the (say) urn:service:sos services. It fills in the services that are supported locally, rather than individually querying for all the services that may or may not be. (Say, mountain rescue in Holland or marine rescue in Switzerland.) The LoST response would include the dial string and, possibly, a service description, using, if possible, the language indicated in the LoST query or whatever languages the local service provider has chosen. Maybe in France the provider description would indicate "does not provide information on selecting fish in restaurants and does not deal with Piranhas." In addition, there might be local services that your phone does not know about. In those cases, depending on the device preferences, these services might be added, with the best-possible locally-provided description. From a protocol perspective, this is all pretty trivial. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 19 13:37:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh8v2-0001wt-40; Fri, 19 May 2006 13:37:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh8v0-0001wo-Gu for ecrit@ietf.org; Fri, 19 May 2006 13:37:42 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh8uz-0007zk-8Q for ecrit@ietf.org; Fri, 19 May 2006 13:37:42 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Fh8ur-0003xi-GM; Fri, 19 May 2006 12:37:33 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Michael Hammer \(mhammer\)'" Subject: RE: List services use case (was Re: [Ecrit] Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) Date: Fri, 19 May 2006 13:37:36 -0400 Message-ID: <04cc01c67b6a$eca4a200$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ7aOQUG8HuF3CrSjav9fDHUxKOLQAAJP1Q In-Reply-To: <446DFEF7.80306@hxr.us> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ecrit@ietf.org, "'Thomson, Martin'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I assure you that "ViPr" (the video telephone I worked on a while ago), could give you a VERY nice UI for this kind of thing, and it indeed would likely first present a very short list of true emergency choices plus a "more" choice. It would be localized, and it would not depend on any prior history. Somehow I think you are missing the big picture I'm describing. I'm thinking someone puts a database together with some kind of xml structure that has things a short name and a brief description, with maybe some flags or categorization, in a variety of languages, and makes it available to a phone that can use that structure, plus the list, to render a useful GUI. Brian -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Friday, May 19, 2006 1:23 PM To: Michael Hammer (mhammer) Cc: Henning Schulzrinne; Brian Rosen; ecrit@ietf.org; Thomson, Martin Subject: Re: List services use case (was Re: [Ecrit] Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) Michael Hammer (mhammer) wrote: > If I were French would I miss the difference between poison and poisson? > > There was a statement earlier that the urn's were protocol elements not > visible to the end-user. > Is that true or not? > > Mike I agree with Mike on this. URNs are protocol elements and should not be shown to the user. And there can be no pretty form for localization if the phone as never encountered the URN before. I'm also a little dubious of any use case that has end users scrolling through a list of emergency services before they make an emergency call. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 19 13:51:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh97d-0003Xk-9x; Fri, 19 May 2006 13:50:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh97b-0003Xe-Ts for ecrit@ietf.org; Fri, 19 May 2006 13:50:43 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh97b-000069-MU for ecrit@ietf.org; Fri, 19 May 2006 13:50:43 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 19 May 2006 10:50:43 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,147,1146466800"; d="scan'208"; a="28447246:sNHT22509296" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4JHoevH005715; Fri, 19 May 2006 13:50:40 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 May 2006 13:50:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: List services use case (was Re: [Ecrit] Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) Date: Fri, 19 May 2006 13:50:39 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E5C36@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: List services use case (was Re: [Ecrit] Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) Thread-Index: AcZ7advomtxu/wstSJW+INL8UUR82wAAr54g From: "Michael Hammer \(mhammer\)" To: "Henning Schulzrinne" X-OriginalArrivalTime: 19 May 2006 17:50:40.0907 (UTC) FILETIME=[BE7B3DB0:01C67B6C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ecrit@ietf.org, "Thomson, Martin" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Agree. I just hadn't seen "language" as an input variable to tailor the output (accompanying text) to the user's language. Mike =20 > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > Sent: Friday, May 19, 2006 1:29 PM > To: Michael Hammer (mhammer) > Cc: Brian Rosen; ecrit@ietf.org; Thomson, Martin > Subject: Re: List services use case (was Re: [Ecrit]=20 > Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) >=20 >=20 >=20 > Michael Hammer (mhammer) wrote: > > If I were French would I miss the difference between poison=20 > and poisson? > >=20 > > There was a statement earlier that the urn's were protocol elements=20 > > not visible to the end-user. > > Is that true or not?=20 >=20 > Yes, that's certainly true. The idea is as follows: >=20 > The smart address book in your phone contains an entry for=20 > all the usual services, but not all of which will be=20 > available in the countries that you're visiting. Maybe the=20 > poison control service will have the requisite skull symbol=20 > on your phone or the appropriate label in your UI language of choice. >=20 > When you are in a new area, the mobile device queries for the=20 > (say) urn:service:sos services. It fills in the services that=20 > are supported locally, rather than individually querying for=20 > all the services that may or may not be. (Say, mountain=20 > rescue in Holland or marine rescue in > Switzerland.) >=20 > The LoST response would include the dial string and,=20 > possibly, a service description, using, if possible, the=20 > language indicated in the LoST query or whatever languages=20 > the local service provider has chosen. Maybe in France the=20 > provider description would indicate "does not provide=20 > information on selecting fish in restaurants and does not=20 > deal with Piranhas." >=20 > In addition, there might be local services that your phone=20 > does not know about. In those cases, depending on the device=20 > preferences, these services might be added, with the=20 > best-possible locally-provided description. >=20 > From a protocol perspective, this is all pretty trivial. >=20 > Henning >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 19 13:53:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9AW-0004up-4R; Fri, 19 May 2006 13:53:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9AV-0004uk-62 for ecrit@ietf.org; Fri, 19 May 2006 13:53:43 -0400 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 1Fh9AT-0000NI-MQ for ecrit@ietf.org; Fri, 19 May 2006 13:53:43 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 19 May 2006 10:53:41 -0700 X-IronPort-AV: i="4.05,147,1146466800"; d="scan'208"; a="322873200:sNHT43017470" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k4JHrelG003183; Fri, 19 May 2006 10:53:40 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4JHreB9009321; Fri, 19 May 2006 10:53:40 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 May 2006 13:53:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: List services use case (was Re: [Ecrit] Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) Date: Fri, 19 May 2006 13:53:39 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E5C39@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: List services use case (was Re: [Ecrit] Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) Thread-Index: AcZ7Zdb7SZ2ZdNmQRvKX5Bn9Vt3/0QAAG1fwAACnswAAAP3RgA== From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Henning Schulzrinne" X-OriginalArrivalTime: 19 May 2006 17:53:40.0249 (UTC) FILETIME=[2960A890:01C67B6D] DKIM-Signature: a=rsa-sha1; q=dns; l=4032; t=1148061220; x=1148925220; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20List=20services=20use=20case=20(was=20Re=3A=20[Ecrit]=20Re=3ACom mmentsI.D-ecrit-service-urn-03=20Child=20helpline); X=v=3Dcisco.com=3B=20h=3DXzP2aBSOS/QZSLTTN4282G3ktQo=3D; b=v5nqE8IEPj4mg7BwUyLZq6vJhNL3L7rH9vDZQI1uk446TkHhaox8mLGbaeG5rki3FTNOSZVC HmaZfQTNPEJWaiqbehPSMdppjStmh1wDkwJmOtmGuT7ue9NIkr0zVBmo; Authentication-Results: sj-dkim-4.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: ecrit@ietf.org, "Thomson, Martin" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org It is the "database somewhere" part that snags me. =20 Will there be a pointer to that database as well? Mike=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Friday, May 19, 2006 1:27 PM > To: Michael Hammer (mhammer); 'Henning Schulzrinne' > Cc: ecrit@ietf.org; 'Thomson, Martin' > Subject: RE: List services use case (was Re: [Ecrit]=20 > Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) >=20 > Yes, that's why we don't really care about the "shape" of the tree. > The URNs are protocol elements; the "name" is not designed to=20 > be shown to a user. That's why I think there is a database=20 > somewhere which has > (localized) information on what these URNs mean. >=20 > The LoST mechanism merely gives you the list of services=20 > available at the current location, which may be much smaller=20 > than the list of all possible service URNs. >=20 > Brian >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, May 19, 2006 1:06 PM > To: Henning Schulzrinne; Brian Rosen > Cc: ecrit@ietf.org; Thomson, Martin > Subject: RE: List services use case (was Re: [Ecrit] > Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) >=20 > If I were French would I miss the difference between poison=20 > and poisson? >=20 > There was a statement earlier that the urn's were protocol=20 > elements not visible to the end-user. =20 > Is that true or not?=20 >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Friday, May 19, 2006 12:59 PM > > To: Brian Rosen > > Cc: ecrit@ietf.org; 'Thomson, Martin' > > Subject: Re: List services use case (was Re: [Ecrit] > > Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) > >=20 > > I agree with Brian. > >=20 > > It seems quite common for GSM phones to show a text message=20 > indicating=20 > > "welcome to Teluristan; you can get concierge services at=20 > *311 and can=20 > > talk to our sales rep at *411." when roaming into a new country or=20 > > service area. The problem with these messages is that they are not=20 > > structured, so there is no easy way for them to be=20 > integrated into the=20 > > phone's address book, for example. With the service listing=20 > proposed,=20 > > this would be fairly straightforward. Given the generic URN service=20 > > names, it would also make it easy to have symbols or=20 > visitor-language=20 > > descriptions on the phone. Thus, tourists could always=20 > easily access=20 > > the local version of the poison control center, for=20 > example, even if=20 > > they have no clue that they'd dial 1-800-222-1222 in the US=20 > for that. > >=20 > > Henning > >=20 > > Brian Rosen wrote: > > > I would imagine that there would be, somewhere, some kind > > of a "pretty > > > print" description of what these services are. The phone > > would access > > > this along with the list of service urns available at their > > location > > > and offer an interesting GUI for what it finds. > > >=20 > > > Brian > > >=20 > > > -----Original Message----- > > > From: Andrew Newton [mailto:andy@hxr.us] > > > Sent: Friday, May 19, 2006 12:46 PM > > > To: Brian Rosen > > > Cc: 'Henning Schulzrinne'; ecrit@ietf.org; 'Thomson, Martin' > > > Subject: Re: List services use case (was Re: [Ecrit] Re: > > > CommmentsI.D-ecrit-service-urn-03 Child helpline) > > >=20 > > > Brian Rosen wrote: > > >> While I can see some really smart phones trying to make > > sense out of > > >> the list, in my mind the purpose here is to develop a > > COMPLETE list > > >> of dial strings that need to be recognized and translated > > into service URNs. > > >=20 > > > Exactly what "smart" thing would they do? > > >=20 > > > -andy > >=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 From ecrit-bounces@ietf.org Fri May 19 13:55:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9CM-0005Lj-Ua; Fri, 19 May 2006 13:55:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9CL-0005Le-Lr for ecrit@ietf.org; Fri, 19 May 2006 13:55:37 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh9CJ-0000Tm-Dr for ecrit@ietf.org; Fri, 19 May 2006 13:55:37 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Fri, 19 May 2006 13:56:01 -0400 id 0158801F.446E06B2.00007D6F Message-ID: <446E068A.7080704@hxr.us> Date: Fri, 19 May 2006 13:55:22 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Brian Rosen Subject: Re: List services use case (was Re: [Ecrit] Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) References: <04cc01c67b6a$eca4a200$640fa8c0@cis.neustar.com> In-Reply-To: <04cc01c67b6a$eca4a200$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: "'Thomson, Martin'" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I understand how software localization works. But software cannot localize well known values it has no knowledge of (think 2 year old firmware and an ever increasing IANA registry). Additionally, the "more choices" menu idea is fine while surfing the web casually, but it is a horrible idea for emergency calls. How do we determine precedence order for which emergency service is on the first screen? How do we avoid "Fire" being on screen 4? -andy ps. actually, the "more choices" on every cell phone I've ever used is infuriating... and I can only imagine the additional frustration while attempting to do so while my house is on fire. Brian Rosen wrote: > I assure you that "ViPr" (the video telephone I worked on a while ago), > could give you a VERY nice UI for this kind of thing, and it indeed would > likely first present a very short list of true emergency choices plus a > "more" choice. It would be localized, and it would not depend on any prior > history. > > Somehow I think you are missing the big picture I'm describing. > I'm thinking someone puts a database together with some kind of xml > structure that has things a short name and a brief description, with maybe > some flags or categorization, in a variety of languages, and makes it > available to a phone that can use that structure, plus the list, to render a > useful GUI. > > Brian > > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Friday, May 19, 2006 1:23 PM > To: Michael Hammer (mhammer) > Cc: Henning Schulzrinne; Brian Rosen; ecrit@ietf.org; Thomson, Martin > Subject: Re: List services use case (was Re: [Ecrit] > Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) > > Michael Hammer (mhammer) wrote: >> If I were French would I miss the difference between poison and poisson? >> >> There was a statement earlier that the urn's were protocol elements not >> visible to the end-user. >> Is that true or not? >> >> Mike > > I agree with Mike on this. URNs are protocol elements and should not be > shown to the user. And there can be no pretty form for localization if > the phone as never encountered the URN before. > > I'm also a little dubious of any use case that has end users scrolling > through a list of emergency services before they make an emergency call. > > -andy > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 19 14:01:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9I6-0005d5-8B; Fri, 19 May 2006 14:01:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9I5-0005d0-IK for ecrit@ietf.org; Fri, 19 May 2006 14:01:33 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh9I3-0000sO-9P for ecrit@ietf.org; Fri, 19 May 2006 14:01:33 -0400 Received: from lion.cs.columbia.edu (IDENT:Sp6MBhSJQoMb2tdyUPDOyh0PfMUNEnn9@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k4JI18X6013561 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 19 May 2006 14:01:28 -0400 (EDT) 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 k4JI17BB016012 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 19 May 2006 14:01:08 -0400 Message-ID: <446E07DE.3070702@cs.columbia.edu> Date: Fri, 19 May 2006 14:01:02 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Andrew Newton Subject: Re: List services use case (was Re: [Ecrit] Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) References: <04cc01c67b6a$eca4a200$640fa8c0@cis.neustar.com> <446E068A.7080704@hxr.us> In-Reply-To: <446E068A.7080704@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_AGE_BODY 0, __CP_NAME_BODY 0, __CP_NAME_SUBJ 0, __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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org You are positing, I believe, a false choice. Nobody is suggesting replacing dialing 911 or 112 with scrolling through a list of emergency services, as long as "dialing" is still the predominant user interface metaphor. (For Brian's Vipr, I suspect that it is not.) I chose the poison control example for a reason - almost everyone will have to consult their phone book to find the number and there's essentially no hope for me to find that number when I'm visiting a foreign country. Andrew Newton wrote: > I understand how software localization works. But software cannot > localize well known values it has no knowledge of (think 2 year old > firmware and an ever increasing IANA registry). > > Additionally, the "more choices" menu idea is fine while surfing the web > casually, but it is a horrible idea for emergency calls. How do we > determine precedence order for which emergency service is on the first > screen? How do we avoid "Fire" being on screen 4? > > -andy > > ps. actually, the "more choices" on every cell phone I've ever used is > infuriating... and I can only imagine the additional frustration while > attempting to do so while my house is on fire. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 19 14:17:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9XQ-0007B0-2a; Fri, 19 May 2006 14:17:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9XO-0007Av-Um for ecrit@ietf.org; Fri, 19 May 2006 14:17:22 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh9XO-0001c5-P0 for ecrit@ietf.org; Fri, 19 May 2006 14:17:22 -0400 Received: from lion.cs.columbia.edu (IDENT:LYip2cykdYtRhVcPZq00aaQD2cj5vNK1@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k4JIH9X6018932 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 19 May 2006 14:17:19 -0400 (EDT) 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 k4JIH7BB018222 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 19 May 2006 14:17:09 -0400 Message-ID: <446E0B9E.5010102@cs.columbia.edu> Date: Fri, 19 May 2006 14:17:02 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: List services use case (was Re: [Ecrit] Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) References: <072C5B76F7CEAB488172C6F64B30B5E3017E5C39@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3017E5C39@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_NAME_BODY 0, __CP_NAME_SUBJ 0, __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: d17f825e43c9aed4fd65b7edddddec89 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Michael Hammer (mhammer) wrote: > It is the "database somewhere" part that snags me. > Will there be a pointer to that database as well? This information could easily be contained in the LoST record for the URN and location; I believe the current schema (where "current" is somewhat fuzzy...) contains such descriptive information. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 19 14:26:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9fc-0002bl-P6; Fri, 19 May 2006 14:25:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9fb-0002a2-Ur for ecrit@ietf.org; Fri, 19 May 2006 14:25:51 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh9fb-0001x8-Ow for ecrit@ietf.org; Fri, 19 May 2006 14:25:51 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Fri, 19 May 2006 14:26:26 -0400 id 0158802E.446E0DD2.000004A6 Message-ID: <446E0DAB.3040203@hxr.us> Date: Fri, 19 May 2006 14:25:47 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: List services use case (was Re: [Ecrit] Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) References: <04cc01c67b6a$eca4a200$640fa8c0@cis.neustar.com> <446E068A.7080704@hxr.us> <446E07DE.3070702@cs.columbia.edu> In-Reply-To: <446E07DE.3070702@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org So this needs to be in the phone BCP. And for UAs that do not use dialing as their predominant user interface, they should try to use some standard or well-known, easy to use mechanism that is equivalent to urn:service:sos. Does that make sense? -andy Henning Schulzrinne wrote: > You are positing, I believe, a false choice. Nobody is suggesting > replacing dialing 911 or 112 with scrolling through a list of emergency > services, as long as "dialing" is still the predominant user interface > metaphor. (For Brian's Vipr, I suspect that it is not.) > > I chose the poison control example for a reason - almost everyone will > have to consult their phone book to find the number and there's > essentially no hope for me to find that number when I'm visiting a > foreign country. > > Andrew Newton wrote: >> I understand how software localization works. But software cannot >> localize well known values it has no knowledge of (think 2 year old >> firmware and an ever increasing IANA registry). >> >> Additionally, the "more choices" menu idea is fine while surfing the >> web casually, but it is a horrible idea for emergency calls. How do >> we determine precedence order for which emergency service is on the >> first screen? How do we avoid "Fire" being on screen 4? >> >> -andy >> >> ps. actually, the "more choices" on every cell phone I've ever used is >> infuriating... and I can only imagine the additional frustration while >> attempting to do so while my house is on fire. >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 19 14:49:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhA1r-0004mD-Ii; Fri, 19 May 2006 14:48:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhA1q-0004iq-0x for ecrit@ietf.org; Fri, 19 May 2006 14:48:50 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhA1o-00044S-Jn for ecrit@ietf.org; Fri, 19 May 2006 14:48:50 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4JImjt0011410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 19 May 2006 11:48:45 -0700 Received: from [129.46.225.88] (dhcp-campbell-28.qualcomm.com [129.46.225.88]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4JImhZp017592; Fri, 19 May 2006 11:48:44 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <446DD9B2.1020607@gmx.net> References: <446DD9B2.1020607@gmx.net> Date: Fri, 19 May 2006 11:48:41 -0700 To: Hannes Tschofenig , ecrit@ietf.org From: Ted Hardie Subject: Re: [Ecrit] Summary of Recent Discussion Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 4:44 PM +0200 5/19/06, Hannes Tschofenig wrote: >Various failure cases in LoST need to be carefully analysed. E.g., A person asks for "urn:service:sos.fire" but only ""urn:service:sos" is available. What would happen? This item and the last one are related to each other. The LoST server should return the contact URI for urn:service:sos along with the URN it used for the mapping. The phone will get a useful contact, and it will know that the location actually derived from a "default" emergency service urn, rather than the specific. Note: I don't think this should work like tree walking. There should be a single default (urn:service:sos for emergency services). If the LoST server does not have the sos.$var you asked for, it *always* goes back to the default. I think this reinforces the idea that you separate emergency services from counselling services or non-emergency public support; they may have a different default, but they certainly should not be sent to the emergency default. Ted >* Henning suggested to extend LoST to return additional information regarding the service (e.g., location information needed). This discussion is relevant for LoST. I can see that there was support for his proposal. This aspect does not need to be captured in the requirements draft. > >* Child helpline >Henning has already captured the child helpline service identifier after a discussion on the mailing list: http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service-urn-03.txt). >(see urn:service:counseling.children) > >* Requirements draft >Roger mentioned a few open issues with the document where he would appreciate input. A final review would help to finish the document. > >Ciao >Hannes > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 19 14:50:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhA3d-0005sB-CY; Fri, 19 May 2006 14:50:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhA3c-0005s6-3p for ecrit@ietf.org; Fri, 19 May 2006 14:50:40 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhA3Z-0004N0-T8 for ecrit@ietf.org; Fri, 19 May 2006 14:50:40 -0400 Received: from lion.cs.columbia.edu (IDENT:GjeYubbdUVg9yUfxLOppWnDn5+8EbbdZ@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k4JIkbX6028760 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 19 May 2006 14:50:37 -0400 (EDT) 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 k4JIkaBB021098 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 19 May 2006 14:46:37 -0400 Message-ID: <446E1287.10706@cs.columbia.edu> Date: Fri, 19 May 2006 14:46:31 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Andrew Newton Subject: Re: List services use case (was Re: [Ecrit] Re:CommmentsI.D-ecrit-service-urn-03 Child helpline) References: <04cc01c67b6a$eca4a200$640fa8c0@cis.neustar.com> <446E068A.7080704@hxr.us> <446E07DE.3070702@cs.columbia.edu> <446E0DAB.3040203@hxr.us> In-Reply-To: <446E0DAB.3040203@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Indeed. In some cases, particularly where there is no easily accessible dial pad in the UI, this may involve a user-confirmed UI interaction (as opposed to just the mis-dial prone "big red emergency button"). Andrew Newton wrote: > So this needs to be in the phone BCP. And for UAs that do not use > dialing as their predominant user interface, they should try to use some > standard or well-known, easy to use mechanism that is equivalent to > urn:service:sos. > > Does that make sense? > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 19 15:01:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhADx-0001zP-Gl; Fri, 19 May 2006 15:01:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhADw-0001zK-Ug for ecrit@ietf.org; Fri, 19 May 2006 15:01:20 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhADu-0004oG-In for ecrit@ietf.org; Fri, 19 May 2006 15:01:20 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FhADi-0003Gu-Om; Fri, 19 May 2006 14:01:07 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Hannes Tschofenig'" , Subject: RE: [Ecrit] Summary of Recent Discussion Date: Fri, 19 May 2006 15:01:10 -0400 Message-ID: <04e101c67b76$9922f440$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ7dOcVnCyFef+mQWWy0imZa0j0dwAAM3hw In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Nope, that won't work. In some countries, there is no sos single service. In other countries, if there is no fire number, there is ONLY the top level sos (with respect to fire). The database has to know this (but that's okay, because it's all local data, as is all the data in the database). If you query with sos, and there is no sos, there will be a local decision of what to return. In most cases, I'd expect they would decide to return sos.police. If you query sos.police in North America, you will definitely get back the sos URI (and presumably the sos URN). It could be that you get back an error (in this jurisdiction, there is no such service, and we want you to do it over). This lets it be a local decision if humanServices.child gets you sos.police. Brian -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com] Sent: Friday, May 19, 2006 2:49 PM To: Hannes Tschofenig; ecrit@ietf.org Subject: Re: [Ecrit] Summary of Recent Discussion At 4:44 PM +0200 5/19/06, Hannes Tschofenig wrote: >Various failure cases in LoST need to be carefully analysed. E.g., A person asks for "urn:service:sos.fire" but only ""urn:service:sos" is available. What would happen? This item and the last one are related to each other. The LoST server should return the contact URI for urn:service:sos along with the URN it used for the mapping. The phone will get a useful contact, and it will know that the location actually derived from a "default" emergency service urn, rather than the specific. Note: I don't think this should work like tree walking. There should be a single default (urn:service:sos for emergency services). If the LoST server does not have the sos.$var you asked for, it *always* goes back to the default. I think this reinforces the idea that you separate emergency services from counselling services or non-emergency public support; they may have a different default, but they certainly should not be sent to the emergency default. Ted >* Henning suggested to extend LoST to return additional information regarding the service (e.g., location information needed). This discussion is relevant for LoST. I can see that there was support for his proposal. This aspect does not need to be captured in the requirements draft. > >* Child helpline >Henning has already captured the child helpline service identifier after a discussion on the mailing list: http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service-urn-03 .txt). >(see urn:service:counseling.children) > >* Requirements draft >Roger mentioned a few open issues with the document where he would appreciate input. A final review would help to finish the document. > >Ciao >Hannes > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 19 16:22:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhBUE-00035j-0S; Fri, 19 May 2006 16:22:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhBUC-00035e-QY for ecrit@ietf.org; Fri, 19 May 2006 16:22:12 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FhBU9-0002KR-7q for ecrit@ietf.org; Fri, 19 May 2006 16:22:12 -0400 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] Summary of Recent Discussion Date: Fri, 19 May 2006 22:26:11 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A4E@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Summary of Recent Discussion Thread-Index: AcZ7dOcVnCyFef+mQWWy0imZa0j0dwAAM3hwAAMBWlY= From: "Stastny Richard" To: "Brian Rosen" , "Ted Hardie" , "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I support this. It is a local decision if child.help is a counselling = service or an emergency service you may even have both. - A conselling service for giving children advice in case they have = problems with their parents or teachers (this may also anonymous) - and an emergency service for children brought by slave-traders into another country (here a location is very useful, because the child may have no idea where it is and may also may not talk the language) This was basically the service CHI requested =20 Richard =20 ________________________________ Von: Brian Rosen [mailto:br@brianrosen.net] Gesendet: Fr 19.05.2006 21:01 An: 'Ted Hardie'; 'Hannes Tschofenig'; ecrit@ietf.org Betreff: RE: [Ecrit] Summary of Recent Discussion Nope, that won't work. In some countries, there is no sos single service. In other countries, = if there is no fire number, there is ONLY the top level sos (with respect = to fire). The database has to know this (but that's okay, because it's all local = data, as is all the data in the database). If you query with sos, and there = is no sos, there will be a local decision of what to return. In most cases, = I'd expect they would decide to return sos.police. If you query sos.police = in North America, you will definitely get back the sos URI (and presumably = the sos URN). It could be that you get back an error (in this jurisdiction, there is no such service, and we want you to do it over). This lets it be a local decision if humanServices.child gets you = sos.police. Brian -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com] Sent: Friday, May 19, 2006 2:49 PM To: Hannes Tschofenig; ecrit@ietf.org Subject: Re: [Ecrit] Summary of Recent Discussion At 4:44 PM +0200 5/19/06, Hannes Tschofenig wrote: >Various failure cases in LoST need to be carefully analysed. E.g., A = person asks for "urn:service:sos.fire" but only ""urn:service:sos" is = available. What would happen? This item and the last one are related to each other. The LoST server should return the contact URI for urn:service:sos along = with the URN it used for the mapping. The phone will get a useful contact, = and it will know that the location actually derived from a "default" = emergency service urn, rather than the specific. Note: I don't think this should work like tree walking. There should = be a single default (urn:service:sos for emergency services). If the LoST server = does not have the sos.$var you asked for, it *always* goes back to the default. = I think this reinforces the idea that you separate emergency services from counselling services or non-emergency public support; they may have a different = default, but they certainly should not be sent to the emergency default. Ted >* Henning suggested to extend LoST to return additional information regarding the service (e.g., location information needed). This = discussion is relevant for LoST. I can see that there was support for his proposal. This aspect does not need to be captured in the requirements draft. > >* Child helpline >Henning has already captured the child helpline service identifier = after a discussion on the mailing list: http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service-urn= -03 .txt). >(see urn:service:counseling.children) > >* Requirements draft >Roger mentioned a few open issues with the document where he would appreciate input. A final review would help to finish the document. > >Ciao >Hannes > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 19 17:16:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhCKV-00022f-4R; Fri, 19 May 2006 17:16:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhCKU-00022a-Cs for ecrit@ietf.org; Fri, 19 May 2006 17:16:14 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhCKQ-0006LY-IL for ecrit@ietf.org; Fri, 19 May 2006 17:16:14 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4JLFslx026777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 19 May 2006 14:15:54 -0700 Received: from [129.46.225.88] (dhcp-campbell-28.qualcomm.com [129.46.225.88]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4JLFqdg009072; Fri, 19 May 2006 14:15:53 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4A4E@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C4A4E@oefeg-s04.oefeg.loc> Date: Fri, 19 May 2006 14:15:51 -0700 To: "Stastny Richard" , "Brian Rosen" , "Hannes Tschofenig" , From: Ted Hardie Subject: Re: [Ecrit] Summary of Recent Discussion Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Continuing the top posting meme, the LoST protocol mechanism appears to be: "Return the urn for which this is a mapping, so the client knows if it is changed". I think the rest of Brian's cases are, in essence, default mappings, where one service (e.g. sos.police) is doing double duty as something else (e.g sos). I would also argue that it would be better in that case to populate the default URN (sos)'s LoST data with the same data as (sos.police) as a direct, effective way of handling that. That means you don't have to do a server configuration mapping step to say "return sos.police to sos queries". Still, I agree that returning the service URN that is associated with the responder may be appropriate, as there may be cases where that will cause the caller to make some decision (e.g. drop the call if they were calling in a police brutality sighting). I think that should not be a protocol error, in other words, but I think we should be strongly pushing for a BCP of urn:service:sos being a populated item in the LoST emergency server; it really does help interoperability here to have a default. This is also where I can't tell whether I agree with Richard or not. The local LoST server should return to you the contact URI of the URN associated with your query. What that URN means should be globally known, not purely based on local custom, or roaming folks are going to be overly surprised. If it isn't sufficiently well described to distinguish between a "my parents make me do chores" counselling service and an emergency child-slave rescue service, then something is wrong. In a local context, it is, of course, possible that the same folks respond to both, because they have been trained to do so. But the services are distinct. If Richard is talking about what the mapping should be in the absence of a service listing, that may be local (should the child slave talk to a counsellor trained to talk to kids, or a policeman trained in dealing with lawbreakers like child slavers?) If he's saying that the local folks should decide that urn:service:help:child should be whatever the local folks say it should mean, that's not globally appropriate. urn:service:help:child.counselling and urn:service:sos:child.rescue should be distinguishable. regards, Ted At 10:26 PM +0200 5/19/06, Stastny Richard wrote: >I support this. It is a local decision if child.help is a counselling service or an emergency service >you may even have both. > >- A conselling service for giving children advice in case they have problems with their parents >or teachers (this may also anonymous) >- and an emergency service for children brought by slave-traders into >another country (here a location is very useful, because the child >may have no idea where it is and may also may not talk the language) > >This was basically the service CHI requested > >Richard > > >________________________________ > >Von: Brian Rosen [mailto:br@brianrosen.net] >Gesendet: Fr 19.05.2006 21:01 >An: 'Ted Hardie'; 'Hannes Tschofenig'; ecrit@ietf.org >Betreff: RE: [Ecrit] Summary of Recent Discussion > > > >Nope, that won't work. > >In some countries, there is no sos single service. In other countries, if >there is no fire number, there is ONLY the top level sos (with respect to >fire). > >The database has to know this (but that's okay, because it's all local data, >as is all the data in the database). If you query with sos, and there is no >sos, there will be a local decision of what to return. In most cases, I'd >expect they would decide to return sos.police. If you query sos.police in >North America, you will definitely get back the sos URI (and presumably the >sos URN). It could be that you get back an error (in this jurisdiction, >there is no such service, and we want you to do it over). > >This lets it be a local decision if humanServices.child gets you sos.police. > >Brian > >-----Original Message----- >From: Ted Hardie [mailto:hardie@qualcomm.com] >Sent: Friday, May 19, 2006 2:49 PM >To: Hannes Tschofenig; ecrit@ietf.org >Subject: Re: [Ecrit] Summary of Recent Discussion > >At 4:44 PM +0200 5/19/06, Hannes Tschofenig wrote: >>Various failure cases in LoST need to be carefully analysed. E.g., A person >asks for "urn:service:sos.fire" but only ""urn:service:sos" is available. >What would happen? This item and the last one are related to each other. > >The LoST server should return the contact URI for urn:service:sos along with >the URN it used for the mapping. The phone will get a useful contact, and >it will know that the location actually derived from a "default" emergency >service urn, rather than the specific. > >Note: I don't think this should work like tree walking. There should be a >single >default (urn:service:sos for emergency services). If the LoST server does >not >have the sos.$var you asked for, it *always* goes back to the default. I >think >this reinforces the idea that you separate emergency services from >counselling >services or non-emergency public support; they may have a different default, >but they certainly should not be sent to the emergency default. > > Ted > > > > > > > >>* Henning suggested to extend LoST to return additional information >regarding the service (e.g., location information needed). This discussion >is relevant for LoST. I can see that there was support for his proposal. >This aspect does not need to be captured in the requirements draft. >> >>* Child helpline >>Henning has already captured the child helpline service identifier after a >discussion on the mailing list: >http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service-urn-03 >.txt). >>(see urn:service:counseling.children) >> >>* Requirements draft >>Roger mentioned a few open issues with the document where he would >appreciate input. A final review would help to finish the document. >> >>Ciao >>Hannes >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 19 18:05:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhD6M-0000Ua-7X; Fri, 19 May 2006 18:05:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhD6L-0000UQ-8A for ecrit@ietf.org; Fri, 19 May 2006 18:05:41 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FhD6I-0001dl-Fn for ecrit@ietf.org; Fri, 19 May 2006 18:05:41 -0400 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] Summary of Recent Discussion Date: Sat, 20 May 2006 00:05:24 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A4F@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Summary of Recent Discussion Thread-Index: AcZ7igowZF54dG7ART2zeTqM37bLdAABkoqX From: "Stastny Richard" To: "Ted Hardie" , "Brian Rosen" , "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Ted,=20 =20 >This is also where I can't tell whether I agree with Richard or not. I also do not know if I agree with you ;-) =20 >From an IETF point of view I agree with you that only a globally unique definition makes sense =20 OTOH, having been nearly for two weeks in Geneva, where every second sentence ends with: this is a national matter .... =20 regards Richard =20 ________________________________ Von: Ted Hardie [mailto:hardie@qualcomm.com] Gesendet: Fr 19.05.2006 23:15 An: Stastny Richard; Brian Rosen; Hannes Tschofenig; ecrit@ietf.org Betreff: Re: [Ecrit] Summary of Recent Discussion Continuing the top posting meme, the LoST protocol mechanism appears to = be: "Return the urn for which this is a mapping, so the client knows if it = is changed". I think the rest of Brian's cases are, in essence, default mappings, = where one service (e.g. sos.police) is doing double duty as something else (e.g = sos). I would also argue that it would be better in that case to populate the default URN (sos)'s LoST data with the same data as (sos.police) as a direct, effective way of handling that. That means you don't have = to do a server configuration mapping step to say "return sos.police to sos = queries". Still, I agree that returning the service URN that is associated with = the responder may be appropriate, as there may be cases where that will cause the = caller to make some decision (e.g. drop the call if they were calling in a police = brutality sighting). I think that should not be a protocol error, in other words, = but I think we should be strongly pushing for a BCP of urn:service:sos being a = populated item in the LoST emergency server; it really does help interoperability = here to have a default. This is also where I can't tell whether I agree with Richard or not. = The local LoST server should return to you the contact URI of the URN associated with = your query. What that URN means should be globally known, not purely based = on local custom, or roaming folks are going to be overly surprised. If it = isn't sufficiently well described to distinguish between a "my parents make me do chores" = counselling service and an emergency child-slave rescue service, then something is = wrong. In a local context, it is, of course, possible that the same folks = respond to both, because they have been trained to do so. But the services are distinct. If Richard is talking about what the mapping should be in the absence of = a service listing, that may be local (should the child slave talk to a = counsellor trained to talk to kids, or a policeman trained in dealing with lawbreakers like = child slavers?) If he's saying that the local folks should decide that = urn:service:help:child should be whatever the local folks say it should mean, that's not globally = appropriate. urn:service:help:child.counselling and urn:service:sos:child.rescue = should be distinguishable. regards, =20 Ted At 10:26 PM +0200 5/19/06, Stastny Richard wrote: >I support this. It is a local decision if child.help is a counselling = service or an emergency service >you may even have both. > >- A conselling service for giving children advice in case they have = problems with their parents >or teachers (this may also anonymous) >- and an emergency service for children brought by slave-traders into >another country (here a location is very useful, because the child >may have no idea where it is and may also may not talk the language) > >This was basically the service CHI requested > >Richard > > >________________________________ > >Von: Brian Rosen [mailto:br@brianrosen.net] >Gesendet: Fr 19.05.2006 21:01 >An: 'Ted Hardie'; 'Hannes Tschofenig'; ecrit@ietf.org >Betreff: RE: [Ecrit] Summary of Recent Discussion > > > >Nope, that won't work. > >In some countries, there is no sos single service. In other countries, = if >there is no fire number, there is ONLY the top level sos (with respect = to >fire). > >The database has to know this (but that's okay, because it's all local = data, >as is all the data in the database). If you query with sos, and there = is no >sos, there will be a local decision of what to return. In most cases, = I'd >expect they would decide to return sos.police. If you query sos.police = in >North America, you will definitely get back the sos URI (and presumably = the >sos URN). It could be that you get back an error (in this = jurisdiction, >there is no such service, and we want you to do it over). > >This lets it be a local decision if humanServices.child gets you = sos.police. > >Brian > >-----Original Message----- >From: Ted Hardie [mailto:hardie@qualcomm.com] >Sent: Friday, May 19, 2006 2:49 PM >To: Hannes Tschofenig; ecrit@ietf.org >Subject: Re: [Ecrit] Summary of Recent Discussion > >At 4:44 PM +0200 5/19/06, Hannes Tschofenig wrote: >>Various failure cases in LoST need to be carefully analysed. E.g., A = person >asks for "urn:service:sos.fire" but only ""urn:service:sos" is = available. >What would happen? This item and the last one are related to each = other. > >The LoST server should return the contact URI for urn:service:sos along = with >the URN it used for the mapping. The phone will get a useful contact, = and >it will know that the location actually derived from a "default" = emergency >service urn, rather than the specific. > >Note: I don't think this should work like tree walking. There should = be a >single >default (urn:service:sos for emergency services). If the LoST server = does >not >have the sos.$var you asked for, it *always* goes back to the default. = I >think >this reinforces the idea that you separate emergency services from >counselling >services or non-emergency public support; they may have a different = default, >but they certainly should not be sent to the emergency default. > > Ted > > > > > > > >>* Henning suggested to extend LoST to return additional information >regarding the service (e.g., location information needed). This = discussion >is relevant for LoST. I can see that there was support for his = proposal. >This aspect does not need to be captured in the requirements draft. >> >>* Child helpline >>Henning has already captured the child helpline service identifier = after a >discussion on the mailing list: >http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service-ur= n-03 >.txt). >>(see urn:service:counseling.children) >> >>* Requirements draft >>Roger mentioned a few open issues with the document where he would >appreciate input. A final review would help to finish the document. >> >>Ciao >>Hannes >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 19 18:50:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhDnH-0001JA-Tl; Fri, 19 May 2006 18:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhDnG-0001If-O6; Fri, 19 May 2006 18:50:02 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhDnG-0004eB-Gf; Fri, 19 May 2006 18:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k4JMo11I026782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 May 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FhDnF-00074y-BH; Fri, 19 May 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 19 May 2006 18:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-service-urn-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : A Uniform Resource Name (URN) for Services Author(s) : H. Schulzrinne Filename : draft-ietf-ecrit-service-urn-03.txt Pages : 15 Date : 2006-5-19 The content of many communication services depends on the context, such as the user's location. We describe a 'service' URN that allows to register such context-dependent services that can be resolved in a distributed manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-service-urn-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-service-urn-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-19152507.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-service-urn-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-service-urn-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-19152507.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Sat May 20 02:07:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhKch-0001tO-Tn; Sat, 20 May 2006 02:07:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhKcg-0001tI-PR for ecrit@ietf.org; Sat, 20 May 2006 02:07:34 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhKcf-0008M9-DM for ecrit@ietf.org; Sat, 20 May 2006 02:07:34 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 19 May 2006 23:07:33 -0700 X-IronPort-AV: i="4.05,149,1146466800"; d="scan'208"; a="280003753:sNHT33083300" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k4K67Wq0004266; Fri, 19 May 2006 23:07:32 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k4K67WHc003475; Fri, 19 May 2006 23:07:32 -0700 (PDT) Received: from [127.0.0.1] (ssh-ams-1.cisco.com [144.254.226.40]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4K64mBB003530; Fri, 19 May 2006 23:04:52 -0700 In-Reply-To: <446DF95B.9070400@cs.columbia.edu> References: <04c201c67b64$75359630$640fa8c0@cis.neustar.com> <446DF95B.9070400@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8A52DA28-5F26-4DE1-A47F-61769A70CE2E@cisco.com> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: List services use case (was Re: [Ecrit] Re: CommmentsI.D-ecrit-service-urn-03 Child helpline) Date: Sat, 20 May 2006 08:07:22 +0200 To: Henning Schulzrinne X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-2.cisco.com; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=3196; t=1148105252; x=1148969252; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20 |Subject:Re=3A=20List=20services=20use=20case=20(was=20Re=3A=20[Ecrit]=20Re=3A=20 CommmentsI.D-ecrit-service-urn-03=20Child=20helpline); X=v=3Dcisco.com=3B=20h=3D/7WKfwPhfg/za6z1CXVljwI793o=3D; b=dBIc2CR1x9gZDyWAgH1AfKl1BfWoO2/ptflWb8+LYKGwosL64/N517fQdMD6EPzqT14AR10C qPFFaF5uGO40v5Du/TWPak1MRLSh9TsQp3lfHCEn83ObYbDs7B4XKAdc; X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ecrit@ietf.org, "'Thomson, Martin'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org First of all I always think a phone have some priming information in it. It is configured for "normal" use. For example how to use it where it normally is. Given this information, the phone only need to know where it is, send a query to the "home listing service" and get temporary reprogramming of whatever features should work differently where the phone is now. Personally I am quite irritated on the sms messages I get when I roam into a new providers network. Specifically when the foreign network change N times the first M hours where neither N or M is large. Including roaming into the same network a few times the first day. Much better to allow "my home provider" to have this as a service, or create the ability for "google's" all over the world to sell listing services to the users. "I am at the moment in Istanbul" is a pretty simple message I can even give to my phone manually (so that timezone is changed, 112/911, listing, best restaurant etc all are changed). I already do this on my phone, to set the timezone, so why can this operation not automatically set other things as well? Patrik On 19 maj 2006, at 18.59, Henning Schulzrinne wrote: > I agree with Brian. > > It seems quite common for GSM phones to show a text message > indicating "welcome to Teluristan; you can get concierge services > at *311 and can talk to our sales rep at *411." when roaming into a > new country or service area. The problem with these messages is > that they are not structured, so there is no easy way for them to > be integrated into the phone's address book, for example. With the > service listing proposed, this would be fairly straightforward. > Given the generic URN service names, it would also make it easy to > have symbols or visitor-language descriptions on the phone. Thus, > tourists could always easily access the local version of the poison > control center, for example, even if they have no clue that they'd > dial 1-800-222-1222 in the US for that. > > Henning > > Brian Rosen wrote: >> I would imagine that there would be, somewhere, some kind of a >> "pretty >> print" description of what these services are. The phone would >> access this >> along with the list of service urns available at their location >> and offer an >> interesting GUI for what it finds. >> Brian >> -----Original Message----- >> From: Andrew Newton [mailto:andy@hxr.us] Sent: Friday, May 19, >> 2006 12:46 PM >> To: Brian Rosen >> Cc: 'Henning Schulzrinne'; ecrit@ietf.org; 'Thomson, Martin' >> Subject: Re: List services use case (was Re: [Ecrit] Re: >> CommmentsI.D-ecrit-service-urn-03 Child helpline) >> Brian Rosen wrote: >>> While I can see some really smart phones trying to make sense out >>> of the >>> list, in my mind the purpose here is to develop a COMPLETE list >>> of dial >>> strings that need to be recognized and translated into service URNs. >> Exactly what "smart" thing would they do? >> -andy > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 20 09:08:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhRB7-0006BR-7x; Sat, 20 May 2006 09:07:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhRB6-0006BM-E3 for ecrit@ietf.org; Sat, 20 May 2006 09:07:32 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhRB4-0007Y1-1q for ecrit@ietf.org; Sat, 20 May 2006 09:07:32 -0400 Received: from [192.168.0.41] (pool-138-89-20-236.mad.east.verizon.net [138.89.20.236]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k4KD7Q0k017790 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 20 May 2006 09:07:26 -0400 (EDT) In-Reply-To: <8A52DA28-5F26-4DE1-A47F-61769A70CE2E@cisco.com> References: <04c201c67b64$75359630$640fa8c0@cis.neustar.com> <446DF95B.9070400@cs.columbia.edu> <8A52DA28-5F26-4DE1-A47F-61769A70CE2E@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Henning Schulzrinne Subject: Re: List services use case (was Re: [Ecrit] Re: CommmentsI.D-ecrit-service-urn-03 Child helpline) Date: Sat, 20 May 2006 09:07:23 -0400 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Patrik, I'm not quite sure if you're agreeing or disagreeing with the general =20= gist of my statement. In any event, I think I'm agreeing with you =20 that having a way to localize services based on my current location =20 is a good thing and SMS (or other human-readable) messages are not =20 really a good approximation of such automatic localization. They =20 simply indicate that there's a need for such information and that =20 service provider have an incentive to provide pointers to such =20 localized services. I'd like to make them work better for both sides. While this is outside the scope of ECRIT, LoST is general enough to =20 manage pointers to other local services, such as the restaurant =20 finder you mention. My current thinking is that this would be =20 something like urn:service:info.* (As described in the current =20 service URN draft, each top-level service can have its own LoST =20 server hierarchy, so the provider of LoST mapping for emergency =20 services doesn't have to worry about informational services and vice =20 versa.) Henning On May 20, 2006, at 2:07 AM, Patrik F=E4ltstr=F6m wrote: > First of all I always think a phone have some priming information =20 > in it. It is configured for "normal" use. For example how to use it =20= > where it normally is. > > Given this information, the phone only need to know where it is, =20 > send a query to the "home listing service" and get temporary =20 > reprogramming of whatever features should work differently where =20 > the phone is now. > > Personally I am quite irritated on the sms messages I get when I =20 > roam into a new providers network. Specifically when the foreign =20 > network change N times the first M hours where neither N or M is =20 > large. Including roaming into the same network a few times the =20 > first day. > > Much better to allow "my home provider" to have this as a service, =20 > or create the ability for "google's" all over the world to sell =20 > listing services to the users. > > "I am at the moment in Istanbul" is a pretty simple message I can =20 > even give to my phone manually (so that timezone is changed, =20 > 112/911, listing, best restaurant etc all are changed). > > I already do this on my phone, to set the timezone, so why can this =20= > operation not automatically set other things as well? > > Patrik > > On 19 maj 2006, at 18.59, Henning Schulzrinne wrote: > >> I agree with Brian. >> >> It seems quite common for GSM phones to show a text message =20 >> indicating "welcome to Teluristan; you can get concierge services =20 >> at *311 and can talk to our sales rep at *411." when roaming into =20 >> a new country or service area. The problem with these messages is =20 >> that they are not structured, so there is no easy way for them to =20 >> be integrated into the phone's address book, for example. With the =20= >> service listing proposed, this would be fairly straightforward. =20 >> Given the generic URN service names, it would also make it easy to =20= >> have symbols or visitor-language descriptions on the phone. Thus, =20 >> tourists could always easily access the local version of the =20 >> poison control center, for example, even if they have no clue that =20= >> they'd dial 1-800-222-1222 in the US for that. >> >> Henning >> >> Brian Rosen wrote: >>> I would imagine that there would be, somewhere, some kind of a =20 >>> "pretty >>> print" description of what these services are. The phone would =20 >>> access this >>> along with the list of service urns available at their location =20 >>> and offer an >>> interesting GUI for what it finds. >>> Brian >>> -----Original Message----- >>> From: Andrew Newton [mailto:andy@hxr.us] Sent: Friday, May 19, =20 >>> 2006 12:46 PM >>> To: Brian Rosen >>> Cc: 'Henning Schulzrinne'; ecrit@ietf.org; 'Thomson, Martin' >>> Subject: Re: List services use case (was Re: [Ecrit] Re: >>> CommmentsI.D-ecrit-service-urn-03 Child helpline) >>> Brian Rosen wrote: >>>> While I can see some really smart phones trying to make sense =20 >>>> out of the >>>> list, in my mind the purpose here is to develop a COMPLETE list =20 >>>> of dial >>>> strings that need to be recognized and translated into service =20 >>>> URNs. >>> Exactly what "smart" thing would they do? >>> -andy >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 20 09:28:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhRVO-0006n9-IE; Sat, 20 May 2006 09:28:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhRVN-0006n4-4m for ecrit@ietf.org; Sat, 20 May 2006 09:28:29 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhRVM-0000Tg-IS for ecrit@ietf.org; Sat, 20 May 2006 09:28:29 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 20 May 2006 06:28:28 -0700 X-IronPort-AV: i="4.05,149,1146466800"; d="scan'208"; a="1809804147:sNHT34319156" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k4KDSRQO005947; Sat, 20 May 2006 06:28:27 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4KDSRB7013574; Sat, 20 May 2006 06:28:27 -0700 (PDT) Received: from [127.0.0.1] (ssh-ams-1.cisco.com [144.254.226.40]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4KDPkpg013494; Sat, 20 May 2006 06:25:46 -0700 In-Reply-To: References: <04c201c67b64$75359630$640fa8c0@cis.neustar.com> <446DF95B.9070400@cs.columbia.edu> <8A52DA28-5F26-4DE1-A47F-61769A70CE2E@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <33D5A65A-C5BC-4E54-97A2-8127B626291B@cisco.com> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: List services use case (was Re: [Ecrit] Re: CommmentsI.D-ecrit-service-urn-03 Child helpline) Date: Sat, 20 May 2006 15:28:20 +0200 To: Henning Schulzrinne X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-1.cisco.com; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=5685; t=1148131707; x=1148995707; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=paf@cisco.com; z=From:=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20 |Subject:Re=3A=20List=20services=20use=20case=20(was=20Re=3A=20[Ecrit]=20Re=3A=20 CommmentsI.D-ecrit-service-urn-03=20Child=20helpline); X=v=3Dcisco.com=3B=20h=3DW5a8tFXfXY2c+CEQ1nPuvtp1ydw=3D; b=o6ZrmH6y3g09LCYXVFYJ5J/KAZap8jhqie+D0itEXXGao381cC86HGCrpMAcrN2Z0RzSd9gk E5L3JL/Qq/c5nmt1eoztOgrWyWm/nATKUVlgok/CeUpAhloqVzSzEOXU; X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On 20 maj 2006, at 15.07, Henning Schulzrinne wrote: > Patrik, > > I'm not quite sure if you're agreeing or disagreeing with the =20 > general gist of my statement. Neither. I just try to point out that some event can be triggered =20 manually, and the rest can follow automatically. We don't have to be =20 able to do everything automatically. And, at the same time we have to (like you seems to have already) =20 understand and accept there will be competition between the location =20 services just like we have competition between Yahoo and Google. Last thing is that I personally think it is better if the end user =20 can choose what service they use (subscribe to) and always use it =20 than having one tied to the local network they roam to. This also fits with for example the view the Swedish IT Minister =20 Ulrica Messing has. One should be able to reach the services one want =20= to use whenever, from wherever and with whatever device. I do though understand different views exist on this last bullet. The =20= technology probably have to support both. Patrik > In any event, I think I'm agreeing with you that having a way to =20 > localize services based on my current location is a good thing and =20 > SMS (or other human-readable) messages are not really a good =20 > approximation of such automatic localization. They simply indicate =20 > that there's a need for such information and that service provider =20 > have an incentive to provide pointers to such localized services. =20 > I'd like to make them work better for both sides. > > While this is outside the scope of ECRIT, LoST is general enough to =20= > manage pointers to other local services, such as the restaurant =20 > finder you mention. My current thinking is that this would be =20 > something like urn:service:info.* (As described in the current =20 > service URN draft, each top-level service can have its own LoST =20 > server hierarchy, so the provider of LoST mapping for emergency =20 > services doesn't have to worry about informational services and =20 > vice versa.) > > Henning > > On May 20, 2006, at 2:07 AM, Patrik F=E4ltstr=F6m wrote: > >> First of all I always think a phone have some priming information =20 >> in it. It is configured for "normal" use. For example how to use =20 >> it where it normally is. >> >> Given this information, the phone only need to know where it is, =20 >> send a query to the "home listing service" and get temporary =20 >> reprogramming of whatever features should work differently where =20 >> the phone is now. >> >> Personally I am quite irritated on the sms messages I get when I =20 >> roam into a new providers network. Specifically when the foreign =20 >> network change N times the first M hours where neither N or M is =20 >> large. Including roaming into the same network a few times the =20 >> first day. >> >> Much better to allow "my home provider" to have this as a service, =20= >> or create the ability for "google's" all over the world to sell =20 >> listing services to the users. >> >> "I am at the moment in Istanbul" is a pretty simple message I can =20 >> even give to my phone manually (so that timezone is changed, =20 >> 112/911, listing, best restaurant etc all are changed). >> >> I already do this on my phone, to set the timezone, so why can =20 >> this operation not automatically set other things as well? >> >> Patrik >> >> On 19 maj 2006, at 18.59, Henning Schulzrinne wrote: >> >>> I agree with Brian. >>> >>> It seems quite common for GSM phones to show a text message =20 >>> indicating "welcome to Teluristan; you can get concierge services =20= >>> at *311 and can talk to our sales rep at *411." when roaming into =20= >>> a new country or service area. The problem with these messages is =20= >>> that they are not structured, so there is no easy way for them to =20= >>> be integrated into the phone's address book, for example. With =20 >>> the service listing proposed, this would be fairly =20 >>> straightforward. Given the generic URN service names, it would =20 >>> also make it easy to have symbols or visitor-language =20 >>> descriptions on the phone. Thus, tourists could always easily =20 >>> access the local version of the poison control center, for =20 >>> example, even if they have no clue that they'd dial =20 >>> 1-800-222-1222 in the US for that. >>> >>> Henning >>> >>> Brian Rosen wrote: >>>> I would imagine that there would be, somewhere, some kind of a =20 >>>> "pretty >>>> print" description of what these services are. The phone would =20 >>>> access this >>>> along with the list of service urns available at their location =20 >>>> and offer an >>>> interesting GUI for what it finds. >>>> Brian >>>> -----Original Message----- >>>> From: Andrew Newton [mailto:andy@hxr.us] Sent: Friday, May 19, =20 >>>> 2006 12:46 PM >>>> To: Brian Rosen >>>> Cc: 'Henning Schulzrinne'; ecrit@ietf.org; 'Thomson, Martin' >>>> Subject: Re: List services use case (was Re: [Ecrit] Re: >>>> CommmentsI.D-ecrit-service-urn-03 Child helpline) >>>> Brian Rosen wrote: >>>>> While I can see some really smart phones trying to make sense =20 >>>>> out of the >>>>> list, in my mind the purpose here is to develop a COMPLETE list =20= >>>>> of dial >>>>> strings that need to be recognized and translated into service =20 >>>>> URNs. >>>> Exactly what "smart" thing would they do? >>>> -andy >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 20 16:25:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhXzQ-0008MB-Na; Sat, 20 May 2006 16:23:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhXzO-0008M6-Sx for ecrit@ietf.org; Sat, 20 May 2006 16:23:54 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FhXzK-0006iy-On for ecrit@ietf.org; Sat, 20 May 2006 16:23:54 -0400 Received: (qmail invoked by alias); 20 May 2006 20:23:47 -0000 Received: from p54987455.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.116.85] by mail.gmx.net (mp043) with SMTP; 20 May 2006 22:23:47 +0200 X-Authenticated: #29516787 Message-ID: <446F7AD5.4010707@gmx.net> Date: Sat, 20 May 2006 22:23:49 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Ecrit] Summary of Recent Discussion References: <32755D354E6B65498C3BD9FD496C7D462C4A4E@oefeg-s04.oefeg.loc> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: Stastny Richard , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Ted, Ted Hardie wrote: > Continuing the top posting meme, the LoST protocol mechanism appears to be: > > "Return the urn for which this is a mapping, so the client knows if it is changed". > > I think the rest of Brian's cases are, in essence, default mappings, where one > service (e.g. sos.police) is doing double duty as something else (e.g sos). I > would also argue that it would be better in that case to populate the > default URN (sos)'s LoST data with the same data as (sos.police) > as a direct, effective way of handling that. Sounds like a good idea to me. Doing this you wouldn't even need to return the service urn with the LoST response since it would match the query. That means you don't have to do > a server configuration mapping step to say "return sos.police to sos queries". I agree. > Still, I agree that returning the service URN that is associated with the responder > may be appropriate, as there may be cases where that will cause the caller to > make some decision (e.g. drop the call if they were calling in a police brutality > sighting). I think that should not be a protocol error, in other words, but I think > we should be strongly pushing for a BCP of urn:service:sos being a populated > item in the LoST emergency server; it really does help interoperability here to > have a default. I am confused with this suggestion. > > This is also where I can't tell whether I agree with Richard or not. The local LoST > server should return to you the contact URI of the URN associated with your > query. What that URN means should be globally known, not purely based on > local custom, or roaming folks are going to be overly surprised. If it isn't sufficiently > well described to distinguish between a "my parents make me do chores" counselling > service and an emergency child-slave rescue service, then something is wrong. > In a local context, it is, of course, possible that the same folks respond to both, > because they have been trained to do so. But the services are distinct. > > If Richard is talking about what the mapping should be in the absence of a > service listing, that may be local (should the child slave talk to a counsellor trained > to talk to kids, or a policeman trained in dealing with lawbreakers like child slavers?) > If he's saying that the local folks should decide that urn:service:help:child should > be whatever the local folks say it should mean, that's not globally appropriate. > urn:service:help:child.counselling and urn:service:sos:child.rescue should be > distinguishable. > regards, > Ted > Ciao Hannes > > > > > > > > > > > > At 10:26 PM +0200 5/19/06, Stastny Richard wrote: > >>I support this. It is a local decision if child.help is a counselling service or an emergency service >>you may even have both. >> >>- A conselling service for giving children advice in case they have problems with their parents >>or teachers (this may also anonymous) >>- and an emergency service for children brought by slave-traders into >>another country (here a location is very useful, because the child >>may have no idea where it is and may also may not talk the language) >> >>This was basically the service CHI requested >> >>Richard >> >> >>________________________________ >> >>Von: Brian Rosen [mailto:br@brianrosen.net] >>Gesendet: Fr 19.05.2006 21:01 >>An: 'Ted Hardie'; 'Hannes Tschofenig'; ecrit@ietf.org >>Betreff: RE: [Ecrit] Summary of Recent Discussion >> >> >> >>Nope, that won't work. >> >>In some countries, there is no sos single service. In other countries, if >>there is no fire number, there is ONLY the top level sos (with respect to >>fire). >> >>The database has to know this (but that's okay, because it's all local data, >>as is all the data in the database). If you query with sos, and there is no >>sos, there will be a local decision of what to return. In most cases, I'd >>expect they would decide to return sos.police. If you query sos.police in >>North America, you will definitely get back the sos URI (and presumably the >>sos URN). It could be that you get back an error (in this jurisdiction, >>there is no such service, and we want you to do it over). >> >>This lets it be a local decision if humanServices.child gets you sos.police. >> >>Brian >> >>-----Original Message----- >>From: Ted Hardie [mailto:hardie@qualcomm.com] >>Sent: Friday, May 19, 2006 2:49 PM >>To: Hannes Tschofenig; ecrit@ietf.org >>Subject: Re: [Ecrit] Summary of Recent Discussion >> >>At 4:44 PM +0200 5/19/06, Hannes Tschofenig wrote: >> >>>Various failure cases in LoST need to be carefully analysed. E.g., A person >> >>asks for "urn:service:sos.fire" but only ""urn:service:sos" is available. >>What would happen? This item and the last one are related to each other. >> >>The LoST server should return the contact URI for urn:service:sos along with >>the URN it used for the mapping. The phone will get a useful contact, and >>it will know that the location actually derived from a "default" emergency >>service urn, rather than the specific. >> >>Note: I don't think this should work like tree walking. There should be a >>single >>default (urn:service:sos for emergency services). If the LoST server does >>not >>have the sos.$var you asked for, it *always* goes back to the default. I >>think >>this reinforces the idea that you separate emergency services from >>counselling >>services or non-emergency public support; they may have a different default, >>but they certainly should not be sent to the emergency default. >> >> Ted >> >> >> >> >> >> >> >> >>>* Henning suggested to extend LoST to return additional information >> >>regarding the service (e.g., location information needed). This discussion >>is relevant for LoST. I can see that there was support for his proposal. >>This aspect does not need to be captured in the requirements draft. >> >>>* Child helpline >>>Henning has already captured the child helpline service identifier after a >> >>discussion on the mailing list: >>http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service-urn-03 >>.txt). >> >>>(see urn:service:counseling.children) >>> >>>* Requirements draft >>>Roger mentioned a few open issues with the document where he would >> >>appreciate input. A final review would help to finish the document. >> >>>Ciao >>>Hannes >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ecrit >> >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >> >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 20 16:53:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhYQV-0003IS-6X; Sat, 20 May 2006 16:51:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhYQU-0003IN-3I for ecrit@ietf.org; Sat, 20 May 2006 16:51:54 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FhYQR-0007yl-G9 for ecrit@ietf.org; Sat, 20 May 2006 16:51:54 -0400 Received: (qmail invoked by alias); 20 May 2006 20:51:49 -0000 Received: from p54987455.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.116.85] by mail.gmx.net (mp036) with SMTP; 20 May 2006 22:51:49 +0200 X-Authenticated: #29516787 Message-ID: <446F8169.4010002@gmx.net> Date: Sat, 20 May 2006 22:51:53 +0200 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: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [Ecrit] WGLC for draft-ietf-ecrit-service-urn-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, we are now starting the Working Group Last Call on the "A Uniform Resource Name (URN) for Services" document. You can find the draft at: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-03.txt The WGLC will end on June 2nd, 2006. Please review this document and post your comments to the list. Ciao Hannes & Marc -------- Original Message -------- Subject: I-D ACTION:draft-ietf-ecrit-service-urn-03.txt Date: Fri, 19 May 2006 18:50:01 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ecrit@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : A Uniform Resource Name (URN) for Services Author(s) : H. Schulzrinne Filename : draft-ietf-ecrit-service-urn-03.txt Pages : 15 Date : 2006-5-19 The content of many communication services depends on the context, such as the user's location. We describe a 'service' URN that allows to register such context-dependent services that can be resolved in a distributed manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-service-urn-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-service-urn-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 22 09:41:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiAes-0007Pm-5U; Mon, 22 May 2006 09:41:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiAeq-0007Ph-V1 for ecrit@ietf.org; Mon, 22 May 2006 09:41:16 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiAep-0000rI-Lq for ecrit@ietf.org; Mon, 22 May 2006 09:41:16 -0400 Received: from dhcp89-089-104.bbn.com ([128.89.89.104] helo=rwatro-xp.bbn.com) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FiAep-0001LP-3s; Mon, 22 May 2006 09:41:15 -0400 Message-Id: <6.1.0.6.2.20060522065257.036212f0@po2.bbn.com> X-Sender: rwatro@po2.bbn.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Mon, 22 May 2006 09:41:45 -0400 To: ecrit@ietf.org From: Ron Watro Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Subject: [Ecrit] Review of Security Threats Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Here are some brief comments on draft-ietf-ecrit-security-threats-01, dated April 17 2006 Good job by Tom to persevere through the various versions of this document. General comment: The current draft focuses on the security requirements for just the parts of the VoIP emergency response system that are ECRIT work items. Some of the previous incarnations of this document also included an overview of the full system security concept, so that one could see that the security being proposed for the ECRIT work items was consistent with at least one full-scale plan. At the interim meeting, it was decided to drop any discussion of system security as a whole. This decision was influenced by several issues, including the desire for ECRIT to make speedy progress and the lack of any consensus on the full system approach. There were some dissenting opinions at the interim meeting, arguing that a properly caveated, strawman view of the full system and its security concept was needed to provide a basis for the security services allocated to ECRIT work items. In any event, we currently have the version without the system view, and going forward we can expect comments asking why the component security requirements were not derived from a set of system security requirements (as is commonly done). Specific comments are below: Abstract --doubled "the" in the last sentence 1 Introduction --suggest changing the two "must be" wordings in the 1st paragraph to "is being" . The marking idea and the mapping server are not the only feasible solutions to the problems at hand. --mixture of commas and periods as list separators in the last paragraph 4 Objectives of attackers --for the third bullet, it seems conceivable that a structured emergency service marker could help support the process of preventing fraudulent emergency calls (by assisting in track-back of the call, for example). In this case, there could be interaction with ECRIT work items --inconsistent punctuation at the end of bulleted items 5 Potential Attacks 5.1 Identifier attacks --Is the emergency identifier known to be just a single bit, or could it contain data that can be use for other proposes (time stamp, cryptographic signature?) --You say that theft-of-service calls most probably will not include any location information - but wouldn't they mostly likely include falsified location information so that they look legit but cannot be tracked back to the source? 6 Security requirements from section 5.1 fraudulent calls --How will a URI be verified as a PSAP? Will the mapping server be used or is this a non-ECRIT security requirement? --Are long distance calls to remote PSAPs always fraudulent? For example, a disreputable foreign entity might set up a phony PSAP for its people to call. Can a service provider refuse to carry or perhaps reroute a long distance emergency request? from section 5.2.1 impersonation of the mapping server --mapping server discovery is apparently outside the scope of ECRIT topic, so does ECRIT simply assume that this will be done in a secure manner? --will the protocol allow exchange with unauthenticated servers if no authenticated ones can be found? --does it ever make sense to return mapping server audit data to the client? Is this data encrypted to make it inaccessible by the client? Is this design intended to address rogue servers? If not, then why not just store the data on the server? from section 5.2.3 snooping attack -- the protocol or system must provide confidentiality mechanisms but the mapping server should respond to non-complaint clients with unprotected data if that is the only option Final comment: Any concern about "insider attack" -- rogue PSAPs, SIP proxies, etc? Ron Watro _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 22 15:56:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiGWE-0007Se-3C; Mon, 22 May 2006 15:56:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiGWD-0007SH-80 for ecrit@ietf.org; Mon, 22 May 2006 15:56:45 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiGWB-0001Y2-MJ for ecrit@ietf.org; Mon, 22 May 2006 15:56:45 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4MJuMLu026352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 May 2006 12:56:22 -0700 Received: from [129.46.225.88] (dhcp-campbell-28.qualcomm.com [129.46.225.88]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4MJuGux025299; Mon, 22 May 2006 12:56:17 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <446F7AD5.4010707@gmx.net> References: <32755D354E6B65498C3BD9FD496C7D462C4A4E@oefeg-s04.oefeg.loc> <446F7AD5.4010707@gmx.net> Date: Mon, 22 May 2006 12:56:14 -0700 To: Hannes Tschofenig From: Ted Hardie Subject: Re: [Ecrit] Summary of Recent Discussion Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Stastny Richard , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org A > >>Still, I agree that returning the service URN that is associated with the responder >>may be appropriate, as there may be cases where that will cause the caller to >>make some decision (e.g. drop the call if they were calling in a police brutality >>sighting). I think that should not be a protocol error, in other words, but I think >>we should be strongly pushing for a BCP of urn:service:sos being a populated >>item in the LoST emergency server; it really does help interoperability here to >>have a default. > >I am confused with this suggestion. > Sorry for the confusion. I am suggesting that it should not be a protocol error for the server to return the contact URI + the service URN when that service URN differed from the one that was requested. I think the base reason for this is the one we identified a long time ago: I ask for sos.fire, but only sos is supported; I return the contact URI, and let the client know that the contact URI is for sos. We need that to be possible. Returning the contact URI and the service URN for sos.police when there is no sos looks like the same protocol mechanism to me. So I think we shouldn't try to rule it out at the protocol level, but advocate instead that people accomplish the same thing by populating the sos service URN with the same data as is present at sos.police. (Given that this is not a protocol mechanism, this would be Best Practice at most). I also acknowledge that there will be corner cases where getting a service URN different than the one requested may cause the caller to do something other than continue the call. I don't thing we ought to be too concerned about that, but given the protocol mechanism is there, we should note it may be useful in that case as well. I hope that's clearer, regards, Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 22 16:29:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiH1b-0007q5-KG; Mon, 22 May 2006 16:29:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiH1Z-0007o4-PD for ecrit@ietf.org; Mon, 22 May 2006 16:29:09 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiH1Y-0003Bt-D2 for ecrit@ietf.org; Mon, 22 May 2006 16:29:09 -0400 Received: from lion.cs.columbia.edu (IDENT:Ac6LGhz6qB0/MW0WHmDC9ZFgbTpx+CR5@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k4MKT5X6009058 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 22 May 2006 16:29:05 -0400 (EDT) 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 k4MKT4BB018595 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 22 May 2006 16:29:05 -0400 Message-ID: <44721F0B.8030509@cs.columbia.edu> Date: Mon, 22 May 2006 16:28:59 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Ecrit] Related services (was: Summary of recent discussion) References: <32755D354E6B65498C3BD9FD496C7D462C4A4E@oefeg-s04.oefeg.loc> <446F7AD5.4010707@gmx.net> 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, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org There seem to be two approaches to this problem: client-based and server-based. In a client-based approach, the server returns an error when a particular service is unavailable. The client then retries with the more general service (sos.police -> sos). Ted seems to advocate the server-based approach where the server "guesses" (quoted, since this might be a fairly predictable algorithm) what the user would want in the absence of its first choice. I don't think there's a right answer here. The client-based approach has the advantage of not returning information that the client already had ("Thanks, I already know about service:sos since I just asked for it, but I wanted to know whether there are sub-services.") and being slightly simpler. The server-based approach has the advantage that the server may have a better idea what's available, avoiding having to client to try a bunch of things. (The discovery mechanism addresses that problem to some extent.) The problem with the server-based approach is that it starts to get messy if the alternative, second-best answer is a list, not a single answer. Suddenly, the protocol has to support providing a possibly lengthy list of services that are all potential substitutes. My gut feeling is that modular protocols are easier to get correct, where each request does something simple and the client makes decisions. For this case, the behavior would be something like (1) client asks for sos-related services and obtains a list of services (some subset of the sub-services in the sos.* list) (2) client obtains the sub-service information (URLs, description, etc.) it cares about Henning Ted Hardie wrote: > A >>> Still, I agree that returning the service URN that is associated with the responder >>> may be appropriate, as there may be cases where that will cause the caller to >>> make some decision (e.g. drop the call if they were calling in a police brutality >>> sighting). I think that should not be a protocol error, in other words, but I think >>> we should be strongly pushing for a BCP of urn:service:sos being a populated >>> item in the LoST emergency server; it really does help interoperability here to >>> have a default. >> I am confused with this suggestion. >> > > Sorry for the confusion. I am suggesting that it should not be a protocol error > for the server to return the contact URI + the service URN when that service > URN differed from the one that was requested. I think the base reason for this > is the one we identified a long time ago: I ask for sos.fire, but only sos is supported; > I return the contact URI, and let the client know that the contact URI is for > sos. We need that to be possible. > > Returning the contact URI and the service URN for sos.police when there is no sos > looks like the same protocol mechanism to me. So I think we shouldn't try > to rule it out at the protocol level, but advocate instead that people accomplish > the same thing by populating the sos service URN with the same data as is > present at sos.police. (Given that this is not a protocol mechanism, this would > be Best Practice at most). > > I also acknowledge that there will be corner cases where getting a service > URN different than the one requested may cause the caller to do something > other than continue the call. I don't thing we ought to be too concerned about that, > but given the protocol mechanism is there, we should note it may be useful > in that case as well. > > I hope that's clearer, > regards, > Ted > > _______________________________________________ > 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 May 22 17:16:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiHlS-0004Yi-FL; Mon, 22 May 2006 17:16:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiHlS-0004Yd-2M for ecrit@ietf.org; Mon, 22 May 2006 17:16:34 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiHlQ-00069A-LA for ecrit@ietf.org; Mon, 22 May 2006 17:16:34 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FiHlF-0001js-LV; Mon, 22 May 2006 16:16:23 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Ted Hardie'" Subject: RE: [Ecrit] Related services (was: Summary of recent discussion) Date: Mon, 22 May 2006 17:15:52 -0400 Message-ID: <089f01c67de4$fe2cc440$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ94IJeqvt49fSmQDeJk/8mYaa4CgAA9Wbw In-Reply-To: <44721F0B.8030509@cs.columbia.edu> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I don't understand how your suggested solution handles the case of child help, where in one jurisdiction, there is an emergency, and in another there is only an NGO non-emergency. Do you propose to have two entries in the tree, and populate one or both and have the client know the difference? I also don't understand the protocol difference between "return a list of sos.*" and "the second-best answer is a list". Both involve the protocol returning one or more items in a list. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, May 22, 2006 4:29 PM > To: Ted Hardie > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Related services (was: Summary of recent discussion) > > There seem to be two approaches to this problem: client-based and > server-based. > > In a client-based approach, the server returns an error when a > particular service is unavailable. The client then retries with the more > general service (sos.police -> sos). > > Ted seems to advocate the server-based approach where the server > "guesses" (quoted, since this might be a fairly predictable algorithm) > what the user would want in the absence of its first choice. > > I don't think there's a right answer here. The client-based approach has > the advantage of not returning information that the client already had > ("Thanks, I already know about service:sos since I just asked for it, > but I wanted to know whether there are sub-services.") and being > slightly simpler. > > The server-based approach has the advantage that the server may have a > better idea what's available, avoiding having to client to try a bunch > of things. (The discovery mechanism addresses that problem to some > extent.) > > The problem with the server-based approach is that it starts to get > messy if the alternative, second-best answer is a list, not a single > answer. Suddenly, the protocol has to support providing a possibly > lengthy list of services that are all potential substitutes. > > My gut feeling is that modular protocols are easier to get correct, > where each request does something simple and the client makes decisions. > For this case, the behavior would be something like > > (1) client asks for sos-related services and obtains a list of services > (some subset of the sub-services in the sos.* list) > > (2) client obtains the sub-service information (URLs, description, etc.) > it cares about > > Henning > > > Ted Hardie wrote: > > A > >>> Still, I agree that returning the service URN that is associated with > the responder > >>> may be appropriate, as there may be cases where that will cause the > caller to > >>> make some decision (e.g. drop the call if they were calling in a > police brutality > >>> sighting). I think that should not be a protocol error, in other > words, but I think > >>> we should be strongly pushing for a BCP of urn:service:sos being a > populated > >>> item in the LoST emergency server; it really does help > interoperability here to > >>> have a default. > >> I am confused with this suggestion. > >> > > > > Sorry for the confusion. I am suggesting that it should not be a > protocol error > > for the server to return the contact URI + the service URN when that > service > > URN differed from the one that was requested. I think the base reason > for this > > is the one we identified a long time ago: I ask for sos.fire, but only > sos is supported; > > I return the contact URI, and let the client know that the contact URI > is for > > sos. We need that to be possible. > > > > Returning the contact URI and the service URN for sos.police when there > is no sos > > looks like the same protocol mechanism to me. So I think we shouldn't > try > > to rule it out at the protocol level, but advocate instead that people > accomplish > > the same thing by populating the sos service URN with the same data as > is > > present at sos.police. (Given that this is not a protocol mechanism, > this would > > be Best Practice at most). > > > > I also acknowledge that there will be corner cases where getting a > service > > URN different than the one requested may cause the caller to do > something > > other than continue the call. I don't thing we ought to be too > concerned about that, > > but given the protocol mechanism is there, we should note it may be > useful > > in that case as well. > > > > I hope that's clearer, > > regards, > > Ted > > > > _______________________________________________ > > 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 Mon May 22 17:19:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiHo3-00050K-PY; Mon, 22 May 2006 17:19:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiHo1-0004uh-Sr for ecrit@ietf.org; Mon, 22 May 2006 17:19:13 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiHo0-0006FP-Ip for ecrit@ietf.org; Mon, 22 May 2006 17:19:13 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FiHnq-00029W-G9; Mon, 22 May 2006 16:19:02 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Hannes Tschofenig'" Subject: RE: [Ecrit] Summary of Recent Discussion Date: Mon, 22 May 2006 17:18:46 -0400 Message-ID: <08a001c67de5$5df97490$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ92c7yR8ToU4/URsSM+uynlreHpwACxmgQ In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: 'Stastny Richard' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I am confused by > Returning the contact URI and the service URN for sos.police when there is > no sos > looks like the same protocol mechanism to me. So I think we shouldn't try > to rule it out at the protocol level, but advocate instead that people > accomplish > the same thing by populating the sos service URN with the same data as is > present at sos.police. (Given that this is not a protocol mechanism, this > would > be Best Practice at most). If it looks like the same mechanism, maybe it should be the same mechanism and we don't need another mechanism. Why are you advocating an alternative to returning sos.police for an sos query if you are okay returning sos for an sos.police query? Brian > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Monday, May 22, 2006 3:56 PM > To: Hannes Tschofenig > Cc: Stastny Richard; Brian Rosen; ecrit@ietf.org > Subject: Re: [Ecrit] Summary of Recent Discussion > > A > > > >>Still, I agree that returning the service URN that is associated with > the responder > >>may be appropriate, as there may be cases where that will cause the > caller to > >>make some decision (e.g. drop the call if they were calling in a police > brutality > >>sighting). I think that should not be a protocol error, in other > words, but I think > >>we should be strongly pushing for a BCP of urn:service:sos being a > populated > >>item in the LoST emergency server; it really does help interoperability > here to > >>have a default. > > > >I am confused with this suggestion. > > > > Sorry for the confusion. I am suggesting that it should not be a protocol > error > for the server to return the contact URI + the service URN when that > service > URN differed from the one that was requested. I think the base reason for > this > is the one we identified a long time ago: I ask for sos.fire, but only > sos is supported; > I return the contact URI, and let the client know that the contact URI is > for > sos. We need that to be possible. > > Returning the contact URI and the service URN for sos.police when there is > no sos > looks like the same protocol mechanism to me. So I think we shouldn't try > to rule it out at the protocol level, but advocate instead that people > accomplish > the same thing by populating the sos service URN with the same data as is > present at sos.police. (Given that this is not a protocol mechanism, this > would > be Best Practice at most). > > I also acknowledge that there will be corner cases where getting a service > URN different than the one requested may cause the caller to do something > other than continue the call. I don't thing we ought to be too concerned > about that, > but given the protocol mechanism is there, we should note it may be useful > in that case as well. > > I hope that's clearer, > regards, > Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 22 17:54:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiIMN-00019e-48; Mon, 22 May 2006 17:54:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiIMM-00018E-5r for ecrit@ietf.org; Mon, 22 May 2006 17:54:42 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiIMG-0008V2-Qq for ecrit@ietf.org; Mon, 22 May 2006 17:54:42 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Mon, 22 May 2006 17:55:10 -0400 id 01588110.4472333E.000013D2 Message-ID: <44723315.6000007@hxr.us> Date: Mon, 22 May 2006 17:54:29 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Related services References: <32755D354E6B65498C3BD9FD496C7D462C4A4E@oefeg-s04.oefeg.loc> <446F7AD5.4010707@gmx.net> <44721F0B.8030509@cs.columbia.edu> In-Reply-To: <44721F0B.8030509@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning Schulzrinne wrote: > The server-based approach has the advantage that the server may have a > better idea what's available, avoiding having to client to try a bunch > of things. (The discovery mechanism addresses that problem to some extent.) The server based approach is more time and network efficient. I hope those are important attributes for emergency use cases. > The problem with the server-based approach is that it starts to get > messy if the alternative, second-best answer is a list, not a single > answer. Suddenly, the protocol has to support providing a possibly > lengthy list of services that are all potential substitutes. What is suppose to happen with a list of services on the user end? I want sos.fire and I get back a list of sos.utility, sos.scuba-accidents, and sos.crazy-persons? What am I suppose to do with those? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 22 18:03:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiIUj-00051X-Kz; Mon, 22 May 2006 18:03:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiIUi-00051S-5B for ecrit@ietf.org; Mon, 22 May 2006 18:03:20 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiIUf-0000UY-C4 for ecrit@ietf.org; Mon, 22 May 2006 18:03:20 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4MM35M1009112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 May 2006 15:03:06 -0700 Received: from [129.46.225.88] (dhcp-campbell-28.qualcomm.com [129.46.225.88]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4MM33kP027945; Mon, 22 May 2006 15:03:04 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <44721F0B.8030509@cs.columbia.edu> References: <32755D354E6B65498C3BD9FD496C7D462C4A4E@oefeg-s04.oefeg.loc> <446F7AD5.4010707@gmx.net> <44721F0B.8030509@cs.columbia.edu> Date: Mon, 22 May 2006 15:03:02 -0700 To: Henning Schulzrinne From: Ted Hardie Subject: Re: [Ecrit] Related services (was: Summary of recent discussion) Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 4:28 PM -0400 5/22/06, Henning Schulzrinne wrote: >There seem to be two approaches to this problem: client-based and server-based. > >In a client-based approach, the server returns an error when a particular service is unavailable. The client then retries with the more general service (sos.police -> sos). > >Ted seems to advocate the server-based approach where the server "guesses" (quoted, since this might be a fairly predictable algorithm) what the user would want in the absence of its first choice. I actually don't think that's what I'm advocating. I believe there are cases where queries will come in for service URNs that are not supported in the local area. If a local administration decides that those do not need to get any service, then a normal "no data" message is returned. I believe, though, that there are cases where they will wish to use one of the emergency service responders as a "backup" service for unknown sos services. Brian indicates that this is commonly police, and I've used that in my examples. I believe the best way to handle that is for the local administration to provision the unsupported emergency service URNs with the same data as is present for the "backup" service (that, is put the sos.police data at sos.foo if sos.foo is not supported). Nobody has to guess at that point; it is a straightforward result. Based on Brian's message, though, I believe there will be cases where the local authorities may not want to provision those service URNs, but will want instead for the LoST server to return what is, essentially, a compound message "There is no service available for your query; the backup service is sos.police, and here is its contact URI". This may be to manage the client expectation or to avoid caching of data that is not, strictly speaking correct. The example I can imagine most clearly here is for a sos.poison. If the jurisdiction doesn't have a poison service or a top-level sos service, the client's query for sos.poison being redirected to sos.police may be far enough off that a client would prefer to try to make a non-emergency call to a known hospital number instead. Other clients might decide to continue the call and ask for police help with finding a poison center. Whichever choice is made, though, the metadata about the redirection to other responders may be valuable. Note that none of this is service "guessing"; it's the jurisdiction covering the location saying what it wants returned--I think that will be easy if they do it by providing contact URIs for the services, but also do-able if they want to provide both a contact URI and the metadata of which service will be really handling the call. Let's put this in jurisdictional terms for a second. If Happyland has services for fire, police, ambulance, and coast guard services, the Happylanders likely know those relevant telephone numbers and will call them in the appropriate moments. When Happyland adopts LoST, they will populate their LoST servers with contact URIs for sos.fire, sos.police, sos.ambulance, and sos.marine. In the telephone system, they may well have only the specific numbers, with no general telephone number at all. If I roam into Happyland, I may be doing so from someplace that uses a single response number for all those services. When I try to look up the contact URI for emergency services, in other words, I'm going to query for sos alone. There is no such service in Happyland. What happens next? If the LoST server returns only that there is no data for sos, the device must at least spend time re-querying, which is a loss of time. If the device knows about sos.fire, sos.police, sos.ambulance, and sos.marine, etc. it will presumably need only a few round trips to find something that works, but any UI input needed will take attention as well as time--which is not great. In the proxy case, there is no chance that the proxy will know which more specific URN to try; it will have to work off some sort of priority table. The device or proxy may also not know of some URNs in use in Happyland. I'm particularly worried about that in cases where a user input like a dialed 911 or 112 is triggering this input. I think we should acknowledge that a client may have to go through this, but push as much as we can to avoid it. That means treating it as "best practice" to create an entry for the covering sos service *even if there is no corresponding telephone number*. Failing that, allowing the LoST server to indicate in metadata that the contact URI is for a service that *will respond* but is not the one for which the query is made is a second line of defense. I'd like to see the client/proxy picking a URN from its known set as the last line of defense. regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 22 18:18:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiIin-0003Nt-V9; Mon, 22 May 2006 18:17:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiIim-0003No-BI for ecrit@ietf.org; Mon, 22 May 2006 18:17:52 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiIik-00016D-2g for ecrit@ietf.org; Mon, 22 May 2006 18:17:52 -0400 Received: from lion.cs.columbia.edu (IDENT:I7MzYui0+/TUICPPSwR68VVRfksAQd3P@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k4MMHkX6013460 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 22 May 2006 18:17:47 -0400 (EDT) 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 k4MMHkBB025580 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 22 May 2006 18:17:46 -0400 Message-ID: <44723885.8000902@cs.columbia.edu> Date: Mon, 22 May 2006 18:17:41 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Related services References: <32755D354E6B65498C3BD9FD496C7D462C4A4E@oefeg-s04.oefeg.loc> <446F7AD5.4010707@gmx.net> <44721F0B.8030509@cs.columbia.edu> <44723315.6000007@hxr.us> In-Reply-To: <44723315.6000007@hxr.us> 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, __FRAUD_419_BADTHINGS 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > The server based approach is more time and network efficient. I hope > those are important attributes for emergency use cases. Since the query is done well ahead of the emergency, this is probably of only modest concern. I suspect that the difference is essentially one round-trip time, at most. > >> The problem with the server-based approach is that it starts to get >> messy if the alternative, second-best answer is a list, not a single >> answer. Suddenly, the protocol has to support providing a possibly >> lengthy list of services that are all potential substitutes. > > What is suppose to happen with a list of services on the user end? I > want sos.fire and I get back a list of sos.utility, sos.scuba-accidents, > and sos.crazy-persons? What am I suppose to do with those? Ignore the ones you don't care about, but an implementation might, as discussed separately, add them to the user's address book since the user might actually care about scuba accidents, even if the phone wasn't programmed for divers or this new service was added after the phone was built. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 22 18:30:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiIv5-0006dD-OD; Mon, 22 May 2006 18:30:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiIv3-0006aS-Ok for ecrit@ietf.org; Mon, 22 May 2006 18:30:33 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiIv2-00025b-HE for ecrit@ietf.org; Mon, 22 May 2006 18:30:33 -0400 Received: from lion.cs.columbia.edu (IDENT:/6QWY6smTav+JXOh7/CSGygLAh9Zv38B@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k4MMUOX6016451 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 22 May 2006 18:30:25 -0400 (EDT) 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 k4MMUOBB026383 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 22 May 2006 18:30:24 -0400 Message-ID: <44723B7B.3070007@cs.columbia.edu> Date: Mon, 22 May 2006 18:30:19 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Related services References: <089f01c67de4$fe2cc440$640fa8c0@cis.neustar.com> In-Reply-To: <089f01c67de4$fe2cc440$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='__CP_NAME_BODY 0, __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: 8b30eb7682a596edff707698f4a80f7d Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: > I don't understand how your suggested solution handles the case of child > help, where in one jurisdiction, there is an emergency, and in another there > is only an NGO non-emergency. Do you propose to have two entries in the > tree, and populate one or both and have the client know the difference? I'm probably misunderstanding you, but this seems to be a labeling (URN) issue, not a lookup issue. child-help would be in one place, either as urn:service:sos.child-help or as urn:service:counseling.child-help. We would pick one, knowing that the boundaries between these are not perfectly well defined, but it doesn't much matter as long as users (and their address books) know where to find them. After all, users would never dial urn:service.anything; they'd follow a textual or iconic description in their pre-populated address book on their cell phone or a link on a web page. As discussed previously, the properties of the call to such services, such as whether location is desired or mandatory, would be stored in the LoST record for that service and jurisdiction. This makes it easy to have different policies in different countries, reflecting national laws and customs. This is true across services. (For example, the poison control emergency service in the US does not, as far as I know, have a legal right to my location or identity information and there might be good reasons to keep it that way, if the poison happens to be derived from cold pills or is a white powder.) > > I also don't understand the protocol difference between "return a list of > sos.*" and "the second-best answer is a list". Both involve the protocol > returning one or more items in a list. Except in the second case, it is a separate operation which is useful by itself. I'm trying to keep things modular and simple, without recreating very similar functionality in different places. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 22 18:31:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiIvb-0007C9-0N; Mon, 22 May 2006 18:31:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiIvZ-0007AR-O7 for ecrit@ietf.org; Mon, 22 May 2006 18:31:05 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiIvY-0002Ch-Im for ecrit@ietf.org; Mon, 22 May 2006 18:31:05 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Mon, 22 May 2006 18:31:37 -0400 id 01588110.44723BCA.00001CAC Message-ID: <44723BA3.1080400@hxr.us> Date: Mon, 22 May 2006 18:30:59 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Related services References: <32755D354E6B65498C3BD9FD496C7D462C4A4E@oefeg-s04.oefeg.loc> <446F7AD5.4010707@gmx.net> <44721F0B.8030509@cs.columbia.edu> <44723315.6000007@hxr.us> <44723885.8000902@cs.columbia.edu> In-Reply-To: <44723885.8000902@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning Schulzrinne wrote: > Ignore the ones you don't care about, but an implementation might, as > discussed separately, add them to the user's address book since the user > might actually care about scuba accidents, even if the phone wasn't > programmed for divers or this new service was added after the phone was > built. Yeah, but who do I call when there is a fire? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 22 18:38:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiJ2m-0001TL-0L; Mon, 22 May 2006 18:38:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiJ2k-0001TG-P1 for ecrit@ietf.org; Mon, 22 May 2006 18:38:30 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiJ2j-0002mq-Gt for ecrit@ietf.org; Mon, 22 May 2006 18:38:30 -0400 Received: from lion.cs.columbia.edu (IDENT:nb9TvVlAIbW57lqeLVjsZ+m9lJwmzHP8@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k4MMcQX6018072 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 22 May 2006 18:38:27 -0400 (EDT) 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 k4MMcQBB026845 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 22 May 2006 18:38:26 -0400 Message-ID: <44723D5D.1060609@cs.columbia.edu> Date: Mon, 22 May 2006 18:38:21 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Related services References: <32755D354E6B65498C3BD9FD496C7D462C4A4E@oefeg-s04.oefeg.loc> <446F7AD5.4010707@gmx.net> <44721F0B.8030509@cs.columbia.edu> <44723315.6000007@hxr.us> <44723885.8000902@cs.columbia.edu> <44723BA3.1080400@hxr.us> In-Reply-To: <44723BA3.1080400@hxr.us> 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, __FRAUD_419_BADTHINGS 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: 2409bba43e9c8d580670fda8b695204a Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I suspect you're trying to say something deep that I'm missing, but it is either - 911 or 112 if that's what I'm trained to do (which is auto-configured by LoST to reach urn:service.sos and the appropriate URL) - the PSAP URL that the local jurisdiction has assigned to the urn:service.sos.fire service in the LoST record (which might well be the same as that for urn:service.sos or urn.service.sos.police or maybe even urn.service.sos.animal-control, but that's of no concern to the caller) - if there is none, the generic (next-layer-up) service, i.e., urn:service:sos and the PSAP URL that goes with that. Henning Andrew Newton wrote: > Henning Schulzrinne wrote: >> Ignore the ones you don't care about, but an implementation might, as >> discussed separately, add them to the user's address book since the >> user might actually care about scuba accidents, even if the phone >> wasn't programmed for divers or this new service was added after the >> phone was built. > > Yeah, but who do I call when there is a fire? > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 22 20:46:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiL2J-0001El-LV; Mon, 22 May 2006 20:46:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiL2I-0001Eg-Qc for ecrit@ietf.org; Mon, 22 May 2006 20:46:10 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiL2F-0007wR-IW for ecrit@ietf.org; Mon, 22 May 2006 20:46:10 -0400 Received: from [10.0.1.103] ([::ffff:68.106.115.242]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 22 May 2006 20:46:33 -0400 id 01588075.44725B69.00003110 In-Reply-To: <44723D5D.1060609@cs.columbia.edu> References: <32755D354E6B65498C3BD9FD496C7D462C4A4E@oefeg-s04.oefeg.loc> <446F7AD5.4010707@gmx.net> <44721F0B.8030509@cs.columbia.edu> <44723315.6000007@hxr.us> <44723885.8000902@cs.columbia.edu> <44723BA3.1080400@hxr.us> <44723D5D.1060609@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0CBAC129-A090-44FA-BCB2-76A878F2A540@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Related services Date: Mon, 22 May 2006 20:45:57 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On May 22, 2006, at 6:38 PM, Henning Schulzrinne wrote: > I suspect you're trying to say something deep that I'm missing, but > it is either > > - 911 or 112 if that's what I'm trained to do (which is auto- > configured by LoST to reach urn:service.sos and the appropriate URL) > > - the PSAP URL that the local jurisdiction has assigned to the > urn:service.sos.fire service in the LoST record (which might well > be the same as that for urn:service.sos or urn.service.sos.police > or maybe even urn.service.sos.animal-control, but that's of no > concern to the caller) > > - if there is none, the generic (next-layer-up) service, i.e., > urn:service:sos and the PSAP URL that goes with that. I'm not trying to say anything deep, I'm just trying to figure out how you imagine this will work (perhaps that does require a lot of deep thinking). My alarm panel, which uses VoIP, has three buttons (actually 6, 2 rows of three that require both buttons in each row to be pressed). One is labeled "Police", one is labeled "Ambulance" and one is labeled "Fire". If I press fire, urn:service.sos.fire is sent to the LoST server. The lost server then responds with urn:service.sos.scuba-accidents, urn:service.sos.crazy-persons, and urn:service.sos.duck-patrol. Why is it not proper for the LoST server simply to respond with "you want urn:service.sos" and here is the URI for that PSAP." Why must the client have to requery by knocking of a label? BTW: I thought there was no tree structure for these URNs, so what does "next-layer-up" mean? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 22 21:27:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiLfw-0003Ok-GB; Mon, 22 May 2006 21:27:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiLfv-0003Ob-Oz for ecrit@ietf.org; Mon, 22 May 2006 21:27:07 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiLft-0000z1-Hg for ecrit@ietf.org; Mon, 22 May 2006 21:27:07 -0400 Received: from [192.168.0.41] (pool-138-89-20-236.mad.east.verizon.net [138.89.20.236]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k4N1R30E015753 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 22 May 2006 21:27:04 -0400 (EDT) In-Reply-To: <0CBAC129-A090-44FA-BCB2-76A878F2A540@hxr.us> References: <32755D354E6B65498C3BD9FD496C7D462C4A4E@oefeg-s04.oefeg.loc> <446F7AD5.4010707@gmx.net> <44721F0B.8030509@cs.columbia.edu> <44723315.6000007@hxr.us> <44723885.8000902@cs.columbia.edu> <44723BA3.1080400@hxr.us> <44723D5D.1060609@cs.columbia.edu> <0CBAC129-A090-44FA-BCB2-76A878F2A540@hxr.us> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8C8B5D79-327B-4127-A048-BAD5AA7CCCF5@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Related services Date: Mon, 22 May 2006 21:27:01 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > My alarm panel, which uses VoIP, has three buttons (actually 6, 2 > rows of three that require both buttons in each row to be > pressed). One is labeled "Police", one is labeled "Ambulance" and > one is labeled "Fire". If I press fire, urn:service.sos.fire is > sent to the LoST server. The lost server then responds with > urn:service.sos.scuba-accidents, urn:service.sos.crazy-persons, and > urn:service.sos.duck-patrol. Why is it not proper for the LoST > server simply to I'm not suggesting that the server respond with scuba-accidents or the like; I'm not sure where I gave you this impression. > respond with "you want urn:service.sos" and here is the URI for > that PSAP." Why must the client have to requery by knocking of a > label? Why not just provide the PSAP URL in that case, even if it's the same answer that urn:service:sos would return? After all, this PSAP is, by definition, able to provide access to fire department services. That it is not an organizationally separate entity seems to be of no interest to the caller. > > BTW: I thought there was no tree structure for these URNs, so what > does "next-layer-up" mean? There is no tree structure, but I thought earlier discussion had agreed that the top-level service (urn:service.x) is always valid if there are any sub-services? > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 22 22:00:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiMBX-0005IA-1Z; Mon, 22 May 2006 21:59:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiMBV-0005I1-Q0 for ecrit@ietf.org; Mon, 22 May 2006 21:59:45 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiMBT-0002pN-Jh for ecrit@ietf.org; Mon, 22 May 2006 21:59:45 -0400 Received: from [10.0.1.103] ([::ffff:68.106.115.242]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 22 May 2006 22:00:09 -0400 id 0158807A.44726CA9.00003DF1 In-Reply-To: <8C8B5D79-327B-4127-A048-BAD5AA7CCCF5@cs.columbia.edu> References: <32755D354E6B65498C3BD9FD496C7D462C4A4E@oefeg-s04.oefeg.loc> <446F7AD5.4010707@gmx.net> <44721F0B.8030509@cs.columbia.edu> <44723315.6000007@hxr.us> <44723885.8000902@cs.columbia.edu> <44723BA3.1080400@hxr.us> <44723D5D.1060609@cs.columbia.edu> <0CBAC129-A090-44FA-BCB2-76A878F2A540@hxr.us> <8C8B5D79-327B-4127-A048-BAD5AA7CCCF5@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Related services Date: Mon, 22 May 2006 21:59:33 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On May 22, 2006, at 9:27 PM, Henning Schulzrinne wrote: > Why not just provide the PSAP URL in that case, even if it's the > same answer that urn:service:sos would return? After all, this PSAP > is, by definition, able to provide access to fire department > services. That it is not an organizationally separate entity seems > to be of no interest to the caller. I think we are saying the same thing, then. >> >> BTW: I thought there was no tree structure for these URNs, so >> what does "next-layer-up" mean? > > There is no tree structure, but I thought earlier discussion had > agreed that the top-level service (urn:service.x) is always valid > if there are any sub-services? I must have missed that, but I'm fine with this idea. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 23 10:00:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiXR2-00059z-An; Tue, 23 May 2006 10:00:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiXR1-00059u-Vg for ecrit@ietf.org; Tue, 23 May 2006 10:00:31 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiXR0-0000bo-Lg for ecrit@ietf.org; Tue, 23 May 2006 10:00:31 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 23 May 2006 07:00:30 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,161,1146466800"; d="scan'208"; a="28705589:sNHT23687088" 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 k4NE0UvF014323; Tue, 23 May 2006 10:00:30 -0400 (EDT) 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); Tue, 23 May 2006 10:00:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Related services Date: Tue, 23 May 2006 10:00:29 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E61F2@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Related services Thread-Index: AcZ+CByHSqYc8x2aQiaWqS3K552C1QAaPMUQ From: "Michael Hammer \(mhammer\)" To: "Henning Schulzrinne" , "Andrew Newton" X-OriginalArrivalTime: 23 May 2006 14:00:29.0824 (UTC) FILETIME=[40163800:01C67E71] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Please explain what you mean or don't mean by "tree structure". Talking about a services and sub-services sounds like a tree to me. Mike > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > Sent: Monday, May 22, 2006 9:27 PM > To: Andrew Newton > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Related services >=20 > > > > My alarm panel, which uses VoIP, has three buttons=20 > (actually 6, 2 rows=20 > > of three that require both buttons in each row to be=20 > pressed). One is=20 > > labeled "Police", one is labeled "Ambulance" and one is labeled=20 > > "Fire". If I press fire, urn:service.sos.fire is sent to the LoST=20 > > server. The lost server then responds with=20 > > urn:service.sos.scuba-accidents, urn:service.sos.crazy-persons, and=20 > > urn:service.sos.duck-patrol. Why is it not proper for the=20 > LoST server=20 > > simply to >=20 > I'm not suggesting that the server respond with=20 > scuba-accidents or the like; I'm not sure where I gave you=20 > this impression. >=20 >=20 > > respond with "you want urn:service.sos" and here is the URI=20 > for that=20 > > PSAP." Why must the client have to requery by knocking of a label? >=20 > Why not just provide the PSAP URL in that case, even if it's=20 > the same answer that urn:service:sos would return? After all,=20 > this PSAP is, by definition, able to provide access to fire=20 > department services. That it is not an organizationally=20 > separate entity seems to be of no interest to the caller. >=20 > > > > BTW: I thought there was no tree structure for these URNs, so what=20 > > does "next-layer-up" mean? >=20 > There is no tree structure, but I thought earlier discussion=20 > had agreed that the top-level service (urn:service.x) is=20 > always valid if there are any sub-services? >=20 > > > > -andy >=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 Tue May 23 10:07:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiXXb-0007zc-7i; Tue, 23 May 2006 10:07:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiXXZ-0007zX-Uj for ecrit@ietf.org; Tue, 23 May 2006 10:07:17 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiXXX-0000oO-GK for ecrit@ietf.org; Tue, 23 May 2006 10:07:17 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 23 May 2006 10:07:10 -0400 X-IronPort-AV: i="4.05,161,1146456000"; d="scan'208"; a="89243881:sNHT14794124980" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4NE79TL025131; Tue, 23 May 2006 10:07:09 -0400 (EDT) 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); Tue, 23 May 2006 10:07:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Related services (was: Summary of recent discussion) Date: Tue, 23 May 2006 10:07:08 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E61F8@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Related services (was: Summary of recent discussion) Thread-Index: AcZ965QewuzIeaT5Sn6XQB2B25e85gAhm/Xg From: "Michael Hammer \(mhammer\)" To: "Ted Hardie" , "Henning Schulzrinne" X-OriginalArrivalTime: 23 May 2006 14:07:09.0590 (UTC) FILETIME=[2E5DAB60:01C67E72] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org There are a number of good ideas about how to provision such a system. I am wondering if this is intended to be part of the protocol document itself or a separate BCP, given that there are several interpretations of how the protocol is to be used? Mike > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com]=20 > Sent: Monday, May 22, 2006 6:03 PM > To: Henning Schulzrinne > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Related services (was: Summary of recent=20 > discussion) >=20 > At 4:28 PM -0400 5/22/06, Henning Schulzrinne wrote: > >There seem to be two approaches to this problem:=20 > client-based and server-based. > > > >In a client-based approach, the server returns an error when=20 > a particular service is unavailable. The client then retries=20 > with the more general service (sos.police -> sos). > > > >Ted seems to advocate the server-based approach where the=20 > server "guesses" (quoted, since this might be a fairly=20 > predictable algorithm) what the user would want in the=20 > absence of its first choice. >=20 > I actually don't think that's what I'm advocating. I=20 > believe there are cases > where queries will come in for service URNs that are not=20 > supported in the local area. If a local administration=20 > decides that those do not need to get any service, then a=20 > normal "no data" message is returned. I believe, though,=20 > that there are cases where they will wish to use one of the=20 > emergency service responders as a "backup" service for=20 > unknown sos services. Brian indicates that this is commonly=20 > police, and I've used that in my examples. >=20 > I believe the best way to handle that is for the local=20 > administration to provision the unsupported emergency service=20 > URNs with the same data as is present for the "backup"=20 > service (that, is put the sos.police data at sos.foo if=20 > sos.foo is not supported). Nobody has to guess at that=20 > point; it is a straightforward result. >=20 > Based on Brian's message, though, I believe there will be=20 > cases where the local authorities may not want to provision=20 > those service URNs, but will want instead for the LoST server=20 > to return what is, essentially, a compound message "There is=20 > no service available for your query; the backup service is sos.police, > and here is its contact URI". This may be to manage the=20 > client expectation or > to avoid caching of data that is not, strictly speaking=20 > correct. The example I can imagine most clearly here is for=20 > a sos.poison. If the jurisdiction doesn't have a poison=20 > service or a top-level sos service, the client's query for=20 > sos.poison being redirected to sos.police may be far enough=20 > off that a client would prefer to try to make a non-emergency=20 > call to a known hospital number instead. Other clients might=20 > decide to continue the call and ask for police help with=20 > finding a poison center. Whichever choice is made, though,=20 > the metadata about the redirection to other responders may be=20 > valuable. >=20 > Note that none of this is service "guessing"; it's the=20 > jurisdiction covering the location saying what it wants=20 > returned--I think that will be easy if they do it by=20 > providing contact URIs for the services, but also do-able if=20 > they want to provide both a contact URI and the metadata of=20 > which service will be really handling the call. >=20 > Let's put this in jurisdictional terms for a second. If=20 > Happyland has services for fire, police, ambulance, and coast=20 > guard services, the Happylanders likely know those relevant=20 > telephone numbers and will call them in the appropriate moments. > When Happyland adopts LoST, they will populate their LoST=20 > servers with contact URIs for sos.fire, sos.police,=20 > sos.ambulance, and sos.marine. In the telephone system, they=20 > may well have only the specific numbers, with no general=20 > telephone number at all. >=20 > If I roam into Happyland, I may be doing so from someplace=20 > that uses a single response number for all those services. =20 > When I try to look up the contact URI for > emergency services, in other words, I'm going to query for=20 > sos alone. There is > no such service in Happyland. >=20 > What happens next? >=20 > If the LoST server returns only that there is no data for=20 > sos, the device must at least spend time re-querying, which=20 > is a loss of time. If the device knows about sos.fire,=20 > sos.police, sos.ambulance, and sos.marine, etc. it will=20 > presumably need only a few round trips to find something that=20 > works, but any UI input needed will take attention as well as=20 > time--which is not great. In the proxy case, there is no=20 > chance that the proxy will know which more specific URN to=20 > try; it will have to work off some sort of priority table.=20 > The device or proxy may also not know of some URNs in use in=20 > Happyland. > I'm particularly worried about that in cases where a user=20 > input like a dialed 911 or 112 is triggering this input. >=20 > I think we should acknowledge that a client may have to go=20 > through this, but push as much as we can to avoid it. That=20 > means treating it as "best practice" > to create an entry for the covering sos service *even if=20 > there is no corresponding telephone number*. Failing that,=20 > allowing the LoST server to indicate in metadata that the=20 > contact URI is for a service that *will respond* but is not=20 > the one for which the query is made is a second line of=20 > defense. I'd like to see the client/proxy picking a URN from=20 > its known set as the last line of defense. >=20 > regards, > Ted Hardie >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 23 10:15:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiXfd-0000KI-Qo; Tue, 23 May 2006 10:15:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiXfc-0000KC-3V for ecrit@ietf.org; Tue, 23 May 2006 10:15:36 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiXfZ-00011y-S0 for ecrit@ietf.org; Tue, 23 May 2006 10:15:36 -0400 Received: from lion.cs.columbia.edu (IDENT:1prq1mFLOvO1r76tNiTy1Ol1Q564DvK2@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k4NEBXX6012833 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 23 May 2006 10:15:32 -0400 (EDT) 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 k4NEBWBB028090 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 23 May 2006 10:11:32 -0400 Message-ID: <4473180C.2010209@cs.columbia.edu> Date: Tue, 23 May 2006 10:11:24 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Ecrit] Related services References: <072C5B76F7CEAB488172C6F64B30B5E3017E61F2@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3017E61F2@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org If you take a look at the service URN draft, you will notice that service descriptions are indeed hierarchical, i.e., a "tree". You could define (and register) a service such a urn:service:sos.fire.grease.hamburger In practice, it would seem unlikely that the nesting would be deeper than maybe three levels. Michael Hammer (mhammer) wrote: > Please explain what you mean or don't mean by "tree structure". > > Talking about a services and sub-services sounds like a tree to me. > > Mike > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 23 10:17:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiXhb-0000P9-MY; Tue, 23 May 2006 10:17:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiXha-0000P0-IX for ecrit@ietf.org; Tue, 23 May 2006 10:17:38 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiXhY-00016K-4G for ecrit@ietf.org; Tue, 23 May 2006 10:17:38 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FiXhS-0005nv-0a; Tue, 23 May 2006 09:17:30 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Related services (was: Summary of recent discussion) Date: Tue, 23 May 2006 10:17:25 -0400 Message-ID: <095d01c67e73$a2bc5c30$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ965QewuzIeaT5Sn6XQB2B25e85gAhm/XgAABMeEA= In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3017E61F8@xmb-rtp-20b.amer.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I hadn't thought through the "compound reply", but I like the idea. I think I can agree with all of this. Brian > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Monday, May 22, 2006 6:03 PM > To: Henning Schulzrinne > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Related services (was: Summary of recent > discussion) > > At 4:28 PM -0400 5/22/06, Henning Schulzrinne wrote: > >There seem to be two approaches to this problem: > client-based and server-based. > > > >In a client-based approach, the server returns an error when > a particular service is unavailable. The client then retries > with the more general service (sos.police -> sos). > > > >Ted seems to advocate the server-based approach where the > server "guesses" (quoted, since this might be a fairly > predictable algorithm) what the user would want in the > absence of its first choice. > > I actually don't think that's what I'm advocating. I > believe there are cases > where queries will come in for service URNs that are not > supported in the local area. If a local administration > decides that those do not need to get any service, then a > normal "no data" message is returned. I believe, though, > that there are cases where they will wish to use one of the > emergency service responders as a "backup" service for > unknown sos services. Brian indicates that this is commonly > police, and I've used that in my examples. > > I believe the best way to handle that is for the local > administration to provision the unsupported emergency service > URNs with the same data as is present for the "backup" > service (that, is put the sos.police data at sos.foo if > sos.foo is not supported). Nobody has to guess at that > point; it is a straightforward result. > > Based on Brian's message, though, I believe there will be > cases where the local authorities may not want to provision > those service URNs, but will want instead for the LoST server > to return what is, essentially, a compound message "There is > no service available for your query; the backup service is sos.police, > and here is its contact URI". This may be to manage the > client expectation or > to avoid caching of data that is not, strictly speaking > correct. The example I can imagine most clearly here is for > a sos.poison. If the jurisdiction doesn't have a poison > service or a top-level sos service, the client's query for > sos.poison being redirected to sos.police may be far enough > off that a client would prefer to try to make a non-emergency > call to a known hospital number instead. Other clients might > decide to continue the call and ask for police help with > finding a poison center. Whichever choice is made, though, > the metadata about the redirection to other responders may be > valuable. > > Note that none of this is service "guessing"; it's the > jurisdiction covering the location saying what it wants > returned--I think that will be easy if they do it by > providing contact URIs for the services, but also do-able if > they want to provide both a contact URI and the metadata of > which service will be really handling the call. > > Let's put this in jurisdictional terms for a second. If > Happyland has services for fire, police, ambulance, and coast > guard services, the Happylanders likely know those relevant > telephone numbers and will call them in the appropriate moments. > When Happyland adopts LoST, they will populate their LoST > servers with contact URIs for sos.fire, sos.police, > sos.ambulance, and sos.marine. In the telephone system, they > may well have only the specific numbers, with no general > telephone number at all. > > If I roam into Happyland, I may be doing so from someplace > that uses a single response number for all those services. > When I try to look up the contact URI for > emergency services, in other words, I'm going to query for > sos alone. There is > no such service in Happyland. > > What happens next? > > If the LoST server returns only that there is no data for > sos, the device must at least spend time re-querying, which > is a loss of time. If the device knows about sos.fire, > sos.police, sos.ambulance, and sos.marine, etc. it will > presumably need only a few round trips to find something that > works, but any UI input needed will take attention as well as > time--which is not great. In the proxy case, there is no > chance that the proxy will know which more specific URN to > try; it will have to work off some sort of priority table. > The device or proxy may also not know of some URNs in use in > Happyland. > I'm particularly worried about that in cases where a user > input like a dialed 911 or 112 is triggering this input. > > I think we should acknowledge that a client may have to go > through this, but push as much as we can to avoid it. That > means treating it as "best practice" > to create an entry for the covering sos service *even if > there is no corresponding telephone number*. Failing that, > allowing the LoST server to indicate in metadata that the > contact URI is for a service that *will respond* but is not > the one for which the query is made is a second line of > defense. I'd like to see the client/proxy picking a URN from > its known set as the last line of defense. > > regards, > Ted Hardie > > _______________________________________________ > 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 Tue May 23 18:17:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FifBa-0000bG-Ec; Tue, 23 May 2006 18:17:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FifBZ-0000bA-Bm for ecrit@ietf.org; Tue, 23 May 2006 18:17:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FifBZ-0007FU-7R for ecrit@ietf.org; Tue, 23 May 2006 18:17:05 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FifBW-0004ZD-4M for ecrit@ietf.org; Tue, 23 May 2006 18:17:04 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 17:17:18 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 23 May 2006 17:17:18 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 17:17:00 -0500 Message-ID: From: "Thomson, Martin" To: "Brian Rosen" , "Ted Hardie" , "Hannes Tschofenig" Date: Tue, 23 May 2006 17:15:07 -0500 Subject: RE: [Ecrit] Summary of Recent Discussion MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 23 May 2006 22:17:00.0171 (UTC) FILETIME=[9C846DB0:01C67EB6] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <08a001c67de5$5df97490$640fa8c0@cis.neustar.com> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Summary of Recent Discussion Thread-Index: AcZ92c7yR8ToU4/URsSM+uynlreHpwACxmgQADQ6idA= X-Spam-Score: -1.3 (-) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Stastny Richard , 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="===============1874988108==" Errors-To: ecrit-bounces@ietf.org --===============1874988108== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message SSB0aGluayB0aGF0IHdoYXQgVGVkIGlzIHNheWluZy9hc3N1bWluZyBpcyB0aGF0IHNvcyBpcyBh IGdlbmVyYWxpemF0aW9uIG9mIHNvcy5wb2xpY2UsIGFuZCBpdCBpcyB0aGVyZWZvcmUgbG9naWNh bCB0aGF0IHNvcyBiZSB1c2VkIGluIHRoZSBhYnNlbmNlIG9mIHNvcy5wb2xpY2UuICBUaGUgc2Ft ZSBjYW5ub3QgYmUgc2FpZCBmb3IgdGhlIHJldmVyc2UsIHNvcy5wb2xpY2UgaXMgcHJvYmFibHkg bm90IGEgcmVhc29uYWJsZSBnZW5lcmFsaXphdGlvbiBvZiBzb3MuICBUaGVyZWZvcmUsIGlmIHlv dSBvbmx5IGhhdmUgc29zLnBvbGljZSwgYW5kIHRoYXQgaXMgdGhlIGVudGl0eSB0aGF0IHlvdSBp bnRlbmQgdG8gaGF2ZSBzZXJ2ZSBzb3MsIHRoZW4geW91IGR1cGxpY2F0ZSB0aGF0IGRhdGEgaW4g dGhlIHNvcyByZWNvcmQsIHJhdGhlciB0aGFuICJyZWRpcmVjdGluZyIgc29zIHF1ZXJpZXMgdG8g c29zLnBvbGljZS4NCg0KQmVzdCBQcmFjdGljZSB3b3VsZCB0aGVyZWZvcmUgZGljdGF0ZSB0aGF0 IHlvdSB3b3VsZCBhbHdheXMgaGF2ZSBkYXRhIGZvciBzb3MuICBXaGF0IGhhcHBlbnMgYWZ0ZXIg dGhhdCwgZm9yIHRoZSAic3ViLXNlcnZpY2VzIiBpcyBlbnRpcmVseSB1cCB0byBsb2NhbCBwb2xp Y3kuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4gUm9zZW4g W21haWx0bzpickBicmlhbnJvc2VuLm5ldF0NCj4gU2VudDogVHVlc2RheSwgMjMgTWF5IDIwMDYg NzoxOSBBTQ0KPiBUbzogJ1RlZCBIYXJkaWUnOyAnSGFubmVzIFRzY2hvZmVuaWcnDQo+IENjOiAn U3Rhc3RueSBSaWNoYXJkJzsgZWNyaXRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtFY3JpdF0g U3VtbWFyeSBvZiBSZWNlbnQgRGlzY3Vzc2lvbg0KPiANCj4gSSBhbSBjb25mdXNlZCBieQ0KPiA+ IFJldHVybmluZyB0aGUgY29udGFjdCBVUkkgYW5kIHRoZSBzZXJ2aWNlIFVSTiBmb3Igc29zLnBv bGljZSB3aGVuIHRoZXJlDQo+IGlzDQo+ID4gbm8gc29zDQo+ID4gbG9va3MgbGlrZSB0aGUgc2Ft ZSBwcm90b2NvbCBtZWNoYW5pc20gdG8gbWUuICBTbyBJIHRoaW5rIHdlIHNob3VsZG4ndA0KPiB0 cnkNCj4gPiB0byBydWxlIGl0IG91dCBhdCB0aGUgcHJvdG9jb2wgbGV2ZWwsIGJ1dCBhZHZvY2F0 ZSBpbnN0ZWFkIHRoYXQgcGVvcGxlDQo+ID4gYWNjb21wbGlzaA0KPiA+IHRoZSBzYW1lIHRoaW5n IGJ5IHBvcHVsYXRpbmcgdGhlIHNvcyBzZXJ2aWNlIFVSTiB3aXRoIHRoZSBzYW1lIGRhdGEgYXMN Cj4gaXMNCj4gPiBwcmVzZW50IGF0IHNvcy5wb2xpY2UuICAoR2l2ZW4gdGhhdCB0aGlzIGlzIG5v dCBhIHByb3RvY29sIG1lY2hhbmlzbSwNCj4gdGhpcw0KPiA+IHdvdWxkDQo+ID4gYmUgQmVzdCBQ cmFjdGljZSBhdCBtb3N0KS4NCj4gDQo+IElmIGl0IGxvb2tzIGxpa2UgdGhlIHNhbWUgbWVjaGFu aXNtLCBtYXliZSBpdCBzaG91bGQgYmUgdGhlIHNhbWUgbWVjaGFuaXNtDQo+IGFuZCB3ZSBkb24n dCBuZWVkIGFub3RoZXIgbWVjaGFuaXNtLiAgV2h5IGFyZSB5b3UgYWR2b2NhdGluZyBhbg0KPiBh bHRlcm5hdGl2ZQ0KPiB0byByZXR1cm5pbmcgc29zLnBvbGljZSBmb3IgYW4gc29zIHF1ZXJ5IGlm IHlvdSBhcmUgb2theSByZXR1cm5pbmcgc29zIGZvcg0KPiBhbiBzb3MucG9saWNlIHF1ZXJ5Pw0K PiANCj4gQnJpYW4NCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9t OiBUZWQgSGFyZGllIFttYWlsdG86aGFyZGllQHF1YWxjb21tLmNvbV0NCj4gPiBTZW50OiBNb25k YXksIE1heSAyMiwgMjAwNiAzOjU2IFBNDQo+ID4gVG86IEhhbm5lcyBUc2Nob2ZlbmlnDQo+ID4g Q2M6IFN0YXN0bnkgUmljaGFyZDsgQnJpYW4gUm9zZW47IGVjcml0QGlldGYub3JnDQo+ID4gU3Vi amVjdDogUmU6IFtFY3JpdF0gU3VtbWFyeSBvZiBSZWNlbnQgRGlzY3Vzc2lvbg0KPiA+DQo+ID4g QQ0KPiA+ID4NCj4gPiA+PlN0aWxsLCBJIGFncmVlIHRoYXQgcmV0dXJuaW5nIHRoZSBzZXJ2aWNl IFVSTiB0aGF0IGlzIGFzc29jaWF0ZWQgd2l0aA0KPiA+IHRoZSByZXNwb25kZXINCj4gPiA+Pm1h eSBiZSBhcHByb3ByaWF0ZSwgYXMgdGhlcmUgbWF5IGJlIGNhc2VzIHdoZXJlIHRoYXQgd2lsbCBj YXVzZSB0aGUNCj4gPiBjYWxsZXIgdG8NCj4gPiA+Pm1ha2Ugc29tZSBkZWNpc2lvbiAoZS5nLiBk cm9wIHRoZSBjYWxsIGlmIHRoZXkgd2VyZSBjYWxsaW5nIGluIGENCj4gcG9saWNlDQo+ID4gYnJ1 dGFsaXR5DQo+ID4gPj5zaWdodGluZykuICAgSSB0aGluayB0aGF0IHNob3VsZCBub3QgYmUgYSBw cm90b2NvbCBlcnJvciwgaW4gb3RoZXINCj4gPiB3b3JkcywgYnV0IEkgdGhpbmsNCj4gPiA+Pndl IHNob3VsZCBiZSBzdHJvbmdseSBwdXNoaW5nIGZvciBhIEJDUCBvZiB1cm46c2VydmljZTpzb3Mg YmVpbmcgYQ0KPiA+IHBvcHVsYXRlZA0KPiA+ID4+aXRlbSBpbiB0aGUgTG9TVCBlbWVyZ2VuY3kg c2VydmVyOyBpdCByZWFsbHkgZG9lcyBoZWxwDQo+IGludGVyb3BlcmFiaWxpdHkNCj4gPiBoZXJl IHRvDQo+ID4gPj5oYXZlIGEgZGVmYXVsdC4NCj4gPiA+DQo+ID4gPkkgYW0gY29uZnVzZWQgd2l0 aCB0aGlzIHN1Z2dlc3Rpb24uDQo+ID4gPg0KPiA+DQo+ID4gU29ycnkgZm9yIHRoZSBjb25mdXNp b24uICBJIGFtIHN1Z2dlc3RpbmcgdGhhdCBpdCBzaG91bGQgbm90IGJlIGENCj4gcHJvdG9jb2wN Cj4gPiBlcnJvcg0KPiA+IGZvciB0aGUgc2VydmVyIHRvIHJldHVybiB0aGUgY29udGFjdCBVUkkg KyB0aGUgc2VydmljZSBVUk4gd2hlbiB0aGF0DQo+ID4gc2VydmljZQ0KPiA+IFVSTiBkaWZmZXJl ZCBmcm9tIHRoZSBvbmUgdGhhdCB3YXMgcmVxdWVzdGVkLiAgSSB0aGluayB0aGUgYmFzZSByZWFz b24NCj4gZm9yDQo+ID4gdGhpcw0KPiA+IGlzIHRoZSBvbmUgd2UgaWRlbnRpZmllZCBhIGxvbmcg dGltZSBhZ286ICBJIGFzayBmb3Igc29zLmZpcmUsIGJ1dCBvbmx5DQo+ID4gc29zIGlzIHN1cHBv cnRlZDsNCj4gPiBJIHJldHVybiB0aGUgY29udGFjdCBVUkksIGFuZCBsZXQgdGhlIGNsaWVudCBr bm93IHRoYXQgdGhlIGNvbnRhY3QgVVJJDQo+IGlzDQo+ID4gZm9yDQo+ID4gc29zLiAgIFdlIG5l ZWQgdGhhdCB0byBiZSBwb3NzaWJsZS4NCj4gPg0KPiA+IFJldHVybmluZyB0aGUgY29udGFjdCBV UkkgYW5kIHRoZSBzZXJ2aWNlIFVSTiBmb3Igc29zLnBvbGljZSB3aGVuIHRoZXJlDQo+IGlzDQo+ ID4gbm8gc29zDQo+ID4gbG9va3MgbGlrZSB0aGUgc2FtZSBwcm90b2NvbCBtZWNoYW5pc20gdG8g bWUuICBTbyBJIHRoaW5rIHdlIHNob3VsZG4ndA0KPiB0cnkNCj4gPiB0byBydWxlIGl0IG91dCBh dCB0aGUgcHJvdG9jb2wgbGV2ZWwsIGJ1dCBhZHZvY2F0ZSBpbnN0ZWFkIHRoYXQgcGVvcGxlDQo+ ID4gYWNjb21wbGlzaA0KPiA+IHRoZSBzYW1lIHRoaW5nIGJ5IHBvcHVsYXRpbmcgdGhlIHNvcyBz ZXJ2aWNlIFVSTiB3aXRoIHRoZSBzYW1lIGRhdGEgYXMNCj4gaXMNCj4gPiBwcmVzZW50IGF0IHNv cy5wb2xpY2UuICAoR2l2ZW4gdGhhdCB0aGlzIGlzIG5vdCBhIHByb3RvY29sIG1lY2hhbmlzbSwN Cj4gdGhpcw0KPiA+IHdvdWxkDQo+ID4gYmUgQmVzdCBQcmFjdGljZSBhdCBtb3N0KS4NCj4gPg0K PiA+IEkgYWxzbyBhY2tub3dsZWRnZSB0aGF0IHRoZXJlIHdpbGwgYmUgY29ybmVyIGNhc2VzIHdo ZXJlIGdldHRpbmcgYQ0KPiBzZXJ2aWNlDQo+ID4gVVJOIGRpZmZlcmVudCB0aGFuIHRoZSBvbmUg cmVxdWVzdGVkIG1heSBjYXVzZSB0aGUgY2FsbGVyIHRvIGRvDQo+IHNvbWV0aGluZw0KPiA+IG90 aGVyIHRoYW4gY29udGludWUgdGhlIGNhbGwuICBJIGRvbid0IHRoaW5nIHdlIG91Z2h0IHRvIGJl IHRvbw0KPiBjb25jZXJuZWQNCj4gPiBhYm91dCB0aGF0LA0KPiA+IGJ1dCBnaXZlbiB0aGUgcHJv dG9jb2wgbWVjaGFuaXNtIGlzIHRoZXJlLCB3ZSBzaG91bGQgbm90ZSBpdCBtYXkgYmUNCj4gdXNl ZnVsDQo+ID4gaW4gdGhhdCBjYXNlIGFzIHdlbGwuDQo+ID4NCj4gPiBJIGhvcGUgdGhhdCdzIGNs ZWFyZXIsDQo+ID4gCQkJcmVnYXJkcywNCj4gPiAJCQkJVGVkDQo+IA0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRWNyaXQgbWFpbGluZyBs aXN0DQo+IEVjcml0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Vjcml0DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K VGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5 DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBp bmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBB bnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ== --===============1874988108== 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 --===============1874988108==-- From ecrit-bounces@ietf.org Wed May 24 15:23:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiywd-00083w-2h; Wed, 24 May 2006 15:22:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiywc-00083o-53 for ecrit@ietf.org; Wed, 24 May 2006 15:22:58 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fiywa-00015k-Mw for ecrit@ietf.org; Wed, 24 May 2006 15:22:58 -0400 Received: (qmail invoked by alias); 24 May 2006 19:22:55 -0000 Received: from p54987372.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.115.114] by mail.gmx.net (mp017) with SMTP; 24 May 2006 21:22:55 +0200 X-Authenticated: #29516787 Message-ID: <4474B292.9040604@gmx.net> Date: Wed, 24 May 2006 21:22:58 +0200 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.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Ecrit] [Fwd: IETF 66 Draft Submission Deadlines] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Please keep the submission deadlines in mind. ------- There are two (2) Internet-Draft cutoff dates for the 66th IETF Meeting in Montreal, Quebec, Canada: June 19th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, June 19th at 9:00 AM ET. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, June 12th at 9:00 AM ET. June 26th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, June 26th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, July 10th at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts at ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 66th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_66.html. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 24 15:46:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FizJ0-000391-F8; Wed, 24 May 2006 15:46:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FizIz-00038r-8Q for ecrit@ietf.org; Wed, 24 May 2006 15:46:05 -0400 Received: from mx.plaxo.com ([66.151.128.13] helo=mx09.plaxo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FizIx-0002xz-Gg for ecrit@ietf.org; Wed, 24 May 2006 15:46:05 -0400 Received: from bes03.plaxo.com (bes03.plaxo.com [10.1.10.3]) by mx09.plaxo.com (Postfix) with QMQP id DBA9B42008 for ; Wed, 24 May 2006 12:45:58 -0700 (PDT) Message-ID: <1148499958.6648.27023.sendUpdate@mx.plaxo.com> Date: 24 May 2006 19:45:58 -0000 From: "Richard Stastny" To: "Ecrit" Precedence: bulk MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_-------==3478731219" X-Spam-Score: 0.9 (/) X-Scan-Signature: 578029c71870398e30dc7af6a1ae528d Subject: [Ecrit] Your contact info X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Reply-To: Plaxo Contact Update for Richard Stastny List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --_-------==3478731219 Content-Type: multipart/alternative; boundary="_--=======2707394293" --_--=======2707394293 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ecrit, I'm updating my address book. Please take a moment to update me with your latest contact info. Click the following link to correct or confirm your information: https://www.plaxo.com/edit_contact_info?r=12885123448-124335839-815709300 Name: ecrit Job Title: Company: Work E-mail: ecrit@ietf.org Work Phone: Work Fax: Work Address Line 1: Work Address Line 2: Work City, State, Zip: Mobile Phone: Home E-mail: Home Phone: Home Fax: Home Address Line 1: Home Address Line 2: Home City, State, Zip: Birthday: P.S. I've included my Plaxo card below so that you have my current information. I've also attached a copy as a vCard. +----------------- | Richard Stastny | richard.stastny@oefeg.at | | OeFEG | Arsenal Objekt 24 | work: +4317978032 | fax: +4317978013 | mobile: +436644204100 | web: voipandenum.blogspot.com +------------------------------------- ____________________________________________________________ This message was sent to you by richard.stastny@oefeg.at via Plaxo. To opt out: https://www.plaxo.com/opt_out?r=12885123448-124335839-815709300 Plaxo's Privacy Policy: http://www.plaxo.com/support/privacy --_--=======2707394293 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Your Contact Info
=20 =20 =20 =20

Ecrit,

I'm updating= my address book. Please take a moment to update me with your latest cont= act info.

Thanks,
Richard Stastny

 

 =20 =20 =20
=20 =20 =20 =20 =20
=20 =20 =20 =20 =20 =20 =20
=20
=20 =20 =20
=09 ecrit =20
no title
<= /td> =20 no company=
=09 no work address =09
=20 = ecrit@ietf.org
=20 =20 no web page
IM: none
 <= /td> =20 =20 <= td class=3D"table_small" nowrap align=3Dright>none none =20
tel: none
fax: none
mobile: 
pager: 
 
=20 =20 =20
=09 Personal Information =09
=09
=09 =09 no home address =09
=20 no email<= /span>
=20 =20 no web page
IM: none
 <= /td> =20 <= span id=3D"START.PlaxoField.Home.Phone1">none =20 <= td class=3D"table_small" nowrap align=3Dright>none =20 =20
home: 
fax: none
mobile: 
birthday: none
=20
     
 
=20
Click to update your info 3D"->"3D"Click
=20
=20


P.S.= I've attached my current information in a vcard. If you=20 get Plaxo too, we can= stay connected without the hassle of sending emails back and forth.
<= /P> =20

If you do = not wish to receive update request emails from Richard Stastny, click= here to opt-out.

--_--=======2707394293-- --_-------==3478731219 Content-Type: text/x-vcard; charset=ISO-8859-1; name="Richard Stastny.vcf" Content-Disposition: attachment; filename="Richard Stastny.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD=20 VERSION:2.1 N:Stastny;Richard;;; FN:Richard Stastny ORG:OeFEG ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Arsenal Objekt 24;Vienna;;1103;Aus= tria TEL;WORK;VOICE:+4317978032 TEL;CELL;VOICE:+436644204100 TEL;WORK;FAX:+4317978013 EMAIL;PREF;INTERNET;WORK:richard.stastny@oefeg.at URL;WORK:http://voipandenum.blogspot.com END:VCARD --_-------==3478731219 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 --_-------==3478731219-- From ecrit-bounces@ietf.org Sun May 28 09:09:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkL0e-0007pr-7n; Sun, 28 May 2006 09:08:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkL0d-0007pm-Jy for ecrit@ietf.org; Sun, 28 May 2006 09:08:43 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FkL0c-0007R6-0G for ecrit@ietf.org; Sun, 28 May 2006 09:08:43 -0400 Received: (qmail invoked by alias); 28 May 2006 13:08:40 -0000 Received: from p54984608.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.70.8] by mail.gmx.net (mp041) with SMTP; 28 May 2006 15:08:40 +0200 X-Authenticated: #29516787 Message-ID: <4479A0DA.1050509@gmx.net> Date: Sun, 28 May 2006 15:08:42 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ron Watro Subject: Re: [Ecrit] Review of Security Threats Draft References: <6.1.0.6.2.20060522065257.036212f0@po2.bbn.com> In-Reply-To: <6.1.0.6.2.20060522065257.036212f0@po2.bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Ron, thanks a lot for your draft review. Ron Watro wrote: > Here are some brief comments on draft-ietf-ecrit-security-threats-01, > dated April 17 2006 > > Good job by Tom to persevere through the various versions of this > document. > > General comment: The current draft focuses on the security > requirements for just the parts of the VoIP emergency response system > that are ECRIT work items. Some of the previous incarnations of this > document also included an overview of the full system security > concept, so that one could see that the security being proposed for > the ECRIT work items was consistent with at least one full-scale > plan. At the interim meeting, it was decided to drop any discussion > of system security as a whole. This decision was influenced by > several issues, including the desire for ECRIT to make speedy > progress and the lack of any consensus on the full system approach. > There were some dissenting opinions at the interim meeting, arguing > that a properly caveated, strawman view of the full system and its > security concept was needed to provide a basis for the security > services allocated to ECRIT work items. In any event, we currently > have the version without the system view, and going forward we can > expect comments asking why the component security requirements were > not derived from a set of system security requirements (as is > commonly done). Good summary. The document had an interesting history. > > Specific comments are below: > > Abstract > > --doubled "the" in the last sentence > > 1 Introduction > > --suggest changing the two "must be" wordings in the 1st paragraph to > "is being" . The marking idea and the mapping server are not the > only feasible solutions to the problems at hand. --mixture of commas > and periods as list separators in the last paragraph > Fine with me. > 4 Objectives of attackers > > --for the third bullet, it seems conceivable that a structured > emergency service marker could help support the process of preventing > fraudulent emergency calls (by assisting in track-back of the call, > for example). In this case, there could be interaction with ECRIT > work items --inconsistent punctuation at the end of bulleted items I guess you refer to this bullet: o to divert emergency responders to non-emergency sites. No attacks affecting the ECRIT Working Group's decisions on the emergency identifier and mapping protocol have been identified that achieve this objective We don't need to worry too much about the solution space in this document. Luckily. > > 5 Potential Attacks > > 5.1 Identifier attacks > > --Is the emergency identifier known to be just a single bit, or could > it contain data that can be use for other proposes (time stamp, > cryptographic signature?) --You say that theft-of-service calls most > probably will not include any location information - but wouldn't > they mostly likely include falsified location information so that > they look legit but cannot be tracked back to the source? The solution for the emergency identifier is described in http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-03.txt > > 6 Security requirements > > from section 5.1 fraudulent calls --How will a URI be verified as a > PSAP? Will the mapping server be used or is this a non-ECRIT > security requirement? That's subject for investigations in the solution space. I see the mapping server as one possible way to deal with it. --Are long distance calls to remote PSAPs > always fraudulent? No, certainly not since there is no concept of "long distant" anymore. For example, a disreputable foreign entity might > set up a phony PSAP for its people to call. Can a service provider > refuse to carry or perhaps reroute a long distance emergency request? That's largely a policy decision. I hope that they do not refuse such message routing practices. Additionally, you have to consider that you would like to get in touch with a PSAP that is close to your physical location. That's the whole point of this mapping protocol work. Hence, you shouldn't need to get in touch with, for example, your home PSAP when you roam to another country. > > > from section 5.2.1 impersonation of the mapping server --mapping > server discovery is apparently outside the scope of ECRIT topic, so > does ECRIT simply assume that this will be done in a secure manner? Well, that's an interesting point. It is not out-of-scope anymore based on the DNS SRV solution we added to http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-03.txt I went through the section again. We do not state that the discovery procedure is outside the scope of the working group. It is, however, also not the case that we go into a long discussion about its vulernabilities either. > --will the protocol allow exchange with unauthenticated servers if no > authenticated ones can be found? --does it ever make sense to return > mapping server audit data to the client? Is this data encrypted to > make it inaccessible by the client? Is this design intended to > address rogue servers? If not, then why not just store the data on > the server? The discovery procedure as described in http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-03.txt uses DNS. Currently, the procedures for selecting an appropriate server, if you receive multiple onces are described in the same draft. What do you mean by audit data? > from section 5.2.3 snooping attack -- the protocol or system must > provide confidentiality mechanisms but the mapping server should > respond to non-complaint clients with unprotected data if that is the > only option I wouldn't call it "non-compliant clients". There are potentially cases where the end host cannot get the TLS working and hence he shouldn't fail to make an emergency call. > > Final comment: Any concern about "insider attack" -- rogue PSAPs, > SIP proxies, etc? Good point. I guess we haven't been very explicit about it. I wonder where to state something about the fact that "insider attacks" are not covered in this document. As with many other protocol insider attacks are something hard to deal with. Thanks again for the review. Ciao Hannes > > Ron Watro > > > > > > > > > > > > > > _______________________________________________ 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