From ecrit-bounces@ietf.org Mon Oct 02 03:43:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUIS2-0002qh-DA; Mon, 02 Oct 2006 03:42:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUIS1-0002q5-2b for ecrit@ietf.org; Mon, 02 Oct 2006 03:42: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 1GUIK7-0000u1-KJ for ecrit@ietf.org; Mon, 02 Oct 2006 03:34:49 -0400 Received: (qmail invoked by alias); 02 Oct 2006 07:34:46 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp014) with SMTP; 02 Oct 2006 09:34:46 +0200 X-Authenticated: #29516787 Message-ID: <4520C11A.9090706@gmx.net> Date: Mon, 02 Oct 2006 09:34:50 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ECRIT Subject: [Ecrit] PROTO Writeup for draft-ietf-ecrit-service-urn-05.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 have completed our work on the "A Uniform Resource Name (URN) for Services" document. Please find the PROTO writeup for draft-ietf-ecrit-service-urn-05.txt at: http://www.ietf-ecrit.org/draft-ietf-ecrit-service-urn-05.txt-PROTO-writeup.txt Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 02 03:43:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUIS3-0002r9-Q6; Mon, 02 Oct 2006 03:42:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUIS1-0002q5-3Z for ecrit@ietf.org; Mon, 02 Oct 2006 03:42: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 1GUIJx-0000tU-Nz for ecrit@ietf.org; Mon, 02 Oct 2006 03:34:40 -0400 Received: (qmail invoked by alias); 02 Oct 2006 07:34:37 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp030) with SMTP; 02 Oct 2006 09:34:37 +0200 X-Authenticated: #29516787 Message-ID: <4520C110.2060500@gmx.net> Date: Mon, 02 Oct 2006 09:34:40 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ECRIT Subject: [Ecrit] PROTO Writeup for draft-ietf-ecrit-security-threats-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 have completed our work on the "Security Threats and Requirements for Emergency Call Marking and Mapping" document. Please find the PROTO writeup for draft-ietf-ecrit-security-threats-03.txt From ecrit-bounces@ietf.org Mon Oct 02 03:43:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUIS2-0002qh-DA; Mon, 02 Oct 2006 03:42:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUIS1-0002q5-2b for ecrit@ietf.org; Mon, 02 Oct 2006 03:42: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 1GUIK7-0000u1-KJ for ecrit@ietf.org; Mon, 02 Oct 2006 03:34:49 -0400 Received: (qmail invoked by alias); 02 Oct 2006 07:34:46 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp014) with SMTP; 02 Oct 2006 09:34:46 +0200 X-Authenticated: #29516787 Message-ID: <4520C11A.9090706@gmx.net> Date: Mon, 02 Oct 2006 09:34:50 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ECRIT Subject: [Ecrit] PROTO Writeup for draft-ietf-ecrit-service-urn-05.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 have completed our work on the "A Uniform Resource Name (URN) for Services" document. Please find the PROTO writeup for draft-ietf-ecrit-service-urn-05.txt at: http://www.ietf-ecrit.org/draft-ietf-ecrit-service-urn-05.txt-PROTO-writeup.txt Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 02 03:43:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUIS3-0002r9-Q6; Mon, 02 Oct 2006 03:42:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUIS1-0002q5-3Z for ecrit@ietf.org; Mon, 02 Oct 2006 03:42: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 1GUIJx-0000tU-Nz for ecrit@ietf.org; Mon, 02 Oct 2006 03:34:40 -0400 Received: (qmail invoked by alias); 02 Oct 2006 07:34:37 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp030) with SMTP; 02 Oct 2006 09:34:37 +0200 X-Authenticated: #29516787 Message-ID: <4520C110.2060500@gmx.net> Date: Mon, 02 Oct 2006 09:34:40 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ECRIT Subject: [Ecrit] PROTO Writeup for draft-ietf-ecrit-security-threats-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 have completed our work on the "Security Threats and Requirements for Emergency Call Marking and Mapping" document. Please find the PROTO writeup for draft-ietf-ecrit-security-threats-03.txt at: http://www.ietf-ecrit.org/draft-ietf-ecrit-security-threats-03-PROTO-writeup.txt Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit at: http://www.ietf-ecrit.org/draft-ietf-ecrit-security-threats-03-PROTO-writeup.txt Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 02 03:45:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUIUH-0004MH-Dr; Mon, 02 Oct 2006 03:45:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUIS1-0002pa-5L for ecrit@ietf.org; Mon, 02 Oct 2006 03:42:57 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GUIJq-0000t6-Cv for ecrit@ietf.org; Mon, 02 Oct 2006 03:34:34 -0400 Received: (qmail invoked by alias); 02 Oct 2006 07:34:29 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp001) with SMTP; 02 Oct 2006 09:34:29 +0200 X-Authenticated: #29516787 Message-ID: <4520C109.3@gmx.net> Date: Mon, 02 Oct 2006 09:34:33 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ECRIT Subject: [Ecrit] PROTO Writeup for draft-ietf-ecrit-requirements-12.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 have completed our work on the "Requirements for Emergency Context Resolution with Internet Technologies" document. Please find the PROTO writeup for draft-ietf-ecrit-requirements-12.txt at: http://www.ietf-ecrit.org/draft-ietf-ecrit-requirements-12-PROTO-writeup.txt Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 02 03:55:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUIeQ-0003VW-PU; Mon, 02 Oct 2006 03:55:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUIeP-0003Uc-SI for ecrit@ietf.org; Mon, 02 Oct 2006 03:55:45 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GUIeO-0004Pf-ES for ecrit@ietf.org; Mon, 02 Oct 2006 03:55:45 -0400 Received: (qmail invoked by alias); 02 Oct 2006 07:55:43 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp045) with SMTP; 02 Oct 2006 09:55:43 +0200 X-Authenticated: #29516787 Message-ID: <4520C603.20407@gmx.net> Date: Mon, 02 Oct 2006 09:55:47 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Ecrit] PROTO Writeups X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all we have recently sent PROTO writeups to our area directors and the IESG to complete the work on three of our documents (security threats, requirements, service URN). The document shepherding process is described in http://tools.ietf.org/id/draft-ietf-proto-wgchair-doc-shepherding-07.txt Since we have to completed this part of the work we need to focus our work on the remaining items, namely * LoST (& discovery) * Mapping Architecture * ECRIT Framework * Phone BCP The agenda for the next IETF meeting will obviously cover these aspects. Additionally, Steven Kent plans to talk about some ECRIT security aspects. If there are additional presentations please let us know. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 02 04:05:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUInZ-0008R4-E5; Mon, 02 Oct 2006 04:05:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUInX-0008Qz-Pi for ecrit@ietf.org; Mon, 02 Oct 2006 04:05:11 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GUInT-0005Ta-Bi for ecrit@ietf.org; Mon, 02 Oct 2006 04:05:11 -0400 Received: (qmail invoked by alias); 02 Oct 2006 08:05:06 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp028) with SMTP; 02 Oct 2006 10:05:06 +0200 X-Authenticated: #29516787 Message-ID: <4520C835.4000208@gmx.net> Date: Mon, 02 Oct 2006 10:05:09 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ecrit] Review List X-BeenThere: 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, to make progress with our work please review the following documents: LoST: ----- http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-lost/draft-ietf-ecrit-lost-01.txt The issue tracker is available at: http://www.tschofenig.priv.at:8080/lost/index DHCP-based LoST discovery: http://tools.ietf.org/wg/ecrit/draft-polk-ecrit-dhc-lost-discovery-01.txt Mapping Architecture: --------------------- http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-mapping-arch/draft-ietf-ecrit-mapping-arch-00.txt ECRIT Framework: ----------------- http://tools.ietf.org/wg/ecrit/draft-rosen-ecrit-framework-00.txt Phone BCP: ---------- http://www.ietf.org/internet-drafts/draft-rosen-sos-phonebcp-01.txt Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 02 09:46:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUO77-00054c-1J; Mon, 02 Oct 2006 09:45:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUO76-00054U-M6; Mon, 02 Oct 2006 09:45:44 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUO72-0004MP-EL; Mon, 02 Oct 2006 09:45:44 -0400 Received: from [192.168.0.41] (pool-141-153-175-20.mad.east.verizon.net [141.153.175.20]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k92Djau9027522 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 2 Oct 2006 09:45:37 -0400 (EDT) In-Reply-To: <4520C11A.9090706@gmx.net> References: <4520C11A.9090706@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <12B4509F-461F-4BA4-A9D2-C8DE20A3E8F9@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] PROTO Writeup for draft-ietf-ecrit-service-urn-05.txt Date: Mon, 2 Oct 2006 09:45:28 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-PerlMx-Spam: Gauge=XXII, Probability=22%, X-Seen-By filter2.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: iesg@ietf.org, ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Minor update: We have implemented the 'sos' service URN in our NG911 prototype, including on the VoIP client (sipc) and the LoST server. On Oct 2, 2006, at 3:34 AM, Hannes Tschofenig wrote: > Hi all, > > we have completed our work on the "A Uniform Resource Name (URN) > for Services" document. > > Please find the PROTO writeup for > draft-ietf-ecrit-service-urn-05.txt at: > http://www.ietf-ecrit.org/draft-ietf-ecrit-service-urn-05.txt-PROTO- > writeup.txt > > Ciao > Hannes & Marc > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 02 10:06:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOR9-00007q-0i; Mon, 02 Oct 2006 10:06:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOR8-00007l-EL for ecrit@ietf.org; Mon, 02 Oct 2006 10:06:26 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUOR6-0006Un-TH for ecrit@ietf.org; Mon, 02 Oct 2006 10:06:26 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k92E6B0x009409; Mon, 2 Oct 2006 16:06:11 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k92E696e016916; Mon, 2 Oct 2006 16:06:11 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 16:05:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] PROTO Writeup for draft-ietf-ecrit-service-urn-05.txt Date: Mon, 2 Oct 2006 16:05:52 +0200 Message-ID: In-Reply-To: <12B4509F-461F-4BA4-A9D2-C8DE20A3E8F9@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PROTO Writeup for draft-ietf-ecrit-service-urn-05.txt Thread-Index: AcbmKdwdOiu/Zj2xQ1mYryTjm0j+KAAAY5CQ From: "Tschofenig, Hannes" To: "Henning Schulzrinne" , "Hannes Tschofenig" X-OriginalArrivalTime: 02 Oct 2006 14:05:52.0205 (UTC) FILETIME=[DEC4A7D0:01C6E62B] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Very good! I added it to the description to the PROTO writeup.=20 =20 Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > Gesendet: Montag, 2. Oktober 2006 15:45 > An: Hannes Tschofenig > Cc: iesg@ietf.org; ECRIT > Betreff: Re: [Ecrit] PROTO Writeup for=20 > draft-ietf-ecrit-service-urn-05.txt >=20 > Minor update: We have implemented the 'sos' service URN in our NG911 =20 > prototype, including on the VoIP client (sipc) and the LoST server. >=20 > On Oct 2, 2006, at 3:34 AM, Hannes Tschofenig wrote: >=20 > > Hi all, > > > > we have completed our work on the "A Uniform Resource Name (URN) =20 > > for Services" document. > > > > Please find the PROTO writeup for > > draft-ietf-ecrit-service-urn-05.txt at: > >=20 > http://www.ietf-ecrit.org/draft-ietf-ecrit-service-urn-05.txt-PROTO-=20 > > writeup.txt > > > > Ciao > > Hannes & Marc > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 02 16:54:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUUnN-0004P5-K2; Mon, 02 Oct 2006 16:53:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUUnM-0004Oo-Q7; Mon, 02 Oct 2006 16:53:48 -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 1GUUnI-0007Gd-JV; Mon, 02 Oct 2006 16:53:48 -0400 Received: from [192.168.0.109] ([::ffff:64.102.254.33]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Mon, 02 Oct 2006 16:53:18 -0400 id 01588063.45217C3E.00006721 Message-ID: <45217C46.7040803@thinkingcat.com> Date: Mon, 02 Oct 2006 16:53:26 -0400 From: Leslie Daigle User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Hannes Tschofenig References: <4520C11A.9090706@gmx.net> In-Reply-To: <4520C11A.9090706@gmx.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: iesg@ietf.org, ECRIT Subject: [Ecrit] Re: PROTO Writeup for draft-ietf-ecrit-service-urn-05.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 BTW -- don't forget the document needs a 2-week review on urn-nid@apps.ietf.org (per the URN registration procedure). (Henning's earlier version was a) circulated on a prelimary basis only, and b) sufficiently different from the final that this box is not checked). Leslie. Hannes Tschofenig wrote: > Hi all, > > we have completed our work on the "A Uniform Resource Name (URN) for > Services" document. > > Please find the PROTO writeup for > draft-ietf-ecrit-service-urn-05.txt at: > http://www.ietf-ecrit.org/draft-ietf-ecrit-service-urn-05.txt-PROTO-writeup.txt > > > Ciao > Hannes & Marc > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 02 17:21:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUVDw-0008Jj-K3; Mon, 02 Oct 2006 17:21:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUVDv-0008JF-8D for ecrit@ietf.org; Mon, 02 Oct 2006 17:21:15 -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 1GUVDs-0004MO-R5 for ecrit@ietf.org; Mon, 02 Oct 2006 17:21:15 -0400 Received: (qmail invoked by alias); 02 Oct 2006 21:21:11 -0000 Received: from p549868EA.dip.t-dialin.net (EHLO [192.168.2.35]) [84.152.104.234] by mail.gmx.net (mp032) with SMTP; 02 Oct 2006 23:21:11 +0200 X-Authenticated: #29516787 Message-ID: <452182C8.5040808@gmx.net> Date: Mon, 02 Oct 2006 23:21:12 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Leslie Daigle References: <4520C11A.9090706@gmx.net> <45217C46.7040803@thinkingcat.com> In-Reply-To: <45217C46.7040803@thinkingcat.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ECRIT Subject: [Ecrit] Re: PROTO Writeup for draft-ietf-ecrit-service-urn-05.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 Hmmm. Who needs to request the feedback from this list? Ciao Hannes Leslie Daigle schrieb: > > BTW -- don't forget the document needs a 2-week review > on urn-nid@apps.ietf.org (per the URN registration procedure). > > (Henning's earlier version was a) circulated on a prelimary > basis only, and b) sufficiently different from the final that > this box is not checked). > > Leslie. > > Hannes Tschofenig wrote: >> Hi all, >> >> we have completed our work on the "A Uniform Resource Name (URN) for >> Services" document. >> >> Please find the PROTO writeup for >> draft-ietf-ecrit-service-urn-05.txt at: >> http://www.ietf-ecrit.org/draft-ietf-ecrit-service-urn-05.txt-PROTO-writeup.txt >> >> >> Ciao >> Hannes & Marc >> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 02 17:23:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUVGJ-0000wl-1F; Mon, 02 Oct 2006 17:23:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUVGH-0000wR-IA for ecrit@ietf.org; Mon, 02 Oct 2006 17:23:41 -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 1GUVGH-0004kI-GX for ecrit@ietf.org; Mon, 02 Oct 2006 17:23:41 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GUVGF-0003fV-9t for ecrit@ietf.org; Mon, 02 Oct 2006 17:23:41 -0400 Received: from [192.168.0.109] ([::ffff:64.102.254.33]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Mon, 02 Oct 2006 17:23:20 -0400 id 015880AE.45218348.00006F38 Message-ID: <45218350.3020507@thinkingcat.com> Date: Mon, 02 Oct 2006 17:23:28 -0400 From: Leslie Daigle User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Hannes Tschofenig References: <4520C11A.9090706@gmx.net> <45217C46.7040803@thinkingcat.com> <452182C8.5040808@gmx.net> In-Reply-To: <452182C8.5040808@gmx.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.2 (-) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ECRIT Subject: [Ecrit] Re: PROTO Writeup for draft-ietf-ecrit-service-urn-05.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 Generally, the proponents of the URN namespace proposal -- document authors, or the WG. Leslie. Hannes Tschofenig wrote: > Hmmm. > > Who needs to request the feedback from this list? > > Ciao > Hannes > > Leslie Daigle schrieb: >> >> BTW -- don't forget the document needs a 2-week review >> on urn-nid@apps.ietf.org (per the URN registration procedure). >> >> (Henning's earlier version was a) circulated on a prelimary >> basis only, and b) sufficiently different from the final that >> this box is not checked). >> >> Leslie. >> >> Hannes Tschofenig wrote: >>> Hi all, >>> >>> we have completed our work on the "A Uniform Resource Name (URN) for >>> Services" document. >>> >>> Please find the PROTO writeup for >>> draft-ietf-ecrit-service-urn-05.txt at: >>> http://www.ietf-ecrit.org/draft-ietf-ecrit-service-urn-05.txt-PROTO-writeup.txt >>> >>> >>> Ciao >>> Hannes & Marc >>> >> >> > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 02 18:18:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUW7T-0003me-Io; Mon, 02 Oct 2006 18:18:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUW7S-0003mU-AN for ecrit@ietf.org; Mon, 02 Oct 2006 18:18:38 -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 1GUW7P-0004E6-RM for ecrit@ietf.org; Mon, 02 Oct 2006 18:18:38 -0400 Received: (qmail invoked by alias); 02 Oct 2006 22:18:34 -0000 Received: from p549868EA.dip.t-dialin.net (EHLO [192.168.2.35]) [84.152.104.234] by mail.gmx.net (mp020) with SMTP; 03 Oct 2006 00:18:34 +0200 X-Authenticated: #29516787 Message-ID: <4521903A.40407@gmx.net> Date: Tue, 03 Oct 2006 00:18:34 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: urn-nid@apps.ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ECRIT Subject: [Ecrit] Request for Service URN Draft Review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, we would like to solicit a review of the Service URN draft. This work is needed for emergency service systems. You can find the draft here: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-05.txt This document was developed within the ECRIT working group and completed WGLC. I have sent a PROTO writeup to the IESG but learned that an additional review by this group would be needed and helpful. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 05 07:49:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVRjT-0004mT-Cq; Thu, 05 Oct 2006 07:49:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVRjQ-0004m2-RF for ecrit@ietf.org; Thu, 05 Oct 2006 07:49:40 -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 1GVRjK-0007zG-Oo for ecrit@ietf.org; Thu, 05 Oct 2006 07:49:40 -0400 Received: (qmail invoked by alias); 05 Oct 2006 11:49:33 -0000 Received: from dyn-160-39-243-37.dyn.columbia.edu (EHLO [160.39.243.37]) [160.39.243.37] by mail.gmx.net (mp015) with SMTP; 05 Oct 2006 13:49:33 +0200 X-Authenticated: #29516787 Message-ID: <4524F151.8000208@gmx.net> Date: Thu, 05 Oct 2006 13:49:37 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ECRIT , GEOPRIV , IETF SIP List Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Ecrit] Remote Participation at the SDO Emergency Service Workshop X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, this is a reminder that you can participate remotely at the SDO Emergency Service Workshop. For instructions see: http://www.ietf-ecrit.org/EmergencyWorkshop2006 Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 09 16:44:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX1z7-0002tB-QP; Mon, 09 Oct 2006 16:44:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX1z6-0002t6-O1 for ecrit@ietf.org; Mon, 09 Oct 2006 16:44:24 -0400 Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX1z2-00027E-C8 for ecrit@ietf.org; Mon, 09 Oct 2006 16:44:24 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1GX1z12N9N-0000xz; Mon, 09 Oct 2006 22:44:19 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Mon, 09 Oct 2006 20:35:43 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1160426143.44.0.0776555849926.issue8@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de login:518a04bce8f5fdb19ebc1cc661140948 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ecrit] [issue8] Service Numbers in LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: LoST Issue Tracker List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes Tschofenig added the comment: Updated text reads:=20 " 6=2E5. Element: 'ServiceNumber' This element contains the service number, which is a string of digits and the symbols '*' and '#' used to reach the service at that particular location. " ---------- title: Dial Strings in LoST -> Service Numbers in LoST __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 10 08:27:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXGi3-0004Oq-HS; Tue, 10 Oct 2006 08:27:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXGi1-0004Od-MO; Tue, 10 Oct 2006 08:27:45 -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 1GXGi1-0007q3-Ka; Tue, 10 Oct 2006 08:27:45 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GXGhx-0000dn-9J; Tue, 10 Oct 2006 08:27:45 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 10 Oct 2006 08:27:21 -0400 id 0158C19B.452B91A9.00004CB1 In-Reply-To: <048e01c6ec5f$7730e860$640fa8c0@cis.neustar.com> References: <048e01c6ec5f$7730e860$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8EE34F4E-05A5-45AF-ADA9-6CB66F6358C7@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Tue, 10 Oct 2006 08:27:40 -0400 To: Brian Rosen , "Ecrit@Ietf.Org" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 'GEOPRIV WG' , "'Dawson, Martin'" Subject: [Ecrit] Re: [Geopriv] coming to terms on location by reference X-BeenThere: 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 Oct 10, 2006, at 7:30 AM, Brian Rosen wrote: > Well, actually, I want to request that there be an (optional) URI > returned > with the response that could contain information about the > location. This > URI, which need not be specified, would be used by PSAPs and other > responders to obtain additional information about the location with > the sos > service. If two calls queried for the same location, they would > get the > same URI, which might be service dependent. > > You can imagine things like floor plans, lists of hazardous materials, > available surveillance video, entrance information, etc for the sos > services. > > There will probably be authentication, and authorization needed to > access > this information. We have name for this in the software industry. It is called feature creep, and it is known to be one of the causes of project failure. I'm not actually sure how this would even work, as LoST is queried by a call routing function and its contents are used for that. Such a URI would have to be conveyed from the seeker to the PSAP, which is not a LoST issue. We've provided extension points in LoST, so this can be added later once there is a lot more detail about what is wanted. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 10 08:38:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXGsD-0000Jv-7D; Tue, 10 Oct 2006 08:38:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXGsB-0000IN-UO; Tue, 10 Oct 2006 08:38:15 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXGs9-0000v3-KO; Tue, 10 Oct 2006 08:38:15 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GXS86-0004lZ-HQ; Tue, 10 Oct 2006 19:39:27 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Ecrit@Ietf.Org'" Date: Tue, 10 Oct 2006 08:38:08 -0400 Message-ID: <049f01c6ec68$f2d24be0$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: <8EE34F4E-05A5-45AF-ADA9-6CB66F6358C7@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbszEFRiehkztLFSzW1AAVrghlf5QAZGWsA 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: 0a7aa2e6e558383d84476dc338324fab Cc: 'GEOPRIV WG' , "'Dawson, Martin'" Subject: [Ecrit] RE: [Geopriv] coming to terms on location by reference X-BeenThere: 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 I've stated before, we plan to use LoST within the Emergency Services IP Network to route calls from ESRPs to PSAPs and from PSAPs to responders. The URI would not be passed; the PSAP or responders would query for it. It might be feature creep, but it is useful. If the IETF doesn't do it, it may be that NENA does an "embrace and extend", which would be unfortunate, but possible, since we're only talking about features on servers within a domain we control. I'd rather not do this. I certainly don't think we want to create ANOTHER database, with a different protocol, to provide this function. I think it may be very useful for non sos services. For example, an apartment building could post its delivery policy (all deliveries by the side door). The information is seen as coming from the building owners/tenants; the URI would be a URI they provide, pointing back to a data structure they maintain. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Tuesday, October 10, 2006 8:28 AM > To: Brian Rosen; Ecrit@Ietf.Org > Cc: 'Dawson, Martin'; 'GEOPRIV WG' > Subject: Re: [Geopriv] coming to terms on location by reference > > > On Oct 10, 2006, at 7:30 AM, Brian Rosen wrote: > > Well, actually, I want to request that there be an (optional) URI > > returned > > with the response that could contain information about the > > location. This > > URI, which need not be specified, would be used by PSAPs and other > > responders to obtain additional information about the location with > > the sos > > service. If two calls queried for the same location, they would > > get the > > same URI, which might be service dependent. > > > > You can imagine things like floor plans, lists of hazardous materials, > > available surveillance video, entrance information, etc for the sos > > services. > > > > There will probably be authentication, and authorization needed to > > access > > this information. > > We have name for this in the software industry. It is called feature > creep, and it is known to be one of the causes of project failure. > > I'm not actually sure how this would even work, as LoST is queried by > a call routing function and its contents are used for that. Such a > URI would have to be conveyed from the seeker to the PSAP, which is > not a LoST issue. > > We've provided extension points in LoST, so this can be added later > once there is a lot more detail about what is wanted. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 10 08:42:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXGvi-0003Hv-OY; Tue, 10 Oct 2006 08:41:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXGvh-0003Gn-1a; Tue, 10 Oct 2006 08:41:53 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXGvf-0001Ug-Pk; Tue, 10 Oct 2006 08:41:53 -0400 Received: from [127.0.0.1] (play.cs.columbia.edu [128.59.21.100]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k9ACfP2w023091 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 10 Oct 2006 08:41:29 -0400 (EDT) In-Reply-To: <8EE34F4E-05A5-45AF-ADA9-6CB66F6358C7@hxr.us> References: <048e01c6ec5f$7730e860$640fa8c0@cis.neustar.com> <8EE34F4E-05A5-45AF-ADA9-6CB66F6358C7@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <29D43109-25D6-436A-8782-E58FA76D28BB@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Tue, 10 Oct 2006 08:41:07 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: 'GEOPRIV WG' , "'Dawson, Martin'" , "Ecrit@Ietf.Org" Subject: [Ecrit] Re: [Geopriv] coming to terms on location by reference X-BeenThere: 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, I don't think this is necessary; there are already mechanisms in SIP where the caller can insert information about the call, the caller and the location, namely the Call-Info header. Needless to say, this has nothing to do with LByR or LByV. Henning On Oct 10, 2006, at 8:27 AM, Andrew Newton wrote: > > On Oct 10, 2006, at 7:30 AM, Brian Rosen wrote: >> Well, actually, I want to request that there be an (optional) URI >> returned >> with the response that could contain information about the >> location. This >> URI, which need not be specified, would be used by PSAPs and other >> responders to obtain additional information about the location >> with the sos >> service. If two calls queried for the same location, they would >> get the >> same URI, which might be service dependent. >> >> You can imagine things like floor plans, lists of hazardous >> materials, >> available surveillance video, entrance information, etc for the sos >> services. >> >> There will probably be authentication, and authorization needed to >> access >> this information. > > We have name for this in the software industry. It is called > feature creep, and it is known to be one of the causes of project > failure. > > I'm not actually sure how this would even work, as LoST is queried > by a call routing function and its contents are used for that. > Such a URI would have to be conveyed from the seeker to the PSAP, > which is not a LoST issue. > > We've provided extension points in LoST, so this can be added later > once there is a lot more detail about what is wanted. > > -andy > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 10 08:52:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXH5l-0000N8-0T; Tue, 10 Oct 2006 08:52:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXH5k-0000N0-Fj; Tue, 10 Oct 2006 08:52:16 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXH5j-0003np-53; Tue, 10 Oct 2006 08:52:16 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GXSLf-0005ep-Nm; Tue, 10 Oct 2006 19:53:28 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Andrew Newton'" Date: Tue, 10 Oct 2006 08:52:10 -0400 Message-ID: <04b001c6ec6a$e84125f0$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: <29D43109-25D6-436A-8782-E58FA76D28BB@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbszjaYWjZf3rgjTECGmHM11ut8jAAZC/ww 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: 'GEOPRIV WG' , "'Dawson, Martin'" , "'Ecrit@Ietf.Org'" Subject: [Ecrit] RE: [Geopriv] coming to terms on location by reference X-BeenThere: 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 caller doesn't have this data. It's not information about the call or the caller, its information about the location. We plan to use Call-Info for information about the call and the caller. This is different. The caller doesn't necessarily have a relationship with the location other than being an authorized visitor. It would be pretty messy to try to pass the information through the location mechanisms (LCP) to the endpoint and then put it on the call except in an enterprise environment, because the access network doesn't know it either. Its information a building owner or tenant knows. I doubt it fits in the LCP any better than LoST. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, October 10, 2006 8:41 AM > To: Andrew Newton > Cc: Brian Rosen; Ecrit@Ietf.Org; 'GEOPRIV WG'; 'Dawson, Martin' > Subject: Re: [Geopriv] coming to terms on location by reference > > Brian, > > I don't think this is necessary; there are already mechanisms in SIP > where the caller can insert information about the call, the caller > and the location, namely the Call-Info header. > > Needless to say, this has nothing to do with LByR or LByV. > > Henning > > On Oct 10, 2006, at 8:27 AM, Andrew Newton wrote: > > > > > On Oct 10, 2006, at 7:30 AM, Brian Rosen wrote: > >> Well, actually, I want to request that there be an (optional) URI > >> returned > >> with the response that could contain information about the > >> location. This > >> URI, which need not be specified, would be used by PSAPs and other > >> responders to obtain additional information about the location > >> with the sos > >> service. If two calls queried for the same location, they would > >> get the > >> same URI, which might be service dependent. > >> > >> You can imagine things like floor plans, lists of hazardous > >> materials, > >> available surveillance video, entrance information, etc for the sos > >> services. > >> > >> There will probably be authentication, and authorization needed to > >> access > >> this information. > > > > We have name for this in the software industry. It is called > > feature creep, and it is known to be one of the causes of project > > failure. > > > > I'm not actually sure how this would even work, as LoST is queried > > by a call routing function and its contents are used for that. > > Such a URI would have to be conveyed from the seeker to the PSAP, > > which is not a LoST issue. > > > > We've provided extension points in LoST, so this can be added later > > once there is a lot more detail about what is wanted. > > > > -andy > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 10 09:07:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXHJs-0002JO-EI; Tue, 10 Oct 2006 09:06:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXHJr-0002J9-IX; Tue, 10 Oct 2006 09:06:51 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXHJp-0007oz-7R; Tue, 10 Oct 2006 09:06:51 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 10 Oct 2006 06:06:48 -0700 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.20060308/8.12.11) with ESMTP id k9AD6moo031294; Tue, 10 Oct 2006 06:06:48 -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 k9AD6mW4028711; Tue, 10 Oct 2006 06:06:48 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 06:06:48 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 06:06:47 -0700 From: "Marc Linsner" To: "'Brian Rosen'" Date: Tue, 10 Oct 2006 09:06:45 -0400 Message-ID: <000001c6ec6c$f10f1b40$260d0d0a@amer.cisco.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: <04b001c6ec6a$e84125f0$640fa8c0@cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbszjaYWjZf3rgjTECGmHM11ut8jAAZC/wwADG3JFA= X-OriginalArrivalTime: 10 Oct 2006 13:06:48.0127 (UTC) FILETIME=[F1A344F0:01C6EC6C] DKIM-Signature: a=rsa-sha1; q=dns; l=1125; t=1160485608; x=1161349608; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:RE=3A=20[Geopriv]=20coming=20to=20terms=20on=20location=20by=20reference; X=v=3Dcisco.com=3B=20h=3DguaozyNa/KDizmdIMkpEGw+PJK4=3D; b=A+KC9tJlYGUCSHjw4x89PaRHfNHAr3Fj9bzi31r85GFR7ID3NVkSzQhjHQSVBE9OdnJrdTWY ShoMVtFrURtCEGambSX7RHAw3KHNcvzFblyLuy9Djl4HKaOX1GxZfHvX; Authentication-Results: sj-dkim-2.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: 'GEOPRIV WG' , "'Ecrit@Ietf.Org'" Subject: [Ecrit] RE: [Geopriv] coming to terms on location by reference X-BeenThere: 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, > > The caller doesn't have this data. It's not information > about the call or the caller, its information about the location. > > We plan to use Call-Info for information about the call and > the caller. > > This is different. The caller doesn't necessarily have a > relationship with the location other than being an authorized > visitor. It would be pretty messy to try to pass the > information through the location mechanisms (LCP) to the > endpoint and then put it on the call except in an enterprise > environment, because the access network doesn't know it > either. Its information a building owner or tenant knows. I > doubt it fits in the LCP any better than LoST. How does the building owner or tenant get the data into the LoST database? The mess seems to be if the PSAP authorities 'open up' the LoST db for input by any/all. Pidf-lo might be the right place, 'for further info about this location goto '. If there is such information available from the building owner or tenant, that would imply they would probably being running the LIS. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 10 09:14:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXHQm-0006e8-Rh; Tue, 10 Oct 2006 09:14:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXHQl-0006ct-84; Tue, 10 Oct 2006 09:13:59 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXHQj-0000j1-Vr; Tue, 10 Oct 2006 09:13:59 -0400 Received: from [127.0.0.1] (play.cs.columbia.edu [128.59.21.100]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k9ADDboA015096 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 10 Oct 2006 09:13:47 -0400 (EDT) In-Reply-To: <000001c6ec6c$f10f1b40$260d0d0a@amer.cisco.com> References: <000001c6ec6c$f10f1b40$260d0d0a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <566DDC84-BA81-4687-B7E7-0C78CDCBD37E@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Tue, 10 Oct 2006 09:13:39 -0400 To: "Marc Linsner" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: 'GEOPRIV WG' , "'Ecrit@Ietf.Org'" Subject: [Ecrit] Re: [Geopriv] coming to terms on location by reference X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I agree that the biggest problem is that this fundamentally changes the operations & management aspect of LoST, as well as the responsibility for the data content. (LoST operator: "You mean I have to check each URL to make sure it doesn't point to whitehouse.com instead of whitehouse.gov?") I will note that RPID already contains information describing the location (placetype and others). It would not be difficult to define another DHCP-civic option, for example, for a location-related URL. This fits well within CIPID; it already has a element. On Oct 10, 2006, at 9:06 AM, Marc Linsner wrote: > > How does the building owner or tenant get the data into the LoST > database? > > The mess seems to be if the PSAP authorities 'open up' the LoST db > for input > by any/all. > > Pidf-lo might be the right place, 'for further info about this > location goto > '. If there is such information available from the building > owner or > tenant, that would imply they would probably being running the LIS. > > -Marc- > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 10 09:23:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXHZK-00025s-5k; Tue, 10 Oct 2006 09:22:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXHZI-00024V-H2; Tue, 10 Oct 2006 09:22:48 -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 1GXHZH-0002Rx-Ar; Tue, 10 Oct 2006 09:22:48 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 10 Oct 2006 09:22:19 -0400 id 0158C13A.452B9E8B.000057BD In-Reply-To: <04b001c6ec6a$e84125f0$640fa8c0@cis.neustar.com> References: <04b001c6ec6a$e84125f0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <142B4F36-F4DC-4069-9AB1-F3451C3D22E0@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Tue, 10 Oct 2006 09:22:39 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: GEOPRIV WG , "Ecrit@Ietf.Org" Subject: [Ecrit] Re: [Geopriv] coming to terms on location by reference X-BeenThere: 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 Oct 10, 2006, at 8:52 AM, Brian Rosen wrote: > The caller doesn't have this data. It's not information about the > call or > the caller, its information about the location. > > We plan to use Call-Info for information about the call and the > caller. > > This is different. How can you possibly expect us to put it in LoST if we don't know what it is and it hasn't been described very well? > I doubt it fits in the LCP > any better than LoST. Actually, there is the dhc-lost draft which has just now (or will become) an ECRIT work item. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 10 09:30:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXHgI-0002Cm-HJ; Tue, 10 Oct 2006 09:30:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXHgH-0002CK-OT; Tue, 10 Oct 2006 09:30:01 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXHg8-0004V1-AK; Tue, 10 Oct 2006 09:30:01 -0400 Received: from ([139.76.131.91]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.163708277; Tue, 10 Oct 2006 09:29:36 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 10 Oct 2006 09:29:36 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 10 Oct 2006 09:29:35 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Importance: normal Priority: normal Date: Tue, 10 Oct 2006 09:29:35 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA2B520A@crexc41p> In-Reply-To: <04b001c6ec6a$e84125f0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] coming to terms on location by reference Thread-Index: AcbszjaYWjZf3rgjTECGmHM11ut8jAAZC/wwADFgN0A= From: "Stark, Barbara" To: "Brian Rosen" , "Henning Schulzrinne" , "Andrew Newton" X-OriginalArrivalTime: 10 Oct 2006 13:29:35.0883 (UTC) FILETIME=[20E245B0:01C6EC70] X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: GEOPRIV WG , "Dawson, Martin" , "Ecrit@Ietf.Org" Subject: [Ecrit] RE: [Geopriv] coming to terms on location by reference X-BeenThere: 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 take on this is that it sounds like an operational nightmare. What used to be a fairly simple system that just needed lots of location info, and PSAP boundary and contact info, now has to have logins/passwords for managers of every large building in a city. And there will need to be a big support desk, for all these people to call when they can't figure out how to input or update their info. And then we'll need laws and regulations to force them to put the info in the system (or it will never happen), and the laws will need to cover what the minimum data set has to be. And we'll need to have a consistent format for all the data, with XML labels for exits, circuit breakers, fire extinguishers, escape ladders, etc., and common notation for how to express their location inside a building; all the building managers will need some tools to help them get all the data formatted correctly. My head hurts just thinking of the bureaucracy that would be created to try to get this done right. Not that bureaucracy tends to get things right... Barbara=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, October 10, 2006 8:52 AM > To: 'Henning Schulzrinne'; 'Andrew Newton' > Cc: 'GEOPRIV WG'; 'Dawson,Martin'; 'Ecrit@Ietf.Org' > Subject: RE: [Geopriv] coming to terms on location by reference >=20 >=20 > The caller doesn't have this data. It's not information=20 > about the call or > the caller, its information about the location. >=20 > We plan to use Call-Info for information about the call and=20 > the caller. >=20 > This is different. The caller doesn't necessarily have a=20 > relationship with > the location other than being an authorized visitor. It=20 > would be pretty > messy to try to pass the information through the location=20 > mechanisms (LCP) > to the endpoint and then put it on the call except in an enterprise > environment, because the access network doesn't know it either. Its > information a building owner or tenant knows. I doubt it=20 > fits in the LCP > any better than LoST. >=20 > Brian >=20 > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Tuesday, October 10, 2006 8:41 AM > > To: Andrew Newton > > Cc: Brian Rosen; Ecrit@Ietf.Org; 'GEOPRIV WG'; 'Dawson, Martin' > > Subject: Re: [Geopriv] coming to terms on location by reference > >=20 > > Brian, > >=20 > > I don't think this is necessary; there are already mechanisms in SIP > > where the caller can insert information about the call, the caller > > and the location, namely the Call-Info header. > >=20 > > Needless to say, this has nothing to do with LByR or LByV. > >=20 > > Henning > >=20 > > On Oct 10, 2006, at 8:27 AM, Andrew Newton wrote: > >=20 > > > > > > On Oct 10, 2006, at 7:30 AM, Brian Rosen wrote: > > >> Well, actually, I want to request that there be an (optional) URI > > >> returned > > >> with the response that could contain information about the > > >> location. This > > >> URI, which need not be specified, would be used by PSAPs=20 > and other > > >> responders to obtain additional information about the location > > >> with the sos > > >> service. If two calls queried for the same location, they would > > >> get the > > >> same URI, which might be service dependent. > > >> > > >> You can imagine things like floor plans, lists of hazardous > > >> materials, > > >> available surveillance video, entrance information, etc=20 > for the sos > > >> services. > > >> > > >> There will probably be authentication, and authorization=20 > needed to > > >> access > > >> this information. > > > > > > We have name for this in the software industry. It is called > > > feature creep, and it is known to be one of the causes of project > > > failure. > > > > > > I'm not actually sure how this would even work, as LoST is queried > > > by a call routing function and its contents are used for that. > > > Such a URI would have to be conveyed from the seeker to the PSAP, > > > which is not a LoST issue. > > > > > > We've provided extension points in LoST, so this can be=20 > added later > > > once there is a lot more detail about what is wanted. > > > > > > -andy > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA624 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 10 09:45:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXHul-0006j4-Sn; Tue, 10 Oct 2006 09:44:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXHul-0006iw-59; Tue, 10 Oct 2006 09:44:59 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXHui-0008NM-Rs; Tue, 10 Oct 2006 09:44:59 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GXTAe-0001y2-Iy; Tue, 10 Oct 2006 20:46:09 -0500 From: "Brian Rosen" To: "'Marc Linsner'" Date: Tue, 10 Oct 2006 09:44:51 -0400 Message-ID: <04c001c6ec72$4488a2f0$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: <000001c6ec6c$f10f1b40$260d0d0a@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbszjaYWjZf3rgjTECGmHM11ut8jAAZC/wwADG3JFAAYkwdkA== 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 'GEOPRIV WG' , "'Ecrit@Ietf.Org'" Subject: [Ecrit] RE: [Geopriv] coming to terms on location by reference X-BeenThere: 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 > How does the building owner or tenant get the data into the LoST database? Basically, it probably comes through the PSAP or some other government authority. Since I expect the PSAP to contract operation of the LoST database, it probably is another service that entity runs. Eventually, I'd like the "validation" mechanism to work for sub building levels (floor, room, ...) and the path would be the same. It's fairly straightforward to validate it, using the post office and the fact that the owner, and even the tenants are known to the authorities. > The mess seems to be if the PSAP authorities 'open up' the LoST db for > input > by any/all. It's just a URI. It's not opening it up very much. > > Pidf-lo might be the right place, 'for further info about this location > goto > '. If there is such information available from the building owner or > tenant, that would imply they would probably being running the LIS. You are just moving the problem. I don't mind that too much, although I didn't think we wanted to carry the data all the way through the path. If you put it in the PIDF, then the access network has to handle it. That's not too bad, although it falls apart when there is a tenant/building owner situation. The tenant is a subscriber of the access network, but the building owner isn't. The real reason I don't want to do that is that it gives the access network more obligations. I don't want to go there. We're going to have enough trouble getting every access network to deploy a LIS and an LCP. Adding more work is counterproductive. That's not a good protocol engineering reason, but it's a pretty good reason nonetheless. It seems to fit LoST: Location+Service in, URI out. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 10 09:52:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXI1d-00058e-Ov; Tue, 10 Oct 2006 09:52:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXI1d-00058W-4P; Tue, 10 Oct 2006 09:52:05 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXI1b-0001yZ-M4; Tue, 10 Oct 2006 09:52:05 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GXTHX-0002S6-87; Tue, 10 Oct 2006 20:53:15 -0500 From: "Brian Rosen" To: "'Stark, Barbara'" , "'Henning Schulzrinne'" , "'Andrew Newton'" Date: Tue, 10 Oct 2006 09:51:57 -0400 Message-ID: <04c401c6ec73$42e9a380$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: <7582BC68E4994F4ABF0BD4723975C3FA2B520A@crexc41p> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbszjaYWjZf3rgjTECGmHM11ut8jAAZC/wwADFgN0AAYWX8IA== 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: d16ce744298aacf98517bc7c108bd198 Cc: 'GEOPRIV WG' , "'Dawson, Martin'" , "'Ecrit@Ietf.Org'" Subject: [Ecrit] RE: [Geopriv] coming to terms on location by reference X-BeenThere: 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 No, it's just a URI. The only mechanism you need is a way to supply the URI. You validate it with a post card. The data format is another story, and outside the expertise of this group. It will, I'm sure, evolve. It can be a local matter: it's information about a building that the PSAP and responders that serve that building agree is useful. The other side of your argument is that we should not have the possibility to provide this information, or, as they do now, the fire chief can carry a box of paper floor plans in the trunk of his car. We can do this another way, but it seems useful to have a mechanism that works across the Internet. Brian > -----Original Message----- > From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] > Sent: Tuesday, October 10, 2006 9:30 AM > To: Brian Rosen; Henning Schulzrinne; Andrew Newton > Cc: GEOPRIV WG; Dawson,Martin; Ecrit@Ietf.Org > Subject: RE: [Geopriv] coming to terms on location by reference > > My take on this is that it sounds like an operational nightmare. What > used to be a fairly simple system that just needed lots of location > info, and PSAP boundary and contact info, now has to have > logins/passwords for managers of every large building in a city. And > there will need to be a big support desk, for all these people to call > when they can't figure out how to input or update their info. And then > we'll need laws and regulations to force them to put the info in the > system (or it will never happen), and the laws will need to cover what > the minimum data set has to be. And we'll need to have a consistent > format for all the data, with XML labels for exits, circuit breakers, > fire extinguishers, escape ladders, etc., and common notation for how to > express their location inside a building; all the building managers will > need some tools to help them get all the data formatted correctly. My > head hurts just thinking of the bureaucracy that would be created to try > to get this done right. Not that bureaucracy tends to get things > right... > Barbara > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, October 10, 2006 8:52 AM > > To: 'Henning Schulzrinne'; 'Andrew Newton' > > Cc: 'GEOPRIV WG'; 'Dawson,Martin'; 'Ecrit@Ietf.Org' > > Subject: RE: [Geopriv] coming to terms on location by reference > > > > > > The caller doesn't have this data. It's not information > > about the call or > > the caller, its information about the location. > > > > We plan to use Call-Info for information about the call and > > the caller. > > > > This is different. The caller doesn't necessarily have a > > relationship with > > the location other than being an authorized visitor. It > > would be pretty > > messy to try to pass the information through the location > > mechanisms (LCP) > > to the endpoint and then put it on the call except in an enterprise > > environment, because the access network doesn't know it either. Its > > information a building owner or tenant knows. I doubt it > > fits in the LCP > > any better than LoST. > > > > Brian > > > > > -----Original Message----- > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > Sent: Tuesday, October 10, 2006 8:41 AM > > > To: Andrew Newton > > > Cc: Brian Rosen; Ecrit@Ietf.Org; 'GEOPRIV WG'; 'Dawson, Martin' > > > Subject: Re: [Geopriv] coming to terms on location by reference > > > > > > Brian, > > > > > > I don't think this is necessary; there are already mechanisms in SIP > > > where the caller can insert information about the call, the caller > > > and the location, namely the Call-Info header. > > > > > > Needless to say, this has nothing to do with LByR or LByV. > > > > > > Henning > > > > > > On Oct 10, 2006, at 8:27 AM, Andrew Newton wrote: > > > > > > > > > > > On Oct 10, 2006, at 7:30 AM, Brian Rosen wrote: > > > >> Well, actually, I want to request that there be an (optional) URI > > > >> returned > > > >> with the response that could contain information about the > > > >> location. This > > > >> URI, which need not be specified, would be used by PSAPs > > and other > > > >> responders to obtain additional information about the location > > > >> with the sos > > > >> service. If two calls queried for the same location, they would > > > >> get the > > > >> same URI, which might be service dependent. > > > >> > > > >> You can imagine things like floor plans, lists of hazardous > > > >> materials, > > > >> available surveillance video, entrance information, etc > > for the sos > > > >> services. > > > >> > > > >> There will probably be authentication, and authorization > > needed to > > > >> access > > > >> this information. > > > > > > > > We have name for this in the software industry. It is called > > > > feature creep, and it is known to be one of the causes of project > > > > failure. > > > > > > > > I'm not actually sure how this would even work, as LoST is queried > > > > by a call routing function and its contents are used for that. > > > > Such a URI would have to be conveyed from the seeker to the PSAP, > > > > which is not a LoST issue. > > > > > > > > We've provided extension points in LoST, so this can be > > added later > > > > once there is a lot more detail about what is wanted. > > > > > > > > -andy > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > ***** > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential, proprietary, and/or > privileged material. Any review, retransmission, dissemination or other > use of, or taking of any action in reliance upon this information by > persons or entities other than the intended recipient is prohibited. If > you received this in error, please contact the sender and delete the > material from all computers. GA624 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 10 09:59:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXI8p-00076Y-EO; Tue, 10 Oct 2006 09:59:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXI8o-00076K-Bv; Tue, 10 Oct 2006 09:59:30 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXI8k-0003cT-Oa; Tue, 10 Oct 2006 09:59:29 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GXTOf-00030i-1Y; Tue, 10 Oct 2006 21:00:37 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Date: Tue, 10 Oct 2006 09:59:15 -0400 Message-ID: <04c801c6ec74$4a388f60$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: <142B4F36-F4DC-4069-9AB1-F3451C3D22E0@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acbs0+yyLPuETfh9TUGUw51nABnZ/QAYJy5Q 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: 7d33c50f3756db14428398e2bdedd581 Cc: 'GEOPRIV WG' , "'Ecrit@Ietf.Org'" Subject: [Ecrit] RE: [Geopriv] coming to terms on location by reference X-BeenThere: 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 > How can you possibly expect us to put it in LoST if we don't know > what it is and it hasn't been described very well? It's a URI. The format and protocol can be defined locally, because the location and the service (PSAP and Responders) are local to one another. What works in the U.S. probably won't work in China. The URI parameter however is universal. Every LoST server could support it. > > > I doubt it fits in the LCP > > any better than LoST. > > Actually, there is the dhc-lost draft which has just now (or will > become) an ECRIT work item. I like dhc-lost, but it's not, as you know, universally applicable. It also requires that we have the endpoint fetch and pass it through the call, although I don't consider that too much of a problem. I'm more worried that because dhcp is not universal, we need a variety of mechanisms and endpoints would have to implement them all. A parameter in the LoST return is much simpler to me. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 10 10:04:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXIDq-0000NB-8w; Tue, 10 Oct 2006 10:04:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXIDo-0000My-5B; Tue, 10 Oct 2006 10:04:40 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXIDl-0004pD-PX; Tue, 10 Oct 2006 10:04:40 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 10 Oct 2006 07:04:37 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9AE4air017235; Tue, 10 Oct 2006 07:04:36 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9AE4aW4013282; Tue, 10 Oct 2006 07:04:36 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 07:04:36 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 07:04:36 -0700 From: "Marc Linsner" To: "'Brian Rosen'" Date: Tue, 10 Oct 2006 10:04:33 -0400 Message-ID: <000801c6ec75$045cb0b0$260d0d0a@amer.cisco.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: <04c001c6ec72$4488a2f0$640fa8c0@cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbszjaYWjZf3rgjTECGmHM11ut8jAAZC/wwADG3JFAAYkwdkADD47LQ X-OriginalArrivalTime: 10 Oct 2006 14:04:36.0515 (UTC) FILETIME=[04F54730:01C6EC75] DKIM-Signature: a=rsa-sha1; q=dns; l=1825; t=1160489076; x=1161353076; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:RE=3A=20[Geopriv]=20coming=20to=20terms=20on=20location=20by=20reference; X=v=3Dcisco.com=3B=20h=3DguaozyNa/KDizmdIMkpEGw+PJK4=3D; b=XjxBZLeBE1Q4FhL/DGDXLWGhrrU4HUc3eR31hhY4iXy9FryCHWtLuUvyQDJjrnC8o3FdBTCo mg4+mpF+N09RCnJ30eU6Hpfl5jmoyiDbtZfxMqfRP5cvwzSGARfw0DCZ; Authentication-Results: sj-dkim-4.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: 'GEOPRIV WG' , "'Ecrit@Ietf.Org'" Subject: [Ecrit] RE: [Geopriv] coming to terms on location by reference X-BeenThere: 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 > > > > Pidf-lo might be the right place, 'for further info about > this location > > goto > > '. If there is such information available from the > building owner or > > tenant, that would imply they would probably being running the LIS. > You are just moving the problem. But I'm moving the problem to the owner of the data! I don't mind that too much, > although I > didn't think we wanted to carry the data all the way through > the path. If > you put it in the PIDF, then the access network has to handle > it. That's > not too bad, although it falls apart when there is a > tenant/building owner > situation. The tenant is a subscriber of the access network, but the > building owner isn't. I don't understand this. You are implying that a tenant that is large enough to have extraneous information about their location (floor plans, hazardous chemicals, etc.), but yet does not control (relies on someone else) the operation their access network/LIS? Makes no sense. Even residential *could* operate their own LIS, regardless of the access provider (yes, reverse DNS LIS discovery would be broken, but it's a bad mechanism to start with). > > The real reason I don't want to do that is that it gives the > access network > more obligations. I don't want to go there. We're going to > have enough > trouble getting every access network to deploy a LIS and an > LCP. Adding > more work is counterproductive. That's not a good protocol > engineering > reason, but it's a pretty good reason nonetheless. > > It seems to fit LoST: Location+Service in, URI out. I agree, the emerging LoST protocol appears to be a good fit for your application. Having Public Safety provide the service is where this falls apart. -Marc- > > Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 10 10:09:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXIHl-0002BL-OV; Tue, 10 Oct 2006 10:08:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXIHk-0002B3-W9; Tue, 10 Oct 2006 10:08:44 -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 1GXIHf-0005Ta-Px; Tue, 10 Oct 2006 10:08:44 -0400 Received: from [172.16.10.86] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Tue, 10 Oct 2006 10:08:20 -0400 id 0158C1D7.452BA954.00006351 Message-ID: <452BA95C.1020209@hxr.us> Date: Tue, 10 Oct 2006 10:08:28 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen References: <04c801c6ec74$4a388f60$640fa8c0@cis.neustar.com> In-Reply-To: <04c801c6ec74$4a388f60$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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: 'GEOPRIV WG' , "'Ecrit@Ietf.Org'" Subject: [Ecrit] Re: [Geopriv] coming to terms on location by reference X-BeenThere: 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: >> How can you possibly expect us to put it in LoST if we don't know >> what it is and it hasn't been described very well? > It's a URI. The format and protocol can be defined locally, because the > location and the service (PSAP and Responders) are local to one another. > What works in the U.S. probably won't work in China. The URI parameter > however is universal. Every LoST server could support it. If it is not universal, how do you know a URI is applicable to all jurisdictions? You seem to be treating a URI as a blob. If it is a blob you want, LoST already has that in the form of an extension point... which can contain a URI or a base 64 encoded JPEG of your cat... or both. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 12 11:33:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY2YI-0006SW-Sn; Thu, 12 Oct 2006 11:32:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY2YH-0006SN-Ag; Thu, 12 Oct 2006 11:32:53 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY2YE-0004xF-PY; Thu, 12 Oct 2006 11:32:53 -0400 Received: from dynamic-acs-24-154-127-115.zoominternet.net ([24.154.127.115] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GY2Y9-0004Ke-KR; Thu, 12 Oct 2006 10:32:46 -0500 From: "Brian Rosen" To: "'Brian Rosen'" , "'Andrew Newton'" Subject: RE: [Ecrit] RE: [Geopriv] coming to terms on location by reference Date: Thu, 12 Oct 2006 11:32:42 -0400 Message-ID: <003201c6ee13$aa9f6540$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: Acbs0+yyLPuETfh9TUGUw51nABnZ/QAYJy5QADZFRyA= In-Reply-To: <04c801c6ec74$4a388f60$640fa8c0@cis.neustar.com> 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: 4adaf050708fb13be3316a9eee889caa Cc: 'GEOPRIV WG' , "'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 Roger Marshall just gave me a suggestion to fix this simply, no new feature required. Define a new service URN that returns this data. Done. That's all we need. Brian > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, October 10, 2006 9:59 AM > To: 'Andrew Newton' > Cc: 'GEOPRIV WG'; 'Ecrit@Ietf.Org' > Subject: [Ecrit] RE: [Geopriv] coming to terms on location by reference > > > How can you possibly expect us to put it in LoST if we don't know > > what it is and it hasn't been described very well? > It's a URI. The format and protocol can be defined locally, because the > location and the service (PSAP and Responders) are local to one another. > What works in the U.S. probably won't work in China. The URI parameter > however is universal. Every LoST server could support it. > > > > > > I doubt it fits in the LCP > > > any better than LoST. > > > > Actually, there is the dhc-lost draft which has just now (or will > > become) an ECRIT work item. > I like dhc-lost, but it's not, as you know, universally applicable. > > It also requires that we have the endpoint fetch and pass it through the > call, although I don't consider that too much of a problem. I'm more > worried that because dhcp is not universal, we need a variety of > mechanisms > and endpoints would have to implement them all. A parameter in the LoST > return is much simpler to me. > > > _______________________________________________ > 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 Oct 12 12:57:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY3sB-0008W2-7A; Thu, 12 Oct 2006 12:57:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY3s9-0008Vf-Rm; Thu, 12 Oct 2006 12:57:29 -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 1GY3s4-0005RQ-ME; Thu, 12 Oct 2006 12:57:29 -0400 Received: from [172.16.10.86] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Thu, 12 Oct 2006 12:57:04 -0400 id 015880D3.452E73E0.00001D16 Message-ID: <452E73E9.2060905@hxr.us> Date: Thu, 12 Oct 2006 12:57:13 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] RE: [Geopriv] coming to terms on location by reference References: <003201c6ee13$aa9f6540$640fa8c0@cis.neustar.com> In-Reply-To: <003201c6ee13$aa9f6540$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: 7aefe408d50e9c7c47615841cb314bed Cc: 'GEOPRIV WG' , "'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: > Define a new service URN that returns this data. Define a new service URN that returns the URI you want? Is that the idea? Fancy that, using URNs for their originally envisioned purpose. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 12 13:20:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY4EH-0005LR-MY; Thu, 12 Oct 2006 13:20:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY4EH-0005LJ-64; Thu, 12 Oct 2006 13:20:21 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY4EF-0008VD-Up; Thu, 12 Oct 2006 13:20:21 -0400 Received: from dynamic-acs-24-154-127-115.zoominternet.net ([24.154.127.115] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GY4E9-0003KP-Sm; Thu, 12 Oct 2006 12:20:14 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] RE: [Geopriv] coming to terms on location by reference Date: Thu, 12 Oct 2006 13:20:13 -0400 Message-ID: <007a01c6ee22$afac9620$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: AcbuH4IOZGBlpG5cROuXdZFV6V0KcAAAnPmw In-Reply-To: <452E73E9.2060905@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 - [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: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: 'GEOPRIV WG' , "'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 Yeah, well, sorry. I should have made that observation myself. Thanks to Roger for pointing out the obvious. In a NENA call today it was observed that, really, in at least a large enterprise environment, it would be best if it WAS in the PIDF. In the general case, it is hard to always assume the operator of the LIS has the data, but in the case of the enterprise who runs a LIS, it does, and in that case it is a whole lot easier to supply it in the PIDF than to get it put in the LoST database. That may mean it makes sense to allow the (same) URI in the PIDF. I'm not sure I like "both" as an answer here, but the cases are pretty different. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Thursday, October 12, 2006 12:57 PM > To: Brian Rosen > Cc: 'GEOPRIV WG'; 'Ecrit@Ietf.Org' > Subject: Re: [Ecrit] RE: [Geopriv] coming to terms on location by > reference > > Brian Rosen wrote: > > Define a new service URN that returns this data. > > Define a new service URN that returns the URI you want? Is that the idea? > Fancy that, using URNs for their originally envisioned purpose. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 12 14:16:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY56c-0007MW-0E; Thu, 12 Oct 2006 14:16:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY56a-0007M9-HT; Thu, 12 Oct 2006 14:16:28 -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 1GY56V-0005Jm-BJ; Thu, 12 Oct 2006 14:16:28 -0400 Received: from [172.16.10.86] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Thu, 12 Oct 2006 14:15:53 -0400 id 015880DB.452E8659.00002FDA Message-ID: <452E8662.2080504@hxr.us> Date: Thu, 12 Oct 2006 14:16:02 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] RE: [Geopriv] coming to terms on location by reference References: <007a01c6ee22$afac9620$640fa8c0@cis.neustar.com> In-Reply-To: <007a01c6ee22$afac9620$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: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: 'GEOPRIV WG' , "'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: > Yeah, well, sorry. I should have made that observation myself. Thanks to > Roger for pointing out the obvious. > > In a NENA call today it was observed that, really, in at least a large > enterprise environment, it would be best if it WAS in the PIDF. In the > general case, it is hard to always assume the operator of the LIS has the > data, but in the case of the enterprise who runs a LIS, it does, and in that > case it is a whole lot easier to supply it in the PIDF than to get it put in > the LoST database. > > That may mean it makes sense to allow the (same) URI in the PIDF. I'm not > sure I like "both" as an answer here, but the cases are pretty different. Perhaps my point was lost (no pun intended). If it is a URI you want, then using a URN to get it involves only DNS, not PIDF nor LoST. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 12 14:31:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY5Ki-0005ek-UX; Thu, 12 Oct 2006 14:31:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY5Ki-0005ec-Ke; Thu, 12 Oct 2006 14:31:04 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY5Kh-000059-B8; Thu, 12 Oct 2006 14:31:04 -0400 Received: from dynamic-acs-24-154-127-115.zoominternet.net ([24.154.127.115] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GY5Kb-0001TE-H5; Thu, 12 Oct 2006 13:30:57 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] RE: [Geopriv] coming to terms on location by reference Date: Thu, 12 Oct 2006 14:30:58 -0400 Message-ID: <009d01c6ee2c$91d6e830$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: AcbuKoORpEwLnP0vT5CzZUlKPAgPAgAAIqug In-Reply-To: <452E8662.2080504@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 - [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: 4d87d2aa806f79fed918a62e834505ca Cc: 'GEOPRIV WG' , "'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 No, you need a URI that is dependent on location. Your query is location in, URI out. DNS does not do that. LoST does. Roger's idea was rather than including an "additional information" URI in every LoST return, for every service, that we define a new service URN for "additional information". You then submit a LoST query with the urn:service:additional-location (or whatever) and your location, and the return is a URI for additional information corresponding to that location. Work this out. The assumption is that, for example, there is a local definition for what additional information is needed/wanted in NYC, and that included floor plans. When a query for, let's say, 1234 5th Street, New York, NY was made with urn:service:additional-information, the response would be a URI that could retrieve the data structure for 1234 5th Street, which contained the floor plan. Any (authorized) responder could get that data by querying LoST given the location. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Thursday, October 12, 2006 2:16 PM > To: Brian Rosen > Cc: 'GEOPRIV WG'; 'Ecrit@Ietf.Org' > Subject: Re: [Ecrit] RE: [Geopriv] coming to terms on location by > reference > > Brian Rosen wrote: > > Yeah, well, sorry. I should have made that observation myself. Thanks > to > > Roger for pointing out the obvious. > > > > In a NENA call today it was observed that, really, in at least a large > > enterprise environment, it would be best if it WAS in the PIDF. In the > > general case, it is hard to always assume the operator of the LIS has > the > > data, but in the case of the enterprise who runs a LIS, it does, and in > that > > case it is a whole lot easier to supply it in the PIDF than to get it > put in > > the LoST database. > > > > That may mean it makes sense to allow the (same) URI in the PIDF. I'm > not > > sure I like "both" as an answer here, but the cases are pretty > different. > > Perhaps my point was lost (no pun intended). If it is a URI you want, > then > using a URN to get it involves only DNS, not PIDF nor LoST. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 12 17:20:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY7yd-000401-NV; Thu, 12 Oct 2006 17:20:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY7yb-0003zd-Rp; Thu, 12 Oct 2006 17:20:25 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY7ya-0003Sc-In; Thu, 12 Oct 2006 17:20:25 -0400 Received: from lion.cs.columbia.edu (IDENT:5YUK4h08oXHM40moew8m3Tz2fiOg2FIK@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k9CLKD5Q019428 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 12 Oct 2006 17:20:14 -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 k9CLKDg7013810 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 12 Oct 2006 17:20:13 -0400 Message-ID: <452EB188.3020205@cs.columbia.edu> Date: Thu, 12 Oct 2006 17:20:08 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] RE: [Geopriv] coming to terms on location by reference References: <007a01c6ee22$afac9620$640fa8c0@cis.neustar.com> In-Reply-To: <007a01c6ee22$afac9620$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%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: 'GEOPRIV WG' , "'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 practical suggestion is to include the URL information in the civic-lo-revision document and then later add a code point to the DHCP-civic registry. I will note that having a single URL refer to possibly multiple semantically different objects seems to be somewhat at odds with HTTP conventions, where Accept is generally used to choose between renditions of the same logical document in different formats (such as an image in GIF or PNG). A floor plan and hazmat information, say, are not really the same logical document. Brian Rosen wrote: > Yeah, well, sorry. I should have made that observation myself. Thanks to > Roger for pointing out the obvious. > > In a NENA call today it was observed that, really, in at least a large > enterprise environment, it would be best if it WAS in the PIDF. In the > general case, it is hard to always assume the operator of the LIS has the > data, but in the case of the enterprise who runs a LIS, it does, and in that > case it is a whole lot easier to supply it in the PIDF than to get it put in > the LoST database. > > That may mean it makes sense to allow the (same) URI in the PIDF. I'm not > sure I like "both" as an answer here, but the cases are pretty different. > > Brian > >> -----Original Message----- >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Thursday, October 12, 2006 12:57 PM >> To: Brian Rosen >> Cc: 'GEOPRIV WG'; 'Ecrit@Ietf.Org' >> Subject: Re: [Ecrit] RE: [Geopriv] coming to terms on location by >> reference >> >> Brian Rosen wrote: >>> Define a new service URN that returns this data. >> Define a new service URN that returns the URI you want? Is that the idea? >> Fancy that, using URNs for their originally envisioned purpose. >> >> -andy > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 12 17:37:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY8Ep-0006Ux-LK; Thu, 12 Oct 2006 17:37:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY8Eo-0006UV-9G; Thu, 12 Oct 2006 17:37:10 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY8En-0006XW-1y; Thu, 12 Oct 2006 17:37:10 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GY8Ef-000087-DV; Thu, 12 Oct 2006 16:37:01 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] RE: [Geopriv] coming to terms on location by reference Date: Thu, 12 Oct 2006 17:37:03 -0400 Message-ID: <019901c6ee46$90d3f850$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: AcbuRDdShUQLg8zVSjK7/YMQcvs9TgAAgGDw In-Reply-To: <452EB188.3020205@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: 7d33c50f3756db14428398e2bdedd581 Cc: 'GEOPRIV WG' , "'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 practical suggestion is to include the URL information in the > civic-lo-revision document and then later add a code point to the > DHCP-civic registry. Good idea > > I will note that having a single URL refer to possibly multiple > semantically different objects seems to be somewhat at odds with HTTP > conventions, where Accept is generally used to choose between renditions > of the same logical document in different formats (such as an image in > GIF or PNG). A floor plan and hazmat information, say, are not really > the same logical document. I was thinking that the local authorities would define a single data structure that had tags for the different kinds if information they were interested in. Some of the tag values might be URLs themselves. The IETF is, of course, not the place to standardize that data structure, at least not now. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 12 17:43:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY8Km-0001HG-7F; Thu, 12 Oct 2006 17:43:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY8Kk-0001GF-Dk; Thu, 12 Oct 2006 17:43:18 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY8Ki-0008Dq-6j; Thu, 12 Oct 2006 17:43:18 -0400 Received: from lion.cs.columbia.edu (IDENT:rWSI9BE9UXtzdrvaK3GKqjBbyRk0AD4M@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k9CLhA5Q024558 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 12 Oct 2006 17:43:11 -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 k9CLh9g7015421 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 12 Oct 2006 17:43:10 -0400 Message-ID: <452EB6E8.6040406@cs.columbia.edu> Date: Thu, 12 Oct 2006 17:43:04 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] RE: [Geopriv] coming to terms on location by reference References: <019901c6ee46$90d3f850$640fa8c0@cis.neustar.com> In-Reply-To: <019901c6ee46$90d3f850$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%, X-Seen-By filter2.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: 'GEOPRIV WG' , "'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 IETF is, of course, not the place to standardize that data structure, at > least not now. Sure - but we need to have some idea what constraints we impose on future solutions. For example, the approach you suggest means that all information has to be managed by a single source, at least at the pointer level. I happen to think that this is not unreasonable, but since the number of types of information is probably fairly small (handful), it would also be quite plausible to remove one layer of indirection. > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 12 18:11:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY8lM-0007sn-5z; Thu, 12 Oct 2006 18:10:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY8lL-0007sO-8x for ecrit@ietf.org; Thu, 12 Oct 2006 18:10:47 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY8lJ-0006AM-Tg for ecrit@ietf.org; Thu, 12 Oct 2006 18:10:47 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1GY8lH-0003V9-3L; Thu, 12 Oct 2006 18:10:43 -0400 Message-ID: <452EBD60.2020100@bbn.com> Date: Thu, 12 Oct 2006 18:10:40 -0400 From: "Richard L. Barnes" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen References: <4520C835.4000208@gmx.net> In-Reply-To: <4520C835.4000208@gmx.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: ECRIT Subject: [Ecrit] Comments on ecrit-framework X-BeenThere: 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 response to Hannes' suggested review list, I took a look at the ecrit-framework draft. My comments are below. I'd be glad to help with revisions, especially to the security considerations; just let me know. --Richard Comments about Security Considerations: -- There should be an introductory paragraph setting out the general security context for ECRIT, roughly as it is laid out in 16.1: There are a variety of security services that can be employed, but any security policies need to be balanced against the need for all legitimate emergency calls to be completed. -- I'd like to suggest a restructuring of the Security Considerations section. There are two core concerns when it comes to security of emergency calling: Location information and call routing. It seems like we could split the security considerations into these two parts, and treat each along its lifecycle. -- Section 16.2 needs a more systematic list of points in the call flow where location data might be compromised, and a corresponding list of countermeasures. -- It's misleading for section 16.2 to reference RFC 3118, which only deals with authentication (not confidentiality). Perhaps there's a separate section here for "Location Integrity" to cover impersonation of location providers, etc.? -- Section 16.4 says that "sips:" forces TLS on each hop, which is false. Other substantive comments: -- Is this intended to be INFORMATIONAL or BCP? It seems like the former, but there are places where it makes recommendations. -- (Page 4) Is there a better example than GPS to differentiate between Acquisition and Determination? AGPS, perhaps, or LLDP-MED? -- (Page 5) I'm not clear on what the bullet about "separation/interleaving of signaling and media packets" means. Can you clarify? -- (Page 6) With respect to the following block: > To ensure that at least one common means of > communications, this document recommends certain minimal capabilities > in [I-D.rosen-sos-phonebcp] that call taker user agents and PSAP- > operated proxies should possess. Do you mean that this document makes recommendations, or that the phonebcp does? -- (Page 8) It seems like this section wanders a little; it should be more structured either by making more thorough use of the numbers in Figure 2 or by referencing the numbers in Figure 1. -- (Page 10) What's the point of messages [M5, M6] (or, equivalently, [M8-9])? It seems like if the UA already had a PSAP URI, it would just go directly there, rather than to the sos URN, and the secondary LoST lookup would be unnecessary. -- (Page 12) Should section 5.1 contain some mention about the usage of the transmitted location for directing first responders? -- (Page 13) In the paragraph starting "All location objects...": This first sentence seems at odds with the guidance of the previous paragraph (pointing to phonebcp). In the second sentence, it's not clear which "such policy decisions" you're referring to. Perhaps this whole paragraph should be struck in deference to the phonebcp? -- (Page 15) "It also requires all devices to be equipped with the appropriate GPS capability." This seemed a little non-sensical to me -- GPS requires devices to be equipped with GPS? How about: "Only devices equipped with the capability to receive GPS signals can use GPS to determine their location" -- (Page 15) Section 5.4: I would remove the hyphens from "by-value" and "by-reference", and the "as" before "by-value". Editorial comments: -- (Page 4) Missing closing paren after "National Emergency Number Association" -- (Page 5) Missing period after "... EV-DO as an uplink" -- (Page 5) Missing comma after "... 9-1-1 or 1-1-2" -- (Page 7) In the first paragraph of section 3, there's a lot of weird parens. -- (Page 8) Numbers in Figure 1 are never referenced -- (Page 8) Reference to Figure 2 should be to Figure 1. -- (Page 9) Missing period after "...may not pass through one" -- (Page 13) Delete "Handling multiple locations ... XRef??." This is already handled at the end of the paragraph. -- (Page 11) "... common emergency call URIs ..." should be "... common emergency call URNs ..." -- (Page 25), "emergency calls are to handled" should be "emergency calls are to be handled _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 12 19:07:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY9e5-00053Q-Qt; Thu, 12 Oct 2006 19:07:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY9d4-0004PW-E9; Thu, 12 Oct 2006 19:06:18 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY9Vp-0006IH-25; Thu, 12 Oct 2006 18:58:55 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GY9Vf-000603-C3; Thu, 12 Oct 2006 17:58:39 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] RE: [Geopriv] coming to terms on location by reference Date: Thu, 12 Oct 2006 18:58:37 -0400 Message-ID: <01c601c6ee51$f896ec80$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: AcbuR2kZRG+XVIc5SG+3lybb5jCvfwACYsSw In-Reply-To: <452EB6E8.6040406@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: 538aad3a3c4f01d8b6a6477ca4248793 Cc: 'GEOPRIV WG' , "'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 there are several dimensions. One is tenant/building owner; some information is available from the tenant, some from the building owner. I was thinking that the base data structure would be from the building owner. He would have things like building floor plans, construction, entrance, elevator, .... kinds of data. He would then have a pointer for each tenant, which would be a data structure provided by the tenant. The tenant would have things like interior floor plans, hazmat data. The thing is, of course, that nearly everything in the tenant part could apply to the building owner. I think there are a very large number of potential items in the data structure. I'm not sure how many of them are small enough to put directly in, vs needing an indirect mechanism. Clearly floor plans are indirect. Something like hazmat data may not be. Elevator status may not be, but remote elevator control probably is (and probably requires significantly more authentication and authorization if it is provided at all). The availability, location, etc of surveillance video could be directly in the structure, but you clearly would have an RTSP (or something like it) pointer to the actual video. There are probably hundreds of potential tags, and I don't know how many are pointers. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, October 12, 2006 5:43 PM > To: Brian Rosen > Cc: 'GEOPRIV WG'; 'Ecrit@Ietf.Org' > Subject: Re: [Ecrit] RE: [Geopriv] coming to terms on location by > reference > > > > > The IETF is, of course, not the place to standardize that data > structure, at > > least not now. > > Sure - but we need to have some idea what constraints we impose on > future solutions. For example, the approach you suggest means that all > information has to be managed by a single source, at least at the > pointer level. I happen to think that this is not unreasonable, but > since the number of types of information is probably fairly small > (handful), it would also be quite plausible to remove one layer of > indirection. > > > > > > Brian > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 12 19:38:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYA7f-0007mx-IA; Thu, 12 Oct 2006 19:37:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYA7d-0007md-FO; Thu, 12 Oct 2006 19:37:53 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYA7c-0007j4-3W; Thu, 12 Oct 2006 19:37:53 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 18:37:49 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 12 Oct 2006 18:37:48 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 18:37:48 -0500 Message-ID: From: "Thomson, Martin" To: "Brian Rosen" , "Henning Schulzrinne" Date: Thu, 12 Oct 2006 18:37:46 -0500 Subject: [Geopriv][Ecrit] Map data for a civic address MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 12 Oct 2006 23:37:48.0448 (UTC) FILETIME=[6CF94A00:01C6EE57] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <01c601c6ee51$f896ec80$640fa8c0@cis.neustar.com> Content-class: urn:content-classes:message Thread-Topic: [Geopriv][Ecrit] Map data for a civic address Thread-Index: AcbuR2kZRG+XVIc5SG+3lybb5jCvfwACYsSwAADKsQA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: GEOPRIV WG , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0598662334==" Errors-To: ecrit-bounces@ietf.org --===============0598662334== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message VGhpcyBhcHBlYXJzIHRvIGhhdmUgYnJhbmNoZWQgb2ZmIG9udG8gYSBuZXcgdG9waWMsIHNvIEkg aGF2ZSB0YWtlbiB0aGUgbGliZXJ0eSBvZiBjaGFuZ2luZyB0aGUgc3ViamVjdC4NCg0KSSB0aGlu ayB0aGF0IHdoYXQgeW91IGFyZSBkZXNjcmliaW5nIGlzIGEgZ29vZCBpZGVhIGZvciBhIG5ldyBz ZXJ2aWNlLCBidXQgSSBkb24ndCB0aGluayB0aGF0IGRlc2lnbmluZyBvbiB0aGUgZmx5IGlzIGdv aW5nIHRvIHdvcmsuICBJIGFsc28gZG9uJ3QgdGhpbmsgdGhhdCBpdCBpcyBuZWNlc3NhcnkgdG8g bHVtcCB0aGlzIGRhdGEgaW4gd2l0aCBhIGNpdmljIGFkZHJlc3MuDQoNCkknZCBjb250ZW5kIHRo YXQgd2hhdCB5b3UgYXJlIHByb3Bvc2luZyBpcyBpbmZvcm1hdGlvbiBfYWJvdXRfIHRoZSBjaXZp YyBhZGRyZXNzLCBub3QgYSBwYXJ0IG9mIHRoZSBhZGRyZXNzLg0KDQpUbyBwaWNrIG9uIG9uZSBh c3BlY3Qgb2YgeW91ciBkYXRhLCB3aGF0IGRpc3Rpbmd1aXNoZXMgYSBmbG9vciBwbGFuIHRoYXQg aGlnaGxpZ2h0cyB3aGVyZSBwYXJ0aWN1bGFyIHJvb21zIGFyZSB0byBhIHN0cmVldCBkaXJlY3Rv cnkgdGhhdCBoaWdobGlnaHRzIHdoZXJlIHJvYWRzIGFyZSwgb3IgYSB3b3JsZCBtYXAgdGhhdCBp bmNsdWRlcyBjb3VudHJ5IGJvcmRlcnM/ICBZZXMsIHlvdSBjYW4gYXJndWUgdGhhdCB0aGVyZSBp cyBhIGxldmVsIGJleW9uZCB3aGljaCB5b3UgY2FuIHN0YXJ0IG1ha2luZyBhc3N1bXB0aW9ucywg YnV0IHRoYXQgcmVxdWlyZXMgdGhhdCB5b3UgZHJhdyBhIGxpbmUuDQoNCkEgYmV0dGVyIGFwcHJv YWNoIHdvdWxkIGJlIHRvIGRlZmluZSBhIHNlcnZpY2UsIGp1c3QgYXMgUm9nZXIgc3VnZ2VzdGVk LiAgTG9jYXRpb24gKyB1cm46c2VydmljZTptYXAgKyBMb1NUID0gTWFwLiAgWW91IGNhbiBhZGQg dG8gdGhpcyBhcyBtdWNoIGNvbXBsZXhpdHkgYXMgeW91IGxpa2UgLSBkZWxlZ2F0aW9uIG9mIHJl c3BvbnNpYmlsaXR5IGZvciBmZWF0dXJlcywgaW5udW1lcmFibGUgdGFncywgc2NhbGFibGUgcmVz b2x1dGlvbiwgZXRjLi4uDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog QnJpYW4gUm9zZW4gW21haWx0bzpickBicmlhbnJvc2VuLm5ldF0NCj4gU2VudDogRnJpZGF5LCAx MyBPY3RvYmVyIDIwMDYgODo1OSBBTQ0KPiBUbzogJ0hlbm5pbmcgU2NodWx6cmlubmUnDQo+IENj OiAnR0VPUFJJViBXRyc7ICdFY3JpdEBJZXRmLk9yZycNCj4gU3ViamVjdDogUkU6IFtFY3JpdF0g UkU6IFtHZW9wcml2XSBjb21pbmcgdG8gdGVybXMgb24gbG9jYXRpb24gYnkNCj4gcmVmZXJlbmNl DQo+IA0KPiBJIHRoaW5rIHRoZXJlIGFyZSBzZXZlcmFsIGRpbWVuc2lvbnMuDQo+IA0KPiBPbmUg aXMgdGVuYW50L2J1aWxkaW5nIG93bmVyOyBzb21lIGluZm9ybWF0aW9uIGlzIGF2YWlsYWJsZSBm cm9tIHRoZQ0KPiB0ZW5hbnQsDQo+IHNvbWUgZnJvbSB0aGUgYnVpbGRpbmcgb3duZXIuICBJIHdh cyB0aGlua2luZyB0aGF0IHRoZSBiYXNlIGRhdGEgc3RydWN0dXJlDQo+IHdvdWxkIGJlIGZyb20g dGhlIGJ1aWxkaW5nIG93bmVyLiAgSGUgd291bGQgaGF2ZSB0aGluZ3MgbGlrZSBidWlsZGluZw0K PiBmbG9vcg0KPiBwbGFucywgY29uc3RydWN0aW9uLCBlbnRyYW5jZSwgZWxldmF0b3IsIC4uLi4g a2luZHMgb2YgZGF0YS4NCj4gDQo+IEhlIHdvdWxkIHRoZW4gaGF2ZSBhIHBvaW50ZXIgZm9yIGVh Y2ggdGVuYW50LCB3aGljaCB3b3VsZCBiZSBhIGRhdGENCj4gc3RydWN0dXJlIHByb3ZpZGVkIGJ5 IHRoZSB0ZW5hbnQuICBUaGUgdGVuYW50IHdvdWxkIGhhdmUgdGhpbmdzIGxpa2UNCj4gaW50ZXJp b3IgZmxvb3IgcGxhbnMsIGhhem1hdCBkYXRhLg0KPiANCj4gVGhlIHRoaW5nIGlzLCBvZiBjb3Vy c2UsIHRoYXQgbmVhcmx5IGV2ZXJ5dGhpbmcgaW4gdGhlIHRlbmFudCBwYXJ0IGNvdWxkDQo+IGFw cGx5IHRvIHRoZSBidWlsZGluZyBvd25lci4NCj4gDQo+IEkgdGhpbmsgdGhlcmUgYXJlIGEgdmVy eSBsYXJnZSBudW1iZXIgb2YgcG90ZW50aWFsIGl0ZW1zIGluIHRoZSBkYXRhDQo+IHN0cnVjdHVy ZS4gIEknbSBub3Qgc3VyZSBob3cgbWFueSBvZiB0aGVtIGFyZSBzbWFsbCBlbm91Z2ggdG8gcHV0 IGRpcmVjdGx5DQo+IGluLCB2cyBuZWVkaW5nIGFuIGluZGlyZWN0IG1lY2hhbmlzbS4gIENsZWFy bHkgZmxvb3IgcGxhbnMgYXJlIGluZGlyZWN0Lg0KPiBTb21ldGhpbmcgbGlrZSBoYXptYXQgZGF0 YSBtYXkgbm90IGJlLiAgRWxldmF0b3Igc3RhdHVzIG1heSBub3QgYmUsIGJ1dA0KPiByZW1vdGUg ZWxldmF0b3IgY29udHJvbCBwcm9iYWJseSBpcyAoYW5kIHByb2JhYmx5IHJlcXVpcmVzIHNpZ25p ZmljYW50bHkNCj4gbW9yZSBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBpZiBpdCBp cyBwcm92aWRlZCBhdCBhbGwpLiAgVGhlDQo+IGF2YWlsYWJpbGl0eSwgbG9jYXRpb24sIGV0YyBv ZiBzdXJ2ZWlsbGFuY2UgdmlkZW8gY291bGQgYmUgZGlyZWN0bHkgaW4gdGhlDQo+IHN0cnVjdHVy ZSwgYnV0IHlvdSBjbGVhcmx5IHdvdWxkIGhhdmUgYW4gUlRTUCAob3Igc29tZXRoaW5nIGxpa2Ug aXQpDQo+IHBvaW50ZXINCj4gdG8gdGhlIGFjdHVhbCB2aWRlby4gIFRoZXJlIGFyZSBwcm9iYWJs eSBodW5kcmVkcyBvZiBwb3RlbnRpYWwgdGFncywgYW5kIEkNCj4gZG9uJ3Qga25vdyBob3cgbWFu eSBhcmUgcG9pbnRlcnMuDQo+IA0KPiBCcmlhbg0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+IEZyb206IEhlbm5pbmcgU2NodWx6cmlubmUgW21haWx0bzpoZ3NAY3MuY29s dW1iaWEuZWR1XQ0KPiA+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDEyLCAyMDA2IDU6NDMgUE0N Cj4gPiBUbzogQnJpYW4gUm9zZW4NCj4gPiBDYzogJ0dFT1BSSVYgV0cnOyAnRWNyaXRASWV0Zi5P cmcnDQo+ID4gU3ViamVjdDogUmU6IFtFY3JpdF0gUkU6IFtHZW9wcml2XSBjb21pbmcgdG8gdGVy bXMgb24gbG9jYXRpb24gYnkNCj4gPiByZWZlcmVuY2UNCj4gPg0KPiA+ID4NCj4gPiA+IFRoZSBJ RVRGIGlzLCBvZiBjb3Vyc2UsIG5vdCB0aGUgcGxhY2UgdG8gc3RhbmRhcmRpemUgdGhhdCBkYXRh DQo+ID4gc3RydWN0dXJlLCBhdA0KPiA+ID4gbGVhc3Qgbm90IG5vdy4NCj4gPg0KPiA+IFN1cmUg LSBidXQgd2UgbmVlZCB0byBoYXZlIHNvbWUgaWRlYSB3aGF0IGNvbnN0cmFpbnRzIHdlIGltcG9z ZSBvbg0KPiA+IGZ1dHVyZSBzb2x1dGlvbnMuIEZvciBleGFtcGxlLCB0aGUgYXBwcm9hY2ggeW91 IHN1Z2dlc3QgbWVhbnMgdGhhdCBhbGwNCj4gPiBpbmZvcm1hdGlvbiBoYXMgdG8gYmUgbWFuYWdl ZCBieSBhIHNpbmdsZSBzb3VyY2UsIGF0IGxlYXN0IGF0IHRoZQ0KPiA+IHBvaW50ZXIgbGV2ZWwu IEkgaGFwcGVuIHRvIHRoaW5rIHRoYXQgdGhpcyBpcyBub3QgdW5yZWFzb25hYmxlLCBidXQNCj4g PiBzaW5jZSB0aGUgbnVtYmVyIG9mIHR5cGVzIG9mIGluZm9ybWF0aW9uIGlzIHByb2JhYmx5IGZh aXJseSBzbWFsbA0KPiA+IChoYW5kZnVsKSwgaXQgd291bGQgYWxzbyBiZSBxdWl0ZSBwbGF1c2li bGUgdG8gcmVtb3ZlIG9uZSBsYXllciBvZg0KPiA+IGluZGlyZWN0aW9uLg0KPiA+DQo+ID4NCj4g PiA+DQo+ID4gPiBCcmlhbg0KPiA+ID4NCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBHZW9wcml2IG1haWxpbmcgbGlzdA0KPiBHZW9w cml2QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dl b3ByaXYNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1l c3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRh aW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0 aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1 dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJd --===============0598662334== 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 --===============0598662334==-- From ecrit-bounces@ietf.org Thu Oct 12 20:01:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYATq-00050D-8p; Thu, 12 Oct 2006 20:00:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYATp-000505-6M; Thu, 12 Oct 2006 20:00:49 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYATn-0004XK-Ni; Thu, 12 Oct 2006 20:00:49 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GYATc-00017D-Iy; Thu, 12 Oct 2006 19:00:37 -0500 From: "Brian Rosen" To: "'Thomson, Martin'" , "'Henning Schulzrinne'" Subject: RE: [Geopriv][Ecrit] Map data for a civic address Date: Thu, 12 Oct 2006 20:00:40 -0400 Message-ID: <01d401c6ee5a$a09403c0$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: AcbuR2kZRG+XVIc5SG+3lybb5jCvfwACYsSwAADKsQAAAU8x4A== 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: 29dc808194f5fb921c09d0040806d6eb Cc: 'GEOPRIV WG' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Agree we aren't going to design it on the fly. I don't think WE are going to design it. At the moment, I really think that is a local matter, and it works as a local matter without any loss of interoperability. It is clearly information ABOUT the address. It's not limited to civic address. I don't think we need to draw lines. While I can't think of a good reason to, if you put in a civic location with just a city name, you might get back a street map. Again, a local matter, it seems to me. One of the reasons why there is some sense to allowing the pointer in the PIDF itself (and it DOES make sense to have a pointer for "additional information about the location in this PIDF") is that, at least in large enterprise, it can give you the right answer, because it comes from the right entity (it is, after all, the enterprise that runs the LIS in this case). A more general case of a broadband carrier serving a high rise apartment building doesn't work, but then the notion of it being in LoST makes sense there. Right now, without a lot to go on, I'm thinking I don't want to standardize a whole bunch of service URNs, one per piece of data and query for them individually. I think I want one locally defined XML structure and a "gimme all you got" query. YMMV. Later, when we have more experience in how this works, and how else we can use it, we could think about creating some more services such as map. Brian > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Thursday, October 12, 2006 7:38 PM > To: Brian Rosen; Henning Schulzrinne > Cc: GEOPRIV WG; ECRIT > Subject: [Geopriv][Ecrit] Map data for a civic address > > This appears to have branched off onto a new topic, so I have taken the > liberty of changing the subject. > > I think that what you are describing is a good idea for a new service, but > I don't think that designing on the fly is going to work. I also don't > think that it is necessary to lump this data in with a civic address. > > I'd contend that what you are proposing is information _about_ the civic > address, not a part of the address. > > To pick on one aspect of your data, what distinguishes a floor plan that > highlights where particular rooms are to a street directory that > highlights where roads are, or a world map that includes country borders? > Yes, you can argue that there is a level beyond which you can start making > assumptions, but that requires that you draw a line. > > A better approach would be to define a service, just as Roger suggested. > Location + urn:service:map + LoST = Map. You can add to this as much > complexity as you like - delegation of responsibility for features, > innumerable tags, scalable resolution, etc... > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, 13 October 2006 8:59 AM > > To: 'Henning Schulzrinne' > > Cc: 'GEOPRIV WG'; 'Ecrit@Ietf.Org' > > Subject: RE: [Ecrit] RE: [Geopriv] coming to terms on location by > > reference > > > > I think there are several dimensions. > > > > One is tenant/building owner; some information is available from the > > tenant, > > some from the building owner. I was thinking that the base data > structure > > would be from the building owner. He would have things like building > > floor > > plans, construction, entrance, elevator, .... kinds of data. > > > > He would then have a pointer for each tenant, which would be a data > > structure provided by the tenant. The tenant would have things like > > interior floor plans, hazmat data. > > > > The thing is, of course, that nearly everything in the tenant part could > > apply to the building owner. > > > > I think there are a very large number of potential items in the data > > structure. I'm not sure how many of them are small enough to put > directly > > in, vs needing an indirect mechanism. Clearly floor plans are indirect. > > Something like hazmat data may not be. Elevator status may not be, but > > remote elevator control probably is (and probably requires significantly > > more authentication and authorization if it is provided at all). The > > availability, location, etc of surveillance video could be directly in > the > > structure, but you clearly would have an RTSP (or something like it) > > pointer > > to the actual video. There are probably hundreds of potential tags, and > I > > don't know how many are pointers. > > > > Brian > > > > > -----Original Message----- > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > Sent: Thursday, October 12, 2006 5:43 PM > > > To: Brian Rosen > > > Cc: 'GEOPRIV WG'; 'Ecrit@Ietf.Org' > > > Subject: Re: [Ecrit] RE: [Geopriv] coming to terms on location by > > > reference > > > > > > > > > > > The IETF is, of course, not the place to standardize that data > > > structure, at > > > > least not now. > > > > > > Sure - but we need to have some idea what constraints we impose on > > > future solutions. For example, the approach you suggest means that all > > > information has to be managed by a single source, at least at the > > > pointer level. I happen to think that this is not unreasonable, but > > > since the number of types of information is probably fairly small > > > (handful), it would also be quite plausible to remove one layer of > > > indirection. > > > > > > > > > > > > > > Brian > > > > > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 12 20:14:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYAgM-0004i9-8O; Thu, 12 Oct 2006 20:13:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYAgL-0004i1-Du; Thu, 12 Oct 2006 20:13:45 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYAgJ-0007Gy-5c; Thu, 12 Oct 2006 20:13:45 -0400 Received: from [192.168.0.41] (pool-141-153-175-20.mad.east.verizon.net [141.153.175.20]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k9D0DWs8001214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 12 Oct 2006 20:13:37 -0400 (EDT) In-Reply-To: <01d401c6ee5a$a09403c0$640fa8c0@cis.neustar.com> References: <01d401c6ee5a$a09403c0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv][Ecrit] Map data for a civic address Date: Thu, 12 Oct 2006 20:13:26 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The only real difference between a PIDF inclusion and a LoST lookup in this case seems to be one layer of indirection, with the attendant advantages and disadvantages. One of the practical issues is that LoST is currently designed for public information; any layer of indirection has to deal with well- discussed problems of having the LoST server decide who gets access to the information. And now we can replay our by-value or by-reference discussion, since we haven't had one in a day or two. Btw, PIDF-LO already contains information _about_ the address, such as the placetype or, if you like, the business name. Henning On Oct 12, 2006, at 8:00 PM, Brian Rosen wrote: > Agree we aren't going to design it on the fly. > > I don't think WE are going to design it. > > At the moment, I really think that is a local matter, and it works > as a > local matter without any loss of interoperability. > > It is clearly information ABOUT the address. > > It's not limited to civic address. > > I don't think we need to draw lines. While I can't think of a good > reason > to, if you put in a civic location with just a city name, you might > get back > a street map. Again, a local matter, it seems to me. > > One of the reasons why there is some sense to allowing the pointer > in the > PIDF itself (and it DOES make sense to have a pointer for "additional > information about the location in this PIDF") is that, at least in > large > enterprise, it can give you the right answer, because it comes from > the > right entity (it is, after all, the enterprise that runs the LIS in > this > case). A more general case of a broadband carrier serving a high rise > apartment building doesn't work, but then the notion of it being in > LoST > makes sense there. > > Right now, without a lot to go on, I'm thinking I don't want to > standardize > a whole bunch of service URNs, one per piece of data and query for > them > individually. I think I want one locally defined XML structure and > a "gimme > all you got" query. YMMV. > > Later, when we have more experience in how this works, and how else > we can > use it, we could think about creating some more services such as map. > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 12 20:15:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYAhq-0005Er-Hi; Thu, 12 Oct 2006 20:15:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYAhp-0005CP-8l; Thu, 12 Oct 2006 20:15:17 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYAho-0007iM-QL; Thu, 12 Oct 2006 20:15:17 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 19:15:16 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 12 Oct 2006 19:15:15 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 19:15:14 -0500 Message-ID: From: "Thomson, Martin" To: "Brian Rosen" , "Henning Schulzrinne" Date: Thu, 12 Oct 2006 19:15:11 -0500 Subject: RE: [Geopriv][Ecrit] Map data for a civic address MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 13 Oct 2006 00:15:14.0959 (UTC) FILETIME=[A7FFA9F0:01C6EE5C] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <01d401c6ee5a$a09403c0$640fa8c0@cis.neustar.com> Content-class: urn:content-classes:message Thread-Topic: [Geopriv][Ecrit] Map data for a civic address Thread-Index: AcbuR2kZRG+XVIc5SG+3lybb5jCvfwACYsSwAADKsQAAAU8x4AAAe/nA X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: GEOPRIV WG , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0713684564==" Errors-To: ecrit-bounces@ietf.org --===============0713684564== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message WW91IG5lZWQgdG8gYmUgY2FyZWZ1bCB0aGF0IHlvdSBhcmVuJ3QgbWlzdGFraW5nIGEgImNhbiIg Zm9yIGEgInNob3VsZCIuDQoNCkluIGFueSBjYXNlLCBhc3N1bWluZyB0aGF0IHRoZSBMSVMgcHJv dmlkZXMgdGhpcyBpbmZvcm1hdGlvbjsgd2hlcmUgZG9lcyB0aGlzIGJlbG9uZz8gIEkgY2FuIHNl ZSBmb3VyIG9wdGlvbnM6DQoNCiAtIEluIHRoZSBjaXZpYyBhZGRyZXNzOiBJJ3ZlIGFscmVhZHkg Z2l2ZW4gbXkgcmVhc29ucyB3aHkgSSBiZWxpZXZlIHRoaXMgaXMgYSBiYWQgaWRlYS4NCg0KIC0g SW4gdGhlIEdlb3ByaXYgZWxlbWVudCAoYWxvbmdzaWRlIDxtZXRob2Q+LCA8dXNhZ2UtcnVsZXM+ IGFuZCBzbyBmb3J0aCkuDQoNCiAtIEluIHRoZSBQSURGOiBJIHdvbmRlciBpZiB0aGlzIGNvdWxk IHJlYWxseSBiZSBjb25zaWRlcmVkIHByZXNlbmNlIGluZm9ybWF0aW9uLg0KDQogLSBJbiB0aGUg YWNxdWlzaXRpb24gcHJvdG9jb2w6IEFkZCBhbiBvcHRpb24gaW4gdGhlIHByb3RvY29sIHRvIHJl cXVlc3QgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhbmQgaW5jbHVkZSB0aGUgZGF0YSBhcyBhbiBh ZGp1bmN0Lg0KDQpQZXJzb25hbGx5LCBJIGxpa2UgdGhlIGxhc3Qgb25lLg0KDQpDaGVlcnMsDQpN YXJ0aW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBSb3Nl biBbbWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0XQ0KPiBTZW50OiBGcmlkYXksIDEzIE9jdG9iZXIg MjAwNiAxMDowMSBBTQ0KPiBUbzogVGhvbXNvbiwgTWFydGluOyAnSGVubmluZyBTY2h1bHpyaW5u ZScNCj4gQ2M6ICdHRU9QUklWIFdHJzsgJ0VDUklUJw0KPiBTdWJqZWN0OiBSRTogW0dlb3ByaXZd W0Vjcml0XSBNYXAgZGF0YSBmb3IgYSBjaXZpYyBhZGRyZXNzDQo+IA0KPiBBZ3JlZSB3ZSBhcmVu J3QgZ29pbmcgdG8gZGVzaWduIGl0IG9uIHRoZSBmbHkuDQo+IA0KPiBJIGRvbid0IHRoaW5rIFdF IGFyZSBnb2luZyB0byBkZXNpZ24gaXQuDQo+IA0KPiBBdCB0aGUgbW9tZW50LCBJIHJlYWxseSB0 aGluayB0aGF0IGlzIGEgbG9jYWwgbWF0dGVyLCBhbmQgaXQgd29ya3MgYXMgYQ0KPiBsb2NhbCBt YXR0ZXIgd2l0aG91dCBhbnkgbG9zcyBvZiBpbnRlcm9wZXJhYmlsaXR5Lg0KPiANCj4gSXQgaXMg Y2xlYXJseSBpbmZvcm1hdGlvbiBBQk9VVCB0aGUgYWRkcmVzcy4NCj4gDQo+IEl0J3Mgbm90IGxp bWl0ZWQgdG8gY2l2aWMgYWRkcmVzcy4NCj4gDQo+IEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byBk cmF3IGxpbmVzLiAgV2hpbGUgSSBjYW4ndCB0aGluayBvZiBhIGdvb2QgcmVhc29uDQo+IHRvLCBp ZiB5b3UgcHV0IGluIGEgY2l2aWMgbG9jYXRpb24gd2l0aCBqdXN0IGEgY2l0eSBuYW1lLCB5b3Ug bWlnaHQgZ2V0DQo+IGJhY2sNCj4gYSBzdHJlZXQgbWFwLiAgQWdhaW4sIGEgbG9jYWwgbWF0dGVy LCBpdCBzZWVtcyB0byBtZS4NCj4gDQo+IE9uZSBvZiB0aGUgcmVhc29ucyB3aHkgdGhlcmUgaXMg c29tZSBzZW5zZSB0byBhbGxvd2luZyB0aGUgcG9pbnRlciBpbiB0aGUNCj4gUElERiBpdHNlbGYg KGFuZCBpdCBET0VTIG1ha2Ugc2Vuc2UgdG8gaGF2ZSBhIHBvaW50ZXIgZm9yICJhZGRpdGlvbmFs DQo+IGluZm9ybWF0aW9uIGFib3V0IHRoZSBsb2NhdGlvbiBpbiB0aGlzIFBJREYiKSBpcyB0aGF0 LCBhdCBsZWFzdCBpbiBsYXJnZQ0KPiBlbnRlcnByaXNlLCBpdCBjYW4gZ2l2ZSB5b3UgdGhlIHJp Z2h0IGFuc3dlciwgYmVjYXVzZSBpdCBjb21lcyBmcm9tIHRoZQ0KPiByaWdodCBlbnRpdHkgKGl0 IGlzLCBhZnRlciBhbGwsIHRoZSBlbnRlcnByaXNlIHRoYXQgcnVucyB0aGUgTElTIGluIHRoaXMN Cj4gY2FzZSkuICBBIG1vcmUgZ2VuZXJhbCBjYXNlIG9mIGEgYnJvYWRiYW5kIGNhcnJpZXIgc2Vy dmluZyBhIGhpZ2ggcmlzZQ0KPiBhcGFydG1lbnQgYnVpbGRpbmcgZG9lc24ndCB3b3JrLCBidXQg dGhlbiB0aGUgbm90aW9uIG9mIGl0IGJlaW5nIGluIExvU1QNCj4gbWFrZXMgc2Vuc2UgdGhlcmUu DQo+IA0KPiBSaWdodCBub3csIHdpdGhvdXQgYSBsb3QgdG8gZ28gb24sIEknbSB0aGlua2luZyBJ IGRvbid0IHdhbnQgdG8NCj4gc3RhbmRhcmRpemUNCj4gYSB3aG9sZSBidW5jaCBvZiBzZXJ2aWNl IFVSTnMsIG9uZSBwZXIgcGllY2Ugb2YgZGF0YSBhbmQgcXVlcnkgZm9yIHRoZW0NCj4gaW5kaXZp ZHVhbGx5LiAgSSB0aGluayBJIHdhbnQgb25lIGxvY2FsbHkgZGVmaW5lZCBYTUwgc3RydWN0dXJl IGFuZCBhDQo+ICJnaW1tZQ0KPiBhbGwgeW91IGdvdCIgcXVlcnkuICBZTU1WLg0KPiANCj4gTGF0 ZXIsIHdoZW4gd2UgaGF2ZSBtb3JlIGV4cGVyaWVuY2UgaW4gaG93IHRoaXMgd29ya3MsIGFuZCBo b3cgZWxzZSB3ZSBjYW4NCj4gdXNlIGl0LCB3ZSBjb3VsZCB0aGluayBhYm91dCBjcmVhdGluZyBz b21lIG1vcmUgc2VydmljZXMgc3VjaCBhcyBtYXAuDQo+IA0KPiBCcmlhbg0KPiANCj4gDQo+IA0K PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogVGhvbXNvbiwgTWFydGlu IFttYWlsdG86TWFydGluLlRob21zb25AYW5kcmV3LmNvbV0NCj4gPiBTZW50OiBUaHVyc2RheSwg T2N0b2JlciAxMiwgMjAwNiA3OjM4IFBNDQo+ID4gVG86IEJyaWFuIFJvc2VuOyBIZW5uaW5nIFNj aHVsenJpbm5lDQo+ID4gQ2M6IEdFT1BSSVYgV0c7IEVDUklUDQo+ID4gU3ViamVjdDogW0dlb3By aXZdW0Vjcml0XSBNYXAgZGF0YSBmb3IgYSBjaXZpYyBhZGRyZXNzDQo+ID4NCj4gPiBUaGlzIGFw cGVhcnMgdG8gaGF2ZSBicmFuY2hlZCBvZmYgb250byBhIG5ldyB0b3BpYywgc28gSSBoYXZlIHRh a2VuIHRoZQ0KPiA+IGxpYmVydHkgb2YgY2hhbmdpbmcgdGhlIHN1YmplY3QuDQo+ID4NCj4gPiBJ IHRoaW5rIHRoYXQgd2hhdCB5b3UgYXJlIGRlc2NyaWJpbmcgaXMgYSBnb29kIGlkZWEgZm9yIGEg bmV3IHNlcnZpY2UsDQo+IGJ1dA0KPiA+IEkgZG9uJ3QgdGhpbmsgdGhhdCBkZXNpZ25pbmcgb24g dGhlIGZseSBpcyBnb2luZyB0byB3b3JrLiAgSSBhbHNvIGRvbid0DQo+ID4gdGhpbmsgdGhhdCBp dCBpcyBuZWNlc3NhcnkgdG8gbHVtcCB0aGlzIGRhdGEgaW4gd2l0aCBhIGNpdmljIGFkZHJlc3Mu DQo+ID4NCj4gPiBJJ2QgY29udGVuZCB0aGF0IHdoYXQgeW91IGFyZSBwcm9wb3NpbmcgaXMgaW5m b3JtYXRpb24gX2Fib3V0XyB0aGUgY2l2aWMNCj4gPiBhZGRyZXNzLCBub3QgYSBwYXJ0IG9mIHRo ZSBhZGRyZXNzLg0KPiA+DQo+ID4gVG8gcGljayBvbiBvbmUgYXNwZWN0IG9mIHlvdXIgZGF0YSwg d2hhdCBkaXN0aW5ndWlzaGVzIGEgZmxvb3IgcGxhbiB0aGF0DQo+ID4gaGlnaGxpZ2h0cyB3aGVy ZSBwYXJ0aWN1bGFyIHJvb21zIGFyZSB0byBhIHN0cmVldCBkaXJlY3RvcnkgdGhhdA0KPiA+IGhp Z2hsaWdodHMgd2hlcmUgcm9hZHMgYXJlLCBvciBhIHdvcmxkIG1hcCB0aGF0IGluY2x1ZGVzIGNv dW50cnkNCj4gYm9yZGVycz8NCj4gPiBZZXMsIHlvdSBjYW4gYXJndWUgdGhhdCB0aGVyZSBpcyBh IGxldmVsIGJleW9uZCB3aGljaCB5b3UgY2FuIHN0YXJ0DQo+IG1ha2luZw0KPiA+IGFzc3VtcHRp b25zLCBidXQgdGhhdCByZXF1aXJlcyB0aGF0IHlvdSBkcmF3IGEgbGluZS4NCj4gPg0KPiA+IEEg YmV0dGVyIGFwcHJvYWNoIHdvdWxkIGJlIHRvIGRlZmluZSBhIHNlcnZpY2UsIGp1c3QgYXMgUm9n ZXIgc3VnZ2VzdGVkLg0KPiA+IExvY2F0aW9uICsgdXJuOnNlcnZpY2U6bWFwICsgTG9TVCA9IE1h cC4gIFlvdSBjYW4gYWRkIHRvIHRoaXMgYXMgbXVjaA0KPiA+IGNvbXBsZXhpdHkgYXMgeW91IGxp a2UgLSBkZWxlZ2F0aW9uIG9mIHJlc3BvbnNpYmlsaXR5IGZvciBmZWF0dXJlcywNCj4gPiBpbm51 bWVyYWJsZSB0YWdzLCBzY2FsYWJsZSByZXNvbHV0aW9uLCBldGMuLi4NCj4gPg0KPiA+ID4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IEJyaWFuIFJvc2VuIFttYWlsdG86 YnJAYnJpYW5yb3Nlbi5uZXRdDQo+ID4gPiBTZW50OiBGcmlkYXksIDEzIE9jdG9iZXIgMjAwNiA4 OjU5IEFNDQo+ID4gPiBUbzogJ0hlbm5pbmcgU2NodWx6cmlubmUnDQo+ID4gPiBDYzogJ0dFT1BS SVYgV0cnOyAnRWNyaXRASWV0Zi5PcmcnDQo+ID4gPiBTdWJqZWN0OiBSRTogW0Vjcml0XSBSRTog W0dlb3ByaXZdIGNvbWluZyB0byB0ZXJtcyBvbiBsb2NhdGlvbiBieQ0KPiA+ID4gcmVmZXJlbmNl DQo+ID4gPg0KPiA+ID4gSSB0aGluayB0aGVyZSBhcmUgc2V2ZXJhbCBkaW1lbnNpb25zLg0KPiA+ ID4NCj4gPiA+IE9uZSBpcyB0ZW5hbnQvYnVpbGRpbmcgb3duZXI7IHNvbWUgaW5mb3JtYXRpb24g aXMgYXZhaWxhYmxlIGZyb20gdGhlDQo+ID4gPiB0ZW5hbnQsDQo+ID4gPiBzb21lIGZyb20gdGhl IGJ1aWxkaW5nIG93bmVyLiAgSSB3YXMgdGhpbmtpbmcgdGhhdCB0aGUgYmFzZSBkYXRhDQo+ID4g c3RydWN0dXJlDQo+ID4gPiB3b3VsZCBiZSBmcm9tIHRoZSBidWlsZGluZyBvd25lci4gIEhlIHdv dWxkIGhhdmUgdGhpbmdzIGxpa2UgYnVpbGRpbmcNCj4gPiA+IGZsb29yDQo+ID4gPiBwbGFucywg Y29uc3RydWN0aW9uLCBlbnRyYW5jZSwgZWxldmF0b3IsIC4uLi4ga2luZHMgb2YgZGF0YS4NCj4g PiA+DQo+ID4gPiBIZSB3b3VsZCB0aGVuIGhhdmUgYSBwb2ludGVyIGZvciBlYWNoIHRlbmFudCwg d2hpY2ggd291bGQgYmUgYSBkYXRhDQo+ID4gPiBzdHJ1Y3R1cmUgcHJvdmlkZWQgYnkgdGhlIHRl bmFudC4gIFRoZSB0ZW5hbnQgd291bGQgaGF2ZSB0aGluZ3MgbGlrZQ0KPiA+ID4gaW50ZXJpb3Ig Zmxvb3IgcGxhbnMsIGhhem1hdCBkYXRhLg0KPiA+ID4NCj4gPiA+IFRoZSB0aGluZyBpcywgb2Yg Y291cnNlLCB0aGF0IG5lYXJseSBldmVyeXRoaW5nIGluIHRoZSB0ZW5hbnQgcGFydA0KPiBjb3Vs ZA0KPiA+ID4gYXBwbHkgdG8gdGhlIGJ1aWxkaW5nIG93bmVyLg0KPiA+ID4NCj4gPiA+IEkgdGhp bmsgdGhlcmUgYXJlIGEgdmVyeSBsYXJnZSBudW1iZXIgb2YgcG90ZW50aWFsIGl0ZW1zIGluIHRo ZSBkYXRhDQo+ID4gPiBzdHJ1Y3R1cmUuICBJJ20gbm90IHN1cmUgaG93IG1hbnkgb2YgdGhlbSBh cmUgc21hbGwgZW5vdWdoIHRvIHB1dA0KPiA+IGRpcmVjdGx5DQo+ID4gPiBpbiwgdnMgbmVlZGlu ZyBhbiBpbmRpcmVjdCBtZWNoYW5pc20uICBDbGVhcmx5IGZsb29yIHBsYW5zIGFyZQ0KPiBpbmRp cmVjdC4NCj4gPiA+IFNvbWV0aGluZyBsaWtlIGhhem1hdCBkYXRhIG1heSBub3QgYmUuICBFbGV2 YXRvciBzdGF0dXMgbWF5IG5vdCBiZSwNCj4gYnV0DQo+ID4gPiByZW1vdGUgZWxldmF0b3IgY29u dHJvbCBwcm9iYWJseSBpcyAoYW5kIHByb2JhYmx5IHJlcXVpcmVzDQo+IHNpZ25pZmljYW50bHkN Cj4gPiA+IG1vcmUgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gaWYgaXQgaXMgcHJv dmlkZWQgYXQgYWxsKS4gIFRoZQ0KPiA+ID4gYXZhaWxhYmlsaXR5LCBsb2NhdGlvbiwgZXRjIG9m IHN1cnZlaWxsYW5jZSB2aWRlbyBjb3VsZCBiZSBkaXJlY3RseSBpbg0KPiA+IHRoZQ0KPiA+ID4g c3RydWN0dXJlLCBidXQgeW91IGNsZWFybHkgd291bGQgaGF2ZSBhbiBSVFNQIChvciBzb21ldGhp bmcgbGlrZSBpdCkNCj4gPiA+IHBvaW50ZXINCj4gPiA+IHRvIHRoZSBhY3R1YWwgdmlkZW8uICBU aGVyZSBhcmUgcHJvYmFibHkgaHVuZHJlZHMgb2YgcG90ZW50aWFsIHRhZ3MsDQo+IGFuZA0KPiA+ IEkNCj4gPiA+IGRvbid0IGtub3cgaG93IG1hbnkgYXJlIHBvaW50ZXJzLg0KPiA+ID4NCj4gPiA+ IEJyaWFuDQo+ID4gPg0KPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4g PiBGcm9tOiBIZW5uaW5nIFNjaHVsenJpbm5lIFttYWlsdG86aGdzQGNzLmNvbHVtYmlhLmVkdV0N Cj4gPiA+ID4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTIsIDIwMDYgNTo0MyBQTQ0KPiA+ID4g PiBUbzogQnJpYW4gUm9zZW4NCj4gPiA+ID4gQ2M6ICdHRU9QUklWIFdHJzsgJ0Vjcml0QElldGYu T3JnJw0KPiA+ID4gPiBTdWJqZWN0OiBSZTogW0Vjcml0XSBSRTogW0dlb3ByaXZdIGNvbWluZyB0 byB0ZXJtcyBvbiBsb2NhdGlvbiBieQ0KPiA+ID4gPiByZWZlcmVuY2UNCj4gPiA+ID4NCj4gPiA+ ID4gPg0KPiA+ID4gPiA+IFRoZSBJRVRGIGlzLCBvZiBjb3Vyc2UsIG5vdCB0aGUgcGxhY2UgdG8g c3RhbmRhcmRpemUgdGhhdCBkYXRhDQo+ID4gPiA+IHN0cnVjdHVyZSwgYXQNCj4gPiA+ID4gPiBs ZWFzdCBub3Qgbm93Lg0KPiA+ID4gPg0KPiA+ID4gPiBTdXJlIC0gYnV0IHdlIG5lZWQgdG8gaGF2 ZSBzb21lIGlkZWEgd2hhdCBjb25zdHJhaW50cyB3ZSBpbXBvc2Ugb24NCj4gPiA+ID4gZnV0dXJl IHNvbHV0aW9ucy4gRm9yIGV4YW1wbGUsIHRoZSBhcHByb2FjaCB5b3Ugc3VnZ2VzdCBtZWFucyB0 aGF0DQo+IGFsbA0KPiA+ID4gPiBpbmZvcm1hdGlvbiBoYXMgdG8gYmUgbWFuYWdlZCBieSBhIHNp bmdsZSBzb3VyY2UsIGF0IGxlYXN0IGF0IHRoZQ0KPiA+ID4gPiBwb2ludGVyIGxldmVsLiBJIGhh cHBlbiB0byB0aGluayB0aGF0IHRoaXMgaXMgbm90IHVucmVhc29uYWJsZSwgYnV0DQo+ID4gPiA+ IHNpbmNlIHRoZSBudW1iZXIgb2YgdHlwZXMgb2YgaW5mb3JtYXRpb24gaXMgcHJvYmFibHkgZmFp cmx5IHNtYWxsDQo+ID4gPiA+IChoYW5kZnVsKSwgaXQgd291bGQgYWxzbyBiZSBxdWl0ZSBwbGF1 c2libGUgdG8gcmVtb3ZlIG9uZSBsYXllciBvZg0KPiA+ID4gPiBpbmRpcmVjdGlvbi4NCj4gPiA+ ID4NCj4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEJyaWFuDQo+ID4gPiA+ID4NCj4gPiA+ DQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPiA+IEdlb3ByaXYgbWFpbGluZyBsaXN0DQo+ID4gPiBHZW9wcml2QGlldGYub3Jn DQo+ID4gPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nZW9wcml2DQo+ ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+ID4gVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBh bmQgbWF5DQo+ID4gY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNl IHByaXZhdGUgaW5mb3JtYXRpb24uDQo+ID4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KPiA+IGltbWVkaWF0ZWx5IGFuZCBkZWxldGUg dGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCj4gPiB0aGlzIGVtYWlsIGlz IHByb2hpYml0ZWQuDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+ID4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiA+IFttZjJdDQo+IA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50 IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3 aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhl IG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGli aXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0= --===============0713684564== 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 --===============0713684564==-- From ecrit-bounces@ietf.org Thu Oct 12 20:27:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYAtE-000419-Fu; Thu, 12 Oct 2006 20:27:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYAtC-00040E-Vy; Thu, 12 Oct 2006 20:27:02 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYAtB-0002oD-PG; Thu, 12 Oct 2006 20:27:02 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 19:27:01 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 12 Oct 2006 19:27:00 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 19:26:59 -0500 Message-ID: From: "Thomson, Martin" To: "Henning Schulzrinne" , "Brian Rosen" Date: Thu, 12 Oct 2006 19:26:57 -0500 Subject: RE: [Geopriv][Ecrit] Map data for a civic address MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 13 Oct 2006 00:26:59.0926 (UTC) FILETIME=[4C311760:01C6EE5E] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: Content-class: urn:content-classes:message Thread-Topic: [Geopriv][Ecrit] Map data for a civic address Thread-Index: AcbuXLYUgrij2NaYSQ2hbQ+trPLacgAAL1WA X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1174917724==" Errors-To: ecrit-bounces@ietf.org --===============1174917724== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message PiBCdHcsIFBJREYtTE8gYWxyZWFkeSBjb250YWlucyBpbmZvcm1hdGlvbiBfYWJvdXRfIHRoZSBh ZGRyZXNzLCBzdWNoDQo+IGFzIHRoZSBwbGFjZXR5cGUgb3IsIGlmIHlvdSBsaWtlLCB0aGUgYnVz aW5lc3MgbmFtZS4NCg0KQnVzaW5lc3MgbmFtZXMgYXJlIG9mdGVuIGEgdmVyeSB1c2VmdWwgd2F5 IG9mIGlkZW50aWZ5aW5nIGEgbG9jYXRpb24gLSB0aGV5IGFyZSBvZnRlbiBmYXIgbW9yZSBwcm9t aW5lbnRseSBkaXNwbGF5ZWQgdGhhbiBvdGhlciBsYWJlbHMsIGxpa2Ugc3RyZWV0IG51bWJlcnMu ICBUaGVyZWZvcmUsIHRoZXkgaGF2ZSBhIGRpcmVjdCB1c2UuDQoNCkFzIGZvciBwbGFjZXR5cGUu Li4gb2J2aW91c2x5IHlvdSB3aWxsIGRpc2FncmVlLCBidXQgSSBkb24ndCB0aGluayB0aGF0IHRo ZXkgc2hvdWxkIGhhdmUgYmVlbiBpbmNsdWRlZCBpbiB0aGUgY2l2aWMgYWRkcmVzcyBlbmNvZGlu Zy4NCg0KQ2hlZXJzLA0KTWFydGluDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25s eSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2Ug cHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3Jp Z2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVk Lg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ== --===============1174917724== 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 --===============1174917724==-- From ecrit-bounces@ietf.org Thu Oct 12 20:39:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYB5D-0002bR-F3; Thu, 12 Oct 2006 20:39:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYB5D-0002bJ-3w; Thu, 12 Oct 2006 20:39:27 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYB5B-0005fS-Sm; Thu, 12 Oct 2006 20:39:27 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GYB4x-0003UA-G6; Thu, 12 Oct 2006 19:39:12 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: What you get may depend on who you are was RE: [Geopriv][Ecrit] Map data for a civic address Date: Thu, 12 Oct 2006 20:39:15 -0400 Message-ID: <01e401c6ee60$048b31a0$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: AcbuXGvSFtKm8iWdTAiCbaOCEXb/2QAAhDzg 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: 7655788c23eb79e336f5f8ba8bce7906 Cc: 'GEOPRIV' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > One of the practical issues is that LoST is currently designed for > public information; any layer of indirection has to deal with well- > discussed problems of having the LoST server decide who gets access > to the information. Could we close this issue out? LoST is defined over TLS. Could the following text be included in Security Considerations: In some jurisdictions, not all of the information in the LoST server may be appropriate for an arbitrary public client to obtain. The LoST server MAY make use of the identity of the requester implied in a TLS connection establishment within which LoST queries and responses are sent and make an authorization decision based on that identity. This means that the response of the server MAY depend on the identity of the requester. The query itself does not contain any explicit identifying information of the requestor. Appropriate TLS privacy mechanisms SHOULD be used to protect the non-public information when such an option is used. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 12 20:54:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYBJU-0003id-70; Thu, 12 Oct 2006 20:54:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYBJT-0003iF-Fe; Thu, 12 Oct 2006 20:54:11 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYBJR-0001hS-8D; Thu, 12 Oct 2006 20:54:11 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Thu, 12 Oct 2006 20:53:35 -0400 id 0158811B.452EE38F.00000154 In-Reply-To: <01e401c6ee60$048b31a0$640fa8c0@cis.neustar.com> References: <01e401c6ee60$048b31a0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7AE794F5-C1E7-43D7-8EAA-632C2B109CB4@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: What you get may depend on who you are was RE: [Geopriv][Ecrit] Map data for a civic address Date: Thu, 12 Oct 2006 20:53:55 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: 'GEOPRIV' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Oct 12, 2006, at 8:39 PM, Brian Rosen wrote: > LoST is defined over TLS. > > Could the following text be included in Security Considerations: > > In some jurisdictions, not all of the information in the LoST > server may be > appropriate for an arbitrary public client to obtain. The LoST > server MAY > make use of the identity of the requester implied in a TLS connection > establishment within which LoST queries and responses are sent and > make an > authorization decision based on that identity. This means that the > response > of the server MAY depend on the identity of the requester. The > query itself > does not contain any explicit identifying information of the > requestor. > Appropriate TLS privacy mechanisms SHOULD be used to protect the > non-public > information when such an option is used. First, being designed over TLS does not mean anything about the information being non-public. Second, we aren't just using TLS. We've been round and round on this. Third, I think this is just a plain bad idea. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 13 12:20:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYPlG-0003BZ-VK; Fri, 13 Oct 2006 12:19:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYPlG-0003BC-2M; Fri, 13 Oct 2006 12:19:50 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYPl4-0005d3-G4; Fri, 13 Oct 2006 12:19:50 -0400 Received: from ([139.76.131.79]) by aismt06p.bellsouth.com with SMTP id KP-AXPRN.9182097; Fri, 13 Oct 2006 12:19:09 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 13 Oct 2006 12:19:09 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 13 Oct 2006 12:19:09 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv][Ecrit] Map data for a civic address Date: Fri, 13 Oct 2006 12:19:09 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA2B5219@crexc41p> In-Reply-To: Importance: normal Priority: normal X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv][Ecrit] Map data for a civic address thread-index: AcbuR2kZRG+XVIc5SG+3lybb5jCvfwACYsSwAADKsQAAAU8x4AAAe/nAACE52IA= From: "Stark, Barbara" To: "Thomson, Martin" , "Brian Rosen" , "Henning Schulzrinne" X-OriginalArrivalTime: 13 Oct 2006 16:19:09.0518 (UTC) FILETIME=[501506E0:01C6EEE3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Cc: GEOPRIV WG , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org If this pointer is provided by the LIS, then all access providers who = supply service to that building would have to have this. For example, if = tenants in a high rise apartment building have a choice between cable = access, DSL, city-wide mesh Wi-Fi, and satellite, all these providers = would have to replicate this pointer in their LIS. So the building = managers would have to know all the possible access mechanisms, how to = get the pointer to these companies, etc. Just a comment. It's definitely do-able. The list of possible access = providers is still short. Barbara > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Thursday, October 12, 2006 8:15 PM > To: Brian Rosen; Henning Schulzrinne > Cc: GEOPRIV WG; ECRIT > Subject: RE: [Geopriv][Ecrit] Map data for a civic address >=20 >=20 > You need to be careful that you aren't mistaking a "can" for=20 > a "should". >=20 > In any case, assuming that the LIS provides this information;=20 > where does this belong? I can see four options: >=20 > - In the civic address: I've already given my reasons why I=20 > believe this is a bad idea. >=20 > - In the Geopriv element (alongside , =20 > and so forth). >=20 > - In the PIDF: I wonder if this could really be considered=20 > presence information. >=20 > - In the acquisition protocol: Add an option in the protocol=20 > to request additional information and include the data as an adjunct. >=20 > Personally, I like the last one. >=20 > Cheers, > Martin >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, 13 October 2006 10:01 AM > > To: Thomson, Martin; 'Henning Schulzrinne' > > Cc: 'GEOPRIV WG'; 'ECRIT' > > Subject: RE: [Geopriv][Ecrit] Map data for a civic address > >=20 > > Agree we aren't going to design it on the fly. > >=20 > > I don't think WE are going to design it. > >=20 > > At the moment, I really think that is a local matter, and=20 > it works as a > > local matter without any loss of interoperability. > >=20 > > It is clearly information ABOUT the address. > >=20 > > It's not limited to civic address. > >=20 > > I don't think we need to draw lines. While I can't think=20 > of a good reason > > to, if you put in a civic location with just a city name,=20 > you might get > > back > > a street map. Again, a local matter, it seems to me. > >=20 > > One of the reasons why there is some sense to allowing the=20 > pointer in the > > PIDF itself (and it DOES make sense to have a pointer for=20 > "additional > > information about the location in this PIDF") is that, at=20 > least in large > > enterprise, it can give you the right answer, because it=20 > comes from the > > right entity (it is, after all, the enterprise that runs=20 > the LIS in this > > case). A more general case of a broadband carrier serving=20 > a high rise > > apartment building doesn't work, but then the notion of it=20 > being in LoST > > makes sense there. > >=20 > > Right now, without a lot to go on, I'm thinking I don't want to > > standardize > > a whole bunch of service URNs, one per piece of data and=20 > query for them > > individually. I think I want one locally defined XML=20 > structure and a > > "gimme > > all you got" query. YMMV. > >=20 > > Later, when we have more experience in how this works, and=20 > how else we can > > use it, we could think about creating some more services=20 > such as map. > >=20 > > Brian > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > > Sent: Thursday, October 12, 2006 7:38 PM > > > To: Brian Rosen; Henning Schulzrinne > > > Cc: GEOPRIV WG; ECRIT > > > Subject: [Geopriv][Ecrit] Map data for a civic address > > > > > > This appears to have branched off onto a new topic, so I=20 > have taken the > > > liberty of changing the subject. > > > > > > I think that what you are describing is a good idea for a=20 > new service, > > but > > > I don't think that designing on the fly is going to work.=20 > I also don't > > > think that it is necessary to lump this data in with a=20 > civic address. > > > > > > I'd contend that what you are proposing is information=20 > _about_ the civic > > > address, not a part of the address. > > > > > > To pick on one aspect of your data, what distinguishes a=20 > floor plan that > > > highlights where particular rooms are to a street directory that > > > highlights where roads are, or a world map that includes country > > borders? > > > Yes, you can argue that there is a level beyond which you=20 > can start > > making > > > assumptions, but that requires that you draw a line. > > > > > > A better approach would be to define a service, just as=20 > Roger suggested. > > > Location + urn:service:map + LoST =3D Map. You can add to=20 > this as much > > > complexity as you like - delegation of responsibility for=20 > features, > > > innumerable tags, scalable resolution, etc... > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Friday, 13 October 2006 8:59 AM > > > > To: 'Henning Schulzrinne' > > > > Cc: 'GEOPRIV WG'; 'Ecrit@Ietf.Org' > > > > Subject: RE: [Ecrit] RE: [Geopriv] coming to terms on=20 > location by > > > > reference > > > > > > > > I think there are several dimensions. > > > > > > > > One is tenant/building owner; some information is=20 > available from the > > > > tenant, > > > > some from the building owner. I was thinking that the base data > > > structure > > > > would be from the building owner. He would have things=20 > like building > > > > floor > > > > plans, construction, entrance, elevator, .... kinds of data. > > > > > > > > He would then have a pointer for each tenant, which=20 > would be a data > > > > structure provided by the tenant. The tenant would=20 > have things like > > > > interior floor plans, hazmat data. > > > > > > > > The thing is, of course, that nearly everything in the=20 > tenant part > > could > > > > apply to the building owner. > > > > > > > > I think there are a very large number of potential=20 > items in the data > > > > structure. I'm not sure how many of them are small=20 > enough to put > > > directly > > > > in, vs needing an indirect mechanism. Clearly floor plans are > > indirect. > > > > Something like hazmat data may not be. Elevator status=20 > may not be, > > but > > > > remote elevator control probably is (and probably requires > > significantly > > > > more authentication and authorization if it is provided=20 > at all). The > > > > availability, location, etc of surveillance video could=20 > be directly in > > > the > > > > structure, but you clearly would have an RTSP (or=20 > something like it) > > > > pointer > > > > to the actual video. There are probably hundreds of=20 > potential tags, > > and > > > I > > > > don't know how many are pointers. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > > Sent: Thursday, October 12, 2006 5:43 PM > > > > > To: Brian Rosen > > > > > Cc: 'GEOPRIV WG'; 'Ecrit@Ietf.Org' > > > > > Subject: Re: [Ecrit] RE: [Geopriv] coming to terms on=20 > location by > > > > > reference > > > > > > > > > > > > > > > > > The IETF is, of course, not the place to=20 > standardize that data > > > > > structure, at > > > > > > least not now. > > > > > > > > > > Sure - but we need to have some idea what constraints=20 > we impose on > > > > > future solutions. For example, the approach you=20 > suggest means that > > all > > > > > information has to be managed by a single source, at=20 > least at the > > > > > pointer level. I happen to think that this is not=20 > unreasonable, but > > > > > since the number of types of information is probably=20 > fairly small > > > > > (handful), it would also be quite plausible to remove=20 > one layer of > > > > > indirection. > > > > > > > > > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > >=20 > -------------------------------------------------------------- > ---------- > > -- > > > ---------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > >=20 > -------------------------------------------------------------- > ---------- > > -- > > > ---------------------- > > > [mf2] > >=20 >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA621 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 13 14:09:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYRTZ-00061m-6h; Fri, 13 Oct 2006 14:09:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYRTY-0005xt-6g; Fri, 13 Oct 2006 14:09:40 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYRTP-00083G-IH; Fri, 13 Oct 2006 14:09:40 -0400 Received: from [172.16.10.86] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Fri, 13 Oct 2006 14:09:00 -0400 id 01588107.452FD63C.00006BB8 Message-ID: <452FD645.5020109@hxr.us> Date: Fri, 13 Oct 2006 14:09:09 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: GEOPRIV WG , ECRIT Subject: Re: [Geopriv][Ecrit] Map data for a civic address References: <7582BC68E4994F4ABF0BD4723975C3FA2B5219@crexc41p> In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA2B5219@crexc41p> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea 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 > Just a comment. It's definitely do-able. The list of possible access providers is still short. Before this goes any further, it should be noted that this is outside the scope of both ECRIT and GEOPRIV. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 18 15:52:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaHSZ-0003hF-EI; Wed, 18 Oct 2006 15:52:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaHRP-0002Qh-RK; Wed, 18 Oct 2006 15:51:04 -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 1GaHRP-0003uf-Ow; Wed, 18 Oct 2006 15:51:03 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GaHRP-0001pc-Ad; Wed, 18 Oct 2006 15:51:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 044A62ACF5; Wed, 18 Oct 2006 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GaHQQ-0001UK-O0; Wed, 18 Oct 2006 15:50:02 -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, 18 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-phonebcp-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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 : Best Current Practice for Communications Services in support of Emergency Calling Author(s) : B. Rosen, J. Polk Filename : draft-ietf-ecrit-phonebcp-00.txt Pages : 16 Date : 2006-10-18 Requesting help in an emergency using a communications device such as a telephone or mobile is an accepted practice in most of the world. As communications devices increasingly utilize the Internet to interconnect and communicate, users will continue to expect to use such devices to request help, regardless of whether or not they communicate using IP. The emergency response community will have to upgrade their facilities to support the wider range of communications services, but cannot be expected to handle wide variation in device and service capability. The IETF has several efforts targeted at standardizing various aspects of placing emergency calls. This memo describes best current practice on how devices and services should use such standards to reliably make emergency calls A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-00.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-phonebcp-00.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-phonebcp-00.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-10-18132520.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-phonebcp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-phonebcp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-18132520.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 Wed Oct 18 18:14:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJgN-0004iL-Ov; Wed, 18 Oct 2006 18:14:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJgM-0004i4-C4 for ecrit@ietf.org; Wed, 18 Oct 2006 18:14:38 -0400 Received: from pne-smtpout1-sn2.hy.skanova.net ([81.228.8.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaJgL-0005LB-BT for ecrit@ietf.org; Wed, 18 Oct 2006 18:14:38 -0400 Received: from Snork (213.64.228.153) by pne-smtpout1-sn2.hy.skanova.net (7.2.075) id 452BAD6D001D2965; Thu, 19 Oct 2006 00:14:36 +0200 From: "Gunnar Hellstrom" To: Subject: RE: [Ecrit] Missing media specificatios in draft-ietf-ecrit-phonebcp-00.txt Date: Thu, 19 Oct 2006 00:14:42 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Importance: Normal In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 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 The ecrit-phonebcp-00 is missing some important specifics about supported media that was included in its predecessor draft-rosen-sos-phonebcp-01.txt The earlier specification draft-rosen-sos-phonebcp-01.txt says in the introduction: ---------------------------------------------------------------------------- ------ While current PSAPs are limited to voice sessions, often with the additional capability to serve hearing impaired users with text based "TTY" devices, envisioned upgrades to PSAPs will allow sessions with audio, video, and several kinds of text including interactive text [RFC4103] and Instant Messages. and [I-D.ietf- sipping-toip] ---------------------------------------------------------------------------- ------- This paragraph does not exist in the new draft, leaving the reader without any clear guidance to implement a terminal that is media compatible with the emergency service. The clarity provided by the previous version can be a very important stabilizing factor, that will result in good high probability for successful emergency calls with other media than audio. I suggest that text providing the same clarity is put back into the specification. But we can take the opportunity to refine the text a bit. The details were only provided in the introduction. I suggest that only a brief statement is placed in the introduction, and the details in section 3: "Which devices and services should support emergency calls". Proposed text: Add a paragraph after the first paragraph of section 2. Introduction: ---------------------------------------------------------------------------- While current PSAPs are limited to voice sessions, sometimes with the additional capability to serve hearing impaired users with textphone devices, envisioned PSAPs will allow sessions with at least audio, video, real-time text and text messaging. -------------------------------------------------------------------------- Add a paragraph to section 3. "Which devices and services should support emergency calls" ---------------------------------------------------------------------------- ------------ The current best practices for media and codec support should be applied. Such practices are described in RFC 4504 [RFC 4504], with common codecs for audio and video, RFC 4103 [RFC 4103] for real-time text and further detailed in [sipping-toip]. Support for Instant Messages according to the SIMPLE MSRP [msrp] protocols is also envisioned. --------------------------------------------------------------------------- In the references, [msrp] should then be introduced. ------------------------------------------------------------------------ [msrp] Relay Extensions for the Message Sessions Relay Protocol (MSRP) ------------------------------------------------------------------------- Thanks, Gunnar --------------------- Gunnar Hellstrom Omnitor gunnar.hellstrom@omnitor.se +46708204288 www.omnitor.se -----Ursprungligt meddelande----- Fran: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Skickat: den 18 oktober 2006 21:50 Till: i-d-announce@ietf.org Kopia: ecrit@ietf.org Amne: [Ecrit] I-D ACTION:draft-ietf-ecrit-phonebcp-00.txt 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 : Best Current Practice for Communications Services in support of Emergency Calling Author(s) : B. Rosen, J. Polk Filename : draft-ietf-ecrit-phonebcp-00.txt Pages : 16 Date : 2006-10-18 Requesting help in an emergency using a communications device such as a telephone or mobile is an accepted practice in most of the world. As communications devices increasingly utilize the Internet to interconnect and communicate, users will continue to expect to use such devices to request help, regardless of whether or not they communicate using IP. The emergency response community will have to upgrade their facilities to support the wider range of communications services, but cannot be expected to handle wide variation in device and service capability. The IETF has several efforts targeted at standardizing various aspects of placing emergency calls. This memo describes best current practice on how devices and services should use such standards to reliably make emergency calls A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-00.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-phonebcp-00.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-phonebcp-00.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 Wed Oct 18 20:16:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaLZn-00080Q-0J; Wed, 18 Oct 2006 20:15:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaLZm-0007zw-4Z for ecrit@ietf.org; Wed, 18 Oct 2006 20:15:58 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaLZk-00031m-KN for ecrit@ietf.org; Wed, 18 Oct 2006 20:15:58 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GaLZZ-0000Dz-6e; Wed, 18 Oct 2006 19:15:45 -0500 From: "Brian Rosen" To: "'Gunnar Hellstrom'" Subject: RE: [Ecrit] Missing media specificatios indraft-ietf-ecrit-phonebcp-00.txt Date: Wed, 18 Oct 2006 20:15:51 -0400 Message-ID: <02c701c6f313$be500040$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: AcbzAs2CKaHGgB6TT621wLQef3FEIAAEAUaA 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: 33cc095b503da4365ce57c727e553cf1 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Gunnar I moved the text to -framework. -framework has the "why", -phonebcp has the "what". So, the normative text is in -phonebcp, and the informative text is in -framework. It's draft-ietf-ecrit-framework-00 and if it's not announced yet, you can pick up a copy at: http://www.brianrosen.net/internet-drafts/draft-ietf-ecrit-framework-00.txt Take a look and see if you want some of your edits applied to -framework, rather than -phonebcp. Normative text for phones or proxies goes in -phonebcp, and would use 2117 language. Brian > -----Original Message----- > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > Sent: Wednesday, October 18, 2006 6:15 PM > To: ecrit@ietf.org > Subject: RE: [Ecrit] Missing media specificatios indraft-ietf-ecrit- > phonebcp-00.txt > > The ecrit-phonebcp-00 is missing some important specifics about supported > media that was included in its predecessor draft-rosen-sos-phonebcp-01.txt > > > > The earlier specification draft-rosen-sos-phonebcp-01.txt says in the > introduction: > -------------------------------------------------------------------------- > -- > ------ > While current PSAPs are limited to voice sessions, often > with the additional capability to serve hearing impaired users with > text based "TTY" devices, envisioned upgrades to PSAPs will allow > sessions with audio, video, and several kinds of text including > interactive text [RFC4103] and Instant Messages. and [I-D.ietf- > sipping-toip] > -------------------------------------------------------------------------- > -- > ------- > This paragraph does not exist in the new draft, leaving the reader without > any clear guidance to implement a terminal that is media compatible with > the > emergency service. > The clarity provided by the previous version can be a very important > stabilizing factor, that will result in good high probability for > successful > emergency calls with other media than audio. > > I suggest that text providing the same clarity is put back into the > specification. But we can take the opportunity to refine the text a bit. > The details were only provided in the introduction. I suggest that only a > brief statement is placed in the introduction, and the details in section > 3: > "Which devices and services should support emergency calls". > > Proposed text: > > Add a paragraph after the first paragraph of section 2. Introduction: > -------------------------------------------------------------------------- > -- > While current PSAPs are limited to voice sessions, sometimes > with the additional capability to serve hearing impaired users > with textphone devices, envisioned PSAPs will allow sessions > with at least audio, video, real-time text and text messaging. > -------------------------------------------------------------------------- > Add a paragraph to section 3. "Which devices and services should support > emergency calls" > -------------------------------------------------------------------------- > -- > ------------ > The current best practices for media and codec support should be > applied. > Such practices are described in RFC 4504 [RFC 4504], with common codecs > for audio and video, RFC 4103 [RFC 4103] for real-time text and further > detailed in [sipping-toip]. Support for Instant Messages according to > the SIMPLE MSRP [msrp] protocols is also envisioned. > -------------------------------------------------------------------------- > - > > In the references, [msrp] should then be introduced. > > ------------------------------------------------------------------------ > [msrp] Relay Extensions for the Message Sessions Relay Protocol > (MSRP) > ------------------------------------------------------------------------- > > Thanks, > Gunnar > --------------------- > Gunnar Hellstrom > Omnitor > gunnar.hellstrom@omnitor.se > +46708204288 > www.omnitor.se > > -----Ursprungligt meddelande----- > Fran: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Skickat: den 18 oktober 2006 21:50 > Till: i-d-announce@ietf.org > Kopia: ecrit@ietf.org > Amne: [Ecrit] I-D ACTION:draft-ietf-ecrit-phonebcp-00.txt > > > 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 : Best Current Practice for Communications Services in > support of > Emergency Calling > Author(s) : B. Rosen, J. Polk > Filename : draft-ietf-ecrit-phonebcp-00.txt > Pages : 16 > Date : 2006-10-18 > > > Requesting help in an emergency using a communications device such as > a telephone or mobile is an accepted practice in most of the world. > As communications devices increasingly utilize the Internet to > interconnect and communicate, users will continue to expect to use > such devices to request help, regardless of whether or not they > communicate using IP. The emergency response community will have to > upgrade their facilities to support the wider range of communications > services, but cannot be expected to handle wide variation in device > and service capability. The IETF has several efforts targeted at > standardizing various aspects of placing emergency calls. This memo > describes best current practice on how devices and services should > use such standards to reliably make emergency calls > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-00.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-phonebcp-00.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-phonebcp-00.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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 19 08:55:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXQd-0004TL-1A; Thu, 19 Oct 2006 08:55:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXQb-0004Rg-FO for ecrit@ietf.org; Thu, 19 Oct 2006 08:55:17 -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 1GaXQX-00076O-4g for ecrit@ietf.org; Thu, 19 Oct 2006 08:55:17 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 19 Oct 2006 05:55:12 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JCtCQN000889 for ; Thu, 19 Oct 2006 05:55:12 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9JCtCAo002145 for ; Thu, 19 Oct 2006 05:55:12 -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.1830); Thu, 19 Oct 2006 05:55:12 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 05:55:11 -0700 From: "Marc Linsner" To: Date: Thu, 19 Oct 2006 08:55:09 -0400 Message-ID: <006401c6f37d$cfc2ceb0$260d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acbzfc4rMAWtwpFISn+qYuCWTtQMWg== X-OriginalArrivalTime: 19 Oct 2006 12:55:12.0168 (UTC) FILETIME=[D0881A80:01C6F37D] DKIM-Signature: a=rsa-sha1; q=dns; l=86; t=1161262512; x=1162126512; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:Agenda=20for=20San=20Diego; X=v=3Dcisco.com=3B=20h=3D2CAFuLtsTyBrSr1wOJws8ab9d6c=3D; b=nxCLuFSE7U4cn3l9h6fJznulCuH6t/Ok5sfRLH/vJNKdInFqUljTbzNGKf3pl+R40r0oXo2K pVM2OqwPAIVIqo8gRPG/bymR5D1WSBzs4mWB4TncFOD5/ydKU2idyigW; Authentication-Results: sj-dkim-3.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [Ecrit] Agenda for San Diego X-BeenThere: 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 want time on the agenda for the San Diego meeting, send an email. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 19 15:30:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gadap-0007KG-Vm; Thu, 19 Oct 2006 15:30:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gadap-0007KA-1Y for ecrit@ietf.org; Thu, 19 Oct 2006 15:30:15 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gadan-00056B-Nz for ecrit@ietf.org; Thu, 19 Oct 2006 15:30:15 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 19 Oct 2006 12:30:14 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JJUD9c006313 for ; Thu, 19 Oct 2006 15:30:13 -0400 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 k9JJUDYL029836 for ; Thu, 19 Oct 2006 15:30:13 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:30:13 -0400 Received: from [161.44.55.227] ([161.44.55.227]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:30:12 -0400 Message-ID: <4537D244.2060400@cisco.com> Date: Thu, 19 Oct 2006 15:30:12 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2006 19:30:12.0721 (UTC) FILETIME=[FF297E10:01C6F3B4] DKIM-Signature: a=rsa-sha1; q=dns; l=1561; t=1161286213; x=1162150213; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:ICE=20Tutorial=20during=20IETF=2067!=20[DO=20NOT=20REPLY] |To:ECRIT=20; X=v=3Dcisco.com=3B=20h=3DIVH9amnYVaV4pfzKKjl/WmQt0Lg=3D; b=jt3/7uWTRFxEJlIM1PQ0lbykOqhFTYBui2DrsGYW0Xl4kHNjZk3r5+hOfN7/PkYDpw1P5YAd y7kEhdJ1tejrCOaNkjljAje3yzrL3GqGWxK3uDYUxsLXvndYB/wS3LQI; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Ecrit] ICE Tutorial during IETF 67! [DO NOT REPLY] X-BeenThere: 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 (Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-11.txt) WHEN: Tuesday, November 7 1130-1300 (lunch logistics are in progress and will be announced ASAP) WHERE: Grande Ballroom A WHO: Anyone with an interest in RAI work that would like to learn more about ICE. WHY: ICE is one of the 'core' SIP specifications (according to the SIP hitchhikers guide) and seeing some good adoption. It's the IETF tool for NAT traversal for SIP-based media. However, it's a complex specification. The tutorial will assume only basic familiarity with SIP, SDP and NAT, and explain the rest. Participants will emerge with a high level understanding of the operation of ICE. The tutorial will be based on the pending -12 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice) so I can get a count of the number of participants for lunch purposes. !DO NOT REPLY TO THIS NOTE! -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Oct 22 23:33:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbqZK-00058e-L3; Sun, 22 Oct 2006 23:33:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbqZJ-0004zk-5d for ecrit@ietf.org; Sun, 22 Oct 2006 23:33:41 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbqPH-0006xi-Gt for ecrit@ietf.org; Sun, 22 Oct 2006 23:23:20 -0400 Received: from [192.168.0.41] (pool-138-89-105-49.mad.east.verizon.net [138.89.105.49]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k9N3NCjM009876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sun, 22 Oct 2006 23:23:17 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <3DBF0AB0-F34D-47FB-A72C-9E07B62D0031@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Henning Schulzrinne Date: Sun, 22 Oct 2006 23:23:03 -0400 X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Ecrit] LoST open issue: ttl X-BeenThere: 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 updating the draft, we stumbled across one open issue that probably needs more working group discussion. It doesn't seem all that important, but has wider implications. The current draft version has the time-to-live value as an integer, measured in seconds. An alternative would be an absolute XML-style time, in GMT. (XML allows time zones, but those don't seem particularly useful here.) The major trade-offs are, in my estimation: (Sync) Relative times don't need clock sync. Whether this matters or not depends on one's estimation of clock sync. In our case, a few minutes are unlikely to matter, given that TTL values of a day or month are far more likely. Note also that the HTTP Date header can be used to detect client mis-configuration. (Delay) Relative TTL values need to be updated each time the object sits in a queue somewhere. Thus, it's important that any delays outside the control of LoST-aware components is minimized, such as any caching by HTTP proxies or delayed TCP. This is probably more of an exception condition than something that would occur on a daily basis. (Signing) A major issue is signing. If we want the authoritative source of the data to sign the object, e.g., using XML-DSIG, relative times aren't useful, since a receiver cannot tell if the object has expired or not. A malicious user can easily inject signed, but expired, data into the system if relative expiration times are used. (Alternatively, the absolute time of creation of the object can be included, but that has the same Sync problem, so one gets the worst of both approaches.) (Caching) It would be nice to be able to cache whole findServiceResponse objects without having to assemble them on retrieval. Otherwise, it would be likely that a LoST resolver, for example, would have to store the DOM in some serialized fashion, update it for each retrieval to correct the TTL value, and then generate, from scratch, the actual textual XML representation. Since such retrievals from caches are likely to be far more common than from origin servers, assuming caches are useful at all, this XML generation may well dominate the overall computational complexity. There may be other considerations that I'm missing. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 23 11:50:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc23w-0006W7-IZ; Mon, 23 Oct 2006 11:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc23v-0006VS-Od for ecrit@ietf.org; Mon, 23 Oct 2006 11:50:03 -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 1Gc23k-0002hx-Nx for ecrit@ietf.org; Mon, 23 Oct 2006 11:50:03 -0400 Received: (qmail invoked by alias); 23 Oct 2006 15:49:51 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp033) with SMTP; 23 Oct 2006 17:49:51 +0200 X-Authenticated: #29516787 Message-ID: <453CE49C.5050901@gmx.net> Date: Mon, 23 Oct 2006 17:49:48 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Ecrit] Agenda X-BeenThere: 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, please find a first proposal for the agenda here: http://www.ietf-ecrit.org/IETF67/ecrit-agenda.txt Please let us know if we forgot something. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 23 13:44:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc3q9-00074N-Ou; Mon, 23 Oct 2006 13:43:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc3q8-00073n-Vs for ecrit@ietf.org; Mon, 23 Oct 2006 13:43:56 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc3pv-0003N5-NW for ecrit@ietf.org; Mon, 23 Oct 2006 13:43:56 -0400 Received: from [172.16.10.86] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Mon, 23 Oct 2006 13:43:13 -0400 id 01588379.453CFF31.00004CC5 Message-ID: <453CFF3F.9060504@hxr.us> Date: Mon, 23 Oct 2006 13:43:27 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] LoST open issue: ttl References: <3DBF0AB0-F34D-47FB-A72C-9E07B62D0031@cs.columbia.edu> In-Reply-To: <3DBF0AB0-F34D-47FB-A72C-9E07B62D0031@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: 92df29fa99cf13e554b84c8374345c17 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org First, I find the argument for delay unconvincing as LoST is not a store-and-forward system and therefore there are no queues of the nature you are talking about. I hope that anybody writing LoST code would know not to wait 30 days on a TCP timeout, as well. Second, the issue of DSIG has come up many times on this list and I don't think we are any closer to getting consensus. In short, in an emergency they will be ignored if they are invalid, so what is the point. To add to that, absolute times could easily cause a signed response to be deemed invalid with just one minute of drift at either end, and one minute drift is not that uncommon. Third, to negate re-assembly, we'd also have to take boundary references and address validation checks out of the protocol. Finally, the specification of the absolute time is much more complex than relative time. Since LoST uses Relax NG, the data type would be the XML Schema dateTime, which is a subset of ISO 8601. That's already a source of interoperability problems. Add on top of that rules for disallowing timezone (which only cause greater confusion), and you have two ways programmers could do the wrong thing very easily. From a code standpoint, this is more complex than relative ttl in seconds. Here is the Java code doing relative time: int ttl = Integer.parseInt( attribute.getValue() ); GregorianCalendar gc = new GregorianCalendar(); gc.add( gc.SECOND, ttl ); Here is the code for the absolute time (from http://www.dpawson.co.uk/relaxng/schema/datetime.html) import java.text.DecimalFormat; import java.text.SimpleDateFormat; import java.util.Date; import java.util.TimeZone; public class Now { public static void main(String[] args) { System.out.println(Now.getISO8601DateTime()); } public static String getISO8601DateTime() { SimpleDateFormat ISO8601Local = new SimpleDateFormat( "yyyy-MM-dd'T'HH:mm:ss"); TimeZone timeZone = TimeZone.getDefault(); ISO8601Local.setTimeZone(timeZone); DecimalFormat twoDigits = new DecimalFormat("00"); Date now = new Date(); int offset = ISO8601Local.getTimeZone().getOffset(now.getTime()); String sign = "+"; if (offset < 0) { offset = -offset; sign = "-"; } int hours = offset / 3600000; int minutes = (offset - hours * 3600000) / 60000; // As things stand any odd seconds in the offset are silently truncated. // Uncomment the next 5 lines to detect that rare circumstance. //if (offset != hours * 3600000 + minutes * 60000) { // // E.g. TZ=Asia/Riyadh87 // throw new RuntimeException("TimeZone offset (" + sign + offset + // " ms) is not an exact number of minutes"); //} String ISO8601Now = ISO8601Local.format(now) + sign + twoDigits.format(hours) + ":" + twoDigits.format(minutes); return ISO8601Now; } } -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 23 16:34:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6Up-0003H2-5B; Mon, 23 Oct 2006 16:34:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6Un-0003GK-IG for ecrit@ietf.org; Mon, 23 Oct 2006 16:34:05 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc6Ue-0001y3-QL for ecrit@ietf.org; Mon, 23 Oct 2006 16:34:05 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Gc6Uc-0007EM-3i; Mon, 23 Oct 2006 16:33:54 -0400 Received: from [127.0.0.1] (dhcp89-089-057.bbn.com [128.89.89.57]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id k9NKXrw20299; Mon, 23 Oct 2006 16:33:53 -0400 (EDT) Message-ID: <453D2732.2020207@bbn.com> Date: Mon, 23 Oct 2006 16:33:54 -0400 From: Richard Barnes User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] LoST open issue: ttl References: <3DBF0AB0-F34D-47FB-A72C-9E07B62D0031@cs.columbia.edu> <453CFF3F.9060504@hxr.us> In-Reply-To: <453CFF3F.9060504@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning, I'm not sure what the conflict is w.r.t. signing. For example, couldn't the authority sign its portion of the response (URI, Service Boundary, etc), and then the LoST server could sign the full combination of this signed data with the TTL? Some responses to Andrew are inline below. Beyond that, I don't regard TTL as an especially sensitive issue. If a client is using LoST for emergency calling, then it seems like the TTL is likely to be ignored in the name of keeping around some URI to try if everything else falls through. That being the case, it doesn't seem like the TTL requires a whole lot of precision, so relative times seem good enough (despite caching issues). Cheers, --Richard > First, I find the argument for delay unconvincing as LoST is not a > store-and-forward system and therefore there are no queues of the nature > you are talking about. I hope that anybody writing LoST code would know > not to wait 30 days on a TCP timeout, as well. Actually, this seemed to me to be one of the more sticky points: LoST is not store-and-forward, but it operates (by default) over HTTP, and there are untold numbers of HTTP proxies in this world. > Second, the issue of DSIG has come up many times on this list and I > don't think we are any closer to getting consensus. In short, in an > emergency they will be ignored if they are invalid, so what is the > point. Just like DSIG arguments, the "emergency excuse" keeps coming up on the list. Even if signatures might not be used as a go/no-go criterion in emergency circumstances, they can provide a measure of confidence, and they can still be useful in other contexts. (I'm not saying they're a necessity here, just that they shouldn't categorically be ruled out.) > To add to that, absolute times could easily cause a signed > response to be deemed invalid with just one minute of drift at either > end, and one minute drift is not that uncommon. This argues against absolute times because of clock sync, not because of signatures. (Maybe that's what you meant, but I was confused by your placing it next to your comments on signatures.) _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 23 20:53:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcAWz-0007TP-CJ; Mon, 23 Oct 2006 20:52:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcAWy-0007Sh-1M for ecrit@ietf.org; Mon, 23 Oct 2006 20:52:36 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcAWw-0003sH-Ot for ecrit@ietf.org; Mon, 23 Oct 2006 20:52:36 -0400 Received: from [192.168.0.41] (pool-138-89-105-49.mad.east.verizon.net [138.89.105.49]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k9O0qGcY005480 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Oct 2006 20:52:17 -0400 (EDT) In-Reply-To: <453D2732.2020207@bbn.com> References: <3DBF0AB0-F34D-47FB-A72C-9E07B62D0031@cs.columbia.edu> <453CFF3F.9060504@hxr.us> <453D2732.2020207@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST open issue: ttl Date: Mon, 23 Oct 2006 20:52:06 -0400 To: Richard Barnes X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Oct 23, 2006, at 4:33 PM, Richard Barnes wrote: > Henning, > > I'm not sure what the conflict is w.r.t. signing. For example, > couldn't the authority sign its portion of the response (URI, > Service Boundary, etc), and then the LoST server could sign the > full combination of this signed data with the TTL? Some responses > to Andrew are inline below. Right, but it is much less likely that the recipient has any useful trust relationship with intermediaries, which could be operated by the hotel I'm staying at and the bogus LoST server it's advertising. I don't see the advantage of this complexity. > > Beyond that, I don't regard TTL as an especially sensitive issue. > If a client is using LoST for emergency calling, then it seems like > the TTL is likely to be ignored in the name of keeping around some > URI to try if everything else falls through. That being the case, > it doesn't seem like the TTL requires a whole lot of precision, so > relative times seem good enough (despite caching issues). The problem is that an attacker can grab an old (stale) signed response and slip it to the innocent client. Take an extreme case, unlikely but possible: Some service has been compromised or handed off to somebody else and the LoST entry is changed for that service. Unfortunately, the bad guy will continue to waive the signed, but stale, version of the advertisement and can thus convince clients that the bad service is still good. In other words, a classical replay attack. Designing a system that facilitates such attacks seems like a bad idea. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 23 21:36:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcBDb-0005Y3-EB; Mon, 23 Oct 2006 21:36:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcBDZ-0005Vd-EJ for ecrit@ietf.org; Mon, 23 Oct 2006 21:36:37 -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 1GcB7o-0004BG-0M for ecrit@ietf.org; Mon, 23 Oct 2006 21:30:43 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 23 Oct 2006 21:30:10 -0400 id 0158848F.453D6CA2.00004A28 In-Reply-To: <453D2732.2020207@bbn.com> References: <3DBF0AB0-F34D-47FB-A72C-9E07B62D0031@cs.columbia.edu> <453CFF3F.9060504@hxr.us> <453D2732.2020207@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0CC7C14F-9270-46B5-A0DD-741451611541@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] LoST open issue: ttl Date: Mon, 23 Oct 2006 21:30:33 -0400 To: Richard Barnes X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Oct 23, 2006, at 4:33 PM, Richard Barnes wrote: >> First, I find the argument for delay unconvincing as LoST is not a >> store-and-forward system and therefore there are no queues of the >> nature you are talking about. I hope that anybody writing LoST >> code would know not to wait 30 days on a TCP timeout, as well. > > Actually, this seemed to me to be one of the more sticky points: > LoST is not store-and-forward, but it operates (by default) over > HTTP, and there are untold numbers of HTTP proxies in this world. I agree. The use of HTTP is a compromise (in the people working together sense, not as a security risk sense). If we are willing to admit that HTTP proxies will cause harm to relative TTLs, then we ought to admit that HTTP is not right for this problem as they will be getting in the middle in the other ways that HTTP proxies do. Ultimately, we should probably recommend in the LoST draft that operators SHOULD NOT use ports 80 and 443. >> Second, the issue of DSIG has come up many times on this list and >> I don't think we are any closer to getting consensus. In short, >> in an emergency they will be ignored if they are invalid, so what >> is the point. > > Just like DSIG arguments, the "emergency excuse" keeps coming up on > the list. Even if signatures might not be used as a go/no-go > criterion in emergency circumstances, they can provide a measure of > confidence, and they can still be useful in other contexts. (I'm > not saying they're a necessity here, just that they shouldn't > categorically be ruled out.) That's an interesting point (and we should probably change the subject as DSIG is really a separate topic). But what does confidence in this case mean? Do we really want to display things like "You dialed 911 but maybe talking to police imposters" to end users? What is automata to do with this confidence, query one more time? I doubt the answer will be any different the second time. I continue to believe that the expense in operating the infrastructure to enable DSIG is worth it when in the end, invalid signatures will be ignored. >> To add to that, absolute times could easily cause a signed >> response to be deemed invalid with just one minute of drift at >> either end, and one minute drift is not that uncommon. > > This argues against absolute times because of clock sync, not > because of signatures. (Maybe that's what you meant, but I was > confused by your placing it next to your comments on signatures.) Exactly. :) -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 23 21:38:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcBFU-0006xt-Jx; Mon, 23 Oct 2006 21:38:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcBFT-0006xo-43 for ecrit@ietf.org; Mon, 23 Oct 2006 21:38:35 -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 1GcBFP-0007IV-SO for ecrit@ietf.org; Mon, 23 Oct 2006 21:38:35 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 23 Oct 2006 21:38:06 -0400 id 01588490.453D6E7E.00004C1A In-Reply-To: References: <3DBF0AB0-F34D-47FB-A72C-9E07B62D0031@cs.columbia.edu> <453CFF3F.9060504@hxr.us> <453D2732.2020207@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] LoST open issue: ttl Date: Mon, 23 Oct 2006 21:38:29 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Oct 23, 2006, at 8:52 PM, Henning Schulzrinne wrote: >> I'm not sure what the conflict is w.r.t. signing. For example, >> couldn't the authority sign its portion of the response (URI, >> Service Boundary, etc), and then the LoST server could sign the >> full combination of this signed data with the TTL? Some responses >> to Andrew are inline below. > > Right, but it is much less likely that the recipient has any useful > trust relationship with intermediaries, which could be operated by > the hotel I'm staying at and the bogus LoST server it's advertising. Going with this scenario, when I visit NYC what says that I have any more of a relationship with the cities LoST server than I do with the hotel's? > I don't see the advantage of this complexity. Actually, I agree with Richard on this point. Not that I'm crazy about digital signatures, but the order of complexity is not that much greater once you've gone through all the trouble of doing digital signatures in the first place. >> Beyond that, I don't regard TTL as an especially sensitive issue. >> If a client is using LoST for emergency calling, then it seems >> like the TTL is likely to be ignored in the name of keeping around >> some URI to try if everything else falls through. That being the >> case, it doesn't seem like the TTL requires a whole lot of >> precision, so relative times seem good enough (despite caching >> issues). > > The problem is that an attacker can grab an old (stale) signed > response and slip it to the innocent client. Take an extreme case, > unlikely but possible: Some service has been compromised or handed > off to somebody else and the LoST entry is changed for that > service. Unfortunately, the bad guy will continue to waive the > signed, but stale, version of the advertisement and can thus > convince clients that the bad service is still good. In other > words, a classical replay attack. Designing a system that > facilitates such attacks seems like a bad idea. Wouldn't the server auth at the TLS layer prevent this? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 23 21:50:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcBRK-0001d3-4n; Mon, 23 Oct 2006 21:50:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcBRI-0001cv-Rr for ecrit@ietf.org; Mon, 23 Oct 2006 21:50:48 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcBRH-0001Ui-Kq for ecrit@ietf.org; Mon, 23 Oct 2006 21:50:48 -0400 Received: from [192.168.0.41] (pool-138-89-105-49.mad.east.verizon.net [138.89.105.49]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k9O1ohvK019132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Oct 2006 21:50:46 -0400 (EDT) In-Reply-To: References: <3DBF0AB0-F34D-47FB-A72C-9E07B62D0031@cs.columbia.edu> <453CFF3F.9060504@hxr.us> <453D2732.2020207@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST open issue: ttl Date: Mon, 23 Oct 2006 21:50:33 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > Going with this scenario, when I visit NYC what says that I have > any more of a relationship with the cities LoST server than I do > with the hotel's? > If we go with Brian's model, the PSAP or government agency will have an easily-recognized certificate, which isn't true for Alice's B&B. >> >> The problem is that an attacker can grab an old (stale) signed >> response and slip it to the innocent client. Take an extreme case, >> unlikely but possible: Some service has been compromised or handed >> off to somebody else and the LoST entry is changed for that >> service. Unfortunately, the bad guy will continue to waive the >> signed, but stale, version of the advertisement and can thus >> convince clients that the bad service is still good. In other >> words, a classical replay attack. Designing a system that >> facilitates such attacks seems like a bad idea. > > Wouldn't the server auth at the TLS layer prevent this? > No, since the old domain name is still valid, just owned by Mr. Evil Twin now (say). > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 23 22:02:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcBcK-00041N-Q4; Mon, 23 Oct 2006 22:02:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcBcJ-0003w3-An for ecrit@ietf.org; Mon, 23 Oct 2006 22:02:11 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcBcH-0003eN-4K for ecrit@ietf.org; Mon, 23 Oct 2006 22:02:11 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 23 Oct 2006 22:01:43 -0400 id 0158848F.453D7407.00005158 In-Reply-To: References: <3DBF0AB0-F34D-47FB-A72C-9E07B62D0031@cs.columbia.edu> <453CFF3F.9060504@hxr.us> <453D2732.2020207@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <90D56712-0D17-4676-B9C7-E75D72C77C04@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] LoST open issue: ttl Date: Mon, 23 Oct 2006 22:02:06 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Oct 23, 2006, at 9:50 PM, Henning Schulzrinne wrote: > If we go with Brian's model, the PSAP or government agency will > have an easily-recognized certificate, which isn't true for Alice's > B&B. Given that Alice's B&B is more likely to get their cert from a commercial CA and the government agency is more likely to get their cert from a government CA nobody has ever heard of, I think the opposite is actually true. >> Wouldn't the server auth at the TLS layer prevent this? > > No, since the old domain name is still valid, just owned by Mr. > Evil Twin now (say). And just where did Mr. Evil Twin get his hands on the private key of that government agency? You are not describing an evil twin attack, you are describing a key compromise. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 23 22:07:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcBhY-0000T8-Be; Mon, 23 Oct 2006 22:07:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcBhX-0000T2-Ji for ecrit@ietf.org; Mon, 23 Oct 2006 22:07:35 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcBhW-0004gY-By for ecrit@ietf.org; Mon, 23 Oct 2006 22:07:35 -0400 Received: from [192.168.0.41] (pool-138-89-105-49.mad.east.verizon.net [138.89.105.49]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k9O27Qip015357 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Oct 2006 22:07:31 -0400 (EDT) In-Reply-To: <453CFF3F.9060504@hxr.us> References: <3DBF0AB0-F34D-47FB-A72C-9E07B62D0031@cs.columbia.edu> <453CFF3F.9060504@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6CBA0FC7-A137-4F5E-B7A5-06562F840B43@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST open issue: ttl Date: Mon, 23 Oct 2006 22:07:17 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Oct 23, 2006, at 1:43 PM, Andrew Newton wrote: > First, I find the argument for delay unconvincing as LoST is not a > store-and-forward system and therefore there are no queues of the > nature you are talking about. I hope that anybody writing LoST > code would know not to wait 30 days on a TCP timeout, as well. > Since we have decided on HTTP, I'd rather have a solution that is robust even if things go boing. Just saying "since we chose something, bad things can't happen" isn't terribly helpful. > Second, the issue of DSIG has come up many times on this list and I > don't think we are any closer to getting consensus. In short, in > an emergency they will be ignored if they are invalid, so what is > the point. To add to that, absolute times could easily cause a > signed response to be deemed invalid with just one minute of drift > at either end, and one minute drift is not that uncommon. We have to remember that LoST can and hopefully will be used for many applications beyond the original emergency scope. Ruling out a reasonable security mechanism to save 10 lines of code seems like a rather peculiar way of designing systems. > > Third, to negate re-assembly, we'd also have to take boundary > references and address validation checks out of the protocol. I don't see the connection for boundary references (or values), as they are independent of the query. It doesn't matter where you are within the polygon - the boundary is still the same. I agree that validation (beyond , which is used for matching and thus is query-independent) is query-dependent. This naturally doesn't affect geospatial queries. > > Finally, the specification of the absolute time is much more > complex than relative time. Since LoST uses Relax NG, the data > type would be the XML Schema dateTime, which is a subset of ISO > 8601. That's already a source of interoperability problems. Add > on top of that rules for disallowing timezone (which only cause > greater confusion), Given the widespread use in other IETF schema, including systems such as EPP that have been standardized recently, I consider that a red herring. I don't recall seeing a last-call comment on the IETF list protesting the inclusion of 8601 in that context, including by yourself. > and you have two ways programmers could do the wrong thing very > easily. From a code standpoint, this is more complex than relative > ttl in seconds. Here is the Java code doing relative time: [3 lines vs. 15 lines with comments elided] Thanks for publishing the code, which then means nobody else has to write it... > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 23 22:10:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcBk7-00021j-RY; Mon, 23 Oct 2006 22:10:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcBk5-00021e-Rg for ecrit@ietf.org; Mon, 23 Oct 2006 22:10:13 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcBk4-0005BA-Jo for ecrit@ietf.org; Mon, 23 Oct 2006 22:10:13 -0400 Received: from [192.168.0.41] (pool-138-89-105-49.mad.east.verizon.net [138.89.105.49]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k9O2A6ol003496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Oct 2006 22:10:11 -0400 (EDT) In-Reply-To: <90D56712-0D17-4676-B9C7-E75D72C77C04@hxr.us> References: <3DBF0AB0-F34D-47FB-A72C-9E07B62D0031@cs.columbia.edu> <453CFF3F.9060504@hxr.us> <453D2732.2020207@bbn.com> <90D56712-0D17-4676-B9C7-E75D72C77C04@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5C6B7DBD-60E7-46E6-8A1A-5E975CE11F6D@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST open issue: ttl Date: Mon, 23 Oct 2006 22:09:56 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Oct 23, 2006, at 10:02 PM, Andrew Newton wrote: > > On Oct 23, 2006, at 9:50 PM, Henning Schulzrinne wrote: >> If we go with Brian's model, the PSAP or government agency will >> have an easily-recognized certificate, which isn't true for >> Alice's B&B. > > Given that Alice's B&B is more likely to get their cert from a > commercial CA and the government agency is more likely to get their > cert from a government CA nobody has ever heard of, I think the > opposite is actually true. The problem is not the CA, it's knowing whether the name for bobcoffeeshop (which is run by Alice's husband) has anything to do with the B&B. > >>> Wouldn't the server auth at the TLS layer prevent this? >> >> No, since the old domain name is still valid, just owned by Mr. >> Evil Twin now (say). > > And just where did Mr. Evil Twin get his hands on the private key > of that government agency? You are not describing an evil twin > attack, you are describing a key compromise. Again, I'm talking about LoST use in general, not just government agencies. Domain names routinely fall into the "wrong" hands after expiration. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 24 09:01:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcLu0-00008I-35; Tue, 24 Oct 2006 09:01:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcLsq-0007oz-Ba for ecrit@ietf.org; Tue, 24 Oct 2006 08:59:56 -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 1GcLfQ-0001j0-Kt for ecrit@ietf.org; Tue, 24 Oct 2006 08:46:08 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 24 Oct 2006 08:45:33 -0400 id 0158C154.453E0AED.0000723C In-Reply-To: <5C6B7DBD-60E7-46E6-8A1A-5E975CE11F6D@cs.columbia.edu> References: <3DBF0AB0-F34D-47FB-A72C-9E07B62D0031@cs.columbia.edu> <453CFF3F.9060504@hxr.us> <453D2732.2020207@bbn.com> <90D56712-0D17-4676-B9C7-E75D72C77C04@hxr.us> <5C6B7DBD-60E7-46E6-8A1A-5E975CE11F6D@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7EDB1FCE-DB81-4C13-B9C8-1BB9442B2437@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] LoST open issue: ttl Date: Tue, 24 Oct 2006 08:45:57 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Oct 23, 2006, at 10:09 PM, Henning Schulzrinne wrote: > The problem is not the CA, it's knowing whether the name for > bobcoffeeshop (which is run by Alice's husband) has anything to do > with the B&B. So we are displaying an X.509 distinguished names to end users now? >> >>>> Wouldn't the server auth at the TLS layer prevent this? >>> >>> No, since the old domain name is still valid, just owned by Mr. >>> Evil Twin now (say). >> >> And just where did Mr. Evil Twin get his hands on the private key >> of that government agency? You are not describing an evil twin >> attack, you are describing a key compromise. > > Again, I'm talking about LoST use in general, not just government > agencies. Domain names routinely fall into the "wrong" hands after > expiration. But private keys do not. Also, what is going on here? LoST clients are pointing at random domains? I thought there was discovery and U- NAPTR and fancy stuff in the middle there, something a domain squatter would very unlikely even have knowledge of. BTW, domain squatting is also not an evil twin attack. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 24 09:16:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcM8b-0004rQ-OT; Tue, 24 Oct 2006 09:16:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcM8a-0004rL-Me for ecrit@ietf.org; Tue, 24 Oct 2006 09:16:12 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcM8R-0008VX-My for ecrit@ietf.org; Tue, 24 Oct 2006 09:16:12 -0400 Received: from [192.168.0.41] (pool-138-89-105-49.mad.east.verizon.net [138.89.105.49]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k9ODFqjN013032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Oct 2006 09:15:58 -0400 (EDT) In-Reply-To: <7EDB1FCE-DB81-4C13-B9C8-1BB9442B2437@hxr.us> References: <3DBF0AB0-F34D-47FB-A72C-9E07B62D0031@cs.columbia.edu> <453CFF3F.9060504@hxr.us> <453D2732.2020207@bbn.com> <90D56712-0D17-4676-B9C7-E75D72C77C04@hxr.us> <5C6B7DBD-60E7-46E6-8A1A-5E975CE11F6D@cs.columbia.edu> <7EDB1FCE-DB81-4C13-B9C8-1BB9442B2437@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST open issue: ttl Date: Tue, 24 Oct 2006 09:15:41 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Oct 24, 2006, at 8:45 AM, Andrew Newton wrote: > > On Oct 23, 2006, at 10:09 PM, Henning Schulzrinne wrote: >> The problem is not the CA, it's knowing whether the name for >> bobcoffeeshop (which is run by Alice's husband) has anything to do >> with the B&B. > > So we are displaying an X.509 distinguished names to end users now? Web browsers do it today... In reality, if signing happens, I suspect we'll see some version of trait-based certificates ("I'm authorized to sign PSAP boundaries"), such as those advocated by Brian. This is somewhat easier than signing locations, say, since all the entities within a country in the end report to a single hierarchy. I'm no expert in federal PKI, but efforts like http://www.entrust.com/e_government/ federal_bridge.htm seem related. Thus, recognizing the CA itself would probably be sufficient as first approximation, even without trait-based PKI. > >>> >>>>> Wouldn't the server auth at the TLS layer prevent this? >>>> >>>> No, since the old domain name is still valid, just owned by Mr. >>>> Evil Twin now (say). >>> >>> And just where did Mr. Evil Twin get his hands on the private key >>> of that government agency? You are not describing an evil twin >>> attack, you are describing a key compromise. >> >> Again, I'm talking about LoST use in general, not just government >> agencies. Domain names routinely fall into the "wrong" hands after >> expiration. > > But private keys do not. Also, what is going on here? LoST > clients are pointing at random domains? I thought there was > discovery and U-NAPTR and fancy stuff in the middle there, > something a domain squatter would very unlikely even have knowledge > of. BTW, domain squatting is also not an evil twin attack. Very simple: You get connected (via U-NAPTR or DHCP) to a shady or compromised LoST resolver at the friendly B&B you're staying at. It presents you the nicely signed (but long expired) record of some service provider, be it for emergencies or taxi services. The domain or IP address in the URL has been acquired by Mr. Evil (or just a competitor of the original owner). This has nothing to do with typo- squatting. IP address squatting is, relatively speaking, even easier: if the original owner outgrows or abandons their hosting provider, just rent that same space. I'd rather design a system that allows us to reliably ensure information integrity from the authoritative source compared to having to backfit it, as for DNS, later, when it becomes much more difficult. I'm having a hard time seeing that 12 lines more code that are already written by somebody else should be an argument for not allowing authoritatively-signed, replay-preventing records that can be cached as a whole. This seems like a pretty low investment for future-proofing. I will note in passing that any system that implements PIDF-LO will already have a 8601 parser, since the and elements use that format. I also find it peculiar that suddenly this is an issue: 4119 only uses absolute, 8601 timestamps. I don't recall that causing heartache or even discussion before. Would you like to revise that particular choice now, too? > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 24 09:25:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcMHn-0005ES-VK; Tue, 24 Oct 2006 09:25:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcMHm-0005EG-Ts for ecrit@ietf.org; Tue, 24 Oct 2006 09:25:42 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcMHk-0002Ll-SR for ecrit@ietf.org; Tue, 24 Oct 2006 09:25:42 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 24 Oct 2006 09:25:15 -0400 id 0158C150.453E143B.00007C16 In-Reply-To: <6CBA0FC7-A137-4F5E-B7A5-06562F840B43@cs.columbia.edu> References: <3DBF0AB0-F34D-47FB-A72C-9E07B62D0031@cs.columbia.edu> <453CFF3F.9060504@hxr.us> <6CBA0FC7-A137-4F5E-B7A5-06562F840B43@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] LoST open issue: ttl Date: Tue, 24 Oct 2006 09:25:36 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Oct 23, 2006, at 10:07 PM, Henning Schulzrinne wrote: > Since we have decided on HTTP, I'd rather have a solution that is > robust even if things go boing. Just saying "since we chose > something, bad things can't happen" isn't terribly helpful. I didn't bring up HTTP. But if you want to talk about the bad things that can happen because of HTTP proxies, it would seem a stale TTL, relative or absolute, is one of the least harmful things that can happen. Far more harmful is an HTTP proxy returning a stale redirect or a stale serviceNotImplemented or stale service boundaries or stale PSAP URIs. If you believe that HTTP proxies will cause harm to TTLs, then you can not honestly make that argument and suggest that the other really bad things won't happen either. I'm all for opening up the debate on the re-use of HTTP since you are now willing to discuss it. > We have to remember that LoST can and hopefully will be used for > many applications beyond the original emergency scope. Ruling out a > reasonable security mechanism to save 10 lines of code seems like a > rather peculiar way of designing systems. I'd like to see your 10 line implementation of XML D-SIG. >> Third, to negate re-assembly, we'd also have to take boundary >> references and address validation checks out of the protocol. > > I don't see the connection for boundary references (or values), as > they are independent of the query. It doesn't matter where you are > within the polygon - the boundary is still the same. > > I agree that validation (beyond , which is used for matching > and thus is query-independent) is query-dependent. This naturally > doesn't affect geospatial queries. I think you missed the point. If an authoritative server signs a response, and a caching server removes part of that response because the client asks it to do so (re the 'include' attribute), the digital signature will not validate. So either address validation is always on, or it is to be removed from the protocol. And we must also remove service boundary references. Of course, Richard's suggestion of just signing the URI gets around that problem. But you disliked his proposal. Either way, the signed data must include something from the query (like a transaction ID or perhaps the query itself). Otherwise, an attacker can simply take a valid answer from another query and play it back. >> Finally, the specification of the absolute time is much more >> complex than relative time. Since LoST uses Relax NG, the data >> type would be the XML Schema dateTime, which is a subset of ISO >> 8601. That's already a source of interoperability problems. Add >> on top of that rules for disallowing timezone (which only cause >> greater confusion), > > Given the widespread use in other IETF schema, including systems > such as EPP that have been standardized recently, I consider that a > red herring. I don't recall seeing a last-call comment on the IETF > list protesting the inclusion of 8601 in that context, including by > yourself. Actually, the issue of date and time datatypes did come up in last call just recently with EPP... you should have read the thread much more closely. EPP itself is ready to go DS, but the reference to RFC 3339 (ISO 8601), where the date and time datatype is specified, is not. That was the central issue about the "down reference". It should also be noted that EPP does not have the notion of caching intermediaries, so the issue of time synchronization is not as relevant. But there are things we can learn from the EPP work, most notably that the PROVREG working group that created EPP explicitly did not use HTTP. They considered it, but found that they were better off without it. >> and you have two ways programmers could do the wrong thing very >> easily. From a code standpoint, this is more complex than >> relative ttl in seconds. Here is the Java code doing relative time: > > [3 lines vs. 15 lines with comments elided] > > Thanks for publishing the code, which then means nobody else has to > write it... If implementers have to rely on code posted by me to get their job done, that is proof that this is unnecessarily complex. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 24 09:28:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcMKr-0005mz-SV; Tue, 24 Oct 2006 09:28:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcMKq-0005mm-Bz for ecrit@ietf.org; Tue, 24 Oct 2006 09:28:52 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcMKm-00039b-0j for ecrit@ietf.org; Tue, 24 Oct 2006 09:28:52 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GcMKg-0006fg-0o; Tue, 24 Oct 2006 08:28:42 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] LoST open issue: ttl Date: Tue, 24 Oct 2006 09:28:42 -0400 Message-ID: <0bd801c6f770$55234350$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: Acb3bHzcyRDaCTM7QVe6iWEnMdl0+AAAqA+Q In-Reply-To: <7EDB1FCE-DB81-4C13-B9C8-1BB9442B2437@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: 244a2fd369eaf00ce6820a760a3de2e8 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Just connecting a few dots: I think normally location comes from a local access network LIS I want the location signed by the LIS I want the cert for the LIS signed by the emergency services authority CA I think normally, the sos part of the LoST service is operated by the emergency services authority I want the route signed by the LoST server I want the cert for the LoST server signed by the emergency services authority CA I want all of this happening before an emergency call. If there is a problem (like the CA of the location signature is not the CA of the LoST server signature), I want the user to be given a simple message (if you dialed the emergency dialstring, it's possible something will go wrong, please have this checked out by your carrier). We probably want a bit more sophistication to "the CA of the location signature is not the CA of the LoST signature", but you get the idea. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Tuesday, October 24, 2006 8:46 AM > To: Henning Schulzrinne > Cc: ECRIT > Subject: Re: [Ecrit] LoST open issue: ttl > > > On Oct 23, 2006, at 10:09 PM, Henning Schulzrinne wrote: > > The problem is not the CA, it's knowing whether the name for > > bobcoffeeshop (which is run by Alice's husband) has anything to do > > with the B&B. > > So we are displaying an X.509 distinguished names to end users now? > > >> > >>>> Wouldn't the server auth at the TLS layer prevent this? > >>> > >>> No, since the old domain name is still valid, just owned by Mr. > >>> Evil Twin now (say). > >> > >> And just where did Mr. Evil Twin get his hands on the private key > >> of that government agency? You are not describing an evil twin > >> attack, you are describing a key compromise. > > > > Again, I'm talking about LoST use in general, not just government > > agencies. Domain names routinely fall into the "wrong" hands after > > expiration. > > But private keys do not. Also, what is going on here? LoST clients > are pointing at random domains? I thought there was discovery and U- > NAPTR and fancy stuff in the middle there, something a domain > squatter would very unlikely even have knowledge of. BTW, domain > squatting is also not an evil twin attack. > > -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 Tue Oct 24 14:01:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcQaN-0003Be-4y; Tue, 24 Oct 2006 14:01:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcQaI-0002PO-KT for ecrit@ietf.org; Tue, 24 Oct 2006 14:01:06 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcQN2-0006S9-FF for ecrit@ietf.org; Tue, 24 Oct 2006 13:47:31 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 24 Oct 2006 10:47:24 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9OHlNqD003501; Tue, 24 Oct 2006 10:47:23 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9OHl9On025821; Tue, 24 Oct 2006 10:47:23 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 10:47:20 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 10:47:19 -0700 From: "Marc Linsner" To: "'Richard Barnes'" Subject: RE: [Ecrit] LoST open issue: ttl Date: Tue, 24 Oct 2006 13:47:19 -0400 Message-ID: <000001c6f794$73f0a8d0$5f7747ab@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acb24q13io/fPYxSSAO0Trct15LepQAsVN6A In-Reply-To: <453D2732.2020207@bbn.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 24 Oct 2006 17:47:20.0034 (UTC) FILETIME=[7404F420:01C6F794] DKIM-Signature: a=rsa-sha1; q=dns; l=560; t=1161712043; x=1162576043; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:RE=3A=20[Ecrit]=20LoST=20open=20issue=3A=20ttl; X=v=3Dcisco.com=3B=20h=3DPFtJn9P7IWsNdzsDnFUHae/Vdp8=3D; b=efKw1rwHfwJbOLCC1RGpyUXVYgmrJBS+iJEONI3t4BnFpNCWeaRj5NsWT8pIhhBlOZiB61fb EjNZAx/n/j9XVzRY93KUqCiG8lKfICh+nFs8FAw3MiaTtxq/O3LvEZik; Authentication-Results: sj-dkim-8.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Richard, > Just like DSIG arguments, the "emergency excuse" keeps coming > up on the list. Even if signatures might not be used as a > go/no-go criterion in emergency circumstances, they can > provide a measure of confidence, and they can still be useful > in other contexts. (I'm not saying they're a necessity here, > just that they shouldn't categorically be ruled out.) > What about the level of confidence in a replay attack? Would not confidence be elevated falsely? Isn't that the exact behavior attackers attempt to achieve? -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 24 14:17:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcQqB-0004we-Ts; Tue, 24 Oct 2006 14:17:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcQqB-0004wY-4m for ecrit@ietf.org; Tue, 24 Oct 2006 14:17:31 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcQq8-0004y3-TK for ecrit@ietf.org; Tue, 24 Oct 2006 14:17:31 -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 1GcQq2-0002Hg-4k; Tue, 24 Oct 2006 14:17:22 -0400 Message-Id: <6.1.0.6.2.20061024140748.0d155de0@po2.bbn.com> X-Sender: rwatro@po2.bbn.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Tue, 24 Oct 2006 14:15:37 -0400 To: "Marc Linsner" , "'Richard Barnes'" ,"'ECRIT'" From: Ron Watro Subject: RE: [Ecrit] LoST open issue: ttl In-Reply-To: <000001c6f794$73f0a8d0$5f7747ab@amer.cisco.com> References: <453D2732.2020207@bbn.com> <000001c6f794$73f0a8d0$5f7747ab@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Marc, Wouldn't timestamps and/or sequence numbers be pretty good at reducing the replay threat? Ron At 01:47 PM 10/24/2006, Marc Linsner wrote: >Richard, > > > Just like DSIG arguments, the "emergency excuse" keeps coming > > up on the list. Even if signatures might not be used as a > > go/no-go criterion in emergency circumstances, they can > > provide a measure of confidence, and they can still be useful > > in other contexts. (I'm not saying they're a necessity here, > > just that they shouldn't categorically be ruled out.) > > > >What about the level of confidence in a replay attack? Would not confidence >be elevated falsely? Isn't that the exact behavior attackers attempt to >achieve? > > >-Marc- > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 24 15:50:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcSI0-0001yY-8q; Tue, 24 Oct 2006 15:50:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcSHi-0001Xs-Sb; Tue, 24 Oct 2006 15:50:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcSHi-0002lx-Ib; Tue, 24 Oct 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 6A88626E64; Tue, 24 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GcSHi-0001QQ-8w; Tue, 24 Oct 2006 15:50:02 -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: Tue, 24 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-lost-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : LoST: A Location-to-Service Translation Protocol Author(s) : T. Hardie, et al. Filename : draft-ietf-ecrit-lost-02.txt Pages : 62 Date : 2006-10-24 This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate PSAP for emergency services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-lost-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-lost-02.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-10-24111005.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-lost-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-lost-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-24111005.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 Wed Oct 25 21:05:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GctgG-0007MT-1l; Wed, 25 Oct 2006 21:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GctgF-0007MN-CE for ecrit@ietf.org; Wed, 25 Oct 2006 21:05:11 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GctgC-0001pw-Ba for ecrit@ietf.org; Wed, 25 Oct 2006 21:05:11 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 193EB20056; Wed, 25 Oct 2006 21:05:04 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21859-09; Wed, 25 Oct 2006 21:05:03 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 7BE962004B; Wed, 25 Oct 2006 21:05:03 -0400 (EDT) To: "ECRIT list" Subject: Comments on Phone BCP (Re: [Ecrit] I-D ACTION:draft-ietf-ecrit-phonebcp-00.txt) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: peter_blatherwick@mitel.com Date: Wed, 25 Oct 2006 21:05:00 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 10/25/2006 09:05:02 PM, Serialize complete at 10/25/2006 09:05:02 PM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.2 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1896216355==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============1896216355== Content-Type: multipart/alternative; boundary="=_alternative 0005F36285257213_=" This is a multipart message in MIME format. --=_alternative 0005F36285257213_= Content-Type: text/plain; charset="us-ascii" Hi all, I've given the new Phone BCP rev a good read, and have a bunch of comments / questions. None negative, just looking to further improve the spec. I have also collected a pile of editorial type nits that I don't want to torture the whole list with, but would be happy to compile and fwd to the authors if they like (Brian, James just let me know). First though, I'm really glad to see LLDP-MED specifically a MUST location method. I certainly believe this is a very good thing, especially in managed enterprise environments. Also think it has a lot of future extension potential. Comments: o Pg 3, Introduction. The "Phone BCP" also covers aspects of network infrastructure and the overall Emergency Call Service itself, as required to support the end device. I think this needs to be more carefully stated in the Intro material, to scope the spec. If the scope cannot be easily limited, then it might be better to either break up into multiple specs (one for end device, one for access network, one for proxy ...), or intentionally pile in all requirements on all elements in the path. Personally, I hope not to need to go to either option; think the content is well targeted, however it is real important to get the right implementation people to take it seriously. A specific Scope section might help. I could try some words if you like. o Pg 3, under "As a quick overview...", 2nd bullet point, also add LLDP-MED. (DHCP and L7 mentioned only) o Sec 4 general. This reads as one big mouthful, and as such makes it hard to follow and determine what applies to what. Suggest some subsectioning would be a very helpful (albeit editorial) change. Suggest: Location Determination Methods, Location Determination Timeliness, Mapping of Location Information. o Sec 4, pg 5, 1st paragraph "Such a method MUST be specified, and every device MUST support it.", I think it would be good to strengthen this, by adding words to the effect of: "It is RECOMMENDED that at least one of the location methods specified here be used, in order to promote improved interoperability." o Sec 4, pg 5, 2nd paragraph, I think it would be helpful to tighten words: "For all other devices, the device MUST support all of: DHCP [ref], L7 [ref], and LLDP-MED [ref]." Also break off part of this paragraph about DHCP to separate paragraph (see next). o Sec 4, pg 5, after above, I think all 3 methods should have some statement of applicability and their general nature. Notably, paragraph on LLDP-MED should not characterize it as "an alternative to DHCP" -- it is not really, though it shares common data format for Civic and Geo LCI. I can try some words if others agree that applicability would be a good thing. o Sec 4, pg 5, 5th paragraph, "For devices that operate in ...". This one is unclear to me. (Thought I got it on first read ... now not so sure.) I *think* it is intended to be about deployments such as ethernet or wireless boxes behind (say) cable / DSL modem, for example residential or small office / home office. (?!?!?) I think this needs to be clarified, and state more clearly which end is receiving location from the network operator, how, and how it is relayed to the actual endpoint through one of the 3 mechanisms. o Sec 4, pg 5, 7th paragraph. Is "Self Reported" meant to mean end-user configured, or something else? It is capitalized as a Formal Term, yet not defined. Needs to be clarified. (actually, a Definitions section might help overall.) o Sec 5, pg 7, 8th paragraph, "Systems that support roaming ...". I think it would be helpful to point out "guest use" of the end device as another important scenario (eg. Alice, visiting Germany; Dieter has an issue and grabs Alice's phone, dials ... what exactly). This is orthogonal to visited network vs home, but has many of the same requirements in terms of knowing the local emergency dial string. o Sec 5, pg 8, 2nd paragraph. This does not mention the proposed DHCP method for supplying local dialstring. I seem to have lost (or is that LoST ;-) track of where this went, if anywhere. What's the state of the proposal to supply dialstring by DHCP? If it is alive, it would be worth mention here. o Sec 6.2, pg 9, item 13, re compressed codecs. Also seem to have lost track on this one. Personally, I believe compressed codecs should be in the SDP list, but as last choice. SHOULD NOT seems too strong, would personally prefer "MUST be lowest priority". At any rate, it should say non-compressed audio codec MUST be supplied, and should name one (likely G.711). Yeah, this is probably still contentious... o Sec 6.2, pg 9, paragraph after item 13, re silence suppression. I think this deserves to be a numbered item, not merely a note. Silence sup non-use is the right thing (ie MUST NOT), normative, so not a side-note. o Sec 6.2, pg 10, 1st paragraph, " ... mapping is performed whenever the UA acquires new location information that is outside the bounds of the current PSAP coverage region ...". Perhaps I'm missing something obvious here, but, HOW can the UA determine this? I would be VERY resistant to burden the end device (which must be simple and very cost-sensitive) with complex and possibly open-ended calculations to figure out PSAP bounds. I think the trigger to get new LoST PSAP URI info should be much simpler, either time based, or at every time the underlying location data changes. o Sec 6.4, pg 11, 4th paragraph, " ... 5 minutes elapses ... call may be declared dead ...". Hmmmm.... Is the 5 minutes an arbitrary SWAG (Scientific Wild-Ass Guess)? Would this requirement potentially differ depending on jurisdiction? Agree there needs to be some time limit, but this just seems arbitrary. o References, both LLDP and LLDP-MED needs corrections: [LLDP] IEEE 802.1AB-2005, Station and Media Access Control Connectivity Discovery (aka Link Layer Discovery Protocol - LLDP), May 2005. <-- Note date, capitalization "AB" and (tm) ... IEEE folks are fussy about these things. [LLDP-MED] ANSI/TIA-1057, Link Layer Discovery Protocol for Media Endpoint Devices (aka LLDP-MED), Apr 2006. ---- Hope that helps. Peter Blatherwick . Internet-Drafts@ietf.org 18.10.06 15:50 To: i-d-announce@ietf.org cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-phonebcp-00.txt 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 : Best Current Practice for Communications Services in support of Emergency Calling Author(s) : B. Rosen, J. Polk Filename : draft-ietf-ecrit-phonebcp-00.txt Pages : 16 Date : 2006-10-18 Requesting help in an emergency using a communications device such as a telephone or mobile is an accepted practice in most of the world. As communications devices increasingly utilize the Internet to interconnect and communicate, users will continue to expect to use such devices to request help, regardless of whether or not they communicate using IP. The emergency response community will have to upgrade their facilities to support the wider range of communications services, but cannot be expected to handle wide variation in device and service capability. The IETF has several efforts targeted at standardizing various aspects of placing emergency calls. This memo describes best current practice on how devices and services should use such standards to reliably make emergency calls A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-00.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-phonebcp-00.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-phonebcp-00.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. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-00.txt_______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --=_alternative 0005F36285257213_= Content-Type: text/html; charset="us-ascii"
Hi all,

I've given the new Phone BCP rev a good read, and have a bunch of comments / questions.  None negative, just looking to further improve the spec.  I have also collected a pile of editorial type nits that I don't want to torture the whole list with, but would be happy to compile and fwd to the authors if they like (Brian, James just let me know).  

First though, I'm really glad to see LLDP-MED specifically a MUST location method.  I certainly believe this is a very good thing, especially in managed enterprise environments.  Also think it has a lot of future extension potential.  

Comments:

o Pg 3, Introduction.  The "Phone BCP" also covers aspects of network infrastructure and the overall Emergency Call Service itself, as required to support the end device.  I think this needs to be more carefully stated in the Intro material, to scope the spec.  If the scope cannot be easily limited, then it might be better to either break up into multiple specs (one for end device, one for access network, one for proxy ...), or intentionally pile in all requirements on all elements in the path.  Personally, I hope not to need to go to either option; think the content is well targeted, however it is real important to get the right implementation people to take it seriously.  A specific Scope section might help.  I could try some words if you like.  

o Pg 3, under "As a quick overview...", 2nd bullet point, also add  LLDP-MED.  (DHCP and L7 mentioned only)

o Sec 4 general.  This reads as one big mouthful, and as such makes it hard to follow and determine what applies to what.  Suggest some subsectioning would be a very helpful (albeit editorial) change. Suggest: Location Determination Methods, Location Determination Timeliness, Mapping of Location Information.  

o Sec 4, pg 5, 1st paragraph "Such a method MUST be specified, and every device MUST support it.", I think it would be good to strengthen this, by adding words to the effect of: "It is RECOMMENDED that at least one of the location methods specified here be used, in order to promote improved interoperability."

o Sec 4, pg 5, 2nd paragraph, I think it would be helpful to tighten words: "For all other devices, the device MUST support all of: DHCP [ref], L7 [ref], and LLDP-MED [ref]."  Also break off part of this paragraph about DHCP to separate paragraph (see next).

o Sec 4, pg 5, after above, I think all 3 methods should have some statement of applicability and their general nature.  Notably, paragraph on LLDP-MED should not characterize it as "an alternative to DHCP" --  it is not really, though it shares common data format for Civic and Geo LCI.  I can try some words if others agree that applicability would be a good thing.    

o Sec 4, pg 5, 5th paragraph, "For devices that operate in ...".  This one is unclear to me.  (Thought I got it on first read ... now not so sure.)   I *think* it is intended to be about deployments such as ethernet or wireless boxes behind (say) cable / DSL modem, for example residential or small office / home office.  (?!?!?)  I think this needs to be clarified, and state more clearly which end is receiving location from the network operator, how, and how it is relayed to the actual endpoint through one of the 3 mechanisms.  

o Sec 4, pg 5, 7th paragraph.  Is "Self Reported" meant to mean end-user configured, or something else?  It is capitalized as a Formal Term, yet not defined.  Needs to be clarified.  (actually, a Definitions section might help overall.)

o Sec 5, pg 7, 8th paragraph, "Systems that support roaming ...".  I think it would be helpful to point out "guest use" of the end device as another important scenario (eg. Alice, visiting Germany; Dieter has an issue and grabs Alice's phone, dials ... what exactly).  This is orthogonal to visited network vs home, but  has many of the same requirements in terms of knowing the local emergency dial string.  

o Sec 5, pg 8, 2nd paragraph.  This does not mention the proposed DHCP method for supplying local dialstring.  I seem to have lost (or is that LoST ;-) track of where this went, if anywhere.  What's the state of the proposal to supply dialstring by DHCP?  If it is alive, it would be worth mention here.  

o Sec 6.2, pg 9, item 13, re compressed codecs.  Also seem to have lost track on this one.  Personally, I believe compressed codecs should be in the SDP list, but as last choice.  SHOULD NOT seems too strong, would personally prefer "MUST be lowest priority".  At any rate, it should say non-compressed audio codec MUST be supplied, and should name one (likely G.711).  Yeah, this is probably still contentious...

o Sec 6.2, pg 9, paragraph after item 13, re silence suppression.  I think this deserves to be a numbered item, not merely a note.  Silence sup non-use is the right thing (ie MUST NOT), normative, so not a side-note.  
o Sec 6.2, pg 10, 1st paragraph, " ... mapping is performed whenever the UA acquires new location information that is outside the bounds of the current PSAP coverage region ...".  Perhaps I'm missing something obvious here, but, HOW can the UA determine this?  I would be VERY resistant to burden the end device (which must be simple and very cost-sensitive) with complex and possibly open-ended calculations to figure out PSAP bounds.  I think the trigger to get new LoST PSAP URI info should be much simpler, either time based, or at every time the underlying location data changes.  

o Sec 6.4, pg 11, 4th paragraph, " ... 5 minutes elapses ... call may be declared dead ...".   Hmmmm....   Is the 5 minutes an arbitrary SWAG (Scientific Wild-Ass Guess)?  Would this requirement potentially differ depending on jurisdiction?  Agree there needs to be some time limit, but this just seems arbitrary.  

o References, both LLDP and LLDP-MED needs corrections:  
[LLDP] IEEE 802.1AB-2005, Station and Media Access Control Connectivity Discovery (aka Link Layer Discovery Protocol - LLDP), May 2005.   <-- Note date, capitalization "AB" and (tm) ... IEEE folks are fussy about these things.  
[LLDP-MED] ANSI/TIA-1057, Link Layer Discovery Protocol for Media Endpoint Devices  (aka LLDP-MED), Apr 2006.  

----

Hope that helps.  

Peter Blatherwick


.  


Internet-Drafts@ietf.org

18.10.06 15:50

       
        To:        i-d-announce@ietf.org
        cc:        ecrit@ietf.org
        Subject:        [Ecrit] I-D ACTION:draft-ietf-ecrit-phonebcp-00.txt



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                                  : Best Current Practice for Communications Services in support of Emergency Calling
                Author(s)                 : B. Rosen, J. Polk
                Filename                 : draft-ietf-ecrit-phonebcp-00.txt
                Pages                                  : 16
                Date                                  : 2006-10-18
               

  Requesting help in an emergency using a communications device such as
  a telephone or mobile is an accepted practice in most of the world.
  As communications devices increasingly utilize the Internet to
  interconnect and communicate, users will continue to expect to use
  such devices to request help, regardless of whether or not they
  communicate using IP.  The emergency response community will have to
  upgrade their facilities to support the wider range of communications
  services, but cannot be expected to handle wide variation in device
  and service capability.  The IETF has several efforts targeted at
  standardizing various aspects of placing emergency calls.  This memo
  describes best current practice on how devices and services should
  use such standards to reliably make emergency calls


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-00.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-phonebcp-00.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-phonebcp-00.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.
ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-00.txt_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

--=_alternative 0005F36285257213_=-- --===============1896216355== 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 --===============1896216355==-- From ecrit-bounces@ietf.org Thu Oct 26 16:56:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCHM-0006Rl-Iv; Thu, 26 Oct 2006 16:56:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCHK-0006RM-JB for ecrit@ietf.org; Thu, 26 Oct 2006 16:56:42 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdCH2-0002Vs-2N for ecrit@ietf.org; Thu, 26 Oct 2006 16:56:42 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1GdCCA44jp-0006ml; Thu, 26 Oct 2006 22:51:23 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Thu, 26 Oct 2006 20:42:11 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1161895331.72.0.750135139784.issue6@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de login:518a04bce8f5fdb19ebc1cc661140948 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ecrit] [issue6] Loop Detection X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: LoST Issue Tracker List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes Tschofenig added the comment: Via mechanisms introduced with draft-ietf-ecrit-lost-02.txt.=20 Issue closed. ---------- status: chatting -> done-cbb __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 26 17:03:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCNh-0007OX-Jv; Thu, 26 Oct 2006 17:03:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCBy-000294-0O for ecrit@ietf.org; Thu, 26 Oct 2006 16:51:10 -0400 Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdCAC-0008CI-CM for ecrit@ietf.org; Thu, 26 Oct 2006 16:49:57 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1GdCAB3j8M-0000ne; Thu, 26 Oct 2006 22:49:19 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Thu, 26 Oct 2006 20:40:08 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1161895208.65.0.996663206632.issue2@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de login:518a04bce8f5fdb19ebc1cc661140948 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Ecrit] [issue2] LoST Query with Composite Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: LoST Issue Tracker List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes Tschofenig added the comment: Issue of composite location "resolved" via the introduction of location=20 profiles that offer extensibility. Hence, a composite location profile can = be=20 created, if needed.=20 Issue closed with draft-ietf-ecrit-lost-02.txt. ---------- status: chatting -> done-cbb __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 26 17:10:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCUv-0002vk-LG; Thu, 26 Oct 2006 17:10:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCBP-0002G3-2K for ecrit@ietf.org; Thu, 26 Oct 2006 16:50:36 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdCAa-0008E3-HT for ecrit@ietf.org; Thu, 26 Oct 2006 16:50:17 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1GdCAZ3XVr-0006um; Thu, 26 Oct 2006 22:49:43 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Thu, 26 Oct 2006 20:40:32 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1161895232.61.0.144077309993.issue8@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de login:518a04bce8f5fdb19ebc1cc661140948 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Ecrit] [issue8] Service Numbers in LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: LoST Issue Tracker List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes Tschofenig added the comment: Issue closed with draft-ietf-ecrit-lost-02.txt. ---------- status: chatting -> done-cbb __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 26 17:19:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCdR-0000S7-Id; Thu, 26 Oct 2006 17:19:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCDt-0002CX-Am for ecrit@ietf.org; Thu, 26 Oct 2006 16:53:09 -0400 Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdC7W-0007tu-IC for ecrit@ietf.org; Thu, 26 Oct 2006 16:47:07 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1GdC7V348y-0007bU; Thu, 26 Oct 2006 22:46:33 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Thu, 26 Oct 2006 20:37:22 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1161895042.29.0.383065855541.issue11@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de login:518a04bce8f5fdb19ebc1cc661140948 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Ecrit] [issue11] Referral Protocol Mechanisms X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: LoST Issue Tracker List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes Tschofenig added the comment: Fixed in draft-ietf-ecrit-lost-02.txt. ---------- status: chatting -> done-cbb __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 26 17:25:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCje-0003wx-8l; Thu, 26 Oct 2006 17:25:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCDo-0002IG-0V for ecrit@ietf.org; Thu, 26 Oct 2006 16:53:04 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdCDK-0000Ng-Oq for ecrit@ietf.org; Thu, 26 Oct 2006 16:53:02 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1GdC8T1pLj-0000ns; Thu, 26 Oct 2006 22:47:33 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Thu, 26 Oct 2006 20:38:22 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1161895102.2.0.906212540579.issue5@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de login:518a04bce8f5fdb19ebc1cc661140948 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ecrit] [issue5] Hint about the Service Boundary X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: LoST Issue Tracker List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes Tschofenig added the comment: Fuctionality for a ServiceBoundary by reference provided in draft-ietf-ecri= t- lost-02.txt.=20 Issue closed. ---------- status: chatting -> done-cbb __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 26 17:26:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCjw-0004EA-3E; Thu, 26 Oct 2006 17:26:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCju-0004CL-Pt for ecrit@ietf.org; Thu, 26 Oct 2006 17:26:14 -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 1GdCjr-00010o-RK for ecrit@ietf.org; Thu, 26 Oct 2006 17:26:14 -0400 Received: (qmail invoked by alias); 26 Oct 2006 21:26:08 -0000 Received: from p549851A5.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.81.165] by mail.gmx.net (mp038) with SMTP; 26 Oct 2006 23:26:08 +0200 X-Authenticated: #29516787 Message-ID: <454127EE.6020203@gmx.net> Date: Thu, 26 Oct 2006 23:26:06 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Ecrit] Agenda Updates, Reading List & Co X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, I have updated the agenda. Please find it here: http://www3.ietf.org/proceedings/06nov/agenda/ecrit.txt Please make sure that the estimated time is correct and reasonable. We also need to know who is going to present. Something missing or wrong? Please read at least these ECRIT documents for the meeting: http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-lost/draft-ietf-ecrit-lost-02.txt http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-00.txt http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-mapping-arch/draft-ietf-ecrit-mapping-arch-00.txt http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-phonebcp/draft-ietf-ecrit-phonebcp-00.txt http://tools.ietf.org/wg/ecrit/draft-polk-ecrit-dhc-lost-discovery-01.txt http://tools.ietf.org/wg/ecrit/draft-polk-ecrit-local-emergency-rph-namespace-00.txt Here are the goals for the meeting: * LoST Can we resolve the remaining open issues to start a WGLC soon after the IETF meeting? * Mapping Architecture & Framework Document What needs to be done to hit our milestones? Nov 2006 An Informational document describing the Mapping Protocol Architecture Dec 2006 An Informational document describing the ECRIT Framework What are the open issues? Why haven't we addressed them already? * DHCP-based LoST Discovery The document was modified based on the mailing list comments. Are we happy with it now? WG item? * Phone BCP When is the document stable enough to solicit reviews by other SDOs? * New work for us? James published draft-polk-ecrit-local-emergency-rph-namespace-00.txt A WG item for us? What is James going todo with all the other documents? Is there other work we should be aware of? Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 26 18:05:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDLn-0004WW-GM; Thu, 26 Oct 2006 18:05:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDLF-0001UE-G1; Thu, 26 Oct 2006 18:04:49 -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 1GdD9g-0005l5-Es; Thu, 26 Oct 2006 17:52:52 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GdD9g-0004ZU-4v; Thu, 26 Oct 2006 17:52:52 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A0F1A1760A; Thu, 26 Oct 2006 19:50:09 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GdBEv-0005Mj-7s; Thu, 26 Oct 2006 15:50:09 -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, 26 Oct 2006 15:50:09 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-framework-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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 : Framework for Emergency Calling in Internet Multimedia Author(s) : B. Rosen, et al. Filename : draft-ietf-ecrit-framework-00.txt Pages : 31 Date : 2006-10-26 Summoning emergency help by the public is a core feature of telephone networks. This document describes a framework of how various IETF protocols and mechanisms are combined to place emergency calls. This includes how these calls are routed to the correct Public Safety Answering Point (PSAP) based on the physical location of the caller, while providing the call taker the necessary information to dispatch a first responder to that location. This document explains how location mapping, call identification and end system behavior are combined to allow multimedia emergency calls. It describes at a high level how the pieces (recognizing a call as an emergency call, marking it as such, determining the location of the caller, routing the call based on location) go together, and references the Internet standards that define the details of these mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-00.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-framework-00.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-framework-00.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-10-26140824.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-26140824.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 Oct 26 18:21:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDbE-0002CL-Vd; Thu, 26 Oct 2006 18:21:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDah-0001gR-Vn for ecrit@ietf.org; Thu, 26 Oct 2006 18:20:47 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdDQh-0000mr-Nr for ecrit@ietf.org; Thu, 26 Oct 2006 18:10:29 -0400 Received: from lion.cs.columbia.edu (IDENT:V4847MP8VjGK3cw0amf/mzFFcs8VOpLK@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k9QM9a6G022752 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 26 Oct 2006 18:10:24 -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 k9QKuUg7027439 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 26 Oct 2006 16:56:30 -0400 Message-ID: <454120F9.50402@cs.columbia.edu> Date: Thu, 26 Oct 2006 16:56:25 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter2.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Ecrit] Changes in LoST -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 Changes: - each request now has its own response; - rewrite of introduction and, to a lesser extent, other sections for continuity and to remove redundancy; - location profiles to describe allowable location types; - ServiceBoundary by reference, not just by value; - include mechanism, to allow clients to specify which information they want the server to return; - , , indicate which pieces of civic address data have been checked, are invalid and have not been checked, respectively; Open issues: - syntax for error responses (the proposal in the draft has known problems); - expiration time - absolute or relative; - handling of 'include' (specifies minimum set vs. strict set) - this primarily affects the cacheability of responses Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 26 19:35:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdEl0-0000k9-2z; Thu, 26 Oct 2006 19:35:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdEkx-0000k4-0Q for ecrit@ietf.org; Thu, 26 Oct 2006 19:35:27 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdEkv-0007hT-JD for ecrit@ietf.org; Thu, 26 Oct 2006 19:35:26 -0400 Received: from [192.168.0.105] ([::ffff:64.102.254.33]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Thu, 26 Oct 2006 19:35:22 -0400 id 015880C2.4541463A.0000029B Message-ID: <45414636.5030502@thinkingcat.com> Date: Thu, 26 Oct 2006 19:35:18 -0400 From: Leslie Daigle User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Hannes Tschofenig References: <450B1F68.10402@gmx.net> <450B3944.6070507@thinkingcat.com> In-Reply-To: <450B3944.6070507@thinkingcat.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: ECRIT Subject: [Ecrit] Re: ECRIT (LoST) and draft-daigle-unaptr-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org FYI, I did submit the revised version of the U-NAPTR document. I believe this version is "done" and submittable to the IESG, but I suspect I should wait until the end of the San Diego meeting before passing it to the IESG (so people have time to comment), if that's okay within your timelines. The technical detail is not particularly different than the -00 version; this version chiefly clarifies that U-NAPTR is a new DDDS application with massive dependencies on S-NAPTR (and fixes the bugs in the example that Martin Thomson was kind enough to point out ;-) ). Leslie. -------- Original Message -------- Subject: I-D ACTION:draft-daigle-unaptr-01.txt Date: Mon, 23 Oct 2006 18:50:01 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Domain-based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS) Author(s) : L. Daigle Filename : draft-daigle-unaptr-01.txt Pages : 11 Date : 2006-10-23 The purpose of this document is to define a new, straightforward Dynamic Delegation Discovery Service (DDDS) application to allow mapping of domain names to URIs for particular application services and protocols. Although defined as a new DDDS application, dubbed U-NAPTR, this is effectively an extension of the Straightforward NAPTR (S-NAPTR) DDDS application. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-daigle-unaptr-01.txt [snip] Leslie Daigle wrote: > > Hi Hannes, > > I don't think there would be a real problem for me to finish > U-NAPTR in that timeframe (i.e., to the IESG by San Diego). > > I was primarily waiting for input (from various interested > parties, not just the ECRIT WG) on the question of whether > to write it as an update of S-NAPTR or a completely new DDDS > application. I believe I have a reasonable fallback plan > for how to handle that, if I get no further comments. > > Thanks, > Leslie. > > Hannes Tschofenig wrote: >> Hi Leslie, >> >> the ECRIT working group is working on an XML-based protocol for >> mapping service identifiers and geospatial or civic location >> information to service contact URIs. You can find the document at: >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-01.txt >> >> Based on your review of the Service URN draft >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-05.txt >> we have moved the DNS-based LoST discovery procedure to the LoST >> protocol draft. The described solution builds on your document >> http://www.ietf.org/internet-drafts/draft-daigle-unaptr-00.txt >> >> Here is the problem: We normatively depend on your document. The ECRIT >> milestones indicate that we need to finish the work on the mapping >> protocol by November 2006. >> >> Hence, we would like to ask you to accelerate your work on >> draft-daigle-unaptr-00.txt. When can you finish the document? >> >> If you cannot finish it very soon then we need to start thinking about >> a different solution. >> >> Ciao >> Hannes & Marc >> > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 27 02:07:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdKrr-0001kx-OR; Fri, 27 Oct 2006 02:06:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdKrq-0001ki-KW for ecrit@ietf.org; Fri, 27 Oct 2006 02:06:58 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdKro-00015s-BZ for ecrit@ietf.org; Fri, 27 Oct 2006 02:06:58 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 26 Oct 2006 23:06:56 -0700 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9R66uUS022043 for ; Fri, 27 Oct 2006 02:06:56 -0400 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 k9R66uDM015333 for ; Fri, 27 Oct 2006 02:06:56 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 02:06:56 -0400 Received: from jmpolk-wxp.cisco.com ([10.82.224.94]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 02:06:55 -0400 Message-Id: <4.3.2.7.2.20061027005140.036ca2e8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 27 Oct 2006 01:06:54 -0500 To: "'ecrit@ietf.org'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Oct 2006 06:06:55.0629 (UTC) FILETIME=[1AC2E3D0:01C6F98E] DKIM-Signature: a=rsa-sha1; q=dns; l=1526; t=1161929216; x=1162793216; c=relaxed/simple; s=rtpdkim1001; 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:New=20ID=20for=20SIP=20RPH=20namespace=20for=20ECRIT=20type=20calling |To:=22'ecrit@ietf.org'=22=20; X=v=3Dcisco.com=3B=20h=3DJID9yCvaVZbmbUo7qkhDahpJK/A=3D; b=N5ypMBhVvfazuZXYd8Irpk84ARi9RocjwVDkouJpH2BqgYqE0LGOYYe+clVz1Fl9founYjDT fjmg+czz9Ftpd0H2k1KAf2fzPsHZdQ+VHOmVByqi/+a6Q+XTWot8xrNr; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Ecrit] New ID for SIP RPH namespace for ECRIT type calling X-BeenThere: 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 ECRIT WG I've written a new ID to create a SIP Resource-Priority header namespace to be used during emergency calling. Right now, I am calling this namespace "Fred&Barney" to get folks attention, but the ID calls out several alternatives to replace this otherwise excellent namespace string. The URL for this ID is here: http://www.ietf.org/internet-drafts/draft-polk-ecrit-local-emergency-rph-namespace-00.txt Brian and I have talked for more than 2 years about doing this, and with a few minutes of spare time before the -00 deadline, I thought I'd start the ball rolling by calling out several alternative strings to use as the namespace, and some early rules around its usage - as one never knows how long it will take to get an RPH namespace to RFC status.... (sigh) I have the number of relative priority levels at 5 at the moment, because I believe (but can be talked out of) this namespace being used not only for public caller-to-PSAP, but also PSAP-to-PSAP and PSAP-to-first_responder (individual or dispatcher). This may be differentiated with different priority levels rather than different namespaces (thus creating at least 3 for ~ each country jurisdiction). I think if we can get this into one namespace, it scales better and interoperates better. (i.e we don't want too many namespaces because RFC 4412 states unknown namespaces mean the header is ignored or errored - which might also be an undesireable event) Comments are appreciated Thanks James _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 27 09:07:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdRQa-0006aQ-Ok; Fri, 27 Oct 2006 09:07:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdRQZ-0006O4-Gi for ecrit@ietf.org; Fri, 27 Oct 2006 09:07:15 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdRQX-0000eb-6x for ecrit@ietf.org; Fri, 27 Oct 2006 09:07:15 -0400 Received: from [192.168.0.41] (pool-138-89-105-49.mad.east.verizon.net [138.89.105.49]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k9RD78qM020768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 27 Oct 2006 09:07:11 -0400 (EDT) In-Reply-To: <4.3.2.7.2.20061027005140.036ca2e8@email.cisco.com> References: <4.3.2.7.2.20061027005140.036ca2e8@email.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] New ID for SIP RPH namespace for ECRIT type calling Date: Fri, 27 Oct 2006 09:06:52 -0400 To: "James M. Polk" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Rather than focusing on labels and names, or how many there should be, there is a much more fundamental question, namely whether this is needed at all. I'm concerned that the approach as proposed is potentially a security risk and has a semantics problem. For citizen-to-authority calls, calls must already be recognizable and routed towards the PSAP. Thus, proxies that recognize such calls can provide them with appropriate signaling treatment, including but not limited to priority, based on that information. (Otherwise, attackers would simply label every call to their friends as having this priority, given that we can't require authentication for emergency calls.) For authority-to-authority calls, it seems that there is significant overlap with the ETS namespace. Even ignoring these issues, I'm unconvinced that packing these unrelated calls into one ordered namespace makes sense. After all, there is no inherent reason why authority-to-civilian calls, say, should have higher (or lower) priority than the converse. Namespaces need to have a consistent priority order across jurisdictions to be meaningful; you can't have "priority 5" be more urgent than "priority 4" in one jurisdiction and the opposite in another. Henning On Oct 27, 2006, at 2:06 AM, James M. Polk wrote: > ECRIT WG > > I've written a new ID to create a SIP Resource-Priority header > namespace to be used during emergency calling. Right now, I am > calling this namespace "Fred&Barney" to get folks attention, but > the ID calls out several alternatives to replace this otherwise > excellent namespace string. > > The URL for this ID is here: > > http://www.ietf.org/internet-drafts/draft-polk-ecrit-local- > emergency-rph-namespace-00.txt > > Brian and I have talked for more than 2 years about doing this, and > with a few minutes of spare time before the -00 deadline, I thought > I'd start the ball rolling by calling out several alternative > strings to use as the namespace, and some early rules around its > usage - as one never knows how long it will take to get an RPH > namespace to RFC status.... (sigh) > > I have the number of relative priority levels at 5 at the moment, > because I believe (but can be talked out of) this namespace being > used not only for public caller-to-PSAP, but also PSAP-to-PSAP and > PSAP-to-first_responder (individual or dispatcher). This may be > differentiated with different priority levels rather than different > namespaces (thus creating at least 3 for ~ each country > jurisdiction). I think if we can get this into one namespace, it > scales better and interoperates better. > > (i.e we don't want too many namespaces because RFC 4412 states > unknown namespaces mean the header is ignored or errored - which > might also be an undesireable event) > > Comments are appreciated > > Thanks > James > > _______________________________________________ > 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 Oct 27 09:29:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdRld-0001WK-A6; Fri, 27 Oct 2006 09:29:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdRlc-0001WA-9b for ecrit@ietf.org; Fri, 27 Oct 2006 09:29:00 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdRlX-0003SM-G4 for ecrit@ietf.org; Fri, 27 Oct 2006 09:29:00 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GdRlR-0006qS-Dt; Fri, 27 Oct 2006 08:28:49 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'James M. Polk'" Subject: RE: [Ecrit] New ID for SIP RPH namespace for ECRIT type calling Date: Fri, 27 Oct 2006 09:28:50 -0400 Message-ID: <064101c6f9cb$d9007140$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: Acb5yNnUzxccDDSESrSXDJ4gNELLxgAAi4uw 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: a87a9cdae4ac5d3fbeee75cd0026d632 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 there is value to the namespace. For one thing, it does exactly what we want: specify a resource priority for a call. While the marking method tells a proxy that the call is a 9-1-1 call, it's not clear that we should be using what is in a Route Header to affect the resource priority of that call. I think the authority to authority use is a little less compelling. I think those calls will use a MLLP like priority/preemption scheme, and I don't know why the existing RPH namespaces aren't good enough. However, there is the call back (authority to citizen). In many cases, it is appropriate to have some resource priority for those calls. I do share some of Henning's concerns about whether ordered priority has any place in this namespace. I'm not sure that it does, but I want to think about that. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, October 27, 2006 9:07 AM > To: James M. Polk > Cc: 'ecrit@ietf.org' > Subject: Re: [Ecrit] New ID for SIP RPH namespace for ECRIT type calling > > Rather than focusing on labels and names, or how many there should > be, there is a much more fundamental question, namely whether this is > needed at all. I'm concerned that the approach as proposed is > potentially a security risk and has a semantics problem. > > For citizen-to-authority calls, calls must already be recognizable > and routed towards the PSAP. Thus, proxies that recognize such calls > can provide them with appropriate signaling treatment, including but > not limited to priority, based on that information. (Otherwise, > attackers would simply label every call to their friends as having > this priority, given that we can't require authentication for > emergency calls.) > > For authority-to-authority calls, it seems that there is significant > overlap with the ETS namespace. > > Even ignoring these issues, I'm unconvinced that packing these > unrelated calls into one ordered namespace makes sense. After all, > there is no inherent reason why authority-to-civilian calls, say, > should have higher (or lower) priority than the converse. Namespaces > need to have a consistent priority order across jurisdictions to be > meaningful; you can't have "priority 5" be more urgent than "priority > 4" in one jurisdiction and the opposite in another. > > Henning > > On Oct 27, 2006, at 2:06 AM, James M. Polk wrote: > > > ECRIT WG > > > > I've written a new ID to create a SIP Resource-Priority header > > namespace to be used during emergency calling. Right now, I am > > calling this namespace "Fred&Barney" to get folks attention, but > > the ID calls out several alternatives to replace this otherwise > > excellent namespace string. > > > > The URL for this ID is here: > > > > http://www.ietf.org/internet-drafts/draft-polk-ecrit-local- > > emergency-rph-namespace-00.txt > > > > Brian and I have talked for more than 2 years about doing this, and > > with a few minutes of spare time before the -00 deadline, I thought > > I'd start the ball rolling by calling out several alternative > > strings to use as the namespace, and some early rules around its > > usage - as one never knows how long it will take to get an RPH > > namespace to RFC status.... (sigh) > > > > I have the number of relative priority levels at 5 at the moment, > > because I believe (but can be talked out of) this namespace being > > used not only for public caller-to-PSAP, but also PSAP-to-PSAP and > > PSAP-to-first_responder (individual or dispatcher). This may be > > differentiated with different priority levels rather than different > > namespaces (thus creating at least 3 for ~ each country > > jurisdiction). I think if we can get this into one namespace, it > > scales better and interoperates better. > > > > (i.e we don't want too many namespaces because RFC 4412 states > > unknown namespaces mean the header is ignored or errored - which > > might also be an undesireable event) > > > > Comments are appreciated > > > > Thanks > > James > > > > _______________________________________________ > > 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 Oct 27 10:56:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdT8T-0001mf-VD; Fri, 27 Oct 2006 10:56:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdT8R-0001mP-R9 for ecrit@ietf.org; Fri, 27 Oct 2006 10:56:39 -0400 Received: from ober.cs.columbia.edu ([128.59.18.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdT8O-00084i-LW for ecrit@ietf.org; Fri, 27 Oct 2006 10:56:39 -0400 Received: from lion.cs.columbia.edu (IDENT:Fq2WHt+nh6JDZoCG2acPk3r7PBAX9TcN@lion.cs.columbia.edu [128.59.16.120]) by ober.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k9REq605010881 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 27 Oct 2006 10:56:26 -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 k9REmkg7014726 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Oct 2006 10:48:47 -0400 Message-ID: <45421C49.70509@cs.columbia.edu> Date: Fri, 27 Oct 2006 10:48:41 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] New ID for SIP RPH namespace for ECRIT type calling References: <064101c6f9cb$d9007140$640fa8c0@cis.neustar.com> In-Reply-To: <064101c6f9cb$d9007140$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%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: > I think there is value to the namespace. > > For one thing, it does exactly what we want: specify a resource priority for > a call. While the marking method tells a proxy that the call is a 9-1-1 > call, it's not clear that we should be using what is in a Route Header to > affect the resource priority of that call. > Just so that we don't talk past each other: We wouldn't be using Route to indicate an emergency call; that's indicated by the request URI and/or To header. If all citizen-to-authority emergency calls should get priority, we're essentially saying the same thing twice, which means we now have to decide what happens for calls that - only indicate that this is an emergency call - only indicate some kind of RP - do both, but use the "wrong" RP value (e.g., use the authority-authority code) Three new cases, no net gain. Also, you haven't addressed my main concern, namely that a RP indication without a strong tie to PSAP routing is a rather large security hole. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 27 11:33:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdTi8-00005d-8G; Fri, 27 Oct 2006 11:33:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdTi7-0008Ul-EU for ecrit@ietf.org; Fri, 27 Oct 2006 11:33:31 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdTi4-0006Q1-41 for ecrit@ietf.org; Fri, 27 Oct 2006 11:33:31 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GdThx-0006qF-Ct; Fri, 27 Oct 2006 10:33:21 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] New ID for SIP RPH namespace for ECRIT type calling Date: Fri, 27 Oct 2006 11:33:23 -0400 Message-ID: <066401c6f9dd$3f2ab550$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: Acb52BXD1a1gs63jSfuDPULDF+6tBgAAyRwQ In-Reply-To: <45421C49.70509@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: 4b800b1eab964a31702fa68f1ff0e955 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 so that we don't talk past each other: We wouldn't be using Route > to indicate an emergency call; that's indicated by the request URI > and/or To header. Well, there is Jonathan's proposal, but even if there wasn't, I thought the service URN has to go in Route because after LoST mapping it wouldn't be in Request URI. Take the case of the proxy doing dialstring interpretation, and just for fun, make it not the one that does LoST. UA: INVITE sip:911;phone-context=atlanta.example.com@example.com;user=dialstring To: sip:911;phone-context=atlanta.example.com@example.com;user=dialstring First Proxy INVITE sip:urn:service:sos To: sip:911;phone-context=atlanta.example.com@example.com;user=dialstring Second Proxy INVITE sip:psap@esrp.pa.us To: sip:911;phone-context=atlanta.example.com@example.com;user=dialstring No service URN. I had thought the messages were: First Proxy INVITE sip:urn:service:sos To: sip:911;phone-context=atlanta.example.com@example.com;user=dialstring Route: sip:urn:service:sos;lr Second Proxy INVITE sip:psap@esrp.pa.us To: sip:911;phone-context=atlanta.example.com@example.com;user=dialstring Route: sip:urn:service:sos;lr > > If all citizen-to-authority emergency calls should get priority, we're > essentially saying the same thing twice, which means we now have to > decide what happens for calls that > > - only indicate that this is an emergency call > - only indicate some kind of RP > - do both, but use the "wrong" RP value (e.g., use the > authority-authority code) > > Three new cases, no net gain. I would say that the presence of a service URN is not a request for resource priority, but is only used for route determination. As I said, I'm not sure there is a need for an ordered priority in this namespace, but if there is, the same problems you would have with use of RPH in any circumstances apply. No new problems > > Also, you haven't addressed my main concern, namely that a RP indication > without a strong tie to PSAP routing is a rather large security hole. RPH in general has that issue. Of course, the same is true of using the service URN. Ignoring for a moment, my argument above: UA: INVITE sip:myfriend@example.com To: sip:urn:service:sos Is exactly the problem you are describing, right? What defenses do we have against this? I think the only thing you could do is to verify that for the location in the Geolocation header, the RequestURI was the LoST response. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 27 12:16:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUNX-0006Ej-Kb; Fri, 27 Oct 2006 12:16:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUNW-0006Ec-QQ for ecrit@ietf.org; Fri, 27 Oct 2006 12:16:18 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176] helo=sea-mimesweep-1.telecomsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdUNQ-0006KM-Cy for ecrit@ietf.org; Fri, 27 Oct 2006 12:16:18 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.5) with ESMTP id ; Fri, 27 Oct 2006 09:16: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] New ID for SIP RPH namespace for ECRIT type calling Date: Fri, 27 Oct 2006 09:16:11 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657506174808@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] New ID for SIP RPH namespace for ECRIT type calling Thread-Index: Acb52BXD1a1gs63jSfuDPULDF+6tBgAAyRwQAAFEFKA= From: "Roger Marshall" To: "Brian Rosen" , "Henning Schulzrinne" 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 >First Proxy >INVITE sip:urn:service:sos >To:=20 >sip:911;phone-context=3Datlanta.example.com@example.com;user=3Ddialstring > >Second Proxy >INVITE sip:psap@esrp.pa.us >To:=20 >sip:911;phone-context=3Datlanta.example.com@example.com;user=3Ddialstring This doesn't make sense to me. How does the First Proxy know to get to the Second Proxy? Are you showing that the service identifier, urn:service:sos, is "hard-coded" within the 1st Proxy ("911"-->"urn:service:sos"=3D=3DIP_addr_Proxy2)? I don't think this would work too well.=20 >I would say that the presence of a service URN is not a=20 >request for resource priority, but is only used for route=20 >determination.=20 What happened to using the service identifier for emergency marking? Emergency marking doesn't have to do with route determination, (unless it is inappropriately used to hard-coded a route). Route determination is equated to a LoST query.=20 Roger Marshall. >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net]=20 >Sent: Friday, October 27, 2006 8:33 AM >To: 'Henning Schulzrinne' >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] New ID for SIP RPH namespace for ECRIT=20 >type calling > >> Just so that we don't talk past each other: We wouldn't be=20 >using Route=20 >> to indicate an emergency call; that's indicated by the request URI=20 >> and/or To header. >Well, there is Jonathan's proposal, but even if there wasn't,=20 >I thought the service URN has to go in Route because after=20 >LoST mapping it wouldn't be in Request URI. > >Take the case of the proxy doing dialstring interpretation,=20 >and just for fun, make it not the one that does LoST. > >UA: >INVITE=20 >sip:911;phone-context=3Datlanta.example.com@example.com;user=3Ddialstring >To:=20 >sip:911;phone-context=3Datlanta.example.com@example.com;user=3Ddialstring > >First Proxy >INVITE sip:urn:service:sos >To:=20 >sip:911;phone-context=3Datlanta.example.com@example.com;user=3Ddialstring > >Second Proxy >INVITE sip:psap@esrp.pa.us >To:=20 >sip:911;phone-context=3Datlanta.example.com@example.com;user=3Ddialstring > >No service URN. I had thought the messages were: >First Proxy >INVITE sip:urn:service:sos >To:=20 >sip:911;phone-context=3Datlanta.example.com@example.com;user=3Ddialstring >Route: sip:urn:service:sos;lr > >Second Proxy >INVITE sip:psap@esrp.pa.us >To:=20 >sip:911;phone-context=3Datlanta.example.com@example.com;user=3Ddialstring >Route: sip:urn:service:sos;lr > > >>=20 >> If all citizen-to-authority emergency calls should get=20 >priority, we're=20 >> essentially saying the same thing twice, which means we now have to=20 >> decide what happens for calls that >>=20 >> - only indicate that this is an emergency call >> - only indicate some kind of RP >> - do both, but use the "wrong" RP value (e.g., use the=20 >> authority-authority code) >>=20 >> Three new cases, no net gain. >I would say that the presence of a service URN is not a=20 >request for resource priority, but is only used for route=20 >determination.=20 > >As I said, I'm not sure there is a need for an ordered=20 >priority in this namespace, but if there is, the same problems=20 >you would have with use of RPH >in any circumstances apply. No new problems > >>=20 >> Also, you haven't addressed my main concern, namely that a RP=20 >> indication without a strong tie to PSAP routing is a rather=20 >large security hole. >RPH in general has that issue.=20 > >Of course, the same is true of using the service URN. =20 >Ignoring for a moment, my argument above: > >UA: >INVITE sip:myfriend@example.com >To: sip:urn:service:sos > >Is exactly the problem you are describing, right? What=20 >defenses do we have against this? I think the only thing you=20 >could do is to verify that for the location in the Geolocation=20 >header, the RequestURI was the LoST response. > >Brian > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > The information contained in this message may be privileged and/or confiden= tial. If you are not the intended recipient, or responsible for delivering = this message to the intended recipient, any review, forwarding, disseminati= on, distribution or copying of this communication or any attachment(s) is s= trictly prohibited. If you have received this message in error, please so n= otify the sender immediately, and delete it and all attachments from your c= omputer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 27 12:42:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUmd-0001kg-LP; Fri, 27 Oct 2006 12:42:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUmc-0001kb-EP for ecrit@ietf.org; Fri, 27 Oct 2006 12:42:14 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdUmX-00020R-Ue for ecrit@ietf.org; Fri, 27 Oct 2006 12:42:14 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GdUmQ-0003lQ-Bk; Fri, 27 Oct 2006 11:42:02 -0500 From: "Brian Rosen" To: "'Roger Marshall'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] New ID for SIP RPH namespace for ECRIT type calling Date: Fri, 27 Oct 2006 12:42:05 -0400 Message-ID: <068001c6f9e6$d7c42c70$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: Acb52BXD1a1gs63jSfuDPULDF+6tBgAAyRwQAAFEFKAAAVAkkA== In-Reply-To: <8C837214C95C864C9F34F3635C2A657506174808@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: 1449ead51a2ff026dcb23465f5379250 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 first proxy has a hard coded route to the second proxy. The first proxy is the P-CSCF, the second proxy is the E-CSCF in IMS terms. All emergency calls are routed to the second proxy and it does all the work. That's a pretty reasonable mechanism; it's what the Packet Cable 2.0 spec says, for instance. It's not unlike how a lot of systems work for gateways, the first hop outbound proxy determines if it needs to route to a gateway, but all gateway calls are passed to another proxy whose job is to pick the right gateway to get the call. It's a pretty simple mechanism, albeit it needs a provisioning step. Of course, you can combine the two proxies into one proxy, and the result would have the problem I showed: without a Route header containing the service urn, the message would no longer have a marking. Actually, I do think the marking is all about routing. It tells you that this call is routed as an emergency call. When in a Route header, it's exactly right: your destination is the UA handling the urn:service:sos URI, Although there may be a number of intermediaries in the path (ESRPs for example). Brian > -----Original Message----- > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > Sent: Friday, October 27, 2006 12:16 PM > To: Brian Rosen; Henning Schulzrinne > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] New ID for SIP RPH namespace for ECRIT type calling > > > >First Proxy > >INVITE sip:urn:service:sos > >To: > >sip:911;phone-context=atlanta.example.com@example.com;user=dialstring > > > >Second Proxy > >INVITE sip:psap@esrp.pa.us > >To: > >sip:911;phone-context=atlanta.example.com@example.com;user=dialstring > > This doesn't make sense to me. How does the First Proxy know to get to > the Second Proxy? Are you showing that the service identifier, > urn:service:sos, is "hard-coded" within the 1st Proxy > ("911"-->"urn:service:sos"==IP_addr_Proxy2)? > > I don't think this would work too well. > > > >I would say that the presence of a service URN is not a > >request for resource priority, but is only used for route > >determination. > > What happened to using the service identifier for emergency marking? > Emergency marking doesn't have to do with route determination, (unless > it is inappropriately used to hard-coded a route). Route determination > is equated to a LoST query. > > > Roger Marshall. > > >-----Original Message----- > >From: Brian Rosen [mailto:br@brianrosen.net] > >Sent: Friday, October 27, 2006 8:33 AM > >To: 'Henning Schulzrinne' > >Cc: ecrit@ietf.org > >Subject: RE: [Ecrit] New ID for SIP RPH namespace for ECRIT > >type calling > > > >> Just so that we don't talk past each other: We wouldn't be > >using Route > >> to indicate an emergency call; that's indicated by the request URI > >> and/or To header. > >Well, there is Jonathan's proposal, but even if there wasn't, > >I thought the service URN has to go in Route because after > >LoST mapping it wouldn't be in Request URI. > > > >Take the case of the proxy doing dialstring interpretation, > >and just for fun, make it not the one that does LoST. > > > >UA: > >INVITE > >sip:911;phone-context=atlanta.example.com@example.com;user=dialstring > >To: > >sip:911;phone-context=atlanta.example.com@example.com;user=dialstring > > > >First Proxy > >INVITE sip:urn:service:sos > >To: > >sip:911;phone-context=atlanta.example.com@example.com;user=dialstring > > > >Second Proxy > >INVITE sip:psap@esrp.pa.us > >To: > >sip:911;phone-context=atlanta.example.com@example.com;user=dialstring > > > >No service URN. I had thought the messages were: > >First Proxy > >INVITE sip:urn:service:sos > >To: > >sip:911;phone-context=atlanta.example.com@example.com;user=dialstring > >Route: sip:urn:service:sos;lr > > > >Second Proxy > >INVITE sip:psap@esrp.pa.us > >To: > >sip:911;phone-context=atlanta.example.com@example.com;user=dialstring > >Route: sip:urn:service:sos;lr > > > > > >> > >> If all citizen-to-authority emergency calls should get > >priority, we're > >> essentially saying the same thing twice, which means we now have to > >> decide what happens for calls that > >> > >> - only indicate that this is an emergency call > >> - only indicate some kind of RP > >> - do both, but use the "wrong" RP value (e.g., use the > >> authority-authority code) > >> > >> Three new cases, no net gain. > >I would say that the presence of a service URN is not a > >request for resource priority, but is only used for route > >determination. > > > >As I said, I'm not sure there is a need for an ordered > >priority in this namespace, but if there is, the same problems > >you would have with use of RPH > >in any circumstances apply. No new problems > > > >> > >> Also, you haven't addressed my main concern, namely that a RP > >> indication without a strong tie to PSAP routing is a rather > >large security hole. > >RPH in general has that issue. > > > >Of course, the same is true of using the service URN. > >Ignoring for a moment, my argument above: > > > >UA: > >INVITE sip:myfriend@example.com > >To: sip:urn:service:sos > > > >Is exactly the problem you are describing, right? What > >defenses do we have against this? I think the only thing you > >could do is to verify that for the location in the Geolocation > >header, the RequestURI was the LoST response. > > > >Brian > > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit > > > > > The information contained in this message may be privileged and/or > confidential. If you are not the intended recipient, or responsible for > delivering this message to the intended recipient, any review, forwarding, > dissemination, distribution or copying of this communication or any > attachment(s) is strictly prohibited. If you have received this message in > error, please so notify the sender immediately, and delete it and all > attachments from your computer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 27 13:44:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdVkQ-0001hb-2V; Fri, 27 Oct 2006 13:44:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdVkP-0001hT-FH for ecrit@ietf.org; Fri, 27 Oct 2006 13:44:01 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdVkO-0003Mo-6a for ecrit@ietf.org; Fri, 27 Oct 2006 13:44:01 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2006 10:44:00 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9RHhxZg005118 for ; Fri, 27 Oct 2006 10:43:59 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9RHhxOV012241 for ; Fri, 27 Oct 2006 10:43:59 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 10:43:59 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.144.112]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 10:43:58 -0700 Message-Id: <4.3.2.7.2.20061027124138.03c72978@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 27 Oct 2006 12:43:57 -0500 To: "'ecrit@ietf.org'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Oct 2006 17:43:59.0057 (UTC) FILETIME=[7B778C10:01C6F9EF] DKIM-Signature: a=rsa-sha1; q=dns; l=136; t=1161971039; x=1162835039; c=relaxed/simple; s=sjdkim5002; 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:LoST=20-02=20and=20error=20handling; X=v=3Dcisco.com=3B=20h=3D1g1prOzGAmLLR8mvgUEeQmUfph4=3D; b=Sq7Qf0mWvlkSMFXmKoapuEOAOvTD8yufTfj3+/q6bA0FeTvjc/FjfSOkURraNh/O42+I/cUc 0hmQtqTItYLzklwG73Q8SIbdlvrUC7vqtJyhAdeviZzt6xLsFox8xzFb; Authentication-Results: sj-dkim-5.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Ecrit] LoST -02 and error handling X-BeenThere: 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 Authors of LoST -02 Please remind me again why were the -01 error codes removed (for a single word text string)? Thanks James _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 27 14:06:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdW6R-00067M-5b; Fri, 27 Oct 2006 14:06:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdW6P-00067H-OJ for ecrit@ietf.org; Fri, 27 Oct 2006 14:06:45 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdW6M-0006rk-Hi for ecrit@ietf.org; Fri, 27 Oct 2006 14:06:45 -0400 Received: from [172.16.10.86] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Fri, 27 Oct 2006 14:06:41 -0400 id 015880F0.45424AB1.00001159 Message-ID: <45424AA7.7040608@hxr.us> Date: Fri, 27 Oct 2006 14:06:31 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ecrit] LoST -02 and error handling References: <4.3.2.7.2.20061027124138.03c72978@email.cisco.com> In-Reply-To: <4.3.2.7.2.20061027124138.03c72978@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 James M. Polk wrote: > Please remind me again why were the -01 error codes removed (for a > single word text string)? Single word text string? You mean that stuff we call XML? We moved away from the error numbers because certain errors required certain syntax, which meant we were no longer defining this XML based protocol with an XML based schema language. Additionally, some of them were not mutually exclusive. Within the author team, we are looking to overhaul it once more because we believe that the current way is still confusing, and we have discussed a simpler, more concise idea. But we are not looking at going back to error numbers. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 27 14:30:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdWTA-00030G-2g; Fri, 27 Oct 2006 14:30:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdWRq-0002FR-9V for ecrit@ietf.org; Fri, 27 Oct 2006 14:28:54 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdWNG-0002W4-0W for ecrit@ietf.org; Fri, 27 Oct 2006 14:24:15 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2006 11:24:10 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9RIO9a1001978; Fri, 27 Oct 2006 11:24:09 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9RIO9OV003323; Fri, 27 Oct 2006 11:24:09 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 11:24:09 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.144.112]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 11:24:08 -0700 Message-Id: <4.3.2.7.2.20061027131608.02ed9008@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 27 Oct 2006 13:24:08 -0500 To: Andrew Newton From: "James M. Polk" Subject: Re: [Ecrit] LoST -02 and error handling In-Reply-To: <45424AA7.7040608@hxr.us> References: <4.3.2.7.2.20061027124138.03c72978@email.cisco.com> <4.3.2.7.2.20061027124138.03c72978@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Oct 2006 18:24:09.0054 (UTC) FILETIME=[17EFE7E0:01C6F9F5] DKIM-Signature: a=rsa-sha1; q=dns; l=1367; t=1161973449; x=1162837449; c=relaxed/simple; s=sjdkim6002; 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]=20LoST=20-02=20and=20error=20handling; X=v=3Dcisco.com=3B=20h=3DyoevR+xst/a2wPVMAK7Ysb0Hpy0=3D; b=hNuJLt1GJ7f1p2YQDrbRc7FNKQyV8U9DMao8Yja6piMHhVSORFNW4b2NKmv78sD1M/YDXFhL GZo9LJg6HtomMugEhbrg8WlL3+NChmB+uRYO01rYplS2Ev69L5+kce7n; Authentication-Results: sj-dkim-6.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); 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 At 02:06 PM 10/27/2006 -0400, Andrew Newton wrote: >James M. Polk wrote: >>Please remind me again why were the -01 error codes removed (for a single >>word text string)? > >Single word text string? You mean that stuff we call XML? no I mean "forbidden" and "notFound" and "serverTimeout" and etc... Which is different than the 400, 401, 404, 503, etc that -01 had in it. I checked with a member of your author team - who confirmed this was to be maintained wrt to the Registry ID he was told about. >We moved away from the error numbers because certain errors required >certain syntax, which meant we were no longer defining this XML based >protocol with an XML based schema language. Additionally, some of them >were not mutually exclusive. > >Within the author team, ahem... now that this is a WG item - don't you authors need WG consensus to make this type of change? At least with a message to the list asking if folks agree? I may have missed that message since the SDO conference (which I don't believe I did at the moment), but I think it is appropriate procedure to do it this way. >we are looking to overhaul it once more because we believe that the >current way is still confusing, and we have discussed a simpler, more >concise idea. But we are not looking at going back to error numbers. > >-andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 27 14:38:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdWac-0007CJ-0B; Fri, 27 Oct 2006 14:37:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdWab-0007CE-7z for ecrit@ietf.org; Fri, 27 Oct 2006 14:37:57 -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 1GdWaT-00041i-Bk for ecrit@ietf.org; Fri, 27 Oct 2006 14:37:57 -0400 Received: from [172.16.10.86] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Fri, 27 Oct 2006 14:37:42 -0400 id 015880F0.454251F6.00001850 Message-ID: <454251EB.3000607@hxr.us> Date: Fri, 27 Oct 2006 14:37:31 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ecrit] LoST -02 and error handling References: <4.3.2.7.2.20061027124138.03c72978@email.cisco.com> <4.3.2.7.2.20061027124138.03c72978@email.cisco.com> <4.3.2.7.2.20061027131608.02ed9008@email.cisco.com> In-Reply-To: <4.3.2.7.2.20061027131608.02ed9008@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) 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 James M. Polk wrote: >> Single word text string? You mean that stuff we call XML? > > no > > I mean "forbidden" and "notFound" and "serverTimeout" and etc... Each one of these is an XML element name in the draft. So yes, that is what you are talking about. > ahem... now that this is a WG item - don't you authors need WG consensus > to make this type of change? At least with a message to the list asking > if folks agree? I may have missed that message since the SDO conference > (which I don't believe I did at the moment), but I think it is > appropriate procedure to do it this way. I don't remember much discussion on this list about switching to error numbers away from the XML. In essence, we are putting things back the way they were. Of course, you and I could snipe at each other all day on the mechanics of how a draft changes, or we could address issues that really matter... such as which method is best for protocol interoperability and readability of the specification. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 27 17:40:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdZRE-0002oO-Cj; Fri, 27 Oct 2006 17:40:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdZRC-0002n2-IH; Fri, 27 Oct 2006 17:40:26 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdZRB-0001TF-3w; Fri, 27 Oct 2006 17:40:26 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2006 14:40:25 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9RLeOgc012710; Fri, 27 Oct 2006 14:40:24 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9RLeObF016249; Fri, 27 Oct 2006 14:40:24 -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.1830); Fri, 27 Oct 2006 14:40:22 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.144.112]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 14:40:22 -0700 Message-Id: <4.3.2.7.2.20061027160222.0304db98@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 27 Oct 2006 16:40:20 -0500 To: Andrew Newton From: "James M. Polk" Subject: Re: [Ecrit] LoST -02 and error handling In-Reply-To: <454251EB.3000607@hxr.us> References: <4.3.2.7.2.20061027131608.02ed9008@email.cisco.com> <4.3.2.7.2.20061027124138.03c72978@email.cisco.com> <4.3.2.7.2.20061027124138.03c72978@email.cisco.com> <4.3.2.7.2.20061027131608.02ed9008@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Oct 2006 21:40:22.0557 (UTC) FILETIME=[817DE4D0:01C6FA10] DKIM-Signature: a=rsa-sha1; q=dns; l=4222; t=1161985224; x=1162849224; c=relaxed/simple; s=sjdkim6002; 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]=20LoST=20-02=20and=20error=20handling; X=v=3Dcisco.com=3B=20h=3DyoevR+xst/a2wPVMAK7Ysb0Hpy0=3D; b=SPJHhFgI5bouPvJeEhSm0rDjZcC/Ak2zmSr1VmO4CRMHHbPBKuJkSI00HIiW9kf71xQBsCjK gwS6NLMUn2bEAfVEV3WkSjDgZ8e/Zycoh41EDyqoaT8tmTehSFjMYCBe; Authentication-Results: sj-dkim-6.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: geopriv@ietf.org, "'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 02:37 PM 10/27/2006 -0400, Andrew Newton wrote: >James M. Polk wrote: >>>Single word text string? You mean that stuff we call XML? >>no >>I mean "forbidden" and "notFound" and "serverTimeout" and etc... > >Each one of these is an XML element name in the draft. So yes, that is >what you are talking about. tomato, tomato, whatever The error code numbers: 400 Bad Request 403 Forbidden 404 Not Found 414 Location Error 500 Server Internal Error 501 Service Not Implemented 504 Server Time-Out were there in LoST-01, now they're gone - I'm asking why, cuz I didn't/don't/haven't seen or read that explained anywhere >>ahem... now that this is a WG item - don't you authors need WG consensus >>to make this type of change? At least with a message to the list asking >>if folks agree? I may have missed that message since the SDO conference >>(which I don't believe I did at the moment), but I think it is >>appropriate procedure to do it this way. > >I don't remember much discussion on this list about switching to error >numbers away from the XML. In essence, we are putting things back the way >they were. this isn't how -00 was, nor -01, so I don't have a reference to what you're referring to when you make the statement: "...back the way they were..." ....? Which version of which ID had it this way. >Of course, you and I could snipe at each other all day on the mechanics of >how a draft changes, or we could address issues that really matter... this is where we apparently differ, cuz I thought I was doing this by creating the Registry (asked for by YOUR co-chair BTW) of common location specific error cause codes, such that all protocols that have errors specific to a location value/reference provided, can use a common set of errors with generally agreed upon meanings. For example, - Alice calls for 911/112 help, the INVITE arrives at the P/E-CSCF (or just ESRP), if there is a problem with just the location provided in that INVITE, the server will respond to Alice's UA with a SIP error. SIP needs to be extended to provide a more granular location-error. - take the above same example, but the P/E-CSCF (ESRP) needs to derefence the URI. This isn't a SIP error anymore if the LoST server cannot service that LoST request, it's a LoST error. Does this need to be communicated back to Alice? In this case probably not. But, if the URI was bad, then it probably does. Now there are two errors (one from LoST in your XML only, and one in SIP in a Reason header) or there is one error (to be used by both protocols, though the form may be different). I think there are a few of the LoST errors that are similar to the SIP Reason errors offered by this new ID. Me thinks this makes things easier, and I'm getting the impression you don't want to discuss that being possible, or are opposed to this idea in general, or something else. Also, if Alice's UA ever does a LoST request her(its?)self, the UA will have to have been coded with all the LoST errors, and a nearly duplicative set of Reason errors that are important to SIP entities whenever Location is conveyed. >such as which method is best for protocol interoperability and readability >of the specification. "the specification"? this isn't a one stop shop my friend, and you well know LoST is only a piece of the puzzle, and a dependant one at that. More than one spec is needed to make any of htis work, and this Registry is an attempt to make some of those pieces work more commonly (in harmony?). Now, I can take the XML element names that are in LoST-02 and make them newly numbered error codes in the Registry, or we can define a translation of a LoST element to SIP Reason: location; cause=9; "Incomplete Location Supplied" or something along these lines whenever this is appropriate, because there are situations in which the LoST server produces an error that the UA needs to get via the ESRP_P/E-CSCF. How this is translated can be easier or harder depending on how we all look at this as an architecture, not a series of solo specs. James >-andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 27 19:21:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdb0y-0000sh-9O; Fri, 27 Oct 2006 19:21:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaxB-0007e0-4o; Fri, 27 Oct 2006 19:17:33 -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 1Gdapt-0000cN-2N; Fri, 27 Oct 2006 19:10:02 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 27 Oct 2006 19:09:50 -0400 id 015880CA.454291BE.00005574 In-Reply-To: <4.3.2.7.2.20061027160222.0304db98@email.cisco.com> References: <4.3.2.7.2.20061027131608.02ed9008@email.cisco.com> <4.3.2.7.2.20061027124138.03c72978@email.cisco.com> <4.3.2.7.2.20061027124138.03c72978@email.cisco.com> <4.3.2.7.2.20061027131608.02ed9008@email.cisco.com> <4.3.2.7.2.20061027160222.0304db98@email.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <88D20E56-1019-4CC2-AEB6-30742691C663@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Geopriv] Re: [Ecrit] LoST -02 and error handling Date: Fri, 27 Oct 2006 19:09:48 -0400 To: "James M. Polk" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: geopriv@ietf.org, "'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 Oct 27, 2006, at 5:40 PM, James M. Polk wrote: >> Each one of these is an XML element name in the draft. So yes, >> that is what you are talking about. > > tomato, tomato, whatever It's only XML, it can be that important to an XML-based protocol. :) > I'm asking why, cuz I didn't/don't/haven't seen or read that > explained anywhere See section 10 of -02. > this isn't how -00 was, nor -01, so I don't have a reference to > what you're referring to when you make the statement: "...back the > way they were..." ....? Which version of which ID had it this > way. See Section 10, Page 22 of -00. > this is where we apparently differ, cuz I thought I was doing this > by creating the Registry (asked for by YOUR co-chair BTW) of common > location specific error cause codes, such that all protocols that > have errors specific to a location value/reference provided, can > use a common set of errors with generally agreed upon meanings. I believe this is already been addressed in another thread on the GEOPRIV list. Shall I forward to you the relevant emails for reference? > For example, > > - Alice calls for 911/112 help, the INVITE arrives at the P/E-CSCF > (or just ESRP), if there is a problem with just the location > provided in that INVITE, the server will respond to Alice's UA with > a SIP error. SIP needs to be extended to provide a more granular > location-error. That sounds about right to me. > - take the above same example, but the P/E-CSCF (ESRP) needs to > derefence the URI. This isn't a SIP error anymore if the LoST > server cannot service that LoST request, it's a LoST error. Does > this need to be communicated back to Alice? In this case probably > not. But, if the URI was bad, then it probably does. Now there are > two errors (one from LoST in your XML only, and one in SIP in a > Reason header) or there is one error (to be used by both protocols, > though the form may be different). Why would there be LoST generated error if the ESRP cannot dereference a location? LoST would not be invoked at all in the scenario you just described because the dereference occurs first. Now, what about expressing both and simultaneously in SIP, as we need to do in LoST. > Me thinks this makes things easier, and I'm getting the impression > you don't want to discuss that being possible, or are opposed to > this idea in general, or something else. Again, this has been covered in another thread on the GEOPRIV list. > Also, if Alice's UA ever does a LoST request her(its?)self, the UA > will have to have been coded with all the LoST errors, and a nearly > duplicative set of Reason errors that are important to SIP entities > whenever Location is conveyed. Probably. But an IANA registry is a long, long way from both those pieces of code being the same. > "the specification"? this isn't a one stop shop my friend, and you > well know LoST is only a piece of the puzzle, and a dependant one > at that. More than one spec is needed to make any of htis work, and > this Registry is an attempt to make some of those pieces work more > commonly (in harmony?). Just how would you have pulled this off if ECRIT had adopted DNS- SOS? This goes to Henning's point (in that other thread) about protocols and their basic nature. > Now, I can take the XML element names that are in LoST-02 and make > them newly numbered error codes in the Registry, or we can define a > translation of a > > LoST element > to > SIP > Reason: location; cause=9; "Incomplete Location Supplied" > > or something along these lines whenever this is appropriate, > because there are situations in which the LoST server produces an > error that the UA needs to get via the ESRP_P/E-CSCF. or you can go with the suggestion made in that other thread. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit