From ecrit-bounces@ietf.org Thu Jun 01 11:48:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpPL-0005T8-UN; Thu, 01 Jun 2006 11:48:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpPL-0005Sk-FS for Ecrit@ietf.org; Thu, 01 Jun 2006 11:48:23 -0400 Received: from fwc-3a.sccx.com ([199.117.205.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlpPJ-00007I-UL for Ecrit@ietf.org; Thu, 01 Jun 2006 11:48:23 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 1 Jun 2006 10:48:18 -0500 Message-ID: <422D410BD61FC04185076AD99AA7207A019B31AD@inilmx01.lgmt.trdo> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Moving On Thread-Index: AcaFks1iKm/GfH82QWSUf6qxzy6+rw== From: "McCalmont, Patti" To: X-OriginalArrivalTime: 01 Jun 2006 15:48:20.0075 (UTC) FILETIME=[CE5FEBB0:01C68592] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Cc: Subject: [Ecrit] Moving On X-BeenThere: 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="===============2034394872==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============2034394872== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68592.CDAB4018" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68592.CDAB4018 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To everyone on the ECRIT list server, =20 June 2nd is my last day with Intrado. I am in the processes of getting ready to move from Illinois to Iowa so am taking the time to focus on my family needs, which includes packing the house up, getting the daughter through High School graduation and then moving her to the University of Iowa (her next school - go Hawkeye's), and finding a new permanent home. =20 I have enjoyed working with and getting to know many of you. I certainly have learned a lot about how IETF works and know this work in ECRIT is in good hands. It's been a great experience for me. =20 Patti McCalmont Sr. System Engineer Intrado Inc. 3030 Warenville Rd Lisle, IL 60532 direct: 630.300.2839 mobile 630.880.6399 fax: 720.494.6600 email: pmccalmont@intrado.com =20 Intrado(r)=20 www.intrado.com =20 ATTENTION: =20 The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify Intrado Inc. immediately at (720) 494-580 and destroy all copies of this message and any attachments. =20 ------_=_NextPart_001_01C68592.CDAB4018 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To everyone on the ECRIT list = server,

 

June 2nd is my last day with Intrado. I am = in the processes of getting ready to move from Illinois to Iowa so am taking = the time to focus on my family needs, which includes packing the house up, = getting the daughter through High School graduation and then moving her to the = University of Iowa (her next school – go Hawkeye’s), and finding a new permanent home.

 

I have enjoyed working with and getting to know many = of you. I certainly have learned a lot about how IETF works and know this work = in ECRIT is in good hands. It’s been a great experience for = me.

 

Patti = McCalmont

Sr. System = Engineer

Intrado = Inc.

3030 Warenville Rd

Lisle, IL 60532

direct: = 630.300.2839

mobile = 630.880.6399

fax: = 720.494.6600

email: pmccalmont@intrado.com

 

Intrado® =

www.intrado.com

 

ATTENTION:

 

The = information contained in this electronic message and any attachments to this message = are intended for the exclusive use of the addressee(s) and may contain = confidential or privileged information. If you are not the intended recipient, please = notify Intrado Inc. immediately at (720) 494-580 and destroy all copies of this message and any attachments.

 

------_=_NextPart_001_01C68592.CDAB4018-- --===============2034394872== 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 --===============2034394872==-- From ecrit-bounces@ietf.org Mon Jun 05 09:35:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnFEq-0004PU-Vu; Mon, 05 Jun 2006 09:35:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnFEn-0004Nz-Hm for ecrit@ietf.org; Mon, 05 Jun 2006 09:35:21 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnFBs-0004pb-F2 for ecrit@ietf.org; Mon, 05 Jun 2006 09:32:21 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML2ov-1FnFBr2pkT-0002jM; Mon, 05 Jun 2006 15:32:19 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Mon, 05 Jun 2006 13:28:08 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1149514088.54.0.834723723484.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: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ecrit] [issue2] Is it allowed to specify civic and geospatial info into the query? 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: Currently, a query (LosT client to LoST server) can either contain civic OR=20 geospatial location information. It cannot contain both. Would it be useful= to=20 allow both to be included in the query? ---------- nosy: +ecrit status: unread -> chatting __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 09:43:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnFMH-0000Dl-HM; Mon, 05 Jun 2006 09:43:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnFMG-0000Dg-6S for ecrit@ietf.org; Mon, 05 Jun 2006 09:43:04 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnFME-00086n-UN for ecrit@ietf.org; Mon, 05 Jun 2006 09:43:04 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FnFM9-0002gx-2w; Mon, 05 Jun 2006 08:42:57 -0500 From: "Brian Rosen" To: "'LoST Issue Tracker'" , Subject: RE: [Ecrit] [issue2] Is it allowed to specify civic and geospatial infointo the query? Date: Mon, 5 Jun 2006 09:42:57 -0400 Message-ID: <00c601c688a5$f67b60a0$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: AcaIpOhMlYFcKTWPQhCJegj04D9Z4gAALtkg In-reply-to: <1149514088.54.0.834723723484.issue2@http://www.tschofenig.priv.at> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I would say no. One of the ideas I think we have agreed to is that the LoST server is not in a position to decide what to do if more than one location is sent. The geo and the civic may (probably will) be somewhat different, and if the difference causes a difference in route, the LoST server can't decide what to do. The client can always send two queries, one with the geo and one with the civic and decide what to do if the results are different. Brian -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@siemens.com] Sent: Monday, June 05, 2006 9:28 AM To: ecrit@ietf.org Subject: [Ecrit] [issue2] Is it allowed to specify civic and geospatial infointo the query? Hannes Tschofenig added the comment: Currently, a query (LosT client to LoST server) can either contain civic OR geospatial location information. It cannot contain both. Would it be useful to allow both to be included in the query? ---------- nosy: +ecrit status: unread -> chatting __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ 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 Jun 05 09:45:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnFOY-0000VY-UQ; Mon, 05 Jun 2006 09:45:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnFOX-0000VT-54 for ecrit@ietf.org; Mon, 05 Jun 2006 09:45:25 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnFOV-0008WC-SO for ecrit@ietf.org; Mon, 05 Jun 2006 09:45:25 -0400 Received: from [192.168.0.41] (pool-138-89-46-232.mad.east.verizon.net [138.89.46.232]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k55DjFIw013642 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 5 Jun 2006 09:45:18 -0400 (EDT) In-Reply-To: <1149514088.54.0.834723723484.issue2@http://www.tschofenig.priv.at> References: <1149514088.54.0.834723723484.issue2@http://www.tschofenig.priv.at> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <71B03D51-B727-453C-B26D-5DF4E95F68A4@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatial info into the query? Date: Mon, 5 Jun 2006 09:45:11 -0400 To: LoST Issue Tracker X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The problem with having both is that the answers may differ, thus creating a new error condition. As far as I can tell, the same result can be achieved by querying sequentially, starting with whatever location information the querier deems best and falling back to the other if needed. Since the querier can issue two queries in parallel if time is important, there is no real performance hit, except for some modest additional packet overhead. Thus, in the spirit of keeping things simple and predictable, I'd say: no. On Jun 5, 2006, at 9:28 AM, Hannes Tschofenig wrote: > > Hannes Tschofenig added the comment: > > Currently, a query (LosT client to LoST server) can either contain > civic OR > geospatial location information. It cannot contain both. Would it > be useful to > allow both to be included in the query? > > ---------- > nosy: +ecrit > status: unread -> chatting > > __________________________________________________ > LoST Issue Tracker > > __________________________________________________ > > _______________________________________________ > 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 Jun 05 10:26:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnG1t-0001hj-Cv; Mon, 05 Jun 2006 10:26:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnG1s-0001gm-4E for ecrit@ietf.org; Mon, 05 Jun 2006 10:26:04 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnG1q-0003r1-RE for ecrit@ietf.org; Mon, 05 Jun 2006 10:26:04 -0400 Received: from [10.0.1.103] ([::ffff:68.106.115.242]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 05 Jun 2006 10:26:30 -0400 id 0158C0EE.44843F16.00007153 In-Reply-To: <71B03D51-B727-453C-B26D-5DF4E95F68A4@cs.columbia.edu> References: <1149514088.54.0.834723723484.issue2@http://www.tschofenig.priv.at> <71B03D51-B727-453C-B26D-5DF4E95F68A4@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <47423448-B898-4862-B530-BDD88485CC7D@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatial info into the query? Date: Mon, 5 Jun 2006 10:25:57 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 Not that I disagree with what you are saying, but wouldn't we want to put the decision as to which is the best PSAP to call based on the two sets of information in the hands of the LoST server and not at the client? Also, in the scenario you have given, how does the seeker determine whether the civic or geo location is best? -andy On Jun 5, 2006, at 9:45 AM, Henning Schulzrinne wrote: > The problem with having both is that the answers may differ, thus > creating a new error condition. As far as I can tell, the same > result can be achieved by querying sequentially, starting with > whatever location information the querier deems best and falling > back to the other if needed. > > Since the querier can issue two queries in parallel if time is > important, there is no real performance hit, except for some modest > additional packet overhead. > > Thus, in the spirit of keeping things simple and predictable, I'd > say: no. > > On Jun 5, 2006, at 9:28 AM, Hannes Tschofenig wrote: > >> >> Hannes Tschofenig added the comment: >> >> Currently, a query (LosT client to LoST server) can either contain >> civic OR >> geospatial location information. It cannot contain both. Would it >> be useful to >> allow both to be included in the query? >> >> ---------- >> nosy: +ecrit >> status: unread -> chatting >> >> __________________________________________________ >> LoST Issue Tracker >> >> __________________________________________________ >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 10:30:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnG6O-000381-9Z; Mon, 05 Jun 2006 10:30:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnG6N-00037w-MX for ecrit@ietf.org; Mon, 05 Jun 2006 10:30:43 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnG6L-0004C7-9o for ecrit@ietf.org; Mon, 05 Jun 2006 10:30:43 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu9) with ESMTP (Nemesis), id 0ML2xA-1FnG681kQV-0001ss; Mon, 05 Jun 2006 16:30:40 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Mon, 05 Jun 2006 14:26:17 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1149517577.24.0.303078922138.issue1@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] [issue1] Do we need a default service URN for the LoST query? 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: A LoST query contains location information and a service URN. Do we want to=20 make the service URN element/attribute optional by indicating a default val= ue?=20 Hence, if someone specifies a query that does not contain a service URN=20 element/attribute then the default value is chosen.=20 I think the service URN attribute/element should be mandatory. ---------- nosy: +ecrit status: unread -> chatting __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 10:32:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnG8S-0003Zd-7j; Mon, 05 Jun 2006 10:32:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnG8R-0003ZT-LB for ecrit@ietf.org; Mon, 05 Jun 2006 10:32:51 -0400 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnG8O-0004M2-7X for ecrit@ietf.org; Mon, 05 Jun 2006 10:32:51 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1FnG8N389A-0007f4; Mon, 05 Jun 2006 16:32:47 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Mon, 05 Jun 2006 14:28:36 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1149517716.58.0.667094320653.issue3@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: 79899194edc4f33a41f49410777972f8 Subject: [Ecrit] [issue3] List all Services Functionality 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 New submission from Hannes Tschofenig : Do we need the capability to list all services supported by the LoST server= ?=20 Would this feature be useful if the service list is constraint to a certain=20 branch of the tree? ---------- assignedto: hannes messages: 5 nosy: ecrit, hannes priority: critical status: unread title: List all Services Functionality __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 10:51:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnGQp-0005hK-B1; Mon, 05 Jun 2006 10:51:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnGQo-0005hF-Hg for ecrit@ietf.org; Mon, 05 Jun 2006 10:51:50 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnGQn-00074e-6r for ecrit@ietf.org; Mon, 05 Jun 2006 10:51:50 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k55Epm03006709 for ; Mon, 5 Jun 2006 08:51:48 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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] [issue2] Is it allowed to specify civic and geospatialinfo into the query? Date: Mon, 5 Jun 2006 08:51:48 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfo into the query? Thread-Index: AcaIrAOdCRikyyJiQ+yuagxRJ6zR4wAALfkQ From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This may depend on the scope of LoST. In the context of emergency context resolution (ecrit::urn:service:sos), I agree with Brian and Henning: no, it is not useful to allow both civic and geospatial information in a query.=20 But LoST draft-00 does explicitly have a broader scope of service URNs that just service:sos and this is where we might need to allow more flexibility. Should this question be coupled with the capability to have multiple requests per mapping query? Jean-Francois=20 > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Monday, June 05, 2006 8:26 AM > To: Henning Schulzrinne > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and > geospatialinfo into the query? >=20 > Not that I disagree with what you are saying, but wouldn't we want to > put the decision as to which is the best PSAP to call based on the > two sets of information in the hands of the LoST server and not at > the client? >=20 > Also, in the scenario you have given, how does the seeker determine > whether the civic or geo location is best? >=20 > -andy >=20 > On Jun 5, 2006, at 9:45 AM, Henning Schulzrinne wrote: >=20 > > The problem with having both is that the answers may differ, thus > > creating a new error condition. As far as I can tell, the same > > result can be achieved by querying sequentially, starting with > > whatever location information the querier deems best and falling > > back to the other if needed. > > > > Since the querier can issue two queries in parallel if time is > > important, there is no real performance hit, except for some modest > > additional packet overhead. > > > > Thus, in the spirit of keeping things simple and predictable, I'd > > say: no. > > > > On Jun 5, 2006, at 9:28 AM, Hannes Tschofenig wrote: > > > >> > >> Hannes Tschofenig added the comment: > >> > >> Currently, a query (LosT client to LoST server) can either contain > >> civic OR > >> geospatial location information. It cannot contain both. Would it > >> be useful to > >> allow both to be included in the query? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 11:02:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnGbE-0001T3-Bv; Mon, 05 Jun 2006 11:02:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnGbD-0001Rd-5X for ecrit@ietf.org; Mon, 05 Jun 2006 11:02:35 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnGbA-0008Fe-PQ for ecrit@ietf.org; Mon, 05 Jun 2006 11:02:35 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1FnGbA18Tt-0001UP; Mon, 05 Jun 2006 17:02:32 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Mon, 05 Jun 2006 14:58:21 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1149519501.05.0.914916605883.issue4@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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ecrit] [issue4] Service URN in Response Message 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 New submission from Hannes Tschofenig : In the current LoST draft we return a service URN in the response message.=20 The current text says:=20 " If a more specific service is requested but does not exist, information for the more generic service SHOULD be returned. For example, a request for urn:service:sos.fire might return urn:service:sos in the United States since citizens in that country reach the fire department through the common emergency service. " In the response message the service URN attribute/element then contains the=20 URN that was used in the matching process.=20 =20 Two questions: * Is this "error" handling mechanism useful? * Do we want to include a query-type attribute with the values 'strict matc= h'=20 and 'loose match' in the query message to indicate what type of behavior is=20 desired? ---------- assignedto: hannes messages: 6 nosy: ecrit, hannes priority: critical status: unread title: Service URN in Response Message __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 12:39:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnI7F-0006H5-UE; Mon, 05 Jun 2006 12:39:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnI6s-0006Gv-GB for ecrit@ietf.org; Mon, 05 Jun 2006 12:39:22 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnI6r-0001Gf-2l for ecrit@ietf.org; Mon, 05 Jun 2006 12:39:22 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Mon, 5 Jun 2006 09:39:18 -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] [issue1] Do we need a default service URN for the LoSTquery? Date: Mon, 5 Jun 2006 09:39:17 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657505130F3A@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [issue1] Do we need a default service URN for the LoSTquery? Thread-Index: AcaIrKJMUrp2I15uTVqzfD4SxRmwpwAEJ/Ug From: "Roger Marshall" To: "LoST Issue Tracker" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The LoST server must support a default, so that if it receives a query which contains location, but no emergency service identifier, then it can still provide an answer. The worst case of having this happen is that clients always get an emergency context associated, location-relevant PSAP URI when they query with location only. The server would then return this "default" ESI so that the client would have it from then on. I think the LoST protocol requirements for query including an ESI is a SHOULD, and a response msg. to include an ESI is a MUST. Roger Marshall. >-----Original Message----- >From: Hannes Tschofenig [mailto:hannes.tschofenig@siemens.com]=20 >Sent: Monday, June 05, 2006 7:26 AM >To: ecrit@ietf.org >Subject: [Ecrit] [issue1] Do we need a default service URN for=20 >the LoSTquery? > > >Hannes Tschofenig added the comment: > >A LoST query contains location information and a service URN.=20 >Do we want to make the service URN element/attribute optional=20 >by indicating a default value?=20 >Hence, if someone specifies a query that does not contain a=20 >service URN element/attribute then the default value is chosen.=20 > >I think the service URN attribute/element should be mandatory. > >---------- >nosy: +ecrit >status: unread -> chatting > >__________________________________________________ >LoST Issue Tracker =20 > >__________________________________________________ > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 13:21:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnIl8-0007pD-ED; Mon, 05 Jun 2006 13:20:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnIl6-0007fg-F9 for ecrit@ietf.org; Mon, 05 Jun 2006 13:20:56 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnIl5-0006RS-1D for ecrit@ietf.org; Mon, 05 Jun 2006 13:20:56 -0400 Received: (qmail invoked by alias); 05 Jun 2006 17:20:52 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp005) with SMTP; 05 Jun 2006 19:20:52 +0200 X-Authenticated: #29516787 Message-ID: <448467F9.4040307@gmx.net> Date: Mon, 05 Jun 2006 19:20:57 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] [issue1] Do we need a default service URN for the LoSTquery? References: <8C837214C95C864C9F34F3635C2A657505130F3A@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A657505130F3A@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Hi Roger, Roger Marshall wrote: > The LoST server must support a default, so that if it receives a query > which contains location, but no emergency service identifier, then it > can still provide an answer. We can also write the protocol in such a way that the emergency service is a mandatory field. Hence, the LoST client always has to provide a service URN. I prefer this approach. > > The worst case of having this happen is that clients always get an > emergency context associated, location-relevant PSAP URI when they query > with location only. The server would then return this "default" ESI so > that the client would have it from then on. > > I think the LoST protocol requirements for query including an ESI is a > SHOULD, and a response msg. to include an ESI is a MUST. Ciao Hannes > > Roger Marshall. > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:hannes.tschofenig@siemens.com] >>Sent: Monday, June 05, 2006 7:26 AM >>To: ecrit@ietf.org >>Subject: [Ecrit] [issue1] Do we need a default service URN for >>the LoSTquery? >> >> >>Hannes Tschofenig added the comment: >> >>A LoST query contains location information and a service URN. >>Do we want to make the service URN element/attribute optional >>by indicating a default value? >>Hence, if someone specifies a query that does not contain a >>service URN element/attribute then the default value is chosen. >> >>I think the service URN attribute/element should be mandatory. >> >>---------- >>nosy: +ecrit >>status: unread -> chatting >> >>__________________________________________________ >>LoST Issue Tracker >> >>__________________________________________________ >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 13:29:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnIth-00010R-Tc; Mon, 05 Jun 2006 13:29:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnItg-00010M-Ib for ecrit@ietf.org; Mon, 05 Jun 2006 13:29:48 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnItc-0007Km-3D for ecrit@ietf.org; Mon, 05 Jun 2006 13:29:48 -0400 Received: (qmail invoked by alias); 05 Jun 2006 17:29:42 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp037) with SMTP; 05 Jun 2006 19:29:42 +0200 X-Authenticated: #29516787 Message-ID: <44846A0F.60909@gmx.net> Date: Mon, 05 Jun 2006 19:29:51 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jean-Francois Mule Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfo into the query? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Jean-Francois, Jean-Francois Mule wrote: > This may depend on the scope of LoST. > > In the context of emergency context resolution > (ecrit::urn:service:sos), I agree with Brian and > Henning: no, it is not useful to allow both civic and geospatial > information in a query. > > But LoST draft-00 does explicitly have a broader scope of service URNs > that just service:sos and this is where we might need to allow more > flexibility. That's a good point. Since the query type is extensible I think we can get away by using a separate query for geospatial, civic and later, if needed, for the combination of both. > > Should this question be coupled with the capability to have multiple > requests per mapping query? If this is useful then most likely in a non-emergency environment. Hence, I would also like to push it towards an extension. Ciao Hannes > > Jean-Francois > > >>-----Original Message----- >>From: Andrew Newton [mailto:andy@hxr.us] >>Sent: Monday, June 05, 2006 8:26 AM >>To: Henning Schulzrinne >>Cc: ecrit@ietf.org >>Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >>geospatialinfo into the query? >> >>Not that I disagree with what you are saying, but wouldn't we want to >>put the decision as to which is the best PSAP to call based on the >>two sets of information in the hands of the LoST server and not at >>the client? >> >>Also, in the scenario you have given, how does the seeker determine >>whether the civic or geo location is best? >> >>-andy >> >>On Jun 5, 2006, at 9:45 AM, Henning Schulzrinne wrote: >> >> >>>The problem with having both is that the answers may differ, thus >>>creating a new error condition. As far as I can tell, the same >>>result can be achieved by querying sequentially, starting with >>>whatever location information the querier deems best and falling >>>back to the other if needed. >>> >>>Since the querier can issue two queries in parallel if time is >>>important, there is no real performance hit, except for some modest >>>additional packet overhead. >>> >>>Thus, in the spirit of keeping things simple and predictable, I'd >>>say: no. >>> >>>On Jun 5, 2006, at 9:28 AM, Hannes Tschofenig wrote: >>> >>> >>>>Hannes Tschofenig added the comment: >>>> >>>>Currently, a query (LosT client to LoST server) can either contain >>>>civic OR >>>>geospatial location information. It cannot contain both. Would it >>>>be useful to >>>>allow both to be included in the query? > > > > > _______________________________________________ > 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 Jun 05 13:46:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnJ9c-0001xl-7G; Mon, 05 Jun 2006 13:46:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnJ9a-0001xf-Vp for ecrit@ietf.org; Mon, 05 Jun 2006 13:46:14 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnJ9Z-0004Fi-Jk for ecrit@ietf.org; Mon, 05 Jun 2006 13:46:14 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1FnJ9Y3m6m-0005UV; Mon, 05 Jun 2006 19:46:12 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Mon, 05 Jun 2006 17:42:01 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1149529321.43.0.303860432851.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: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Ecrit] [issue5] PSAP Boundary Hint 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 New submission from Hannes Tschofenig : The response message may provide information about the PSAP boundary.=20 First question: Should the LoST client indicate whether it wants to have th= e=20 PSAP boundary as hint included in the response message? Alternatively, we c= ould=20 include this information per-default in a mobility environment (see Geopriv= -L7=20 discussion).=20 Current protocol proposals focused on the distribution of a polygon (when=20 geospatial location information is used in the query) to express the PSAP=20 boundary.=20 Second question: While it is quite simple what to return for geospatial=20 location information it seems to be more complicated for civic location=20 information. Has someone already thought about civic info? Is there existin= g=20 work outside the IETF we can leverage? ---------- assignedto: hannes messages: 7 nosy: ecrit, hannes priority: critical status: unread title: PSAP Boundary Hint __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 13:47:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnJAi-00023A-Tq; Mon, 05 Jun 2006 13:47:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnJAi-00022R-Ek for ecrit@ietf.org; Mon, 05 Jun 2006 13:47:24 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnJAh-0004Ha-7v for ecrit@ietf.org; Mon, 05 Jun 2006 13:47:24 -0400 Received: from lion.cs.columbia.edu (IDENT:cBErWCkxhWO8I4RDidIV8/jAezJoW1wP@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k55HlGX6016863 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 5 Jun 2006 13:47:16 -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 k55HlABB026608 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Jun 2006 13:47:14 -0400 Message-ID: <44846E19.10601@cs.columbia.edu> Date: Mon, 05 Jun 2006 13:47:05 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] [issue1] Do we need a default service URN for the LoSTquery? References: <8C837214C95C864C9F34F3635C2A657505130F3A@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A657505130F3A@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Roger Marshall wrote: > The LoST server must support a default, so that if it receives a query > which contains location, but no emergency service identifier, then it > can still provide an answer. I don't see that as necessary or helpful. Why can't the client always insert a service URN? This seems a trivial thing to do for a client and avoids problems of trying to guess what the client really wanted. (Remember that LoST may well be used for non-emergency services, too.) I don't think "you know what I mean" protocol features are a good way forward. > > The worst case of having this happen is that clients always get an > emergency context associated, location-relevant PSAP URI when they query > with location only. The server would then return this "default" ESI so > that the client would have it from then on. > > I think the LoST protocol requirements for query including an ESI is a > SHOULD, and a response msg. to include an ESI is a MUST. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 14:00:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnJNe-00007w-8v; Mon, 05 Jun 2006 14:00:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnJNd-00007m-4e for ecrit@ietf.org; Mon, 05 Jun 2006 14:00:45 -0400 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnJNa-0004ew-Ow for ecrit@ietf.org; Mon, 05 Jun 2006 14:00:45 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu9) with ESMTP (Nemesis), id 0ML2xA-1FnJNa17KC-0001ip; Mon, 05 Jun 2006 20:00:42 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Mon, 05 Jun 2006 17:56:30 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1149530190.74.0.24969342146.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: 93238566e09e6e262849b4f805833007 Subject: [Ecrit] [issue6] 'Authority' Attribute in LoST Response 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 New submission from Hannes Tschofenig : ECON-IRIS defined an 'authority' attribute in the response message. This attribute provides information about the authoritive source of the map= ping=20 data.=20 Question: Is it useful to provide such information in a LoST response? What information would be a good identifier for an authoritive source? ---------- assignedto: hannes messages: 8 nosy: ecrit, hannes priority: critical status: unread title: 'Authority' Attribute in LoST Response __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 14:53:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnKD9-0006TW-83; Mon, 05 Jun 2006 14:53:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnKD5-0006TR-JU for ecrit@ietf.org; Mon, 05 Jun 2006 14:53:55 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnKD4-0000zp-CG for ecrit@ietf.org; Mon, 05 Jun 2006 14:53:55 -0400 Received: from lion.cs.columbia.edu (IDENT:URo8O+ubXXvauNMueipVzQ5ZMYCZYYmE@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k55IraX6008397 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 5 Jun 2006 14:53:43 -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 k55IrZBB030747 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Jun 2006 14:53:36 -0400 Message-ID: <44847DAA.5090201@cs.columbia.edu> Date: Mon, 05 Jun 2006 14:53:30 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatial info into the query? References: <1149514088.54.0.834723723484.issue2@http://www.tschofenig.priv.at> <71B03D51-B727-453C-B26D-5DF4E95F68A4@cs.columbia.edu> <47423448-B898-4862-B530-BDD88485CC7D@hxr.us> In-Reply-To: <47423448-B898-4862-B530-BDD88485CC7D@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Andrew Newton wrote: > Not that I disagree with what you are saying, but wouldn't we want to > put the decision as to which is the best PSAP to call based on the two > sets of information in the hands of the LoST server and not at the client? > > Also, in the scenario you have given, how does the seeker determine > whether the civic or geo location is best? Hard to say in general. There might be reasons that the client has a preference or knows which type of information to trust more: - GPS data has not been updated in a while (lost satellite contact) or has a high error margin, but civic data (e.g., via LLDP) is more recent. vs. - GPS data is recent, but maybe the system also has some geo-mapped data. vs. - End system uses some kind of Skyhook-like 802.11 service, which has moderate accuracy and has some civic "beacon" information that's not as recent. In all of these dual-information cases, I don't see how anybody except the seeker can make any determination which type of information is better, more accurate, more recent, etc. There's obviously a different scenario when for some reason, the LoST server only knows a mapping for either geo or civic, but not both. In that case, an error message such as "No resolution for civic; try geo" (obviously, an error code, not just a string) might be helpful. In practice, I suspect that the server will have the same information for both geo and civic; that seems to be the common case today where both are available. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 15:01:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnKK6-0001Sh-Bx; Mon, 05 Jun 2006 15:01:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnKK5-0001ST-0x for ecrit@ietf.org; Mon, 05 Jun 2006 15:01:09 -0400 Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnKK3-000235-JM for ecrit@ietf.org; Mon, 05 Jun 2006 15:01:09 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu9) with ESMTP (Nemesis), id 0ML2xA-1FnKK23dQW-0005bL; Mon, 05 Jun 2006 21:01:07 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Mon, 05 Jun 2006 18:56:55 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1149533815.28.0.96627716085.issue4@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: b280b4db656c3ca28dd62e5e0b03daa8 Subject: [Ecrit] [issue4] Service URN in Response Message 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: I went through the mailing list about this issue again.=20 The mailing discussion started around=20 http://www1.ietf.org/mail-archive/web/ecrit/current/msg01964.html Martin, Mike, Henning, Brian, Andy, Ted, Hannes and Henning participated in= the=20 discussion.=20 I am actually confused and I am not quite sure what the outcome of the=20 discussion is. Here are a few discussion snippets: Henning Schulzrinne wrote: > > On May 17, 2006, at 8:05 PM, Thomson, Martin wrote: > >> I don't have a problem with asking for sub-services. For instance, I kn= ow=20 about urn:service:massage, but I might like to know that=20 urn:service:massage.swedish exists. That's valuable. >> >> Of course, the advantage with what we have currently is that this featur= e=20 can be added later. If it isn't necessary, then we can leave it until we d= on't=20 have more pressing problems to address. > > > Indeed - that's a separate query. > >> >> Q: If I try to resolve urn:service:sos.fire and it doesn't exist, can th= e=20 LoST server unilaterally return the result for urn:service:sos? > > > I suppose, as a hint, although I'm a bit worried about the complexity onc= e=20 you generalize this. Imagine that we have more than two levels of service=20 descriptions (urn:service:sos.fire.cats_in_trees). Should the result includ= e=20 the whole tree above the (non-existing) service? > > I think a better approach is to have the client do the "list subservices"=20 query, and then query for those subservices. Less guesswork and special cas= es. > > Henning=20 Ted argued:=20 " I think the rest of Brian's cases are, in essence, default mappings, where = one service (e.g. sos.police) is doing double duty as something else (e.g sos).= I would also argue that it would be better in that case to populate the default URN (sos)'s LoST data with the same data as (sos.police) as a direct, effective way of handling that. " Hannes responded:=20 " Doing this you wouldn't even need to return the service urn with the LoST=20 response since it would match the query.=20 " ---------- status: unread -> chatting __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 15:11:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnKTl-0005XL-W3; Mon, 05 Jun 2006 15:11:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnKTk-0005Tt-S3 for ecrit@ietf.org; Mon, 05 Jun 2006 15:11:08 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnKTj-0002jb-MT for ecrit@ietf.org; Mon, 05 Jun 2006 15:11:08 -0400 Received: from [10.0.1.103] ([::ffff:68.106.115.242]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 05 Jun 2006 15:11:35 -0400 id 0158C0F2.448481E7.0000253A In-Reply-To: <44847DAA.5090201@cs.columbia.edu> References: <1149514088.54.0.834723723484.issue2@http://www.tschofenig.priv.at> <71B03D51-B727-453C-B26D-5DF4E95F68A4@cs.columbia.edu> <47423448-B898-4862-B530-BDD88485CC7D@hxr.us> <44847DAA.5090201@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <04812CCE-EE9A-4516-B842-EFBCB9E710C2@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatial info into the query? Date: Mon, 5 Jun 2006 15:11:05 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: > In all of these dual-information cases, I don't see how anybody > except the seeker can make any determination which type of > information is better, more accurate, more recent, etc. Would we want the seeker to determine which information it feels is best to provide to the PSAP? I've always heard that the answer would be no: provide both to the PSAP. So why then would we not provide the same information when determining which PSAP to contact? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 15:14:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnKXL-0007pg-KZ; Mon, 05 Jun 2006 15:14:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnKXK-0007nm-8l for ecrit@ietf.org; Mon, 05 Jun 2006 15:14:50 -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 1FnKXJ-0003JC-3N for ecrit@ietf.org; Mon, 05 Jun 2006 15:14:50 -0400 Received: from [10.0.1.103] ([::ffff:68.106.115.242]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 05 Jun 2006 15:15:17 -0400 id 0158C0F2.448482C5.000025C7 In-Reply-To: <1149530190.74.0.24969342146.issue6@http://www.tschofenig.priv.at> References: <1149530190.74.0.24969342146.issue6@http://www.tschofenig.priv.at> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <65E1C69D-FBB8-42C8-90FE-AF3B4A49F3D5@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] [issue6] 'Authority' Attribute in LoST Response Date: Mon, 5 Jun 2006 15:14:47 -0400 To: LoST Issue Tracker X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 5, 2006, at 1:56 PM, Hannes Tschofenig wrote: > Question: Is it useful to provide such information in a LoST response? > What information would be a good identifier for an authoritive source? It may useful to detect referall loops by LoST resolvers. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 15:15:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnKXZ-0008Br-9f; Mon, 05 Jun 2006 15:15:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnKXY-0008Bm-Gh for ecrit@ietf.org; Mon, 05 Jun 2006 15:15:04 -0400 Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnKXW-0003Ki-3z for ecrit@ietf.org; Mon, 05 Jun 2006 15:15:04 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1FnKXV1gSB-0007dV; Mon, 05 Jun 2006 21:15:01 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Mon, 05 Jun 2006 19:10:49 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1149534649.93.0.0607807562156.issue7@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: 50a516d93fd399dc60588708fd9a3002 Subject: [Ecrit] [issue7] Adding Additional Info to LoST Response 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 New submission from Hannes Tschofenig : Hannes wrote:=20 * Henning suggested to extend LoST to return additional information regardi= ng=20 the service (e.g., location information needed). This discussion is relevan= t=20 for LoST. I can see that there was support for his proposal. This aspect do= es=20 not need to be captured in the requirements draft.=20 Here is Henning's proposal:=20 " One pretty simple solution is to have a four-valued attribute: - required --> no service without it; you're legally obligated to provide = it=20 for this service - helpful --> the receiver would like to have this information, but isn't=20 going to refuse the call and you're not legally obligated; if you route th= e=20 call yourself, you don't need to include it in signaling - routing --> the receiver doesn't need it, but it's used to route the ca= ll - ignored --> the receiver will just ignore the location information and=20 there's no location-based routing I suspect this can be split into two dimensions (routing and end system).=20 " Question: Is this something to consider?=20 (PS: I might have missed other, much better, proposals in the mailing list=20 discussion.) ---------- assignedto: hannes messages: 10 nosy: ecrit, hannes priority: critical status: unread title: Adding Additional Info to LoST Response __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 15:31:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnKn8-0006T7-Ar; Mon, 05 Jun 2006 15:31:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnKn7-0006RN-OL for ecrit@ietf.org; Mon, 05 Jun 2006 15:31:09 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnKk4-0003iW-LC for ecrit@ietf.org; Mon, 05 Jun 2006 15:28:02 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1FnKk32QhC-0000TP; Mon, 05 Jun 2006 21:27:59 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Mon, 05 Jun 2006 19:23:47 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1149535427.95.0.97800587706.issue3@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: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Ecrit] [issue3] List all Services Functionality 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: The ability to use LoST to list services it supports was discussed in the p= ast=20 already. Here are some example discussion snippets hidden somewhere in this=20 mailing list thread: http://www1.ietf.org/mail-archive/web/ecrit/current/msg01964.html Brian Rosen wrote: >> I would imagine that there would be, somewhere, some kind of a "pretty >> print" description of what these services are. The phone would access = this >> along with the list of service urns available at their location and off= er an >> interesting GUI for what it finds. >> Brian Henning Schulzrinne wrote: > I agree with Brian. > > It seems quite common for GSM phones to show a text message =20 indicating "welcome to Teluristan; you can get concierge services at *311 = and=20 can talk to our sales rep at *411." when roaming into a new country or ser= vice=20 area. The problem with these messages is that they are not structured, so=20 there is no easy way for them to be integrated into the phone's address bo= ok,=20 for example. With the service listing proposed, this would be fairly=20 straightforward. Given the generic URN service names, it would also make i= t=20 easy to have symbols or visitor-language descriptions on the phone. Thus, =20 tourists could always easily access the local version of the poison contro= l=20 center, for example, even if they have no clue that they'd dial 1-800-222-= 1222=20 in the US for that. > > Henning ---------- status: unread -> chatting __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 15:40:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnKvj-0002oc-4a; Mon, 05 Jun 2006 15:40:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnKvh-0002lO-R9 for ecrit@ietf.org; Mon, 05 Jun 2006 15:40:01 -0400 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnKvg-00058A-EO for ecrit@ietf.org; Mon, 05 Jun 2006 15:40:01 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1FnKvf3qXV-000464; Mon, 05 Jun 2006 21:40:00 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Mon, 05 Jun 2006 19:35:48 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1149536148.3.0.994600075606.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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ecrit] [issue8] Dial Strings 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 New submission from Hannes Tschofenig : In http://www1.ietf.org/mail-archive/web/ecrit/current/msg01937.html Roger describes the different variations of LoST message exchanges.=20 Roger mentions that the LoST response returns a dial string. This idea of u= sing=20 LoST for providing dial strings that are valid in a particular geographical=20 area was already mentioned in the past.=20 When do we return a dial string? Should we use a separate query for this=20 purpose or an attribute to the query message? ---------- assignedto: hannes messages: 12 nosy: ecrit, hannes priority: critical status: unread title: Dial Strings in LoST __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 15:51:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnL6i-00087T-94; Mon, 05 Jun 2006 15:51:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnL5U-000520-Ce for ecrit@ietf.org; Mon, 05 Jun 2006 15:50:08 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnL5S-0006Id-2p for ecrit@ietf.org; Mon, 05 Jun 2006 15:50:08 -0400 Received: from lion.cs.columbia.edu (IDENT:zVr8owAVXEiulOaXCsfbqdLw7HyQbPpC@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k55JnuX6001600 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 5 Jun 2006 15:50:00 -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 k55JnuBB003251 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Jun 2006 15:49:56 -0400 Message-ID: <44848ADE.3090307@cs.columbia.edu> Date: Mon, 05 Jun 2006 15:49:50 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: LoST Issue Tracker Subject: Re: [Ecrit] [issue8] Dial Strings in LoST References: <1149536148.3.0.994600075606.issue8@http://www.tschofenig.priv.at> In-Reply-To: <1149536148.3.0.994600075606.issue8@http://www.tschofenig.priv.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Given that this information is short and generally needed, it seems easiest to include it with the response, as in some-KPML-string We can query for each element separately, but that seems to just add complexity and more failure cases. Hannes Tschofenig wrote: > New submission from Hannes Tschofenig : > > In http://www1.ietf.org/mail-archive/web/ecrit/current/msg01937.html > Roger describes the different variations of LoST message exchanges. > > Roger mentions that the LoST response returns a dial string. This idea of using > LoST for providing dial strings that are valid in a particular geographical > area was already mentioned in the past. > > When do we return a dial string? Should we use a separate query for this > purpose or an attribute to the query message? > > ---------- > assignedto: hannes > messages: 12 > nosy: ecrit, hannes > priority: critical > status: unread > title: Dial Strings in LoST > > __________________________________________________ > LoST Issue Tracker > > __________________________________________________ > > _______________________________________________ > 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 Jun 05 16:00:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLFH-0006gq-DS; Mon, 05 Jun 2006 16:00:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLFG-0006gW-A1 for ecrit@ietf.org; Mon, 05 Jun 2006 16:00:14 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnLFF-0007ln-0S for ecrit@ietf.org; Mon, 05 Jun 2006 16:00:14 -0400 Received: from lion.cs.columbia.edu (IDENT:6p2l+9XZtkojgtDEZ4WCF5vQIPOhZyfn@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k55K0AX6004108 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 5 Jun 2006 16:00:10 -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 k55K0ABB004125 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Jun 2006 16:00:10 -0400 Message-ID: <44848D45.4040005@cs.columbia.edu> Date: Mon, 05 Jun 2006 16:00:05 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: LoST Issue Tracker Subject: Re: [Ecrit] [issue4] Service URN in Response Message References: <1149533815.28.0.96627716085.issue4@http://www.tschofenig.priv.at> In-Reply-To: <1149533815.28.0.96627716085.issue4@http://www.tschofenig.priv.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org If we assume that there's a "list services" method, would we still need this? Maybe it would help to define a usage scenario, as participants in this discussion may have different ideas. One additional item of discussion that we seemed to agree on was that the server could provide PSAP information for a more specialized service even if it was the same as the more general service. For example, in the US, the PSAP information for sos.fire would always return the same information as sos.police (and as just plain sos) as long as all these emergency requests get routed to a single PSAP, regardless of the nature of the emergency. (This isn't quite true for all sos services even in the US, as poison-control gets routed elsewhere.) Hannes Tschofenig wrote: > Hannes Tschofenig added the comment: > > I went through the mailing list about this issue again. > The mailing discussion started around > http://www1.ietf.org/mail-archive/web/ecrit/current/msg01964.html > > Henning Schulzrinne wrote: > >> On May 17, 2006, at 8:05 PM, Thomson, Martin wrote: >> >>> I don't have a problem with asking for sub-services. For instance, I know > about urn:service:massage, but I might like to know that > urn:service:massage.swedish exists. That's valuable. >>> Of course, the advantage with what we have currently is that this feature > can be added later. If it isn't necessary, then we can leave it until we don't > have more pressing problems to address. >> >> Indeed - that's a separate query. >> >>> Q: If I try to resolve urn:service:sos.fire and it doesn't exist, can the > LoST server unilaterally return the result for urn:service:sos? >> >> I suppose, as a hint, although I'm a bit worried about the complexity once > you generalize this. Imagine that we have more than two levels of service > descriptions (urn:service:sos.fire.cats_in_trees). Should the result include > the whole tree above the (non-existing) service? >> I think a better approach is to have the client do the "list subservices" > query, and then query for those subservices. Less guesswork and special cases. >> Henning > > > > > Ted argued: > > " > I think the rest of Brian's cases are, in essence, default mappings, where one > service (e.g. sos.police) is doing double duty as something else (e.g sos). I > would also argue that it would be better in that case to populate the > default URN (sos)'s LoST data with the same data as (sos.police) > as a direct, effective way of handling that. > " > > Hannes responded: > " > Doing this you wouldn't even need to return the service urn with the LoST > response since it would match the query. > " > > ---------- > status: unread -> chatting > > __________________________________________________ > LoST Issue Tracker > > __________________________________________________ > > _______________________________________________ > 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 Jun 05 16:05:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLAo-0004fn-CK; Mon, 05 Jun 2006 15:55:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLAb-0004Wt-GW for ecrit@ietf.org; Mon, 05 Jun 2006 15:55:25 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnLAZ-0007Pu-RP for ecrit@ietf.org; Mon, 05 Jun 2006 15:55:25 -0400 Received: from lion.cs.columbia.edu (IDENT:13oLMiZEYZcA/6GegqvHg6weycDATOWM@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k55JtKX6002781 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 5 Jun 2006 15:55:21 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k55JtKBB003707 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Jun 2006 15:55:20 -0400 Message-ID: <44848C23.6060701@cs.columbia.edu> Date: Mon, 05 Jun 2006 15:55:15 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatial info into the query? References: <1149514088.54.0.834723723484.issue2@http://www.tschofenig.priv.at> <71B03D51-B727-453C-B26D-5DF4E95F68A4@cs.columbia.edu> <47423448-B898-4862-B530-BDD88485CC7D@hxr.us> <44847DAA.5090201@cs.columbia.edu> <04812CCE-EE9A-4516-B842-EFBCB9E710C2@hxr.us> In-Reply-To: <04812CCE-EE9A-4516-B842-EFBCB9E710C2@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' 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 At the PSAP, we have a human that can look at this information and make decisions (and maybe even ask if there's a discrepancy). That seems a stretch for the LoST server. Andrew Newton wrote: > > On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: >> In all of these dual-information cases, I don't see how anybody except >> the seeker can make any determination which type of information is >> better, more accurate, more recent, etc. > > Would we want the seeker to determine which information it feels is best > to provide to the PSAP? I've always heard that the answer would be no: > provide both to the PSAP. So why then would we not provide the same > information when determining which PSAP to contact? > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 16:18:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLWg-0005KT-81; Mon, 05 Jun 2006 16:18:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLWe-0005Jy-Fg for ecrit@ietf.org; Mon, 05 Jun 2006 16:18:12 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnLWd-0002e8-6k for ecrit@ietf.org; Mon, 05 Jun 2006 16:18:12 -0400 Received: from lion.cs.columbia.edu (IDENT:/wF6TnhL2WKKh3BqXWjcHNCVGl1c/6JH@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k55KI8X6009433 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 5 Jun 2006 16:18:09 -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 k55KI6BB005577 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Jun 2006 16:18:08 -0400 Message-ID: <44849179.1090208@cs.columbia.edu> Date: Mon, 05 Jun 2006 16:18:01 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: LoST Issue Tracker Subject: Re: [Ecrit] [issue4] Service URN in Response Message References: <1149519501.05.0.914916605883.issue4@http://www.tschofenig.priv.at> In-Reply-To: <1149519501.05.0.914916605883.issue4@http://www.tschofenig.priv.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 this is related to the issue of the other thread, regarding defaults. I don't think the querier actually cares whether the PSAP for sos.fire and sos.police happens to be the same. Thus, I think this is purely a server configuration issue where the server database is set up to return a default value for unknown emergency services. This seems to be the case in practice today: even in places where there are separate numbers for various services, if you don't know whom to call for a "non-standard" emergency, you'd probably call the police. Hannes Tschofenig wrote: > New submission from Hannes Tschofenig : > > In the current LoST draft we return a service URN in the response message. > The current text says: > > " > If a more specific service is requested but does not exist, > information for the more generic service SHOULD be returned. For > example, a request for urn:service:sos.fire might return > urn:service:sos in the United States since citizens in that country > reach the fire department through the common emergency service. > " > > In the response message the service URN attribute/element then contains the > URN that was used in the matching process. > > Two questions: > > * Is this "error" handling mechanism useful? > * Do we want to include a query-type attribute with the values 'strict match' > and 'loose match' in the query message to indicate what type of behavior is > desired? > > ---------- > assignedto: hannes > messages: 6 > nosy: ecrit, hannes > priority: critical > status: unread > title: Service URN in Response Message > > __________________________________________________ > LoST Issue Tracker > > __________________________________________________ > > _______________________________________________ > 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 Jun 05 16:29:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLh9-0008Oy-6e; Mon, 05 Jun 2006 16:29:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLh7-0008Nx-ST for ecrit@ietf.org; Mon, 05 Jun 2006 16:29:01 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnLh6-0003G0-I3 for ecrit@ietf.org; Mon, 05 Jun 2006 16:29:01 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FnLgy-00026H-Db; Mon, 05 Jun 2006 15:28:52 -0500 From: "Brian Rosen" To: "'LoST Issue Tracker'" , Subject: RE: [Ecrit] [issue4] Service URN in Response Message Date: Mon, 5 Jun 2006 16:28:56 -0400 Message-ID: <023101c688de$ad2f3ff0$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: AcaIsRUGwOZhSMdoRSKI0hxD+vbZ/wALXHzQ In-reply-to: <1149519501.05.0.914916605883.issue4@http://www.tschofenig.priv.at> 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: 82c9bddb247d9ba4471160a9a865a5f3 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 Yes, I think it's necessary. You requested one thing, you got another. You should be told what you got. No, I don't think we need to provide options for strict/loose match. Brian -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@siemens.com] Sent: Monday, June 05, 2006 10:58 AM To: ecrit@ietf.org Subject: [Ecrit] [issue4] Service URN in Response Message New submission from Hannes Tschofenig : In the current LoST draft we return a service URN in the response message. The current text says: " If a more specific service is requested but does not exist, information for the more generic service SHOULD be returned. For example, a request for urn:service:sos.fire might return urn:service:sos in the United States since citizens in that country reach the fire department through the common emergency service. " In the response message the service URN attribute/element then contains the URN that was used in the matching process. Two questions: * Is this "error" handling mechanism useful? * Do we want to include a query-type attribute with the values 'strict match' and 'loose match' in the query message to indicate what type of behavior is desired? ---------- assignedto: hannes messages: 6 nosy: ecrit, hannes priority: critical status: unread title: Service URN in Response Message __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ 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 Jun 05 16:29:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLhi-00008B-Go; Mon, 05 Jun 2006 16:29:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLhh-000086-4J for ecrit@ietf.org; Mon, 05 Jun 2006 16:29:37 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnLhf-0003Gf-Kt for ecrit@ietf.org; Mon, 05 Jun 2006 16:29:37 -0400 Received: (qmail invoked by alias); 05 Jun 2006 20:29:32 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp006) with SMTP; 05 Jun 2006 22:29:32 +0200 X-Authenticated: #29516787 Message-ID: <44849423.8010904@gmx.net> Date: Mon, 05 Jun 2006 22:29:23 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] [issue4] Service URN in Response Message References: <1149533815.28.0.96627716085.issue4@http://www.tschofenig.priv.at> <44848D45.4040005@cs.columbia.edu> In-Reply-To: <44848D45.4040005@cs.columbia.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Henning, Henning Schulzrinne wrote: > If we assume that there's a "list services" method, would we still need > this? I wasn't quite sure whether there is an agreement for such a 'list services' functionality. Have you seen enough interest in this funcationality? Here is his original text: >> Ted argued: >> " >> I think the rest of Brian's cases are, in essence, default mappings, >> where one >> service (e.g. sos.police) is doing double duty as something else (e.g >> sos). I >> would also argue that it would be better in that case to populate the >> default URN (sos)'s LoST data with the same data as (sos.police) >> as a direct, effective way of handling that. >> " Ciao Hannes > > Maybe it would help to define a usage scenario, as participants in this > discussion may have different ideas. > > One additional item of discussion that we seemed to agree on was that > the server could provide PSAP information for a more specialized service > even if it was the same as the more general service. For example, in the > US, the PSAP information for sos.fire would always return the same > information as sos.police (and as just plain sos) as long as all these > emergency requests get routed to a single PSAP, regardless of the nature > of the emergency. (This isn't quite true for all sos services even in > the US, as poison-control gets routed elsewhere.) Does this directly relate to Ted's proposal where he wants to respond to a query to sos.fire even if there is only the generic service sos by linking the sos data items to sos.fire? Ciao Hannes > > Hannes Tschofenig wrote: > >> Hannes Tschofenig added the comment: >> >> I went through the mailing list about this issue again. The mailing >> discussion started around >> http://www1.ietf.org/mail-archive/web/ecrit/current/msg01964.html >> > >> Henning Schulzrinne wrote: >> >>> On May 17, 2006, at 8:05 PM, Thomson, Martin wrote: >>> >>>> I don't have a problem with asking for sub-services. For instance, >>>> I know >> >> about urn:service:massage, but I might like to know that >> urn:service:massage.swedish exists. That's valuable. >> >>>> Of course, the advantage with what we have currently is that this >>>> feature >> >> can be added later. If it isn't necessary, then we can leave it until >> we don't have more pressing problems to address. >> >>> >>> Indeed - that's a separate query. >>> >>>> Q: If I try to resolve urn:service:sos.fire and it doesn't exist, >>>> can the >> >> LoST server unilaterally return the result for urn:service:sos? >> >>> >>> I suppose, as a hint, although I'm a bit worried about the complexity >>> once >> >> you generalize this. Imagine that we have more than two levels of >> service descriptions (urn:service:sos.fire.cats_in_trees). Should the >> result include the whole tree above the (non-existing) service? >> >>> I think a better approach is to have the client do the "list >>> subservices" >> >> query, and then query for those subservices. Less guesswork and >> special cases. >> >>> Henning >> >> >> >> >> >> Ted argued: >> " >> I think the rest of Brian's cases are, in essence, default mappings, >> where one >> service (e.g. sos.police) is doing double duty as something else (e.g >> sos). I >> would also argue that it would be better in that case to populate the >> default URN (sos)'s LoST data with the same data as (sos.police) >> as a direct, effective way of handling that. >> " >> >> Hannes responded: " >> Doing this you wouldn't even need to return the service urn with the >> LoST response since it would match the query. " >> >> ---------- >> status: unread -> chatting >> >> __________________________________________________ >> LoST Issue Tracker >> >> __________________________________________________ >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 16:32:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLkK-00013Q-K5; Mon, 05 Jun 2006 16:32:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLkK-00013L-3v for ecrit@ietf.org; Mon, 05 Jun 2006 16:32:20 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnLkI-0003rH-QR for ecrit@ietf.org; Mon, 05 Jun 2006 16:32:20 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FnLkA-0002Dc-87; Mon, 05 Jun 2006 15:32:10 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Andrew Newton'" Subject: RE: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfo into the query? Date: Mon, 5 Jun 2006 16:32:14 -0400 Message-ID: <023201c688df$231e9850$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: AcaI21h2iDDpoiz/SgC8Q1DZtrmzpgAA2mcw In-reply-to: <44848C23.6060701@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: 4adaf050708fb13be3316a9eee889caa Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think this is the issue. There is no guidance we can give the server to tell it how to resolve what to do when both locations are valid but the URI for the geo does match the URI for the civic. This happens a lot when you are near boundaries because the precision and accuracy of the two methods differ. I think you pick ONE and use it. Even if you send more than one along, the PSAP has to know which one you used to route. It's going to continue to use that until a human says otherwise. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, June 05, 2006 3:55 PM To: Andrew Newton Cc: ecrit@ietf.org Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfo into the query? At the PSAP, we have a human that can look at this information and make decisions (and maybe even ask if there's a discrepancy). That seems a stretch for the LoST server. Andrew Newton wrote: > > On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: >> In all of these dual-information cases, I don't see how anybody except >> the seeker can make any determination which type of information is >> better, more accurate, more recent, etc. > > Would we want the seeker to determine which information it feels is best > to provide to the PSAP? I've always heard that the answer would be no: > provide both to the PSAP. So why then would we not provide the same > information when determining which PSAP to contact? > > -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 Mon Jun 05 16:34:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLlv-0001rJ-C0; Mon, 05 Jun 2006 16:33:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLlu-0001pC-AQ for ecrit@ietf.org; Mon, 05 Jun 2006 16:33:58 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnLlr-0004DS-S8 for ecrit@ietf.org; Mon, 05 Jun 2006 16:33:58 -0400 Received: (qmail invoked by alias); 05 Jun 2006 20:33:54 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp001) with SMTP; 05 Jun 2006 22:33:54 +0200 X-Authenticated: #29516787 Message-ID: <4484953B.4000402@gmx.net> Date: Mon, 05 Jun 2006 22:34:03 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] [issue4] Service URN in Response Message References: <1149519501.05.0.914916605883.issue4@http://www.tschofenig.priv.at> <44849179.1090208@cs.columbia.edu> In-Reply-To: <44849179.1090208@cs.columbia.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Henning, Henning Schulzrinne wrote: > I think this is related to the issue of the other thread, regarding > defaults. It is similar but there is a difference: * 'Default' means that the LoST client does not provide a service URN and the LoST server just assumes that there is a default value for it. * The 'service URN' in the response message addresses the error handling where the requested service is not available but the LoST server can use another service instead (e.g., sos instead of sos.fire). > > I don't think the querier actually cares whether the PSAP for sos.fire > and sos.police happens to be the same. > > Thus, I think this is purely a server configuration issue where the > server database is set up to return a default value for unknown > emergency services. This seems to be the case in practice today: even in > places where there are separate numbers for various services, if you > don't know whom to call for a "non-standard" emergency, you'd probably > call the police. With your description it would not make sense to return the service URN in the response message if we assume that the querier does not care about this aspect. Would this be OK for you? Ciao Hannes > > Hannes Tschofenig wrote: > >> New submission from Hannes Tschofenig : >> >> In the current LoST draft we return a service URN in the response >> message. The current text says: >> " >> If a more specific service is requested but does not exist, >> information for the more generic service SHOULD be returned. For >> example, a request for urn:service:sos.fire might return >> urn:service:sos in the United States since citizens in that country >> reach the fire department through the common emergency service. >> " >> >> In the response message the service URN attribute/element then >> contains the URN that was used in the matching process. >> Two questions: >> >> * Is this "error" handling mechanism useful? >> * Do we want to include a query-type attribute with the values 'strict >> match' and 'loose match' in the query message to indicate what type of >> behavior is desired? >> >> ---------- >> assignedto: hannes >> messages: 6 >> nosy: ecrit, hannes >> priority: critical >> status: unread >> title: Service URN in Response Message >> >> __________________________________________________ >> LoST Issue Tracker >> >> __________________________________________________ >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 16:34:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLmk-00034k-Sa; Mon, 05 Jun 2006 16:34:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLmj-0002zA-CU for ecrit@ietf.org; Mon, 05 Jun 2006 16:34: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 1FnLZb-0002v1-AL for ecrit@ietf.org; Mon, 05 Jun 2006 16:21:15 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FnLIE-0005Vm-AQ for ecrit@ietf.org; Mon, 05 Jun 2006 16:03:20 -0400 Received: from lion.cs.columbia.edu (IDENT:oVilz3MEsosuneJLDu67BxjfuYV436Jq@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k55K3FX6004895 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 5 Jun 2006 16:03:16 -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 k55K3FBB004233 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Jun 2006 16:03:15 -0400 Message-ID: <44848DFE.8040409@cs.columbia.edu> Date: Mon, 05 Jun 2006 16:03:10 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: LoST Issue Tracker , ecrit@ietf.org Subject: Re: [Ecrit] [issue6] 'Authority' Attribute in LoST Response References: <1149530190.74.0.24969342146.issue6@http://www.tschofenig.priv.at> In-Reply-To: <1149530190.74.0.24969342146.issue6@http://www.tschofenig.priv.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: -1.9 (-) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I suppose it could be an IETF enterprise identifier (since these are free and there's already a registry). I'm not quite sure what you'd do with this information. I think we talked about a "bug reporting" address, or possibly several (http:, mailto:, sip:, etc.), at the interim meeting, but that may be a separate feature. Hannes Tschofenig wrote: > New submission from Hannes Tschofenig : > > ECON-IRIS defined an 'authority' attribute in the response message. > > This attribute provides information about the authoritive source of the mapping > data. > > Question: Is it useful to provide such information in a LoST response? > What information would be a good identifier for an authoritive source? > > ---------- > assignedto: hannes > messages: 8 > nosy: ecrit, hannes > priority: critical > status: unread > title: 'Authority' Attribute in LoST Response > > __________________________________________________ > LoST Issue Tracker > > __________________________________________________ > > _______________________________________________ > 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 Jun 05 16:35:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLnO-0003Ou-U5; Mon, 05 Jun 2006 16:35:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLnN-0003Op-F4 for ecrit@ietf.org; Mon, 05 Jun 2006 16:35:29 -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 1FnLnM-0004pM-1N for ecrit@ietf.org; Mon, 05 Jun 2006 16:35:29 -0400 Received: (qmail invoked by alias); 05 Jun 2006 20:35:26 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp035) with SMTP; 05 Jun 2006 22:35:26 +0200 X-Authenticated: #29516787 Message-ID: <44849595.1080008@gmx.net> Date: Mon, 05 Jun 2006 22:35:33 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] [issue4] Service URN in Response Message References: <023101c688de$ad2f3ff0$640fa8c0@cis.neustar.com> In-Reply-To: <023101c688de$ad2f3ff0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Brian, Brian Rosen wrote: > Yes, I think it's necessary. You requested one thing, you got another. You > should be told what you got. Hmmm. Minor disagreement with Henning. > > No, I don't think we need to provide options for strict/loose match. OK. > > Brian Ciao Hannes > > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@siemens.com] > Sent: Monday, June 05, 2006 10:58 AM > To: ecrit@ietf.org > Subject: [Ecrit] [issue4] Service URN in Response Message > > > New submission from Hannes Tschofenig : > > In the current LoST draft we return a service URN in the response message. > The current text says: > > " > If a more specific service is requested but does not exist, > information for the more generic service SHOULD be returned. For > example, a request for urn:service:sos.fire might return > urn:service:sos in the United States since citizens in that country > reach the fire department through the common emergency service. > " > > In the response message the service URN attribute/element then contains the > URN that was used in the matching process. > > Two questions: > > * Is this "error" handling mechanism useful? > * Do we want to include a query-type attribute with the values 'strict > match' > and 'loose match' in the query message to indicate what type of behavior is > desired? > > ---------- > assignedto: hannes > messages: 6 > nosy: ecrit, hannes > priority: critical > status: unread > title: Service URN in Response Message > > __________________________________________________ > LoST Issue Tracker > > __________________________________________________ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 16:35:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLnh-0003aQ-4I; Mon, 05 Jun 2006 16:35:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLng-0003a4-GQ for ecrit@ietf.org; Mon, 05 Jun 2006 16:35:48 -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 1FnLZJ-0002v1-Ca for ecrit@ietf.org; Mon, 05 Jun 2006 16:20:57 -0400 Received: from can.cs.columbia.edu ([128.59.16.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FnLSX-0005gb-AH for ecrit@ietf.org; Mon, 05 Jun 2006 16:14:01 -0400 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by can.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k55KDroD000460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 5 Jun 2006 16:13:53 -0400 (EDT) Received: from lion.cs.columbia.edu (IDENT:Rf/kIaZ9eivU67MBU6QAs7tVT3OBbhye@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k55KDoX6008176 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 5 Jun 2006 16:13:51 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k55KDoBB005175 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Jun 2006 16:13:50 -0400 Message-ID: <44849079.2080507@cs.columbia.edu> Date: Mon, 05 Jun 2006 16:13:45 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: LoST Issue Tracker Subject: Re: [Ecrit] [issue5] PSAP Boundary Hint References: <1149529321.43.0.303860432851.issue5@http://www.tschofenig.priv.at> In-Reply-To: <1149529321.43.0.303860432851.issue5@http://www.tschofenig.priv.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: -2.3 (--) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The only reason not to include it would be to save space in the response. In mobile cases, the client would almost always have to query for this anyway, to know when to ask for a mapping again, so I don't see much advantage of keeping it separate as the total protocol overhead would only increase. As to civic: This is actually fairly easy if we remember that the boundary region doesn't have to be complete. In other words, returning a subregion is harmless and just results in some additional queries that wouldn't be strictly necessary. Thus, if almost the whole county is covered by a PSAP, you'd just return the next-lower A* level (municipality), even though this is a subset of the actual coverage region. Since civic information is most useful for nomadic and stationary devices and these devices don't tend to move more than a few times a day, the impact on query load will be modest. If we adopt this approach, the descriptor for a civic region is likely to be small and thus there doesn't seem to be a reason to have another special query. Henning Hannes Tschofenig wrote: > New submission from Hannes Tschofenig : > > The response message may provide information about the PSAP boundary. > > First question: Should the LoST client indicate whether it wants to have the > PSAP boundary as hint included in the response message? Alternatively, we could > include this information per-default in a mobility environment (see Geopriv-L7 > discussion). > > Current protocol proposals focused on the distribution of a polygon (when > geospatial location information is used in the query) to express the PSAP > boundary. > > Second question: While it is quite simple what to return for geospatial > location information it seems to be more complicated for civic location > information. Has someone already thought about civic info? Is there existing > work outside the IETF we can leverage? > > ---------- > assignedto: hannes > messages: 7 > nosy: ecrit, hannes > priority: critical > status: unread > title: PSAP Boundary Hint > > __________________________________________________ > LoST Issue Tracker > > __________________________________________________ > > _______________________________________________ > 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 Jun 05 16:35:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLnq-0003fF-AJ; Mon, 05 Jun 2006 16:35:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLnp-0003fA-J2 for ecrit@ietf.org; Mon, 05 Jun 2006 16:35:57 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnLno-0004vZ-8t for ecrit@ietf.org; Mon, 05 Jun 2006 16:35:57 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FnLng-0002TN-8D; Mon, 05 Jun 2006 15:35:48 -0500 From: "Brian Rosen" To: "'LoST Issue Tracker'" , Subject: RE: [Ecrit] [issue3] List all Services Functionality Date: Mon, 5 Jun 2006 16:35:52 -0400 Message-ID: <023c01c688df$a50dfe00$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: AcaI1piG9AK3wG0uTW+vOdtUPjM/WQACKi6A In-reply-to: <1149535427.95.0.97800587706.issue3@http://www.tschofenig.priv.at> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I don't think that the "pretty print" thing is in LoST. I think there is a requirement on LoST to enumerate the services it has URIs for given a location. I think Henning doesn't want just to return the tree; he wants at most a subtree, and maybe just a list (just one level below the specified start point). Brian -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@siemens.com] Sent: Monday, June 05, 2006 3:24 PM To: ecrit@ietf.org Subject: [Ecrit] [issue3] List all Services Functionality Hannes Tschofenig added the comment: The ability to use LoST to list services it supports was discussed in the past already. Here are some example discussion snippets hidden somewhere in this mailing list thread: http://www1.ietf.org/mail-archive/web/ecrit/current/msg01964.html Brian Rosen wrote: >> I would imagine that there would be, somewhere, some kind of a "pretty >> print" description of what these services are. The phone would access this >> along with the list of service urns available at their location and offer an >> interesting GUI for what it finds. >> Brian Henning Schulzrinne wrote: > I agree with Brian. > > It seems quite common for GSM phones to show a text message indicating "welcome to Teluristan; you can get concierge services at *311 and can talk to our sales rep at *411." when roaming into a new country or service area. The problem with these messages is that they are not structured, so there is no easy way for them to be integrated into the phone's address book, for example. With the service listing proposed, this would be fairly straightforward. Given the generic URN service names, it would also make it easy to have symbols or visitor-language descriptions on the phone. Thus, tourists could always easily access the local version of the poison control center, for example, even if they have no clue that they'd dial 1-800-222-1222 in the US for that. > > Henning ---------- status: unread -> chatting __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ 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 Jun 05 16:38:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLqd-0004QP-OY; Mon, 05 Jun 2006 16:38:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLqc-0004O9-Je for ecrit@ietf.org; Mon, 05 Jun 2006 16:38:50 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnLqb-0005VL-5v for ecrit@ietf.org; Mon, 05 Jun 2006 16:38:50 -0400 Received: (qmail invoked by alias); 05 Jun 2006 20:38:47 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp015) with SMTP; 05 Jun 2006 22:38:47 +0200 X-Authenticated: #29516787 Message-ID: <44849660.9060906@gmx.net> Date: Mon, 05 Jun 2006 22:38:56 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfo into the query? References: <023201c688df$231e9850$640fa8c0@cis.neustar.com> In-Reply-To: <023201c688df$231e9850$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org It seems that we closed this issue. Everyone seems to be in favor for a civic OR geospatial. Extensions possible for future applications. Ciao Hannes Brian Rosen wrote: > I think this is the issue. There is no guidance we can give the server to > tell it how to resolve what to do when both locations are valid but the URI > for the geo does match the URI for the civic. > > This happens a lot when you are near boundaries because the precision and > accuracy of the two methods differ. > > I think you pick ONE and use it. > > Even if you send more than one along, the PSAP has to know which one you > used to route. It's going to continue to use that until a human says > otherwise. > > Brian > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, June 05, 2006 3:55 PM > To: Andrew Newton > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and > geospatialinfo into the query? > > At the PSAP, we have a human that can look at this information and make > decisions (and maybe even ask if there's a discrepancy). That seems a > stretch for the LoST server. > > Andrew Newton wrote: > >>On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: >> >>>In all of these dual-information cases, I don't see how anybody except >>>the seeker can make any determination which type of information is >>>better, more accurate, more recent, etc. >> >>Would we want the seeker to determine which information it feels is best >>to provide to the PSAP? I've always heard that the answer would be no: >>provide both to the PSAP. So why then would we not provide the same >>information when determining which PSAP to contact? >> >>-andy > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 16:42:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLtk-0006tN-Nc; Mon, 05 Jun 2006 16:42:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLtf-0006pE-Q1 for ecrit@ietf.org; Mon, 05 Jun 2006 16:41:59 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnLte-0006Gg-GB for ecrit@ietf.org; Mon, 05 Jun 2006 16:41:59 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FnLtW-0002pN-5y; Mon, 05 Jun 2006 15:41:50 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'LoST Issue Tracker'" , Subject: RE: [Ecrit] [issue6] 'Authority' Attribute in LoST Response Date: Mon, 5 Jun 2006 16:41:54 -0400 Message-ID: <024701c688e0$7cc7ab70$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: AcaI33w7NLFWA09MSBWIQDukAPyhegAALnIw In-reply-to: <44848DFE.8040409@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: 82c9bddb247d9ba4471160a9a865a5f3 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 reason you want it is to provide a way to report an error. I think it's essential. I think you need a URI, which could be a website or an email address. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, June 05, 2006 4:03 PM To: LoST Issue Tracker; ecrit@ietf.org Subject: Re: [Ecrit] [issue6] 'Authority' Attribute in LoST Response I suppose it could be an IETF enterprise identifier (since these are free and there's already a registry). I'm not quite sure what you'd do with this information. I think we talked about a "bug reporting" address, or possibly several (http:, mailto:, sip:, etc.), at the interim meeting, but that may be a separate feature. Hannes Tschofenig wrote: > New submission from Hannes Tschofenig : > > ECON-IRIS defined an 'authority' attribute in the response message. > > This attribute provides information about the authoritive source of the mapping > data. > > Question: Is it useful to provide such information in a LoST response? > What information would be a good identifier for an authoritive source? > > ---------- > assignedto: hannes > messages: 8 > nosy: ecrit, hannes > priority: critical > status: unread > title: 'Authority' Attribute in LoST Response > > __________________________________________________ > LoST Issue Tracker > > __________________________________________________ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 16:43:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLuk-0007xE-Rd; Mon, 05 Jun 2006 16:43:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLuj-0007v1-FV for ecrit@ietf.org; Mon, 05 Jun 2006 16:43:05 -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 1FnLui-0006Ln-13 for ecrit@ietf.org; Mon, 05 Jun 2006 16:43:05 -0400 Received: (qmail invoked by alias); 05 Jun 2006 20:43:02 -0000 Received: from p54985901.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.89.1] by mail.gmx.net (mp036) with SMTP; 05 Jun 2006 22:43:02 +0200 X-Authenticated: #29516787 Message-ID: <44849760.4000103@gmx.net> Date: Mon, 05 Jun 2006 22:43:12 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] [issue3] List all Services Functionality References: <023c01c688df$a50dfe00$640fa8c0@cis.neustar.com> In-Reply-To: <023c01c688df$a50dfe00$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Brian, Brian Rosen wrote: > I don't think that the "pretty print" thing is in LoST. I know. I think there is a > requirement on LoST to enumerate the services it has URIs for given a > location. Fine. I think Henning doesn't want just to return the tree; he wants at > most a subtree, and maybe just a list (just one level below the specified > start point). We could return the full subtree based with the service URN provided as a starting point for the search. Ciao Hannes > > Brian > > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@siemens.com] > Sent: Monday, June 05, 2006 3:24 PM > To: ecrit@ietf.org > Subject: [Ecrit] [issue3] List all Services Functionality > > > Hannes Tschofenig added the comment: > > The ability to use LoST to list services it supports was discussed in the > past > already. Here are some example discussion snippets hidden somewhere in this > mailing list thread: > http://www1.ietf.org/mail-archive/web/ecrit/current/msg01964.html > > > > Brian Rosen wrote: > > >>>I would imagine that there would be, somewhere, some kind of a "pretty >>>print" description of what these services are. The phone would access > > this > >>>along with the list of service urns available at their location and > > offer an > >>>interesting GUI for what it finds. >>>Brian > > > > Henning Schulzrinne wrote: > > >>I agree with Brian. >> >>It seems quite common for GSM phones to show a text message > > indicating "welcome to Teluristan; you can get concierge services at *311 > and > can talk to our sales rep at *411." when roaming into a new country or > service > area. The problem with these messages is that they are not structured, so > there is no easy way for them to be integrated into the phone's address > book, > for example. With the service listing proposed, this would be fairly > straightforward. Given the generic URN service names, it would also make it > > easy to have symbols or visitor-language descriptions on the phone. Thus, > tourists could always easily access the local version of the poison control > > center, for example, even if they have no clue that they'd dial > 1-800-222-1222 > in the US for that. > >>Henning > > > ---------- > status: unread -> chatting > > __________________________________________________ > LoST Issue Tracker > > __________________________________________________ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 16:44:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLvq-0008HX-Vd; Mon, 05 Jun 2006 16:44:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLvp-0008HS-NR for ecrit@ietf.org; Mon, 05 Jun 2006 16:44:13 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnLvo-0006cW-9a for ecrit@ietf.org; Mon, 05 Jun 2006 16:44:13 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Mon, 5 Jun 2006 13:44:11 -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] [issue2] Is it allowed to specify civic and geospatialinfointo the query? Date: Mon, 5 Jun 2006 13:44:10 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575051312D0@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfointo the query? Thread-Index: AcaI4BSzbwvFLs03QUKFoZvcfsyjQQAADCMA From: "Roger Marshall" To: "Hannes Tschofenig" , "Brian Rosen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I don't disagree that we ask the LoST server to pick one and use it. =20 We need to be consistent though, and so therefore, I propose that the LoST server always picks the geo over the civic and returns a flag in the response stating that the geo was used to perform mapping. Roger. >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 >Sent: Monday, June 05, 2006 1:39 PM >To: Brian Rosen >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic=20 >and geospatialinfointo the query? > >It seems that we closed this issue. > >Everyone seems to be in favor for a civic OR geospatial. >Extensions possible for future applications. > >Ciao >Hannes > >Brian Rosen wrote: >> I think this is the issue. There is no guidance we can give the=20 >> server to tell it how to resolve what to do when both locations are=20 >> valid but the URI for the geo does match the URI for the civic. >>=20 >> This happens a lot when you are near boundaries because the=20 >precision=20 >> and accuracy of the two methods differ. >>=20 >> I think you pick ONE and use it. >>=20 >> Even if you send more than one along, the PSAP has to know which one=20 >> you used to route. It's going to continue to use that until a human=20 >> says otherwise. >>=20 >> Brian >>=20 >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Monday, June 05, 2006 3:55 PM >> To: Andrew Newton >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and=20 >> geospatialinfo into the query? >>=20 >> At the PSAP, we have a human that can look at this information and=20 >> make decisions (and maybe even ask if there's a discrepancy). That=20 >> seems a stretch for the LoST server. >>=20 >> Andrew Newton wrote: >>=20 >>>On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: >>> >>>>In all of these dual-information cases, I don't see how anybody=20 >>>>except the seeker can make any determination which type of=20 >>>>information is better, more accurate, more recent, etc. >>> >>>Would we want the seeker to determine which information it feels is=20 >>>best to provide to the PSAP? I've always heard that the=20 >answer would be no: >>>provide both to the PSAP. So why then would we not provide the same=20 >>>information when determining which PSAP to contact? >>> >>>-andy >>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 16:46:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLyQ-0000H2-Nh; Mon, 05 Jun 2006 16:46:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLyP-0000Gx-EB for ecrit@ietf.org; Mon, 05 Jun 2006 16:46:53 -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 1FnLyO-0007B9-0P for ecrit@ietf.org; Mon, 05 Jun 2006 16:46:53 -0400 Received: (qmail invoked by alias); 05 Jun 2006 20:46:50 -0000 Received: from p54985901.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.89.1] by mail.gmx.net (mp039) with SMTP; 05 Jun 2006 22:46:50 +0200 X-Authenticated: #29516787 Message-ID: <44849844.8080705@gmx.net> Date: Mon, 05 Jun 2006 22:47:00 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] [issue6] 'Authority' Attribute in LoST Response References: <024701c688e0$7cc7ab70$640fa8c0@cis.neustar.com> In-Reply-To: <024701c688e0$7cc7ab70$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Brian, Brian Rosen wrote: > The reason you want it is to provide a way to report an error. > I think it's essential. > > I think you need a URI, which could be a website or an email address. > > Brian I wanted to go through the interim meeting minutes where we discussed this type of error case as a separate item. I think it is a separate scenario. I think we need to describe the use cases we have in mind in more detail. Andy mentioned referall loops and you another error case. Ciao Hannes > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, June 05, 2006 4:03 PM > To: LoST Issue Tracker; ecrit@ietf.org > Subject: Re: [Ecrit] [issue6] 'Authority' Attribute in LoST Response > > I suppose it could be an IETF enterprise identifier (since these are > free and there's already a registry). > > I'm not quite sure what you'd do with this information. I think we > talked about a "bug reporting" address, or possibly several (http:, > mailto:, sip:, etc.), at the interim meeting, but that may be a separate > feature. > > Hannes Tschofenig wrote: > >>New submission from Hannes Tschofenig : >> >>ECON-IRIS defined an 'authority' attribute in the response message. >> >>This attribute provides information about the authoritive source of the > > mapping > >>data. >> >>Question: Is it useful to provide such information in a LoST response? >>What information would be a good identifier for an authoritive source? >> >>---------- >>assignedto: hannes >>messages: 8 >>nosy: ecrit, hannes >>priority: critical >>status: unread >>title: 'Authority' Attribute in LoST Response >> >>__________________________________________________ >>LoST Issue Tracker >> >>__________________________________________________ >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 16:48:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnM02-0001OA-8S; Mon, 05 Jun 2006 16:48:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnM01-0001I6-Cw for ecrit@ietf.org; Mon, 05 Jun 2006 16:48:33 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnLzz-0007TC-UD for ecrit@ietf.org; Mon, 05 Jun 2006 16:48:33 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Mon, 5 Jun 2006 13:48:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] [issue3] List all Services Functionality Date: Mon, 5 Jun 2006 13:48:30 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575051312E4@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [issue3] List all Services Functionality Thread-Index: AcaI4Ke4I2NkTCb2TM+H00LTOljxegAAKeog From: "Roger Marshall" To: "Hannes Tschofenig" , "Brian Rosen" X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f 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 support the notion of returning a sub-tree. -roger. >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 >Sent: Monday, June 05, 2006 1:43 PM >To: Brian Rosen >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] [issue3] List all Services Functionality > >Hi Brian, > >Brian Rosen wrote: >> I don't think that the "pretty print" thing is in LoST. > >I know. > > I think there is a >> requirement on LoST to enumerate the services it has URIs=20 >for given a=20 >> location. > >Fine. > > I think Henning doesn't want just to return the tree; he wants at >> most a subtree, and maybe just a list (just one level below the=20 >> specified start point). > >We could return the full subtree based with the service URN=20 >provided as a starting point for the search. > >Ciao >Hannes > > >>=20 >> Brian >>=20 >> -----Original Message----- >> From: Hannes Tschofenig [mailto:hannes.tschofenig@siemens.com] >> Sent: Monday, June 05, 2006 3:24 PM >> To: ecrit@ietf.org >> Subject: [Ecrit] [issue3] List all Services Functionality >>=20 >>=20 >> Hannes Tschofenig added the comment: >>=20 >> The ability to use LoST to list services it supports was=20 >discussed in=20 >> the past already. Here are some example discussion snippets hidden=20 >> somewhere in this mailing list thread: >> http://www1.ietf.org/mail-archive/web/ecrit/current/msg01964.html >>=20 >>=20 >>=20 >> Brian Rosen wrote: >>=20 >>=20 >>>>I would imagine that there would be, somewhere, some kind of a =20 >>>>"pretty print" description of what these services are. The phone=20 >>>>would access >>=20 >> this >>=20 >>>>along with the list of service urns available at their location and >>=20 >> offer an >>=20 >>>>interesting GUI for what it finds. >>>>Brian >>=20 >>=20 >>=20 >> Henning Schulzrinne wrote: >>=20 >>=20 >>>I agree with Brian. >>> >>>It seems quite common for GSM phones to show a text message >>=20 >> indicating "welcome to Teluristan; you can get concierge=20 >services at=20 >> *311 and can talk to our sales rep at *411." when roaming=20 >into a new=20 >> country or service area. The problem with these messages is =20 >that they=20 >> are not structured, so there is no easy way for them to be=20 >integrated=20 >> into the phone's address book, for example. With the =20 >service listing=20 >> proposed, this would be fairly straightforward. Given the=20 >generic URN=20 >> service names, it would also make it >>=20 >> easy to have symbols or visitor-language descriptions on the phone.=20 >> Thus, tourists could always easily access the local version of the=20 >> poison control >>=20 >> center, for example, even if they have no clue that they'd dial >> 1-800-222-1222 >> in the US for that. >>=20 >>>Henning >>=20 >>=20 >> ---------- >> status: unread -> chatting >>=20 >> __________________________________________________ >> LoST Issue Tracker =20 >> >> __________________________________________________ >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 16:49:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnM16-0004VA-5r; Mon, 05 Jun 2006 16:49:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnM14-0004U7-IM for ecrit@ietf.org; Mon, 05 Jun 2006 16:49:38 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnM13-00081U-3q for ecrit@ietf.org; Mon, 05 Jun 2006 16:49:38 -0400 Received: (qmail invoked by alias); 05 Jun 2006 20:49:35 -0000 Received: from p54985901.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.89.1] by mail.gmx.net (mp012) with SMTP; 05 Jun 2006 22:49:35 +0200 X-Authenticated: #29516787 Message-ID: <448498E8.9040500@gmx.net> Date: Mon, 05 Jun 2006 22:49:44 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfointo the query? References: <8C837214C95C864C9F34F3635C2A6575051312D0@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A6575051312D0@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Roger, I think the current suggestion is that the LoST client just picks whatever he wants and then uses the mapping protocol to trigger the resolution. Using geo and civic might be, from a certain point of view, just be an optimization. The LoST client can always trigger separate queries with all the location info it has. Ciao Hannes Roger Marshall wrote: > I don't disagree that we ask the LoST server to pick one and use it. > > We need to be consistent though, and so therefore, I propose that the > LoST server always picks the geo over the civic and returns a flag in > the response stating that the geo was used to perform mapping. > > Roger. > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: Monday, June 05, 2006 1:39 PM >>To: Brian Rosen >>Cc: ecrit@ietf.org >>Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic >>and geospatialinfointo the query? >> >>It seems that we closed this issue. >> >>Everyone seems to be in favor for a civic OR geospatial. >>Extensions possible for future applications. >> >>Ciao >>Hannes >> >>Brian Rosen wrote: >> >>>I think this is the issue. There is no guidance we can give the >>>server to tell it how to resolve what to do when both locations are >>>valid but the URI for the geo does match the URI for the civic. >>> >>>This happens a lot when you are near boundaries because the >> >>precision >> >>>and accuracy of the two methods differ. >>> >>>I think you pick ONE and use it. >>> >>>Even if you send more than one along, the PSAP has to know which one >>>you used to route. It's going to continue to use that until a human >>>says otherwise. >>> >>>Brian >>> >>>-----Original Message----- >>>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>Sent: Monday, June 05, 2006 3:55 PM >>>To: Andrew Newton >>>Cc: ecrit@ietf.org >>>Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >>>geospatialinfo into the query? >>> >>>At the PSAP, we have a human that can look at this information and >>>make decisions (and maybe even ask if there's a discrepancy). That >>>seems a stretch for the LoST server. >>> >>>Andrew Newton wrote: >>> >>> >>>>On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: >>>> >>>> >>>>>In all of these dual-information cases, I don't see how anybody >>>>>except the seeker can make any determination which type of >>>>>information is better, more accurate, more recent, etc. >>>> >>>>Would we want the seeker to determine which information it feels is >>>>best to provide to the PSAP? I've always heard that the >> >>answer would be no: >> >>>>provide both to the PSAP. So why then would we not provide the same >>>>information when determining which PSAP to contact? >>>> >>>>-andy >>> >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >> >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >> > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 16:59:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMAg-00059V-Ll; Mon, 05 Jun 2006 16:59:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMAf-000597-Qm for ecrit@ietf.org; Mon, 05 Jun 2006 16:59:33 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnMAd-0001uM-5T for ecrit@ietf.org; Mon, 05 Jun 2006 16:59:33 -0400 Received: (qmail invoked by alias); 05 Jun 2006 20:59:30 -0000 Received: from p54985901.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.89.1] by mail.gmx.net (mp010) with SMTP; 05 Jun 2006 22:59:30 +0200 X-Authenticated: #29516787 Message-ID: <44849B3B.8080505@gmx.net> Date: Mon, 05 Jun 2006 22:59:39 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ecrit] LoST Issue Tracker X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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 setup an issue tracker for LoST, as you might have noticed based on the posting that are forwarded to the mailing list. Please find the issue tracker at: http://www.ietf-ecrit.org:8080/lost/ Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 17:01:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMCU-0006Sz-1V; Mon, 05 Jun 2006 17:01:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMCS-0006Sp-Vb for ecrit@ietf.org; Mon, 05 Jun 2006 17:01:24 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnMCR-0002CR-PB for ecrit@ietf.org; Mon, 05 Jun 2006 17:01:24 -0400 Received: from lion.cs.columbia.edu (IDENT:lSBJIwxZlowGA0gdkLxLuWkFv9DxEwac@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k55L11X6022004 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 5 Jun 2006 17:01:21 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k55L11BB009303 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Jun 2006 17:01:01 -0400 Message-ID: <44849B88.8050003@cs.columbia.edu> Date: Mon, 05 Jun 2006 17:00:56 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: LoST Issue Tracker Subject: Re: [Ecrit] [issue3] List all Services Functionality References: <1149517716.58.0.667094320653.issue3@http://www.tschofenig.priv.at> In-Reply-To: <1149517716.58.0.667094320653.issue3@http://www.tschofenig.priv.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes Tschofenig wrote: > New submission from Hannes Tschofenig : > > Do we need the capability to list all services supported by the LoST server? I don't think every server needs to support this, but it does seem useful. > Would this feature be useful if the service list is constraint to a certain > branch of the tree? By the current design, each top-level service can have a different LoST server, so I suppose the only question is whether only (1) urn:service:sos or also (2) urn:service:sos.fire [all servies and more deeply-nested URNs should be a query input. My inclination is to support both, although I could easily be convinced that keeping it simple and only supporting one type of query (as in (1)) is sufficient. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 17:07:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMIZ-0003rp-V7; Mon, 05 Jun 2006 17:07:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMIY-0003ri-NR for ecrit@ietf.org; Mon, 05 Jun 2006 17:07:42 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnMIY-0002T7-84 for ecrit@ietf.org; Mon, 05 Jun 2006 17:07:42 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Mon, 5 Jun 2006 14:07:41 -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] [issue2] Is it allowed to specify civic and geospatialinfointo the query? Date: Mon, 5 Jun 2006 14:07:40 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750513132A@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfointo the query? Thread-Index: AcaI4ZBc7DC/l2x7RLae6xWGROfYUwAAFbYw From: "Roger Marshall" To: "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes: Thanks for clarifying. =20 I think it's a bad idea to withold location information from the LoST server. To suggest that we restrict the client, allowing only one to be sent, sounds to me like we're placing a constraint on the PIDF-LO, saying it can't have both (assuming LoST reuses the PIDF-LO). I don't think we can get away with that. If the PIDF-LO has both, how is it that we can glibly strip one out? To do so would be unreasonable. Since the client can have both civic and geo in the PIDF-LO, it can also send both to the server. What am I missing? =20 It's the LoST server's job to pick one, not the client's. So, the requirement I would support is as follows: Rx' LoST client SHALL query with either civic or geo. =20 Ry' LoST client SHOULD query with *both* civic and geo. When LoST server receives both civic and geo, the server SHOULD try to use the geo first. The LoST server response SHALL indicate which data was used (either geo or civic).=20 -roger. >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 >Sent: Monday, June 05, 2006 1:50 PM >To: Roger Marshall >Cc: Brian Rosen; ecrit@ietf.org >Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic=20 >and geospatialinfointo the query? > >Hi Roger, > >I think the current suggestion is that the LoST client just=20 >picks whatever he wants and then uses the mapping protocol to=20 >trigger the resolution. > >Using geo and civic might be, from a certain point of view,=20 >just be an optimization. The LoST client can always trigger=20 >separate queries with all the location info it has. > >Ciao >Hannes > >Roger Marshall wrote: >> I don't disagree that we ask the LoST server to pick one and=20 >use it. =20 >>=20 >> We need to be consistent though, and so therefore, I propose=20 >that the=20 >> LoST server always picks the geo over the civic and returns=20 >a flag in=20 >> the response stating that the geo was used to perform mapping. >>=20 >> Roger. >>=20 >>=20 >>>-----Original Message----- >>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>Sent: Monday, June 05, 2006 1:39 PM >>>To: Brian Rosen >>>Cc: ecrit@ietf.org >>>Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and=20 >>>geospatialinfointo the query? >>> >>>It seems that we closed this issue. >>> >>>Everyone seems to be in favor for a civic OR geospatial. >>>Extensions possible for future applications. >>> >>>Ciao >>>Hannes >>> >>>Brian Rosen wrote: >>> >>>>I think this is the issue. There is no guidance we can give the=20 >>>>server to tell it how to resolve what to do when both=20 >locations are=20 >>>>valid but the URI for the geo does match the URI for the civic. >>>> >>>>This happens a lot when you are near boundaries because the >>> >>>precision >>> >>>>and accuracy of the two methods differ. >>>> >>>>I think you pick ONE and use it. >>>> >>>>Even if you send more than one along, the PSAP has to know=20 >which one=20 >>>>you used to route. It's going to continue to use that=20 >until a human=20 >>>>says otherwise. >>>> >>>>Brian >>>> >>>>-----Original Message----- >>>>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>Sent: Monday, June 05, 2006 3:55 PM >>>>To: Andrew Newton >>>>Cc: ecrit@ietf.org >>>>Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and=20 >>>>geospatialinfo into the query? >>>> >>>>At the PSAP, we have a human that can look at this information and=20 >>>>make decisions (and maybe even ask if there's a discrepancy). That=20 >>>>seems a stretch for the LoST server. >>>> >>>>Andrew Newton wrote: >>>> >>>> >>>>>On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: >>>>> >>>>> >>>>>>In all of these dual-information cases, I don't see how anybody=20 >>>>>>except the seeker can make any determination which type of=20 >>>>>>information is better, more accurate, more recent, etc. >>>>> >>>>>Would we want the seeker to determine which information it=20 >feels is=20 >>>>>best to provide to the PSAP? I've always heard that the >>> >>>answer would be no: >>> >>>>>provide both to the PSAP. So why then would we not=20 >provide the same=20 >>>>>information when determining which PSAP to contact? >>>>> >>>>>-andy >>>> >>>> >>>>_______________________________________________ >>>>Ecrit mailing list >>>>Ecrit@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>>>_______________________________________________ >>>>Ecrit mailing list >>>>Ecrit@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>> >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ecrit >>> >>=20 >>=20 >>=20 > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 17:18:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMT3-0006AJ-97; Mon, 05 Jun 2006 17:18:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMT1-00069m-DP for ecrit@ietf.org; Mon, 05 Jun 2006 17:18:31 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnMT1-0002mz-2Y for ecrit@ietf.org; Mon, 05 Jun 2006 17:18:31 -0400 Received: from lion.cs.columbia.edu (IDENT:aDGkUPMpIIb6wqJTB5gQYmsc9DawPPSX@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k55LIGX6027681 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 5 Jun 2006 17:18: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 k55LICBB010500 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Jun 2006 17:18:16 -0400 Message-ID: <44849F8F.6090908@cs.columbia.edu> Date: Mon, 05 Jun 2006 17:18:07 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfointo the query? References: <8C837214C95C864C9F34F3635C2A65750513132A@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A65750513132A@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d 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 problem is that in some cases, your algorithm would not work, as civic information might be more recent or accurate (e.g., Skyhook geo information might only have 200' accuracy). I see no loss in functionality, and gains in expressiveness, to have the client choose which information it wants the server to use. If it wants to get information for both, it can query twice. Having both just adds more special cases, error conditions, processing rules. Anything with a SHOULD in it means that we'll have some servers behave differently, i.e., making the behavior unpredictable. In my view, SHOULDs SHOULD be avoided at all cost :-) Roger Marshall wrote: > Hannes: Thanks for clarifying. > > I think it's a bad idea to withold location information from the LoST > server. > > To suggest that we restrict the client, allowing only one to be sent, > sounds to me like we're placing a constraint on the PIDF-LO, saying it > can't have both (assuming LoST reuses the PIDF-LO). I don't think we > can get away with that. If the PIDF-LO has both, how is it that we can > glibly strip one out? To do so would be unreasonable. > > Since the client can have both civic and geo in the PIDF-LO, it can also > send both to the server. What am I missing? > > It's the LoST server's job to pick one, not the client's. > > So, the requirement I would support is as follows: > > Rx' LoST client SHALL query with either civic or geo. > Ry' LoST client SHOULD query with *both* civic and geo. When LoST > server receives both civic and geo, the server SHOULD try to use the geo > first. The LoST server response SHALL indicate which data was used > (either geo or civic). > > -roger. > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Monday, June 05, 2006 1:50 PM >> To: Roger Marshall >> Cc: Brian Rosen; ecrit@ietf.org >> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic >> and geospatialinfointo the query? >> >> Hi Roger, >> >> I think the current suggestion is that the LoST client just >> picks whatever he wants and then uses the mapping protocol to >> trigger the resolution. >> >> Using geo and civic might be, from a certain point of view, >> just be an optimization. The LoST client can always trigger >> separate queries with all the location info it has. >> >> Ciao >> Hannes >> >> Roger Marshall wrote: >>> I don't disagree that we ask the LoST server to pick one and >> use it. >>> We need to be consistent though, and so therefore, I propose >> that the >>> LoST server always picks the geo over the civic and returns >> a flag in >>> the response stating that the geo was used to perform mapping. >>> >>> Roger. >>> >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Monday, June 05, 2006 1:39 PM >>>> To: Brian Rosen >>>> Cc: ecrit@ietf.org >>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >>>> geospatialinfointo the query? >>>> >>>> It seems that we closed this issue. >>>> >>>> Everyone seems to be in favor for a civic OR geospatial. >>>> Extensions possible for future applications. >>>> >>>> Ciao >>>> Hannes >>>> >>>> Brian Rosen wrote: >>>> >>>>> I think this is the issue. There is no guidance we can give the >>>>> server to tell it how to resolve what to do when both >> locations are >>>>> valid but the URI for the geo does match the URI for the civic. >>>>> >>>>> This happens a lot when you are near boundaries because the >>>> precision >>>> >>>>> and accuracy of the two methods differ. >>>>> >>>>> I think you pick ONE and use it. >>>>> >>>>> Even if you send more than one along, the PSAP has to know >> which one >>>>> you used to route. It's going to continue to use that >> until a human >>>>> says otherwise. >>>>> >>>>> Brian >>>>> >>>>> -----Original Message----- >>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>> Sent: Monday, June 05, 2006 3:55 PM >>>>> To: Andrew Newton >>>>> Cc: ecrit@ietf.org >>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >>>>> geospatialinfo into the query? >>>>> >>>>> At the PSAP, we have a human that can look at this information and >>>>> make decisions (and maybe even ask if there's a discrepancy). That >>>>> seems a stretch for the LoST server. >>>>> >>>>> Andrew Newton wrote: >>>>> >>>>> >>>>>> On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: >>>>>> >>>>>> >>>>>>> In all of these dual-information cases, I don't see how anybody >>>>>>> except the seeker can make any determination which type of >>>>>>> information is better, more accurate, more recent, etc. >>>>>> Would we want the seeker to determine which information it >> feels is >>>>>> best to provide to the PSAP? I've always heard that the >>>> answer would be no: >>>> >>>>>> provide both to the PSAP. So why then would we not >> provide the same >>>>>> information when determining which PSAP to contact? >>>>>> >>>>>> -andy >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>> >>> >>> >> > > _______________________________________________ > 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 Jun 05 17:23:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMYG-00044v-EZ; Mon, 05 Jun 2006 17:23:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMYF-00043d-2F for ecrit@ietf.org; Mon, 05 Jun 2006 17:23:55 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnMYE-0002xY-Iv for ecrit@ietf.org; Mon, 05 Jun 2006 17:23:55 -0400 Received: (qmail invoked by alias); 05 Jun 2006 21:23:53 -0000 Received: from p54985901.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.89.1] by mail.gmx.net (mp001) with SMTP; 05 Jun 2006 23:23:53 +0200 X-Authenticated: #29516787 Message-ID: <4484A0F2.50304@gmx.net> Date: Mon, 05 Jun 2006 23:24:02 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfointo the query? References: <8C837214C95C864C9F34F3635C2A65750513132A@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A65750513132A@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Roger, Roger Marshall wrote: > Hannes: Thanks for clarifying. > > I think it's a bad idea to withold location information from the LoST > server. > > To suggest that we restrict the client, allowing only one to be sent, > sounds to me like we're placing a constraint on the PIDF-LO, saying it > can't have both (assuming LoST reuses the PIDF-LO). I don't think we > can get away with that. If the PIDF-LO has both, how is it that we can > glibly strip one out? To do so would be unreasonable. To clarify: * You can send as many queries as you want but not with the same message. Different location information => different query * We don't use a PIDF-LO in LoST. We use the raw location info. > > Since the client can have both civic and geo in the PIDF-LO, it can also > send both to the server. What am I missing? None of the proposals ever used a PIDF-LO as input; just location info. > > It's the LoST server's job to pick one, not the client's. At the PSAP and the emergency routing proxy I agree with you. > > So, the requirement I would support is as follows: > > Rx' LoST client SHALL query with either civic or geo. That's fine. > Ry' LoST client SHOULD query with *both* civic and geo. When LoST > server receives both civic and geo, the server SHOULD try to use the geo > first. The LoST server response SHALL indicate which data was used > (either geo or civic). I guess you will not support for this one based on the response I saw on the list so far. Ciao Hannes > > -roger. > > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: Monday, June 05, 2006 1:50 PM >>To: Roger Marshall >>Cc: Brian Rosen; ecrit@ietf.org >>Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic >>and geospatialinfointo the query? >> >>Hi Roger, >> >>I think the current suggestion is that the LoST client just >>picks whatever he wants and then uses the mapping protocol to >>trigger the resolution. >> >>Using geo and civic might be, from a certain point of view, >>just be an optimization. The LoST client can always trigger >>separate queries with all the location info it has. >> >>Ciao >>Hannes >> >>Roger Marshall wrote: >> >>>I don't disagree that we ask the LoST server to pick one and >> >>use it. >> >>>We need to be consistent though, and so therefore, I propose >> >>that the >> >>>LoST server always picks the geo over the civic and returns >> >>a flag in >> >>>the response stating that the geo was used to perform mapping. >>> >>>Roger. >>> >>> >>> >>>>-----Original Message----- >>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>Sent: Monday, June 05, 2006 1:39 PM >>>>To: Brian Rosen >>>>Cc: ecrit@ietf.org >>>>Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >>>>geospatialinfointo the query? >>>> >>>>It seems that we closed this issue. >>>> >>>>Everyone seems to be in favor for a civic OR geospatial. >>>>Extensions possible for future applications. >>>> >>>>Ciao >>>>Hannes >>>> >>>>Brian Rosen wrote: >>>> >>>> >>>>>I think this is the issue. There is no guidance we can give the >>>>>server to tell it how to resolve what to do when both >> >>locations are >> >>>>>valid but the URI for the geo does match the URI for the civic. >>>>> >>>>>This happens a lot when you are near boundaries because the >>>> >>>>precision >>>> >>>> >>>>>and accuracy of the two methods differ. >>>>> >>>>>I think you pick ONE and use it. >>>>> >>>>>Even if you send more than one along, the PSAP has to know >> >>which one >> >>>>>you used to route. It's going to continue to use that >> >>until a human >> >>>>>says otherwise. >>>>> >>>>>Brian >>>>> >>>>>-----Original Message----- >>>>>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>>Sent: Monday, June 05, 2006 3:55 PM >>>>>To: Andrew Newton >>>>>Cc: ecrit@ietf.org >>>>>Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >>>>>geospatialinfo into the query? >>>>> >>>>>At the PSAP, we have a human that can look at this information and >>>>>make decisions (and maybe even ask if there's a discrepancy). That >>>>>seems a stretch for the LoST server. >>>>> >>>>>Andrew Newton wrote: >>>>> >>>>> >>>>> >>>>>>On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: >>>>>> >>>>>> >>>>>> >>>>>>>In all of these dual-information cases, I don't see how anybody >>>>>>>except the seeker can make any determination which type of >>>>>>>information is better, more accurate, more recent, etc. >>>>>> >>>>>>Would we want the seeker to determine which information it >> >>feels is >> >>>>>>best to provide to the PSAP? I've always heard that the >>>> >>>>answer would be no: >>>> >>>> >>>>>>provide both to the PSAP. So why then would we not >> >>provide the same >> >>>>>>information when determining which PSAP to contact? >>>>>> >>>>>>-andy >>>>> >>>>> >>>>>_______________________________________________ >>>>>Ecrit mailing list >>>>>Ecrit@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> >>>>>_______________________________________________ >>>>>Ecrit mailing list >>>>>Ecrit@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> >>>> >>>> >>>>_______________________________________________ >>>>Ecrit mailing list >>>>Ecrit@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/ecrit >>>> >>> >>> >>> >> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 17:24:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMZA-0005CS-QR; Mon, 05 Jun 2006 17:24:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMZ9-00055s-16 for ecrit@ietf.org; Mon, 05 Jun 2006 17:24:51 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnMZ7-0002zH-Qr for ecrit@ietf.org; Mon, 05 Jun 2006 17:24:51 -0400 Received: from lion.cs.columbia.edu (IDENT:qISd7IGAIrecu3o1keGDW6dpMhsv8wAZ@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k55LNPX6028935 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 5 Jun 2006 17:23:47 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k55LNPBB010820 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Jun 2006 17:23:25 -0400 Message-ID: <4484A0C8.7030805@cs.columbia.edu> Date: Mon, 05 Jun 2006 17:23:20 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] [issue4] Service URN in Response Message References: <023101c688de$ad2f3ff0$640fa8c0@cis.neustar.com> <44849595.1080008@gmx.net> In-Reply-To: <44849595.1080008@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.4 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org >> Yes, I think it's necessary. You requested one thing, you got >> another. You >> should be told what you got. I'm not sure that's really the case. It would be the case if you requested urn:service:pizza-delivery and somehow got an answer for urn:service:weightloss, but, here, we seem to be talking about the case that a single PSAP handles multiple types of emergencies and that there's no separate PSAP record for the type of emergency you requested. > > Hmmm. Minor disagreement with Henning. > >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 17:25:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMZi-0005qb-33; Mon, 05 Jun 2006 17:25:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMZg-0005qW-5u for ecrit@ietf.org; Mon, 05 Jun 2006 17:25:24 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnMZe-00030C-TJ for ecrit@ietf.org; Mon, 05 Jun 2006 17:25:24 -0400 Received: from lion.cs.columbia.edu (IDENT:9b/K3pk1fZ3WNJ1Vr6fKEDrB3P8fsnnG@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k55LLMX6028573 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 5 Jun 2006 17:24:28 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k55LLLBB010803 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Jun 2006 17:21:22 -0400 Message-ID: <4484A04C.7080600@cs.columbia.edu> Date: Mon, 05 Jun 2006 17:21:16 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] [issue6] 'Authority' Attribute in LoST Response References: <024701c688e0$7cc7ab70$640fa8c0@cis.neustar.com> In-Reply-To: <024701c688e0$7cc7ab70$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Brian Rosen wrote: > The reason you want it is to provide a way to report an error. > I think it's essential. > > I think you need a URI, which could be a website or an email address. That's what I suggested, except to allow multiple URIs if you want to easily provide multiple means of contact without having to fish them out of a web page. (For example, an automated checker of some kind might want to report problems via an email interface, rather than screen-scrape a web form.) Dealing with referral loops is a very different issue and probably not addressed by including authority information. In some cases, revisiting the same server or authority may be the right thing to do (see "SIP spirals" for a version of that issue). > > Brian > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, June 05, 2006 4:03 PM > To: LoST Issue Tracker; ecrit@ietf.org > Subject: Re: [Ecrit] [issue6] 'Authority' Attribute in LoST Response > > I suppose it could be an IETF enterprise identifier (since these are > free and there's already a registry). > > I'm not quite sure what you'd do with this information. I think we > talked about a "bug reporting" address, or possibly several (http:, > mailto:, sip:, etc.), at the interim meeting, but that may be a separate > feature. > > Hannes Tschofenig wrote: >> New submission from Hannes Tschofenig : >> >> ECON-IRIS defined an 'authority' attribute in the response message. >> >> This attribute provides information about the authoritive source of the > mapping >> data. >> >> Question: Is it useful to provide such information in a LoST response? >> What information would be a good identifier for an authoritive source? >> >> ---------- >> assignedto: hannes >> messages: 8 >> nosy: ecrit, hannes >> priority: critical >> status: unread >> title: 'Authority' Attribute in LoST Response >> >> __________________________________________________ >> LoST Issue Tracker >> >> __________________________________________________ >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 17:25:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMa8-00062g-CI; Mon, 05 Jun 2006 17:25:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMa7-00062a-GC for ecrit@ietf.org; Mon, 05 Jun 2006 17:25:51 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnMa6-00030q-8L for ecrit@ietf.org; Mon, 05 Jun 2006 17:25:51 -0400 Received: from lion.cs.columbia.edu (IDENT:g9PsHm/tchLpXi+aWuNyrffaaRye4mwj@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k55LPXX6029691 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 5 Jun 2006 17:25:46 -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 k55LPWBB011123 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Jun 2006 17:25:33 -0400 Message-ID: <4484A148.4080001@cs.columbia.edu> Date: Mon, 05 Jun 2006 17:25:28 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] [issue4] Service URN in Response Message References: <1149519501.05.0.914916605883.issue4@http://www.tschofenig.priv.at> <44849179.1090208@cs.columbia.edu> <4484953B.4000402@gmx.net> In-Reply-To: <4484953B.4000402@gmx.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'd like to better understand the model that people have in mind, where this condition would actually occur and where this information would actually be useful to the querier. (I don't think the querier needs to know which emergency services happen to all land on the same PSAP in a particular area.) >> Thus, I think this is purely a server configuration issue where the >> server database is set up to return a default value for unknown >> emergency services. This seems to be the case in practice today: even >> in places where there are separate numbers for various services, if >> you don't know whom to call for a "non-standard" emergency, you'd >> probably call the police. > > With your description it would not make sense to return the service URN > in the response message if we assume that the querier does not care > about this aspect. Would this be OK for you? > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 17:35:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMjU-00033Z-3y; Mon, 05 Jun 2006 17:35:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMjT-00033U-Jr for ecrit@ietf.org; Mon, 05 Jun 2006 17:35:31 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnMjT-0003nT-3D for ecrit@ietf.org; Mon, 05 Jun 2006 17:35:31 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Mon, 5 Jun 2006 14:35:28 -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] [issue2] Is it allowed to specify civic and geospatialinfointo the query? Date: Mon, 5 Jun 2006 14:35:28 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657505131385@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfointo the query? Thread-Index: AcaI5lp1c/tuZa5hT/ONoqt8qgHEvAAAPcjA From: "Roger Marshall" To: "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af 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 Seems like a lot of programmatic overhead being built in to the LoST client... how to parse the original PIDF-LO, how to pick between multiple tuples, etc. How many LoST clients are there go to be? Millions? >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 >Sent: Monday, June 05, 2006 2:24 PM >To: Roger Marshall >Cc: Brian Rosen; ecrit@ietf.org >Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic=20 >and geospatialinfointo the query? > >Hi Roger, > >Roger Marshall wrote: >> Hannes: Thanks for clarifying. =20 >>=20 >> I think it's a bad idea to withold location information from=20 >the LoST=20 >> server. >>=20 >> To suggest that we restrict the client, allowing only one to=20 >be sent,=20 >> sounds to me like we're placing a constraint on the PIDF-LO,=20 >saying it=20 >> can't have both (assuming LoST reuses the PIDF-LO). I don't think we >> can get away with that. If the PIDF-LO has both, how is it=20 >that we can >> glibly strip one out? To do so would be unreasonable. > >To clarify: > >* You can send as many queries as you want but not with the=20 >same message. Different location information =3D> different query > >* We don't use a PIDF-LO in LoST. We use the raw location info. > >>=20 >> Since the client can have both civic and geo in the PIDF-LO, it can=20 >> also send both to the server. What am I missing? > >None of the proposals ever used a PIDF-LO as input; just location info. > >>=20 >> It's the LoST server's job to pick one, not the client's. > >At the PSAP and the emergency routing proxy I agree with you. > >>=20 >> So, the requirement I would support is as follows: >>=20 >> Rx' LoST client SHALL query with either civic or geo. > >That's fine. > > >> Ry' LoST client SHOULD query with *both* civic and geo. When LoST=20 >> server receives both civic and geo, the server SHOULD try to use the=20 >> geo first. The LoST server response SHALL indicate which data was=20 >> used (either geo or civic). > >I guess you will not support for this one based on the=20 >response I saw on the list so far. > >Ciao >Hannes > >>=20 >> -roger. >>=20 >>=20 >>=20 >>>-----Original Message----- >>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>Sent: Monday, June 05, 2006 1:50 PM >>>To: Roger Marshall >>>Cc: Brian Rosen; ecrit@ietf.org >>>Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and=20 >>>geospatialinfointo the query? >>> >>>Hi Roger, >>> >>>I think the current suggestion is that the LoST client just picks=20 >>>whatever he wants and then uses the mapping protocol to trigger the=20 >>>resolution. >>> >>>Using geo and civic might be, from a certain point of view,=20 >just be an=20 >>>optimization. The LoST client can always trigger separate=20 >queries with=20 >>>all the location info it has. >>> >>>Ciao >>>Hannes >>> >>>Roger Marshall wrote: >>> >>>>I don't disagree that we ask the LoST server to pick one and >>> >>>use it. =20 >>> >>>>We need to be consistent though, and so therefore, I propose >>> >>>that the >>> >>>>LoST server always picks the geo over the civic and returns >>> >>>a flag in >>> >>>>the response stating that the geo was used to perform mapping. >>>> >>>>Roger. >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>Sent: Monday, June 05, 2006 1:39 PM >>>>>To: Brian Rosen >>>>>Cc: ecrit@ietf.org >>>>>Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and=20 >>>>>geospatialinfointo the query? >>>>> >>>>>It seems that we closed this issue. >>>>> >>>>>Everyone seems to be in favor for a civic OR geospatial. >>>>>Extensions possible for future applications. >>>>> >>>>>Ciao >>>>>Hannes >>>>> >>>>>Brian Rosen wrote: >>>>> >>>>> >>>>>>I think this is the issue. There is no guidance we can give the=20 >>>>>>server to tell it how to resolve what to do when both >>> >>>locations are >>> >>>>>>valid but the URI for the geo does match the URI for the civic. >>>>>> >>>>>>This happens a lot when you are near boundaries because the >>>>> >>>>>precision >>>>> >>>>> >>>>>>and accuracy of the two methods differ. >>>>>> >>>>>>I think you pick ONE and use it. >>>>>> >>>>>>Even if you send more than one along, the PSAP has to know >>> >>>which one >>> >>>>>>you used to route. It's going to continue to use that >>> >>>until a human >>> >>>>>>says otherwise. >>>>>> >>>>>>Brian >>>>>> >>>>>>-----Original Message----- >>>>>>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>>>Sent: Monday, June 05, 2006 3:55 PM >>>>>>To: Andrew Newton >>>>>>Cc: ecrit@ietf.org >>>>>>Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and=20 >>>>>>geospatialinfo into the query? >>>>>> >>>>>>At the PSAP, we have a human that can look at this=20 >information and=20 >>>>>>make decisions (and maybe even ask if there's a=20 >discrepancy). That=20 >>>>>>seems a stretch for the LoST server. >>>>>> >>>>>>Andrew Newton wrote: >>>>>> >>>>>> >>>>>> >>>>>>>On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>>In all of these dual-information cases, I don't see how anybody=20 >>>>>>>>except the seeker can make any determination which type of=20 >>>>>>>>information is better, more accurate, more recent, etc. >>>>>>> >>>>>>>Would we want the seeker to determine which information it >>> >>>feels is >>> >>>>>>>best to provide to the PSAP? I've always heard that the >>>>> >>>>>answer would be no: >>>>> >>>>> >>>>>>>provide both to the PSAP. So why then would we not >>> >>>provide the same >>> >>>>>>>information when determining which PSAP to contact? >>>>>>> >>>>>>>-andy >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Ecrit mailing list >>>>>>Ecrit@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Ecrit mailing list >>>>>>Ecrit@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Ecrit mailing list >>>>>Ecrit@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/ecrit >>>>> >>>> >>>> >>>> >>> >>=20 >>=20 > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 17:39:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMmz-0003Q5-Jk; Mon, 05 Jun 2006 17:39:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMmz-0003Q0-8U for ecrit@ietf.org; Mon, 05 Jun 2006 17:39:09 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnMmy-0004Wj-Iw for ecrit@ietf.org; Mon, 05 Jun 2006 17:39:09 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 05 Jun 2006 14:39:08 -0700 X-IronPort-AV: i="4.05,212,1146466800"; d="scan'208"; a="289152929:sNHT112784046" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k55Ld4vD010125; Mon, 5 Jun 2006 14:39:04 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k55Ld49s025253; Mon, 5 Jun 2006 14:39:04 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Jun 2006 14:39:04 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Jun 2006 14:39:03 -0700 From: "Marc Linsner" To: "'Hannes Tschofenig'" Subject: RE: [Ecrit] [issue2] Is it allowed to specify civicand geospatialinfointo the query? Date: Mon, 5 Jun 2006 17:39:01 -0400 Message-ID: <003001c688e8$772bfec0$2c0d0d0a@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: <4484A0F2.50304@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaI5l69qufWevg7RsOr1RoHAsNpMgAAQa1g X-OriginalArrivalTime: 05 Jun 2006 21:39:04.0194 (UTC) FILETIME=[774CA620:01C688E8] DKIM-Signature: a=rsa-sha1; q=dns; l=6591; t=1149543544; x=1150407544; c=relaxed/simple; s=sjdkim4001; 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]=20[issue2]=20Is=20it=20allowed=20to=20specify=20civicand =09geospatialinfointo=20the=20query?; X=v=3Dcisco.com=3B=20h=3Dp/XbRvyDc+zjtYgVmedhTVu4aA0=3D; b=QaQ+Q9lDD7YcYJjoFZZ4xp2weTh7bywF4qdWpExuUYHZEHm2XpzBkc8Rhzcv+DEKcHghEQ0S CZCCAZzDIwT32HlYv6xdC5B7eAApAuqOf1KYwf4OWbigtoJQQCCTc6WM; 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: ce732c7d36989a1bd55104ba259c40a1 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 agree, the LoST client submits one location at a time. No decisions made by LoST server/service. -Marc- > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Monday, June 05, 2006 5:24 PM > To: Roger Marshall > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] [issue2] Is it allowed to specify > civicand geospatialinfointo the query? > > Hi Roger, > > Roger Marshall wrote: > > Hannes: Thanks for clarifying. > > > > I think it's a bad idea to withold location information > from the LoST > > server. > > > > To suggest that we restrict the client, allowing only one > to be sent, > > sounds to me like we're placing a constraint on the > PIDF-LO, saying it > > can't have both (assuming LoST reuses the PIDF-LO). I > don't think we > > can get away with that. If the PIDF-LO has both, how is > it that we can > > glibly strip one out? To do so would be unreasonable. > > To clarify: > > * You can send as many queries as you want but not with the > same message. Different location information => different query > > * We don't use a PIDF-LO in LoST. We use the raw location info. > > > > > Since the client can have both civic and geo in the PIDF-LO, it can > > also send both to the server. What am I missing? > > None of the proposals ever used a PIDF-LO as input; just > location info. > > > > > It's the LoST server's job to pick one, not the client's. > > At the PSAP and the emergency routing proxy I agree with you. > > > > > So, the requirement I would support is as follows: > > > > Rx' LoST client SHALL query with either civic or geo. > > That's fine. > > > > Ry' LoST client SHOULD query with *both* civic and geo. When LoST > > server receives both civic and geo, the server SHOULD try > to use the > > geo first. The LoST server response SHALL indicate which data was > > used (either geo or civic). > > I guess you will not support for this one based on the > response I saw on the list so far. > > Ciao > Hannes > > > > > -roger. > > > > > > > >>-----Original Message----- > >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>Sent: Monday, June 05, 2006 1:50 PM > >>To: Roger Marshall > >>Cc: Brian Rosen; ecrit@ietf.org > >>Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and > >>geospatialinfointo the query? > >> > >>Hi Roger, > >> > >>I think the current suggestion is that the LoST client just picks > >>whatever he wants and then uses the mapping protocol to trigger the > >>resolution. > >> > >>Using geo and civic might be, from a certain point of view, > just be an > >>optimization. The LoST client can always trigger separate > queries with > >>all the location info it has. > >> > >>Ciao > >>Hannes > >> > >>Roger Marshall wrote: > >> > >>>I don't disagree that we ask the LoST server to pick one and > >> > >>use it. > >> > >>>We need to be consistent though, and so therefore, I propose > >> > >>that the > >> > >>>LoST server always picks the geo over the civic and returns > >> > >>a flag in > >> > >>>the response stating that the geo was used to perform mapping. > >>> > >>>Roger. > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>Sent: Monday, June 05, 2006 1:39 PM > >>>>To: Brian Rosen > >>>>Cc: ecrit@ietf.org > >>>>Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and > >>>>geospatialinfointo the query? > >>>> > >>>>It seems that we closed this issue. > >>>> > >>>>Everyone seems to be in favor for a civic OR geospatial. > >>>>Extensions possible for future applications. > >>>> > >>>>Ciao > >>>>Hannes > >>>> > >>>>Brian Rosen wrote: > >>>> > >>>> > >>>>>I think this is the issue. There is no guidance we can give the > >>>>>server to tell it how to resolve what to do when both > >> > >>locations are > >> > >>>>>valid but the URI for the geo does match the URI for the civic. > >>>>> > >>>>>This happens a lot when you are near boundaries because the > >>>> > >>>>precision > >>>> > >>>> > >>>>>and accuracy of the two methods differ. > >>>>> > >>>>>I think you pick ONE and use it. > >>>>> > >>>>>Even if you send more than one along, the PSAP has to know > >> > >>which one > >> > >>>>>you used to route. It's going to continue to use that > >> > >>until a human > >> > >>>>>says otherwise. > >>>>> > >>>>>Brian > >>>>> > >>>>>-----Original Message----- > >>>>>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>>>>Sent: Monday, June 05, 2006 3:55 PM > >>>>>To: Andrew Newton > >>>>>Cc: ecrit@ietf.org > >>>>>Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and > >>>>>geospatialinfo into the query? > >>>>> > >>>>>At the PSAP, we have a human that can look at this > information and > >>>>>make decisions (and maybe even ask if there's a > discrepancy). That > >>>>>seems a stretch for the LoST server. > >>>>> > >>>>>Andrew Newton wrote: > >>>>> > >>>>> > >>>>> > >>>>>>On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>>In all of these dual-information cases, I don't see > how anybody > >>>>>>>except the seeker can make any determination which type of > >>>>>>>information is better, more accurate, more recent, etc. > >>>>>> > >>>>>>Would we want the seeker to determine which information it > >> > >>feels is > >> > >>>>>>best to provide to the PSAP? I've always heard that the > >>>> > >>>>answer would be no: > >>>> > >>>> > >>>>>>provide both to the PSAP. So why then would we not > >> > >>provide the same > >> > >>>>>>information when determining which PSAP to contact? > >>>>>> > >>>>>>-andy > >>>>> > >>>>> > >>>>>_______________________________________________ > >>>>>Ecrit mailing list > >>>>>Ecrit@ietf.org > >>>>>https://www1.ietf.org/mailman/listinfo/ecrit > >>>>> > >>>>> > >>>>>_______________________________________________ > >>>>>Ecrit mailing list > >>>>>Ecrit@ietf.org > >>>>>https://www1.ietf.org/mailman/listinfo/ecrit > >>>>> > >>>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>Ecrit mailing list > >>>>Ecrit@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/ecrit > >>>> > >>> > >>> > >>> > >> > > > > > > > _______________________________________________ > 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 Jun 05 17:49:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMwt-0004TV-QZ; Mon, 05 Jun 2006 17:49:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMws-0004TQ-By for ecrit@ietf.org; Mon, 05 Jun 2006 17:49:22 -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 1FnMwr-0005pZ-5O for ecrit@ietf.org; Mon, 05 Jun 2006 17:49:22 -0400 Received: from [10.0.1.103] ([::ffff:68.106.115.242]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 05 Jun 2006 17:49:49 -0400 id 0158C102.4484A6FD.00004698 In-Reply-To: <4484A04C.7080600@cs.columbia.edu> References: <024701c688e0$7cc7ab70$640fa8c0@cis.neustar.com> <4484A04C.7080600@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] [issue6] 'Authority' Attribute in LoST Response Date: Mon, 5 Jun 2006 17:49:20 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 5, 2006, at 5:21 PM, Henning Schulzrinne wrote: > > > Brian Rosen wrote: >> The reason you want it is to provide a way to report an error. >> I think it's essential. >> I think you need a URI, which could be a website or an email address. > > That's what I suggested, except to allow multiple URIs if you want > to easily provide multiple means of contact without having to fish > them out of a web page. (For example, an automated checker of some > kind might want to report problems via an email interface, rather > than screen-scrape a web form.) > > Dealing with referral loops is a very different issue and probably > not addressed by including authority information. In some cases, > revisiting the same server or authority may be the right thing to > do (see "SIP spirals" for a version of that issue). Just why would I want to ask the same question multiple times to the same server in the same seek operation? It would seem that detecting referral loops would be awfully important. The type of identifier used is not that important, so a URI is fine by me. I'm not sure about multiple URIs. Also, you'd need to define a much more detailed interface for automated checking than "here is a bunch of URIs". -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 17:58:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnN5S-0007Su-EC; Mon, 05 Jun 2006 17:58:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnN5R-0007Sp-Ht for ecrit@ietf.org; Mon, 05 Jun 2006 17:58:13 -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 1FnN5R-0006mv-67 for ecrit@ietf.org; Mon, 05 Jun 2006 17:58:13 -0400 Received: from [10.0.1.103] ([::ffff:68.106.115.242]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 05 Jun 2006 17:58:40 -0400 id 0158C105.4484A910.00004809 In-Reply-To: <003001c688e8$772bfec0$2c0d0d0a@amer.cisco.com> References: <003001c688e8$772bfec0$2c0d0d0a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8FA03125-5A38-4DFB-9EEB-34FB29F3A5C1@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] [issue2] Is it allowed to specify civicand geospatialinfointo the query? Date: Mon, 5 Jun 2006 17:58:11 -0400 To: "Marc Linsner" X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 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 we'd have a protocol more capable of adapting to unforeseen, real world issues if both were sent and the server had the opportunity to determine which type of location it preferred. I must admit that it seems a bit of a stretch, but I think it is just as possible as Henning's idea that the client will have the same type of notion. It almost always seems to me that if ever there is a question about preference, it should fall to the LoST service operators and their jurisdictional considerations. It also seems to me that if a client or seeker does, in some odd way, have a notion of a preferred type of location when it possesses both, that it can always just send the query with only the type of location it prefers. For clients that don't have this strong notion, send both and see if the server has a preference. -andy On Jun 5, 2006, at 5:39 PM, Marc Linsner wrote: > I agree, the LoST client submits one location at a time. No > decisions made > by LoST server/service. > > -Marc- > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Monday, June 05, 2006 5:24 PM >> To: Roger Marshall >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] [issue2] Is it allowed to specify >> civicand geospatialinfointo the query? >> >> Hi Roger, >> >> Roger Marshall wrote: >>> Hannes: Thanks for clarifying. >>> >>> I think it's a bad idea to withold location information >> from the LoST >>> server. >>> >>> To suggest that we restrict the client, allowing only one >> to be sent, >>> sounds to me like we're placing a constraint on the >> PIDF-LO, saying it >>> can't have both (assuming LoST reuses the PIDF-LO). I >> don't think we >>> can get away with that. If the PIDF-LO has both, how is >> it that we can >>> glibly strip one out? To do so would be unreasonable. >> >> To clarify: >> >> * You can send as many queries as you want but not with the >> same message. Different location information => different query >> >> * We don't use a PIDF-LO in LoST. We use the raw location info. >> >>> >>> Since the client can have both civic and geo in the PIDF-LO, it can >>> also send both to the server. What am I missing? >> >> None of the proposals ever used a PIDF-LO as input; just >> location info. >> >>> >>> It's the LoST server's job to pick one, not the client's. >> >> At the PSAP and the emergency routing proxy I agree with you. >> >>> >>> So, the requirement I would support is as follows: >>> >>> Rx' LoST client SHALL query with either civic or geo. >> >> That's fine. >> >> >>> Ry' LoST client SHOULD query with *both* civic and geo. When LoST >>> server receives both civic and geo, the server SHOULD try >> to use the >>> geo first. The LoST server response SHALL indicate which data was >>> used (either geo or civic). >> >> I guess you will not support for this one based on the >> response I saw on the list so far. >> >> Ciao >> Hannes >> >>> >>> -roger. >>> >>> >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Monday, June 05, 2006 1:50 PM >>>> To: Roger Marshall >>>> Cc: Brian Rosen; ecrit@ietf.org >>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >>>> geospatialinfointo the query? >>>> >>>> Hi Roger, >>>> >>>> I think the current suggestion is that the LoST client just picks >>>> whatever he wants and then uses the mapping protocol to trigger the >>>> resolution. >>>> >>>> Using geo and civic might be, from a certain point of view, >> just be an >>>> optimization. The LoST client can always trigger separate >> queries with >>>> all the location info it has. >>>> >>>> Ciao >>>> Hannes >>>> >>>> Roger Marshall wrote: >>>> >>>>> I don't disagree that we ask the LoST server to pick one and >>>> >>>> use it. >>>> >>>>> We need to be consistent though, and so therefore, I propose >>>> >>>> that the >>>> >>>>> LoST server always picks the geo over the civic and returns >>>> >>>> a flag in >>>> >>>>> the response stating that the geo was used to perform mapping. >>>>> >>>>> Roger. >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>> Sent: Monday, June 05, 2006 1:39 PM >>>>>> To: Brian Rosen >>>>>> Cc: ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >>>>>> geospatialinfointo the query? >>>>>> >>>>>> It seems that we closed this issue. >>>>>> >>>>>> Everyone seems to be in favor for a civic OR geospatial. >>>>>> Extensions possible for future applications. >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> Brian Rosen wrote: >>>>>> >>>>>> >>>>>>> I think this is the issue. There is no guidance we can give the >>>>>>> server to tell it how to resolve what to do when both >>>> >>>> locations are >>>> >>>>>>> valid but the URI for the geo does match the URI for the civic. >>>>>>> >>>>>>> This happens a lot when you are near boundaries because the >>>>>> >>>>>> precision >>>>>> >>>>>> >>>>>>> and accuracy of the two methods differ. >>>>>>> >>>>>>> I think you pick ONE and use it. >>>>>>> >>>>>>> Even if you send more than one along, the PSAP has to know >>>> >>>> which one >>>> >>>>>>> you used to route. It's going to continue to use that >>>> >>>> until a human >>>> >>>>>>> says otherwise. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>>>> Sent: Monday, June 05, 2006 3:55 PM >>>>>>> To: Andrew Newton >>>>>>> Cc: ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >>>>>>> geospatialinfo into the query? >>>>>>> >>>>>>> At the PSAP, we have a human that can look at this >> information and >>>>>>> make decisions (and maybe even ask if there's a >> discrepancy). That >>>>>>> seems a stretch for the LoST server. >>>>>>> >>>>>>> Andrew Newton wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> In all of these dual-information cases, I don't see >> how anybody >>>>>>>>> except the seeker can make any determination which type of >>>>>>>>> information is better, more accurate, more recent, etc. >>>>>>>> >>>>>>>> Would we want the seeker to determine which information it >>>> >>>> feels is >>>> >>>>>>>> best to provide to the PSAP? I've always heard that the >>>>>> >>>>>> answer would be no: >>>>>> >>>>>> >>>>>>>> provide both to the PSAP. So why then would we not >>>> >>>> provide the same >>>> >>>>>>>> information when determining which PSAP to contact? >>>>>>>> >>>>>>>> -andy >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 18:23:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnNTp-0005E8-SL; Mon, 05 Jun 2006 18:23:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnNTp-0005E3-0p for ecrit@ietf.org; Mon, 05 Jun 2006 18:23:25 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnNTo-0001G6-Cc for ecrit@ietf.org; Mon, 05 Jun 2006 18:23:25 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 05 Jun 2006 15:23:23 -0700 X-IronPort-AV: i="4.05,212,1146466800"; d="scan'208"; a="289180112:sNHT41001364" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k55MNNYa030003; Mon, 5 Jun 2006 15:23:23 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k55MNM9s003586; Mon, 5 Jun 2006 15:23:23 -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.211); Mon, 5 Jun 2006 15:23:22 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Jun 2006 15:23:22 -0700 From: "Marc Linsner" To: "'Andrew Newton'" Subject: RE: [Ecrit] [issue2] Is it allowed to specify civicand geospatialinfointo the query? Date: Mon, 5 Jun 2006 18:23:20 -0400 Message-ID: <003701c688ee$a78282a0$2c0d0d0a@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: <8FA03125-5A38-4DFB-9EEB-34FB29F3A5C1@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaI6zjnhQc8CUHLTvKUn0joHvMpxgAAhz/A X-OriginalArrivalTime: 05 Jun 2006 22:23:22.0344 (UTC) FILETIME=[A7AE2680:01C688EE] DKIM-Signature: a=rsa-sha1; q=dns; l=8943; t=1149546203; x=1150410203; c=relaxed/simple; s=sjdkim2001; 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]=20[issue2]=20Is=20it=20allowed=20to=20specify=20civicand =09geospatialinfointo=20the=20query?; X=v=3Dcisco.com=3B=20h=3Dp/XbRvyDc+zjtYgVmedhTVu4aA0=3D; b=GlwBbaANH2xoBqsN+iOgTdZLqTL+3B7NzlUF+Y2YFQVdZrEPOl+z47z1cFvUo9e/Uwerdw+D OTiiMp9Wzr408yPsv80Kk4k1cBTY1sT2O/Meq1Zzc9AQ6xmcFuwTMoKJ; 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: 8a4bcf8f67063cac573319207fe3db35 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 Andy, The problem is that the 'preferred' location is the accurate one. No LoST server/service will be able to determine which one is most accurate. You may equate the same problem to the client, but IMO, it's better that the client make the decision since it's closer to the human that 'should' know. -Marc- > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Monday, June 05, 2006 5:58 PM > To: Marc Linsner > Cc: 'Hannes Tschofenig'; ecrit@ietf.org > Subject: Re: [Ecrit] [issue2] Is it allowed to specify > civicand geospatialinfointo the query? > > I think we'd have a protocol more capable of adapting to > unforeseen, real world issues if both were sent and the > server had the opportunity to determine which type of > location it preferred. I must admit that it seems a bit of a > stretch, but I think it is just as possible as Henning's idea > that the client will have the same type of notion. It almost > always seems to me that if ever there is a question about > preference, it should fall to the LoST service operators and > their jurisdictional considerations. > > It also seems to me that if a client or seeker does, in some > odd way, have a notion of a preferred type of location when > it possesses both, that it can always just send the query > with only the type of location it prefers. For clients that > don't have this strong notion, send both and see if the > server has a preference. > > -andy > > > On Jun 5, 2006, at 5:39 PM, Marc Linsner wrote: > > > I agree, the LoST client submits one location at a time. > No decisions > > made by LoST server/service. > > > > -Marc- > > > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: Monday, June 05, 2006 5:24 PM > >> To: Roger Marshall > >> Cc: ecrit@ietf.org > >> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civicand > >> geospatialinfointo the query? > >> > >> Hi Roger, > >> > >> Roger Marshall wrote: > >>> Hannes: Thanks for clarifying. > >>> > >>> I think it's a bad idea to withold location information > >> from the LoST > >>> server. > >>> > >>> To suggest that we restrict the client, allowing only one > >> to be sent, > >>> sounds to me like we're placing a constraint on the > >> PIDF-LO, saying it > >>> can't have both (assuming LoST reuses the PIDF-LO). I > >> don't think we > >>> can get away with that. If the PIDF-LO has both, how is > >> it that we can > >>> glibly strip one out? To do so would be unreasonable. > >> > >> To clarify: > >> > >> * You can send as many queries as you want but not with the same > >> message. Different location information => different query > >> > >> * We don't use a PIDF-LO in LoST. We use the raw location info. > >> > >>> > >>> Since the client can have both civic and geo in the > PIDF-LO, it can > >>> also send both to the server. What am I missing? > >> > >> None of the proposals ever used a PIDF-LO as input; just location > >> info. > >> > >>> > >>> It's the LoST server's job to pick one, not the client's. > >> > >> At the PSAP and the emergency routing proxy I agree with you. > >> > >>> > >>> So, the requirement I would support is as follows: > >>> > >>> Rx' LoST client SHALL query with either civic or geo. > >> > >> That's fine. > >> > >> > >>> Ry' LoST client SHOULD query with *both* civic and geo. > When LoST > >>> server receives both civic and geo, the server SHOULD try > >> to use the > >>> geo first. The LoST server response SHALL indicate which > data was > >>> used (either geo or civic). > >> > >> I guess you will not support for this one based on the > response I saw > >> on the list so far. > >> > >> Ciao > >> Hannes > >> > >>> > >>> -roger. > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>> Sent: Monday, June 05, 2006 1:50 PM > >>>> To: Roger Marshall > >>>> Cc: Brian Rosen; ecrit@ietf.org > >>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and > >>>> geospatialinfointo the query? > >>>> > >>>> Hi Roger, > >>>> > >>>> I think the current suggestion is that the LoST client > just picks > >>>> whatever he wants and then uses the mapping protocol to > trigger the > >>>> resolution. > >>>> > >>>> Using geo and civic might be, from a certain point of view, > >> just be an > >>>> optimization. The LoST client can always trigger separate > >> queries with > >>>> all the location info it has. > >>>> > >>>> Ciao > >>>> Hannes > >>>> > >>>> Roger Marshall wrote: > >>>> > >>>>> I don't disagree that we ask the LoST server to pick one and > >>>> > >>>> use it. > >>>> > >>>>> We need to be consistent though, and so therefore, I propose > >>>> > >>>> that the > >>>> > >>>>> LoST server always picks the geo over the civic and returns > >>>> > >>>> a flag in > >>>> > >>>>> the response stating that the geo was used to perform mapping. > >>>>> > >>>>> Roger. > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>>> Sent: Monday, June 05, 2006 1:39 PM > >>>>>> To: Brian Rosen > >>>>>> Cc: ecrit@ietf.org > >>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify > civic and > >>>>>> geospatialinfointo the query? > >>>>>> > >>>>>> It seems that we closed this issue. > >>>>>> > >>>>>> Everyone seems to be in favor for a civic OR geospatial. > >>>>>> Extensions possible for future applications. > >>>>>> > >>>>>> Ciao > >>>>>> Hannes > >>>>>> > >>>>>> Brian Rosen wrote: > >>>>>> > >>>>>> > >>>>>>> I think this is the issue. There is no guidance we > can give the > >>>>>>> server to tell it how to resolve what to do when both > >>>> > >>>> locations are > >>>> > >>>>>>> valid but the URI for the geo does match the URI for > the civic. > >>>>>>> > >>>>>>> This happens a lot when you are near boundaries because the > >>>>>> > >>>>>> precision > >>>>>> > >>>>>> > >>>>>>> and accuracy of the two methods differ. > >>>>>>> > >>>>>>> I think you pick ONE and use it. > >>>>>>> > >>>>>>> Even if you send more than one along, the PSAP has to know > >>>> > >>>> which one > >>>> > >>>>>>> you used to route. It's going to continue to use that > >>>> > >>>> until a human > >>>> > >>>>>>> says otherwise. > >>>>>>> > >>>>>>> Brian > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>>>>>> Sent: Monday, June 05, 2006 3:55 PM > >>>>>>> To: Andrew Newton > >>>>>>> Cc: ecrit@ietf.org > >>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to > specify civic and > >>>>>>> geospatialinfo into the query? > >>>>>>> > >>>>>>> At the PSAP, we have a human that can look at this > >> information and > >>>>>>> make decisions (and maybe even ask if there's a > >> discrepancy). That > >>>>>>> seems a stretch for the LoST server. > >>>>>>> > >>>>>>> Andrew Newton wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> In all of these dual-information cases, I don't see > >> how anybody > >>>>>>>>> except the seeker can make any determination which type of > >>>>>>>>> information is better, more accurate, more recent, etc. > >>>>>>>> > >>>>>>>> Would we want the seeker to determine which information it > >>>> > >>>> feels is > >>>> > >>>>>>>> best to provide to the PSAP? I've always heard that the > >>>>>> > >>>>>> answer would be no: > >>>>>> > >>>>>> > >>>>>>>> provide both to the PSAP. So why then would we not > >>>> > >>>> provide the same > >>>> > >>>>>>>> information when determining which PSAP to contact? > >>>>>>>> > >>>>>>>> -andy > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Ecrit mailing list > >>>>>>> Ecrit@ietf.org > >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Ecrit mailing list > >>>>>>> Ecrit@ietf.org > >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Ecrit mailing list > >>>>>> Ecrit@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 18:23:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnNUD-0005Lb-LR; Mon, 05 Jun 2006 18:23:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnNUC-0005LW-Du for ecrit@ietf.org; Mon, 05 Jun 2006 18:23:48 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnNUB-0001HH-SO for ecrit@ietf.org; Mon, 05 Jun 2006 18:23:48 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Mon, 5 Jun 2006 15:23:46 -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] [issue2] Is it allowed to specify civic and geospatialinfointo the query? Date: Mon, 5 Jun 2006 15:23:45 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657505131429@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfointo the query? Thread-Index: AcaI5lp1c/tuZa5hT/ONoqt8qgHEvAABndkw From: "Roger Marshall" To: "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 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 admit that this theme is somewhat of a tangent to the subject, but can the authors of LoST help me understand the reasons for not using the PIDF-LO. Is it the overhead? Is the PIDF-LO not adequate to convey location some how? As an example, if the PIDF-LO format is changed significantly in some way, it will mandate a s/w change to ~10^8 clients vs. only ~10^2 - 10^4 server instances. =20 It seems to me that as the PIDF-LO undergoes changes over time, that the choice between having to modify client software vs. server software instances represents a huge difference in effort. Roger Marshall >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 >Sent: Monday, June 05, 2006 2:24 PM >To: Roger Marshall >Cc: Brian Rosen; ecrit@ietf.org >Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic=20 >and geospatialinfointo the query? > >Hi Roger, > >Roger Marshall wrote: >> Hannes: Thanks for clarifying. =20 >>=20 >> I think it's a bad idea to withold location information from=20 >the LoST=20 >> server. >>=20 >> To suggest that we restrict the client, allowing only one to=20 >be sent,=20 >> sounds to me like we're placing a constraint on the PIDF-LO,=20 >saying it=20 >> can't have both (assuming LoST reuses the PIDF-LO). I don't think we >> can get away with that. If the PIDF-LO has both, how is it=20 >that we can >> glibly strip one out? To do so would be unreasonable. > >To clarify: > >* You can send as many queries as you want but not with the=20 >same message. Different location information =3D> different query > >* We don't use a PIDF-LO in LoST. We use the raw location info. > >>=20 >> Since the client can have both civic and geo in the PIDF-LO, it can=20 >> also send both to the server. What am I missing? > >None of the proposals ever used a PIDF-LO as input; just location info. > >>=20 >> It's the LoST server's job to pick one, not the client's. > >At the PSAP and the emergency routing proxy I agree with you. > >>=20 >> So, the requirement I would support is as follows: >>=20 >> Rx' LoST client SHALL query with either civic or geo. > >That's fine. > > >> Ry' LoST client SHOULD query with *both* civic and geo. When LoST=20 >> server receives both civic and geo, the server SHOULD try to use the=20 >> geo first. The LoST server response SHALL indicate which data was=20 >> used (either geo or civic). > >I guess you will not support for this one based on the=20 >response I saw on the list so far. > >Ciao >Hannes > >>=20 >> -roger. >>=20 >>=20 >>=20 >>>-----Original Message----- >>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>Sent: Monday, June 05, 2006 1:50 PM >>>To: Roger Marshall >>>Cc: Brian Rosen; ecrit@ietf.org >>>Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and=20 >>>geospatialinfointo the query? >>> >>>Hi Roger, >>> >>>I think the current suggestion is that the LoST client just picks=20 >>>whatever he wants and then uses the mapping protocol to trigger the=20 >>>resolution. >>> >>>Using geo and civic might be, from a certain point of view,=20 >just be an=20 >>>optimization. The LoST client can always trigger separate=20 >queries with=20 >>>all the location info it has. >>> >>>Ciao >>>Hannes >>> >>>Roger Marshall wrote: >>> >>>>I don't disagree that we ask the LoST server to pick one and >>> >>>use it. =20 >>> >>>>We need to be consistent though, and so therefore, I propose >>> >>>that the >>> >>>>LoST server always picks the geo over the civic and returns >>> >>>a flag in >>> >>>>the response stating that the geo was used to perform mapping. >>>> >>>>Roger. >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>Sent: Monday, June 05, 2006 1:39 PM >>>>>To: Brian Rosen >>>>>Cc: ecrit@ietf.org >>>>>Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and=20 >>>>>geospatialinfointo the query? >>>>> >>>>>It seems that we closed this issue. >>>>> >>>>>Everyone seems to be in favor for a civic OR geospatial. >>>>>Extensions possible for future applications. >>>>> >>>>>Ciao >>>>>Hannes >>>>> >>>>>Brian Rosen wrote: >>>>> >>>>> >>>>>>I think this is the issue. There is no guidance we can give the=20 >>>>>>server to tell it how to resolve what to do when both >>> >>>locations are >>> >>>>>>valid but the URI for the geo does match the URI for the civic. >>>>>> >>>>>>This happens a lot when you are near boundaries because the >>>>> >>>>>precision >>>>> >>>>> >>>>>>and accuracy of the two methods differ. >>>>>> >>>>>>I think you pick ONE and use it. >>>>>> >>>>>>Even if you send more than one along, the PSAP has to know >>> >>>which one >>> >>>>>>you used to route. It's going to continue to use that >>> >>>until a human >>> >>>>>>says otherwise. >>>>>> >>>>>>Brian >>>>>> >>>>>>-----Original Message----- >>>>>>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>>>Sent: Monday, June 05, 2006 3:55 PM >>>>>>To: Andrew Newton >>>>>>Cc: ecrit@ietf.org >>>>>>Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and=20 >>>>>>geospatialinfo into the query? >>>>>> >>>>>>At the PSAP, we have a human that can look at this=20 >information and=20 >>>>>>make decisions (and maybe even ask if there's a=20 >discrepancy). That=20 >>>>>>seems a stretch for the LoST server. >>>>>> >>>>>>Andrew Newton wrote: >>>>>> >>>>>> >>>>>> >>>>>>>On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>>In all of these dual-information cases, I don't see how anybody=20 >>>>>>>>except the seeker can make any determination which type of=20 >>>>>>>>information is better, more accurate, more recent, etc. >>>>>>> >>>>>>>Would we want the seeker to determine which information it >>> >>>feels is >>> >>>>>>>best to provide to the PSAP? I've always heard that the >>>>> >>>>>answer would be no: >>>>> >>>>> >>>>>>>provide both to the PSAP. So why then would we not >>> >>>provide the same >>> >>>>>>>information when determining which PSAP to contact? >>>>>>> >>>>>>>-andy >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Ecrit mailing list >>>>>>Ecrit@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Ecrit mailing list >>>>>>Ecrit@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Ecrit mailing list >>>>>Ecrit@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/ecrit >>>>> >>>> >>>> >>>> >>> >>=20 >>=20 > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 18:42:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnNm5-0007WU-1l; Mon, 05 Jun 2006 18:42:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnNm3-0007WO-E2 for ecrit@ietf.org; Mon, 05 Jun 2006 18:42:15 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnNm2-0003wZ-Fg for ecrit@ietf.org; Mon, 05 Jun 2006 18:42:15 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Mon, 5 Jun 2006 15:42:12 -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] [issue2] Is it allowed to specifycivicand geospatialinfointo the query? Date: Mon, 5 Jun 2006 15:42:12 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657505131459@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [issue2] Is it allowed to specifycivicand geospatialinfointo the query? Thread-Index: AcaI6zjnhQc8CUHLTvKUn0joHvMpxgAAhz/AAABd9UA= From: "Roger Marshall" To: "Marc Linsner" , "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: 731ea0e9f5725b67e634db1918f3b951 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 Marc: What is the scale of "accuracy" for a civic street address? 0%,100%? Just because both civic and geo are included, doesn't mean one is better. For example, it is obvious that lat/lon's have measurement criteria whereas civic addresses don't, since they're either "stated" or "derived". Parcel-based GIS mapping systems exist today which describe a location in terms of both. As a simple example, Google Earth does this for you. You specify 123 Main Street, Anytown, USA and once it finds it, it also provides a lat/lon. I admit that the there are challenges with using both, but I expect that those issues will become fewer over time. Does there have to be a line in the sand as to whether a particular location is known in terms of civic vs. geo and not both? I don't think so.=20 Roger Marshall =20 >-----Original Message----- >From: Marc Linsner [mailto:mlinsner@cisco.com]=20 >Sent: Monday, June 05, 2006 3:23 PM >To: 'Andrew Newton' >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivicand=20 >geospatialinfointo the query? > >Andy, > >The problem is that the 'preferred' location is the accurate=20 >one. No LoST server/service will be able to determine which=20 >one is most accurate. You may equate the same problem to the=20 >client, but IMO, it's better that the client make the decision=20 >since it's closer to the human that 'should' know. > >-Marc- > > > >> -----Original Message----- >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Monday, June 05, 2006 5:58 PM >> To: Marc Linsner >> Cc: 'Hannes Tschofenig'; ecrit@ietf.org >> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civicand=20 >> geospatialinfointo the query? >>=20 >> I think we'd have a protocol more capable of adapting to unforeseen,=20 >> real world issues if both were sent and the server had the=20 >opportunity=20 >> to determine which type of location it preferred. I must admit that=20 >> it seems a bit of a stretch, but I think it is just as possible as=20 >> Henning's idea that the client will have the same type of=20 >notion. It=20 >> almost always seems to me that if ever there is a question about=20 >> preference, it should fall to the LoST service operators and their=20 >> jurisdictional considerations. >>=20 >> It also seems to me that if a client or seeker does, in some=20 >odd way,=20 >> have a notion of a preferred type of location when it=20 >possesses both,=20 >> that it can always just send the query with only the type of=20 >location=20 >> it prefers. For clients that don't have this strong notion,=20 >send both=20 >> and see if the server has a preference. >>=20 >> -andy >>=20 >>=20 >> On Jun 5, 2006, at 5:39 PM, Marc Linsner wrote: >>=20 >> > I agree, the LoST client submits one location at a time. =20 >> No decisions >> > made by LoST server/service. >> > >> > -Marc- >> > >> >> -----Original Message----- >> >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> >> Sent: Monday, June 05, 2006 5:24 PM >> >> To: Roger Marshall >> >> Cc: ecrit@ietf.org >> >> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civicand=20 >> >> geospatialinfointo the query? >> >> >> >> Hi Roger, >> >> >> >> Roger Marshall wrote: >> >>> Hannes: Thanks for clarifying. >> >>> >> >>> I think it's a bad idea to withold location information >> >> from the LoST >> >>> server. >> >>> >> >>> To suggest that we restrict the client, allowing only one >> >> to be sent, >> >>> sounds to me like we're placing a constraint on the >> >> PIDF-LO, saying it >> >>> can't have both (assuming LoST reuses the PIDF-LO). I >> >> don't think we >> >>> can get away with that. If the PIDF-LO has both, how is >> >> it that we can >> >>> glibly strip one out? To do so would be unreasonable. >> >> >> >> To clarify: >> >> >> >> * You can send as many queries as you want but not with the same=20 >> >> message. Different location information =3D> different query >> >> >> >> * We don't use a PIDF-LO in LoST. We use the raw location info. >> >> >> >>> >> >>> Since the client can have both civic and geo in the >> PIDF-LO, it can >> >>> also send both to the server. What am I missing? >> >> >> >> None of the proposals ever used a PIDF-LO as input; just location=20 >> >> info. >> >> >> >>> >> >>> It's the LoST server's job to pick one, not the client's. >> >> >> >> At the PSAP and the emergency routing proxy I agree with you. >> >> >> >>> >> >>> So, the requirement I would support is as follows: >> >>> >> >>> Rx' LoST client SHALL query with either civic or geo. >> >> >> >> That's fine. >> >> >> >> >> >>> Ry' LoST client SHOULD query with *both* civic and geo. =20 >> When LoST >> >>> server receives both civic and geo, the server SHOULD try >> >> to use the >> >>> geo first. The LoST server response SHALL indicate which >> data was >> >>> used (either geo or civic). >> >> >> >> I guess you will not support for this one based on the >> response I saw >> >> on the list so far. >> >> >> >> Ciao >> >> Hannes >> >> >> >>> >> >>> -roger. >> >>> >> >>> >> >>> >> >>>> -----Original Message----- >> >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> >>>> Sent: Monday, June 05, 2006 1:50 PM >> >>>> To: Roger Marshall >> >>>> Cc: Brian Rosen; ecrit@ietf.org >> >>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify=20 >civic and=20 >> >>>> geospatialinfointo the query? >> >>>> >> >>>> Hi Roger, >> >>>> >> >>>> I think the current suggestion is that the LoST client >> just picks >> >>>> whatever he wants and then uses the mapping protocol to >> trigger the >> >>>> resolution. >> >>>> >> >>>> Using geo and civic might be, from a certain point of view, >> >> just be an >> >>>> optimization. The LoST client can always trigger separate >> >> queries with >> >>>> all the location info it has. >> >>>> >> >>>> Ciao >> >>>> Hannes >> >>>> >> >>>> Roger Marshall wrote: >> >>>> >> >>>>> I don't disagree that we ask the LoST server to pick one and >> >>>> >> >>>> use it. >> >>>> >> >>>>> We need to be consistent though, and so therefore, I propose >> >>>> >> >>>> that the >> >>>> >> >>>>> LoST server always picks the geo over the civic and returns >> >>>> >> >>>> a flag in >> >>>> >> >>>>> the response stating that the geo was used to perform mapping. >> >>>>> >> >>>>> Roger. >> >>>>> >> >>>>> >> >>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> >>>>>> Sent: Monday, June 05, 2006 1:39 PM >> >>>>>> To: Brian Rosen >> >>>>>> Cc: ecrit@ietf.org >> >>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify >> civic and >> >>>>>> geospatialinfointo the query? >> >>>>>> >> >>>>>> It seems that we closed this issue. >> >>>>>> >> >>>>>> Everyone seems to be in favor for a civic OR geospatial. >> >>>>>> Extensions possible for future applications. >> >>>>>> >> >>>>>> Ciao >> >>>>>> Hannes >> >>>>>> >> >>>>>> Brian Rosen wrote: >> >>>>>> >> >>>>>> >> >>>>>>> I think this is the issue. There is no guidance we >> can give the >> >>>>>>> server to tell it how to resolve what to do when both >> >>>> >> >>>> locations are >> >>>> >> >>>>>>> valid but the URI for the geo does match the URI for >> the civic. >> >>>>>>> >> >>>>>>> This happens a lot when you are near boundaries because the >> >>>>>> >> >>>>>> precision >> >>>>>> >> >>>>>> >> >>>>>>> and accuracy of the two methods differ. >> >>>>>>> >> >>>>>>> I think you pick ONE and use it. >> >>>>>>> >> >>>>>>> Even if you send more than one along, the PSAP has to know >> >>>> >> >>>> which one >> >>>> >> >>>>>>> you used to route. It's going to continue to use that >> >>>> >> >>>> until a human >> >>>> >> >>>>>>> says otherwise. >> >>>>>>> >> >>>>>>> Brian >> >>>>>>> >> >>>>>>> -----Original Message----- >> >>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> >>>>>>> Sent: Monday, June 05, 2006 3:55 PM >> >>>>>>> To: Andrew Newton >> >>>>>>> Cc: ecrit@ietf.org >> >>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to >> specify civic and >> >>>>>>> geospatialinfo into the query? >> >>>>>>> >> >>>>>>> At the PSAP, we have a human that can look at this >> >> information and >> >>>>>>> make decisions (and maybe even ask if there's a >> >> discrepancy). That >> >>>>>>> seems a stretch for the LoST server. >> >>>>>>> >> >>>>>>> Andrew Newton wrote: >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>>> On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>> In all of these dual-information cases, I don't see >> >> how anybody >> >>>>>>>>> except the seeker can make any determination which type of=20 >> >>>>>>>>> information is better, more accurate, more recent, etc. >> >>>>>>>> >> >>>>>>>> Would we want the seeker to determine which information it >> >>>> >> >>>> feels is >> >>>> >> >>>>>>>> best to provide to the PSAP? I've always heard that the >> >>>>>> >> >>>>>> answer would be no: >> >>>>>> >> >>>>>> >> >>>>>>>> provide both to the PSAP. So why then would we not >> >>>> >> >>>> provide the same >> >>>> >> >>>>>>>> information when determining which PSAP to contact? >> >>>>>>>> >> >>>>>>>> -andy >> >>>>>>> >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> Ecrit mailing list >> >>>>>>> Ecrit@ietf.org >> >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >> >>>>>>> >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> Ecrit mailing list >> >>>>>>> Ecrit@ietf.org >> >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >> >>>>>>> >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> Ecrit mailing list >> >>>>>> Ecrit@ietf.org >> >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >> >>>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>> >> >>> >> >>> >> >> >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/ecrit >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www1.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 18:46:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnNpl-0001Xg-IK; Mon, 05 Jun 2006 18:46:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnNpk-0001Xb-LP for ecrit@ietf.org; Mon, 05 Jun 2006 18:46:04 -0400 Received: from qfe1.f10207-20.atlanta2.level3.net ([67.72.93.25] helo=f10207-20.adc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnNpk-00045Y-7M for ecrit@ietf.org; Mon, 05 Jun 2006 18:46:04 -0400 Received: from machine77.Level3.com (qfe0.f10212-07.adc1.oss.level3.com [10.2.1.102]) by f10207-20.adc1.level3.com (8.12.10/8.12.10) with ESMTP id k55Mju6r019942 for ; Mon, 5 Jun 2006 22:46:01 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id 97EBA124819 for ; Mon, 5 Jun 2006 22:45:55 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner5.level3.com (Postfix) with SMTP id 5065B124811 for ; Mon, 5 Jun 2006 22:45:55 +0000 (GMT) Received: from idc1exc0004.corp.global.level3.com ([10.1.9.15]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 16:45:55 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivicand geospatialinfointo the query? Date: Mon, 5 Jun 2006 16:45:53 -0600 Message-ID: <3F75233A2E57CC468B35F3B1FAF71EC003DF8E41@idc1exc0004.corp.global.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [issue2] Is it allowed to specifycivicand geospatialinfointo the query? Thread-Index: AcaI6zjnhQc8CUHLTvKUn0joHvMpxgAAhz/AAADhiCA= From: "Hearty, John" To: X-OriginalArrivalTime: 05 Jun 2006 22:45:55.0099 (UTC) FILETIME=[CDFC2EB0:01C688F1] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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 the client knows better than the LoST server which location is more accurate. It adds a bit of complexity, but why not let the client send both types and inform the server with a precision parameter which is more accurate. The server can then take this into account along with other factors. John -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com]=20 Sent: Monday, June 05, 2006 4:23 PM To: 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivicand geospatialinfointo the query? Andy, The problem is that the 'preferred' location is the accurate one. No LoST server/service will be able to determine which one is most accurate. You may equate the same problem to the client, but IMO, it's better that the client make the decision since it's closer to the human that 'should' know. -Marc- > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us]=20 > Sent: Monday, June 05, 2006 5:58 PM > To: Marc Linsner > Cc: 'Hannes Tschofenig'; ecrit@ietf.org > Subject: Re: [Ecrit] [issue2] Is it allowed to specify=20 > civicand geospatialinfointo the query? >=20 > I think we'd have a protocol more capable of adapting to=20 > unforeseen, real world issues if both were sent and the=20 > server had the opportunity to determine which type of=20 > location it preferred. I must admit that it seems a bit of a=20 > stretch, but I think it is just as possible as Henning's idea=20 > that the client will have the same type of notion. It almost=20 > always seems to me that if ever there is a question about=20 > preference, it should fall to the LoST service operators and=20 > their jurisdictional considerations. >=20 > It also seems to me that if a client or seeker does, in some=20 > odd way, have a notion of a preferred type of location when=20 > it possesses both, that it can always just send the query=20 > with only the type of location it prefers. For clients that=20 > don't have this strong notion, send both and see if the=20 > server has a preference. >=20 > -andy >=20 >=20 > On Jun 5, 2006, at 5:39 PM, Marc Linsner wrote: >=20 > > I agree, the LoST client submits one location at a time. =20 > No decisions=20 > > made by LoST server/service. > > > > -Marc- > > > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: Monday, June 05, 2006 5:24 PM > >> To: Roger Marshall > >> Cc: ecrit@ietf.org > >> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civicand=20 > >> geospatialinfointo the query? > >> > >> Hi Roger, > >> > >> Roger Marshall wrote: > >>> Hannes: Thanks for clarifying. > >>> > >>> I think it's a bad idea to withold location information > >> from the LoST > >>> server. > >>> > >>> To suggest that we restrict the client, allowing only one > >> to be sent, > >>> sounds to me like we're placing a constraint on the > >> PIDF-LO, saying it > >>> can't have both (assuming LoST reuses the PIDF-LO). I > >> don't think we > >>> can get away with that. If the PIDF-LO has both, how is > >> it that we can > >>> glibly strip one out? To do so would be unreasonable. > >> > >> To clarify: > >> > >> * You can send as many queries as you want but not with the same=20 > >> message. Different location information =3D> different query > >> > >> * We don't use a PIDF-LO in LoST. We use the raw location info. > >> > >>> > >>> Since the client can have both civic and geo in the=20 > PIDF-LO, it can=20 > >>> also send both to the server. What am I missing? > >> > >> None of the proposals ever used a PIDF-LO as input; just location=20 > >> info. > >> > >>> > >>> It's the LoST server's job to pick one, not the client's. > >> > >> At the PSAP and the emergency routing proxy I agree with you. > >> > >>> > >>> So, the requirement I would support is as follows: > >>> > >>> Rx' LoST client SHALL query with either civic or geo. > >> > >> That's fine. > >> > >> > >>> Ry' LoST client SHOULD query with *both* civic and geo. =20 > When LoST=20 > >>> server receives both civic and geo, the server SHOULD try > >> to use the > >>> geo first. The LoST server response SHALL indicate which=20 > data was=20 > >>> used (either geo or civic). > >> > >> I guess you will not support for this one based on the=20 > response I saw=20 > >> on the list so far. > >> > >> Ciao > >> Hannes > >> > >>> > >>> -roger. > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>> Sent: Monday, June 05, 2006 1:50 PM > >>>> To: Roger Marshall > >>>> Cc: Brian Rosen; ecrit@ietf.org > >>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and=20 > >>>> geospatialinfointo the query? > >>>> > >>>> Hi Roger, > >>>> > >>>> I think the current suggestion is that the LoST client=20 > just picks=20 > >>>> whatever he wants and then uses the mapping protocol to=20 > trigger the=20 > >>>> resolution. > >>>> > >>>> Using geo and civic might be, from a certain point of view, > >> just be an > >>>> optimization. The LoST client can always trigger separate > >> queries with > >>>> all the location info it has. > >>>> > >>>> Ciao > >>>> Hannes > >>>> > >>>> Roger Marshall wrote: > >>>> > >>>>> I don't disagree that we ask the LoST server to pick one and > >>>> > >>>> use it. > >>>> > >>>>> We need to be consistent though, and so therefore, I propose > >>>> > >>>> that the > >>>> > >>>>> LoST server always picks the geo over the civic and returns > >>>> > >>>> a flag in > >>>> > >>>>> the response stating that the geo was used to perform mapping. > >>>>> > >>>>> Roger. > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>>> Sent: Monday, June 05, 2006 1:39 PM > >>>>>> To: Brian Rosen > >>>>>> Cc: ecrit@ietf.org > >>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify=20 > civic and=20 > >>>>>> geospatialinfointo the query? > >>>>>> > >>>>>> It seems that we closed this issue. > >>>>>> > >>>>>> Everyone seems to be in favor for a civic OR geospatial. > >>>>>> Extensions possible for future applications. > >>>>>> > >>>>>> Ciao > >>>>>> Hannes > >>>>>> > >>>>>> Brian Rosen wrote: > >>>>>> > >>>>>> > >>>>>>> I think this is the issue. There is no guidance we=20 > can give the=20 > >>>>>>> server to tell it how to resolve what to do when both > >>>> > >>>> locations are > >>>> > >>>>>>> valid but the URI for the geo does match the URI for=20 > the civic. > >>>>>>> > >>>>>>> This happens a lot when you are near boundaries because the > >>>>>> > >>>>>> precision > >>>>>> > >>>>>> > >>>>>>> and accuracy of the two methods differ. > >>>>>>> > >>>>>>> I think you pick ONE and use it. > >>>>>>> > >>>>>>> Even if you send more than one along, the PSAP has to know > >>>> > >>>> which one > >>>> > >>>>>>> you used to route. It's going to continue to use that > >>>> > >>>> until a human > >>>> > >>>>>>> says otherwise. > >>>>>>> > >>>>>>> Brian > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>>>>>> Sent: Monday, June 05, 2006 3:55 PM > >>>>>>> To: Andrew Newton > >>>>>>> Cc: ecrit@ietf.org > >>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to=20 > specify civic and=20 > >>>>>>> geospatialinfo into the query? > >>>>>>> > >>>>>>> At the PSAP, we have a human that can look at this > >> information and > >>>>>>> make decisions (and maybe even ask if there's a > >> discrepancy). That > >>>>>>> seems a stretch for the LoST server. > >>>>>>> > >>>>>>> Andrew Newton wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> In all of these dual-information cases, I don't see > >> how anybody > >>>>>>>>> except the seeker can make any determination which type of=20 > >>>>>>>>> information is better, more accurate, more recent, etc. > >>>>>>>> > >>>>>>>> Would we want the seeker to determine which information it > >>>> > >>>> feels is > >>>> > >>>>>>>> best to provide to the PSAP? I've always heard that the > >>>>>> > >>>>>> answer would be no: > >>>>>> > >>>>>> > >>>>>>>> provide both to the PSAP. So why then would we not > >>>> > >>>> provide the same > >>>> > >>>>>>>> information when determining which PSAP to contact? > >>>>>>>> > >>>>>>>> -andy > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Ecrit mailing list > >>>>>>> Ecrit@ietf.org > >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Ecrit mailing list > >>>>>>> Ecrit@ietf.org > >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Ecrit mailing list > >>>>>> Ecrit@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 18:47:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnNr8-0001cK-5l; Mon, 05 Jun 2006 18:47:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnNr6-0001cF-Oj for ecrit@ietf.org; Mon, 05 Jun 2006 18:47:28 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnNr5-0004Kf-EL for ecrit@ietf.org; Mon, 05 Jun 2006 18:47:28 -0400 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.6.118]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k55MlEg12297; Mon, 5 Jun 2006 16:47:14 -0600 Message-ID: <4484B68A.9060603@ntt-at.com> Date: Mon, 05 Jun 2006 15:56:10 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] [issue1] Do we need a default service URN for the LoSTquery? References: <8C837214C95C864C9F34F3635C2A657505130F3A@SEA-EXCHVS-2.telecomsys.com> <44846E19.10601@cs.columbia.edu> In-Reply-To: <44846E19.10601@cs.columbia.edu> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I strongly agree with Henning here for the exact reason Henning expressed. Default service, from the importance will likely be the emergency service, and this will lead to unintended emergency call if we support this default service. It may be a possibility that requesting without the service identifier will result with a response containing list of services the LOST server supports. Regards Shida Henning Schulzrinne wrote: > > > Roger Marshall wrote: >> The LoST server must support a default, so that if it receives a query >> which contains location, but no emergency service identifier, then it >> can still provide an answer. > > I don't see that as necessary or helpful. Why can't the client always > insert a service URN? This seems a trivial thing to do for a client > and avoids problems of trying to guess what the client really wanted. > (Remember that LoST may well be used for non-emergency services, too.) > > I don't think "you know what I mean" protocol features are a good way > forward. > > >> >> The worst case of having this happen is that clients always get an >> emergency context associated, location-relevant PSAP URI when they query >> with location only. The server would then return this "default" ESI so >> that the client would have it from then on. >> >> I think the LoST protocol requirements for query including an ESI is a >> SHOULD, and a response msg. to include an ESI is a MUST. >> > > _______________________________________________ > 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 Jun 05 19:44:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnOkA-0004QC-Gg; Mon, 05 Jun 2006 19:44:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnOkA-0004Q7-5q for ecrit@ietf.org; Mon, 05 Jun 2006 19:44:22 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnOk7-0001af-DP for ecrit@ietf.org; Mon, 05 Jun 2006 19:44:22 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 05 Jun 2006 16:44:18 -0700 X-IronPort-AV: i="4.05,212,1146466800"; d="scan'208"; a="289224908:sNHT39174668" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k55NiIPl006144; Mon, 5 Jun 2006 16:44:18 -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 k55NiHcL006911; Mon, 5 Jun 2006 16:44:17 -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.211); Mon, 5 Jun 2006 16:44:17 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Jun 2006 16:44:16 -0700 From: "Marc Linsner" To: "'Roger Marshall'" , "'Andrew Newton'" Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivicand geospatialinfointo the query? Date: Mon, 5 Jun 2006 19:44:15 -0400 Message-ID: <004a01c688f9$f519f0b0$2c0d0d0a@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: <8C837214C95C864C9F34F3635C2A657505131459@SEA-EXCHVS-2.telecomsys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaI6zjnhQc8CUHLTvKUn0joHvMpxgAAhz/AAABd9UAAAiMDIA== X-OriginalArrivalTime: 05 Jun 2006 23:44:16.0944 (UTC) FILETIME=[F53F5300:01C688F9] DKIM-Signature: a=rsa-sha1; q=dns; l=12309; t=1149551058; x=1150415058; c=relaxed/simple; s=sjdkim7001; 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]=20[issue2]=20Is=20it=20allowed=20to=20specifycivicand=09 geospatialinfointo=20the=20query?; X=v=3Dcisco.com=3B=20h=3Dirf8KLOLMPhN6H64FPMmfUdJ8vY=3D; b=jMn30cLDE9Jnq26PLHFzXdVtxgieMKaWG1pVxNWiu2jsjgN9NG8d15ZvdNjU97pwuOBRsDL9 L8BnTcRmdft7IH1EDnPobkS8WNEIsI6JLy7NBwisrLJtQuEmd0QwgeB0; Authentication-Results: sj-dkim-7.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 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 Roger, I'm not arguing geo vs. civil. All I am trying to state is when multiple location representations are known for a LoST client, the LoST server/service should not be the one to determine which representation is best. Setup for failure example #1: A single LoST query contains both a civic (123 Main St.) and a geo representation. All geocode databases return 456 Second St. for the geo. Which one should LoST prefer? Setup for failure example #2: A single LoST query contains two civic representations. One is in New York City and the other in Seattle. Which one should LoST prefer? IMO, each example should be (2) unique queries, one for each representation, and let the client deal with it. This decision needs to be made as close to a human as possible, I don't foresee any programmatic solution. If the client holds (2) location representations, the problem is theirs and needs to be resolved there. Once a PSAP call taker (a second human) is involved, then the two humans can negotiate the issue. Too many variables to standardize a solution. -Marc- > > Marc: > What is the scale of "accuracy" for a civic street address? 0%,100%? > > Just because both civic and geo are included, doesn't mean > one is better. For example, it is obvious that lat/lon's > have measurement criteria whereas civic addresses don't, > since they're either "stated" or "derived". > > Parcel-based GIS mapping systems exist today which describe a > location in terms of both. As a simple example, Google Earth > does this for you. > You specify 123 Main Street, Anytown, USA and once it finds > it, it also provides a lat/lon. I admit that the there are > challenges with using both, but I expect that those issues > will become fewer over time. > > Does there have to be a line in the sand as to whether a > particular location is known in terms of civic vs. geo and > not both? I don't think so. > > > Roger Marshall > > > >-----Original Message----- > >From: Marc Linsner [mailto:mlinsner@cisco.com] > >Sent: Monday, June 05, 2006 3:23 PM > >To: 'Andrew Newton' > >Cc: ecrit@ietf.org > >Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivicand > >geospatialinfointo the query? > > > >Andy, > > > >The problem is that the 'preferred' location is the accurate > one. No > >LoST server/service will be able to determine which one is most > >accurate. You may equate the same problem to the client, > but IMO, it's > >better that the client make the decision since it's closer > to the human > >that 'should' know. > > > >-Marc- > > > > > > > >> -----Original Message----- > >> From: Andrew Newton [mailto:andy@hxr.us] > >> Sent: Monday, June 05, 2006 5:58 PM > >> To: Marc Linsner > >> Cc: 'Hannes Tschofenig'; ecrit@ietf.org > >> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civicand > >> geospatialinfointo the query? > >> > >> I think we'd have a protocol more capable of adapting to > unforeseen, > >> real world issues if both were sent and the server had the > >opportunity > >> to determine which type of location it preferred. I must > admit that > >> it seems a bit of a stretch, but I think it is just as possible as > >> Henning's idea that the client will have the same type of > >notion. It > >> almost always seems to me that if ever there is a question about > >> preference, it should fall to the LoST service operators and their > >> jurisdictional considerations. > >> > >> It also seems to me that if a client or seeker does, in some > >odd way, > >> have a notion of a preferred type of location when it > >possesses both, > >> that it can always just send the query with only the type of > >location > >> it prefers. For clients that don't have this strong notion, > >send both > >> and see if the server has a preference. > >> > >> -andy > >> > >> > >> On Jun 5, 2006, at 5:39 PM, Marc Linsner wrote: > >> > >> > I agree, the LoST client submits one location at a time. > >> No decisions > >> > made by LoST server/service. > >> > > >> > -Marc- > >> > > >> >> -----Original Message----- > >> >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> >> Sent: Monday, June 05, 2006 5:24 PM > >> >> To: Roger Marshall > >> >> Cc: ecrit@ietf.org > >> >> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civicand > >> >> geospatialinfointo the query? > >> >> > >> >> Hi Roger, > >> >> > >> >> Roger Marshall wrote: > >> >>> Hannes: Thanks for clarifying. > >> >>> > >> >>> I think it's a bad idea to withold location information > >> >> from the LoST > >> >>> server. > >> >>> > >> >>> To suggest that we restrict the client, allowing only one > >> >> to be sent, > >> >>> sounds to me like we're placing a constraint on the > >> >> PIDF-LO, saying it > >> >>> can't have both (assuming LoST reuses the PIDF-LO). I > >> >> don't think we > >> >>> can get away with that. If the PIDF-LO has both, how is > >> >> it that we can > >> >>> glibly strip one out? To do so would be unreasonable. > >> >> > >> >> To clarify: > >> >> > >> >> * You can send as many queries as you want but not with > the same > >> >> message. Different location information => different query > >> >> > >> >> * We don't use a PIDF-LO in LoST. We use the raw location info. > >> >> > >> >>> > >> >>> Since the client can have both civic and geo in the > >> PIDF-LO, it can > >> >>> also send both to the server. What am I missing? > >> >> > >> >> None of the proposals ever used a PIDF-LO as input; > just location > >> >> info. > >> >> > >> >>> > >> >>> It's the LoST server's job to pick one, not the client's. > >> >> > >> >> At the PSAP and the emergency routing proxy I agree with you. > >> >> > >> >>> > >> >>> So, the requirement I would support is as follows: > >> >>> > >> >>> Rx' LoST client SHALL query with either civic or geo. > >> >> > >> >> That's fine. > >> >> > >> >> > >> >>> Ry' LoST client SHOULD query with *both* civic and geo. > >> When LoST > >> >>> server receives both civic and geo, the server SHOULD try > >> >> to use the > >> >>> geo first. The LoST server response SHALL indicate which > >> data was > >> >>> used (either geo or civic). > >> >> > >> >> I guess you will not support for this one based on the > >> response I saw > >> >> on the list so far. > >> >> > >> >> Ciao > >> >> Hannes > >> >> > >> >>> > >> >>> -roger. > >> >>> > >> >>> > >> >>> > >> >>>> -----Original Message----- > >> >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> >>>> Sent: Monday, June 05, 2006 1:50 PM > >> >>>> To: Roger Marshall > >> >>>> Cc: Brian Rosen; ecrit@ietf.org > >> >>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify > >civic and > >> >>>> geospatialinfointo the query? > >> >>>> > >> >>>> Hi Roger, > >> >>>> > >> >>>> I think the current suggestion is that the LoST client > >> just picks > >> >>>> whatever he wants and then uses the mapping protocol to > >> trigger the > >> >>>> resolution. > >> >>>> > >> >>>> Using geo and civic might be, from a certain point of view, > >> >> just be an > >> >>>> optimization. The LoST client can always trigger separate > >> >> queries with > >> >>>> all the location info it has. > >> >>>> > >> >>>> Ciao > >> >>>> Hannes > >> >>>> > >> >>>> Roger Marshall wrote: > >> >>>> > >> >>>>> I don't disagree that we ask the LoST server to pick one and > >> >>>> > >> >>>> use it. > >> >>>> > >> >>>>> We need to be consistent though, and so therefore, I propose > >> >>>> > >> >>>> that the > >> >>>> > >> >>>>> LoST server always picks the geo over the civic and returns > >> >>>> > >> >>>> a flag in > >> >>>> > >> >>>>> the response stating that the geo was used to > perform mapping. > >> >>>>> > >> >>>>> Roger. > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>>> -----Original Message----- > >> >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> >>>>>> Sent: Monday, June 05, 2006 1:39 PM > >> >>>>>> To: Brian Rosen > >> >>>>>> Cc: ecrit@ietf.org > >> >>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify > >> civic and > >> >>>>>> geospatialinfointo the query? > >> >>>>>> > >> >>>>>> It seems that we closed this issue. > >> >>>>>> > >> >>>>>> Everyone seems to be in favor for a civic OR geospatial. > >> >>>>>> Extensions possible for future applications. > >> >>>>>> > >> >>>>>> Ciao > >> >>>>>> Hannes > >> >>>>>> > >> >>>>>> Brian Rosen wrote: > >> >>>>>> > >> >>>>>> > >> >>>>>>> I think this is the issue. There is no guidance we > >> can give the > >> >>>>>>> server to tell it how to resolve what to do when both > >> >>>> > >> >>>> locations are > >> >>>> > >> >>>>>>> valid but the URI for the geo does match the URI for > >> the civic. > >> >>>>>>> > >> >>>>>>> This happens a lot when you are near boundaries because the > >> >>>>>> > >> >>>>>> precision > >> >>>>>> > >> >>>>>> > >> >>>>>>> and accuracy of the two methods differ. > >> >>>>>>> > >> >>>>>>> I think you pick ONE and use it. > >> >>>>>>> > >> >>>>>>> Even if you send more than one along, the PSAP has to know > >> >>>> > >> >>>> which one > >> >>>> > >> >>>>>>> you used to route. It's going to continue to use that > >> >>>> > >> >>>> until a human > >> >>>> > >> >>>>>>> says otherwise. > >> >>>>>>> > >> >>>>>>> Brian > >> >>>>>>> > >> >>>>>>> -----Original Message----- > >> >>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >> >>>>>>> Sent: Monday, June 05, 2006 3:55 PM > >> >>>>>>> To: Andrew Newton > >> >>>>>>> Cc: ecrit@ietf.org > >> >>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to > >> specify civic and > >> >>>>>>> geospatialinfo into the query? > >> >>>>>>> > >> >>>>>>> At the PSAP, we have a human that can look at this > >> >> information and > >> >>>>>>> make decisions (and maybe even ask if there's a > >> >> discrepancy). That > >> >>>>>>> seems a stretch for the LoST server. > >> >>>>>>> > >> >>>>>>> Andrew Newton wrote: > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>>> On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>>> In all of these dual-information cases, I don't see > >> >> how anybody > >> >>>>>>>>> except the seeker can make any determination > which type of > >> >>>>>>>>> information is better, more accurate, more recent, etc. > >> >>>>>>>> > >> >>>>>>>> Would we want the seeker to determine which information it > >> >>>> > >> >>>> feels is > >> >>>> > >> >>>>>>>> best to provide to the PSAP? I've always heard that the > >> >>>>>> > >> >>>>>> answer would be no: > >> >>>>>> > >> >>>>>> > >> >>>>>>>> provide both to the PSAP. So why then would we not > >> >>>> > >> >>>> provide the same > >> >>>> > >> >>>>>>>> information when determining which PSAP to contact? > >> >>>>>>>> > >> >>>>>>>> -andy > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> _______________________________________________ > >> >>>>>>> Ecrit mailing list > >> >>>>>>> Ecrit@ietf.org > >> >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> _______________________________________________ > >> >>>>>>> Ecrit mailing list > >> >>>>>>> Ecrit@ietf.org > >> >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >> >>>>>>> > >> >>>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> _______________________________________________ > >> >>>>>> Ecrit mailing list > >> >>>>>> Ecrit@ietf.org > >> >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >> >>>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>> > >> >>> > >> >>> > >> >> > >> >> > >> >> _______________________________________________ > >> >> Ecrit mailing list > >> >> Ecrit@ietf.org > >> >> https://www1.ietf.org/mailman/listinfo/ecrit > >> > > >> > _______________________________________________ > >> > Ecrit mailing list > >> > Ecrit@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/ecrit > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 20:03:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnP30-0005tG-1r; Mon, 05 Jun 2006 20:03:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnP2z-0005tB-CI for ecrit@ietf.org; Mon, 05 Jun 2006 20:03:49 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnP2y-0004tt-QZ for ecrit@ietf.org; Mon, 05 Jun 2006 20:03:49 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 19:04:12 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 05 Jun 2006 19:04:11 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 19:04:11 -0500 Message-ID: From: "Winterbottom, James" To: "Marc Linsner" , "Roger Marshall" , "Andrew Newton" Date: Mon, 5 Jun 2006 19:04:05 -0500 Subject: RE: [Ecrit] [issue2] Is it allowed tospecifycivicand geospatialinfointo the query? MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 06 Jun 2006 00:04:11.0327 (UTC) FILETIME=[BD27B4F0:01C688FC] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <004a01c688f9$f519f0b0$2c0d0d0a@amer.cisco.com> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] [issue2] Is it allowed tospecifycivicand geospatialinfointo the query? Thread-Index: AcaI6zjnhQc8CUHLTvKUn0joHvMpxgAAhz/AAABd9UAAAiMDIAABQpIg X-Spam-Score: 0.0 (/) X-Scan-Signature: 94962611154c8404498b19f744990308 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Why wouldn't the LoSt server simply treat each representation on its own merits? You give me two locations you get back 2 URIs, even if they are the same. > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Tuesday, 6 June 2006 9:44 AM > To: 'Roger Marshall'; 'Andrew Newton' > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] [issue2] Is it allowed tospecifycivicand > geospatialinfointo the query? >=20 > Roger, >=20 > I'm not arguing geo vs. civil. All I am trying to state is when multiple > location representations are known for a LoST client, the LoST > server/service should not be the one to determine which representation is > best. >=20 > Setup for failure example #1: A single LoST query contains both a civic > (123 > Main St.) and a geo representation. All geocode databases return 456 > Second > St. for the geo. Which one should LoST prefer? >=20 > Setup for failure example #2: A single LoST query contains two civic > representations. One is in New York City and the other in Seattle. Which > one should LoST prefer? >=20 > IMO, each example should be (2) unique queries, one for each > representation, > and let the client deal with it. This decision needs to be made as close > to > a human as possible, I don't foresee any programmatic solution. If the > client holds (2) location representations, the problem is theirs and needs > to be resolved there. Once a PSAP call taker (a second human) is > involved, > then the two humans can negotiate the issue. >=20 > Too many variables to standardize a solution. >=20 > -Marc- >=20 >=20 >=20 >=20 > > > > Marc: > > What is the scale of "accuracy" for a civic street address? 0%,100%? > > > > Just because both civic and geo are included, doesn't mean > > one is better. For example, it is obvious that lat/lon's > > have measurement criteria whereas civic addresses don't, > > since they're either "stated" or "derived". > > > > Parcel-based GIS mapping systems exist today which describe a > > location in terms of both. As a simple example, Google Earth > > does this for you. > > You specify 123 Main Street, Anytown, USA and once it finds > > it, it also provides a lat/lon. I admit that the there are > > challenges with using both, but I expect that those issues > > will become fewer over time. > > > > Does there have to be a line in the sand as to whether a > > particular location is known in terms of civic vs. geo and > > not both? I don't think so. > > > > > > Roger Marshall > > > > > > >-----Original Message----- > > >From: Marc Linsner [mailto:mlinsner@cisco.com] > > >Sent: Monday, June 05, 2006 3:23 PM > > >To: 'Andrew Newton' > > >Cc: ecrit@ietf.org > > >Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivicand > > >geospatialinfointo the query? > > > > > >Andy, > > > > > >The problem is that the 'preferred' location is the accurate > > one. No > > >LoST server/service will be able to determine which one is most > > >accurate. You may equate the same problem to the client, > > but IMO, it's > > >better that the client make the decision since it's closer > > to the human > > >that 'should' know. > > > > > >-Marc- > > > > > > > > > > > >> -----Original Message----- > > >> From: Andrew Newton [mailto:andy@hxr.us] > > >> Sent: Monday, June 05, 2006 5:58 PM > > >> To: Marc Linsner > > >> Cc: 'Hannes Tschofenig'; ecrit@ietf.org > > >> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civicand > > >> geospatialinfointo the query? > > >> > > >> I think we'd have a protocol more capable of adapting to > > unforeseen, > > >> real world issues if both were sent and the server had the > > >opportunity > > >> to determine which type of location it preferred. I must > > admit that > > >> it seems a bit of a stretch, but I think it is just as possible as > > >> Henning's idea that the client will have the same type of > > >notion. It > > >> almost always seems to me that if ever there is a question about > > >> preference, it should fall to the LoST service operators and their > > >> jurisdictional considerations. > > >> > > >> It also seems to me that if a client or seeker does, in some > > >odd way, > > >> have a notion of a preferred type of location when it > > >possesses both, > > >> that it can always just send the query with only the type of > > >location > > >> it prefers. For clients that don't have this strong notion, > > >send both > > >> and see if the server has a preference. > > >> > > >> -andy > > >> > > >> > > >> On Jun 5, 2006, at 5:39 PM, Marc Linsner wrote: > > >> > > >> > I agree, the LoST client submits one location at a time. > > >> No decisions > > >> > made by LoST server/service. > > >> > > > >> > -Marc- > > >> > > > >> >> -----Original Message----- > > >> >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > >> >> Sent: Monday, June 05, 2006 5:24 PM > > >> >> To: Roger Marshall > > >> >> Cc: ecrit@ietf.org > > >> >> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civicand > > >> >> geospatialinfointo the query? > > >> >> > > >> >> Hi Roger, > > >> >> > > >> >> Roger Marshall wrote: > > >> >>> Hannes: Thanks for clarifying. > > >> >>> > > >> >>> I think it's a bad idea to withold location information > > >> >> from the LoST > > >> >>> server. > > >> >>> > > >> >>> To suggest that we restrict the client, allowing only one > > >> >> to be sent, > > >> >>> sounds to me like we're placing a constraint on the > > >> >> PIDF-LO, saying it > > >> >>> can't have both (assuming LoST reuses the PIDF-LO). I > > >> >> don't think we > > >> >>> can get away with that. If the PIDF-LO has both, how is > > >> >> it that we can > > >> >>> glibly strip one out? To do so would be unreasonable. > > >> >> > > >> >> To clarify: > > >> >> > > >> >> * You can send as many queries as you want but not with > > the same > > >> >> message. Different location information =3D> different query > > >> >> > > >> >> * We don't use a PIDF-LO in LoST. We use the raw location info. > > >> >> > > >> >>> > > >> >>> Since the client can have both civic and geo in the > > >> PIDF-LO, it can > > >> >>> also send both to the server. What am I missing? > > >> >> > > >> >> None of the proposals ever used a PIDF-LO as input; > > just location > > >> >> info. > > >> >> > > >> >>> > > >> >>> It's the LoST server's job to pick one, not the client's. > > >> >> > > >> >> At the PSAP and the emergency routing proxy I agree with you. > > >> >> > > >> >>> > > >> >>> So, the requirement I would support is as follows: > > >> >>> > > >> >>> Rx' LoST client SHALL query with either civic or geo. > > >> >> > > >> >> That's fine. > > >> >> > > >> >> > > >> >>> Ry' LoST client SHOULD query with *both* civic and geo. > > >> When LoST > > >> >>> server receives both civic and geo, the server SHOULD try > > >> >> to use the > > >> >>> geo first. The LoST server response SHALL indicate which > > >> data was > > >> >>> used (either geo or civic). > > >> >> > > >> >> I guess you will not support for this one based on the > > >> response I saw > > >> >> on the list so far. > > >> >> > > >> >> Ciao > > >> >> Hannes > > >> >> > > >> >>> > > >> >>> -roger. > > >> >>> > > >> >>> > > >> >>> > > >> >>>> -----Original Message----- > > >> >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > >> >>>> Sent: Monday, June 05, 2006 1:50 PM > > >> >>>> To: Roger Marshall > > >> >>>> Cc: Brian Rosen; ecrit@ietf.org > > >> >>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify > > >civic and > > >> >>>> geospatialinfointo the query? > > >> >>>> > > >> >>>> Hi Roger, > > >> >>>> > > >> >>>> I think the current suggestion is that the LoST client > > >> just picks > > >> >>>> whatever he wants and then uses the mapping protocol to > > >> trigger the > > >> >>>> resolution. > > >> >>>> > > >> >>>> Using geo and civic might be, from a certain point of view, > > >> >> just be an > > >> >>>> optimization. The LoST client can always trigger separate > > >> >> queries with > > >> >>>> all the location info it has. > > >> >>>> > > >> >>>> Ciao > > >> >>>> Hannes > > >> >>>> > > >> >>>> Roger Marshall wrote: > > >> >>>> > > >> >>>>> I don't disagree that we ask the LoST server to pick one and > > >> >>>> > > >> >>>> use it. > > >> >>>> > > >> >>>>> We need to be consistent though, and so therefore, I propose > > >> >>>> > > >> >>>> that the > > >> >>>> > > >> >>>>> LoST server always picks the geo over the civic and returns > > >> >>>> > > >> >>>> a flag in > > >> >>>> > > >> >>>>> the response stating that the geo was used to > > perform mapping. > > >> >>>>> > > >> >>>>> Roger. > > >> >>>>> > > >> >>>>> > > >> >>>>> > > >> >>>>>> -----Original Message----- > > >> >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > >> >>>>>> Sent: Monday, June 05, 2006 1:39 PM > > >> >>>>>> To: Brian Rosen > > >> >>>>>> Cc: ecrit@ietf.org > > >> >>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify > > >> civic and > > >> >>>>>> geospatialinfointo the query? > > >> >>>>>> > > >> >>>>>> It seems that we closed this issue. > > >> >>>>>> > > >> >>>>>> Everyone seems to be in favor for a civic OR geospatial. > > >> >>>>>> Extensions possible for future applications. > > >> >>>>>> > > >> >>>>>> Ciao > > >> >>>>>> Hannes > > >> >>>>>> > > >> >>>>>> Brian Rosen wrote: > > >> >>>>>> > > >> >>>>>> > > >> >>>>>>> I think this is the issue. There is no guidance we > > >> can give the > > >> >>>>>>> server to tell it how to resolve what to do when both > > >> >>>> > > >> >>>> locations are > > >> >>>> > > >> >>>>>>> valid but the URI for the geo does match the URI for > > >> the civic. > > >> >>>>>>> > > >> >>>>>>> This happens a lot when you are near boundaries because the > > >> >>>>>> > > >> >>>>>> precision > > >> >>>>>> > > >> >>>>>> > > >> >>>>>>> and accuracy of the two methods differ. > > >> >>>>>>> > > >> >>>>>>> I think you pick ONE and use it. > > >> >>>>>>> > > >> >>>>>>> Even if you send more than one along, the PSAP has to know > > >> >>>> > > >> >>>> which one > > >> >>>> > > >> >>>>>>> you used to route. It's going to continue to use that > > >> >>>> > > >> >>>> until a human > > >> >>>> > > >> >>>>>>> says otherwise. > > >> >>>>>>> > > >> >>>>>>> Brian > > >> >>>>>>> > > >> >>>>>>> -----Original Message----- > > >> >>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > >> >>>>>>> Sent: Monday, June 05, 2006 3:55 PM > > >> >>>>>>> To: Andrew Newton > > >> >>>>>>> Cc: ecrit@ietf.org > > >> >>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to > > >> specify civic and > > >> >>>>>>> geospatialinfo into the query? > > >> >>>>>>> > > >> >>>>>>> At the PSAP, we have a human that can look at this > > >> >> information and > > >> >>>>>>> make decisions (and maybe even ask if there's a > > >> >> discrepancy). That > > >> >>>>>>> seems a stretch for the LoST server. > > >> >>>>>>> > > >> >>>>>>> Andrew Newton wrote: > > >> >>>>>>> > > >> >>>>>>> > > >> >>>>>>> > > >> >>>>>>>> On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: > > >> >>>>>>>> > > >> >>>>>>>> > > >> >>>>>>>> > > >> >>>>>>>>> In all of these dual-information cases, I don't see > > >> >> how anybody > > >> >>>>>>>>> except the seeker can make any determination > > which type of > > >> >>>>>>>>> information is better, more accurate, more recent, etc. > > >> >>>>>>>> > > >> >>>>>>>> Would we want the seeker to determine which information it > > >> >>>> > > >> >>>> feels is > > >> >>>> > > >> >>>>>>>> best to provide to the PSAP? I've always heard that the > > >> >>>>>> > > >> >>>>>> answer would be no: > > >> >>>>>> > > >> >>>>>> > > >> >>>>>>>> provide both to the PSAP. So why then would we not > > >> >>>> > > >> >>>> provide the same > > >> >>>> > > >> >>>>>>>> information when determining which PSAP to contact? > > >> >>>>>>>> > > >> >>>>>>>> -andy > > >> >>>>>>> > > >> >>>>>>> > > >> >>>>>>> _______________________________________________ > > >> >>>>>>> Ecrit mailing list > > >> >>>>>>> Ecrit@ietf.org > > >> >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > > >> >>>>>>> > > >> >>>>>>> > > >> >>>>>>> _______________________________________________ > > >> >>>>>>> Ecrit mailing list > > >> >>>>>>> Ecrit@ietf.org > > >> >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > > >> >>>>>>> > > >> >>>>>>> > > >> >>>>>> > > >> >>>>>> > > >> >>>>>> _______________________________________________ > > >> >>>>>> Ecrit mailing list > > >> >>>>>> Ecrit@ietf.org > > >> >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > > >> >>>>>> > > >> >>>>> > > >> >>>>> > > >> >>>>> > > >> >>>> > > >> >>> > > >> >>> > > >> >> > > >> >> > > >> >> _______________________________________________ > > >> >> 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 > > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 20:11:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPAQ-0001ic-7e; Mon, 05 Jun 2006 20:11:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPAO-0001iU-C3 for ecrit@ietf.org; Mon, 05 Jun 2006 20:11:28 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPAN-0006AP-Ra for ecrit@ietf.org; Mon, 05 Jun 2006 20:11:28 -0400 Received: from [192.168.0.41] (pool-138-89-46-232.mad.east.verizon.net [138.89.46.232]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k560BIOb004204 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 5 Jun 2006 20:11:18 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] [issue2] Is it allowed tospecifycivicand geospatialinfointo the query? Date: Mon, 5 Jun 2006 20:11:14 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a9ddb14fac983e71b59f23b52a45b4e 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 Yes, you could do that, but you now have to carry possibly two error indications, have to worry about carrying two boundaries, etc. Just made the protocol much messier, for both client and server. It gets worse: in all likelihood, the server has to recurse or iterate differently for civic and geo coordinates, so the server has to wait until both results are in from upstream servers (or return just one result after a timeout). This all just seems pointlessly complex, given that the same result can be trivially achieved by splitting the query. On Jun 5, 2006, at 8:04 PM, Winterbottom, James wrote: > Why wouldn't the LoSt server simply treat each representation on > its own > merits? You give me two locations you get back 2 URIs, even if they > are > the same. > > >> -----Original Message----- >> From: Marc Linsner [mailto:mlinsner@cisco.com] >> Sent: Tuesday, 6 June 2006 9:44 AM >> To: 'Roger Marshall'; 'Andrew Newton' >> Cc: ecrit@ietf.org >> Subject: RE: [Ecrit] [issue2] Is it allowed tospecifycivicand >> geospatialinfointo the query? >> >> Roger, >> >> I'm not arguing geo vs. civil. All I am trying to state is when > multiple >> location representations are known for a LoST client, the LoST >> server/service should not be the one to determine which >> representation > is >> best. >> >> Setup for failure example #1: A single LoST query contains both a > civic >> (123 >> Main St.) and a geo representation. All geocode databases return 456 >> Second >> St. for the geo. Which one should LoST prefer? >> >> Setup for failure example #2: A single LoST query contains two civic >> representations. One is in New York City and the other in Seattle. > Which >> one should LoST prefer? >> >> IMO, each example should be (2) unique queries, one for each >> representation, >> and let the client deal with it. This decision needs to be made as > close >> to >> a human as possible, I don't foresee any programmatic solution. If > the >> client holds (2) location representations, the problem is theirs and > needs >> to be resolved there. Once a PSAP call taker (a second human) is >> involved, >> then the two humans can negotiate the issue. >> >> Too many variables to standardize a solution. >> >> -Marc- >> >> >> >> >>> >>> Marc: >>> What is the scale of "accuracy" for a civic street address? > 0%,100%? >>> >>> Just because both civic and geo are included, doesn't mean >>> one is better. For example, it is obvious that lat/lon's >>> have measurement criteria whereas civic addresses don't, >>> since they're either "stated" or "derived". >>> >>> Parcel-based GIS mapping systems exist today which describe a >>> location in terms of both. As a simple example, Google Earth >>> does this for you. >>> You specify 123 Main Street, Anytown, USA and once it finds >>> it, it also provides a lat/lon. I admit that the there are >>> challenges with using both, but I expect that those issues >>> will become fewer over time. >>> >>> Does there have to be a line in the sand as to whether a >>> particular location is known in terms of civic vs. geo and >>> not both? I don't think so. >>> >>> >>> Roger Marshall >>> >>> >>>> -----Original Message----- >>>> From: Marc Linsner [mailto:mlinsner@cisco.com] >>>> Sent: Monday, June 05, 2006 3:23 PM >>>> To: 'Andrew Newton' >>>> Cc: ecrit@ietf.org >>>> Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivicand >>>> geospatialinfointo the query? >>>> >>>> Andy, >>>> >>>> The problem is that the 'preferred' location is the accurate >>> one. No >>>> LoST server/service will be able to determine which one is most >>>> accurate. You may equate the same problem to the client, >>> but IMO, it's >>>> better that the client make the decision since it's closer >>> to the human >>>> that 'should' know. >>>> >>>> -Marc- >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Andrew Newton [mailto:andy@hxr.us] >>>>> Sent: Monday, June 05, 2006 5:58 PM >>>>> To: Marc Linsner >>>>> Cc: 'Hannes Tschofenig'; ecrit@ietf.org >>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civicand >>>>> geospatialinfointo the query? >>>>> >>>>> I think we'd have a protocol more capable of adapting to >>> unforeseen, >>>>> real world issues if both were sent and the server had the >>>> opportunity >>>>> to determine which type of location it preferred. I must >>> admit that >>>>> it seems a bit of a stretch, but I think it is just as possible > as >>>>> Henning's idea that the client will have the same type of >>>> notion. It >>>>> almost always seems to me that if ever there is a question about >>>>> preference, it should fall to the LoST service operators and > their >>>>> jurisdictional considerations. >>>>> >>>>> It also seems to me that if a client or seeker does, in some >>>> odd way, >>>>> have a notion of a preferred type of location when it >>>> possesses both, >>>>> that it can always just send the query with only the type of >>>> location >>>>> it prefers. For clients that don't have this strong notion, >>>> send both >>>>> and see if the server has a preference. >>>>> >>>>> -andy >>>>> >>>>> >>>>> On Jun 5, 2006, at 5:39 PM, Marc Linsner wrote: >>>>> >>>>>> I agree, the LoST client submits one location at a time. >>>>> No decisions >>>>>> made by LoST server/service. >>>>>> >>>>>> -Marc- >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>> Sent: Monday, June 05, 2006 5:24 PM >>>>>>> To: Roger Marshall >>>>>>> Cc: ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify > civicand >>>>>>> geospatialinfointo the query? >>>>>>> >>>>>>> Hi Roger, >>>>>>> >>>>>>> Roger Marshall wrote: >>>>>>>> Hannes: Thanks for clarifying. >>>>>>>> >>>>>>>> I think it's a bad idea to withold location information >>>>>>> from the LoST >>>>>>>> server. >>>>>>>> >>>>>>>> To suggest that we restrict the client, allowing only one >>>>>>> to be sent, >>>>>>>> sounds to me like we're placing a constraint on the >>>>>>> PIDF-LO, saying it >>>>>>>> can't have both (assuming LoST reuses the PIDF-LO). I >>>>>>> don't think we >>>>>>>> can get away with that. If the PIDF-LO has both, how is >>>>>>> it that we can >>>>>>>> glibly strip one out? To do so would be unreasonable. >>>>>>> >>>>>>> To clarify: >>>>>>> >>>>>>> * You can send as many queries as you want but not with >>> the same >>>>>>> message. Different location information => different query >>>>>>> >>>>>>> * We don't use a PIDF-LO in LoST. We use the raw location > info. >>>>>>> >>>>>>>> >>>>>>>> Since the client can have both civic and geo in the >>>>> PIDF-LO, it can >>>>>>>> also send both to the server. What am I missing? >>>>>>> >>>>>>> None of the proposals ever used a PIDF-LO as input; >>> just location >>>>>>> info. >>>>>>> >>>>>>>> >>>>>>>> It's the LoST server's job to pick one, not the client's. >>>>>>> >>>>>>> At the PSAP and the emergency routing proxy I agree with you. >>>>>>> >>>>>>>> >>>>>>>> So, the requirement I would support is as follows: >>>>>>>> >>>>>>>> Rx' LoST client SHALL query with either civic or geo. >>>>>>> >>>>>>> That's fine. >>>>>>> >>>>>>> >>>>>>>> Ry' LoST client SHOULD query with *both* civic and geo. >>>>> When LoST >>>>>>>> server receives both civic and geo, the server SHOULD try >>>>>>> to use the >>>>>>>> geo first. The LoST server response SHALL indicate which >>>>> data was >>>>>>>> used (either geo or civic). >>>>>>> >>>>>>> I guess you will not support for this one based on the >>>>> response I saw >>>>>>> on the list so far. >>>>>>> >>>>>>> Ciao >>>>>>> Hannes >>>>>>> >>>>>>>> >>>>>>>> -roger. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>> Sent: Monday, June 05, 2006 1:50 PM >>>>>>>>> To: Roger Marshall >>>>>>>>> Cc: Brian Rosen; ecrit@ietf.org >>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify >>>> civic and >>>>>>>>> geospatialinfointo the query? >>>>>>>>> >>>>>>>>> Hi Roger, >>>>>>>>> >>>>>>>>> I think the current suggestion is that the LoST client >>>>> just picks >>>>>>>>> whatever he wants and then uses the mapping protocol to >>>>> trigger the >>>>>>>>> resolution. >>>>>>>>> >>>>>>>>> Using geo and civic might be, from a certain point of view, >>>>>>> just be an >>>>>>>>> optimization. The LoST client can always trigger separate >>>>>>> queries with >>>>>>>>> all the location info it has. >>>>>>>>> >>>>>>>>> Ciao >>>>>>>>> Hannes >>>>>>>>> >>>>>>>>> Roger Marshall wrote: >>>>>>>>> >>>>>>>>>> I don't disagree that we ask the LoST server to pick one > and >>>>>>>>> >>>>>>>>> use it. >>>>>>>>> >>>>>>>>>> We need to be consistent though, and so therefore, I > propose >>>>>>>>> >>>>>>>>> that the >>>>>>>>> >>>>>>>>>> LoST server always picks the geo over the civic and returns >>>>>>>>> >>>>>>>>> a flag in >>>>>>>>> >>>>>>>>>> the response stating that the geo was used to >>> perform mapping. >>>>>>>>>> >>>>>>>>>> Roger. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>>>> Sent: Monday, June 05, 2006 1:39 PM >>>>>>>>>>> To: Brian Rosen >>>>>>>>>>> Cc: ecrit@ietf.org >>>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify >>>>> civic and >>>>>>>>>>> geospatialinfointo the query? >>>>>>>>>>> >>>>>>>>>>> It seems that we closed this issue. >>>>>>>>>>> >>>>>>>>>>> Everyone seems to be in favor for a civic OR geospatial. >>>>>>>>>>> Extensions possible for future applications. >>>>>>>>>>> >>>>>>>>>>> Ciao >>>>>>>>>>> Hannes >>>>>>>>>>> >>>>>>>>>>> Brian Rosen wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I think this is the issue. There is no guidance we >>>>> can give the >>>>>>>>>>>> server to tell it how to resolve what to do when both >>>>>>>>> >>>>>>>>> locations are >>>>>>>>> >>>>>>>>>>>> valid but the URI for the geo does match the URI for >>>>> the civic. >>>>>>>>>>>> >>>>>>>>>>>> This happens a lot when you are near boundaries because > the >>>>>>>>>>> >>>>>>>>>>> precision >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> and accuracy of the two methods differ. >>>>>>>>>>>> >>>>>>>>>>>> I think you pick ONE and use it. >>>>>>>>>>>> >>>>>>>>>>>> Even if you send more than one along, the PSAP has to > know >>>>>>>>> >>>>>>>>> which one >>>>>>>>> >>>>>>>>>>>> you used to route. It's going to continue to use that >>>>>>>>> >>>>>>>>> until a human >>>>>>>>> >>>>>>>>>>>> says otherwise. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>>>>>>>>> Sent: Monday, June 05, 2006 3:55 PM >>>>>>>>>>>> To: Andrew Newton >>>>>>>>>>>> Cc: ecrit@ietf.org >>>>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to >>>>> specify civic and >>>>>>>>>>>> geospatialinfo into the query? >>>>>>>>>>>> >>>>>>>>>>>> At the PSAP, we have a human that can look at this >>>>>>> information and >>>>>>>>>>>> make decisions (and maybe even ask if there's a >>>>>>> discrepancy). That >>>>>>>>>>>> seems a stretch for the LoST server. >>>>>>>>>>>> >>>>>>>>>>>> Andrew Newton wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> In all of these dual-information cases, I don't see >>>>>>> how anybody >>>>>>>>>>>>>> except the seeker can make any determination >>> which type of >>>>>>>>>>>>>> information is better, more accurate, more recent, etc. >>>>>>>>>>>>> >>>>>>>>>>>>> Would we want the seeker to determine which information > it >>>>>>>>> >>>>>>>>> feels is >>>>>>>>> >>>>>>>>>>>>> best to provide to the PSAP? I've always heard that the >>>>>>>>>>> >>>>>>>>>>> answer would be no: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> provide both to the PSAP. So why then would we not >>>>>>>>> >>>>>>>>> provide the same >>>>>>>>> >>>>>>>>>>>>> information when determining which PSAP to contact? >>>>>>>>>>>>> >>>>>>>>>>>>> -andy >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Ecrit mailing list >>>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Ecrit mailing list >>>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Ecrit mailing list >>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > ---------------------------------------------------------------------- > -------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ---------------------------------------------------------------------- > -------------------------- > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 20:17:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPG0-0002mz-Vw; Mon, 05 Jun 2006 20:17:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPFz-0002jC-R4 for ecrit@ietf.org; Mon, 05 Jun 2006 20:17:15 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPFy-0006IX-Ig for ecrit@ietf.org; Mon, 05 Jun 2006 20:17:15 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 19:17:40 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 05 Jun 2006 19:17:38 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 19:17:38 -0500 Message-ID: From: "Thomson, Martin" To: "Henning Schulzrinne" , "LoST Issue Tracker" Date: Mon, 5 Jun 2006 19:17:01 -0500 Subject: RE: [Ecrit] [issue3] List all Services Functionality MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 06 Jun 2006 00:17:38.0509 (UTC) FILETIME=[9E45E7D0:01C688FE] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <44849B88.8050003@cs.columbia.edu> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] [issue3] List all Services Functionality Thread-Index: AcaI5FW6K7FrxyvDT6OrMydcqp3ShwAGbFfA X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1518385884==" Errors-To: ecrit-bounces@ietf.org --===============1518385884== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message TXkgdGhvdWdodCBvbiB0aGUgdG9waWMgd2FzIHRoYXQgeW91IGNhbiBxdWVyeSBmb3INCg0KICB1 cm46c2VydmljZTpzb3MuKg0KDQpUaGlzIGNhbiBlaXRoZXIgcmVzdWx0IGluIGEgc3ViLXRyZWUs IG9yIGp1c3QgYSBsaXN0IG9mIHRoZSBpbW1lZGlhdGUgY2hpbGRyZW4gb2YgdGhhdCBub2RlLiAg SSBkb24ndCBzZWUgYW55IHBhcnRpY3VsYXJseSBzdHJvbmcgcmVhc29uIGZvciBlaXRoZXIgKG1h a2UgeW91ciBvd24gdHJhZGUtb2ZmKS4NCg0KSG93ZXZlciwgdG8gYmUgY2xlYXIsIEkgdGhpbmsg dGhhdCBhIHF1ZXJ5IGZvciAidXJuOnNlcnZpY2U6KiIgaXMgaW1wcmFjdGljYWwgYW5kIHBvdGVu dGlhbGx5IGRhbmdlcm91cy4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBIZW5uaW5nIFNjaHVsenJpbm5lIFttYWlsdG86aGdzQGNzLmNvbHVtYmlhLmVkdV0NCj4gU2Vu dDogVHVlc2RheSwgNiBKdW5lIDIwMDYgNzowMSBBTQ0KPiBUbzogTG9TVCBJc3N1ZSBUcmFja2Vy DQo+IENjOiBlY3JpdEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0Vjcml0XSBbaXNzdWUzXSBM aXN0IGFsbCBTZXJ2aWNlcyBGdW5jdGlvbmFsaXR5DQo+IA0KPiANCj4gDQo+IEhhbm5lcyBUc2No b2ZlbmlnIHdyb3RlOg0KPiA+IE5ldyBzdWJtaXNzaW9uIGZyb20gSGFubmVzIFRzY2hvZmVuaWcg PEhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQ+Og0KPiA+DQo+ID4gRG8gd2UgbmVlZCB0aGUgY2Fw YWJpbGl0eSB0byBsaXN0IGFsbCBzZXJ2aWNlcyBzdXBwb3J0ZWQgYnkgdGhlIExvU1QNCj4gc2Vy dmVyPw0KPiANCj4gSSBkb24ndCB0aGluayBldmVyeSBzZXJ2ZXIgbmVlZHMgdG8gc3VwcG9ydCB0 aGlzLCBidXQgaXQgZG9lcyBzZWVtIHVzZWZ1bC4NCj4gDQo+IA0KPiANCj4gPiBXb3VsZCB0aGlz IGZlYXR1cmUgYmUgdXNlZnVsIGlmIHRoZSBzZXJ2aWNlIGxpc3QgaXMgY29uc3RyYWludCB0byBh DQo+IGNlcnRhaW4NCj4gPiBicmFuY2ggb2YgdGhlIHRyZWU/DQo+IA0KPiBCeSB0aGUgY3VycmVu dCBkZXNpZ24sIGVhY2ggdG9wLWxldmVsIHNlcnZpY2UgY2FuIGhhdmUgYSBkaWZmZXJlbnQgTG9T VA0KPiBzZXJ2ZXIsIHNvIEkgc3VwcG9zZSB0aGUgb25seSBxdWVzdGlvbiBpcyB3aGV0aGVyIG9u bHkNCj4gDQo+ICgxKSB1cm46c2VydmljZTpzb3MNCj4gDQo+IG9yIGFsc28NCj4gDQo+ICgyKSB1 cm46c2VydmljZTpzb3MuZmlyZSBbYWxsIHNlcnZpZXMNCj4gDQo+IGFuZCBtb3JlIGRlZXBseS1u ZXN0ZWQgVVJOcyBzaG91bGQgYmUgYSBxdWVyeSBpbnB1dC4gTXkgaW5jbGluYXRpb24gaXMNCj4g dG8gc3VwcG9ydCBib3RoLCBhbHRob3VnaCBJIGNvdWxkIGVhc2lseSBiZSBjb252aW5jZWQgdGhh dCBrZWVwaW5nIGl0DQo+IHNpbXBsZSBhbmQgb25seSBzdXBwb3J0aW5nIG9uZSB0eXBlIG9mIHF1 ZXJ5IChhcyBpbiAoMSkpIGlzIHN1ZmZpY2llbnQuDQo+IA0KPiBIZW5uaW5nDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBFY3JpdCBtYWls aW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZWNyaXQNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFu ZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2 YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5h bC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJd --===============1518385884== 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 --===============1518385884==-- From ecrit-bounces@ietf.org Mon Jun 05 20:18:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPHK-0003JV-Az; Mon, 05 Jun 2006 20:18:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPHI-0003JP-UY for ecrit@ietf.org; Mon, 05 Jun 2006 20:18:36 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPHI-0006Jv-IX for ecrit@ietf.org; Mon, 05 Jun 2006 20:18:36 -0400 Received: from [192.168.0.41] (pool-138-89-46-232.mad.east.verizon.net [138.89.46.232]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k560IYjG004882 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 5 Jun 2006 20:18:34 -0400 (EDT) In-Reply-To: <8C837214C95C864C9F34F3635C2A657505131429@SEA-EXCHVS-2.telecomsys.com> References: <8C837214C95C864C9F34F3635C2A657505131429@SEA-EXCHVS-2.telecomsys.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <414AC67C-EAB2-44C7-918B-ACD3C3858D03@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfointo the query? Date: Mon, 5 Jun 2006 20:18:30 -0400 To: "Roger Marshall" X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Extracting civic and/or geo element from PIDF-LO seems rather trivial for the client and the basic division of PIDF-LO would need more than just a minor change in the spec. (In any event, in many cases, the client will need to construct the location information from local non- XML data, be it GPS, LLDP-MED or DHCP, and can't just blindly copy some XML blob it's been handed.) No, I'm not worried about the few extra elements, although they are not particularly helpful (and, in the case of the entity URL, may need scrubbing to avoid revealing unnecessary privacy-sensitive personal information downstream). On Jun 5, 2006, at 6:23 PM, Roger Marshall wrote: > I admit that this theme is somewhat of a tangent to the subject, > but can > the authors of LoST help me understand the reasons for not using the > PIDF-LO. > > Is it the overhead? Is the PIDF-LO not adequate to convey location > some > how? > > As an example, if the PIDF-LO format is changed significantly in some > way, it will mandate a s/w change to ~10^8 clients vs. only ~10^2 - > 10^4 > server instances. > > It seems to me that as the PIDF-LO undergoes changes over time, > that the > choice between having to modify client software vs. server software > instances represents a huge difference in effort. > > > Roger Marshall > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Monday, June 05, 2006 2:24 PM >> To: Roger Marshall >> Cc: Brian Rosen; ecrit@ietf.org >> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic >> and geospatialinfointo the query? >> >> Hi Roger, >> >> Roger Marshall wrote: >>> Hannes: Thanks for clarifying. >>> >>> I think it's a bad idea to withold location information from >> the LoST >>> server. >>> >>> To suggest that we restrict the client, allowing only one to >> be sent, >>> sounds to me like we're placing a constraint on the PIDF-LO, >> saying it >>> can't have both (assuming LoST reuses the PIDF-LO). I don't >>> think we >>> can get away with that. If the PIDF-LO has both, how is it >> that we can >>> glibly strip one out? To do so would be unreasonable. >> >> To clarify: >> >> * You can send as many queries as you want but not with the >> same message. Different location information => different query >> >> * We don't use a PIDF-LO in LoST. We use the raw location info. >> >>> >>> Since the client can have both civic and geo in the PIDF-LO, it can >>> also send both to the server. What am I missing? >> >> None of the proposals ever used a PIDF-LO as input; just location >> info. >> >>> >>> It's the LoST server's job to pick one, not the client's. >> >> At the PSAP and the emergency routing proxy I agree with you. >> >>> >>> So, the requirement I would support is as follows: >>> >>> Rx' LoST client SHALL query with either civic or geo. >> >> That's fine. >> >> >>> Ry' LoST client SHOULD query with *both* civic and geo. When LoST >>> server receives both civic and geo, the server SHOULD try to use the >>> geo first. The LoST server response SHALL indicate which data was >>> used (either geo or civic). >> >> I guess you will not support for this one based on the >> response I saw on the list so far. >> >> Ciao >> Hannes >> >>> >>> -roger. >>> >>> >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Monday, June 05, 2006 1:50 PM >>>> To: Roger Marshall >>>> Cc: Brian Rosen; ecrit@ietf.org >>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >>>> geospatialinfointo the query? >>>> >>>> Hi Roger, >>>> >>>> I think the current suggestion is that the LoST client just picks >>>> whatever he wants and then uses the mapping protocol to trigger the >>>> resolution. >>>> >>>> Using geo and civic might be, from a certain point of view, >> just be an >>>> optimization. The LoST client can always trigger separate >> queries with >>>> all the location info it has. >>>> >>>> Ciao >>>> Hannes >>>> >>>> Roger Marshall wrote: >>>> >>>>> I don't disagree that we ask the LoST server to pick one and >>>> >>>> use it. >>>> >>>>> We need to be consistent though, and so therefore, I propose >>>> >>>> that the >>>> >>>>> LoST server always picks the geo over the civic and returns >>>> >>>> a flag in >>>> >>>>> the response stating that the geo was used to perform mapping. >>>>> >>>>> Roger. >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>> Sent: Monday, June 05, 2006 1:39 PM >>>>>> To: Brian Rosen >>>>>> Cc: ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >>>>>> geospatialinfointo the query? >>>>>> >>>>>> It seems that we closed this issue. >>>>>> >>>>>> Everyone seems to be in favor for a civic OR geospatial. >>>>>> Extensions possible for future applications. >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> Brian Rosen wrote: >>>>>> >>>>>> >>>>>>> I think this is the issue. There is no guidance we can give the >>>>>>> server to tell it how to resolve what to do when both >>>> >>>> locations are >>>> >>>>>>> valid but the URI for the geo does match the URI for the civic. >>>>>>> >>>>>>> This happens a lot when you are near boundaries because the >>>>>> >>>>>> precision >>>>>> >>>>>> >>>>>>> and accuracy of the two methods differ. >>>>>>> >>>>>>> I think you pick ONE and use it. >>>>>>> >>>>>>> Even if you send more than one along, the PSAP has to know >>>> >>>> which one >>>> >>>>>>> you used to route. It's going to continue to use that >>>> >>>> until a human >>>> >>>>>>> says otherwise. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>>>> Sent: Monday, June 05, 2006 3:55 PM >>>>>>> To: Andrew Newton >>>>>>> Cc: ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >>>>>>> geospatialinfo into the query? >>>>>>> >>>>>>> At the PSAP, we have a human that can look at this >> information and >>>>>>> make decisions (and maybe even ask if there's a >> discrepancy). That >>>>>>> seems a stretch for the LoST server. >>>>>>> >>>>>>> Andrew Newton wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> In all of these dual-information cases, I don't see how >>>>>>>>> anybody >>>>>>>>> except the seeker can make any determination which type of >>>>>>>>> information is better, more accurate, more recent, etc. >>>>>>>> >>>>>>>> Would we want the seeker to determine which information it >>>> >>>> feels is >>>> >>>>>>>> best to provide to the PSAP? I've always heard that the >>>>>> >>>>>> answer would be no: >>>>>> >>>>>> >>>>>>>> provide both to the PSAP. So why then would we not >>>> >>>> provide the same >>>> >>>>>>>> information when determining which PSAP to contact? >>>>>>>> >>>>>>>> -andy >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> >> > > _______________________________________________ > 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 Jun 05 20:21:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPKO-0006Lv-MQ; Mon, 05 Jun 2006 20:21:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPKN-0006DI-Dt for ecrit@ietf.org; Mon, 05 Jun 2006 20:21:47 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPKM-0006Op-7L for ecrit@ietf.org; Mon, 05 Jun 2006 20:21:47 -0400 Received: from [192.168.0.41] (pool-138-89-46-232.mad.east.verizon.net [138.89.46.232]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k560LcHo006424 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 5 Jun 2006 20:21:39 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9BC979E3-2DB7-4986-897B-22107F777B5D@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] [issue3] List all Services Functionality Date: Mon, 5 Jun 2006 20:21:34 -0400 To: "Thomson, Martin" X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 5, 2006, at 8:17 PM, Thomson, Martin wrote: > My thought on the topic was that you can query for > > urn:service:sos.* > > This can either result in a sub-tree, or just a list of the > immediate children of that node. I don't see any particularly > strong reason for either (make your own trade-off). I can agree with that. If we go with that approach, queries for any subtree must also be possible, so that the client can recurse if the server didn't. > > However, to be clear, I think that a query for "urn:service:*" is > impractical and potentially dangerous. Agreed. To be clear as well, I don't think this equivalent of "ls -R" cannot be supported in general, given the issue that different top- level services may have completely different LoST server hierarchies. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 20:27:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPQJ-0008DA-Lw; Mon, 05 Jun 2006 20:27:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPQH-0008Bo-Uh for ecrit@ietf.org; Mon, 05 Jun 2006 20:27:53 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPQG-0006YD-OJ for ecrit@ietf.org; Mon, 05 Jun 2006 20:27:53 -0400 Received: from [192.168.0.41] (pool-138-89-46-232.mad.east.verizon.net [138.89.46.232]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k560RnRQ005714 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 5 Jun 2006 20:27:50 -0400 (EDT) In-Reply-To: References: <024701c688e0$7cc7ab70$640fa8c0@cis.neustar.com> <4484A04C.7080600@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] [issue6] 'Authority' Attribute in LoST Response Date: Mon, 5 Jun 2006 20:27:46 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 > > Just why would I want to ask the same question multiple times to > the same server in the same seek operation? It would seem that > detecting referral loops would be awfully important. The type of > identifier used is not that important, so a URI is fine by me. It's a bit of a stretch, so a URL that identifies the actual "virtual" host is probably sufficient to deal with the case that a single server can serve multiple levels (such as state and some towns within a state, but not county). > I'm not sure about multiple URIs. Also, you'd need to define a > much more detailed interface for automated checking than "here is a > bunch of URIs". The idea for automated checking would be that the checker is a robot, but it would just generate text meant for a human, just like web checkers generate mail to webmaster@domain that's meant to be interpreted by a human. As long as there's no particular format requirement, the URL is pretty self-describing, just like a link is on a web page. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 20:31:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPU9-0003px-Ju; Mon, 05 Jun 2006 20:31:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPU8-0003kG-Bb for ecrit@ietf.org; Mon, 05 Jun 2006 20:31:52 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPU7-0007Fj-2k for ecrit@ietf.org; Mon, 05 Jun 2006 20:31:52 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 19:32:16 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 05 Jun 2006 19:32:15 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 19:32:15 -0500 Message-ID: From: "Thomson, Martin" To: "Henning Schulzrinne" , "Hannes Tschofenig" Date: Mon, 5 Jun 2006 19:31:26 -0500 Subject: RE: [Ecrit] [issue4] Service URN in Response Message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 06 Jun 2006 00:32:15.0068 (UTC) FILETIME=[A8BE31C0:01C68900] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <4484A148.4080001@cs.columbia.edu> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] [issue4] Service URN in Response Message Thread-Index: AcaI5utNkDcRp2v2Tpq5sIh8k0Dz4wAGLPdw X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2111494478==" Errors-To: ecrit-bounces@ietf.org --===============2111494478== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message SSBhZ3JlZSwgd2UgbmVlZCB0byBiZSBjbGVhcmVyIGFib3V0IHdoYXQgdGhlIExvU1Qgc2VydmVy IGlzIGRvaW5nLg0KDQpJIHByb3Bvc2UgdGhhdCBpdCBiZSBwb3NzaWJsZSB0byByZXF1ZXN0IGZv ciAidXJuOnNlcnZpY2U6eC55LnoiIGFuZCBnZXQgYSByZXN1bHQgZm9yIGVpdGhlciAidXJuOnNl cnZpY2U6eC55IiBvciAidXJuOnNlcnZpY2U6eCIuICBUaGF0IGlzIHdoYXQgdGhlIG9yaWdpbmFs IHRleHQgc2FpZC4gIEkgdGhpbmsgd2UgY2FuIGJlIGNsZWFyZXIgYW5kIHNheSB0aGF0IHlvdSBz aG91bGQgbmV2ZXIgZ2V0ICJ1cm46c2VydmljZTp4IiB1bmxlc3MgeW91ciByZXF1ZXN0IHN0YXJ0 ZWQgd2l0aCAidXJuOnNlcnZpY2U6eCIgYW5kIHlvdSBjYW4gbmV2ZXIgZ2V0ICJ1cm46c2Vydmlj ZTp4LnkiIGlmIHlvdSBhc2tlZCBmb3IgInVybjpzZXJ2aWNlOngiLiAgVGhhdCBpcywgdGhlIHNl cnZlciBjYW4gZ28gdXAgdGhlIHRyZWUsIGJ1dCBuZXZlciBzaWRld2F5cyBvciBkb3duLg0KDQoo VGhlIGZhY3QgdGhhdCAidXJuOnNlcnZpY2U6eCIgPT0gInVybjpzZXJ2aWNlOngueSIgaXMgc29t ZXRoaW5nIEkgZG9uJ3QgY2FyZSBhYm91dDsgdGhhdCdzIGp1cmlzZGljdGlvbmFsIHNwZWNpZmlj IGFuZCBjYW4gYmUgc29sdmVkIHdpdGggc2VydmVyIGNvbmZpZ3VyYXRpb24uICBUaGlzIHNob3Vs ZG4ndCBiZSBjb25mdXNlZCB3aXRoIHRoZSBmYWxsYmFjayBvcHRpb24uKQ0KDQpPbiBwYXJhbWV0 ZXJzLCBCcmlhbiBoYWQgaXQgcmlnaHQuICBJZiB0aGlzIGZhbGxiYWNrIG9jY3VycywgbWFrZSBz dXJlIHRoZSBjbGllbnQga25vd3MuICBBICJzdHJpY3QiIHBhcmFtZXRlciBpc24ndCBuZWNlc3Nh cnksIHByb3ZpZGluZyB0aGlzIGJlaGF2aW91ciBpcyBjbGVhci4NCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBIZW5uaW5nIFNjaHVsenJpbm5lIFttYWlsdG86aGdzQGNz LmNvbHVtYmlhLmVkdV0NCj4gU2VudDogVHVlc2RheSwgNiBKdW5lIDIwMDYgNzoyNSBBTQ0KPiBU bzogSGFubmVzIFRzY2hvZmVuaWcNCj4gQ2M6IGVjcml0QGlldGYub3JnDQo+IFN1YmplY3Q6IFJl OiBbRWNyaXRdIFtpc3N1ZTRdIFNlcnZpY2UgVVJOIGluIFJlc3BvbnNlIE1lc3NhZ2UNCj4gDQo+ IEknZCBsaWtlIHRvIGJldHRlciB1bmRlcnN0YW5kIHRoZSBtb2RlbCB0aGF0IHBlb3BsZSBoYXZl IGluIG1pbmQsIHdoZXJlDQo+IHRoaXMgY29uZGl0aW9uIHdvdWxkIGFjdHVhbGx5IG9jY3VyIGFu ZCB3aGVyZSB0aGlzIGluZm9ybWF0aW9uIHdvdWxkDQo+IGFjdHVhbGx5IGJlIHVzZWZ1bCB0byB0 aGUgcXVlcmllci4gKEkgZG9uJ3QgdGhpbmsgdGhlIHF1ZXJpZXIgbmVlZHMgdG8NCj4ga25vdyB3 aGljaCBlbWVyZ2VuY3kgc2VydmljZXMgaGFwcGVuIHRvIGFsbCBsYW5kIG9uIHRoZSBzYW1lIFBT QVAgaW4gYQ0KPiBwYXJ0aWN1bGFyIGFyZWEuKQ0KPiANCj4gPj4gVGh1cywgSSB0aGluayB0aGlz IGlzIHB1cmVseSBhIHNlcnZlciBjb25maWd1cmF0aW9uIGlzc3VlIHdoZXJlIHRoZQ0KPiA+PiBz ZXJ2ZXIgZGF0YWJhc2UgaXMgc2V0IHVwIHRvIHJldHVybiBhIGRlZmF1bHQgdmFsdWUgZm9yIHVu a25vd24NCj4gPj4gZW1lcmdlbmN5IHNlcnZpY2VzLiBUaGlzIHNlZW1zIHRvIGJlIHRoZSBjYXNl IGluIHByYWN0aWNlIHRvZGF5OiBldmVuDQo+ID4+IGluIHBsYWNlcyB3aGVyZSB0aGVyZSBhcmUg c2VwYXJhdGUgbnVtYmVycyBmb3IgdmFyaW91cyBzZXJ2aWNlcywgaWYNCj4gPj4geW91IGRvbid0 IGtub3cgd2hvbSB0byBjYWxsIGZvciBhICJub24tc3RhbmRhcmQiIGVtZXJnZW5jeSwgeW91J2QN Cj4gPj4gcHJvYmFibHkgY2FsbCB0aGUgcG9saWNlLg0KPiA+DQo+ID4gV2l0aCB5b3VyIGRlc2Ny aXB0aW9uIGl0IHdvdWxkIG5vdCBtYWtlIHNlbnNlIHRvIHJldHVybiB0aGUgc2VydmljZSBVUk4N Cj4gPiBpbiB0aGUgcmVzcG9uc2UgbWVzc2FnZSBpZiB3ZSBhc3N1bWUgdGhhdCB0aGUgcXVlcmll ciBkb2VzIG5vdCBjYXJlDQo+ID4gYWJvdXQgdGhpcyBhc3BlY3QuIFdvdWxkIHRoaXMgYmUgT0sg Zm9yIHlvdT8NCj4gPg0KPiA+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRo ZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwg cHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3Ug aGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1l ZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9m DQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClttZjJd --===============2111494478== 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 --===============2111494478==-- From ecrit-bounces@ietf.org Mon Jun 05 20:32:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPUT-0004Ni-In; Mon, 05 Jun 2006 20:32:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPUS-0004NQ-00 for ecrit@ietf.org; Mon, 05 Jun 2006 20:32:12 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPUR-0007GH-59 for ecrit@ietf.org; Mon, 05 Jun 2006 20:32:11 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 05 Jun 2006 17:32:11 -0700 X-IronPort-AV: i="4.05,212,1146466800"; d="scan'208"; a="429909809:sNHT35761126" 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/8.12.11) with ESMTP id k560WAZM011181; Mon, 5 Jun 2006 17:32:10 -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 k560WAA2007168; Mon, 5 Jun 2006 17:32:10 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Jun 2006 17:31:54 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Jun 2006 17:31:52 -0700 From: "Marc Linsner" To: "'Winterbottom, James'" Subject: RE: [Ecrit] [issue2] Is it allowed tospecifycivicand geospatialinfointo the query? Date: Mon, 5 Jun 2006 20:31:50 -0400 Message-ID: <006701c68900$9c2a21d0$2c0d0d0a@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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaI6zjnhQc8CUHLTvKUn0joHvMpxgAAhz/AAABd9UAAAiMDIAABQpIgAADvqdA= X-OriginalArrivalTime: 06 Jun 2006 00:31:54.0344 (UTC) FILETIME=[9C63F680:01C68900] DKIM-Signature: a=rsa-sha1; q=dns; l=15304; t=1149553930; x=1150417930; c=relaxed/simple; s=sjdkim3001; 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]=20[issue2]=20Is=20it=20allowed=20tospecifycivicand=09geo spatialinfointo=20the=20query?; X=v=3Dcisco.com=3B=20h=3DvDtJI3f0MrHHcf1xhy4jlH4sCxE=3D; b=m4dTTXQwsQsvB0U9kWMrsjXb/dsFkXCIqchoD8p8c1IOjkN7nSFR17MSwUwW5bfjWL98L9tb 790mBo1CHJ32yI4XpW+KEnAdySeiiHYnBzGdi1AqTS3IQ5/UZh3WeFB7; 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: c375f2012a4f820b0c0fd6fb14a28357 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, What happens if the answer is in 2 different admin domains (not cached)? Does the client resolver have to wait for both responses and assemble them? One at a time is very clean and quick. -Marc- > > Why wouldn't the LoSt server simply treat each representation > on its own merits? You give me two locations you get back 2 > URIs, even if they are the same. > > > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Tuesday, 6 June 2006 9:44 AM > > To: 'Roger Marshall'; 'Andrew Newton' > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] [issue2] Is it allowed tospecifycivicand > > geospatialinfointo the query? > > > > Roger, > > > > I'm not arguing geo vs. civil. All I am trying to state is when > multiple > > location representations are known for a LoST client, the LoST > > server/service should not be the one to determine which > representation > is > > best. > > > > Setup for failure example #1: A single LoST query contains both a > civic > > (123 > > Main St.) and a geo representation. All geocode databases > return 456 > > Second St. for the geo. Which one should LoST prefer? > > > > Setup for failure example #2: A single LoST query contains > two civic > > representations. One is in New York City and the other in Seattle. > Which > > one should LoST prefer? > > > > IMO, each example should be (2) unique queries, one for each > > representation, and let the client deal with it. This > decision needs > > to be made as > close > > to > > a human as possible, I don't foresee any programmatic solution. If > the > > client holds (2) location representations, the problem is theirs and > needs > > to be resolved there. Once a PSAP call taker (a second human) is > > involved, then the two humans can negotiate the issue. > > > > Too many variables to standardize a solution. > > > > -Marc- > > > > > > > > > > > > > > Marc: > > > What is the scale of "accuracy" for a civic street address? > 0%,100%? > > > > > > Just because both civic and geo are included, doesn't mean one is > > > better. For example, it is obvious that lat/lon's have > measurement > > > criteria whereas civic addresses don't, since they're either > > > "stated" or "derived". > > > > > > Parcel-based GIS mapping systems exist today which describe a > > > location in terms of both. As a simple example, Google > Earth does > > > this for you. > > > You specify 123 Main Street, Anytown, USA and once it > finds it, it > > > also provides a lat/lon. I admit that the there are > challenges with > > > using both, but I expect that those issues will become fewer over > > > time. > > > > > > Does there have to be a line in the sand as to whether a > particular > > > location is known in terms of civic vs. geo and not both? > I don't > > > think so. > > > > > > > > > Roger Marshall > > > > > > > > > >-----Original Message----- > > > >From: Marc Linsner [mailto:mlinsner@cisco.com] > > > >Sent: Monday, June 05, 2006 3:23 PM > > > >To: 'Andrew Newton' > > > >Cc: ecrit@ietf.org > > > >Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivicand > > > >geospatialinfointo the query? > > > > > > > >Andy, > > > > > > > >The problem is that the 'preferred' location is the accurate > > > one. No > > > >LoST server/service will be able to determine which one is most > > > >accurate. You may equate the same problem to the client, > > > but IMO, it's > > > >better that the client make the decision since it's closer > > > to the human > > > >that 'should' know. > > > > > > > >-Marc- > > > > > > > > > > > > > > > >> -----Original Message----- > > > >> From: Andrew Newton [mailto:andy@hxr.us] > > > >> Sent: Monday, June 05, 2006 5:58 PM > > > >> To: Marc Linsner > > > >> Cc: 'Hannes Tschofenig'; ecrit@ietf.org > > > >> Subject: Re: [Ecrit] [issue2] Is it allowed to specify > civicand > > > >> geospatialinfointo the query? > > > >> > > > >> I think we'd have a protocol more capable of adapting to > > > unforeseen, > > > >> real world issues if both were sent and the server had the > > > >opportunity > > > >> to determine which type of location it preferred. I must > > > admit that > > > >> it seems a bit of a stretch, but I think it is just as possible > as > > > >> Henning's idea that the client will have the same type of > > > >notion. It > > > >> almost always seems to me that if ever there is a > question about > > > >> preference, it should fall to the LoST service operators and > their > > > >> jurisdictional considerations. > > > >> > > > >> It also seems to me that if a client or seeker does, in some > > > >odd way, > > > >> have a notion of a preferred type of location when it > > > >possesses both, > > > >> that it can always just send the query with only the type of > > > >location > > > >> it prefers. For clients that don't have this strong notion, > > > >send both > > > >> and see if the server has a preference. > > > >> > > > >> -andy > > > >> > > > >> > > > >> On Jun 5, 2006, at 5:39 PM, Marc Linsner wrote: > > > >> > > > >> > I agree, the LoST client submits one location at a time. > > > >> No decisions > > > >> > made by LoST server/service. > > > >> > > > > >> > -Marc- > > > >> > > > > >> >> -----Original Message----- > > > >> >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > >> >> Sent: Monday, June 05, 2006 5:24 PM > > > >> >> To: Roger Marshall > > > >> >> Cc: ecrit@ietf.org > > > >> >> Subject: Re: [Ecrit] [issue2] Is it allowed to specify > civicand > > > >> >> geospatialinfointo the query? > > > >> >> > > > >> >> Hi Roger, > > > >> >> > > > >> >> Roger Marshall wrote: > > > >> >>> Hannes: Thanks for clarifying. > > > >> >>> > > > >> >>> I think it's a bad idea to withold location information > > > >> >> from the LoST > > > >> >>> server. > > > >> >>> > > > >> >>> To suggest that we restrict the client, allowing only one > > > >> >> to be sent, > > > >> >>> sounds to me like we're placing a constraint on the > > > >> >> PIDF-LO, saying it > > > >> >>> can't have both (assuming LoST reuses the PIDF-LO). I > > > >> >> don't think we > > > >> >>> can get away with that. If the PIDF-LO has both, how is > > > >> >> it that we can > > > >> >>> glibly strip one out? To do so would be unreasonable. > > > >> >> > > > >> >> To clarify: > > > >> >> > > > >> >> * You can send as many queries as you want but not with > > > the same > > > >> >> message. Different location information => different query > > > >> >> > > > >> >> * We don't use a PIDF-LO in LoST. We use the raw location > info. > > > >> >> > > > >> >>> > > > >> >>> Since the client can have both civic and geo in the > > > >> PIDF-LO, it can > > > >> >>> also send both to the server. What am I missing? > > > >> >> > > > >> >> None of the proposals ever used a PIDF-LO as input; > > > just location > > > >> >> info. > > > >> >> > > > >> >>> > > > >> >>> It's the LoST server's job to pick one, not the client's. > > > >> >> > > > >> >> At the PSAP and the emergency routing proxy I agree > with you. > > > >> >> > > > >> >>> > > > >> >>> So, the requirement I would support is as follows: > > > >> >>> > > > >> >>> Rx' LoST client SHALL query with either civic or geo. > > > >> >> > > > >> >> That's fine. > > > >> >> > > > >> >> > > > >> >>> Ry' LoST client SHOULD query with *both* civic and geo. > > > >> When LoST > > > >> >>> server receives both civic and geo, the server SHOULD try > > > >> >> to use the > > > >> >>> geo first. The LoST server response SHALL indicate which > > > >> data was > > > >> >>> used (either geo or civic). > > > >> >> > > > >> >> I guess you will not support for this one based on the > > > >> response I saw > > > >> >> on the list so far. > > > >> >> > > > >> >> Ciao > > > >> >> Hannes > > > >> >> > > > >> >>> > > > >> >>> -roger. > > > >> >>> > > > >> >>> > > > >> >>> > > > >> >>>> -----Original Message----- > > > >> >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > >> >>>> Sent: Monday, June 05, 2006 1:50 PM > > > >> >>>> To: Roger Marshall > > > >> >>>> Cc: Brian Rosen; ecrit@ietf.org > > > >> >>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify > > > >civic and > > > >> >>>> geospatialinfointo the query? > > > >> >>>> > > > >> >>>> Hi Roger, > > > >> >>>> > > > >> >>>> I think the current suggestion is that the LoST client > > > >> just picks > > > >> >>>> whatever he wants and then uses the mapping protocol to > > > >> trigger the > > > >> >>>> resolution. > > > >> >>>> > > > >> >>>> Using geo and civic might be, from a certain > point of view, > > > >> >> just be an > > > >> >>>> optimization. The LoST client can always trigger separate > > > >> >> queries with > > > >> >>>> all the location info it has. > > > >> >>>> > > > >> >>>> Ciao > > > >> >>>> Hannes > > > >> >>>> > > > >> >>>> Roger Marshall wrote: > > > >> >>>> > > > >> >>>>> I don't disagree that we ask the LoST server to pick one > and > > > >> >>>> > > > >> >>>> use it. > > > >> >>>> > > > >> >>>>> We need to be consistent though, and so therefore, I > propose > > > >> >>>> > > > >> >>>> that the > > > >> >>>> > > > >> >>>>> LoST server always picks the geo over the civic > and returns > > > >> >>>> > > > >> >>>> a flag in > > > >> >>>> > > > >> >>>>> the response stating that the geo was used to > > > perform mapping. > > > >> >>>>> > > > >> >>>>> Roger. > > > >> >>>>> > > > >> >>>>> > > > >> >>>>> > > > >> >>>>>> -----Original Message----- > > > >> >>>>>> From: Hannes Tschofenig > [mailto:Hannes.Tschofenig@gmx.net] > > > >> >>>>>> Sent: Monday, June 05, 2006 1:39 PM > > > >> >>>>>> To: Brian Rosen > > > >> >>>>>> Cc: ecrit@ietf.org > > > >> >>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify > > > >> civic and > > > >> >>>>>> geospatialinfointo the query? > > > >> >>>>>> > > > >> >>>>>> It seems that we closed this issue. > > > >> >>>>>> > > > >> >>>>>> Everyone seems to be in favor for a civic OR geospatial. > > > >> >>>>>> Extensions possible for future applications. > > > >> >>>>>> > > > >> >>>>>> Ciao > > > >> >>>>>> Hannes > > > >> >>>>>> > > > >> >>>>>> Brian Rosen wrote: > > > >> >>>>>> > > > >> >>>>>> > > > >> >>>>>>> I think this is the issue. There is no guidance we > > > >> can give the > > > >> >>>>>>> server to tell it how to resolve what to do when both > > > >> >>>> > > > >> >>>> locations are > > > >> >>>> > > > >> >>>>>>> valid but the URI for the geo does match the URI for > > > >> the civic. > > > >> >>>>>>> > > > >> >>>>>>> This happens a lot when you are near boundaries because > the > > > >> >>>>>> > > > >> >>>>>> precision > > > >> >>>>>> > > > >> >>>>>> > > > >> >>>>>>> and accuracy of the two methods differ. > > > >> >>>>>>> > > > >> >>>>>>> I think you pick ONE and use it. > > > >> >>>>>>> > > > >> >>>>>>> Even if you send more than one along, the PSAP has to > know > > > >> >>>> > > > >> >>>> which one > > > >> >>>> > > > >> >>>>>>> you used to route. It's going to continue to use that > > > >> >>>> > > > >> >>>> until a human > > > >> >>>> > > > >> >>>>>>> says otherwise. > > > >> >>>>>>> > > > >> >>>>>>> Brian > > > >> >>>>>>> > > > >> >>>>>>> -----Original Message----- > > > >> >>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > >> >>>>>>> Sent: Monday, June 05, 2006 3:55 PM > > > >> >>>>>>> To: Andrew Newton > > > >> >>>>>>> Cc: ecrit@ietf.org > > > >> >>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to > > > >> specify civic and > > > >> >>>>>>> geospatialinfo into the query? > > > >> >>>>>>> > > > >> >>>>>>> At the PSAP, we have a human that can look at this > > > >> >> information and > > > >> >>>>>>> make decisions (and maybe even ask if there's a > > > >> >> discrepancy). That > > > >> >>>>>>> seems a stretch for the LoST server. > > > >> >>>>>>> > > > >> >>>>>>> Andrew Newton wrote: > > > >> >>>>>>> > > > >> >>>>>>> > > > >> >>>>>>> > > > >> >>>>>>>> On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: > > > >> >>>>>>>> > > > >> >>>>>>>> > > > >> >>>>>>>> > > > >> >>>>>>>>> In all of these dual-information cases, I don't see > > > >> >> how anybody > > > >> >>>>>>>>> except the seeker can make any determination > > > which type of > > > >> >>>>>>>>> information is better, more accurate, more > recent, etc. > > > >> >>>>>>>> > > > >> >>>>>>>> Would we want the seeker to determine which > information > it > > > >> >>>> > > > >> >>>> feels is > > > >> >>>> > > > >> >>>>>>>> best to provide to the PSAP? I've always > heard that the > > > >> >>>>>> > > > >> >>>>>> answer would be no: > > > >> >>>>>> > > > >> >>>>>> > > > >> >>>>>>>> provide both to the PSAP. So why then would we not > > > >> >>>> > > > >> >>>> provide the same > > > >> >>>> > > > >> >>>>>>>> information when determining which PSAP to contact? > > > >> >>>>>>>> > > > >> >>>>>>>> -andy > > > >> >>>>>>> > > > >> >>>>>>> > > > >> >>>>>>> _______________________________________________ > > > >> >>>>>>> Ecrit mailing list > > > >> >>>>>>> Ecrit@ietf.org > > > >> >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > > > >> >>>>>>> > > > >> >>>>>>> > > > >> >>>>>>> _______________________________________________ > > > >> >>>>>>> Ecrit mailing list > > > >> >>>>>>> Ecrit@ietf.org > > > >> >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > > > >> >>>>>>> > > > >> >>>>>>> > > > >> >>>>>> > > > >> >>>>>> > > > >> >>>>>> _______________________________________________ > > > >> >>>>>> Ecrit mailing list > > > >> >>>>>> Ecrit@ietf.org > > > >> >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > > > >> >>>>>> > > > >> >>>>> > > > >> >>>>> > > > >> >>>>> > > > >> >>>> > > > >> >>> > > > >> >>> > > > >> >> > > > >> >> > > > >> >> _______________________________________________ > > > >> >> Ecrit mailing list > > > >> >> Ecrit@ietf.org > > > >> >> https://www1.ietf.org/mailman/listinfo/ecrit > > > >> > > > > >> > _______________________________________________ > > > >> > Ecrit mailing list > > > >> > Ecrit@ietf.org > > > >> > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > >_______________________________________________ > > > >Ecrit mailing list > > > >Ecrit@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------- > ---------------------------------- > 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 Mon Jun 05 20:39:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPb0-0005Jm-A9; Mon, 05 Jun 2006 20:38:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPay-0005Io-PO for ecrit@ietf.org; Mon, 05 Jun 2006 20:38: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 1FnPay-0000Bt-7c for ecrit@ietf.org; Mon, 05 Jun 2006 20:38:56 -0400 Received: from [10.0.1.103] ([::ffff:68.106.115.242]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 05 Jun 2006 20:39:23 -0400 id 0158C105.4484CEBB.0000608C In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] [issue2] Is it allowed tospecifycivicand geospatialinfointo the query? Date: Mon, 5 Jun 2006 20:38:53 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: 748ed3980abc7d4bd6a14905626ff64e 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 It's an extra outer loop, and only more complex if you have somebody trying to make it that way. Otherwise, it is exactly the same amount of work. As to the point that a human, in an emergency situation, at the seeker is in a better position to make the correct judgement, I dispute that. Most people will look at lat/long coordinates and not have the faintest clue how accurate they are. If you plunk me down in the middle of Tokyo, I'd have to do a coin toss to tell you which is more accurate, civic or geo. And what about cases were the seeker is a gateway? To be honest, whether the server would know better or the client would know better is something I think none of us can answer with certainty at the moment. I would just rather not create a protocol that precludes one or the other. -andy On Jun 5, 2006, at 8:11 PM, Henning Schulzrinne wrote: > Yes, you could do that, but you now have to carry possibly two > error indications, have to worry about carrying two boundaries, > etc. Just made the protocol much messier, for both client and > server. It gets worse: in all likelihood, the server has to recurse > or iterate differently for civic and geo coordinates, so the server > has to wait until both results are in from upstream servers (or > return just one result after a timeout). This all just seems > pointlessly complex, given that the same result can be trivially > achieved by splitting the query. > > On Jun 5, 2006, at 8:04 PM, Winterbottom, James wrote: > >> Why wouldn't the LoSt server simply treat each representation on >> its own >> merits? You give me two locations you get back 2 URIs, even if >> they are >> the same. >> >> >>> -----Original Message----- >>> From: Marc Linsner [mailto:mlinsner@cisco.com] >>> Sent: Tuesday, 6 June 2006 9:44 AM >>> To: 'Roger Marshall'; 'Andrew Newton' >>> Cc: ecrit@ietf.org >>> Subject: RE: [Ecrit] [issue2] Is it allowed tospecifycivicand >>> geospatialinfointo the query? >>> >>> Roger, >>> >>> I'm not arguing geo vs. civil. All I am trying to state is when >> multiple >>> location representations are known for a LoST client, the LoST >>> server/service should not be the one to determine which >>> representation >> is >>> best. >>> >>> Setup for failure example #1: A single LoST query contains both a >> civic >>> (123 >>> Main St.) and a geo representation. All geocode databases return >>> 456 >>> Second >>> St. for the geo. Which one should LoST prefer? >>> >>> Setup for failure example #2: A single LoST query contains two civic >>> representations. One is in New York City and the other in Seattle. >> Which >>> one should LoST prefer? >>> >>> IMO, each example should be (2) unique queries, one for each >>> representation, >>> and let the client deal with it. This decision needs to be made as >> close >>> to >>> a human as possible, I don't foresee any programmatic solution. If >> the >>> client holds (2) location representations, the problem is theirs and >> needs >>> to be resolved there. Once a PSAP call taker (a second human) is >>> involved, >>> then the two humans can negotiate the issue. >>> >>> Too many variables to standardize a solution. >>> >>> -Marc- >>> >>> >>> >>> >>>> >>>> Marc: >>>> What is the scale of "accuracy" for a civic street address? >> 0%,100%? >>>> >>>> Just because both civic and geo are included, doesn't mean >>>> one is better. For example, it is obvious that lat/lon's >>>> have measurement criteria whereas civic addresses don't, >>>> since they're either "stated" or "derived". >>>> >>>> Parcel-based GIS mapping systems exist today which describe a >>>> location in terms of both. As a simple example, Google Earth >>>> does this for you. >>>> You specify 123 Main Street, Anytown, USA and once it finds >>>> it, it also provides a lat/lon. I admit that the there are >>>> challenges with using both, but I expect that those issues >>>> will become fewer over time. >>>> >>>> Does there have to be a line in the sand as to whether a >>>> particular location is known in terms of civic vs. geo and >>>> not both? I don't think so. >>>> >>>> >>>> Roger Marshall >>>> >>>> >>>>> -----Original Message----- >>>>> From: Marc Linsner [mailto:mlinsner@cisco.com] >>>>> Sent: Monday, June 05, 2006 3:23 PM >>>>> To: 'Andrew Newton' >>>>> Cc: ecrit@ietf.org >>>>> Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivicand >>>>> geospatialinfointo the query? >>>>> >>>>> Andy, >>>>> >>>>> The problem is that the 'preferred' location is the accurate >>>> one. No >>>>> LoST server/service will be able to determine which one is most >>>>> accurate. You may equate the same problem to the client, >>>> but IMO, it's >>>>> better that the client make the decision since it's closer >>>> to the human >>>>> that 'should' know. >>>>> >>>>> -Marc- >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Andrew Newton [mailto:andy@hxr.us] >>>>>> Sent: Monday, June 05, 2006 5:58 PM >>>>>> To: Marc Linsner >>>>>> Cc: 'Hannes Tschofenig'; ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civicand >>>>>> geospatialinfointo the query? >>>>>> >>>>>> I think we'd have a protocol more capable of adapting to >>>> unforeseen, >>>>>> real world issues if both were sent and the server had the >>>>> opportunity >>>>>> to determine which type of location it preferred. I must >>>> admit that >>>>>> it seems a bit of a stretch, but I think it is just as possible >> as >>>>>> Henning's idea that the client will have the same type of >>>>> notion. It >>>>>> almost always seems to me that if ever there is a question about >>>>>> preference, it should fall to the LoST service operators and >> their >>>>>> jurisdictional considerations. >>>>>> >>>>>> It also seems to me that if a client or seeker does, in some >>>>> odd way, >>>>>> have a notion of a preferred type of location when it >>>>> possesses both, >>>>>> that it can always just send the query with only the type of >>>>> location >>>>>> it prefers. For clients that don't have this strong notion, >>>>> send both >>>>>> and see if the server has a preference. >>>>>> >>>>>> -andy >>>>>> >>>>>> >>>>>> On Jun 5, 2006, at 5:39 PM, Marc Linsner wrote: >>>>>> >>>>>>> I agree, the LoST client submits one location at a time. >>>>>> No decisions >>>>>>> made by LoST server/service. >>>>>>> >>>>>>> -Marc- >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>> Sent: Monday, June 05, 2006 5:24 PM >>>>>>>> To: Roger Marshall >>>>>>>> Cc: ecrit@ietf.org >>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify >> civicand >>>>>>>> geospatialinfointo the query? >>>>>>>> >>>>>>>> Hi Roger, >>>>>>>> >>>>>>>> Roger Marshall wrote: >>>>>>>>> Hannes: Thanks for clarifying. >>>>>>>>> >>>>>>>>> I think it's a bad idea to withold location information >>>>>>>> from the LoST >>>>>>>>> server. >>>>>>>>> >>>>>>>>> To suggest that we restrict the client, allowing only one >>>>>>>> to be sent, >>>>>>>>> sounds to me like we're placing a constraint on the >>>>>>>> PIDF-LO, saying it >>>>>>>>> can't have both (assuming LoST reuses the PIDF-LO). I >>>>>>>> don't think we >>>>>>>>> can get away with that. If the PIDF-LO has both, how is >>>>>>>> it that we can >>>>>>>>> glibly strip one out? To do so would be unreasonable. >>>>>>>> >>>>>>>> To clarify: >>>>>>>> >>>>>>>> * You can send as many queries as you want but not with >>>> the same >>>>>>>> message. Different location information => different query >>>>>>>> >>>>>>>> * We don't use a PIDF-LO in LoST. We use the raw location >> info. >>>>>>>> >>>>>>>>> >>>>>>>>> Since the client can have both civic and geo in the >>>>>> PIDF-LO, it can >>>>>>>>> also send both to the server. What am I missing? >>>>>>>> >>>>>>>> None of the proposals ever used a PIDF-LO as input; >>>> just location >>>>>>>> info. >>>>>>>> >>>>>>>>> >>>>>>>>> It's the LoST server's job to pick one, not the client's. >>>>>>>> >>>>>>>> At the PSAP and the emergency routing proxy I agree with you. >>>>>>>> >>>>>>>>> >>>>>>>>> So, the requirement I would support is as follows: >>>>>>>>> >>>>>>>>> Rx' LoST client SHALL query with either civic or geo. >>>>>>>> >>>>>>>> That's fine. >>>>>>>> >>>>>>>> >>>>>>>>> Ry' LoST client SHOULD query with *both* civic and geo. >>>>>> When LoST >>>>>>>>> server receives both civic and geo, the server SHOULD try >>>>>>>> to use the >>>>>>>>> geo first. The LoST server response SHALL indicate which >>>>>> data was >>>>>>>>> used (either geo or civic). >>>>>>>> >>>>>>>> I guess you will not support for this one based on the >>>>>> response I saw >>>>>>>> on the list so far. >>>>>>>> >>>>>>>> Ciao >>>>>>>> Hannes >>>>>>>> >>>>>>>>> >>>>>>>>> -roger. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>>> Sent: Monday, June 05, 2006 1:50 PM >>>>>>>>>> To: Roger Marshall >>>>>>>>>> Cc: Brian Rosen; ecrit@ietf.org >>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify >>>>> civic and >>>>>>>>>> geospatialinfointo the query? >>>>>>>>>> >>>>>>>>>> Hi Roger, >>>>>>>>>> >>>>>>>>>> I think the current suggestion is that the LoST client >>>>>> just picks >>>>>>>>>> whatever he wants and then uses the mapping protocol to >>>>>> trigger the >>>>>>>>>> resolution. >>>>>>>>>> >>>>>>>>>> Using geo and civic might be, from a certain point of view, >>>>>>>> just be an >>>>>>>>>> optimization. The LoST client can always trigger separate >>>>>>>> queries with >>>>>>>>>> all the location info it has. >>>>>>>>>> >>>>>>>>>> Ciao >>>>>>>>>> Hannes >>>>>>>>>> >>>>>>>>>> Roger Marshall wrote: >>>>>>>>>> >>>>>>>>>>> I don't disagree that we ask the LoST server to pick one >> and >>>>>>>>>> >>>>>>>>>> use it. >>>>>>>>>> >>>>>>>>>>> We need to be consistent though, and so therefore, I >> propose >>>>>>>>>> >>>>>>>>>> that the >>>>>>>>>> >>>>>>>>>>> LoST server always picks the geo over the civic and returns >>>>>>>>>> >>>>>>>>>> a flag in >>>>>>>>>> >>>>>>>>>>> the response stating that the geo was used to >>>> perform mapping. >>>>>>>>>>> >>>>>>>>>>> Roger. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>>>>> Sent: Monday, June 05, 2006 1:39 PM >>>>>>>>>>>> To: Brian Rosen >>>>>>>>>>>> Cc: ecrit@ietf.org >>>>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify >>>>>> civic and >>>>>>>>>>>> geospatialinfointo the query? >>>>>>>>>>>> >>>>>>>>>>>> It seems that we closed this issue. >>>>>>>>>>>> >>>>>>>>>>>> Everyone seems to be in favor for a civic OR geospatial. >>>>>>>>>>>> Extensions possible for future applications. >>>>>>>>>>>> >>>>>>>>>>>> Ciao >>>>>>>>>>>> Hannes >>>>>>>>>>>> >>>>>>>>>>>> Brian Rosen wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> I think this is the issue. There is no guidance we >>>>>> can give the >>>>>>>>>>>>> server to tell it how to resolve what to do when both >>>>>>>>>> >>>>>>>>>> locations are >>>>>>>>>> >>>>>>>>>>>>> valid but the URI for the geo does match the URI for >>>>>> the civic. >>>>>>>>>>>>> >>>>>>>>>>>>> This happens a lot when you are near boundaries because >> the >>>>>>>>>>>> >>>>>>>>>>>> precision >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> and accuracy of the two methods differ. >>>>>>>>>>>>> >>>>>>>>>>>>> I think you pick ONE and use it. >>>>>>>>>>>>> >>>>>>>>>>>>> Even if you send more than one along, the PSAP has to >> know >>>>>>>>>> >>>>>>>>>> which one >>>>>>>>>> >>>>>>>>>>>>> you used to route. It's going to continue to use that >>>>>>>>>> >>>>>>>>>> until a human >>>>>>>>>> >>>>>>>>>>>>> says otherwise. >>>>>>>>>>>>> >>>>>>>>>>>>> Brian >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>>>>>>>>>> Sent: Monday, June 05, 2006 3:55 PM >>>>>>>>>>>>> To: Andrew Newton >>>>>>>>>>>>> Cc: ecrit@ietf.org >>>>>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to >>>>>> specify civic and >>>>>>>>>>>>> geospatialinfo into the query? >>>>>>>>>>>>> >>>>>>>>>>>>> At the PSAP, we have a human that can look at this >>>>>>>> information and >>>>>>>>>>>>> make decisions (and maybe even ask if there's a >>>>>>>> discrepancy). That >>>>>>>>>>>>> seems a stretch for the LoST server. >>>>>>>>>>>>> >>>>>>>>>>>>> Andrew Newton wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> In all of these dual-information cases, I don't see >>>>>>>> how anybody >>>>>>>>>>>>>>> except the seeker can make any determination >>>> which type of >>>>>>>>>>>>>>> information is better, more accurate, more recent, etc. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Would we want the seeker to determine which information >> it >>>>>>>>>> >>>>>>>>>> feels is >>>>>>>>>> >>>>>>>>>>>>>> best to provide to the PSAP? I've always heard that the >>>>>>>>>>>> >>>>>>>>>>>> answer would be no: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> provide both to the PSAP. So why then would we not >>>>>>>>>> >>>>>>>>>> provide the same >>>>>>>>>> >>>>>>>>>>>>>> information when determining which PSAP to contact? >>>>>>>>>>>>>> >>>>>>>>>>>>>> -andy >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Ecrit mailing list >>>>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Ecrit mailing list >>>>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Ecrit mailing list >>>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Ecrit mailing list >>>>>>>> Ecrit@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >> >> --------------------------------------------------------------------- >> --------------------------- >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> --------------------------------------------------------------------- >> --------------------------- >> [mf2] >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 20:40:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPc5-0005gH-7G; Mon, 05 Jun 2006 20:40:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPc3-0005gC-Dv for ecrit@ietf.org; Mon, 05 Jun 2006 20:40:03 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPc2-0000OW-4j for ecrit@ietf.org; Mon, 05 Jun 2006 20:40:03 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 19:40:27 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 05 Jun 2006 19:40:26 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 19:40:25 -0500 Message-ID: From: "Thomson, Martin" To: "LoST Issue Tracker" , Date: Mon, 5 Jun 2006 19:40:30 -0500 Subject: RE: [Ecrit] [issue7] Adding Additional Info to LoST Response MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 06 Jun 2006 00:40:25.0684 (UTC) FILETIME=[CD2C4140:01C68901] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <1149534649.93.0.0607807562156.issue7@http://www.tschofenig.priv.at> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] [issue7] Adding Additional Info to LoST Response Thread-Index: AcaI1GFDkpx+NXWFRKWT/gHgkqwCXAALQMUg X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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="===============2097821173==" Errors-To: ecrit-bounces@ietf.org --===============2097821173== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message S2VlcCBpbiBtaW5kIHRoYXQgZm9yIG91ciBwcmltYXJ5IHVzZSBjYXNlLCB0aGlzIGluZm9ybWF0 aW9uIGlzIGFscmVhZHkga25vd24uICBJJ2QgY29uc2lkZXIgaXQgbGlrZWx5IHRoYXQgY2xpZW50 cyB3aWxsIGFsc28ga25vdyB0aGUgYW5zd2VyIGZvciBhIG90aGVyIHNlcnZpY2VzLiAgTm8gZ3Vh cmFudGVlcywgc28gaXQgY291bGQgYmUgdXNlZnVsLg0KDQpXZSBoYXZlIHRvIGJlIGNhcmVmdWwg YWJvdXQgYWRkaW5nIHRvbyBtdWNoIHRvIHRoZSBjb3JlIHByb3RvY29sLiAgTGlrZSB0aGUgbGlz dCBzZXJ2aWNlcywgSSB0aGluayB0aGF0IHRoaXMgaXMgc29tZXRoaW5nIHRoYXQgY2FuIGJlIGFk ZGVkIGxhdGVyLCBhcyBhbiBleHRlbnNpb24uDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogSGFubmVzIFRzY2hvZmVuaWcgW21haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0Bz aWVtZW5zLmNvbV0NCj4gU2VudDogVHVlc2RheSwgNiBKdW5lIDIwMDYgNToxMSBBTQ0KPiBUbzog ZWNyaXRAaWV0Zi5vcmcNCj4gU3ViamVjdDogW0Vjcml0XSBbaXNzdWU3XSBBZGRpbmcgQWRkaXRp b25hbCBJbmZvIHRvIExvU1QgUmVzcG9uc2UNCj4gDQo+IA0KPiBOZXcgc3VibWlzc2lvbiBmcm9t IEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0PjoNCj4gDQo+IEhh bm5lcyB3cm90ZToNCj4gDQo+ICogSGVubmluZyBzdWdnZXN0ZWQgdG8gZXh0ZW5kIExvU1QgdG8g cmV0dXJuIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24NCj4gcmVnYXJkaW5nDQo+IHRoZSBzZXJ2aWNl IChlLmcuLCBsb2NhdGlvbiBpbmZvcm1hdGlvbiBuZWVkZWQpLiBUaGlzIGRpc2N1c3Npb24gaXMN Cj4gcmVsZXZhbnQNCj4gZm9yIExvU1QuIEkgY2FuIHNlZSB0aGF0IHRoZXJlIHdhcyBzdXBwb3J0 IGZvciBoaXMgcHJvcG9zYWwuIFRoaXMgYXNwZWN0DQo+IGRvZXMNCj4gbm90IG5lZWQgdG8gYmUg Y2FwdHVyZWQgaW4gdGhlIHJlcXVpcmVtZW50cyBkcmFmdC4NCj4gDQo+IEhlcmUgaXMgSGVubmlu ZydzIHByb3Bvc2FsOg0KPiANCj4gIg0KPiBPbmUgcHJldHR5IHNpbXBsZSBzb2x1dGlvbiBpcyB0 byBoYXZlIGEgZm91ci12YWx1ZWQgYXR0cmlidXRlOg0KPiANCj4gLSByZXF1aXJlZCAtLT4gbm8g c2VydmljZSB3aXRob3V0IGl0OyB5b3UncmUgbGVnYWxseSBvYmxpZ2F0ZWQgdG8gIHByb3ZpZGUN Cj4gaXQNCj4gZm9yIHRoaXMgc2VydmljZQ0KPiAtIGhlbHBmdWwgIC0tPiB0aGUgcmVjZWl2ZXIg d291bGQgbGlrZSB0byBoYXZlIHRoaXMgaW5mb3JtYXRpb24sIGJ1dA0KPiBpc24ndA0KPiBnb2lu ZyB0byByZWZ1c2UgdGhlIGNhbGwgYW5kIHlvdSdyZSBub3QgbGVnYWxseSBvYmxpZ2F0ZWQ7IGlm ICB5b3Ugcm91dGUNCj4gdGhlDQo+IGNhbGwgeW91cnNlbGYsIHlvdSBkb24ndCBuZWVkIHRvIGlu Y2x1ZGUgaXQgaW4gc2lnbmFsaW5nDQo+IC0gcm91dGluZyAgLS0+IHRoZSByZWNlaXZlciBkb2Vz bid0IG5lZWQgaXQsIGJ1dCBpdCdzIHVzZWQgdG8gcm91dGUgIHRoZQ0KPiBjYWxsDQo+IC0gaWdu b3JlZCAgLS0+IHRoZSByZWNlaXZlciB3aWxsIGp1c3QgaWdub3JlIHRoZSBsb2NhdGlvbiBpbmZv cm1hdGlvbiAgYW5kDQo+IHRoZXJlJ3Mgbm8gbG9jYXRpb24tYmFzZWQgcm91dGluZw0KPiANCj4g SSBzdXNwZWN0IHRoaXMgY2FuIGJlIHNwbGl0IGludG8gdHdvIGRpbWVuc2lvbnMgKHJvdXRpbmcg YW5kIGVuZCAgc3lzdGVtKS4NCj4gIg0KPiANCj4gUXVlc3Rpb246IElzIHRoaXMgc29tZXRoaW5n IHRvIGNvbnNpZGVyPw0KPiAoUFM6IEkgbWlnaHQgaGF2ZSBtaXNzZWQgb3RoZXIsIG11Y2ggYmV0 dGVyLCBwcm9wb3NhbHMgaW4gdGhlIG1haWxpbmcgbGlzdA0KPiBkaXNjdXNzaW9uLikNCj4gDQo+ IC0tLS0tLS0tLS0NCj4gYXNzaWduZWR0bzogaGFubmVzDQo+IG1lc3NhZ2VzOiAxMA0KPiBub3N5 OiBlY3JpdCwgaGFubmVzDQo+IHByaW9yaXR5OiBjcml0aWNhbA0KPiBzdGF0dXM6IHVucmVhZA0K PiB0aXRsZTogQWRkaW5nIEFkZGl0aW9uYWwgSW5mbyB0byBMb1NUIFJlc3BvbnNlDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMb1NU IElzc3VlIFRyYWNrZXIgPGhhbm5lcy50c2Nob2ZlbmlnQHNpZW1lbnMuY29tPg0KPiA8aHR0cDov L3d3dy50c2Nob2ZlbmlnLmNvbTo4MDgwL2xvc3QvaXNzdWU3Pg0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+ IEVjcml0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2Vjcml0DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBt ZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250 YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1h dGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5h dXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ== --===============2097821173== 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 --===============2097821173==-- From ecrit-bounces@ietf.org Mon Jun 05 20:45:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPhF-0001tv-GJ; Mon, 05 Jun 2006 20:45:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPhE-0001tq-RD for ecrit@ietf.org; Mon, 05 Jun 2006 20:45:24 -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 1FnPhE-0000yh-FU for ecrit@ietf.org; Mon, 05 Jun 2006 20:45:24 -0400 Received: from [10.0.1.103] ([::ffff:68.106.115.242]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 05 Jun 2006 20:45:52 -0400 id 0158C105.4484D040.000061D7 In-Reply-To: <8C837214C95C864C9F34F3635C2A657505131429@SEA-EXCHVS-2.telecomsys.com> References: <8C837214C95C864C9F34F3635C2A657505131429@SEA-EXCHVS-2.telecomsys.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <254C8B11-5B22-4911-B234-657C6D7617A9@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfointo the query? Date: Mon, 5 Jun 2006 20:45:22 -0400 To: "Roger Marshall" X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac 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 Roger, The location information in PIDF-LO for geo is GML and the civic has its own namespace, making it really easy to pluck that information out of it. The other elements didn't seem necessary. The parts that LoST uses are an exact fragment of the PIDF-LO would be constructed and passed in the SIP message. -andy On Jun 5, 2006, at 6:23 PM, Roger Marshall wrote: > I admit that this theme is somewhat of a tangent to the subject, > but can > the authors of LoST help me understand the reasons for not using the > PIDF-LO. > > Is it the overhead? Is the PIDF-LO not adequate to convey location > some > how? > > As an example, if the PIDF-LO format is changed significantly in some > way, it will mandate a s/w change to ~10^8 clients vs. only ~10^2 - > 10^4 > server instances. > > It seems to me that as the PIDF-LO undergoes changes over time, > that the > choice between having to modify client software vs. server software > instances represents a huge difference in effort. > > > Roger Marshall > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Monday, June 05, 2006 2:24 PM >> To: Roger Marshall >> Cc: Brian Rosen; ecrit@ietf.org >> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic >> and geospatialinfointo the query? >> >> Hi Roger, >> >> Roger Marshall wrote: >>> Hannes: Thanks for clarifying. >>> >>> I think it's a bad idea to withold location information from >> the LoST >>> server. >>> >>> To suggest that we restrict the client, allowing only one to >> be sent, >>> sounds to me like we're placing a constraint on the PIDF-LO, >> saying it >>> can't have both (assuming LoST reuses the PIDF-LO). I don't >>> think we >>> can get away with that. If the PIDF-LO has both, how is it >> that we can >>> glibly strip one out? To do so would be unreasonable. >> >> To clarify: >> >> * You can send as many queries as you want but not with the >> same message. Different location information => different query >> >> * We don't use a PIDF-LO in LoST. We use the raw location info. >> >>> >>> Since the client can have both civic and geo in the PIDF-LO, it can >>> also send both to the server. What am I missing? >> >> None of the proposals ever used a PIDF-LO as input; just location >> info. >> >>> >>> It's the LoST server's job to pick one, not the client's. >> >> At the PSAP and the emergency routing proxy I agree with you. >> >>> >>> So, the requirement I would support is as follows: >>> >>> Rx' LoST client SHALL query with either civic or geo. >> >> That's fine. >> >> >>> Ry' LoST client SHOULD query with *both* civic and geo. When LoST >>> server receives both civic and geo, the server SHOULD try to use the >>> geo first. The LoST server response SHALL indicate which data was >>> used (either geo or civic). >> >> I guess you will not support for this one based on the >> response I saw on the list so far. >> >> Ciao >> Hannes >> >>> >>> -roger. >>> >>> >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Monday, June 05, 2006 1:50 PM >>>> To: Roger Marshall >>>> Cc: Brian Rosen; ecrit@ietf.org >>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >>>> geospatialinfointo the query? >>>> >>>> Hi Roger, >>>> >>>> I think the current suggestion is that the LoST client just picks >>>> whatever he wants and then uses the mapping protocol to trigger the >>>> resolution. >>>> >>>> Using geo and civic might be, from a certain point of view, >> just be an >>>> optimization. The LoST client can always trigger separate >> queries with >>>> all the location info it has. >>>> >>>> Ciao >>>> Hannes >>>> >>>> Roger Marshall wrote: >>>> >>>>> I don't disagree that we ask the LoST server to pick one and >>>> >>>> use it. >>>> >>>>> We need to be consistent though, and so therefore, I propose >>>> >>>> that the >>>> >>>>> LoST server always picks the geo over the civic and returns >>>> >>>> a flag in >>>> >>>>> the response stating that the geo was used to perform mapping. >>>>> >>>>> Roger. >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>> Sent: Monday, June 05, 2006 1:39 PM >>>>>> To: Brian Rosen >>>>>> Cc: ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >>>>>> geospatialinfointo the query? >>>>>> >>>>>> It seems that we closed this issue. >>>>>> >>>>>> Everyone seems to be in favor for a civic OR geospatial. >>>>>> Extensions possible for future applications. >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> Brian Rosen wrote: >>>>>> >>>>>> >>>>>>> I think this is the issue. There is no guidance we can give the >>>>>>> server to tell it how to resolve what to do when both >>>> >>>> locations are >>>> >>>>>>> valid but the URI for the geo does match the URI for the civic. >>>>>>> >>>>>>> This happens a lot when you are near boundaries because the >>>>>> >>>>>> precision >>>>>> >>>>>> >>>>>>> and accuracy of the two methods differ. >>>>>>> >>>>>>> I think you pick ONE and use it. >>>>>>> >>>>>>> Even if you send more than one along, the PSAP has to know >>>> >>>> which one >>>> >>>>>>> you used to route. It's going to continue to use that >>>> >>>> until a human >>>> >>>>>>> says otherwise. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>>>> Sent: Monday, June 05, 2006 3:55 PM >>>>>>> To: Andrew Newton >>>>>>> Cc: ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >>>>>>> geospatialinfo into the query? >>>>>>> >>>>>>> At the PSAP, we have a human that can look at this >> information and >>>>>>> make decisions (and maybe even ask if there's a >> discrepancy). That >>>>>>> seems a stretch for the LoST server. >>>>>>> >>>>>>> Andrew Newton wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> In all of these dual-information cases, I don't see how >>>>>>>>> anybody >>>>>>>>> except the seeker can make any determination which type of >>>>>>>>> information is better, more accurate, more recent, etc. >>>>>>>> >>>>>>>> Would we want the seeker to determine which information it >>>> >>>> feels is >>>> >>>>>>>> best to provide to the PSAP? I've always heard that the >>>>>> >>>>>> answer would be no: >>>>>> >>>>>> >>>>>>>> provide both to the PSAP. So why then would we not >>>> >>>> provide the same >>>> >>>>>>>> information when determining which PSAP to contact? >>>>>>>> >>>>>>>> -andy >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> >> > > _______________________________________________ > 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 Jun 05 20:46:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPiB-000257-S3; Mon, 05 Jun 2006 20:46:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPiA-00022S-G3 for ecrit@ietf.org; Mon, 05 Jun 2006 20:46:22 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPi9-00011Y-6d for ecrit@ietf.org; Mon, 05 Jun 2006 20:46:22 -0400 Received: from [192.168.0.41] (pool-138-89-46-232.mad.east.verizon.net [138.89.46.232]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k560kE2Q007355 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 5 Jun 2006 20:46:20 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <449B5265-5415-4913-BE74-FC7CA89CBB18@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] [issue7] Adding Additional Info to LoST Response Date: Mon, 5 Jun 2006 20:46:11 -0400 To: "Thomson, Martin" X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org We went through this before, where we discussed that these requirements may well depend on the country you happen to be asking about and are thus unlikely to be known by the client, at least not without manual configuration (which we are presumably trying to avoid). On Jun 5, 2006, at 8:40 PM, Thomson, Martin wrote: > Keep in mind that for our primary use case, this information is > already known. I'd consider it likely that clients will also know > the answer for a other services. No guarantees, so it could be > useful. > > We have to be careful about adding too much to the core protocol. > Like the list services, I think that this is something that can be > added later, as an extension. > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:hannes.tschofenig@siemens.com] >> Sent: Tuesday, 6 June 2006 5:11 AM >> To: ecrit@ietf.org >> Subject: [Ecrit] [issue7] Adding Additional Info to LoST Response >> >> >> New submission from Hannes Tschofenig : >> >> Hannes wrote: >> >> * Henning suggested to extend LoST to return additional information >> regarding >> the service (e.g., location information needed). This discussion is >> relevant >> for LoST. I can see that there was support for his proposal. This >> aspect >> does >> not need to be captured in the requirements draft. >> >> Here is Henning's proposal: >> >> " >> One pretty simple solution is to have a four-valued attribute: >> >> - required --> no service without it; you're legally obligated to >> provide >> it >> for this service >> - helpful --> the receiver would like to have this information, but >> isn't >> going to refuse the call and you're not legally obligated; if you >> route >> the >> call yourself, you don't need to include it in signaling >> - routing --> the receiver doesn't need it, but it's used to >> route the >> call >> - ignored --> the receiver will just ignore the location >> information and >> there's no location-based routing >> >> I suspect this can be split into two dimensions (routing and end >> system). >> " >> >> Question: Is this something to consider? >> (PS: I might have missed other, much better, proposals in the >> mailing list >> discussion.) >> >> ---------- >> assignedto: hannes >> messages: 10 >> nosy: ecrit, hannes >> priority: critical >> status: unread >> title: Adding Additional Info to LoST Response >> >> __________________________________________________ >> LoST Issue Tracker >> >> __________________________________________________ >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > ---------------------------------------------------------------------- > -------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ---------------------------------------------------------------------- > -------------------------- > [mf2]_______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 20:49:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPlQ-00058d-0Q; Mon, 05 Jun 2006 20:49:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPlO-00058Y-Ph for ecrit@ietf.org; Mon, 05 Jun 2006 20:49:42 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPlO-0001de-3d for ecrit@ietf.org; Mon, 05 Jun 2006 20:49:42 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 19:50:07 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 05 Jun 2006 19:50:06 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 19:50:06 -0500 Message-ID: From: "Thomson, Martin" To: "Andrew Newton" , "Henning Schulzrinne" Date: Mon, 5 Jun 2006 19:48:33 -0500 Subject: RE: [Ecrit] [issue2] Is it allowedtospecifycivicand geospatialinfointo the query? MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 06 Jun 2006 00:50:06.0118 (UTC) FILETIME=[27237460:01C68903] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: Content-class: urn:content-classes:message Thread-Topic: [Ecrit] [issue2] Is it allowedtospecifycivicand geospatialinfointo the query? Thread-Index: AcaJAZsI2JZ7TdzgTUKBSQezMURl/wAAGSdQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1931813562==" Errors-To: ecrit-bounces@ietf.org --===============1931813562== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message U291bmRzIGxpa2UgZ29vZCByZWFzb25pbmcgdG8gbWUuDQoNCkRvIHdlIHN0aWxsIGhhdmUgYSB3 YXkgZm9yIHRoZSBMb1NUIHNlcnZlciB0byBpbmRpY2F0ZSB3aGF0IGxvY2F0aW9uIGluZm9ybWF0 aW9uIGl0IHVzZWQgaW4gaXRzIGRlY2lzaW9uPyAgVGhhdCBpcyBjZXJ0YWlubHkgdXNlZnVsIGlu IHRoaXMgY2FzZS4gIFRoZSBMb1NUIHNlcnZlciBjYW4ganVzdCB0aHJvdyBvdXQgdGhlIHBpZWNl cyBpdCBkb2Vzbid0IHdhbnQuDQoNCkFsdGhvdWdoLCBJIGV4cGVjdCB0aGF0IHdlIGFyZSByZWx5 aW5nIG9uIGNsaWVudCBpbXBsZW1lbnRhdGlvbnMgdG8gbWFrZSB0aGUgZGVjaXNpb24sIG5vdCBw ZW9wbGUuICBJJ2QgcmF0aGVyIGhhdmUgdGhlIExvU1Qgc2VydmVyIG1ha2UgdGhhdCBkZXRlcm1p bmF0aW9uLCB3aXRoIGFsbCB0aGUgaW5mb3JtYXRpb24gYXZhaWxhYmxlLCByYXRoZXIgdGhhbiBy aXNrIG1pc3Npbmcgb3V0IHZpdGFsIGluZm9ybWF0aW9uLg0KDQpFdmVuIHdoZXJlIHRoZSBjbGll bnQgaXMgYWJsZSB0byBtYWtlIGEgZGV0ZXJtaW5hdGlvbiwgdGhpcyBtaWdodCBzdGlsbCBmYWls IGR1ZSB0byBsaW1pdGF0aW9ucyBvbiBlaXRoZXIgc2lkZS4gIEZvciBpbnN0YW5jZSwgdGhlIExv U1Qgc2VydmVyIG1pZ2h0IHVzZSBnZW9kZXRpYyBpbmZvcm1hdGlvbiBvbmx5LCBhbmQgdXNlcyBh IGdlb2NvZGVyIHRvIGdldCBnZW9kZXRpYyBpbmZvcm1hdGlvbi4gIEhvd2V2ZXIsIGl0IG1heSBi ZSB1bmFibGUgdG8gZ2VvY29kZSBhIGNpdmljIGFkZHJlc3MgZG93biB0byB0aGUgbW9zdCBwcmVj aXNlIGZpZWxkcyAtLSBpdCBjYW4gb25seSBnZW9jb2RlIGRvd24gdG8gYSBzdHJlZXQuICBJZiB0 aGUgY2xpZW50IHRocmV3IG91dCBnZW9kZXRpYyBiZWNhdXNlIGNpdmljIHdhcyBkb3duIHRvIHJv b20gYW5kIGdlb2RldGljIHdhcyArLy0gMjAwbSwgdGhlbiB5b3UgaGF2ZSBsb3N0IGluZm9ybWF0 aW9uIHRoYXQgbWlnaHQgaGF2ZSBiZWVuIG1vcmUgdXNlZnVsIHRvIHRoZSBMb1NUIHNlcnZlci4N Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbmRyZXcgTmV3dG9uIFtt YWlsdG86YW5keUBoeHIudXNdDQo+IFNlbnQ6IFR1ZXNkYXksIDYgSnVuZSAyMDA2IDEwOjM5IEFN DQo+IFRvOiBIZW5uaW5nIFNjaHVsenJpbm5lDQo+IENjOiBlY3JpdEBpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogW0Vjcml0XSBbaXNzdWUyXSBJcyBpdCBhbGxvd2VkdG9zcGVjaWZ5Y2l2aWNhbmQN Cj4gZ2Vvc3BhdGlhbGluZm9pbnRvIHRoZSBxdWVyeT8NCj4gDQo+IEl0J3MgYW4gZXh0cmEgb3V0 ZXIgbG9vcCwgYW5kIG9ubHkgbW9yZSBjb21wbGV4IGlmIHlvdSBoYXZlIHNvbWVib2R5DQo+IHRy eWluZyB0byBtYWtlIGl0IHRoYXQgd2F5LiAgT3RoZXJ3aXNlLCBpdCBpcyBleGFjdGx5IHRoZSBz YW1lIGFtb3VudA0KPiBvZiB3b3JrLg0KPiANCj4gQXMgdG8gdGhlIHBvaW50IHRoYXQgYSBodW1h biwgaW4gYW4gZW1lcmdlbmN5IHNpdHVhdGlvbiwgYXQgdGhlDQo+IHNlZWtlciBpcyBpbiBhIGJl dHRlciBwb3NpdGlvbiB0byBtYWtlIHRoZSBjb3JyZWN0IGp1ZGdlbWVudCwgSQ0KPiBkaXNwdXRl IHRoYXQuICBNb3N0IHBlb3BsZSB3aWxsIGxvb2sgYXQgbGF0L2xvbmcgY29vcmRpbmF0ZXMgYW5k IG5vdA0KPiBoYXZlIHRoZSBmYWludGVzdCBjbHVlIGhvdyBhY2N1cmF0ZSB0aGV5IGFyZS4gIElm IHlvdSBwbHVuayBtZSBkb3duDQo+IGluIHRoZSBtaWRkbGUgb2YgVG9reW8sIEknZCBoYXZlIHRv IGRvIGEgY29pbiB0b3NzIHRvIHRlbGwgeW91IHdoaWNoDQo+IGlzIG1vcmUgYWNjdXJhdGUsIGNp dmljIG9yIGdlby4gIEFuZCB3aGF0IGFib3V0IGNhc2VzIHdlcmUgdGhlIHNlZWtlcg0KPiBpcyBh IGdhdGV3YXk/DQo+IA0KPiBUbyBiZSBob25lc3QsIHdoZXRoZXIgdGhlIHNlcnZlciB3b3VsZCBr bm93IGJldHRlciBvciB0aGUgY2xpZW50DQo+IHdvdWxkIGtub3cgYmV0dGVyIGlzIHNvbWV0aGlu ZyBJIHRoaW5rIG5vbmUgb2YgdXMgY2FuIGFuc3dlciB3aXRoDQo+IGNlcnRhaW50eSBhdCB0aGUg bW9tZW50LiAgSSB3b3VsZCBqdXN0IHJhdGhlciBub3QgY3JlYXRlIGEgcHJvdG9jb2wNCj4gdGhh dCBwcmVjbHVkZXMgb25lIG9yIHRoZSBvdGhlci4NCj4gDQo+IC1hbmR5DQo+IA0KPiBPbiBKdW4g NSwgMjAwNiwgYXQgODoxMSBQTSwgSGVubmluZyBTY2h1bHpyaW5uZSB3cm90ZToNCj4gDQo+ID4g WWVzLCB5b3UgY291bGQgZG8gdGhhdCwgYnV0IHlvdSBub3cgaGF2ZSB0byBjYXJyeSBwb3NzaWJs eSB0d28NCj4gPiBlcnJvciBpbmRpY2F0aW9ucywgaGF2ZSB0byB3b3JyeSBhYm91dCBjYXJyeWlu ZyB0d28gYm91bmRhcmllcywNCj4gPiBldGMuIEp1c3QgbWFkZSB0aGUgcHJvdG9jb2wgbXVjaCBt ZXNzaWVyLCBmb3IgYm90aCBjbGllbnQgYW5kDQo+ID4gc2VydmVyLiBJdCBnZXRzIHdvcnNlOiBp biBhbGwgbGlrZWxpaG9vZCwgdGhlIHNlcnZlciBoYXMgdG8gcmVjdXJzZQ0KPiA+IG9yIGl0ZXJh dGUgZGlmZmVyZW50bHkgZm9yIGNpdmljIGFuZCBnZW8gY29vcmRpbmF0ZXMsIHNvIHRoZSBzZXJ2 ZXINCj4gPiBoYXMgdG8gd2FpdCB1bnRpbCBib3RoIHJlc3VsdHMgYXJlIGluIGZyb20gdXBzdHJl YW0gc2VydmVycyAob3INCj4gPiByZXR1cm4ganVzdCBvbmUgcmVzdWx0IGFmdGVyIGEgdGltZW91 dCkuIFRoaXMgYWxsIGp1c3Qgc2VlbXMNCj4gPiBwb2ludGxlc3NseSBjb21wbGV4LCBnaXZlbiB0 aGF0IHRoZSBzYW1lIHJlc3VsdCBjYW4gYmUgdHJpdmlhbGx5DQo+ID4gYWNoaWV2ZWQgYnkgc3Bs aXR0aW5nIHRoZSBxdWVyeS4NCj4gPg0KPiA+IE9uIEp1biA1LCAyMDA2LCBhdCA4OjA0IFBNLCBX aW50ZXJib3R0b20sIEphbWVzIHdyb3RlOg0KPiA+DQo+ID4+IFdoeSB3b3VsZG4ndCB0aGUgTG9T dCBzZXJ2ZXIgc2ltcGx5IHRyZWF0IGVhY2ggcmVwcmVzZW50YXRpb24gb24NCj4gPj4gaXRzIG93 bg0KPiA+PiBtZXJpdHM/IFlvdSBnaXZlIG1lIHR3byBsb2NhdGlvbnMgeW91IGdldCBiYWNrIDIg VVJJcywgZXZlbiBpZg0KPiA+PiB0aGV5IGFyZQ0KPiA+PiB0aGUgc2FtZS4NCj4gPj4NCj4gPj4N Cj4gPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+PiBGcm9tOiBNYXJjIExpbnNu ZXIgW21haWx0bzptbGluc25lckBjaXNjby5jb21dDQo+ID4+PiBTZW50OiBUdWVzZGF5LCA2IEp1 bmUgMjAwNiA5OjQ0IEFNDQo+ID4+PiBUbzogJ1JvZ2VyIE1hcnNoYWxsJzsgJ0FuZHJldyBOZXd0 b24nDQo+ID4+PiBDYzogZWNyaXRAaWV0Zi5vcmcNCj4gPj4+IFN1YmplY3Q6IFJFOiBbRWNyaXRd IFtpc3N1ZTJdIElzIGl0IGFsbG93ZWQgdG9zcGVjaWZ5Y2l2aWNhbmQNCj4gPj4+IGdlb3NwYXRp YWxpbmZvaW50byB0aGUgcXVlcnk/DQo+ID4+Pg0KPiA+Pj4gUm9nZXIsDQo+ID4+Pg0KPiA+Pj4g SSdtIG5vdCBhcmd1aW5nIGdlbyB2cy4gY2l2aWwuICBBbGwgSSBhbSB0cnlpbmcgdG8gc3RhdGUg aXMgd2hlbg0KPiA+PiBtdWx0aXBsZQ0KPiA+Pj4gbG9jYXRpb24gcmVwcmVzZW50YXRpb25zIGFy ZSBrbm93biBmb3IgYSBMb1NUIGNsaWVudCwgdGhlIExvU1QNCj4gPj4+IHNlcnZlci9zZXJ2aWNl IHNob3VsZCBub3QgYmUgdGhlIG9uZSB0byBkZXRlcm1pbmUgd2hpY2gNCj4gPj4+IHJlcHJlc2Vu dGF0aW9uDQo+ID4+IGlzDQo+ID4+PiBiZXN0Lg0KPiA+Pj4NCj4gPj4+IFNldHVwIGZvciBmYWls dXJlIGV4YW1wbGUgIzE6IEEgc2luZ2xlIExvU1QgcXVlcnkgY29udGFpbnMgYm90aCBhDQo+ID4+ IGNpdmljDQo+ID4+PiAoMTIzDQo+ID4+PiBNYWluIFN0LikgYW5kIGEgZ2VvIHJlcHJlc2VudGF0 aW9uLiAgQWxsIGdlb2NvZGUgZGF0YWJhc2VzIHJldHVybg0KPiA+Pj4gNDU2DQo+ID4+PiBTZWNv bmQNCj4gPj4+IFN0LiBmb3IgdGhlIGdlby4gIFdoaWNoIG9uZSBzaG91bGQgTG9TVCBwcmVmZXI/ DQo+ID4+Pg0KPiA+Pj4gU2V0dXAgZm9yIGZhaWx1cmUgZXhhbXBsZSAjMjogQSBzaW5nbGUgTG9T VCBxdWVyeSBjb250YWlucyB0d28gY2l2aWMNCj4gPj4+IHJlcHJlc2VudGF0aW9ucy4gIE9uZSBp cyBpbiBOZXcgWW9yayBDaXR5IGFuZCB0aGUgb3RoZXIgaW4gU2VhdHRsZS4NCj4gPj4gV2hpY2gN Cj4gPj4+IG9uZSBzaG91bGQgTG9TVCBwcmVmZXI/DQo+ID4+Pg0KPiA+Pj4gSU1PLCBlYWNoIGV4 YW1wbGUgc2hvdWxkIGJlICgyKSB1bmlxdWUgcXVlcmllcywgb25lIGZvciBlYWNoDQo+ID4+PiBy ZXByZXNlbnRhdGlvbiwNCj4gPj4+IGFuZCBsZXQgdGhlIGNsaWVudCBkZWFsIHdpdGggaXQuICBU aGlzIGRlY2lzaW9uIG5lZWRzIHRvIGJlIG1hZGUgYXMNCj4gPj4gY2xvc2UNCj4gPj4+IHRvDQo+ ID4+PiBhIGh1bWFuIGFzIHBvc3NpYmxlLCBJIGRvbid0IGZvcmVzZWUgYW55IHByb2dyYW1tYXRp YyBzb2x1dGlvbi4gIElmDQo+ID4+IHRoZQ0KPiA+Pj4gY2xpZW50IGhvbGRzICgyKSBsb2NhdGlv biByZXByZXNlbnRhdGlvbnMsIHRoZSBwcm9ibGVtIGlzIHRoZWlycyBhbmQNCj4gPj4gbmVlZHMN Cj4gPj4+IHRvIGJlIHJlc29sdmVkIHRoZXJlLiAgT25jZSBhIFBTQVAgY2FsbCB0YWtlciAoYSBz ZWNvbmQgaHVtYW4pIGlzDQo+ID4+PiBpbnZvbHZlZCwNCj4gPj4+IHRoZW4gdGhlIHR3byBodW1h bnMgY2FuIG5lZ290aWF0ZSB0aGUgaXNzdWUuDQo+ID4+Pg0KPiA+Pj4gVG9vIG1hbnkgdmFyaWFi bGVzIHRvIHN0YW5kYXJkaXplIGEgc29sdXRpb24uDQo+ID4+Pg0KPiA+Pj4gLU1hcmMtDQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4+DQo+ID4+Pj4gTWFyYzoNCj4gPj4+PiBXaGF0 IGlzIHRoZSBzY2FsZSBvZiAiYWNjdXJhY3kiIGZvciBhIGNpdmljIHN0cmVldCBhZGRyZXNzPw0K PiA+PiAwJSwxMDAlPw0KPiA+Pj4+DQo+ID4+Pj4gSnVzdCBiZWNhdXNlIGJvdGggY2l2aWMgYW5k IGdlbyBhcmUgaW5jbHVkZWQsIGRvZXNuJ3QgbWVhbg0KPiA+Pj4+IG9uZSBpcyBiZXR0ZXIuICBG b3IgZXhhbXBsZSwgaXQgaXMgIG9idmlvdXMgdGhhdCBsYXQvbG9uJ3MNCj4gPj4+PiBoYXZlIG1l YXN1cmVtZW50IGNyaXRlcmlhIHdoZXJlYXMgY2l2aWMgYWRkcmVzc2VzIGRvbid0LA0KPiA+Pj4+ IHNpbmNlIHRoZXkncmUgZWl0aGVyICJzdGF0ZWQiIG9yICJkZXJpdmVkIi4NCj4gPj4+Pg0KPiA+ Pj4+IFBhcmNlbC1iYXNlZCBHSVMgbWFwcGluZyBzeXN0ZW1zIGV4aXN0IHRvZGF5IHdoaWNoIGRl c2NyaWJlIGENCj4gPj4+PiBsb2NhdGlvbiBpbiB0ZXJtcyBvZiBib3RoLiAgQXMgYSBzaW1wbGUg ZXhhbXBsZSwgR29vZ2xlIEVhcnRoDQo+ID4+Pj4gZG9lcyB0aGlzIGZvciB5b3UuDQo+ID4+Pj4g WW91IHNwZWNpZnkgMTIzIE1haW4gU3RyZWV0LCBBbnl0b3duLCBVU0EgYW5kIG9uY2UgaXQgZmlu ZHMNCj4gPj4+PiBpdCwgaXQgYWxzbyBwcm92aWRlcyBhIGxhdC9sb24uICBJIGFkbWl0IHRoYXQg dGhlIHRoZXJlIGFyZQ0KPiA+Pj4+IGNoYWxsZW5nZXMgd2l0aCB1c2luZyBib3RoLCBidXQgSSBl eHBlY3QgdGhhdCB0aG9zZSBpc3N1ZXMNCj4gPj4+PiB3aWxsIGJlY29tZSBmZXdlciBvdmVyIHRp bWUuDQo+ID4+Pj4NCj4gPj4+PiBEb2VzIHRoZXJlIGhhdmUgdG8gYmUgYSBsaW5lIGluIHRoZSBz YW5kIGFzIHRvIHdoZXRoZXIgYQ0KPiA+Pj4+IHBhcnRpY3VsYXIgbG9jYXRpb24gaXMga25vd24g aW4gdGVybXMgb2YgY2l2aWMgdnMuIGdlbyBhbmQNCj4gPj4+PiBub3QgYm90aD8gIEkgZG9uJ3Qg dGhpbmsgc28uDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+IFJvZ2VyIE1hcnNoYWxsDQo+ID4+Pj4N Cj4gPj4+Pg0KPiA+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+PiBGcm9t OiBNYXJjIExpbnNuZXIgW21haWx0bzptbGluc25lckBjaXNjby5jb21dDQo+ID4+Pj4+IFNlbnQ6 IE1vbmRheSwgSnVuZSAwNSwgMjAwNiAzOjIzIFBNDQo+ID4+Pj4+IFRvOiAnQW5kcmV3IE5ld3Rv bicNCj4gPj4+Pj4gQ2M6IGVjcml0QGlldGYub3JnDQo+ID4+Pj4+IFN1YmplY3Q6IFJFOiBbRWNy aXRdIFtpc3N1ZTJdIElzIGl0IGFsbG93ZWQgdG8gc3BlY2lmeWNpdmljYW5kDQo+ID4+Pj4+IGdl b3NwYXRpYWxpbmZvaW50byB0aGUgcXVlcnk/DQo+ID4+Pj4+DQo+ID4+Pj4+IEFuZHksDQo+ID4+ Pj4+DQo+ID4+Pj4+IFRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlICdwcmVmZXJyZWQnIGxvY2F0aW9u IGlzIHRoZSBhY2N1cmF0ZQ0KPiA+Pj4+IG9uZS4gIE5vDQo+ID4+Pj4+IExvU1Qgc2VydmVyL3Nl cnZpY2Ugd2lsbCBiZSBhYmxlIHRvIGRldGVybWluZSB3aGljaCBvbmUgaXMgbW9zdA0KPiA+Pj4+ PiBhY2N1cmF0ZS4gIFlvdSBtYXkgZXF1YXRlIHRoZSBzYW1lIHByb2JsZW0gdG8gdGhlIGNsaWVu dCwNCj4gPj4+PiBidXQgSU1PLCBpdCdzDQo+ID4+Pj4+IGJldHRlciB0aGF0IHRoZSBjbGllbnQg bWFrZSB0aGUgZGVjaXNpb24gc2luY2UgaXQncyBjbG9zZXINCj4gPj4+PiB0byB0aGUgaHVtYW4N Cj4gPj4+Pj4gdGhhdCAnc2hvdWxkJyBrbm93Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiAtTWFyYy0NCj4g Pj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4+Pj4+PiBGcm9tOiBBbmRyZXcgTmV3dG9uIFttYWlsdG86YW5keUBoeHIudXNdDQo+ ID4+Pj4+PiBTZW50OiBNb25kYXksIEp1bmUgMDUsIDIwMDYgNTo1OCBQTQ0KPiA+Pj4+Pj4gVG86 IE1hcmMgTGluc25lcg0KPiA+Pj4+Pj4gQ2M6ICdIYW5uZXMgVHNjaG9mZW5pZyc7IGVjcml0QGll dGYub3JnDQo+ID4+Pj4+PiBTdWJqZWN0OiBSZTogW0Vjcml0XSBbaXNzdWUyXSBJcyBpdCBhbGxv d2VkIHRvIHNwZWNpZnkgY2l2aWNhbmQNCj4gPj4+Pj4+IGdlb3NwYXRpYWxpbmZvaW50byB0aGUg cXVlcnk/DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSSB0aGluayB3ZSdkIGhhdmUgYSBwcm90b2NvbCBt b3JlIGNhcGFibGUgb2YgYWRhcHRpbmcgdG8NCj4gPj4+PiB1bmZvcmVzZWVuLA0KPiA+Pj4+Pj4g cmVhbCB3b3JsZCBpc3N1ZXMgaWYgYm90aCB3ZXJlIHNlbnQgYW5kIHRoZSBzZXJ2ZXIgaGFkIHRo ZQ0KPiA+Pj4+PiBvcHBvcnR1bml0eQ0KPiA+Pj4+Pj4gdG8gZGV0ZXJtaW5lIHdoaWNoIHR5cGUg b2YgbG9jYXRpb24gaXQgcHJlZmVycmVkLiAgSSBtdXN0DQo+ID4+Pj4gYWRtaXQgdGhhdA0KPiA+ Pj4+Pj4gaXQgc2VlbXMgYSBiaXQgb2YgYSBzdHJldGNoLCBidXQgSSB0aGluayBpdCBpcyBqdXN0 IGFzIHBvc3NpYmxlDQo+ID4+IGFzDQo+ID4+Pj4+PiBIZW5uaW5nJ3MgaWRlYSB0aGF0IHRoZSBj bGllbnQgd2lsbCBoYXZlIHRoZSBzYW1lIHR5cGUgb2YNCj4gPj4+Pj4gbm90aW9uLiAgSXQNCj4g Pj4+Pj4+IGFsbW9zdCBhbHdheXMgc2VlbXMgdG8gbWUgdGhhdCBpZiBldmVyIHRoZXJlIGlzIGEg cXVlc3Rpb24gYWJvdXQNCj4gPj4+Pj4+IHByZWZlcmVuY2UsIGl0IHNob3VsZCBmYWxsIHRvIHRo ZSBMb1NUIHNlcnZpY2Ugb3BlcmF0b3JzIGFuZA0KPiA+PiB0aGVpcg0KPiA+Pj4+Pj4ganVyaXNk aWN0aW9uYWwgY29uc2lkZXJhdGlvbnMuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSXQgYWxzbyBzZWVt cyB0byBtZSB0aGF0IGlmIGEgY2xpZW50IG9yIHNlZWtlciBkb2VzLCBpbiBzb21lDQo+ID4+Pj4+ IG9kZCB3YXksDQo+ID4+Pj4+PiBoYXZlIGEgbm90aW9uIG9mIGEgcHJlZmVycmVkIHR5cGUgb2Yg bG9jYXRpb24gd2hlbiBpdA0KPiA+Pj4+PiBwb3NzZXNzZXMgYm90aCwNCj4gPj4+Pj4+IHRoYXQg aXQgY2FuIGFsd2F5cyBqdXN0IHNlbmQgdGhlIHF1ZXJ5IHdpdGggb25seSB0aGUgdHlwZSBvZg0K PiA+Pj4+PiBsb2NhdGlvbg0KPiA+Pj4+Pj4gaXQgcHJlZmVycy4gIEZvciBjbGllbnRzIHRoYXQg ZG9uJ3QgaGF2ZSB0aGlzIHN0cm9uZyBub3Rpb24sDQo+ID4+Pj4+IHNlbmQgYm90aA0KPiA+Pj4+ Pj4gYW5kIHNlZSBpZiB0aGUgc2VydmVyIGhhcyBhIHByZWZlcmVuY2UuDQo+ID4+Pj4+Pg0KPiA+ Pj4+Pj4gLWFuZHkNCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gT24gSnVuIDUsIDIwMDYs IGF0IDU6MzkgUE0sIE1hcmMgTGluc25lciB3cm90ZToNCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4gSSBh Z3JlZSwgdGhlIExvU1QgY2xpZW50IHN1Ym1pdHMgb25lIGxvY2F0aW9uIGF0IGEgdGltZS4NCj4g Pj4+Pj4+IE5vIGRlY2lzaW9ucw0KPiA+Pj4+Pj4+IG1hZGUgYnkgTG9TVCBzZXJ2ZXIvc2Vydmlj ZS4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IC1NYXJjLQ0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4+Pj4+IEZyb206IEhhbm5lcyBUc2Nob2Zl bmlnIFttYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldF0NCj4gPj4+Pj4+Pj4gU2VudDog TW9uZGF5LCBKdW5lIDA1LCAyMDA2IDU6MjQgUE0NCj4gPj4+Pj4+Pj4gVG86IFJvZ2VyIE1hcnNo YWxsDQo+ID4+Pj4+Pj4+IENjOiBlY3JpdEBpZXRmLm9yZw0KPiA+Pj4+Pj4+PiBTdWJqZWN0OiBS ZTogW0Vjcml0XSBbaXNzdWUyXSBJcyBpdCBhbGxvd2VkIHRvIHNwZWNpZnkNCj4gPj4gY2l2aWNh bmQNCj4gPj4+Pj4+Pj4gZ2Vvc3BhdGlhbGluZm9pbnRvIHRoZSBxdWVyeT8NCj4gPj4+Pj4+Pj4N Cj4gPj4+Pj4+Pj4gSGkgUm9nZXIsDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IFJvZ2VyIE1hcnNo YWxsIHdyb3RlOg0KPiA+Pj4+Pj4+Pj4gSGFubmVzOiBUaGFua3MgZm9yIGNsYXJpZnlpbmcuDQo+ ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gSSB0aGluayBpdCdzIGEgYmFkIGlkZWEgdG8gd2l0aG9s ZCBsb2NhdGlvbiBpbmZvcm1hdGlvbg0KPiA+Pj4+Pj4+PiBmcm9tIHRoZSBMb1NUDQo+ID4+Pj4+ Pj4+PiBzZXJ2ZXIuDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gVG8gc3VnZ2VzdCB0aGF0IHdl IHJlc3RyaWN0IHRoZSBjbGllbnQsIGFsbG93aW5nIG9ubHkgb25lDQo+ID4+Pj4+Pj4+IHRvIGJl IHNlbnQsDQo+ID4+Pj4+Pj4+PiBzb3VuZHMgdG8gbWUgbGlrZSB3ZSdyZSBwbGFjaW5nIGEgY29u c3RyYWludCBvbiB0aGUNCj4gPj4+Pj4+Pj4gUElERi1MTywgc2F5aW5nIGl0DQo+ID4+Pj4+Pj4+ PiBjYW4ndCBoYXZlIGJvdGggKGFzc3VtaW5nIExvU1QgcmV1c2VzIHRoZSBQSURGLUxPKS4gIEkN Cj4gPj4+Pj4+Pj4gZG9uJ3QgdGhpbmsgd2UNCj4gPj4+Pj4+Pj4+IGNhbiBnZXQgYXdheSB3aXRo IHRoYXQuICAgSWYgdGhlIFBJREYtTE8gaGFzIGJvdGgsIGhvdyBpcw0KPiA+Pj4+Pj4+PiBpdCB0 aGF0IHdlIGNhbg0KPiA+Pj4+Pj4+Pj4gZ2xpYmx5IHN0cmlwIG9uZSBvdXQ/ICBUbyBkbyBzbyB3 b3VsZCBiZSB1bnJlYXNvbmFibGUuDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IFRvIGNsYXJpZnk6 DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ICogWW91IGNhbiBzZW5kIGFzIG1hbnkgcXVlcmllcyBh cyB5b3Ugd2FudCBidXQgbm90IHdpdGgNCj4gPj4+PiB0aGUgc2FtZQ0KPiA+Pj4+Pj4+PiBtZXNz YWdlLiBEaWZmZXJlbnQgbG9jYXRpb24gaW5mb3JtYXRpb24gPT4gZGlmZmVyZW50IHF1ZXJ5DQo+ ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ICogV2UgZG9uJ3QgdXNlIGEgUElERi1MTyBpbiBMb1NULiBX ZSB1c2UgdGhlIHJhdyBsb2NhdGlvbg0KPiA+PiBpbmZvLg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+ Pj4NCj4gPj4+Pj4+Pj4+IFNpbmNlIHRoZSBjbGllbnQgY2FuIGhhdmUgYm90aCBjaXZpYyBhbmQg Z2VvIGluIHRoZQ0KPiA+Pj4+Pj4gUElERi1MTywgaXQgY2FuDQo+ID4+Pj4+Pj4+PiBhbHNvIHNl bmQgYm90aCB0byB0aGUgc2VydmVyLiAgV2hhdCBhbSBJIG1pc3Npbmc/DQo+ID4+Pj4+Pj4+DQo+ ID4+Pj4+Pj4+IE5vbmUgb2YgdGhlIHByb3Bvc2FscyBldmVyIHVzZWQgYSBQSURGLUxPIGFzIGlu cHV0Ow0KPiA+Pj4+IGp1c3QgbG9jYXRpb24NCj4gPj4+Pj4+Pj4gaW5mby4NCj4gPj4+Pj4+Pj4N Cj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBJdCdzIHRoZSBMb1NUIHNlcnZlcidzIGpvYiB0byBw aWNrIG9uZSwgbm90IHRoZSBjbGllbnQncy4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gQXQgdGhl IFBTQVAgYW5kIHRoZSBlbWVyZ2VuY3kgcm91dGluZyBwcm94eSBJIGFncmVlIHdpdGggeW91Lg0K PiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IFNvLCB0aGUgcmVxdWlyZW1lbnQg SSB3b3VsZCBzdXBwb3J0IGlzIGFzIGZvbGxvd3M6DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4g UngnIExvU1QgY2xpZW50IFNIQUxMIHF1ZXJ5IHdpdGggZWl0aGVyIGNpdmljIG9yIGdlby4NCj4g Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gVGhhdCdzIGZpbmUuDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ DQo+ID4+Pj4+Pj4+PiBSeScgTG9TVCBjbGllbnQgU0hPVUxEIHF1ZXJ5IHdpdGggKmJvdGgqIGNp dmljIGFuZCBnZW8uDQo+ID4+Pj4+PiBXaGVuIExvU1QNCj4gPj4+Pj4+Pj4+IHNlcnZlciByZWNl aXZlcyBib3RoIGNpdmljIGFuZCBnZW8sIHRoZSBzZXJ2ZXIgU0hPVUxEIHRyeQ0KPiA+Pj4+Pj4+ PiB0byB1c2UgdGhlDQo+ID4+Pj4+Pj4+PiBnZW8gZmlyc3QuICBUaGUgTG9TVCBzZXJ2ZXIgcmVz cG9uc2UgU0hBTEwgaW5kaWNhdGUgd2hpY2gNCj4gPj4+Pj4+IGRhdGEgd2FzDQo+ID4+Pj4+Pj4+ PiB1c2VkIChlaXRoZXIgZ2VvIG9yIGNpdmljKS4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gSSBn dWVzcyB5b3Ugd2lsbCBub3Qgc3VwcG9ydCBmb3IgdGhpcyBvbmUgYmFzZWQgb24gdGhlDQo+ID4+ Pj4+PiByZXNwb25zZSBJIHNhdw0KPiA+Pj4+Pj4+PiBvbiB0aGUgbGlzdCBzbyBmYXIuDQo+ID4+ Pj4+Pj4+DQo+ID4+Pj4+Pj4+IENpYW8NCj4gPj4+Pj4+Pj4gSGFubmVzDQo+ID4+Pj4+Pj4+DQo+ ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gLXJvZ2VyLg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+ DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4+Pj4+Pj4+Pj4gRnJvbTogSGFubmVzIFRzY2hvZmVuaWcgW21haWx0bzpIYW5uZXMuVHNjaG9m ZW5pZ0BnbXgubmV0XQ0KPiA+Pj4+Pj4+Pj4+IFNlbnQ6IE1vbmRheSwgSnVuZSAwNSwgMjAwNiAx OjUwIFBNDQo+ID4+Pj4+Pj4+Pj4gVG86IFJvZ2VyIE1hcnNoYWxsDQo+ID4+Pj4+Pj4+Pj4gQ2M6 IEJyaWFuIFJvc2VuOyBlY3JpdEBpZXRmLm9yZw0KPiA+Pj4+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBb RWNyaXRdIFtpc3N1ZTJdIElzIGl0IGFsbG93ZWQgdG8gc3BlY2lmeQ0KPiA+Pj4+PiBjaXZpYyBh bmQNCj4gPj4+Pj4+Pj4+PiBnZW9zcGF0aWFsaW5mb2ludG8gdGhlIHF1ZXJ5Pw0KPiA+Pj4+Pj4+ Pj4+DQo+ID4+Pj4+Pj4+Pj4gSGkgUm9nZXIsDQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBJ IHRoaW5rIHRoZSBjdXJyZW50IHN1Z2dlc3Rpb24gaXMgdGhhdCB0aGUgTG9TVCBjbGllbnQNCj4g Pj4+Pj4+IGp1c3QgcGlja3MNCj4gPj4+Pj4+Pj4+PiB3aGF0ZXZlciBoZSB3YW50cyBhbmQgdGhl biB1c2VzIHRoZSBtYXBwaW5nIHByb3RvY29sIHRvDQo+ID4+Pj4+PiB0cmlnZ2VyIHRoZQ0KPiA+ Pj4+Pj4+Pj4+IHJlc29sdXRpb24uDQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBVc2luZyBn ZW8gYW5kIGNpdmljIG1pZ2h0IGJlLCBmcm9tIGEgY2VydGFpbiBwb2ludCBvZiB2aWV3LA0KPiA+ Pj4+Pj4+PiBqdXN0IGJlIGFuDQo+ID4+Pj4+Pj4+Pj4gb3B0aW1pemF0aW9uLiBUaGUgTG9TVCBj bGllbnQgY2FuIGFsd2F5cyB0cmlnZ2VyIHNlcGFyYXRlDQo+ID4+Pj4+Pj4+IHF1ZXJpZXMgd2l0 aA0KPiA+Pj4+Pj4+Pj4+IGFsbCB0aGUgbG9jYXRpb24gaW5mbyBpdCBoYXMuDQo+ID4+Pj4+Pj4+ Pj4NCj4gPj4+Pj4+Pj4+PiBDaWFvDQo+ID4+Pj4+Pj4+Pj4gSGFubmVzDQo+ID4+Pj4+Pj4+Pj4N Cj4gPj4+Pj4+Pj4+PiBSb2dlciBNYXJzaGFsbCB3cm90ZToNCj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+ Pj4+Pj4+PiBJIGRvbid0IGRpc2FncmVlIHRoYXQgd2UgYXNrIHRoZSBMb1NUIHNlcnZlciB0byBw aWNrIG9uZQ0KPiA+PiBhbmQNCj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IHVzZSBpdC4NCj4g Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiBXZSBuZWVkIHRvIGJlIGNvbnNpc3RlbnQgdGhvdWdo LCBhbmQgc28gdGhlcmVmb3JlLCBJDQo+ID4+IHByb3Bvc2UNCj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+ Pj4+Pj4+IHRoYXQgdGhlDQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4gTG9TVCBzZXJ2ZXIg YWx3YXlzIHBpY2tzIHRoZSBnZW8gb3ZlciB0aGUgY2l2aWMgYW5kIHJldHVybnMNCj4gPj4+Pj4+ Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IGEgZmxhZyBpbg0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+ IHRoZSByZXNwb25zZSBzdGF0aW5nIHRoYXQgdGhlIGdlbyB3YXMgdXNlZCB0bw0KPiA+Pj4+IHBl cmZvcm0gbWFwcGluZy4NCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4gUm9nZXIuDQo+ID4+ Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+Pj4+Pj4+Pj4gRnJvbTogSGFubmVzIFRz Y2hvZmVuaWcgW21haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0XQ0KPiA+Pj4+Pj4+Pj4+ Pj4gU2VudDogTW9uZGF5LCBKdW5lIDA1LCAyMDA2IDE6MzkgUE0NCj4gPj4+Pj4+Pj4+Pj4+IFRv OiBCcmlhbiBSb3Nlbg0KPiA+Pj4+Pj4+Pj4+Pj4gQ2M6IGVjcml0QGlldGYub3JnDQo+ID4+Pj4+ Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW0Vjcml0XSBbaXNzdWUyXSBJcyBpdCBhbGxvd2VkIHRvIHNw ZWNpZnkNCj4gPj4+Pj4+IGNpdmljIGFuZA0KPiA+Pj4+Pj4+Pj4+Pj4gZ2Vvc3BhdGlhbGluZm9p bnRvIHRoZSBxdWVyeT8NCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBJdCBzZWVtcyB0 aGF0IHdlIGNsb3NlZCB0aGlzIGlzc3VlLg0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+ IEV2ZXJ5b25lIHNlZW1zIHRvIGJlIGluIGZhdm9yIGZvciBhIGNpdmljIE9SIGdlb3NwYXRpYWwu DQo+ID4+Pj4+Pj4+Pj4+PiBFeHRlbnNpb25zIHBvc3NpYmxlIGZvciBmdXR1cmUgYXBwbGljYXRp b25zLg0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IENpYW8NCj4gPj4+Pj4+Pj4+Pj4+ IEhhbm5lcw0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IEJyaWFuIFJvc2VuIHdyb3Rl Og0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4gSSB0aGlu ayB0aGlzIGlzIHRoZSBpc3N1ZS4gIFRoZXJlIGlzIG5vIGd1aWRhbmNlIHdlDQo+ID4+Pj4+PiBj YW4gZ2l2ZSB0aGUNCj4gPj4+Pj4+Pj4+Pj4+PiBzZXJ2ZXIgdG8gdGVsbCBpdCBob3cgdG8gcmVz b2x2ZSB3aGF0IHRvIGRvIHdoZW4gIGJvdGgNCj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IGxv Y2F0aW9ucyBhcmUNCj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4+IHZhbGlkIGJ1dCB0aGUg VVJJIGZvciB0aGUgZ2VvIGRvZXMgbWF0Y2ggdGhlIFVSSSBmb3INCj4gPj4+Pj4+IHRoZSBjaXZp Yy4NCj4gPj4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4+IFRoaXMgaGFwcGVucyBhIGxvdCB3 aGVuIHlvdSBhcmUgbmVhciBib3VuZGFyaWVzIGJlY2F1c2UNCj4gPj4gdGhlDQo+ID4+Pj4+Pj4+ Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gcHJlY2lzaW9uDQo+ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+ Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+PiBhbmQgYWNjdXJhY3kgb2YgdGhlIHR3byBtZXRob2RzIGRp ZmZlci4NCj4gPj4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4+IEkgdGhpbmsgeW91IHBpY2sg T05FIGFuZCB1c2UgaXQuDQo+ID4+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+PiBFdmVuIGlm IHlvdSBzZW5kIG1vcmUgdGhhbiBvbmUgYWxvbmcsIHRoZSBQU0FQIGhhcyB0bw0KPiA+PiBrbm93 DQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiB3aGljaCBvbmUNCj4gPj4+Pj4+Pj4+Pg0KPiA+ Pj4+Pj4+Pj4+Pj4+IHlvdSB1c2VkIHRvIHJvdXRlLiAgSXQncyBnb2luZyB0byBjb250aW51ZSB0 byB1c2UgdGhhdA0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gdW50aWwgYSBodW1hbg0KPiA+ Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4gc2F5cyBvdGhlcndpc2UuDQo+ID4+Pj4+Pj4+Pj4+ Pj4NCj4gPj4+Pj4+Pj4+Pj4+PiBCcmlhbg0KPiA+Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+ Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4+Pj4+Pj4+PiBGcm9tOiBIZW5u aW5nIFNjaHVsenJpbm5lIFttYWlsdG86aGdzQGNzLmNvbHVtYmlhLmVkdV0NCj4gPj4+Pj4+Pj4+ Pj4+PiBTZW50OiBNb25kYXksIEp1bmUgMDUsIDIwMDYgMzo1NSBQTQ0KPiA+Pj4+Pj4+Pj4+Pj4+ IFRvOiBBbmRyZXcgTmV3dG9uDQo+ID4+Pj4+Pj4+Pj4+Pj4gQ2M6IGVjcml0QGlldGYub3JnDQo+ ID4+Pj4+Pj4+Pj4+Pj4gU3ViamVjdDogUmU6IFtFY3JpdF0gW2lzc3VlMl0gSXMgaXQgYWxsb3dl ZCB0bw0KPiA+Pj4+Pj4gc3BlY2lmeSBjaXZpYyBhbmQNCj4gPj4+Pj4+Pj4+Pj4+PiBnZW9zcGF0 aWFsaW5mbyBpbnRvIHRoZSBxdWVyeT8NCj4gPj4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4+ IEF0IHRoZSBQU0FQLCB3ZSBoYXZlIGEgaHVtYW4gdGhhdCBjYW4gbG9vayBhdCB0aGlzDQo+ID4+ Pj4+Pj4+IGluZm9ybWF0aW9uIGFuZA0KPiA+Pj4+Pj4+Pj4+Pj4+IG1ha2UgZGVjaXNpb25zIChh bmQgbWF5YmUgZXZlbiBhc2sgaWYgdGhlcmUncyBhDQo+ID4+Pj4+Pj4+IGRpc2NyZXBhbmN5KS4g VGhhdA0KPiA+Pj4+Pj4+Pj4+Pj4+IHNlZW1zIGEgc3RyZXRjaCBmb3IgdGhlIExvU1Qgc2VydmVy Lg0KPiA+Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4gQW5kcmV3IE5ld3RvbiB3cm90ZToN Cj4gPj4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4NCj4gPj4+ Pj4+Pj4+Pj4+Pj4gT24gSnVuIDUsIDIwMDYsIGF0IDI6NTMgUE0sIEhlbm5pbmcgU2NodWx6cmlu bmUgd3JvdGU6DQo+ID4+Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4+PiBJbiBhbGwgb2YgdGhlc2UgZHVhbC1pbmZvcm1hdGlv biBjYXNlcywgSSBkb24ndCBzZWUNCj4gPj4+Pj4+Pj4gaG93IGFueWJvZHkNCj4gPj4+Pj4+Pj4+ Pj4+Pj4+IGV4Y2VwdCB0aGUgc2Vla2VyIGNhbiBtYWtlIGFueSBkZXRlcm1pbmF0aW9uDQo+ID4+ Pj4gd2hpY2ggdHlwZSBvZg0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4gaW5mb3JtYXRpb24gaXMgYmV0dGVy LCBtb3JlIGFjY3VyYXRlLCBtb3JlIHJlY2VudCwgZXRjLg0KPiA+Pj4+Pj4+Pj4+Pj4+Pg0KPiA+ Pj4+Pj4+Pj4+Pj4+PiBXb3VsZCB3ZSB3YW50IHRoZSBzZWVrZXIgdG8gZGV0ZXJtaW5lIHdoaWNo IGluZm9ybWF0aW9uDQo+ID4+IGl0DQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBmZWVscyBp cw0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4+IGJlc3QgdG8gcHJvdmlkZSB0byB0aGUg UFNBUD8gIEkndmUgYWx3YXlzIGhlYXJkIHRoYXQgdGhlDQo+ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+ Pj4+Pj4+Pj4gYW5zd2VyIHdvdWxkIGJlIG5vOg0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+ Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4+IHByb3ZpZGUgYm90aCB0byB0aGUgUFNBUC4gIFNvIHdoeSB0 aGVuIHdvdWxkIHdlIG5vdA0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gcHJvdmlkZSB0aGUg c2FtZQ0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4+IGluZm9ybWF0aW9uIHdoZW4gZGV0 ZXJtaW5pbmcgd2hpY2ggUFNBUCB0byBjb250YWN0Pw0KPiA+Pj4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+ Pj4+Pj4+Pj4+PiAtYW5keQ0KPiA+Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4NCj4gPj4+ Pj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+Pj4+Pj4+Pj4+Pj4+IEVjcml0IG1haWxpbmcgbGlzdA0KPiA+Pj4+Pj4+Pj4+Pj4+IEVj cml0QGlldGYub3JnDQo+ID4+Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZWNyaXQNCj4gPj4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4+DQo+ID4+ Pj4+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPj4+Pj4+Pj4+Pj4+PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4+Pj4+PiBF Y3JpdEBpZXRmLm9yZw0KPiA+Pj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2Vjcml0DQo+ID4+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+Pg0KPiA+ Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4+Pj4+Pj4gRWNyaXQg bWFpbGluZyBsaXN0DQo+ID4+Pj4+Pj4+Pj4+PiBFY3JpdEBpZXRmLm9yZw0KPiA+Pj4+Pj4+Pj4+ Pj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4gPj4+Pj4+ Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+ Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+ Pg0KPiA+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+Pj4+Pj4+PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4gRWNyaXRAaWV0 Zi5vcmcNCj4gPj4+Pj4+Pj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZWNyaXQNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+Pj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+ID4+Pj4+ Pj4gRWNyaXRAaWV0Zi5vcmcNCj4gPj4+Pj4+PiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9lY3JpdA0KPiA+Pj4+Pg0KPiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4g Pj4+Pj4gRWNyaXRAaWV0Zi5vcmcNCj4gPj4+Pj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZWNyaXQNCj4gPj4+Pj4NCj4gPj4+DQo+ID4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gRWNyaXQgbWFpbGluZyBsaXN0 DQo+ID4+PiBFY3JpdEBpZXRmLm9yZw0KPiA+Pj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZWNyaXQNCj4gPj4NCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiBUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25h dGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCj4gPj4gY29udGFpbiBwcml2aWxlZ2VkLCBwcm9w cmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uDQo+ID4+IElmIHlvdSBo YXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCj4gPj4g aW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVz ZSBvZg0KPiA+PiB0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQo+ID4+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gW21mMl0NCj4gPj4NCj4gPj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gRWNy aXQgbWFpbGluZyBsaXN0DQo+ID4+IEVjcml0QGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3MS5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+ID4NCj4gDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBFY3JpdCBtYWlsaW5nIGxp c3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZWNyaXQNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpU aGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkN CmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGlu Zm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFu eSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJd --===============1931813562== 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 --===============1931813562==-- From ecrit-bounces@ietf.org Mon Jun 05 20:57:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPsc-00005t-LE; Mon, 05 Jun 2006 20:57:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPsb-00005f-Qf for ecrit@ietf.org; Mon, 05 Jun 2006 20:57:09 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPsZ-0002XG-ST for ecrit@ietf.org; Mon, 05 Jun 2006 20:57:09 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 05 Jun 2006 17:57:03 -0700 X-IronPort-AV: i="4.05,212,1146466800"; d="scan'208"; a="289260193:sNHT6409454878" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k560v2C7026150; Mon, 5 Jun 2006 17:57:02 -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 k560v2CY025797; Mon, 5 Jun 2006 17:57:02 -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.211); Mon, 5 Jun 2006 17:57:02 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Jun 2006 17:57:01 -0700 From: "Marc Linsner" To: "'Andrew Newton'" Subject: RE: [Ecrit] [issue2] Is it allowed tospecifycivicand geospatialinfointo the query? Date: Mon, 5 Jun 2006 20:57:00 -0400 Message-ID: <007501c68904$1ead34a0$2c0d0d0a@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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaJAZmBt6JEod/CQzm+3ox8surmVAAAVw2g X-OriginalArrivalTime: 06 Jun 2006 00:57:01.0828 (UTC) FILETIME=[1EEBC440:01C68904] DKIM-Signature: a=rsa-sha1; q=dns; l=17018; t=1149555422; x=1150419422; c=relaxed/simple; s=sjdkim2001; 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]=20[issue2]=20Is=20it=20allowed=20tospecifycivicand=09geo spatialinfointo=20the=20query?; X=v=3Dcisco.com=3B=20h=3DvDtJI3f0MrHHcf1xhy4jlH4sCxE=3D; b=gcfS4zaaAWyZXRiyRKXc04PvxQ/vAaj8bDD5u8Jx+rfmcJmfnIgRaLuY5wOdTaHjQ0FqfqlI oXkBjb552Kob1RyYd51uIG4rDk3bVs+qZWq/guzwCCJPJIuTxFNsRyxC; 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: 56904003e9d74831849863e83b1962ec Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > As to the point that a human, in an emergency situation, at > the seeker is in a better position to make the correct > judgement, I dispute that. And it's by magic that the LoST server can make this decision? 'Hmm, your query has an east coast accent so it probably came from New York, so that's the location I'll respond to and disregard the Seattle location.' Most people will look at lat/long > coordinates and not have the faintest clue how accurate they > are. Most people utilize mapping software to assist interpreting geo information. -Marc- If you plunk me down in the middle of Tokyo, I'd have > to do a coin toss to tell you which is more accurate, civic > or geo. And what about cases were the seeker is a gateway? > > To be honest, whether the server would know better or the > client would know better is something I think none of us can > answer with certainty at the moment. I would just rather not > create a protocol that precludes one or the other. > > -andy > > On Jun 5, 2006, at 8:11 PM, Henning Schulzrinne wrote: > > > Yes, you could do that, but you now have to carry possibly two > > error indications, have to worry about carrying two boundaries, > > etc. Just made the protocol much messier, for both client and > > server. It gets worse: in all likelihood, the server has to > recurse > > or iterate differently for civic and geo coordinates, so > the server > > has to wait until both results are in from upstream servers (or > > return just one result after a timeout). This all just seems > > pointlessly complex, given that the same result can be trivially > > achieved by splitting the query. > > > > On Jun 5, 2006, at 8:04 PM, Winterbottom, James wrote: > > > >> Why wouldn't the LoSt server simply treat each representation on > >> its own > >> merits? You give me two locations you get back 2 URIs, even if > >> they are > >> the same. > >> > >> > >>> -----Original Message----- > >>> From: Marc Linsner [mailto:mlinsner@cisco.com] > >>> Sent: Tuesday, 6 June 2006 9:44 AM > >>> To: 'Roger Marshall'; 'Andrew Newton' > >>> Cc: ecrit@ietf.org > >>> Subject: RE: [Ecrit] [issue2] Is it allowed tospecifycivicand > >>> geospatialinfointo the query? > >>> > >>> Roger, > >>> > >>> I'm not arguing geo vs. civil. All I am trying to state is when > >> multiple > >>> location representations are known for a LoST client, the LoST > >>> server/service should not be the one to determine which > >>> representation > >> is > >>> best. > >>> > >>> Setup for failure example #1: A single LoST query contains both a > >> civic > >>> (123 > >>> Main St.) and a geo representation. All geocode > databases return > >>> 456 > >>> Second > >>> St. for the geo. Which one should LoST prefer? > >>> > >>> Setup for failure example #2: A single LoST query > contains two civic > >>> representations. One is in New York City and the other > in Seattle. > >> Which > >>> one should LoST prefer? > >>> > >>> IMO, each example should be (2) unique queries, one for each > >>> representation, > >>> and let the client deal with it. This decision needs to > be made as > >> close > >>> to > >>> a human as possible, I don't foresee any programmatic > solution. If > >> the > >>> client holds (2) location representations, the problem is > theirs and > >> needs > >>> to be resolved there. Once a PSAP call taker (a second human) is > >>> involved, > >>> then the two humans can negotiate the issue. > >>> > >>> Too many variables to standardize a solution. > >>> > >>> -Marc- > >>> > >>> > >>> > >>> > >>>> > >>>> Marc: > >>>> What is the scale of "accuracy" for a civic street address? > >> 0%,100%? > >>>> > >>>> Just because both civic and geo are included, doesn't mean > >>>> one is better. For example, it is obvious that lat/lon's > >>>> have measurement criteria whereas civic addresses don't, > >>>> since they're either "stated" or "derived". > >>>> > >>>> Parcel-based GIS mapping systems exist today which describe a > >>>> location in terms of both. As a simple example, Google Earth > >>>> does this for you. > >>>> You specify 123 Main Street, Anytown, USA and once it finds > >>>> it, it also provides a lat/lon. I admit that the there are > >>>> challenges with using both, but I expect that those issues > >>>> will become fewer over time. > >>>> > >>>> Does there have to be a line in the sand as to whether a > >>>> particular location is known in terms of civic vs. geo and > >>>> not both? I don't think so. > >>>> > >>>> > >>>> Roger Marshall > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Marc Linsner [mailto:mlinsner@cisco.com] > >>>>> Sent: Monday, June 05, 2006 3:23 PM > >>>>> To: 'Andrew Newton' > >>>>> Cc: ecrit@ietf.org > >>>>> Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivicand > >>>>> geospatialinfointo the query? > >>>>> > >>>>> Andy, > >>>>> > >>>>> The problem is that the 'preferred' location is the accurate > >>>> one. No > >>>>> LoST server/service will be able to determine which one is most > >>>>> accurate. You may equate the same problem to the client, > >>>> but IMO, it's > >>>>> better that the client make the decision since it's closer > >>>> to the human > >>>>> that 'should' know. > >>>>> > >>>>> -Marc- > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Andrew Newton [mailto:andy@hxr.us] > >>>>>> Sent: Monday, June 05, 2006 5:58 PM > >>>>>> To: Marc Linsner > >>>>>> Cc: 'Hannes Tschofenig'; ecrit@ietf.org > >>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civicand > >>>>>> geospatialinfointo the query? > >>>>>> > >>>>>> I think we'd have a protocol more capable of adapting to > >>>> unforeseen, > >>>>>> real world issues if both were sent and the server had the > >>>>> opportunity > >>>>>> to determine which type of location it preferred. I must > >>>> admit that > >>>>>> it seems a bit of a stretch, but I think it is just as possible > >> as > >>>>>> Henning's idea that the client will have the same type of > >>>>> notion. It > >>>>>> almost always seems to me that if ever there is a > question about > >>>>>> preference, it should fall to the LoST service operators and > >> their > >>>>>> jurisdictional considerations. > >>>>>> > >>>>>> It also seems to me that if a client or seeker does, in some > >>>>> odd way, > >>>>>> have a notion of a preferred type of location when it > >>>>> possesses both, > >>>>>> that it can always just send the query with only the type of > >>>>> location > >>>>>> it prefers. For clients that don't have this strong notion, > >>>>> send both > >>>>>> and see if the server has a preference. > >>>>>> > >>>>>> -andy > >>>>>> > >>>>>> > >>>>>> On Jun 5, 2006, at 5:39 PM, Marc Linsner wrote: > >>>>>> > >>>>>>> I agree, the LoST client submits one location at a time. > >>>>>> No decisions > >>>>>>> made by LoST server/service. > >>>>>>> > >>>>>>> -Marc- > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>>>>> Sent: Monday, June 05, 2006 5:24 PM > >>>>>>>> To: Roger Marshall > >>>>>>>> Cc: ecrit@ietf.org > >>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify > >> civicand > >>>>>>>> geospatialinfointo the query? > >>>>>>>> > >>>>>>>> Hi Roger, > >>>>>>>> > >>>>>>>> Roger Marshall wrote: > >>>>>>>>> Hannes: Thanks for clarifying. > >>>>>>>>> > >>>>>>>>> I think it's a bad idea to withold location information > >>>>>>>> from the LoST > >>>>>>>>> server. > >>>>>>>>> > >>>>>>>>> To suggest that we restrict the client, allowing only one > >>>>>>>> to be sent, > >>>>>>>>> sounds to me like we're placing a constraint on the > >>>>>>>> PIDF-LO, saying it > >>>>>>>>> can't have both (assuming LoST reuses the PIDF-LO). I > >>>>>>>> don't think we > >>>>>>>>> can get away with that. If the PIDF-LO has both, how is > >>>>>>>> it that we can > >>>>>>>>> glibly strip one out? To do so would be unreasonable. > >>>>>>>> > >>>>>>>> To clarify: > >>>>>>>> > >>>>>>>> * You can send as many queries as you want but not with > >>>> the same > >>>>>>>> message. Different location information => different query > >>>>>>>> > >>>>>>>> * We don't use a PIDF-LO in LoST. We use the raw location > >> info. > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Since the client can have both civic and geo in the > >>>>>> PIDF-LO, it can > >>>>>>>>> also send both to the server. What am I missing? > >>>>>>>> > >>>>>>>> None of the proposals ever used a PIDF-LO as input; > >>>> just location > >>>>>>>> info. > >>>>>>>> > >>>>>>>>> > >>>>>>>>> It's the LoST server's job to pick one, not the client's. > >>>>>>>> > >>>>>>>> At the PSAP and the emergency routing proxy I agree with you. > >>>>>>>> > >>>>>>>>> > >>>>>>>>> So, the requirement I would support is as follows: > >>>>>>>>> > >>>>>>>>> Rx' LoST client SHALL query with either civic or geo. > >>>>>>>> > >>>>>>>> That's fine. > >>>>>>>> > >>>>>>>> > >>>>>>>>> Ry' LoST client SHOULD query with *both* civic and geo. > >>>>>> When LoST > >>>>>>>>> server receives both civic and geo, the server SHOULD try > >>>>>>>> to use the > >>>>>>>>> geo first. The LoST server response SHALL indicate which > >>>>>> data was > >>>>>>>>> used (either geo or civic). > >>>>>>>> > >>>>>>>> I guess you will not support for this one based on the > >>>>>> response I saw > >>>>>>>> on the list so far. > >>>>>>>> > >>>>>>>> Ciao > >>>>>>>> Hannes > >>>>>>>> > >>>>>>>>> > >>>>>>>>> -roger. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>>>>>>> Sent: Monday, June 05, 2006 1:50 PM > >>>>>>>>>> To: Roger Marshall > >>>>>>>>>> Cc: Brian Rosen; ecrit@ietf.org > >>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify > >>>>> civic and > >>>>>>>>>> geospatialinfointo the query? > >>>>>>>>>> > >>>>>>>>>> Hi Roger, > >>>>>>>>>> > >>>>>>>>>> I think the current suggestion is that the LoST client > >>>>>> just picks > >>>>>>>>>> whatever he wants and then uses the mapping protocol to > >>>>>> trigger the > >>>>>>>>>> resolution. > >>>>>>>>>> > >>>>>>>>>> Using geo and civic might be, from a certain point of view, > >>>>>>>> just be an > >>>>>>>>>> optimization. The LoST client can always trigger separate > >>>>>>>> queries with > >>>>>>>>>> all the location info it has. > >>>>>>>>>> > >>>>>>>>>> Ciao > >>>>>>>>>> Hannes > >>>>>>>>>> > >>>>>>>>>> Roger Marshall wrote: > >>>>>>>>>> > >>>>>>>>>>> I don't disagree that we ask the LoST server to pick one > >> and > >>>>>>>>>> > >>>>>>>>>> use it. > >>>>>>>>>> > >>>>>>>>>>> We need to be consistent though, and so therefore, I > >> propose > >>>>>>>>>> > >>>>>>>>>> that the > >>>>>>>>>> > >>>>>>>>>>> LoST server always picks the geo over the civic > and returns > >>>>>>>>>> > >>>>>>>>>> a flag in > >>>>>>>>>> > >>>>>>>>>>> the response stating that the geo was used to > >>>> perform mapping. > >>>>>>>>>>> > >>>>>>>>>>> Roger. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>> From: Hannes Tschofenig > [mailto:Hannes.Tschofenig@gmx.net] > >>>>>>>>>>>> Sent: Monday, June 05, 2006 1:39 PM > >>>>>>>>>>>> To: Brian Rosen > >>>>>>>>>>>> Cc: ecrit@ietf.org > >>>>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify > >>>>>> civic and > >>>>>>>>>>>> geospatialinfointo the query? > >>>>>>>>>>>> > >>>>>>>>>>>> It seems that we closed this issue. > >>>>>>>>>>>> > >>>>>>>>>>>> Everyone seems to be in favor for a civic OR geospatial. > >>>>>>>>>>>> Extensions possible for future applications. > >>>>>>>>>>>> > >>>>>>>>>>>> Ciao > >>>>>>>>>>>> Hannes > >>>>>>>>>>>> > >>>>>>>>>>>> Brian Rosen wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> I think this is the issue. There is no guidance we > >>>>>> can give the > >>>>>>>>>>>>> server to tell it how to resolve what to do when both > >>>>>>>>>> > >>>>>>>>>> locations are > >>>>>>>>>> > >>>>>>>>>>>>> valid but the URI for the geo does match the URI for > >>>>>> the civic. > >>>>>>>>>>>>> > >>>>>>>>>>>>> This happens a lot when you are near boundaries because > >> the > >>>>>>>>>>>> > >>>>>>>>>>>> precision > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> and accuracy of the two methods differ. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I think you pick ONE and use it. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Even if you send more than one along, the PSAP has to > >> know > >>>>>>>>>> > >>>>>>>>>> which one > >>>>>>>>>> > >>>>>>>>>>>>> you used to route. It's going to continue to use that > >>>>>>>>>> > >>>>>>>>>> until a human > >>>>>>>>>> > >>>>>>>>>>>>> says otherwise. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Brian > >>>>>>>>>>>>> > >>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>>>>>>>>>>>> Sent: Monday, June 05, 2006 3:55 PM > >>>>>>>>>>>>> To: Andrew Newton > >>>>>>>>>>>>> Cc: ecrit@ietf.org > >>>>>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to > >>>>>> specify civic and > >>>>>>>>>>>>> geospatialinfo into the query? > >>>>>>>>>>>>> > >>>>>>>>>>>>> At the PSAP, we have a human that can look at this > >>>>>>>> information and > >>>>>>>>>>>>> make decisions (and maybe even ask if there's a > >>>>>>>> discrepancy). That > >>>>>>>>>>>>> seems a stretch for the LoST server. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Andrew Newton wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> In all of these dual-information cases, I don't see > >>>>>>>> how anybody > >>>>>>>>>>>>>>> except the seeker can make any determination > >>>> which type of > >>>>>>>>>>>>>>> information is better, more accurate, more > recent, etc. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Would we want the seeker to determine which information > >> it > >>>>>>>>>> > >>>>>>>>>> feels is > >>>>>>>>>> > >>>>>>>>>>>>>> best to provide to the PSAP? I've always > heard that the > >>>>>>>>>>>> > >>>>>>>>>>>> answer would be no: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>>> provide both to the PSAP. So why then would we not > >>>>>>>>>> > >>>>>>>>>> provide the same > >>>>>>>>>> > >>>>>>>>>>>>>> information when determining which PSAP to contact? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -andy > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>> Ecrit mailing list > >>>>>>>>>>>>> Ecrit@ietf.org > >>>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>> Ecrit mailing list > >>>>>>>>>>>>> Ecrit@ietf.org > >>>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> Ecrit mailing list > >>>>>>>>>>>> Ecrit@ietf.org > >>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Ecrit mailing list > >>>>>>>> Ecrit@ietf.org > >>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Ecrit mailing list > >>>>>>> Ecrit@ietf.org > >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>> > >>>>> _______________________________________________ > >>>>> Ecrit mailing list > >>>>> Ecrit@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>> > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/ecrit > >> > >> > --------------------------------------------------------------------- > >> --------------------------- > >> This message is for the designated recipient only and may > >> contain privileged, proprietary, or otherwise private information. > >> If you have received it in error, please notify the sender > >> immediately and delete the original. Any unauthorized use of > >> this email is prohibited. > >> > --------------------------------------------------------------------- > >> --------------------------- > >> [mf2] > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 05 21:04:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPzv-0001u8-BI; Mon, 05 Jun 2006 21:04:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPzu-0001u3-22 for ecrit@ietf.org; Mon, 05 Jun 2006 21:04:42 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPzs-00045K-Rj for ecrit@ietf.org; Mon, 05 Jun 2006 21:04:42 -0400 Received: from [10.0.1.103] ([::ffff:68.106.115.242]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 05 Jun 2006 21:05:09 -0400 id 0158C102.4484D4C5.00006560 In-Reply-To: References: <024701c688e0$7cc7ab70$640fa8c0@cis.neustar.com> <4484A04C.7080600@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8CB88358-F626-4216-8677-AE0CE10EB676@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] [issue6] 'Authority' Attribute in LoST Response Date: Mon, 5 Jun 2006 21:04:39 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 5, 2006, at 8:27 PM, Henning Schulzrinne wrote: >> Just why would I want to ask the same question multiple times to >> the same server in the same seek operation? It would seem that >> detecting referral loops would be awfully important. The type of >> identifier used is not that important, so a URI is fine by me. > > It's a bit of a stretch, so a URL that identifies the actual > "virtual" host is probably sufficient to deal with the case that a > single server can serve multiple levels (such as state and some > towns within a state, but not county). I don't understand your response. Is the scenario you are drawing one where a single URL identifies a server that serves a state and some of the towns in the state but not some of the counties that hierarchically between the state and the towns? It would seem a bit odd for a server that has the authoritative information to say, "you must first go ask that guy and he will refer you to me, and then I will answer your question." Talk about bureaucracy! >> I'm not sure about multiple URIs. Also, you'd need to define a >> much more detailed interface for automated checking than "here is >> a bunch of URIs". > > The idea for automated checking would be that the checker is a > robot, but it would just generate text meant for a human, just like > web checkers generate mail to webmaster@domain that's meant to be > interpreted by a human. The common name for this is "spam". I don't care if you want to do this, so long as it doesn't interfere with referral loop detection. But I do think it is overkill. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 06 03:31:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnW2C-0003t4-4K; Tue, 06 Jun 2006 03:31:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnW2A-0003pg-Cw for ecrit@ietf.org; Tue, 06 Jun 2006 03:31:26 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnW29-0002rY-IF for ecrit@ietf.org; Tue, 06 Jun 2006 03:31:26 -0400 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.6.118]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k567VJ022042; Tue, 6 Jun 2006 01:31:19 -0600 Message-ID: <4485315B.20900@ntt-at.com> Date: Tue, 06 Jun 2006 00:40:11 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Ecrit] [issue2] Is it allowed tospecifycivicand geospatialinfointo the query? References: <007501c68904$1ead34a0$2c0d0d0a@amer.cisco.com> In-Reply-To: <007501c68904$1ead34a0$2c0d0d0a@amer.cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 06321bb70e4329e24fb56a67c5eca3a0 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I thought we wanted to eliminate as much user's involvement as possible when making an emergency call, so I object returning multiple URIs based on multiple location type if we anticipate any user's interaction as a result of supporting this feature. Now, on the other hand if the LOST server complies to requirement Ma8 and returns only one primary URI with multiple alternate URIs (possibly 2 from Geo resolution and 1 from Civic resolution if one of the URI from Civic resolution was picked as the primary URI), I don't really see a problem with LOST server returning URIs based on two different location types(civic & geo). BTW did I see any post on this thread stating LOST server might return an error when it does not support the location type? I hope I am hallucinating because if that is the behavior considered for LOST server, it should at least redirect to another LOST server that can resolve the location type provided(Considering UA can't provide any other location type it will not be able to make an emergency call..). Regards Shida Marc Linsner wrote: > > >> As to the point that a human, in an emergency situation, at >> the seeker is in a better position to make the correct >> judgement, I dispute that. >> > > And it's by magic that the LoST server can make this decision? 'Hmm, your > query has an east coast accent so it probably came from New York, so that's > the location I'll respond to and disregard the Seattle location.' > > Most people will look at lat/long > >> coordinates and not have the faintest clue how accurate they >> are. >> > > Most people utilize mapping software to assist interpreting geo information. > > -Marc- > > If you plunk me down in the middle of Tokyo, I'd have > >> to do a coin toss to tell you which is more accurate, civic >> or geo. And what about cases were the seeker is a gateway? >> >> To be honest, whether the server would know better or the >> client would know better is something I think none of us can >> answer with certainty at the moment. I would just rather not >> create a protocol that precludes one or the other. >> >> -andy >> >> On Jun 5, 2006, at 8:11 PM, Henning Schulzrinne wrote: >> >> >>> Yes, you could do that, but you now have to carry possibly two >>> error indications, have to worry about carrying two boundaries, >>> etc. Just made the protocol much messier, for both client and >>> server. It gets worse: in all likelihood, the server has to >>> >> recurse >> >>> or iterate differently for civic and geo coordinates, so >>> >> the server >> >>> has to wait until both results are in from upstream servers (or >>> return just one result after a timeout). This all just seems >>> pointlessly complex, given that the same result can be trivially >>> achieved by splitting the query. >>> >>> On Jun 5, 2006, at 8:04 PM, Winterbottom, James wrote: >>> >>> >>>> Why wouldn't the LoSt server simply treat each representation on >>>> its own >>>> merits? You give me two locations you get back 2 URIs, even if >>>> they are >>>> the same. >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Marc Linsner [mailto:mlinsner@cisco.com] >>>>> Sent: Tuesday, 6 June 2006 9:44 AM >>>>> To: 'Roger Marshall'; 'Andrew Newton' >>>>> Cc: ecrit@ietf.org >>>>> Subject: RE: [Ecrit] [issue2] Is it allowed tospecifycivicand >>>>> geospatialinfointo the query? >>>>> >>>>> Roger, >>>>> >>>>> I'm not arguing geo vs. civil. All I am trying to state is when >>>>> >>>> multiple >>>> >>>>> location representations are known for a LoST client, the LoST >>>>> server/service should not be the one to determine which >>>>> representation >>>>> >>>> is >>>> >>>>> best. >>>>> >>>>> Setup for failure example #1: A single LoST query contains both a >>>>> >>>> civic >>>> >>>>> (123 >>>>> Main St.) and a geo representation. All geocode >>>>> >> databases return >> >>>>> 456 >>>>> Second >>>>> St. for the geo. Which one should LoST prefer? >>>>> >>>>> Setup for failure example #2: A single LoST query >>>>> >> contains two civic >> >>>>> representations. One is in New York City and the other >>>>> >> in Seattle. >> >>>> Which >>>> >>>>> one should LoST prefer? >>>>> >>>>> IMO, each example should be (2) unique queries, one for each >>>>> representation, >>>>> and let the client deal with it. This decision needs to >>>>> >> be made as >> >>>> close >>>> >>>>> to >>>>> a human as possible, I don't foresee any programmatic >>>>> >> solution. If >> >>>> the >>>> >>>>> client holds (2) location representations, the problem is >>>>> >> theirs and >> >>>> needs >>>> >>>>> to be resolved there. Once a PSAP call taker (a second human) is >>>>> involved, >>>>> then the two humans can negotiate the issue. >>>>> >>>>> Too many variables to standardize a solution. >>>>> >>>>> -Marc- >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Marc: >>>>>> What is the scale of "accuracy" for a civic street address? >>>>>> >>>> 0%,100%? >>>> >>>>>> Just because both civic and geo are included, doesn't mean >>>>>> one is better. For example, it is obvious that lat/lon's >>>>>> have measurement criteria whereas civic addresses don't, >>>>>> since they're either "stated" or "derived". >>>>>> >>>>>> Parcel-based GIS mapping systems exist today which describe a >>>>>> location in terms of both. As a simple example, Google Earth >>>>>> does this for you. >>>>>> You specify 123 Main Street, Anytown, USA and once it finds >>>>>> it, it also provides a lat/lon. I admit that the there are >>>>>> challenges with using both, but I expect that those issues >>>>>> will become fewer over time. >>>>>> >>>>>> Does there have to be a line in the sand as to whether a >>>>>> particular location is known in terms of civic vs. geo and >>>>>> not both? I don't think so. >>>>>> >>>>>> >>>>>> Roger Marshall >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Marc Linsner [mailto:mlinsner@cisco.com] >>>>>>> Sent: Monday, June 05, 2006 3:23 PM >>>>>>> To: 'Andrew Newton' >>>>>>> Cc: ecrit@ietf.org >>>>>>> Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivicand >>>>>>> geospatialinfointo the query? >>>>>>> >>>>>>> Andy, >>>>>>> >>>>>>> The problem is that the 'preferred' location is the accurate >>>>>>> >>>>>> one. No >>>>>> >>>>>>> LoST server/service will be able to determine which one is most >>>>>>> accurate. You may equate the same problem to the client, >>>>>>> >>>>>> but IMO, it's >>>>>> >>>>>>> better that the client make the decision since it's closer >>>>>>> >>>>>> to the human >>>>>> >>>>>>> that 'should' know. >>>>>>> >>>>>>> -Marc- >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Andrew Newton [mailto:andy@hxr.us] >>>>>>>> Sent: Monday, June 05, 2006 5:58 PM >>>>>>>> To: Marc Linsner >>>>>>>> Cc: 'Hannes Tschofenig'; ecrit@ietf.org >>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civicand >>>>>>>> geospatialinfointo the query? >>>>>>>> >>>>>>>> I think we'd have a protocol more capable of adapting to >>>>>>>> >>>>>> unforeseen, >>>>>> >>>>>>>> real world issues if both were sent and the server had the >>>>>>>> >>>>>>> opportunity >>>>>>> >>>>>>>> to determine which type of location it preferred. I must >>>>>>>> >>>>>> admit that >>>>>> >>>>>>>> it seems a bit of a stretch, but I think it is just as possible >>>>>>>> >>>> as >>>> >>>>>>>> Henning's idea that the client will have the same type of >>>>>>>> >>>>>>> notion. It >>>>>>> >>>>>>>> almost always seems to me that if ever there is a >>>>>>>> >> question about >> >>>>>>>> preference, it should fall to the LoST service operators and >>>>>>>> >>>> their >>>> >>>>>>>> jurisdictional considerations. >>>>>>>> >>>>>>>> It also seems to me that if a client or seeker does, in some >>>>>>>> >>>>>>> odd way, >>>>>>> >>>>>>>> have a notion of a preferred type of location when it >>>>>>>> >>>>>>> possesses both, >>>>>>> >>>>>>>> that it can always just send the query with only the type of >>>>>>>> >>>>>>> location >>>>>>> >>>>>>>> it prefers. For clients that don't have this strong notion, >>>>>>>> >>>>>>> send both >>>>>>> >>>>>>>> and see if the server has a preference. >>>>>>>> >>>>>>>> -andy >>>>>>>> >>>>>>>> >>>>>>>> On Jun 5, 2006, at 5:39 PM, Marc Linsner wrote: >>>>>>>> >>>>>>>> >>>>>>>>> I agree, the LoST client submits one location at a time. >>>>>>>>> >>>>>>>> No decisions >>>>>>>> >>>>>>>>> made by LoST server/service. >>>>>>>>> >>>>>>>>> -Marc- >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>>> Sent: Monday, June 05, 2006 5:24 PM >>>>>>>>>> To: Roger Marshall >>>>>>>>>> Cc: ecrit@ietf.org >>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify >>>>>>>>>> >>>> civicand >>>> >>>>>>>>>> geospatialinfointo the query? >>>>>>>>>> >>>>>>>>>> Hi Roger, >>>>>>>>>> >>>>>>>>>> Roger Marshall wrote: >>>>>>>>>> >>>>>>>>>>> Hannes: Thanks for clarifying. >>>>>>>>>>> >>>>>>>>>>> I think it's a bad idea to withold location information >>>>>>>>>>> >>>>>>>>>> from the LoST >>>>>>>>>> >>>>>>>>>>> server. >>>>>>>>>>> >>>>>>>>>>> To suggest that we restrict the client, allowing only one >>>>>>>>>>> >>>>>>>>>> to be sent, >>>>>>>>>> >>>>>>>>>>> sounds to me like we're placing a constraint on the >>>>>>>>>>> >>>>>>>>>> PIDF-LO, saying it >>>>>>>>>> >>>>>>>>>>> can't have both (assuming LoST reuses the PIDF-LO). I >>>>>>>>>>> >>>>>>>>>> don't think we >>>>>>>>>> >>>>>>>>>>> can get away with that. If the PIDF-LO has both, how is >>>>>>>>>>> >>>>>>>>>> it that we can >>>>>>>>>> >>>>>>>>>>> glibly strip one out? To do so would be unreasonable. >>>>>>>>>>> >>>>>>>>>> To clarify: >>>>>>>>>> >>>>>>>>>> * You can send as many queries as you want but not with >>>>>>>>>> >>>>>> the same >>>>>> >>>>>>>>>> message. Different location information => different query >>>>>>>>>> >>>>>>>>>> * We don't use a PIDF-LO in LoST. We use the raw location >>>>>>>>>> >>>> info. >>>> >>>>>>>>>>> Since the client can have both civic and geo in the >>>>>>>>>>> >>>>>>>> PIDF-LO, it can >>>>>>>> >>>>>>>>>>> also send both to the server. What am I missing? >>>>>>>>>>> >>>>>>>>>> None of the proposals ever used a PIDF-LO as input; >>>>>>>>>> >>>>>> just location >>>>>> >>>>>>>>>> info. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> It's the LoST server's job to pick one, not the client's. >>>>>>>>>>> >>>>>>>>>> At the PSAP and the emergency routing proxy I agree with you. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> So, the requirement I would support is as follows: >>>>>>>>>>> >>>>>>>>>>> Rx' LoST client SHALL query with either civic or geo. >>>>>>>>>>> >>>>>>>>>> That's fine. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Ry' LoST client SHOULD query with *both* civic and geo. >>>>>>>>>>> >>>>>>>> When LoST >>>>>>>> >>>>>>>>>>> server receives both civic and geo, the server SHOULD try >>>>>>>>>>> >>>>>>>>>> to use the >>>>>>>>>> >>>>>>>>>>> geo first. The LoST server response SHALL indicate which >>>>>>>>>>> >>>>>>>> data was >>>>>>>> >>>>>>>>>>> used (either geo or civic). >>>>>>>>>>> >>>>>>>>>> I guess you will not support for this one based on the >>>>>>>>>> >>>>>>>> response I saw >>>>>>>> >>>>>>>>>> on the list so far. >>>>>>>>>> >>>>>>>>>> Ciao >>>>>>>>>> Hannes >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -roger. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>>>>> Sent: Monday, June 05, 2006 1:50 PM >>>>>>>>>>>> To: Roger Marshall >>>>>>>>>>>> Cc: Brian Rosen; ecrit@ietf.org >>>>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify >>>>>>>>>>>> >>>>>>> civic and >>>>>>> >>>>>>>>>>>> geospatialinfointo the query? >>>>>>>>>>>> >>>>>>>>>>>> Hi Roger, >>>>>>>>>>>> >>>>>>>>>>>> I think the current suggestion is that the LoST client >>>>>>>>>>>> >>>>>>>> just picks >>>>>>>> >>>>>>>>>>>> whatever he wants and then uses the mapping protocol to >>>>>>>>>>>> >>>>>>>> trigger the >>>>>>>> >>>>>>>>>>>> resolution. >>>>>>>>>>>> >>>>>>>>>>>> Using geo and civic might be, from a certain point of view, >>>>>>>>>>>> >>>>>>>>>> just be an >>>>>>>>>> >>>>>>>>>>>> optimization. The LoST client can always trigger separate >>>>>>>>>>>> >>>>>>>>>> queries with >>>>>>>>>> >>>>>>>>>>>> all the location info it has. >>>>>>>>>>>> >>>>>>>>>>>> Ciao >>>>>>>>>>>> Hannes >>>>>>>>>>>> >>>>>>>>>>>> Roger Marshall wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> I don't disagree that we ask the LoST server to pick one >>>>>>>>>>>>> >>>> and >>>> >>>>>>>>>>>> use it. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> We need to be consistent though, and so therefore, I >>>>>>>>>>>>> >>>> propose >>>> >>>>>>>>>>>> that the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> LoST server always picks the geo over the civic >>>>>>>>>>>>> >> and returns >> >>>>>>>>>>>> a flag in >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> the response stating that the geo was used to >>>>>>>>>>>>> >>>>>> perform mapping. >>>>>> >>>>>>>>>>>>> Roger. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Hannes Tschofenig >>>>>>>>>>>>>> >> [mailto:Hannes.Tschofenig@gmx.net] >> >>>>>>>>>>>>>> Sent: Monday, June 05, 2006 1:39 PM >>>>>>>>>>>>>> To: Brian Rosen >>>>>>>>>>>>>> Cc: ecrit@ietf.org >>>>>>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify >>>>>>>>>>>>>> >>>>>>>> civic and >>>>>>>> >>>>>>>>>>>>>> geospatialinfointo the query? >>>>>>>>>>>>>> >>>>>>>>>>>>>> It seems that we closed this issue. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Everyone seems to be in favor for a civic OR geospatial. >>>>>>>>>>>>>> Extensions possible for future applications. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ciao >>>>>>>>>>>>>> Hannes >>>>>>>>>>>>>> >>>>>>>>>>>>>> Brian Rosen wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think this is the issue. There is no guidance we >>>>>>>>>>>>>>> >>>>>>>> can give the >>>>>>>> >>>>>>>>>>>>>>> server to tell it how to resolve what to do when both >>>>>>>>>>>>>>> >>>>>>>>>>>> locations are >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> valid but the URI for the geo does match the URI for >>>>>>>>>>>>>>> >>>>>>>> the civic. >>>>>>>> >>>>>>>>>>>>>>> This happens a lot when you are near boundaries because >>>>>>>>>>>>>>> >>>> the >>>> >>>>>>>>>>>>>> precision >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> and accuracy of the two methods differ. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think you pick ONE and use it. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Even if you send more than one along, the PSAP has to >>>>>>>>>>>>>>> >>>> know >>>> >>>>>>>>>>>> which one >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> you used to route. It's going to continue to use that >>>>>>>>>>>>>>> >>>>>>>>>>>> until a human >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> says otherwise. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Brian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>>>>>>>>>>>> Sent: Monday, June 05, 2006 3:55 PM >>>>>>>>>>>>>>> To: Andrew Newton >>>>>>>>>>>>>>> Cc: ecrit@ietf.org >>>>>>>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to >>>>>>>>>>>>>>> >>>>>>>> specify civic and >>>>>>>> >>>>>>>>>>>>>>> geospatialinfo into the query? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> At the PSAP, we have a human that can look at this >>>>>>>>>>>>>>> >>>>>>>>>> information and >>>>>>>>>> >>>>>>>>>>>>>>> make decisions (and maybe even ask if there's a >>>>>>>>>>>>>>> >>>>>>>>>> discrepancy). That >>>>>>>>>> >>>>>>>>>>>>>>> seems a stretch for the LoST server. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Andrew Newton wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In all of these dual-information cases, I don't see >>>>>>>>>>>>>>>>> >>>>>>>>>> how anybody >>>>>>>>>> >>>>>>>>>>>>>>>>> except the seeker can make any determination >>>>>>>>>>>>>>>>> >>>>>> which type of >>>>>> >>>>>>>>>>>>>>>>> information is better, more accurate, more >>>>>>>>>>>>>>>>> >> recent, etc. >> >>>>>>>>>>>>>>>> Would we want the seeker to determine which information >>>>>>>>>>>>>>>> >>>> it >>>> >>>>>>>>>>>> feels is >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>> best to provide to the PSAP? I've always >>>>>>>>>>>>>>>> >> heard that the >> >>>>>>>>>>>>>> answer would be no: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> provide both to the PSAP. So why then would we not >>>>>>>>>>>>>>>> >>>>>>>>>>>> provide the same >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>> information when determining which PSAP to contact? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -andy >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> Ecrit mailing list >>>>>>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> Ecrit mailing list >>>>>>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> Ecrit mailing list >>>>>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Ecrit mailing list >>>>>>>>>> Ecrit@ietf.org >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Ecrit mailing list >>>>>>>>> Ecrit@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>> >>>> >> --------------------------------------------------------------------- >> >>>> --------------------------- >>>> This message is for the designated recipient only and may >>>> contain privileged, proprietary, or otherwise private information. >>>> If you have received it in error, please notify the sender >>>> immediately and delete the original. Any unauthorized use of >>>> this email is prohibited. >>>> >>>> >> --------------------------------------------------------------------- >> >>>> --------------------------- >>>> [mf2] >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 06 08:18:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnaVV-0006Qo-SQ; Tue, 06 Jun 2006 08:18:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnaVU-0006Ji-FU for ecrit@ietf.org; Tue, 06 Jun 2006 08:18:00 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnaVS-00017b-5o for ecrit@ietf.org; Tue, 06 Jun 2006 08:18:00 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k56CEtZE016926; Tue, 6 Jun 2006 07:14:56 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 6 Jun 2006 13:14:54 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C2908E5@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'shida@ntt-at.com'" , Henning Schulzrinne Subject: RE: [Ecrit] [issue1] Do we need a default service URN for the LoS Tquery? Date: Tue, 6 Jun 2006 13:14:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-2022-jp" X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I still see this capability as a distinction between emergency calls and other geographically provided services. If I have a "sos" urn with a subtype, then I want the default emergency operator for my local area, if the subtype cannot be matched. If I have a "food" urn with a subtype of "pizza", then I don't want the default food service if the subtype cannot be matched. More specifically, for local support helplines, if I dial the suicide advice helpline, then I want to reach that helpline with its guarantees of anonymity, no matter where it is provided, rather than provided with a more local general support line. regards Keith > -----Original Message----- > From: Shida Schubert [mailto:shida@ntt-at.com] > Sent: 05 June 2006 23:56 > To: Henning Schulzrinne > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] [issue1] Do we need a default service > URN for the LoSTquery? > > > > I strongly agree with Henning here for the exact reason > Henning expressed. > > Default service, from the importance will likely be the emergency > service, and this will lead to unintended emergency call if we > support this default service. > > It may be a possibility that requesting without the service identifier > will result with a response containing list of services the > LOST server > supports. > > Regards > Shida > > Henning Schulzrinne wrote: > > > > > > Roger Marshall wrote: > >> The LoST server must support a default, so that if it > receives a query > >> which contains location, but no emergency service > identifier, then it > >> can still provide an answer. > > > > I don't see that as necessary or helpful. Why can't the > client always > > insert a service URN? This seems a trivial thing to do for a client > > and avoids problems of trying to guess what the client > really wanted. > > (Remember that LoST may well be used for non-emergency > services, too.) > > > > I don't think "you know what I mean" protocol features are > a good way > > forward. > > > > > >> > >> The worst case of having this happen is that clients always get an > >> emergency context associated, location-relevant PSAP URI > when they query > >> with location only. The server would then return this > "default" ESI so > >> that the client would have it from then on. > >> > >> I think the LoST protocol requirements for query including > an ESI is a > >> SHOULD, and a response msg. to include an ESI is a MUST. > >> > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 06 09:40:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnbnB-0000eu-6o; Tue, 06 Jun 2006 09:40:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnbn9-0000eK-ON for ecrit@ietf.org; Tue, 06 Jun 2006 09:40:19 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnbn8-0001XP-HH for ecrit@ietf.org; Tue, 06 Jun 2006 09:40:19 -0400 Received: from [10.0.1.103] ([::ffff:68.106.115.242]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 06 Jun 2006 09:40:46 -0400 id 0158C10D.448585DE.000072D3 In-Reply-To: <4485315B.20900@ntt-at.com> References: <007501c68904$1ead34a0$2c0d0d0a@amer.cisco.com> <4485315B.20900@ntt-at.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1426B51F-EF8A-4BB0-BDB2-EC7D1268C058@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] [issue2] Is it allowed tospecifycivicand geospatialinfointo the query? Date: Tue, 6 Jun 2006 09:40:13 -0400 To: shida@ntt-at.com X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 6, 2006, at 3:40 AM, Shida Schubert wrote: > > I thought we wanted to eliminate as much user's involvement > as possible when making an emergency call, so I object returning > multiple URIs based on multiple location type if we anticipate any > user's interaction as a result of supporting this feature. That sounds ideal, though with all the talk about listing services, etc... I'm not sure that is a goal. Also, the two separate query solution proposed by Henning doesn't seem to solve the problem. The user could still get back two different PSAP URIs based on both geo and civic. > Now, on the other hand if the LOST server complies to requirement > Ma8 and returns only one primary URI with multiple alternate URIs > (possibly 2 from Geo resolution and 1 from Civic resolution if one > of the > URI from Civic resolution was picked as the primary URI), > I don't really see a problem with LOST server returning URIs based > on two different location types(civic & geo). This sounds more reasonable, and only possible with the single query solution. Well, it could be done with multiple queries, but that would mean matching transactions via IP addresses, which has the obvious NAT problem. > BTW did I see any post on this thread stating LOST server might > return an error when it does not support the location type? > I hope I am hallucinating because if that is the behavior > considered for LOST server, it should at least redirect to another > LOST server that can resolve the location type provided(Considering > UA can't provide any other location type it will not be able to make > an emergency call..). Some of the threads are hard for me to follow. But I would assume that any authoritative server that has to say "I don't know." would atleast return a default URI. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 06 12:02:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fne0H-0006vG-1g; Tue, 06 Jun 2006 12:02:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fne0F-0006tC-8M for ecrit@ietf.org; Tue, 06 Jun 2006 12:01:59 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fne0E-00026S-0l for ecrit@ietf.org; Tue, 06 Jun 2006 12:01:59 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 06 Jun 2006 09:01:55 -0700 X-IronPort-AV: i="4.05,214,1146466800"; d="scan'208"; a="1820264995:sNHT276312976" 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/8.12.11) with ESMTP id k56G1ttZ027475; Tue, 6 Jun 2006 09:01:55 -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 k56G1scN027325; Tue, 6 Jun 2006 09:01:54 -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.211); Tue, 6 Jun 2006 09:01:51 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Jun 2006 09:01:49 -0700 From: "Marc Linsner" To: Subject: RE: [Ecrit] [issue2] Is it allowed tospecifycivicand geospatialinfointo the query? Date: Tue, 6 Jun 2006 12:01:48 -0400 Message-ID: <007901c68982$850b4560$2c0d0d0a@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.2869 Thread-Index: AcaJOzkP+QeLLFAvTZGyY+jkolrrgQAKItSA In-Reply-To: <4485315B.20900@ntt-at.com> X-OriginalArrivalTime: 06 Jun 2006 16:01:50.0051 (UTC) FILETIME=[85393330:01C68982] DKIM-Signature: a=rsa-sha1; q=dns; l=26550; t=1149609715; x=1150473715; c=relaxed/simple; s=sjdkim8001; 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]=20[issue2]=20Is=20it=20allowed=09tospecifycivicand=09geo spatialinfointo=20the=20query?; X=v=3Dcisco.com=3B=20h=3DvDtJI3f0MrHHcf1xhy4jlH4sCxE=3D; b=Prasqv8MOBi4imENL6C2II11s18ROqDOHxv1ebLz+m5a6xzpc9DJAbIupC5QDxnqZZNTWbYU 9p0Dwk6bxxml+TfugGzKfyei5EPt4uBTmdy0/NQnmv6A5KuWWUAQzffE; 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: fc33afc280b74ce7916a8c9e6ab57db8 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 LoST administration authorities are NOT responsible for location determination. The parallel in the legacy environment never has been responsible for caller location, and I don't understand how they ever should/will be. To create a system that puts any amount of liability on the LoST administration wrt LoST client location determination seems like a bad design. If you expect the LoST service to choose a 'preferred' location, you are placing them in the location determination task. If a LoST client (seeker) submits two location representations and it is expected that the LoST service will determine which representation is preferred, this function puts liability on the LoST admin authorities. This cannot be allowed. It doesn't matter whether the two submitted locations describe the exact same square millimeter on the planet, it must be the seeker who determines which resolved URI to use for follow-on session initiation. It would be expected that the two resolutions in this ridiculous example are the same, hence an easy choice for the seeker to make. But, since it is completely possible in a 'I'm LoST, tell where I'm at' scenario to have two jurisdictionally unique locations (New York City & Seattle), requiring the LoST admin to figure out the 'preferred' location cannot be expected. IMO, the basis for this thread is the long standing debate on geo vs. civic. We (IETF) have support for both representations in all protocols to date and this is NOT an IETF decision, this is an end-user (caller and/or PSAP) decision, and this debate needs to happen elsewhere. Can we now conclude this topic with a resolution that a seeker submits a single location representation with each query? -Marc- > -----Original Message----- > From: Shida Schubert [mailto:shida@ntt-at.com] > Sent: Tuesday, June 06, 2006 3:40 AM > To: Marc Linsner > Cc: 'Andrew Newton'; ecrit@ietf.org > Subject: Re: [Ecrit] [issue2] Is it allowed tospecifycivicand > geospatialinfointo the query? > > > I thought we wanted to eliminate as much user's involvement > as possible when making an emergency call, so I object > returning multiple URIs based on multiple location type if we > anticipate any user's interaction as a result of supporting > this feature. > > Now, on the other hand if the LOST server complies to requirement > Ma8 and returns only one primary URI with multiple alternate > URIs (possibly 2 from Geo resolution and 1 from Civic > resolution if one of the URI from Civic resolution was picked > as the primary URI), I don't really see a problem with LOST > server returning URIs based on two different location > types(civic & geo). > > BTW did I see any post on this thread stating LOST server > might return an error when it does not support the location type? > I hope I am hallucinating because if that is the behavior > considered for LOST server, it should at least redirect to > another LOST server that can resolve the location type > provided(Considering UA can't provide any other location type > it will not be able to make an emergency call..). > > Regards > Shida > > Marc Linsner wrote: > > > > > >> As to the point that a human, in an emergency situation, at the > >> seeker is in a better position to make the correct judgement, I > >> dispute that. > >> > > > > And it's by magic that the LoST server can make this > decision? 'Hmm, > > your query has an east coast accent so it probably came > from New York, > > so that's the location I'll respond to and disregard the > Seattle location.' > > > > Most people will look at lat/long > > > >> coordinates and not have the faintest clue how accurate they are. > >> > > > > Most people utilize mapping software to assist interpreting > geo information. > > > > -Marc- > > > > If you plunk me down in the middle of Tokyo, I'd have > > > >> to do a coin toss to tell you which is more accurate, > civic or geo. > >> And what about cases were the seeker is a gateway? > >> > >> To be honest, whether the server would know better or the client > >> would know better is something I think none of us can answer with > >> certainty at the moment. I would just rather not create a > protocol > >> that precludes one or the other. > >> > >> -andy > >> > >> On Jun 5, 2006, at 8:11 PM, Henning Schulzrinne wrote: > >> > >> > >>> Yes, you could do that, but you now have to carry > possibly two error > >>> indications, have to worry about carrying two boundaries, > etc. Just > >>> made the protocol much messier, for both client and > server. It gets > >>> worse: in all likelihood, the server has to > >>> > >> recurse > >> > >>> or iterate differently for civic and geo coordinates, so > >>> > >> the server > >> > >>> has to wait until both results are in from upstream servers (or > >>> return just one result after a timeout). This all just seems > >>> pointlessly complex, given that the same result can be trivially > >>> achieved by splitting the query. > >>> > >>> On Jun 5, 2006, at 8:04 PM, Winterbottom, James wrote: > >>> > >>> > >>>> Why wouldn't the LoSt server simply treat each representation on > >>>> its own merits? You give me two locations you get back 2 > URIs, even > >>>> if they are the same. > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Marc Linsner [mailto:mlinsner@cisco.com] > >>>>> Sent: Tuesday, 6 June 2006 9:44 AM > >>>>> To: 'Roger Marshall'; 'Andrew Newton' > >>>>> Cc: ecrit@ietf.org > >>>>> Subject: RE: [Ecrit] [issue2] Is it allowed tospecifycivicand > >>>>> geospatialinfointo the query? > >>>>> > >>>>> Roger, > >>>>> > >>>>> I'm not arguing geo vs. civil. All I am trying to state is when > >>>>> > >>>> multiple > >>>> > >>>>> location representations are known for a LoST client, the LoST > >>>>> server/service should not be the one to determine which > >>>>> representation > >>>>> > >>>> is > >>>> > >>>>> best. > >>>>> > >>>>> Setup for failure example #1: A single LoST query > contains both a > >>>>> > >>>> civic > >>>> > >>>>> (123 > >>>>> Main St.) and a geo representation. All geocode > >>>>> > >> databases return > >> > >>>>> 456 > >>>>> Second > >>>>> St. for the geo. Which one should LoST prefer? > >>>>> > >>>>> Setup for failure example #2: A single LoST query > >>>>> > >> contains two civic > >> > >>>>> representations. One is in New York City and the other > >>>>> > >> in Seattle. > >> > >>>> Which > >>>> > >>>>> one should LoST prefer? > >>>>> > >>>>> IMO, each example should be (2) unique queries, one for each > >>>>> representation, and let the client deal with it. This decision > >>>>> needs to > >>>>> > >> be made as > >> > >>>> close > >>>> > >>>>> to > >>>>> a human as possible, I don't foresee any programmatic > >>>>> > >> solution. If > >> > >>>> the > >>>> > >>>>> client holds (2) location representations, the problem is > >>>>> > >> theirs and > >> > >>>> needs > >>>> > >>>>> to be resolved there. Once a PSAP call taker (a second > human) is > >>>>> involved, then the two humans can negotiate the issue. > >>>>> > >>>>> Too many variables to standardize a solution. > >>>>> > >>>>> -Marc- > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> Marc: > >>>>>> What is the scale of "accuracy" for a civic street address? > >>>>>> > >>>> 0%,100%? > >>>> > >>>>>> Just because both civic and geo are included, doesn't > mean one is > >>>>>> better. For example, it is obvious that lat/lon's have > >>>>>> measurement criteria whereas civic addresses don't, > since they're > >>>>>> either "stated" or "derived". > >>>>>> > >>>>>> Parcel-based GIS mapping systems exist today which describe a > >>>>>> location in terms of both. As a simple example, Google Earth > >>>>>> does this for you. > >>>>>> You specify 123 Main Street, Anytown, USA and once it > finds it, > >>>>>> it also provides a lat/lon. I admit that the there are > >>>>>> challenges with using both, but I expect that those > issues will > >>>>>> become fewer over time. > >>>>>> > >>>>>> Does there have to be a line in the sand as to whether a > >>>>>> particular location is known in terms of civic vs. geo and not > >>>>>> both? I don't think so. > >>>>>> > >>>>>> > >>>>>> Roger Marshall > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Marc Linsner [mailto:mlinsner@cisco.com] > >>>>>>> Sent: Monday, June 05, 2006 3:23 PM > >>>>>>> To: 'Andrew Newton' > >>>>>>> Cc: ecrit@ietf.org > >>>>>>> Subject: RE: [Ecrit] [issue2] Is it allowed to > specifycivicand > >>>>>>> geospatialinfointo the query? > >>>>>>> > >>>>>>> Andy, > >>>>>>> > >>>>>>> The problem is that the 'preferred' location is the accurate > >>>>>>> > >>>>>> one. No > >>>>>> > >>>>>>> LoST server/service will be able to determine which > one is most > >>>>>>> accurate. You may equate the same problem to the client, > >>>>>>> > >>>>>> but IMO, it's > >>>>>> > >>>>>>> better that the client make the decision since it's closer > >>>>>>> > >>>>>> to the human > >>>>>> > >>>>>>> that 'should' know. > >>>>>>> > >>>>>>> -Marc- > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Andrew Newton [mailto:andy@hxr.us] > >>>>>>>> Sent: Monday, June 05, 2006 5:58 PM > >>>>>>>> To: Marc Linsner > >>>>>>>> Cc: 'Hannes Tschofenig'; ecrit@ietf.org > >>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to > specify civicand > >>>>>>>> geospatialinfointo the query? > >>>>>>>> > >>>>>>>> I think we'd have a protocol more capable of adapting to > >>>>>>>> > >>>>>> unforeseen, > >>>>>> > >>>>>>>> real world issues if both were sent and the server had the > >>>>>>>> > >>>>>>> opportunity > >>>>>>> > >>>>>>>> to determine which type of location it preferred. I must > >>>>>>>> > >>>>>> admit that > >>>>>> > >>>>>>>> it seems a bit of a stretch, but I think it is just > as possible > >>>>>>>> > >>>> as > >>>> > >>>>>>>> Henning's idea that the client will have the same type of > >>>>>>>> > >>>>>>> notion. It > >>>>>>> > >>>>>>>> almost always seems to me that if ever there is a > >>>>>>>> > >> question about > >> > >>>>>>>> preference, it should fall to the LoST service operators and > >>>>>>>> > >>>> their > >>>> > >>>>>>>> jurisdictional considerations. > >>>>>>>> > >>>>>>>> It also seems to me that if a client or seeker does, in some > >>>>>>>> > >>>>>>> odd way, > >>>>>>> > >>>>>>>> have a notion of a preferred type of location when it > >>>>>>>> > >>>>>>> possesses both, > >>>>>>> > >>>>>>>> that it can always just send the query with only the type of > >>>>>>>> > >>>>>>> location > >>>>>>> > >>>>>>>> it prefers. For clients that don't have this strong notion, > >>>>>>>> > >>>>>>> send both > >>>>>>> > >>>>>>>> and see if the server has a preference. > >>>>>>>> > >>>>>>>> -andy > >>>>>>>> > >>>>>>>> > >>>>>>>> On Jun 5, 2006, at 5:39 PM, Marc Linsner wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>>> I agree, the LoST client submits one location at a time. > >>>>>>>>> > >>>>>>>> No decisions > >>>>>>>> > >>>>>>>>> made by LoST server/service. > >>>>>>>>> > >>>>>>>>> -Marc- > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>>>>>>> Sent: Monday, June 05, 2006 5:24 PM > >>>>>>>>>> To: Roger Marshall > >>>>>>>>>> Cc: ecrit@ietf.org > >>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify > >>>>>>>>>> > >>>> civicand > >>>> > >>>>>>>>>> geospatialinfointo the query? > >>>>>>>>>> > >>>>>>>>>> Hi Roger, > >>>>>>>>>> > >>>>>>>>>> Roger Marshall wrote: > >>>>>>>>>> > >>>>>>>>>>> Hannes: Thanks for clarifying. > >>>>>>>>>>> > >>>>>>>>>>> I think it's a bad idea to withold location information > >>>>>>>>>>> > >>>>>>>>>> from the LoST > >>>>>>>>>> > >>>>>>>>>>> server. > >>>>>>>>>>> > >>>>>>>>>>> To suggest that we restrict the client, allowing only one > >>>>>>>>>>> > >>>>>>>>>> to be sent, > >>>>>>>>>> > >>>>>>>>>>> sounds to me like we're placing a constraint on the > >>>>>>>>>>> > >>>>>>>>>> PIDF-LO, saying it > >>>>>>>>>> > >>>>>>>>>>> can't have both (assuming LoST reuses the PIDF-LO). I > >>>>>>>>>>> > >>>>>>>>>> don't think we > >>>>>>>>>> > >>>>>>>>>>> can get away with that. If the PIDF-LO has both, how is > >>>>>>>>>>> > >>>>>>>>>> it that we can > >>>>>>>>>> > >>>>>>>>>>> glibly strip one out? To do so would be unreasonable. > >>>>>>>>>>> > >>>>>>>>>> To clarify: > >>>>>>>>>> > >>>>>>>>>> * You can send as many queries as you want but not with > >>>>>>>>>> > >>>>>> the same > >>>>>> > >>>>>>>>>> message. Different location information => different query > >>>>>>>>>> > >>>>>>>>>> * We don't use a PIDF-LO in LoST. We use the raw location > >>>>>>>>>> > >>>> info. > >>>> > >>>>>>>>>>> Since the client can have both civic and geo in the > >>>>>>>>>>> > >>>>>>>> PIDF-LO, it can > >>>>>>>> > >>>>>>>>>>> also send both to the server. What am I missing? > >>>>>>>>>>> > >>>>>>>>>> None of the proposals ever used a PIDF-LO as input; > >>>>>>>>>> > >>>>>> just location > >>>>>> > >>>>>>>>>> info. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> It's the LoST server's job to pick one, not the client's. > >>>>>>>>>>> > >>>>>>>>>> At the PSAP and the emergency routing proxy I > agree with you. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> So, the requirement I would support is as follows: > >>>>>>>>>>> > >>>>>>>>>>> Rx' LoST client SHALL query with either civic or geo. > >>>>>>>>>>> > >>>>>>>>>> That's fine. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Ry' LoST client SHOULD query with *both* civic and geo. > >>>>>>>>>>> > >>>>>>>> When LoST > >>>>>>>> > >>>>>>>>>>> server receives both civic and geo, the server SHOULD try > >>>>>>>>>>> > >>>>>>>>>> to use the > >>>>>>>>>> > >>>>>>>>>>> geo first. The LoST server response SHALL indicate which > >>>>>>>>>>> > >>>>>>>> data was > >>>>>>>> > >>>>>>>>>>> used (either geo or civic). > >>>>>>>>>>> > >>>>>>>>>> I guess you will not support for this one based on the > >>>>>>>>>> > >>>>>>>> response I saw > >>>>>>>> > >>>>>>>>>> on the list so far. > >>>>>>>>>> > >>>>>>>>>> Ciao > >>>>>>>>>> Hannes > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> -roger. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>> From: Hannes Tschofenig > [mailto:Hannes.Tschofenig@gmx.net] > >>>>>>>>>>>> Sent: Monday, June 05, 2006 1:50 PM > >>>>>>>>>>>> To: Roger Marshall > >>>>>>>>>>>> Cc: Brian Rosen; ecrit@ietf.org > >>>>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify > >>>>>>>>>>>> > >>>>>>> civic and > >>>>>>> > >>>>>>>>>>>> geospatialinfointo the query? > >>>>>>>>>>>> > >>>>>>>>>>>> Hi Roger, > >>>>>>>>>>>> > >>>>>>>>>>>> I think the current suggestion is that the LoST client > >>>>>>>>>>>> > >>>>>>>> just picks > >>>>>>>> > >>>>>>>>>>>> whatever he wants and then uses the mapping protocol to > >>>>>>>>>>>> > >>>>>>>> trigger the > >>>>>>>> > >>>>>>>>>>>> resolution. > >>>>>>>>>>>> > >>>>>>>>>>>> Using geo and civic might be, from a certain > point of view, > >>>>>>>>>>>> > >>>>>>>>>> just be an > >>>>>>>>>> > >>>>>>>>>>>> optimization. The LoST client can always trigger separate > >>>>>>>>>>>> > >>>>>>>>>> queries with > >>>>>>>>>> > >>>>>>>>>>>> all the location info it has. > >>>>>>>>>>>> > >>>>>>>>>>>> Ciao > >>>>>>>>>>>> Hannes > >>>>>>>>>>>> > >>>>>>>>>>>> Roger Marshall wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> I don't disagree that we ask the LoST server to pick one > >>>>>>>>>>>>> > >>>> and > >>>> > >>>>>>>>>>>> use it. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> We need to be consistent though, and so therefore, I > >>>>>>>>>>>>> > >>>> propose > >>>> > >>>>>>>>>>>> that the > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> LoST server always picks the geo over the civic > >>>>>>>>>>>>> > >> and returns > >> > >>>>>>>>>>>> a flag in > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> the response stating that the geo was used to > >>>>>>>>>>>>> > >>>>>> perform mapping. > >>>>>> > >>>>>>>>>>>>> Roger. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>> From: Hannes Tschofenig > >>>>>>>>>>>>>> > >> [mailto:Hannes.Tschofenig@gmx.net] > >> > >>>>>>>>>>>>>> Sent: Monday, June 05, 2006 1:39 PM > >>>>>>>>>>>>>> To: Brian Rosen > >>>>>>>>>>>>>> Cc: ecrit@ietf.org > >>>>>>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify > >>>>>>>>>>>>>> > >>>>>>>> civic and > >>>>>>>> > >>>>>>>>>>>>>> geospatialinfointo the query? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> It seems that we closed this issue. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Everyone seems to be in favor for a civic OR > geospatial. > >>>>>>>>>>>>>> Extensions possible for future applications. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Ciao > >>>>>>>>>>>>>> Hannes > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Brian Rosen wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I think this is the issue. There is no guidance we > >>>>>>>>>>>>>>> > >>>>>>>> can give the > >>>>>>>> > >>>>>>>>>>>>>>> server to tell it how to resolve what to do when both > >>>>>>>>>>>>>>> > >>>>>>>>>>>> locations are > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>>>> valid but the URI for the geo does match the URI for > >>>>>>>>>>>>>>> > >>>>>>>> the civic. > >>>>>>>> > >>>>>>>>>>>>>>> This happens a lot when you are near > boundaries because > >>>>>>>>>>>>>>> > >>>> the > >>>> > >>>>>>>>>>>>>> precision > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> and accuracy of the two methods differ. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I think you pick ONE and use it. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Even if you send more than one along, the PSAP has to > >>>>>>>>>>>>>>> > >>>> know > >>>> > >>>>>>>>>>>> which one > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>>>> you used to route. It's going to continue to use that > >>>>>>>>>>>>>>> > >>>>>>>>>>>> until a human > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>>>> says otherwise. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Brian > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>>>>>>>>>>>>>> Sent: Monday, June 05, 2006 3:55 PM > >>>>>>>>>>>>>>> To: Andrew Newton > >>>>>>>>>>>>>>> Cc: ecrit@ietf.org > >>>>>>>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to > >>>>>>>>>>>>>>> > >>>>>>>> specify civic and > >>>>>>>> > >>>>>>>>>>>>>>> geospatialinfo into the query? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> At the PSAP, we have a human that can look at this > >>>>>>>>>>>>>>> > >>>>>>>>>> information and > >>>>>>>>>> > >>>>>>>>>>>>>>> make decisions (and maybe even ask if there's a > >>>>>>>>>>>>>>> > >>>>>>>>>> discrepancy). That > >>>>>>>>>> > >>>>>>>>>>>>>>> seems a stretch for the LoST server. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Andrew Newton wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Jun 5, 2006, at 2:53 PM, Henning > Schulzrinne wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> In all of these dual-information cases, I don't see > >>>>>>>>>>>>>>>>> > >>>>>>>>>> how anybody > >>>>>>>>>> > >>>>>>>>>>>>>>>>> except the seeker can make any determination > >>>>>>>>>>>>>>>>> > >>>>>> which type of > >>>>>> > >>>>>>>>>>>>>>>>> information is better, more accurate, more > >>>>>>>>>>>>>>>>> > >> recent, etc. > >> > >>>>>>>>>>>>>>>> Would we want the seeker to determine which > information > >>>>>>>>>>>>>>>> > >>>> it > >>>> > >>>>>>>>>>>> feels is > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>>>>> best to provide to the PSAP? I've always > >>>>>>>>>>>>>>>> > >> heard that the > >> > >>>>>>>>>>>>>> answer would be no: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> provide both to the PSAP. So why then would we not > >>>>>>>>>>>>>>>> > >>>>>>>>>>>> provide the same > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>>>>> information when determining which PSAP to contact? > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> -andy > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>>> Ecrit mailing list > >>>>>>>>>>>>>>> Ecrit@ietf.org > >>>>>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>>> Ecrit mailing list > >>>>>>>>>>>>>>> Ecrit@ietf.org > >>>>>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>> Ecrit mailing list > >>>>>>>>>>>>>> Ecrit@ietf.org > >>>>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Ecrit mailing list > >>>>>>>>>> Ecrit@ietf.org > >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Ecrit mailing list > >>>>>>>>> Ecrit@ietf.org > >>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Ecrit mailing list > >>>>>>> Ecrit@ietf.org > >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>> > >>>>>>> > >>>>> _______________________________________________ > >>>>> Ecrit mailing list > >>>>> Ecrit@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>> > >>>> > >> > --------------------------------------------------------------------- > >> > >>>> --------------------------- > >>>> This message is for the designated recipient only and > may contain > >>>> privileged, proprietary, or otherwise private information. > >>>> If you have received it in error, please notify the sender > >>>> immediately and delete the original. Any unauthorized > use of this > >>>> email is prohibited. > >>>> > >>>> > >> > --------------------------------------------------------------------- > >> > >>>> --------------------------- > >>>> [mf2] > >>>> > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>> > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 06 15:44:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnhTh-0007XW-PS; Tue, 06 Jun 2006 15:44:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnhTd-0007V6-EP for ecrit@ietf.org; Tue, 06 Jun 2006 15:44:33 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnhTc-0005D7-EH for ecrit@ietf.org; Tue, 06 Jun 2006 15:44:33 -0400 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.6.118]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k56JiXU23744; Tue, 6 Jun 2006 13:44:33 -0600 Message-ID: <4485DD38.3040005@ntt-at.com> Date: Tue, 06 Jun 2006 12:53:28 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Ecrit] [issue2] Is it allowed tospecifycivicand geospatialinfointo the query? References: <007901c68982$850b4560$2c0d0d0a@amer.cisco.com> In-Reply-To: <007901c68982$850b4560$2c0d0d0a@amer.cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a5dcb2bb18117d8df5b4813a4ce477ef Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I personally don't have any objection to Marc's resolution. Regards Shida Marc Linsner wrote: > The LoST administration authorities are NOT responsible for location > determination. The parallel in the legacy environment never has been > responsible for caller location, and I don't understand how they ever > should/will be. To create a system that puts any amount of liability on the > LoST administration wrt LoST client location determination seems like a bad > design. If you expect the LoST service to choose a 'preferred' location, > you are placing them in the location determination task. If a LoST client > (seeker) submits two location representations and it is expected that the > LoST service will determine which representation is preferred, this function > puts liability on the LoST admin authorities. This cannot be allowed. It > doesn't matter whether the two submitted locations describe the exact same > square millimeter on the planet, it must be the seeker who determines which > resolved URI to use for follow-on session initiation. It would be expected > that the two resolutions in this ridiculous example are the same, hence an > easy choice for the seeker to make. But, since it is completely possible in > a 'I'm LoST, tell where I'm at' scenario to have two jurisdictionally unique > locations (New York City & Seattle), requiring the LoST admin to figure out > the 'preferred' location cannot be expected. > > IMO, the basis for this thread is the long standing debate on geo vs. civic. > We (IETF) have support for both representations in all protocols to date and > this is NOT an IETF decision, this is an end-user (caller and/or PSAP) > decision, and this debate needs to happen elsewhere. > > Can we now conclude this topic with a resolution that a seeker submits a > single location representation with each query? > > -Marc- > > > >> -----Original Message----- >> From: Shida Schubert [mailto:shida@ntt-at.com] >> Sent: Tuesday, June 06, 2006 3:40 AM >> To: Marc Linsner >> Cc: 'Andrew Newton'; ecrit@ietf.org >> Subject: Re: [Ecrit] [issue2] Is it allowed tospecifycivicand >> geospatialinfointo the query? >> >> >> I thought we wanted to eliminate as much user's involvement >> as possible when making an emergency call, so I object >> returning multiple URIs based on multiple location type if we >> anticipate any user's interaction as a result of supporting >> this feature. >> >> Now, on the other hand if the LOST server complies to requirement >> Ma8 and returns only one primary URI with multiple alternate >> URIs (possibly 2 from Geo resolution and 1 from Civic >> resolution if one of the URI from Civic resolution was picked >> as the primary URI), I don't really see a problem with LOST >> server returning URIs based on two different location >> types(civic & geo). >> >> BTW did I see any post on this thread stating LOST server >> might return an error when it does not support the location type? >> I hope I am hallucinating because if that is the behavior >> considered for LOST server, it should at least redirect to >> another LOST server that can resolve the location type >> provided(Considering UA can't provide any other location type >> it will not be able to make an emergency call..). >> >> Regards >> Shida >> >> Marc Linsner wrote: >> >>> >>> >>> >>>> As to the point that a human, in an emergency situation, at the >>>> seeker is in a better position to make the correct judgement, I >>>> dispute that. >>>> >>>> >>> And it's by magic that the LoST server can make this >>> >> decision? 'Hmm, >> >>> your query has an east coast accent so it probably came >>> >> from New York, >> >>> so that's the location I'll respond to and disregard the >>> >> Seattle location.' >> >>> Most people will look at lat/long >>> >>> >>>> coordinates and not have the faintest clue how accurate they are. >>>> >>>> >>> Most people utilize mapping software to assist interpreting >>> >> geo information. >> >>> -Marc- >>> >>> If you plunk me down in the middle of Tokyo, I'd have >>> >>> >>>> to do a coin toss to tell you which is more accurate, >>>> >> civic or geo. >> >>>> And what about cases were the seeker is a gateway? >>>> >>>> To be honest, whether the server would know better or the client >>>> would know better is something I think none of us can answer with >>>> certainty at the moment. I would just rather not create a >>>> >> protocol >> >>>> that precludes one or the other. >>>> >>>> -andy >>>> >>>> On Jun 5, 2006, at 8:11 PM, Henning Schulzrinne wrote: >>>> >>>> >>>> >>>>> Yes, you could do that, but you now have to carry >>>>> >> possibly two error >> >>>>> indications, have to worry about carrying two boundaries, >>>>> >> etc. Just >> >>>>> made the protocol much messier, for both client and >>>>> >> server. It gets >> >>>>> worse: in all likelihood, the server has to >>>>> >>>>> >>>> recurse >>>> >>>> >>>>> or iterate differently for civic and geo coordinates, so >>>>> >>>>> >>>> the server >>>> >>>> >>>>> has to wait until both results are in from upstream servers (or >>>>> return just one result after a timeout). This all just seems >>>>> pointlessly complex, given that the same result can be trivially >>>>> achieved by splitting the query. >>>>> >>>>> On Jun 5, 2006, at 8:04 PM, Winterbottom, James wrote: >>>>> >>>>> >>>>> >>>>>> Why wouldn't the LoSt server simply treat each representation on >>>>>> its own merits? You give me two locations you get back 2 >>>>>> >> URIs, even >> >>>>>> if they are the same. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Marc Linsner [mailto:mlinsner@cisco.com] >>>>>>> Sent: Tuesday, 6 June 2006 9:44 AM >>>>>>> To: 'Roger Marshall'; 'Andrew Newton' >>>>>>> Cc: ecrit@ietf.org >>>>>>> Subject: RE: [Ecrit] [issue2] Is it allowed tospecifycivicand >>>>>>> geospatialinfointo the query? >>>>>>> >>>>>>> Roger, >>>>>>> >>>>>>> I'm not arguing geo vs. civil. All I am trying to state is when >>>>>>> >>>>>>> >>>>>> multiple >>>>>> >>>>>> >>>>>>> location representations are known for a LoST client, the LoST >>>>>>> server/service should not be the one to determine which >>>>>>> representation >>>>>>> >>>>>>> >>>>>> is >>>>>> >>>>>> >>>>>>> best. >>>>>>> >>>>>>> Setup for failure example #1: A single LoST query >>>>>>> >> contains both a >> >>>>>>> >>>>>>> >>>>>> civic >>>>>> >>>>>> >>>>>>> (123 >>>>>>> Main St.) and a geo representation. All geocode >>>>>>> >>>>>>> >>>> databases return >>>> >>>> >>>>>>> 456 >>>>>>> Second >>>>>>> St. for the geo. Which one should LoST prefer? >>>>>>> >>>>>>> Setup for failure example #2: A single LoST query >>>>>>> >>>>>>> >>>> contains two civic >>>> >>>> >>>>>>> representations. One is in New York City and the other >>>>>>> >>>>>>> >>>> in Seattle. >>>> >>>> >>>>>> Which >>>>>> >>>>>> >>>>>>> one should LoST prefer? >>>>>>> >>>>>>> IMO, each example should be (2) unique queries, one for each >>>>>>> representation, and let the client deal with it. This decision >>>>>>> needs to >>>>>>> >>>>>>> >>>> be made as >>>> >>>> >>>>>> close >>>>>> >>>>>> >>>>>>> to >>>>>>> a human as possible, I don't foresee any programmatic >>>>>>> >>>>>>> >>>> solution. If >>>> >>>> >>>>>> the >>>>>> >>>>>> >>>>>>> client holds (2) location representations, the problem is >>>>>>> >>>>>>> >>>> theirs and >>>> >>>> >>>>>> needs >>>>>> >>>>>> >>>>>>> to be resolved there. Once a PSAP call taker (a second >>>>>>> >> human) is >> >>>>>>> involved, then the two humans can negotiate the issue. >>>>>>> >>>>>>> Too many variables to standardize a solution. >>>>>>> >>>>>>> -Marc- >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Marc: >>>>>>>> What is the scale of "accuracy" for a civic street address? >>>>>>>> >>>>>>>> >>>>>> 0%,100%? >>>>>> >>>>>> >>>>>>>> Just because both civic and geo are included, doesn't >>>>>>>> >> mean one is >> >>>>>>>> better. For example, it is obvious that lat/lon's have >>>>>>>> measurement criteria whereas civic addresses don't, >>>>>>>> >> since they're >> >>>>>>>> either "stated" or "derived". >>>>>>>> >>>>>>>> Parcel-based GIS mapping systems exist today which describe a >>>>>>>> location in terms of both. As a simple example, Google Earth >>>>>>>> does this for you. >>>>>>>> You specify 123 Main Street, Anytown, USA and once it >>>>>>>> >> finds it, >> >>>>>>>> it also provides a lat/lon. I admit that the there are >>>>>>>> challenges with using both, but I expect that those >>>>>>>> >> issues will >> >>>>>>>> become fewer over time. >>>>>>>> >>>>>>>> Does there have to be a line in the sand as to whether a >>>>>>>> particular location is known in terms of civic vs. geo and not >>>>>>>> both? I don't think so. >>>>>>>> >>>>>>>> >>>>>>>> Roger Marshall >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Marc Linsner [mailto:mlinsner@cisco.com] >>>>>>>>> Sent: Monday, June 05, 2006 3:23 PM >>>>>>>>> To: 'Andrew Newton' >>>>>>>>> Cc: ecrit@ietf.org >>>>>>>>> Subject: RE: [Ecrit] [issue2] Is it allowed to >>>>>>>>> >> specifycivicand >> >>>>>>>>> geospatialinfointo the query? >>>>>>>>> >>>>>>>>> Andy, >>>>>>>>> >>>>>>>>> The problem is that the 'preferred' location is the accurate >>>>>>>>> >>>>>>>>> >>>>>>>> one. No >>>>>>>> >>>>>>>> >>>>>>>>> LoST server/service will be able to determine which >>>>>>>>> >> one is most >> >>>>>>>>> accurate. You may equate the same problem to the client, >>>>>>>>> >>>>>>>>> >>>>>>>> but IMO, it's >>>>>>>> >>>>>>>> >>>>>>>>> better that the client make the decision since it's closer >>>>>>>>> >>>>>>>>> >>>>>>>> to the human >>>>>>>> >>>>>>>> >>>>>>>>> that 'should' know. >>>>>>>>> >>>>>>>>> -Marc- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Andrew Newton [mailto:andy@hxr.us] >>>>>>>>>> Sent: Monday, June 05, 2006 5:58 PM >>>>>>>>>> To: Marc Linsner >>>>>>>>>> Cc: 'Hannes Tschofenig'; ecrit@ietf.org >>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to >>>>>>>>>> >> specify civicand >> >>>>>>>>>> geospatialinfointo the query? >>>>>>>>>> >>>>>>>>>> I think we'd have a protocol more capable of adapting to >>>>>>>>>> >>>>>>>>>> >>>>>>>> unforeseen, >>>>>>>> >>>>>>>> >>>>>>>>>> real world issues if both were sent and the server had the >>>>>>>>>> >>>>>>>>>> >>>>>>>>> opportunity >>>>>>>>> >>>>>>>>> >>>>>>>>>> to determine which type of location it preferred. I must >>>>>>>>>> >>>>>>>>>> >>>>>>>> admit that >>>>>>>> >>>>>>>> >>>>>>>>>> it seems a bit of a stretch, but I think it is just >>>>>>>>>> >> as possible >> >>>>>>>>>> >>>>>>>>>> >>>>>> as >>>>>> >>>>>> >>>>>>>>>> Henning's idea that the client will have the same type of >>>>>>>>>> >>>>>>>>>> >>>>>>>>> notion. It >>>>>>>>> >>>>>>>>> >>>>>>>>>> almost always seems to me that if ever there is a >>>>>>>>>> >>>>>>>>>> >>>> question about >>>> >>>> >>>>>>>>>> preference, it should fall to the LoST service operators and >>>>>>>>>> >>>>>>>>>> >>>>>> their >>>>>> >>>>>> >>>>>>>>>> jurisdictional considerations. >>>>>>>>>> >>>>>>>>>> It also seems to me that if a client or seeker does, in some >>>>>>>>>> >>>>>>>>>> >>>>>>>>> odd way, >>>>>>>>> >>>>>>>>> >>>>>>>>>> have a notion of a preferred type of location when it >>>>>>>>>> >>>>>>>>>> >>>>>>>>> possesses both, >>>>>>>>> >>>>>>>>> >>>>>>>>>> that it can always just send the query with only the type of >>>>>>>>>> >>>>>>>>>> >>>>>>>>> location >>>>>>>>> >>>>>>>>> >>>>>>>>>> it prefers. For clients that don't have this strong notion, >>>>>>>>>> >>>>>>>>>> >>>>>>>>> send both >>>>>>>>> >>>>>>>>> >>>>>>>>>> and see if the server has a preference. >>>>>>>>>> >>>>>>>>>> -andy >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Jun 5, 2006, at 5:39 PM, Marc Linsner wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I agree, the LoST client submits one location at a time. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> No decisions >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> made by LoST server/service. >>>>>>>>>>> >>>>>>>>>>> -Marc- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>>>>> Sent: Monday, June 05, 2006 5:24 PM >>>>>>>>>>>> To: Roger Marshall >>>>>>>>>>>> Cc: ecrit@ietf.org >>>>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> civicand >>>>>> >>>>>> >>>>>>>>>>>> geospatialinfointo the query? >>>>>>>>>>>> >>>>>>>>>>>> Hi Roger, >>>>>>>>>>>> >>>>>>>>>>>> Roger Marshall wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Hannes: Thanks for clarifying. >>>>>>>>>>>>> >>>>>>>>>>>>> I think it's a bad idea to withold location information >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> from the LoST >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> server. >>>>>>>>>>>>> >>>>>>>>>>>>> To suggest that we restrict the client, allowing only one >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> to be sent, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> sounds to me like we're placing a constraint on the >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> PIDF-LO, saying it >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> can't have both (assuming LoST reuses the PIDF-LO). I >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> don't think we >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> can get away with that. If the PIDF-LO has both, how is >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> it that we can >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> glibly strip one out? To do so would be unreasonable. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> To clarify: >>>>>>>>>>>> >>>>>>>>>>>> * You can send as many queries as you want but not with >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> the same >>>>>>>> >>>>>>>> >>>>>>>>>>>> message. Different location information => different query >>>>>>>>>>>> >>>>>>>>>>>> * We don't use a PIDF-LO in LoST. We use the raw location >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> info. >>>>>> >>>>>> >>>>>>>>>>>>> Since the client can have both civic and geo in the >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> PIDF-LO, it can >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> also send both to the server. What am I missing? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> None of the proposals ever used a PIDF-LO as input; >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> just location >>>>>>>> >>>>>>>> >>>>>>>>>>>> info. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> It's the LoST server's job to pick one, not the client's. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> At the PSAP and the emergency routing proxy I >>>>>>>>>>>> >> agree with you. >> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> So, the requirement I would support is as follows: >>>>>>>>>>>>> >>>>>>>>>>>>> Rx' LoST client SHALL query with either civic or geo. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> That's fine. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Ry' LoST client SHOULD query with *both* civic and geo. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> When LoST >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> server receives both civic and geo, the server SHOULD try >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> to use the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> geo first. The LoST server response SHALL indicate which >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> data was >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> used (either geo or civic). >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> I guess you will not support for this one based on the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> response I saw >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> on the list so far. >>>>>>>>>>>> >>>>>>>>>>>> Ciao >>>>>>>>>>>> Hannes >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> -roger. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Hannes Tschofenig >>>>>>>>>>>>>> >> [mailto:Hannes.Tschofenig@gmx.net] >> >>>>>>>>>>>>>> Sent: Monday, June 05, 2006 1:50 PM >>>>>>>>>>>>>> To: Roger Marshall >>>>>>>>>>>>>> Cc: Brian Rosen; ecrit@ietf.org >>>>>>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>> civic and >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>> geospatialinfointo the query? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Roger, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think the current suggestion is that the LoST client >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> just picks >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> whatever he wants and then uses the mapping protocol to >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> trigger the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> resolution. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Using geo and civic might be, from a certain >>>>>>>>>>>>>> >> point of view, >> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> just be an >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> optimization. The LoST client can always trigger separate >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> queries with >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> all the location info it has. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ciao >>>>>>>>>>>>>> Hannes >>>>>>>>>>>>>> >>>>>>>>>>>>>> Roger Marshall wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I don't disagree that we ask the LoST server to pick one >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>> and >>>>>> >>>>>> >>>>>>>>>>>>>> use it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> We need to be consistent though, and so therefore, I >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>> propose >>>>>> >>>>>> >>>>>>>>>>>>>> that the >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> LoST server always picks the geo over the civic >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>> and returns >>>> >>>> >>>>>>>>>>>>>> a flag in >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> the response stating that the geo was used to >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> perform mapping. >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> Roger. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: Hannes Tschofenig >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>> [mailto:Hannes.Tschofenig@gmx.net] >>>> >>>> >>>>>>>>>>>>>>>> Sent: Monday, June 05, 2006 1:39 PM >>>>>>>>>>>>>>>> To: Brian Rosen >>>>>>>>>>>>>>>> Cc: ecrit@ietf.org >>>>>>>>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> civic and >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> geospatialinfointo the query? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It seems that we closed this issue. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Everyone seems to be in favor for a civic OR >>>>>>>>>>>>>>>> >> geospatial. >> >>>>>>>>>>>>>>>> Extensions possible for future applications. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ciao >>>>>>>>>>>>>>>> Hannes >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Brian Rosen wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I think this is the issue. There is no guidance we >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> can give the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>> server to tell it how to resolve what to do when both >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> locations are >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> valid but the URI for the geo does match the URI for >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> the civic. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>> This happens a lot when you are near >>>>>>>>>>>>>>>>> >> boundaries because >> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>> the >>>>>> >>>>>> >>>>>>>>>>>>>>>> precision >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> and accuracy of the two methods differ. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I think you pick ONE and use it. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Even if you send more than one along, the PSAP has to >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>> know >>>>>> >>>>>> >>>>>>>>>>>>>> which one >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> you used to route. It's going to continue to use that >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> until a human >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> says otherwise. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Brian >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>>>>>>>>>>>>>> Sent: Monday, June 05, 2006 3:55 PM >>>>>>>>>>>>>>>>> To: Andrew Newton >>>>>>>>>>>>>>>>> Cc: ecrit@ietf.org >>>>>>>>>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> specify civic and >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>> geospatialinfo into the query? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> At the PSAP, we have a human that can look at this >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> information and >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>> make decisions (and maybe even ask if there's a >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> discrepancy). That >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>> seems a stretch for the LoST server. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Andrew Newton wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Jun 5, 2006, at 2:53 PM, Henning >>>>>>>>>>>>>>>>>> >> Schulzrinne wrote: >> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> In all of these dual-information cases, I don't see >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> how anybody >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> except the seeker can make any determination >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>> which type of >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>> information is better, more accurate, more >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>> recent, etc. >>>> >>>> >>>>>>>>>>>>>>>>>> Would we want the seeker to determine which >>>>>>>>>>>>>>>>>> >> information >> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>> it >>>>>> >>>>>> >>>>>>>>>>>>>> feels is >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> best to provide to the PSAP? I've always >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>> heard that the >>>> >>>> >>>>>>>>>>>>>>>> answer would be no: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> provide both to the PSAP. So why then would we not >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> provide the same >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> information when determining which PSAP to contact? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -andy >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> Ecrit mailing list >>>>>>>>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> Ecrit mailing list >>>>>>>>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> Ecrit mailing list >>>>>>>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Ecrit mailing list >>>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Ecrit mailing list >>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Ecrit mailing list >>>>>>>>> Ecrit@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> >>>>>> >>>>>> >> --------------------------------------------------------------------- >> >>>> >>>> >>>>>> --------------------------- >>>>>> This message is for the designated recipient only and >>>>>> >> may contain >> >>>>>> privileged, proprietary, or otherwise private information. >>>>>> If you have received it in error, please notify the sender >>>>>> immediately and delete the original. Any unauthorized >>>>>> >> use of this >> >>>>>> email is prohibited. >>>>>> >>>>>> >>>>>> >> --------------------------------------------------------------------- >> >>>> >>>> >>>>>> --------------------------- >>>>>> [mf2] >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >>> >>> > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 06 15:56:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnhfJ-00046r-LL; Tue, 06 Jun 2006 15:56:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnhfF-000454-5j for ecrit@ietf.org; Tue, 06 Jun 2006 15:56:33 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnhfD-0007tI-OP for ecrit@ietf.org; Tue, 06 Jun 2006 15:56:33 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1FnhaM0lDA-0001Ws; Tue, 06 Jun 2006 21:51:30 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Tue, 06 Jun 2006 19:47:16 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1149623236.47.0.303260595032.issue3@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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ecrit] [issue3] List all Services Functionality 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: TENTATIVE SUMMARY: The functionality of a service listing will be supported by returning the c= hild=20 elements of a given URN. __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 06 15:58:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnhgn-0004PE-05; Tue, 06 Jun 2006 15:58:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnhgm-0004P9-Go for ecrit@ietf.org; Tue, 06 Jun 2006 15:58:08 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnhgl-00088t-5J for ecrit@ietf.org; Tue, 06 Jun 2006 15:58:08 -0400 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.6.118]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k56Jvi427019; Tue, 6 Jun 2006 13:57:44 -0600 Message-ID: <4485E050.3050806@ntt-at.com> Date: Tue, 06 Jun 2006 13:06:40 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Ecrit] [issue1] Do we need a default service URN for the LoS Tquery? References: <475FF955A05DD411980D00508B6D5FB00C2908E5@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C2908E5@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Keith; I think we are debating over having no Service URN at all here. I think there was some discussion on what if subtype was requested for "sos" urn which is not supported by the jurisdiction and I think most of the people agreed that it should provide a URI based on the default(parent URN type > urn:sos). Regards Shida Drage, Keith (Keith) wrote: > I still see this capability as a distinction between emergency calls and other geographically provided services. > > If I have a "sos" urn with a subtype, then I want the default emergency operator for my local area, if the subtype cannot be matched. > > If I have a "food" urn with a subtype of "pizza", then I don't want the default food service if the subtype cannot be matched. More specifically, for local support helplines, if I dial the suicide advice helpline, then I want to reach that helpline with its guarantees of anonymity, no matter where it is provided, rather than provided with a more local general support line. > > regards > > Keith > > >> -----Original Message----- >> From: Shida Schubert [mailto:shida@ntt-at.com] >> Sent: 05 June 2006 23:56 >> To: Henning Schulzrinne >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] [issue1] Do we need a default service >> URN for the LoSTquery? >> >> >> >> I strongly agree with Henning here for the exact reason >> Henning expressed. >> >> Default service, from the importance will likely be the emergency >> service, and this will lead to unintended emergency call if we >> support this default service. >> >> It may be a possibility that requesting without the service identifier >> will result with a response containing list of services the >> LOST server >> supports. >> >> Regards >> Shida >> >> Henning Schulzrinne wrote: >> >>> Roger Marshall wrote: >>> >>>> The LoST server must support a default, so that if it >>>> >> receives a query >> >>>> which contains location, but no emergency service >>>> >> identifier, then it >> >>>> can still provide an answer. >>>> >>> I don't see that as necessary or helpful. Why can't the >>> >> client always >> >>> insert a service URN? This seems a trivial thing to do for a client >>> and avoids problems of trying to guess what the client >>> >> really wanted. >> >>> (Remember that LoST may well be used for non-emergency >>> >> services, too.) >> >>> I don't think "you know what I mean" protocol features are >>> >> a good way >> >>> forward. >>> >>> >>> >>>> The worst case of having this happen is that clients always get an >>>> emergency context associated, location-relevant PSAP URI >>>> >> when they query >> >>>> with location only. The server would then return this >>>> >> "default" ESI so >> >>>> that the client would have it from then on. >>>> >>>> I think the LoST protocol requirements for query including >>>> >> an ESI is a >> >>>> SHOULD, and a response msg. to include an ESI is a MUST. >>>> >>>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 06 15:58:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnhhB-0004V7-7I; Tue, 06 Jun 2006 15:58:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnhhA-0004V2-EL for ecrit@ietf.org; Tue, 06 Jun 2006 15:58:32 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnhh9-0008Bo-4Z for ecrit@ietf.org; Tue, 06 Jun 2006 15:58:32 -0400 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.6.118]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k56JwVN27288; Tue, 6 Jun 2006 13:58:31 -0600 Message-ID: <4485E07F.7040504@ntt-at.com> Date: Tue, 06 Jun 2006 13:07:27 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] [issue2] Is it allowed tospecifycivicand geospatialinfointo the query? References: <007501c68904$1ead34a0$2c0d0d0a@amer.cisco.com> <4485315B.20900@ntt-at.com> <1426B51F-EF8A-4BB0-BDB2-EC7D1268C058@hxr.us> In-Reply-To: <1426B51F-EF8A-4BB0-BDB2-EC7D1268C058@hxr.us> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Andrew; comments inline. Andrew Newton wrote: > > On Jun 6, 2006, at 3:40 AM, Shida Schubert wrote: > >> >> I thought we wanted to eliminate as much user's involvement >> as possible when making an emergency call, so I object returning >> multiple URIs based on multiple location type if we anticipate any >> user's interaction as a result of supporting this feature. > > That sounds ideal, though with all the talk about listing services, > etc... I'm not sure that is a goal. > I thought getting a list would be a completely different query distinct from "get me a URI for this service X for this location Y". > Also, the two separate query solution proposed by Henning doesn't seem > to solve the problem. The user could still get back two different PSAP > URIs based on both geo and civic. Agree. > >> Now, on the other hand if the LOST server complies to requirement >> Ma8 and returns only one primary URI with multiple alternate URIs >> (possibly 2 from Geo resolution and 1 from Civic resolution if one of >> the >> URI from Civic resolution was picked as the primary URI), >> I don't really see a problem with LOST server returning URIs based >> on two different location types(civic & geo). > > This sounds more reasonable, and only possible with the single query > solution. Well, it could be done with multiple queries, but that would > mean matching transactions via IP addresses, which has the obvious NAT > problem. Agree. > >> BTW did I see any post on this thread stating LOST server might >> return an error when it does not support the location type? >> I hope I am hallucinating because if that is the behavior >> considered for LOST server, it should at least redirect to another >> LOST server that can resolve the location type provided(Considering >> UA can't provide any other location type it will not be able to make >> an emergency call..). > > Some of the threads are hard for me to follow. But I would assume that > any authoritative server that has to say "I don't know." would atleast > return a default URI. That's good to hear, especially when it's coming from one of the co-author of the draft. Thanks Shida > > -andy > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 06 16:05:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnhnc-0005mU-0F; Tue, 06 Jun 2006 16:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnhnZ-0005kU-77 for ecrit@ietf.org; Tue, 06 Jun 2006 16:05:09 -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 1FnhnX-0000pV-OY for ecrit@ietf.org; Tue, 06 Jun 2006 16:05:09 -0400 Received: (qmail invoked by alias); 06 Jun 2006 20:05:05 -0000 Received: from p549872D5.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.114.213] by mail.gmx.net (mp019) with SMTP; 06 Jun 2006 22:05:05 +0200 X-Authenticated: #29516787 Message-ID: <4485DFEE.9040206@gmx.net> Date: Tue, 06 Jun 2006 22:05:02 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Thomson, Martin" Subject: Re: [Ecrit] [issue4] Service URN in Response Message References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Martin, thanks for your input. I think the important issue here is that future services are defined in such a way that the "urn:service:x" == "urn:service:x.y" equation produces something reasonable. I suspect that this will at the end be the quintessence of the problem. Since this is difficult to solve (in general) we can do the following. Assume that the query is for "urn:service:x.y". * If the semantic of the service supports the "urn:service:x" == "urn:service:x.y" semantic then we apply Ted's approach. * If the semantic of the service supports the "urn:service:x" == "urn:service:x.y" semantic then an error message is returned "service not available". Ted's approach: Populate "urn:service:x"'s LoST data with the same data as "urn:service:x.y" Does this sound like a reasonable compromise? Ciao Hannes Thomson, Martin wrote: > I agree, we need to be clearer about what the LoST server is doing. > > I propose that it be possible to request for "urn:service:x.y.z" and get a result for either "urn:service:x.y" or "urn:service:x". That is what the original text said. I think we can be clearer and say that you should never get "urn:service:x" unless your request started with "urn:service:x" and you can never get "urn:service:x.y" if you asked for "urn:service:x". That is, the server can go up the tree, but never sideways or down. > > (The fact that "urn:service:x" == "urn:service:x.y" is something I don't care about; that's jurisdictional specific and can be solved with server configuration. This shouldn't be confused with the fallback option.) > > On parameters, Brian had it right. If this fallback occurs, make sure the client knows. A "strict" parameter isn't necessary, providing this behaviour is clear. > > >>-----Original Message----- >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>Sent: Tuesday, 6 June 2006 7:25 AM >>To: Hannes Tschofenig >>Cc: ecrit@ietf.org >>Subject: Re: [Ecrit] [issue4] Service URN in Response Message >> >>I'd like to better understand the model that people have in mind, where >>this condition would actually occur and where this information would >>actually be useful to the querier. (I don't think the querier needs to >>know which emergency services happen to all land on the same PSAP in a >>particular area.) >> >> >>>>Thus, I think this is purely a server configuration issue where the >>>>server database is set up to return a default value for unknown >>>>emergency services. This seems to be the case in practice today: even >>>>in places where there are separate numbers for various services, if >>>>you don't know whom to call for a "non-standard" emergency, you'd >>>>probably call the police. >>> >>>With your description it would not make sense to return the service URN >>>in the response message if we assume that the querier does not care >>>about this aspect. Would this be OK for you? >>> >>> >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit > > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 06 16:13:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnhvQ-0007q1-W3; Tue, 06 Jun 2006 16:13:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnhvQ-0007nr-6N for ecrit@ietf.org; Tue, 06 Jun 2006 16:13:16 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnhvO-000203-RA for ecrit@ietf.org; Tue, 06 Jun 2006 16:13:16 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML2ov-1FnhvO0gZb-0002dD; Tue, 06 Jun 2006 22:13:14 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Tue, 06 Jun 2006 20:09:00 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1149624540.36.0.543230829089.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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ecrit] [issue5] PSAP Boundary Hint 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: TENTATIVE SUMMARY:=20 QUESTION:=20 Should the LoST client indicate whether it wants to have the PSAP boundary = as=20 hint included in the response message? ANSWER: It is not seen as a hudge overhead to always return the hint.=20 QUESTION:=20 How should the civic PSAP boundary look like?=20 ANSWER:=20 A civic address information object that contains a subregion. ---------- status: unread -> chatting __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 06 16:18:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fni0Y-0000ii-LJ; Tue, 06 Jun 2006 16:18:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fni0X-0000ia-9f for ecrit@ietf.org; Tue, 06 Jun 2006 16:18:33 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fni0V-0002RM-Vg for ecrit@ietf.org; Tue, 06 Jun 2006 16:18:33 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 06 Jun 2006 13:18:32 -0700 X-IronPort-AV: i="4.05,214,1146466800"; d="scan'208"; a="1820486927:sNHT36161424" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k56KIVg5025330; Tue, 6 Jun 2006 13:18:31 -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 k56KIUA0012384; Tue, 6 Jun 2006 13:18:31 -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.211); Tue, 6 Jun 2006 13:18:28 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Jun 2006 13:18:28 -0700 From: "Marc Linsner" To: , "'Andrew Newton'" Subject: RE: [Ecrit] [issue2] Is it allowed tospecifycivicand geospatialinfointo the query? Date: Tue, 6 Jun 2006 16:18:26 -0400 Message-ID: <012f01c689a6$5f11b410$2c0d0d0a@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.2869 Thread-Index: AcaJo53+EsZlHD1vTcCLXFZQalabaQAAhPcQ In-Reply-To: <4485E07F.7040504@ntt-at.com> X-OriginalArrivalTime: 06 Jun 2006 20:18:28.0253 (UTC) FILETIME=[5F445CD0:01C689A6] DKIM-Signature: a=rsa-sha1; q=dns; l=1029; t=1149625111; x=1150489111; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:RE=3A=20[Ecrit]=20[issue2]=20Is=20it=20allowed=09tospecifycivicand=09geo spatialinfointo=20the=20query?; X=v=3Dcisco.com=3B=20h=3DIuIlr+wYmdkMKMoQlnykM0RmKyI=3D; b=UH83dD/58GS1Jva11fGqmSvrsuCjUn8CJHrpF71PL9xgzBWRmE3xZEgQ+kcoVx9VLks+6GQI vRExqP4P4aF/94J4OykRAvRLeEJ42UeLi2K0eABK0cK7zP6TPAwaxhLE; Authentication-Results: sj-dkim-1.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org snip..................................... > > > >> Now, on the other hand if the LOST server complies to requirement > >> Ma8 and returns only one primary URI with multiple alternate URIs > >> (possibly 2 from Geo resolution and 1 from Civic > resolution if one of > >> the URI from Civic resolution was picked as the primary > URI), I don't > >> really see a problem with LOST server returning URIs based on two > >> different location types(civic & geo). > > > > This sounds more reasonable, and only possible with the > single query > > solution. Well, it could be done with multiple queries, but > that would > > mean matching transactions via IP addresses, which has the > obvious NAT > > problem. > Agree. > > snip............................. Requirement Ma8 talks about returning multiple uri types (sip, im, email, etc.) all for the SAME location representation. Ma8 does NOT deal with resolving multiple location representations that are sent within the same query. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 06 16:27:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fni8v-0005jM-0e; Tue, 06 Jun 2006 16:27:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fni8u-0005jH-Lg for ecrit@ietf.org; Tue, 06 Jun 2006 16:27:12 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fni8t-0002mg-93 for ecrit@ietf.org; Tue, 06 Jun 2006 16:27:12 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu10) with ESMTP (Nemesis), id 0ML31I-1Fni8s2uaN-0007Wk; Tue, 06 Jun 2006 22:27:10 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Tue, 06 Jun 2006 20:22:56 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1149625376.92.0.889096320727.issue7@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: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ecrit] [issue7] Adding Additional Info to LoST Response 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: TENTATIVE SUMMARY: No big discussion about this subject. Martin reminded to think about additi= onal=20 protocol complexity. Henning pointed to the usefulness of an attribute that=20 indicates to express whether location info is needed for a specific service=20 identifier. ---------- status: unread -> chatting __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 06 16:28:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fni9u-0006Gr-D9; Tue, 06 Jun 2006 16:28:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fni9u-0006Gm-4K for ecrit@ietf.org; Tue, 06 Jun 2006 16:28:14 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fni9r-0002ox-NV for ecrit@ietf.org; Tue, 06 Jun 2006 16:28:14 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu10) with ESMTP (Nemesis), id 0ML31I-1Fni9r1S2e-0007W8; Tue, 06 Jun 2006 22:28:11 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Tue, 06 Jun 2006 20:23:57 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1149625437.54.0.0288341032573.issue7@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: d17f825e43c9aed4fd65b7edddddec89 Subject: [Ecrit] [issue7] Adding Additional Info to LoST Response 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: TENTATIVE SUMMARY: A dial string is included in the response message. __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 06 16:28:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FniAb-0006Oi-MD; Tue, 06 Jun 2006 16:28:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FniAa-0006Od-SG for ecrit@ietf.org; Tue, 06 Jun 2006 16:28:56 -0400 Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FniAZ-0002r0-Fb for ecrit@ietf.org; Tue, 06 Jun 2006 16:28:56 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu9) with ESMTP (Nemesis), id 0ML2xA-1FniAY4307-0005e2; Tue, 06 Jun 2006 22:28:55 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Tue, 06 Jun 2006 20:24:41 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1149625481.17.0.517736938178.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: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ecrit] [issue8] Dial Strings 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: TENTATIVE SUMMARY: A dial string is included in the response message. ---------- status: unread -> chatting __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 06 16:47:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FniSk-00037I-I3; Tue, 06 Jun 2006 16:47:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FniSj-00036c-8t for ecrit@ietf.org; Tue, 06 Jun 2006 16:47: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 1FnhWa-0005e4-Cl for ecrit@ietf.org; Tue, 06 Jun 2006 15:47:36 -0400 Received: from moutng.kundenserver.de ([212.227.126.187]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FnhSC-0001HH-WB for ecrit@ietf.org; Tue, 06 Jun 2006 15:43:06 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML2ov-1FnhSB3Lnd-0002jW; Tue, 06 Jun 2006 21:43:04 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Tue, 06 Jun 2006 19:38:50 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1149622730.04.0.0711041106661.issue1@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de login:518a04bce8f5fdb19ebc1cc661140948 X-Spam-Score: -2.6 (--) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Ecrit] [issue1] Do we need a default service URN for the LoST query? 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: TENTATIVE SUMMARY: The LoST query MUST carry a service identifier.=20 A default service is therefore NOT needed. __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 06 17:02:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnihW-0005O6-62; Tue, 06 Jun 2006 17:02:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnihU-0005O0-4L for ecrit@ietf.org; Tue, 06 Jun 2006 17:02:56 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnihR-0007qR-Tg for ecrit@ietf.org; Tue, 06 Jun 2006 17:02:56 -0400 Received: from [160.39.251.236] (dyn-160-39-251-236.dyn.columbia.edu [160.39.251.236]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k56L2gPs019374 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 6 Jun 2006 17:02:43 -0400 (EDT) In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C2908E5@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB00C2908E5@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] [issue1] Do we need a default service URN for the LoS Tquery? Date: Tue, 6 Jun 2006 10:03:07 -0400 To: "Drage, Keith (Keith)" X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org As you indicate, the desired behavior depends strongly on the service and maybe even on local customs and regulations. In this particular case, it seems trivial for the servers to be configured to do the right thing, i.e., either return an error or return a common URL for all services ("wildcard"). On Jun 6, 2006, at 8:14 AM, Drage, Keith (Keith) wrote: > I still see this capability as a distinction between emergency > calls and other geographically provided services. > > If I have a "sos" urn with a subtype, then I want the default > emergency operator for my local area, if the subtype cannot be > matched. > > If I have a "food" urn with a subtype of "pizza", then I don't want > the default food service if the subtype cannot be matched. More > specifically, for local support helplines, if I dial the suicide > advice helpline, then I want to reach that helpline with its > guarantees of anonymity, no matter where it is provided, rather > than provided with a more local general support line. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 06 17:05:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnikD-0006aJ-Sw; Tue, 06 Jun 2006 17:05:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnikC-0006Yz-Hq for ecrit@ietf.org; Tue, 06 Jun 2006 17:05:44 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnik9-0008C5-54 for ecrit@ietf.org; Tue, 06 Jun 2006 17:05:44 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1Fnik80elo-0000rh; Tue, 06 Jun 2006 23:05:40 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Tue, 06 Jun 2006 21:01:26 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1149627686.3.0.0391560947404.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: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Ecrit] [issue2] Is it allowed to specify civic and geospatial info into the query? 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: TENTATIVE SUMMARY: I think the long discussion did not lead to a conclusion.=20 Here is the current discussion status:=20 * Either civic OR geospatial in a LoST query=20 Marc, Henning, Shida * Both civic AND geospatial possible in a LoST query=20 Roger, Martin, Andy,=20 These folks don't seem to take a position: James W., John Hearty, Jean-Francois, Brian Looks like a hard issue to resolve. If someone has suggestions how we can b= ring=20 a few facts into the discussion. __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 06 17:12:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FniqT-0007Hc-3j; Tue, 06 Jun 2006 17:12:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FniqR-0007CM-Ai for ecrit@ietf.org; Tue, 06 Jun 2006 17:12:11 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FniqQ-000118-0V for ecrit@ietf.org; Tue, 06 Jun 2006 17:12:11 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 06 Jun 2006 14:12:10 -0700 X-IronPort-AV: i="4.05,214,1146466800"; d="scan'208"; a="1820521262:sNHT31475020" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k56LC9Ki003937; Tue, 6 Jun 2006 14:12:09 -0700 Received: from [68.49.184.222] (rtp-vpn3-88.cisco.com [10.82.216.88]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k56LC8ku002937; Tue, 6 Jun 2006 17:12:08 -0400 (EDT) In-Reply-To: <1149627686.3.0.0391560947404.issue2@http://www.tschofenig.priv.at> References: <1149627686.3.0.0391560947404.issue2@http://www.tschofenig.priv.at> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <36aab5b47e8c99105504bb621915ceaa@cisco.com> Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatial info into the query? Date: Tue, 6 Jun 2006 17:12:07 -0400 To: LoST Issue Tracker X-Mailer: Apple Mail (2.624) DKIM-Signature: a=rsa-sha1; q=dns; l=1721; t=1149628329; x=1150492329; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jschnizl@cisco.com; z=From:John=20Schnizlein=20 |Subject:Re=3A=20[Ecrit]=20[issue2]=20Is=20it=20allowed=20to=20specify=20civic=20 and=20geospatial=20info=20into=20the=20query?; X=v=3Dcisco.com=3B=20h=3D3X9pBK1vGn3jOxyYpUqjEzbkfkQ=3D; b=mMOC2hieT2QtqhiHt6EpQWcs8loMR0AIl+xz/dI1E8aiC+bvc0++WRKI/swgFFPpCjqdoGQ5 4WUARrmu6pLAUd32Wg2zXGnS69/2fiXY9DzalLlLSArjXuQVHXFx9aBG; Authentication-Results: sj-dkim-2.cisco.com; header.From=jschnizl@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 That both civic and geospatial are possible in a LoST query is perfectly compatible with either one or the other is a LoST query. The simple resolution is to send two queries - one for each. For that matter, if the host has multiple location values, for example (but not limited to) different sets of civil attributes, from different sources, there should be no problem with it making LoST queries for each of them (one at a time) and including the results in its decision as to which PSAP to alert. The one-at-a-time method avoids complication in the LoST protocol as well as the risk that the LoST server might attempt (inappropriately) to decide which is best for the client. John On Jun 6, 2006, at 5:01 PM, Hannes Tschofenig wrote: > > Hannes Tschofenig added the comment: > > TENTATIVE SUMMARY: > > I think the long discussion did not lead to a conclusion. > Here is the current discussion status: > > * Either civic OR geospatial in a LoST query > > Marc, Henning, Shida > > * Both civic AND geospatial possible in a LoST query > > Roger, Martin, Andy, > > > These folks don't seem to take a position: > > James W., John Hearty, Jean-Francois, Brian > > Looks like a hard issue to resolve. If someone has suggestions how we > can bring > a few facts into the discussion. > > __________________________________________________ > LoST Issue Tracker > > __________________________________________________ > > _______________________________________________ > 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 Jun 06 17:29:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnj7X-0001lA-0W; Tue, 06 Jun 2006 17:29:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnj7V-0001ku-LU for ecrit@ietf.org; Tue, 06 Jun 2006 17:29: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 1FniX9-0006kl-Tr for ecrit@ietf.org; Tue, 06 Jun 2006 16:52:15 -0400 Received: from moutng.kundenserver.de ([212.227.126.187]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fni47-0002pX-W8 for ecrit@ietf.org; Tue, 06 Jun 2006 16:22:18 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1Fni471EVA-0007iA; Tue, 06 Jun 2006 22:22:15 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Tue, 06 Jun 2006 20:18:01 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1149625081.55.0.664176009258.issue6@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de login:518a04bce8f5fdb19ebc1cc661140948 X-Spam-Score: -2.6 (--) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Ecrit] [issue6] 'Authority' Attribute in LoST Response 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: TENTATIVE SUMMARY: Andy provided the requirement to detect referral loops. Text input is neede= d=2E=20 The name of the attribute might need to be changed to avoid confusion with=20 other use cases. ---------- status: unread -> chatting __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 06 17:40:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnjIH-0000JI-N8; Tue, 06 Jun 2006 17:40:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnjIG-0000JD-VK for ecrit@ietf.org; Tue, 06 Jun 2006 17:40:56 -0400 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnjIF-0005HH-J1 for ecrit@ietf.org; Tue, 06 Jun 2006 17:40:56 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis), id 0ML2Dk-1FnjIE3hrP-0004eb; Tue, 06 Jun 2006 23:40:54 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Tue, 06 Jun 2006 21:36:40 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1149629800.98.0.282775722827.issue9@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: 93238566e09e6e262849b4f805833007 Subject: [Ecrit] [issue9] LoST Response with PSAP Preference 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 New submission from Hannes Tschofenig : Roger indicated that the LoST response would provide a preference value=20 attached to each URI. See http://www1.ietf.org/mail-archive/web/ecrit/current/msg01937.html=20 Does someone have more information about the usage scenario? If we return multiple URIs cannot we just use the first one in the list as = the=20 preferred one (primary contact) and the rest as alternate contact URIs? ---------- assignedto: hannes messages: 22 nosy: ecrit, hannes priority: critical status: unread title: LoST Response with PSAP Preference __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 06 17:51:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnjSV-0006rn-TB; Tue, 06 Jun 2006 17:51:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnjSV-0006rg-5O for ecrit@ietf.org; Tue, 06 Jun 2006 17:51:31 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnjST-0006Vt-SR for ecrit@ietf.org; Tue, 06 Jun 2006 17:51:31 -0400 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.6.118]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k56LpTT00489; Tue, 6 Jun 2006 15:51:29 -0600 Message-ID: <4485FAFA.2090305@ntt-at.com> Date: Tue, 06 Jun 2006 15:00:26 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Ecrit] [issue2] Is it allowed tospecifycivicand geospatialinfointo the query? References: <012f01c689a6$5f11b410$2c0d0d0a@amer.cisco.com> In-Reply-To: <012f01c689a6$5f11b410$2c0d0d0a@amer.cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org My mistake I meant Ma9 not Ma8. Regards Shida Marc Linsner wrote: > > snip..................................... > >>>> Now, on the other hand if the LOST server complies to requirement >>>> Ma8 and returns only one primary URI with multiple alternate URIs >>>> (possibly 2 from Geo resolution and 1 from Civic >>>> >> resolution if one of >> >>>> the URI from Civic resolution was picked as the primary >>>> >> URI), I don't >> >>>> really see a problem with LOST server returning URIs based on two >>>> different location types(civic & geo). >>>> >>> This sounds more reasonable, and only possible with the >>> >> single query >> >>> solution. Well, it could be done with multiple queries, but >>> >> that would >> >>> mean matching transactions via IP addresses, which has the >>> >> obvious NAT >> >>> problem. >>> >> Agree. >> > snip............................. > > Requirement Ma8 talks about returning multiple uri types (sip, im, email, > etc.) all for the SAME location representation. Ma8 does NOT deal with > resolving multiple location representations that are sent within the same > query. > > -Marc- > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 06 17:52:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnjTt-0007uf-SD; Tue, 06 Jun 2006 17:52:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnjTs-0007oM-6O for ecrit@ietf.org; Tue, 06 Jun 2006 17:52:56 -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 1FnimX-0000Fk-Ey for ecrit@ietf.org; Tue, 06 Jun 2006 17:08:09 -0400 Received: from moutng.kundenserver.de ([212.227.126.183]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fnij2-00043V-Ex for ecrit@ietf.org; Tue, 06 Jun 2006 17:04:37 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1Fnij11XM7-0002jI; Tue, 06 Jun 2006 23:04:31 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Tue, 06 Jun 2006 21:00:17 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1149627617.55.0.692466660016.issue4@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de login:518a04bce8f5fdb19ebc1cc661140948 X-Spam-Score: -2.6 (--) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Ecrit] [issue4] Service URN in Response Message 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: TENTATIVE SUMMARY: I think the long discussion did not lead to a conclusion.=20 Here is the current discussion status:=20 * Either civic OR geospatial in a LoST query=20 Marc, Henning, Shida * Both civic AND geospatial possible in a LoST query=20 Roger, Martin, Andy,=20 These folks don't seem to take a position: James W., John Hearty, Jean-Francois, Brian Looks like a hard issue to resolve. If someone has suggestions how we can b= ring=20 a few facts into the discussion. __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 06 18:37:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnkBL-0000ns-1Y; Tue, 06 Jun 2006 18:37:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnkBJ-0000nn-Jc for ecrit@ietf.org; Tue, 06 Jun 2006 18:37:49 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnkBI-0004t2-A7 for ecrit@ietf.org; Tue, 06 Jun 2006 18:37:49 -0400 Received: from lion.cs.columbia.edu (IDENT:WwHVUt0cu2iileQHI+uiHolUgtJnt/x2@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k56MZXX6018659 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 6 Jun 2006 18:37:42 -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 k56MZXBB028051 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Jun 2006 18:35:33 -0400 Message-ID: <44860330.9000805@cs.columbia.edu> Date: Tue, 06 Jun 2006 18:35:28 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: LoST Issue Tracker Subject: Re: [Ecrit] [issue9] LoST Response with PSAP Preference References: <1149629800.98.0.282775722827.issue9@http://www.tschofenig.priv.at> In-Reply-To: <1149629800.98.0.282775722827.issue9@http://www.tschofenig.priv.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 least in SIP, preference values have been of little use, as there's little information to be gleaned from this, beyond some rough order. (If somebody labels two servers as 0.5 and 0.6, is this any different from 0.3 and 0.4 or 0.01 and 0.02?) My concern is that this creates essentially four layers of selection and choices in the overall resolution process: - LoST - DNS NAPTR (for SIP) - DNS SRV (also for SIP) - SIP redirection and proxying at a PSAP server Do you try all instances of SIP servers in the NAPTR records for the first LoST record first or do you go to the second LoST record if the first NAPTR record fails (no SIP response)? Do you go to the second LoST record if the first PSAP is busy? Should you go to the second LoST record because your ping time to that PSAP (server) is better? I'm neutral on having multiple URIs, in the ordered-list manner Hannes suggested, but the behavior and interaction with the other mechanisms would need to be very clearly defined. For example, I think that emergency fail-over is better handled at the SIP redirection layer, where you simply put a set of backup proxies somewhere and list them last in the SIP NAPTR/SRV lists. This avoids all caching issues. An example of something to avoid: If the server inserts the second URL believing that this is only the absolute-last-choice leading to a national call center in some bunker in South Dakota, and the caller picks URLs by ping time, the result may not exactly be what we'd want. Henning Hannes Tschofenig wrote: > New submission from Hannes Tschofenig : > > Roger indicated that the LoST response would provide a preference value > attached to each URI. See > http://www1.ietf.org/mail-archive/web/ecrit/current/msg01937.html > > Does someone have more information about the usage scenario? > If we return multiple URIs cannot we just use the first one in the list as the > preferred one (primary contact) and the rest as alternate contact URIs? > > ---------- > assignedto: hannes > messages: 22 > nosy: ecrit, hannes > priority: critical > status: unread > title: LoST Response with PSAP Preference > > __________________________________________________ > LoST Issue Tracker > > __________________________________________________ > > _______________________________________________ > 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 Jun 06 20:02:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnlUk-0003js-E4; Tue, 06 Jun 2006 20:01:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnlUi-0003jn-Qu for ecrit@ietf.org; Tue, 06 Jun 2006 20:01:56 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnlUh-0005Fa-In for ecrit@ietf.org; Tue, 06 Jun 2006 20:01:56 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jun 2006 19:02:21 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 06 Jun 2006 19:02:20 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jun 2006 19:02:19 -0500 Message-ID: From: "Winterbottom, James" To: "LoST Issue Tracker" , Date: Tue, 6 Jun 2006 19:02:16 -0500 Subject: RE: [Ecrit] [issue4] Service URN in Response Message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 07 Jun 2006 00:02:19.0806 (UTC) FILETIME=[A518B3E0:01C689C5] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <1149627617.55.0.692466660016.issue4@http://www.tschofenig.priv.at> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] [issue4] Service URN in Response Message Thread-Index: AcaJs5h1qOrs6LIKQfu6tjhGZ9yRhAAEc76g X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 Hi Hannes, My position is that the send everything you have to the Lost Server and let it decide which one to use. Sorry for not being clear Cheers James=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@siemens.com] > Sent: Wednesday, 7 June 2006 7:00 AM > To: ecrit@ietf.org > Subject: [Ecrit] [issue4] Service URN in Response Message >=20 >=20 > Hannes Tschofenig added the comment: >=20 > TENTATIVE SUMMARY: >=20 > I think the long discussion did not lead to a conclusion. > Here is the current discussion status: >=20 > * Either civic OR geospatial in a LoST query >=20 > Marc, Henning, Shida >=20 > * Both civic AND geospatial possible in a LoST query >=20 > Roger, Martin, Andy, >=20 >=20 > These folks don't seem to take a position: >=20 > James W., John Hearty, Jean-Francois, Brian >=20 > Looks like a hard issue to resolve. If someone has suggestions how we can > bring > a few facts into the discussion. >=20 > __________________________________________________ > LoST Issue Tracker > > __________________________________________________ >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 06 22:47:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fno5I-0000MO-6y; Tue, 06 Jun 2006 22:47:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fno5G-0000LC-Qc for ecrit@ietf.org; Tue, 06 Jun 2006 22:47:50 -0400 Received: from insmtp.indigital.net ([66.249.239.11] helo=inbsf.indigital.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fno5F-0000kV-5g for ecrit@ietf.org; Tue, 06 Jun 2006 22:47:50 -0400 Received: from apa9.indigital.net (IP-66.249.239.20.indigital.net [66.249.239.20]) by inbsf.indigital.net (Spam Firewall) with ESMTP id 2B4B11A60BC for ; Tue, 6 Jun 2006 22:47:46 -0400 (EDT) Received: from [66.170.32.12] (helo=[192.168.53.41]) by apa9.indigital.net with smtp (Exim 4.43) id 1Fno5A-00043N-FI for ecrit@ietf.org; Tue, 06 Jun 2006 22:47:46 -0400 Message-ID: <44863E49.9050806@indigital.net> Date: Tue, 06 Jun 2006 22:47:37 -0400 From: Byron Smith Organization: INdigital Telecom User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: ecrit@ietf.org Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatial info into the query? References: <1149627686.3.0.0391560947404.issue2@http://www.tschofenig.priv.at> <36aab5b47e8c99105504bb621915ceaa@cisco.com> In-Reply-To: <36aab5b47e8c99105504bb621915ceaa@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by INdigital SMTP Gateway at indigital.net X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bsmith@indigital.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I want to support John. And add my vote that if you wish, nothing keeps you can make multiple queries. But one at a time. This keeps the communications protocol simple. It keeps the server-service simple. Note that it doesn't preclude making two, three, or even ten queries, if you are so inclined. (Though the reason for wanting to do so isn't clear to my simple mind.) And, if you want to make it complicated, to decide between civil vs geo vs handset vs network vs SWAG, and calculate a weighty medium between all the answers, well, then you can do so. At the client. You are not constrained by any preexisting algorithm or value system or artificial expert coded into the server. Modular / flexible = good. Monolithic / rigid = bad. Byron John Schnizlein wrote: > That both civic and geospatial are possible in a LoST query is > perfectly compatible with either one or the other is a LoST query. > The simple resolution is to send two queries - one for each. > > For that matter, if the host has multiple location values, for example > (but not limited to) different sets of civil attributes, from > different sources, there should be no problem with it making LoST > queries for each of them (one at a time) and including the results in > its decision as to which PSAP to alert. The one-at-a-time method > avoids complication in the LoST protocol as well as the risk that the > LoST server might attempt (inappropriately) to decide which is best > for the client. > > John > > On Jun 6, 2006, at 5:01 PM, Hannes Tschofenig wrote: > >> >> Hannes Tschofenig added the comment: >> >> TENTATIVE SUMMARY: >> >> I think the long discussion did not lead to a conclusion. >> Here is the current discussion status: >> >> * Either civic OR geospatial in a LoST query >> >> Marc, Henning, Shida >> >> * Both civic AND geospatial possible in a LoST query >> >> Roger, Martin, Andy, >> >> >> These folks don't seem to take a position: >> >> James W., John Hearty, Jean-Francois, Brian >> >> Looks like a hard issue to resolve. If someone has suggestions how we >> can bring >> a few facts into the discussion. >> >> __________________________________________________ >> LoST Issue Tracker >> >> __________________________________________________ >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 01:23:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnqVQ-0002JC-0h; Wed, 07 Jun 2006 01:23:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnqVP-0002GH-Ee for ecrit@ietf.org; Wed, 07 Jun 2006 01:22:59 -0400 Received: from mta1.prod1.dngr.net ([216.220.209.220] helo=mfe3.prod.danger.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnqTS-0001VE-Tx for ecrit@ietf.org; Wed, 07 Jun 2006 01:21:03 -0400 Received: from [10.253.5.251] (HELO localhost.localdomain) by mfe3.prod.danger.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 694896948; Tue, 06 Jun 2006 22:20:55 -0700 Date: Wed, 7 Jun 2006 01:20:45 -0400 Subject: Re: [Ecrit] [issue4] Service URN in Response Message X-Mailer: Danger Service X-Danger-Send-Id: AAADRkSGYjcAAYa4 Content-Transfer-Encoding: 7bit In-Reply-To: <4485DFEE.9040206@gmx.net> Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Hannes Tschofenig , "Thomson, Martin" Mime-Version: 1.0 References: <4485DFEE.9040206@gmx.net> From: Brian Rosen Message-Id: <1149657654.2AE1B5C7@fc8.dngr.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This is reasonable only if you also include urn:service.x in the reply, so that when you ask for x.y you are told you got the URIs for x. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 01:24:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnqWP-00032R-BD; Wed, 07 Jun 2006 01:24:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnqWO-00031Y-0i for ecrit@ietf.org; Wed, 07 Jun 2006 01:24:00 -0400 Received: from mta3.prod1.dngr.net ([216.220.209.222] helo=mfe1.prod.danger.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnqWK-0001i3-Ow for ecrit@ietf.org; Wed, 07 Jun 2006 01:24:00 -0400 Received: from [10.253.1.251] (HELO localhost.localdomain) by mfe1.prod.danger.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 682837254; Tue, 06 Jun 2006 22:23:56 -0700 Date: Wed, 7 Jun 2006 01:23:46 -0400 Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatial info into the query? X-Mailer: Danger Service X-Danger-Send-Id: AAAJpkSGYuwAAYa0 Content-Transfer-Encoding: 7bit In-Reply-To: <1149627686.3.0.0391560947404.issue2@http://www.tschofenig.priv.at> Content-Type: text/plain; charset="us-ascii"; format="flowed" To: LoST Issue Tracker , ecrit@ietf.org Mime-Version: 1.0 References: <1149627686.3.0.0391560947404.issue2@http://www.tschofenig.priv.at> From: Brian Rosen Message-Id: <1149657835.6BFD303@fc7.dngr.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I am with Marc, only send one. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 01:28:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnqan-0003TI-9o; Wed, 07 Jun 2006 01:28:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnqam-0003TD-Hp for ecrit@ietf.org; Wed, 07 Jun 2006 01:28:32 -0400 Received: from mta2.prod1.dngr.net ([216.220.209.221] helo=mfe2.prod.danger.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnqal-0001nU-AY for ecrit@ietf.org; Wed, 07 Jun 2006 01:28:32 -0400 Received: from [10.253.3.251] (HELO localhost.localdomain) by mfe2.prod.danger.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 681728657; Tue, 06 Jun 2006 22:28:30 -0700 Date: Wed, 7 Jun 2006 01:28:21 -0400 Subject: Re: [Ecrit] [issue9] LoST Response with PSAP Preference X-Mailer: Danger Service X-Danger-Send-Id: AAAIHESGY/4AAYar Content-Transfer-Encoding: 7bit In-Reply-To: <1149629800.98.0.282775722827.issue9@http://www.tschofenig.priv.at> Content-Type: text/plain; charset="us-ascii"; format="flowed" To: LoST Issue Tracker , ecrit@ietf.org Mime-Version: 1.0 References: <1149629800.98.0.282775722827.issue9@http://www.tschofenig.priv.at> From: Brian Rosen Message-Id: <1149658110.28EFE6A3@fb9.dngr.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I prefer to be explicit rather than implicit, but I don't care that much. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 01:36:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnqir-0001Jy-DT; Wed, 07 Jun 2006 01:36:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnqip-0001Jt-Us for ecrit@ietf.org; Wed, 07 Jun 2006 01:36:51 -0400 Received: from mta1.prod1.dngr.net ([216.220.209.220] helo=mfe3.prod.danger.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnqio-0003ZN-LZ for ecrit@ietf.org; Wed, 07 Jun 2006 01:36:51 -0400 Received: from [10.253.5.251] (HELO localhost.localdomain) by mfe3.prod.danger.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 694907261; Tue, 06 Jun 2006 22:36:49 -0700 Date: Wed, 7 Jun 2006 01:36:40 -0400 Subject: Re: [Ecrit] [issue4] Service URN in Response Message X-Mailer: Danger Service X-Danger-Send-Id: AAAaP0SGZfEAAYax Content-Transfer-Encoding: 7bit In-Reply-To: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: "Winterbottom, James" , LoST Issue Tracker , ecrit@ietf.org Mime-Version: 1.0 References: From: Brian Rosen Message-Id: <1149658609.18099708@fd6.dngr.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 Ask som psap folks what they think of that idea. The server, for which the psap ( or the local emergency authority) is ultimately responsible for the data and the behavior of the server. They pretty consistantly tell me they have no way to make decisions like this. Were you thinking the RFC would specify what the server does in that case? If it's configuration and policy, then I think there is no chance the operator of the server will accept that responsibility, because they don't have any knowledge to guide the choice. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 04:28:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FntPG-0002Vf-Eo; Wed, 07 Jun 2006 04:28:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FntPF-0002Va-JP for ecrit@ietf.org; Wed, 07 Jun 2006 04:28:49 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FntPD-0006Ni-7P for ecrit@ietf.org; Wed, 07 Jun 2006 04:28:49 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTPœ id k578SdJt009223Wed, 7 Jun 2006 08:28:39 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1FntP5-0009xZ-00; Wed, 07 Jun 2006 09:28:39 +0100 Date: Wed, 7 Jun 2006 09:28:39 +0100 From: "Clive D.W. Feather" To: Marc Linsner Subject: Re: [Ecrit] [issue2] Is it allowed to specifycivicand geospatialinfointo the query? Message-ID: <20060607082839.GD31934@finch-staff-1.thus.net> References: <8C837214C95C864C9F34F3635C2A657505131459@SEA-EXCHVS-2.telecomsys.com> <004a01c688f9$f519f0b0$2c0d0d0a@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004a01c688f9$f519f0b0$2c0d0d0a@amer.cisco.com> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Marc Linsner said: > Setup for failure example #1: A single LoST query contains both a civic (123 > Main St.) and a geo representation. All geocode databases return 456 Second > St. for the geo. Which one should LoST prefer? By coincidence, I had an email from a friend in Switzerland yesterday that expresses a similar situation. His house is labelled 38 and the house next door is 40 - all the signs on the houses say this and his post is addressed to number 38. He has just had a letter from the local authority telling him that a mistake was made N (where N>20) years ago and actually his house is 40 and the other one is 38. However, he and his neighbour intend to keep the existing numbers rather than try to deal with redirecting vast amounts of post. So, assuming the official databases are updated, the lat-long of the house with "38" written on it will return number 40, while that of the house with "40" written on it will return number 38. Which one should be used? -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 06:47:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnvZK-0001Rc-9S; Wed, 07 Jun 2006 06:47:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnvZJ-0001OJ-Ht for ecrit@ietf.org; Wed, 07 Jun 2006 06:47:21 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnvZI-0006Qh-6s for ecrit@ietf.org; Wed, 07 Jun 2006 06:47:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfo into the query? Date: Wed, 7 Jun 2006 12:51:24 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C5006@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfo into the query? Thread-Index: AcaJ8yqgShG6HqG5THu2vdE8IWrJEQALRDGQ From: "Stastny Richard" To: "Brian Rosen" , "LoST Issue Tracker" , X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I also support Marc, one query at a time Richard > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, June 07, 2006 7:24 AM > To: LoST Issue Tracker; ecrit@ietf.org > Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and > geospatialinfo into the query? >=20 > I am with Marc, only send one. >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 07:34:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnwJ7-0007KS-R5; Wed, 07 Jun 2006 07:34:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnwJ6-0007KN-E2 for ecrit@ietf.org; Wed, 07 Jun 2006 07:34:40 -0400 Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnwJ5-0005Ll-16 for ecrit@ietf.org; Wed, 07 Jun 2006 07:34:40 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu9) with ESMTP (Nemesis), id 0ML2xA-1FnwJ41f8F-0003X6; Wed, 07 Jun 2006 13:34:38 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Wed, 07 Jun 2006 11:30:23 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1149679823.21.0.0302372418614.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: 93238566e09e6e262849b4f805833007 Subject: [Ecrit] [issue2] Is it allowed to specify civic and geospatial info into the query? 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: TENTATIVE SUMMARY: Here is the update:=20 * Either civic OR geospatial in a LoST query=20 Marc, Henning, Shida, Richard, Brian, John Schnizlein, Byron Smith, * Both civic AND geospatial possible in a LoST query=20 Roger, Martin, Andy, James W. These folks don't seem to take a clear position: John Hearty, Jean-Francois, Clive D.W. Feather __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 07:43:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnwRr-0003vv-QD; Wed, 07 Jun 2006 07:43:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnwRq-0003vq-1N for ecrit@ietf.org; Wed, 07 Jun 2006 07:43:42 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnwRo-0007uv-LS for ecrit@ietf.org; Wed, 07 Jun 2006 07:43:42 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTPœ id k57Bhd85006957Wed, 7 Jun 2006 11:43:39 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1FnwRn-000Ezp-00; Wed, 07 Jun 2006 12:43:39 +0100 Date: Wed, 7 Jun 2006 12:43:39 +0100 From: "Clive D.W. Feather" To: Hannes Tschofenig Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatial info into the query? Message-ID: <20060607114339.GI31934@finch-staff-1.thus.net> References: <1149679823.21.0.0302372418614.issue2@http://www.tschofenig.priv.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1149679823.21.0.0302372418614.issue2@http://www.tschofenig.priv.at> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes Tschofenig said: > These folks don't seem to take a clear position: > John Hearty, Jean-Francois, Clive D.W. Feather Sorry. Put me in the: > * Either civic OR geospatial in a LoST query [but not both] camp. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 09:04:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnxi3-0003My-Qx; Wed, 07 Jun 2006 09:04:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnxi2-0003Mn-QU for ecrit@ietf.org; Wed, 07 Jun 2006 09:04:30 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnxi1-00079s-I9 for ecrit@ietf.org; Wed, 07 Jun 2006 09:04:30 -0400 Received: from [192.168.0.41] (pool-138-89-46-232.mad.east.verizon.net [138.89.46.232]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k57D4EqR023524 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 7 Jun 2006 09:04:24 -0400 (EDT) In-Reply-To: <1149679823.21.0.0302372418614.issue2@http://www.tschofenig.priv.at> References: <1149679823.21.0.0302372418614.issue2@http://www.tschofenig.priv.at> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatial info into the query? Date: Wed, 7 Jun 2006 09:04:12 -0400 To: LoST Issue Tracker X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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'll add one additional consideration. Somewhere along the way, I heard the bonmot that computer science only knows three numbers: 0, 1 and infinity. This is generally taken to mean that systems should support none, one or an (essentially) infinite number of objects, for example, but not some arbitrary limit. (Many buffer overflows can be taken as an illustration of what happens when people assume otherwise.) This would mean that if we were to support both geo and civic, we'd also have to support any number of location objects, in any geo/civic combination. After all, an end system could easily get geo or civic information from multiple sources. Since, according to the arguments put forth, the LoST server is in the best position to sort this out, all location objects, of whatever kind, would have to be presented at the same time, whether 1, 2 or a dozen. This probably means that the real alternative to the first option is "an unlimited combination of geo and civic". On Jun 7, 2006, at 7:30 AM, Hannes Tschofenig wrote: > > Hannes Tschofenig added the comment: > > TENTATIVE SUMMARY: > > Here is the update: > > * Either civic OR geospatial in a LoST query > > Marc, Henning, Shida, Richard, Brian, John Schnizlein, Byron Smith, > > > * Both civic AND geospatial possible in a LoST query > > Roger, Martin, Andy, James W. > > These folks don't seem to take a clear position: > > John Hearty, Jean-Francois, Clive D.W. Feather > > __________________________________________________ > LoST Issue Tracker > > __________________________________________________ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 12:09:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0ap-00041X-DH; Wed, 07 Jun 2006 12:09:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0ao-00041G-M2 for ecrit@ietf.org; Wed, 07 Jun 2006 12:09:14 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo0am-0003nS-8i for ecrit@ietf.org; Wed, 07 Jun 2006 12:09:14 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2006 09:09:11 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="1821246558:sNHT31621352" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k57G9BS3031677; Wed, 7 Jun 2006 09:09:11 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k57G9Bku016282; Wed, 7 Jun 2006 12:09:11 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 12:09:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] [issue3] List all Services Functionality Date: Wed, 7 Jun 2006 12:09:09 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3018B74AE@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [issue3] List all Services Functionality Thread-Index: AcaJo1zpm0y8aHpSQRaksHQmOI6gQAAqRk3A From: "Michael Hammer \(mhammer\)" To: "LoST Issue Tracker" , X-OriginalArrivalTime: 07 Jun 2006 16:09:10.0897 (UTC) FILETIME=[B666B610:01C68A4C] DKIM-Signature: a=rsa-sha1; q=dns; l=1062; t=1149696551; x=1150560551; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Ecrit]=20[issue3]=20List=20all=20Services=20Functionality; X=v=3Dcisco.com=3B=20h=3D3qc7YXZPzgyuB3ymv7qPnNiBMGQ=3D; b=JxgongyID5EuqqW1UI5cetYgl0cs+ShWdRW+XBTXJ8Z2u8VTnJCvyJmAB/+I6pW+96YezY/i TcKHYACloKC1Y0pAaKTYpE0cShObYtxSA6XJjeZwaDgu8uwm7gISNFOv; Authentication-Results: sj-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Request clarification: Immediate children or grand-children, great-grand-children, etc.? It might be best to only return one level at a time, given that there could in the long run be many levels (the infinite option :) Mike =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@siemens.com]=20 > Sent: Tuesday, June 06, 2006 3:47 PM > To: ecrit@ietf.org > Subject: [Ecrit] [issue3] List all Services Functionality >=20 >=20 > Hannes Tschofenig added the comment: >=20 > TENTATIVE SUMMARY: >=20 > The functionality of a service listing will be supported by=20 > returning the child elements of a given URN. >=20 > __________________________________________________ > LoST Issue Tracker =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 Wed Jun 07 13:22:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1jp-0003zD-Ow; Wed, 07 Jun 2006 13:22:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1jo-0003z8-KT for ecrit@ietf.org; Wed, 07 Jun 2006 13:22:36 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fo1jn-0005Cs-5y for ecrit@ietf.org; Wed, 07 Jun 2006 13:22:36 -0400 Received: (qmail invoked by alias); 07 Jun 2006 17:22:33 -0000 Received: from p54986F68.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.111.104] by mail.gmx.net (mp001) with SMTP; 07 Jun 2006 19:22:33 +0200 X-Authenticated: #29516787 Message-ID: <44870B57.1020909@gmx.net> Date: Wed, 07 Jun 2006 19:22:31 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Ecrit] [issue3] List all Services Functionality References: <072C5B76F7CEAB488172C6F64B30B5E3018B74AE@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3018B74AE@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Mike, Returning the child elements only seems to be appropriate to me. Ciao Hannes Michael Hammer (mhammer) wrote: > Request clarification: Immediate children or grand-children, > great-grand-children, etc.? > > It might be best to only return one level at a time, given that there > could in the long run be many levels (the infinite option :) > > Mike > > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:hannes.tschofenig@siemens.com] >>Sent: Tuesday, June 06, 2006 3:47 PM >>To: ecrit@ietf.org >>Subject: [Ecrit] [issue3] List all Services Functionality >> >> >>Hannes Tschofenig added the comment: >> >>TENTATIVE SUMMARY: >> >>The functionality of a service listing will be supported by >>returning the child elements of a given URN. >> >>__________________________________________________ >>LoST Issue Tracker >> >>__________________________________________________ >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 13:40:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo20z-0000TI-VC; Wed, 07 Jun 2006 13:40:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo20y-0000T9-FG for ecrit@ietf.org; Wed, 07 Jun 2006 13:40:20 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fo20x-0007Jt-1Y for ecrit@ietf.org; Wed, 07 Jun 2006 13:40:20 -0400 Received: (qmail invoked by alias); 07 Jun 2006 17:40:17 -0000 Received: from p54986F68.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.111.104] by mail.gmx.net (mp029) with SMTP; 07 Jun 2006 19:40:17 +0200 X-Authenticated: #29516787 Message-ID: <44870F7F.8050403@gmx.net> Date: Wed, 07 Jun 2006 19:40:15 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] [issue3] List all Services Functionality References: <072C5B76F7CEAB488172C6F64B30B5E3018B74AE@xmb-rtp-20b.amer.cisco.com> <44870B57.1020909@gmx.net> In-Reply-To: <44870B57.1020909@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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 am referring to immediate child elements only. A query for 'urn:service:sos' would return * urn:service:sos.ambulance * urn:service:sos.animal-control * urn:service:sos.fire .... * urn:service:sos.suicide (based on http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-03.txt Ciao Hannes Hannes Tschofenig wrote: > Hi Mike, > > Returning the child elements only seems to be appropriate to me. > > Ciao > Hannes > > Michael Hammer (mhammer) wrote: > >> Request clarification: Immediate children or grand-children, >> great-grand-children, etc.? >> >> It might be best to only return one level at a time, given that there >> could in the long run be many levels (the infinite option :) >> >> Mike >> >> >> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:hannes.tschofenig@siemens.com] Sent: >>> Tuesday, June 06, 2006 3:47 PM >>> To: ecrit@ietf.org >>> Subject: [Ecrit] [issue3] List all Services Functionality >>> >>> >>> Hannes Tschofenig added the comment: >>> >>> TENTATIVE SUMMARY: >>> >>> The functionality of a service listing will be supported by returning >>> the child elements of a given URN. >>> >>> __________________________________________________ >>> LoST Issue Tracker >>> >>> __________________________________________________ >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 15:23:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo3cZ-0001Ku-9a; Wed, 07 Jun 2006 15:23:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo3cY-0001Kp-OS for ecrit@ietf.org; Wed, 07 Jun 2006 15:23:14 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo3cY-0002yC-5l for ecrit@ietf.org; Wed, 07 Jun 2006 15:23:14 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k57JHwW06959; Wed, 7 Jun 2006 15:17:58 -0400 (EDT) Received: from [127.0.0.1] ([47.130.17.72] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 15:23:11 -0400 Message-ID: <44872798.8060006@nortel.com> Date: Wed, 07 Jun 2006 15:23:04 -0400 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] [issue2] Is it allowed to specify civicand geospatialinfointo the query? References: <8C837214C95C864C9F34F3635C2A657505131429@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A657505131429@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2006 19:23:11.0119 (UTC) FILETIME=[D083A1F0:01C68A67] X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org You seem to be assuming that the LoST client is the user terminal, and at the same time assuming that it has to parse PIDF-LO. This doesn't make sense to me -- won't it be the originator of the PIDF-LO and have the raw data in hand? Roger Marshall wrote: > I admit that this theme is somewhat of a tangent to the subject, but can > the authors of LoST help me understand the reasons for not using the > PIDF-LO. > > Is it the overhead? Is the PIDF-LO not adequate to convey location some > how? > > As an example, if the PIDF-LO format is changed significantly in some > way, it will mandate a s/w change to ~10^8 clients vs. only ~10^2 - 10^4 > server instances. > > It seems to me that as the PIDF-LO undergoes changes over time, that the > choice between having to modify client software vs. server software > instances represents a huge difference in effort. > > > Roger Marshall > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Monday, June 05, 2006 2:24 PM >> To: Roger Marshall >> Cc: Brian Rosen; ecrit@ietf.org >> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic >> and geospatialinfointo the query? >> >> Hi Roger, >> >> Roger Marshall wrote: >>> Hannes: Thanks for clarifying. >>> >>> I think it's a bad idea to withold location information from >> the LoST >>> server. >>> >>> To suggest that we restrict the client, allowing only one to >> be sent, >>> sounds to me like we're placing a constraint on the PIDF-LO, >> saying it >>> can't have both (assuming LoST reuses the PIDF-LO). I don't think we >>> can get away with that. If the PIDF-LO has both, how is it >> that we can >>> glibly strip one out? To do so would be unreasonable. >> To clarify: >> >> * You can send as many queries as you want but not with the >> same message. Different location information => different query >> >> * We don't use a PIDF-LO in LoST. We use the raw location info. >> >>> Since the client can have both civic and geo in the PIDF-LO, it can >>> also send both to the server. What am I missing? >> None of the proposals ever used a PIDF-LO as input; just location info. >> >>> It's the LoST server's job to pick one, not the client's. >> At the PSAP and the emergency routing proxy I agree with you. >> >>> So, the requirement I would support is as follows: >>> >>> Rx' LoST client SHALL query with either civic or geo. >> That's fine. >> >> >>> Ry' LoST client SHOULD query with *both* civic and geo. When LoST >>> server receives both civic and geo, the server SHOULD try to use the >>> geo first. The LoST server response SHALL indicate which data was >>> used (either geo or civic). >> I guess you will not support for this one based on the >> response I saw on the list so far. >> >> Ciao >> Hannes >> >>> -roger. >>> >>> >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Monday, June 05, 2006 1:50 PM >>>> To: Roger Marshall >>>> Cc: Brian Rosen; ecrit@ietf.org >>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >>>> geospatialinfointo the query? >>>> >>>> Hi Roger, >>>> >>>> I think the current suggestion is that the LoST client just picks >>>> whatever he wants and then uses the mapping protocol to trigger the >>>> resolution. >>>> >>>> Using geo and civic might be, from a certain point of view, >> just be an >>>> optimization. The LoST client can always trigger separate >> queries with >>>> all the location info it has. >>>> >>>> Ciao >>>> Hannes >>>> >>>> Roger Marshall wrote: >>>> >>>>> I don't disagree that we ask the LoST server to pick one and >>>> use it. >>>> >>>>> We need to be consistent though, and so therefore, I propose >>>> that the >>>> >>>>> LoST server always picks the geo over the civic and returns >>>> a flag in >>>> >>>>> the response stating that the geo was used to perform mapping. >>>>> >>>>> Roger. >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>> Sent: Monday, June 05, 2006 1:39 PM >>>>>> To: Brian Rosen >>>>>> Cc: ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >>>>>> geospatialinfointo the query? >>>>>> >>>>>> It seems that we closed this issue. >>>>>> >>>>>> Everyone seems to be in favor for a civic OR geospatial. >>>>>> Extensions possible for future applications. >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> Brian Rosen wrote: >>>>>> >>>>>> >>>>>>> I think this is the issue. There is no guidance we can give the >>>>>>> server to tell it how to resolve what to do when both >>>> locations are >>>> >>>>>>> valid but the URI for the geo does match the URI for the civic. >>>>>>> >>>>>>> This happens a lot when you are near boundaries because the >>>>>> precision >>>>>> >>>>>> >>>>>>> and accuracy of the two methods differ. >>>>>>> >>>>>>> I think you pick ONE and use it. >>>>>>> >>>>>>> Even if you send more than one along, the PSAP has to know >>>> which one >>>> >>>>>>> you used to route. It's going to continue to use that >>>> until a human >>>> >>>>>>> says otherwise. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>>>> Sent: Monday, June 05, 2006 3:55 PM >>>>>>> To: Andrew Newton >>>>>>> Cc: ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >>>>>>> geospatialinfo into the query? >>>>>>> >>>>>>> At the PSAP, we have a human that can look at this >> information and >>>>>>> make decisions (and maybe even ask if there's a >> discrepancy). That >>>>>>> seems a stretch for the LoST server. >>>>>>> >>>>>>> Andrew Newton wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> In all of these dual-information cases, I don't see how anybody >>>>>>>>> except the seeker can make any determination which type of >>>>>>>>> information is better, more accurate, more recent, etc. >>>>>>>> Would we want the seeker to determine which information it >>>> feels is >>>> >>>>>>>> best to provide to the PSAP? I've always heard that the >>>>>> answer would be no: >>>>>> >>>>>> >>>>>>>> provide both to the PSAP. So why then would we not >>>> provide the same >>>> >>>>>>>> information when determining which PSAP to contact? >>>>>>>> >>>>>>>> -andy >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>> >>>>> >>> >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 16:13:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4PL-0003Ng-Fn; Wed, 07 Jun 2006 16:13:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4PJ-0003Mv-FQ for ecrit@ietf.org; Wed, 07 Jun 2006 16:13:38 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo4PI-0004Ok-Si for ecrit@ietf.org; Wed, 07 Jun 2006 16:13:37 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 7 Jun 2006 13:13:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] [issue2] Is it allowed to specify civicand geospatialinfointo the query? Date: Wed, 7 Jun 2006 13:13:35 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657505191672@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [issue2] Is it allowed to specify civicand geospatialinfointo the query? Thread-Index: AcaKZ9fvmbwDLM/3QGKw/3nULmd6swABL34g From: "Roger Marshall" To: "Tom-PT Taylor" X-Spam-Score: 0.0 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 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 Tom: I don't restrict the LoST client to be end device (UA). As discussed, LoST queries could be done node by node. As an example, LoST clients could take the form of near or far proxies (ESRPs) for stepwise location-to-uri resolution, whether done in a by-value or by-reference model, or the PSAP UA (CPE), in case of PSAP transfer, etc. I guess my main point is that (in many cases) this notion of LoST client decision making is a client-heavy approach, done in an environment where clients outnumber servers by 4-1 (um=3Dorders of magnitude!). Roger. =20 >-----Original Message----- >From: Tom-PT Taylor [mailto:taylor@nortel.com]=20 >Sent: Wednesday, June 07, 2006 12:23 PM >To: Roger Marshall >Cc: Hannes Tschofenig; ecrit@ietf.org >Subject: Re: [Ecrit] [issue2] Is it allowed to specify=20 >civicand geospatialinfointo the query? > >You seem to be assuming that the LoST client is the user=20 >terminal, and at the same time assuming that it has to parse=20 >PIDF-LO. This doesn't make sense to me -- won't it be the=20 >originator of the PIDF-LO and have the raw data in hand? > >Roger Marshall wrote: >> I admit that this theme is somewhat of a tangent to the subject, but=20 >> can the authors of LoST help me understand the reasons for not using=20 >> the PIDF-LO. >>=20 >> Is it the overhead? Is the PIDF-LO not adequate to convey location=20 >> some how? >>=20 >> As an example, if the PIDF-LO format is changed=20 >significantly in some=20 >> way, it will mandate a s/w change to ~10^8 clients vs. only ~10^2 -=20 >> 10^4 server instances. >> =20 >> It seems to me that as the PIDF-LO undergoes changes over time, that=20 >> the choice between having to modify client software vs. server=20 >> software instances represents a huge difference in effort. >>=20 >>=20 >> Roger Marshall >>=20 >>=20 >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: Monday, June 05, 2006 2:24 PM >>> To: Roger Marshall >>> Cc: Brian Rosen; ecrit@ietf.org >>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and=20 >>> geospatialinfointo the query? >>> >>> Hi Roger, >>> >>> Roger Marshall wrote: >>>> Hannes: Thanks for clarifying. =20 >>>> >>>> I think it's a bad idea to withold location information from >>> the LoST >>>> server. >>>> >>>> To suggest that we restrict the client, allowing only one to >>> be sent, >>>> sounds to me like we're placing a constraint on the PIDF-LO, >>> saying it >>>> can't have both (assuming LoST reuses the PIDF-LO). I=20 >don't think we >>>> can get away with that. If the PIDF-LO has both, how is it=20 >>> that we can >>>> glibly strip one out? To do so would be unreasonable. >>> To clarify: >>> >>> * You can send as many queries as you want but not with the same=20 >>> message. Different location information =3D> different query >>> >>> * We don't use a PIDF-LO in LoST. We use the raw location info. >>> >>>> Since the client can have both civic and geo in the=20 >PIDF-LO, it can=20 >>>> also send both to the server. What am I missing? >>> None of the proposals ever used a PIDF-LO as input; just=20 >location info. >>> >>>> It's the LoST server's job to pick one, not the client's. >>> At the PSAP and the emergency routing proxy I agree with you. >>> >>>> So, the requirement I would support is as follows: >>>> >>>> Rx' LoST client SHALL query with either civic or geo. >>> That's fine. >>> >>> >>>> Ry' LoST client SHOULD query with *both* civic and geo. When LoST=20 >>>> server receives both civic and geo, the server SHOULD try=20 >to use the=20 >>>> geo first. The LoST server response SHALL indicate which data was=20 >>>> used (either geo or civic). >>> I guess you will not support for this one based on the=20 >response I saw=20 >>> on the list so far. >>> >>> Ciao >>> Hannes >>> >>>> -roger. >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>> Sent: Monday, June 05, 2006 1:50 PM >>>>> To: Roger Marshall >>>>> Cc: Brian Rosen; ecrit@ietf.org >>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and=20 >>>>> geospatialinfointo the query? >>>>> >>>>> Hi Roger, >>>>> >>>>> I think the current suggestion is that the LoST client just picks=20 >>>>> whatever he wants and then uses the mapping protocol to=20 >trigger the=20 >>>>> resolution. >>>>> >>>>> Using geo and civic might be, from a certain point of view, >>> just be an >>>>> optimization. The LoST client can always trigger separate >>> queries with >>>>> all the location info it has. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> Roger Marshall wrote: >>>>> >>>>>> I don't disagree that we ask the LoST server to pick one and >>>>> use it. =20 >>>>> >>>>>> We need to be consistent though, and so therefore, I propose >>>>> that the >>>>> >>>>>> LoST server always picks the geo over the civic and returns >>>>> a flag in >>>>> >>>>>> the response stating that the geo was used to perform mapping. >>>>>> >>>>>> Roger. >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>> Sent: Monday, June 05, 2006 1:39 PM >>>>>>> To: Brian Rosen >>>>>>> Cc: ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify=20 >civic and=20 >>>>>>> geospatialinfointo the query? >>>>>>> >>>>>>> It seems that we closed this issue. >>>>>>> >>>>>>> Everyone seems to be in favor for a civic OR geospatial. >>>>>>> Extensions possible for future applications. >>>>>>> >>>>>>> Ciao >>>>>>> Hannes >>>>>>> >>>>>>> Brian Rosen wrote: >>>>>>> >>>>>>> >>>>>>>> I think this is the issue. There is no guidance we=20 >can give the=20 >>>>>>>> server to tell it how to resolve what to do when both >>>>> locations are >>>>> >>>>>>>> valid but the URI for the geo does match the URI for the civic. >>>>>>>> >>>>>>>> This happens a lot when you are near boundaries because the >>>>>>> precision >>>>>>> >>>>>>> >>>>>>>> and accuracy of the two methods differ. >>>>>>>> >>>>>>>> I think you pick ONE and use it. >>>>>>>> >>>>>>>> Even if you send more than one along, the PSAP has to know >>>>> which one >>>>> >>>>>>>> you used to route. It's going to continue to use that >>>>> until a human >>>>> >>>>>>>> says otherwise. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>>>>> Sent: Monday, June 05, 2006 3:55 PM >>>>>>>> To: Andrew Newton >>>>>>>> Cc: ecrit@ietf.org >>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify=20 >civic and=20 >>>>>>>> geospatialinfo into the query? >>>>>>>> >>>>>>>> At the PSAP, we have a human that can look at this >>> information and >>>>>>>> make decisions (and maybe even ask if there's a >>> discrepancy). That >>>>>>>> seems a stretch for the LoST server. >>>>>>>> >>>>>>>> Andrew Newton wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> In all of these dual-information cases, I don't see how=20 >>>>>>>>>> anybody except the seeker can make any determination which=20 >>>>>>>>>> type of information is better, more accurate, more=20 >recent, etc. >>>>>>>>> Would we want the seeker to determine which information it >>>>> feels is >>>>> >>>>>>>>> best to provide to the PSAP? I've always heard that the >>>>>>> answer would be no: >>>>>>> >>>>>>> >>>>>>>>> provide both to the PSAP. So why then would we not >>>>> provide the same >>>>> >>>>>>>>> information when determining which PSAP to contact? >>>>>>>>> >>>>>>>>> -andy >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Ecrit mailing list >>>>>>>> Ecrit@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Ecrit mailing list >>>>>>>> Ecrit@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>> >>>>>> >>>> >>> >>=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 Wed Jun 07 16:16:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4SH-0004Vo-JG; Wed, 07 Jun 2006 16:16:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4SF-0004V8-C7 for ecrit@ietf.org; Wed, 07 Jun 2006 16:16:39 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo4SE-0004ZK-1W for ecrit@ietf.org; Wed, 07 Jun 2006 16:16:39 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k57JpmK26065; Wed, 7 Jun 2006 15:51:49 -0400 (EDT) Received: from [127.0.0.1] ([47.130.17.72] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 15:51:39 -0400 Message-ID: <44872E47.2070201@nortel.com> Date: Wed, 07 Jun 2006 15:51:35 -0400 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: LoST Issue Tracker Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatial info into the query? References: <1149679823.21.0.0302372418614.issue2@http://www.tschofenig.priv.at> In-Reply-To: <1149679823.21.0.0302372418614.issue2@http://www.tschofenig.priv.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2006 19:51:40.0034 (UTC) FILETIME=[CB1B5E20:01C68A6B] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Add my voice for one only. Keep the protocol simple. Hannes Tschofenig wrote: > Hannes Tschofenig added the comment: > > TENTATIVE SUMMARY: > > Here is the update: > > * Either civic OR geospatial in a LoST query > > Marc, Henning, Shida, Richard, Brian, John Schnizlein, Byron Smith, > > > * Both civic AND geospatial possible in a LoST query > > Roger, Martin, Andy, James W. > > These folks don't seem to take a clear position: > > John Hearty, Jean-Francois, Clive D.W. Feather > > __________________________________________________ > LoST Issue Tracker > > __________________________________________________ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 16:28:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4dT-0000Av-Gg; Wed, 07 Jun 2006 16:28:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo48G-0005vr-KJ for ecrit@ietf.org; Wed, 07 Jun 2006 15:56:01 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo48C-0001Sm-2L for ecrit@ietf.org; Wed, 07 Jun 2006 15:55:58 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 7 Jun 2006 12:55:54 -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] [issue9] LoST Response with PSAP Preference Date: Wed, 7 Jun 2006 12:55:53 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750519163C@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [issue9] LoST Response with PSAP Preference Thread-Index: AcaJudzDd6EEjOH/QAmTilB7/ZkfJwApnLUw From: "Roger Marshall" To: "Henning Schulzrinne" , "LoST Issue Tracker" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b 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 can agree that when multiple URIs are returned that they be returned per an ordered list, (based on resiliancy considerations more than any other thing), but in addition, I propose the following: In addition to basing the ordered list on location, there may be other preferential information to consider, such as the inclusion of special attributes (similar to a web server receiving accept-encoding(?) headers from a web client). Though these may not always apply, these shouldn't be precluded from being allowed in the protocol, since they could be used in the future to support the following use cases: 1. ) Ability to differentiate between fixed and mobile subscribers. Some PSAPs today support mobile calls, while others don't. This is largely a result of PSAP equipment capabilities and training, and won't be suddenly remedied any time soon for IP-based calls. There may be a need to have the LoST server return a PSAP URI appropriate to the type of call being made - whether fixed, or mobile. 2. ) Public jurisdictional conflicts. A person is walking onto a college campus, when she is unexpectedly injured. A witness makes an emergency call from a campus installed emergency phone, while the injured person makes an emergency call from her cell phone. Campus personnel show up, followed by other off-campus (e.g. county) emergency personnel. Despite having plenty of assistance, extra resources weren't really necessary in this case. In addition, total available emergency service capacity was reduced, and extra cost was incurred. 3. ) Private jurisdictional conflict. Same as above, except this time, applied to a corporate campus which experiences a minor hazmat spill. A call for 9-1-1 should get the corporate hazmat team, but instead results in the county fire trucks arriving at the company's front gate without the company having prior knowledge which would have been necessary to deal with the problem. Large companies usually like to field emergency calls first, so they can invoke their own processes first. I proposed that LoST clients may be allowed to include special attributes (not defined here, but which may be defined later) in the LoST request. I would also say that the requirement for the LoST server is that they could ignore these special attributes. Roger Marshall >-----Original Message----- >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 >Sent: Tuesday, June 06, 2006 3:35 PM >To: LoST Issue Tracker >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] [issue9] LoST Response with PSAP Preference > >At least in SIP, preference values have been of little use, as=20 >there's little information to be gleaned from this, beyond=20 >some rough order. (If somebody labels two servers as 0.5 and=20 >0.6, is this any different from >0.3 and 0.4 or 0.01 and 0.02?) > >My concern is that this creates essentially four layers of=20 >selection and choices in the overall resolution process: > >- LoST >- DNS NAPTR (for SIP) >- DNS SRV (also for SIP) >- SIP redirection and proxying at a PSAP server > >Do you try all instances of SIP servers in the NAPTR records=20 >for the first LoST record first or do you go to the second=20 >LoST record if the first NAPTR record fails (no SIP response)?=20 >Do you go to the second LoST record if the first PSAP is busy?=20 >Should you go to the second LoST record because your ping time=20 >to that PSAP (server) is better? > >I'm neutral on having multiple URIs, in the ordered-list=20 >manner Hannes suggested, but the behavior and interaction with=20 >the other mechanisms would need to be very clearly defined.=20 >For example, I think that emergency fail-over is better=20 >handled at the SIP redirection layer, where you simply put a=20 >set of backup proxies somewhere and list them last in the SIP=20 >NAPTR/SRV lists. This avoids all caching issues. > >An example of something to avoid: If the server inserts the=20 >second URL believing that this is only the=20 >absolute-last-choice leading to a national call center in some=20 >bunker in South Dakota, and the caller picks URLs by ping=20 >time, the result may not exactly be what we'd want. > > >Henning > >Hannes Tschofenig wrote: >> New submission from Hannes Tschofenig : >>=20 >> Roger indicated that the LoST response would provide a preference=20 >> value attached to each URI. See=20 >> http://www1.ietf.org/mail-archive/web/ecrit/current/msg01937.html >>=20 >> Does someone have more information about the usage scenario? >> If we return multiple URIs cannot we just use the first one in the=20 >> list as the preferred one (primary contact) and the rest as=20 >alternate contact URIs? >>=20 >> ---------- >> assignedto: hannes >> messages: 22 >> nosy: ecrit, hannes >> priority: critical >> status: unread >> title: LoST Response with PSAP Preference >>=20 >> __________________________________________________ >> LoST Issue Tracker =20 >> >> __________________________________________________ >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 17:13:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo5Kw-0004aE-8S; Wed, 07 Jun 2006 17:13:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo5Kv-0004Zv-IT for ecrit@ietf.org; Wed, 07 Jun 2006 17:13:09 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo5Ku-0003bN-7J for ecrit@ietf.org; Wed, 07 Jun 2006 17:13:09 -0400 Received: from lion.cs.columbia.edu (IDENT:j4DSTRYiFSTMKoWqkQ2U6ic9KprRYV/u@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k57LCuX6022011 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 7 Jun 2006 17:13:02 -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 k57LCrBB005508 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 7 Jun 2006 17:12:56 -0400 Message-ID: <44874150.90407@cs.columbia.edu> Date: Wed, 07 Jun 2006 17:12:48 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] [issue9] LoST Response with PSAP Preference References: <8C837214C95C864C9F34F3635C2A65750519163C@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A65750519163C@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 Roger Marshall wrote: > In addition to basing the ordered list on location, there may be other > preferential information to consider, such as the inclusion of special > attributes (similar to a web server receiving accept-encoding(?) headers Accept-encoding (and the other Accept-* headers) are all query headers that guide the server in returning one object. HTTP does not deliver a bag of responses. > from a web client). Though these may not always apply, these shouldn't > be precluded from being allowed in the protocol, since they could be > used in the future to support the following use cases: > > 1. ) Ability to differentiate between fixed and mobile subscribers. > Some PSAPs today support mobile calls, while others don't. This is > largely a result of PSAP equipment capabilities and training, and won't > be suddenly remedied any time soon for IP-based calls. There may be a > need to have the LoST server return a PSAP URI appropriate to the type > of call being made - whether fixed, or mobile. This seems like a query parameter, rather than offering the client a whole list of choices. (If the client knows the difference between mobile and not, it can presumably indicate which answer it is looking for.) > > 2. ) Public jurisdictional conflicts. A person is walking onto a > college campus, when she is unexpectedly injured. A witness makes an > emergency call from a campus installed emergency phone, while the > injured person makes an emergency call from her cell phone. Campus > personnel show up, followed by other off-campus (e.g. county) emergency > personnel. Despite having plenty of assistance, extra resources weren't > really necessary in this case. In addition, total available emergency > service capacity was reduced, and extra cost was incurred. I'm unsure as to how this can be resolved by a location mapping protocol, as opposed to some backend coordination protocol where the campus police tells the city police which incidents its currently working on. Location information itself clearly isn't sufficient to know that these two incidents are the same - the second caller could be calling about the building that's on fire... > > 3. ) Private jurisdictional conflict. Same as above, except this time, > applied to a corporate campus which experiences a minor hazmat spill. A > call for 9-1-1 should get the corporate hazmat team, but instead results > in the county fire trucks arriving at the company's front gate without > the company having prior knowledge which would have been necessary to > deal with the problem. Large companies usually like to field emergency > calls first, so they can invoke their own processes first. At least in my model of how LoST would work, the company could either "carve out" a particular area where it is the "PSAP" (presumably with permission of the local jurisdiction) or the outbound proxy/ESRP does the appropriate routing. > > I proposed that LoST clients may be allowed to include special > attributes (not defined here, but which may be defined later) in the > LoST request. I would also say that the requirement for the LoST server > is that they could ignore these special attributes. I agree that we should be able to include additional query attributes beyond the service identifier and location. As with most extensions, there are probably two options: - ignore if you don't understand them (and maybe indicate the ones the server did take into account) - refuse the request if a server doesn't understand a particular qualifier For simplicity and because of the nature of what we're trying to do, I'm inclined to only support the former. > > > Roger Marshall _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 17:55:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo5zZ-00006k-KQ; Wed, 07 Jun 2006 17:55:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo5zW-0008Lp-BL for ecrit@ietf.org; Wed, 07 Jun 2006 17:55:06 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo5zV-0003Jp-Rf for ecrit@ietf.org; Wed, 07 Jun 2006 17:55:06 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 16:55:32 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 07 Jun 2006 16:55:32 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 16:55:31 -0500 Message-ID: From: "Winterbottom, James" To: "Roger Marshall" , "Tom-PT Taylor" Date: Wed, 7 Jun 2006 16:55:28 -0500 Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivicand geospatialinfointo the query? MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 07 Jun 2006 21:55:31.0221 (UTC) FILETIME=[18708450:01C68A7D] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <8C837214C95C864C9F34F3635C2A657505191672@SEA-EXCHVS-2.telecomsys.com> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] [issue2] Is it allowed to specifycivicand geospatialinfointo the query? Thread-Index: AcaKZ9fvmbwDLM/3QGKw/3nULmd6swABL34gAAPi/CA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b 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 agree with Roger here. In the immediate future, and I suspect that for quite some time, routing decisions based on location will come from centralized call server implementations. If the call server gets a PIDF-LO it will, at best, simply grab everything in every location-info element and send it upwards, unless you are suggesting that the call server make the decision about which location to use. I would argue that the call-server is in an even less good position to make this decision than the LoST server. At least the LoST server is already required to have some rules and information with regards to making routing decisions. Cheers James > -----Original Message----- > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > Sent: Thursday, 8 June 2006 6:14 AM > To: Tom-PT Taylor > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivicand > geospatialinfointo the query? >=20 > Tom: > I don't restrict the LoST client to be end device (UA). As discussed, > LoST queries could be done node by node. As an example, LoST clients > could take the form of near or far proxies (ESRPs) for stepwise > location-to-uri resolution, whether done in a by-value or by-reference > model, or the PSAP UA (CPE), in case of PSAP transfer, etc. >=20 > I guess my main point is that (in many cases) this notion of LoST client > decision making is a client-heavy approach, done in an environment where > clients outnumber servers by 4-1 (um=3Dorders of magnitude!). >=20 > Roger. >=20 >=20 > >-----Original Message----- > >From: Tom-PT Taylor [mailto:taylor@nortel.com] > >Sent: Wednesday, June 07, 2006 12:23 PM > >To: Roger Marshall > >Cc: Hannes Tschofenig; ecrit@ietf.org > >Subject: Re: [Ecrit] [issue2] Is it allowed to specify > >civicand geospatialinfointo the query? > > > >You seem to be assuming that the LoST client is the user > >terminal, and at the same time assuming that it has to parse > >PIDF-LO. This doesn't make sense to me -- won't it be the > >originator of the PIDF-LO and have the raw data in hand? > > > >Roger Marshall wrote: > >> I admit that this theme is somewhat of a tangent to the subject, but > >> can the authors of LoST help me understand the reasons for not using > >> the PIDF-LO. > >> > >> Is it the overhead? Is the PIDF-LO not adequate to convey location > >> some how? > >> > >> As an example, if the PIDF-LO format is changed > >significantly in some > >> way, it will mandate a s/w change to ~10^8 clients vs. only ~10^2 - > >> 10^4 server instances. > >> > >> It seems to me that as the PIDF-LO undergoes changes over time, that > >> the choice between having to modify client software vs. server > >> software instances represents a huge difference in effort. > >> > >> > >> Roger Marshall > >> > >> > >>> -----Original Message----- > >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>> Sent: Monday, June 05, 2006 2:24 PM > >>> To: Roger Marshall > >>> Cc: Brian Rosen; ecrit@ietf.org > >>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and > >>> geospatialinfointo the query? > >>> > >>> Hi Roger, > >>> > >>> Roger Marshall wrote: > >>>> Hannes: Thanks for clarifying. > >>>> > >>>> I think it's a bad idea to withold location information from > >>> the LoST > >>>> server. > >>>> > >>>> To suggest that we restrict the client, allowing only one to > >>> be sent, > >>>> sounds to me like we're placing a constraint on the PIDF-LO, > >>> saying it > >>>> can't have both (assuming LoST reuses the PIDF-LO). I > >don't think we > >>>> can get away with that. If the PIDF-LO has both, how is it > >>> that we can > >>>> glibly strip one out? To do so would be unreasonable. > >>> To clarify: > >>> > >>> * You can send as many queries as you want but not with the same > >>> message. Different location information =3D> different query > >>> > >>> * We don't use a PIDF-LO in LoST. We use the raw location info. > >>> > >>>> Since the client can have both civic and geo in the > >PIDF-LO, it can > >>>> also send both to the server. What am I missing? > >>> None of the proposals ever used a PIDF-LO as input; just > >location info. > >>> > >>>> It's the LoST server's job to pick one, not the client's. > >>> At the PSAP and the emergency routing proxy I agree with you. > >>> > >>>> So, the requirement I would support is as follows: > >>>> > >>>> Rx' LoST client SHALL query with either civic or geo. > >>> That's fine. > >>> > >>> > >>>> Ry' LoST client SHOULD query with *both* civic and geo. When LoST > >>>> server receives both civic and geo, the server SHOULD try > >to use the > >>>> geo first. The LoST server response SHALL indicate which data was > >>>> used (either geo or civic). > >>> I guess you will not support for this one based on the > >response I saw > >>> on the list so far. > >>> > >>> Ciao > >>> Hannes > >>> > >>>> -roger. > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>> Sent: Monday, June 05, 2006 1:50 PM > >>>>> To: Roger Marshall > >>>>> Cc: Brian Rosen; ecrit@ietf.org > >>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and > >>>>> geospatialinfointo the query? > >>>>> > >>>>> Hi Roger, > >>>>> > >>>>> I think the current suggestion is that the LoST client just picks > >>>>> whatever he wants and then uses the mapping protocol to > >trigger the > >>>>> resolution. > >>>>> > >>>>> Using geo and civic might be, from a certain point of view, > >>> just be an > >>>>> optimization. The LoST client can always trigger separate > >>> queries with > >>>>> all the location info it has. > >>>>> > >>>>> Ciao > >>>>> Hannes > >>>>> > >>>>> Roger Marshall wrote: > >>>>> > >>>>>> I don't disagree that we ask the LoST server to pick one and > >>>>> use it. > >>>>> > >>>>>> We need to be consistent though, and so therefore, I propose > >>>>> that the > >>>>> > >>>>>> LoST server always picks the geo over the civic and returns > >>>>> a flag in > >>>>> > >>>>>> the response stating that the geo was used to perform mapping. > >>>>>> > >>>>>> Roger. > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>>>> Sent: Monday, June 05, 2006 1:39 PM > >>>>>>> To: Brian Rosen > >>>>>>> Cc: ecrit@ietf.org > >>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify > >civic and > >>>>>>> geospatialinfointo the query? > >>>>>>> > >>>>>>> It seems that we closed this issue. > >>>>>>> > >>>>>>> Everyone seems to be in favor for a civic OR geospatial. > >>>>>>> Extensions possible for future applications. > >>>>>>> > >>>>>>> Ciao > >>>>>>> Hannes > >>>>>>> > >>>>>>> Brian Rosen wrote: > >>>>>>> > >>>>>>> > >>>>>>>> I think this is the issue. There is no guidance we > >can give the > >>>>>>>> server to tell it how to resolve what to do when both > >>>>> locations are > >>>>> > >>>>>>>> valid but the URI for the geo does match the URI for the civic. > >>>>>>>> > >>>>>>>> This happens a lot when you are near boundaries because the > >>>>>>> precision > >>>>>>> > >>>>>>> > >>>>>>>> and accuracy of the two methods differ. > >>>>>>>> > >>>>>>>> I think you pick ONE and use it. > >>>>>>>> > >>>>>>>> Even if you send more than one along, the PSAP has to know > >>>>> which one > >>>>> > >>>>>>>> you used to route. It's going to continue to use that > >>>>> until a human > >>>>> > >>>>>>>> says otherwise. > >>>>>>>> > >>>>>>>> Brian > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>>>>>>> Sent: Monday, June 05, 2006 3:55 PM > >>>>>>>> To: Andrew Newton > >>>>>>>> Cc: ecrit@ietf.org > >>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify > >civic and > >>>>>>>> geospatialinfo into the query? > >>>>>>>> > >>>>>>>> At the PSAP, we have a human that can look at this > >>> information and > >>>>>>>> make decisions (and maybe even ask if there's a > >>> discrepancy). That > >>>>>>>> seems a stretch for the LoST server. > >>>>>>>> > >>>>>>>> Andrew Newton wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> In all of these dual-information cases, I don't see how > >>>>>>>>>> anybody except the seeker can make any determination which > >>>>>>>>>> type of information is better, more accurate, more > >recent, etc. > >>>>>>>>> Would we want the seeker to determine which information it > >>>>> feels is > >>>>> > >>>>>>>>> best to provide to the PSAP? I've always heard that the > >>>>>>> answer would be no: > >>>>>>> > >>>>>>> > >>>>>>>>> provide both to the PSAP. So why then would we not > >>>>> provide the same > >>>>> > >>>>>>>>> information when determining which PSAP to contact? > >>>>>>>>> > >>>>>>>>> -andy > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Ecrit mailing list > >>>>>>>> Ecrit@ietf.org > >>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Ecrit mailing list > >>>>>>>> Ecrit@ietf.org > >>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Ecrit mailing list > >>>>>>> Ecrit@ietf.org > >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>> > >>>>>> > >>>>>> > >>>> > >>> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > >> > > > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 17:59:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo63c-0002bT-W2; Wed, 07 Jun 2006 17:59:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo63b-0002b4-Fe for ecrit@ietf.org; Wed, 07 Jun 2006 17:59:19 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo63Y-0003PD-Vk for ecrit@ietf.org; Wed, 07 Jun 2006 17:59:19 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 7 Jun 2006 14:59:13 -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] [issue9] LoST Response with PSAP Preference Date: Wed, 7 Jun 2006 14:59:12 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575051917C6@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [issue9] LoST Response with PSAP Preference Thread-Index: AcaKdy+LdtuPh/sRTXWoGokKt6n8ogABHgPQ From: "Roger Marshall" To: "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning: See response in-line. Thanks. =20 >-----Original Message----- >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 >Sent: Wednesday, June 07, 2006 2:13 PM >To: Roger Marshall >Cc: LoST Issue Tracker; ecrit@ietf.org >Subject: Re: [Ecrit] [issue9] LoST Response with PSAP Preference > > > >Roger Marshall wrote: > >> In addition to basing the ordered list on location, there=20 >may be other=20 >> preferential information to consider, such as the inclusion=20 >of special=20 >> attributes (similar to a web server receiving accept-encoding(?)=20 >> headers > >Accept-encoding (and the other Accept-* headers) are all query=20 >headers that guide the server in returning one object. HTTP=20 >does not deliver a bag of responses. > >> from a web client). Though these may not always apply, these=20 >> shouldn't be precluded from being allowed in the protocol,=20 >since they=20 >> could be used in the future to support the following use cases: >>=20 >> 1. ) Ability to differentiate between fixed and mobile subscribers. >> Some PSAPs today support mobile calls, while others don't. This is=20 >> largely a result of PSAP equipment capabilities and training, and=20 >> won't be suddenly remedied any time soon for IP-based calls. There=20 >> may be a need to have the LoST server return a PSAP URI=20 >appropriate to=20 >> the type of call being made - whether fixed, or mobile. > >This seems like a query parameter, rather than offering the=20 >client a whole list of choices. (If the client knows the=20 >difference between mobile and not, it can presumably indicate=20 >which answer it is looking for.) > Agree. > >>=20 >> 2. ) Public jurisdictional conflicts. A person is walking onto a=20 >> college campus, when she is unexpectedly injured. A witness=20 >makes an=20 >> emergency call from a campus installed emergency phone, while the=20 >> injured person makes an emergency call from her cell phone. Campus=20 >> personnel show up, followed by other off-campus (e.g. county)=20 >> emergency personnel. Despite having plenty of assistance, extra=20 >> resources weren't really necessary in this case. In addition, total=20 >> available emergency service capacity was reduced, and extra=20 >cost was incurred. > >I'm unsure as to how this can be resolved by a location=20 >mapping protocol, as opposed to some backend coordination=20 >protocol where the campus police tells the city police which=20 >incidents its currently working on. Location information=20 >itself clearly isn't sufficient to know that these two=20 >incidents are the same - the second caller could be calling=20 >about the building that's on fire... > The question then is whether the campus wants to be the first to know about the fire (to evacuate), or the local jurisdiction (to roll trucks). I think all I'm trying to say is that the LoST protocol should support ordering, and to point out a use case wherein it may need to be configurable based on location.=20 > > >>=20 >> 3. ) Private jurisdictional conflict. Same as above, except this=20 >> time, applied to a corporate campus which experiences a minor hazmat=20 >> spill. A call for 9-1-1 should get the corporate hazmat team, but=20 >> instead results in the county fire trucks arriving at the company's=20 >> front gate without the company having prior knowledge which=20 >would have=20 >> been necessary to deal with the problem. Large companies usually=20 >> like to field emergency calls first, so they can invoke=20 >their own processes first. > >At least in my model of how LoST would work, the company could=20 >either "carve out" a particular area where it is the "PSAP"=20 >(presumably with permission of the local jurisdiction) or the=20 >outbound proxy/ESRP does the appropriate routing. > I agree that coordination is the best policy, still I don't see this as much of a "carving out" into a separate boudary, as much as of a 2nd tier "overlaid" choice for routing (used as a fallback), so again, the LoST response could order appropriately. I don't really think there is any real disagreement here. > >>=20 >> I proposed that LoST clients may be allowed to include special=20 >> attributes (not defined here, but which may be defined later) in the=20 >> LoST request. I would also say that the requirement for the LoST=20 >> server is that they could ignore these special attributes. > >I agree that we should be able to include additional query=20 >attributes beyond the service identifier and location. As with=20 >most extensions, there are probably two options: > >- ignore if you don't understand them (and maybe indicate the=20 >ones the server did take into account) >- refuse the request if a server doesn't understand a=20 >particular qualifier > >For simplicity and because of the nature of what we're trying=20 >to do, I'm inclined to only support the former. > Agreed. -roger. > >>=20 >>=20 >> Roger Marshall > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 18:08:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo6Cq-0001IX-4y; Wed, 07 Jun 2006 18:08:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo6Cp-0001Ep-C5 for ecrit@ietf.org; Wed, 07 Jun 2006 18:08:51 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo6Co-0003dR-5C for ecrit@ietf.org; Wed, 07 Jun 2006 18:08:51 -0400 Received: from lion.cs.columbia.edu (IDENT:vMbhUMzIXBKJaPH/SEl+8BNNqyh05zR1@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k57M8FX6012653 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 7 Jun 2006 18:08:48 -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 k57M8EBB009051 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 7 Jun 2006 18:08:14 -0400 Message-ID: <44874E49.4090100@cs.columbia.edu> Date: Wed, 07 Jun 2006 18:08:09 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] [issue9] LoST Response with PSAP Preference References: <8C837214C95C864C9F34F3635C2A6575051917C6@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A6575051917C6@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 > The question then is whether the campus wants to be the first to know > about the fire (to evacuate), or the local jurisdiction (to roll > trucks). I think all I'm trying to say is that the LoST protocol should > support ordering, and to point out a use case wherein it may need to be > configurable based on location. This goes back to my earlier note. When getting these two URLs, what would a client do with this? Would you indicate "if you don't like the amateur cops from the University [URL1], please call the real ones from the NYPD [URL2]" ? Or would you always indicate a hierarchy of services, as in campus police NYPD NY state troopers FBI Since this mapping is for the PSAP, not the actual first responders, I always thought it was the job of the campus PSAP to decide whether to call in the city cops. At least, this is how it works on our campus (for on-campus calls). Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 18:42:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo6jb-00014E-2E; Wed, 07 Jun 2006 18:42:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo6jZ-00013h-Nx for ecrit@ietf.org; Wed, 07 Jun 2006 18:42:41 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo6jY-0006dK-Dg for ecrit@ietf.org; Wed, 07 Jun 2006 18:42:41 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 17:43:07 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 07 Jun 2006 17:43:06 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 17:43:05 -0500 Message-ID: From: "Thomson, Martin" To: "LoST Issue Tracker" , Date: Wed, 7 Jun 2006 17:42:24 -0500 Subject: RE: [Ecrit] [issue2] Is it allowed to specify civic and geospatial infointo the query? MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 07 Jun 2006 22:43:05.0984 (UTC) FILETIME=[BE02C800:01C68A83] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <1149679823.21.0.0302372418614.issue2@http://www.tschofenig.priv.at> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] [issue2] Is it allowed to specify civic and geospatial infointo the query? Thread-Index: AcaKJpfw4mXAws9xRRCt00g7woL//AAWv0iQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1568010199==" Errors-To: ecrit-bounces@ietf.org --===============1568010199== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message SSdkIGxpa2UgdG8gY2xhcmlmeSBteSBwb3NpdGlvbiwgYmVjYXVzZSBJIHRoaW5rIHRoYXQgdGhp cyBkaXNjdXNzaW9uIGhhcyBoZWFkZWQgb2ZmIGNvdXJzZSBhIGxpdHRsZS4NCg0KRmlyc3RseSwg SSdkIHJlY29tbWVuZCB0aGF0IHBlb3BsZSByZWFkIHRoZSBQRElGLUxPIFtzaWNdIHByb2ZpbGUg ZHJhZnQuICBUaGF0IGRyYWZ0IHRhbGtzIGFib3V0IGNhcmRpbmFsaXR5IGFuZCBJIHRoaW5rIHRo YXQgaXQgaXMgZXh0cmVtZWx5IGltcG9ydGFudCB0byB0aGlzIGRpc2N1c3Npb24uDQoNCmh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZ2VvcHJpdi1wZGlmLWxvLXByb2ZpbGUt MDQudHh0DQoNClRoaXMgZG9jdW1lbnQgbm90ZXMgdGhhdCBpdCBpcyBwb3NzaWJsZSB0byBoYXZl IGNpdmljIGFuZCBnZW9kZXRpYyB0aGF0IHRvZ2V0aGVyIGZvcm0gYSBjb21wbGV4IHRvIGRlc2Ny aWJlIGEgc2luZ2xlIGxvY2F0aW9uLiAgVGhlIGV4YW1wbGUgdXNlZCBpcyBhIHNldCBvZiAyLWRp bWVuc2lvbmFsIGNvb3JkaW5hdGVzIHdpdGggYW4gYWx0aXR1ZGUgZXhwcmVzc2VkIGluIGJ1aWxk aW5nIGZsb29ycy4gIFRoaXMgaXMgdGhlIHJlYXNvbiB0aGF0IEkgc3VwcG9ydCBib3RoLCBub3Qg YmVjYXVzZSBJIHNlZSB0aGF0IHRoZSBMb1NUIHNlcnZlciBiZWluZyBhYmxlIHRvIG1ha2UgaW50 ZWxsaWdlbnQgZGVjaXNpb25zIGFib3V0IG11bHRpcGxlIGNvbmZsaWN0aW5nIHBpZWNlcyBvZiBp bmZvcm1hdGlvbi4NCg0KSGVyZSdzIGhvdyBJIHNlZSB0aGlzIHdvcmtpbmcuICBUaGUgc2Vla2Vy IGhhcyBhIFBJREYtTE8uICBUaGV5IGFwcGx5IHRoZSBzZWxlY3Rpb24gbWV0aG9kcyBkZXNjcmli ZWQgaW4gdGhlIGFib3ZlIGRvY3VtZW50IHRvIHNlbGVjdCBhIHNpbmdsZSB0dXBsZSB0aGF0IGNv bnRhaW5zIGxvY2F0aW9uIGluZm9ybWF0aW9uLg0KKFhQYXRoPSIvcHJlc2VuY2UvdHVwbGVbc3Rh dHVzL2dlb3ByaXZdWzFdIikNCg0KV2hhdGV2ZXIgbG9jYXRpb24gaW5mb3JtYXRpb24gdGhhdCB0 dXBsZSBjb250YWlucywgYmUgaXQgZ2VvZGV0aWMgb3IgY2l2aWMsIHRoZSBzZWVrZXIgbGlmdHMg dGhlIGNvbnRlbnRzIG9mIHRoZSBsb2NhdGlvbi1pbmZvIGVsZW1lbnQgYW5kIHB1dHMgaXQgaW4g YW4gYXBwcm9wcmlhdGUgTG9TVCBxdWVyeS4NCg0KSGVyZSBhcmUgdGhlIGFwcGxpY2FibGUgcnVs ZXM6DQoNCiAgIFJ1bGUgIzE6IEEgZ2VvcHJpdiBlbGVtZW50IE1VU1QgZGVzY3JpYmUgYSBkaXNj cmV0ZSBsb2NhdGlvbi4NCiAgIFJ1bGUgIzQ6IFByb3ZpZGluZyBtb3JlIHRoYW4gb25lIGxvY2F0 aW9uIGluIGEgc2luZ2xlIDxsb2NhdGlvbi1pbmZvPg0KICAgICAgZWxlbWVudCBTSE9VTEQgYmUg YXZvaWRlZCB3aGVyZSBwb3NzaWJsZS4NCiAgIFJ1bGUgIzU6IFdoZW4gcHJvdmlkaW5nIG1vcmUg dGhhbiBvbmUgbG9jYXRpb24gaW4gYSBzaW5nbGUgPGxvY2F0aW9uLQ0KICAgICAgaW5mbz4gZWxl bWVudCB0aGUgbG9jYXRpb25zIE1VU1QgYmUgcHJvdmlkZWQgYnkgYSBjb21tb24gc291cmNlLg0K ICAgUnVsZSAjNjogUHJvdmlkaW5nIG1vcmUgdGhhbiBvbmUgbG9jYXRpb24gaW4gYSBzaW5nbGUg PGxvY2F0aW9uLWluZm8+DQogICAgICBlbGVtZW50IFNIT1VMRCBvbmx5IGJlIGRvbmUgaWYgdGhl eSBmb3JtIGEgY29tcGxleCB0byBkZXNjcmliZSB0aGUNCiAgICAgIHNhbWUgbG9jYXRpb24uICBG b3IgZXhhbXBsZSwgYSBnZW9kZXRpYyBsb2NhdGlvbiBkZXNjcmliaW5nIGENCiAgICAgIHBvaW50 LCBhbmQgYSBjaXZpYyBsb2NhdGlvbiBpbmRpY2F0aW5nIHRoZSBmbG9vciBpbiBhIGJ1aWxkaW5n Lg0KICAgUnVsZSAjODogV2hlcmUgYSBQSURGIGRvY3VtZW50IGNvbnRhaW5zIG1vcmUgdGhhbiBv bmUgdHVwbGUNCiAgICAgIGNvbnRhaW5pbmcgYSBzdGF0dXMgZWxlbWVudCB3aXRoIGEgZ2VvcHJp diBsb2NhdGlvbiBlbGVtZW50ICwgdGhlDQogICAgICBwcmlvcml0eSBvZiB0dXBsZXMgU0hPVUxE IGJlIGJhc2VkIG9uIHR1cGxlIHBvc2l0aW9uIHdpdGhpbiB0aGUNCiAgICAgIFBJREYgZG9jdW1l bnQuICBUaGF0IGlzIHRvIHNheSwgdGhlIHR1cGxlIHdpdGggdGhlIGhpZ2hlc3QNCiAgICAgIHBy aW9yaXR5IGxvY2F0aW9uIG9jY3VycyBlYXJsaWVzdCBpbiB0aGUgUElERiBkb2N1bWVudC4gIElu aXRpYWwNCiAgICAgIHByaW9yaXR5IFNIT1VMRCBiZSBkZXRlcm1pbmVkIGJ5IHRoZSBvcmlnaW5h dGluZyBVQSwgdGhlIGZpbmFsDQogICAgICBwcmlvcml0eSBNQVkgYmUgZGV0ZXJtaW5lZCBieSBh IHByb3h5IGFsb25nIHRoZSB3YXksIG9yIHRoZSBVQVMuDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBIYW5uZXMgVHNjaG9mZW5pZyBbbWFpbHRvOmhhbm5lcy50c2No b2ZlbmlnQHNpZW1lbnMuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIDcgSnVuZSAyMDA2IDk6MzAg UE0NCj4gVG86IGVjcml0QGlldGYub3JnDQo+IFN1YmplY3Q6IFtFY3JpdF0gW2lzc3VlMl0gSXMg aXQgYWxsb3dlZCB0byBzcGVjaWZ5IGNpdmljIGFuZCBnZW9zcGF0aWFsDQo+IGluZm9pbnRvIHRo ZSBxdWVyeT8NCj4gDQo+IA0KPiBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdA Z214Lm5ldD4gYWRkZWQgdGhlIGNvbW1lbnQ6DQo+IA0KPiBURU5UQVRJVkUgU1VNTUFSWToNCj4g DQo+IEhlcmUgaXMgdGhlIHVwZGF0ZToNCj4gDQo+ICogRWl0aGVyIGNpdmljIE9SIGdlb3NwYXRp YWwgaW4gYSBMb1NUIHF1ZXJ5DQo+IA0KPiBNYXJjLCBIZW5uaW5nLCBTaGlkYSwgUmljaGFyZCwg QnJpYW4sIEpvaG4gU2Nobml6bGVpbiwgQnlyb24gU21pdGgsDQo+IA0KPiANCj4gKiBCb3RoIGNp dmljIEFORCBnZW9zcGF0aWFsIHBvc3NpYmxlIGluIGEgTG9TVCBxdWVyeQ0KPiANCj4gUm9nZXIs IE1hcnRpbiwgQW5keSwgSmFtZXMgVy4NCj4gDQo+IFRoZXNlIGZvbGtzIGRvbid0IHNlZW0gdG8g dGFrZSBhIGNsZWFyIHBvc2l0aW9uOg0KPiANCj4gSm9obiBIZWFydHksIEplYW4tRnJhbmNvaXMs IENsaXZlIEQuVy4gRmVhdGhlcg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gTG9TVCBJc3N1ZSBUcmFja2VyIDxoYW5uZXMudHNjaG9m ZW5pZ0BzaWVtZW5zLmNvbT4NCj4gPGh0dHA6Ly93d3cudHNjaG9mZW5pZy5jb206ODA4MC9sb3N0 L2lzc3VlMj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IEVjcml0IG1haWxpbmcgbGlzdA0KPiBFY3JpdEBpZXRmLm9yZw0KPiBodHRwczovL3d3 dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQg cmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwg b3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVk IGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBk ZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwg aXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K W21mMl0= --===============1568010199== 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 --===============1568010199==-- From ecrit-bounces@ietf.org Wed Jun 07 19:01:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo71U-0007Tf-MS; Wed, 07 Jun 2006 19:01:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo71T-0007Ta-AF for ecrit@ietf.org; Wed, 07 Jun 2006 19:01:11 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo71P-0002Ak-SW for ecrit@ietf.org; Wed, 07 Jun 2006 19:01:11 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 7 Jun 2006 16:01:06 -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] [issue9] LoST Response with PSAP Preference Date: Wed, 7 Jun 2006 16:01:05 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657505191887@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [issue9] LoST Response with PSAP Preference Thread-Index: AcaKfvgH3O3Y7S4xQHyncp3d6++FAAABEXbQ From: "Roger Marshall" To: "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 When walking onto a campus, a call for emergency services shouldn't result in two different scenarios, depending on which device/media you're using. Though this is what happens in today's world. Today, PSAP routing is inconsistent by technology, (you get campus PSAP when using wired vs. city PSAP when using wireless). I think the inconsistency should be fixed and it seems to me that LoST could help fix it. I'm not promoting call-time user interaction with the returned set of URIs, but rather when multiples are returned, that the device selects the first one, and if for some reason it doesn't work, then the device selects the second URI to route the call. The order in which the URIs are returned is a LoST Server setting (based on jurisdiction agreement). On the other hand, it now also occurs to me that we might want to consider a user specified profile driven return order under certain circumstances (let's say there is no way you want campus police to come to your aid). This one would probably be less controversial in a commercial context for example, where you might want to exclude one brand of gas station from being included in the returned list (e.g., since they had a worse track record with oil-spills). Roger Marshall >-----Original Message----- >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 >Sent: Wednesday, June 07, 2006 3:08 PM >To: Roger Marshall >Cc: LoST Issue Tracker; ecrit@ietf.org >Subject: Re: [Ecrit] [issue9] LoST Response with PSAP Preference > >> The question then is whether the campus wants to be the=20 >first to know=20 >> about the fire (to evacuate), or the local jurisdiction (to roll=20 >> trucks). I think all I'm trying to say is that the LoST protocol=20 >> should support ordering, and to point out a use case wherein it may=20 >> need to be configurable based on location. > >This goes back to my earlier note. When getting these two=20 >URLs, what would a client do with this? Would you indicate > >"if you don't like the amateur cops from the University=20 >[URL1], please call the real ones from the NYPD [URL2]" > >? > >Or would you always indicate a hierarchy of services, as in > >campus police >NYPD >NY state troopers >FBI > >Since this mapping is for the PSAP, not the actual first=20 >responders, I always thought it was the job of the campus PSAP=20 >to decide whether to call in the city cops. At least, this is=20 >how it works on our campus (for on-campus calls). > >Henning > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 19:03:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo740-0001Jy-RW; Wed, 07 Jun 2006 19:03:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo73z-0001Jt-P8 for ecrit@ietf.org; Wed, 07 Jun 2006 19:03:47 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo73z-0002FH-3g for ecrit@ietf.org; Wed, 07 Jun 2006 19:03:47 -0400 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.6.118]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k57MxLR06700; Wed, 7 Jun 2006 16:59:21 -0600 Message-ID: <44875C62.2090907@ntt-at.com> Date: Wed, 07 Jun 2006 16:08:18 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Ecrit] [issue2] Is it allowed to specifycivicand geospatialinfointo the query? References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ff67cea9f7df2d77f61a364cea0926e8 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I am really LoST here and I hope I am the only one. Is PIDF-LO used for LoST query or not and if not where is this written? Anyhow, I think we are saying that LoST client whether it's UAC or Proxy needs to decide on the best suited location to be used for querying LoST server. This best suited location will vary depending on the implementation and deployment scenario. For example, if UAC doesn't support the LoST protocol, and it's the proxy that needs to query the LoST server on behalf of the UAC If there is a PIDF-LO inside the INVITE, the proxy needs to strip one of the location element in PIDF-LO if more than one is present and query the LoST server to obtain the PSAP URI to route a call. I think if UAC can't make the decision, proxy will generally have a better chance of knowing which location is more accurate for UAC (Of course there are a lot of corner cases to this.. VPN + client not supporting location etc.) than the LoST server as proxy will have a better idea of where the call has been routed thus far. I understand that the LoST server only gets service-URN and location. It does not receive any via header or route header to help aid with the decision of which location might be more appropriate. (If PIDF-LO with "provided-by" is present via/route header might be used to prioritize the location used.) Regards Shida Winterbottom, James wrote: > I agree with Roger here. > In the immediate future, and I suspect that for quite some time, routing > decisions based on location will come from centralized call server > implementations. If the call server gets a PIDF-LO it will, at best, > simply grab everything in every location-info element and send it > upwards, unless you are suggesting that the call server make the > decision about which location to use. I would argue that the call-server > is in an even less good position to make this decision than the LoST > server. At least the LoST server is already required to have some rules > and information with regards to making routing decisions. > > Cheers > James > > >> -----Original Message----- >> From: Roger Marshall [mailto:RMarshall@telecomsys.com] >> Sent: Thursday, 8 June 2006 6:14 AM >> To: Tom-PT Taylor >> Cc: ecrit@ietf.org >> Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivicand >> geospatialinfointo the query? >> >> Tom: >> I don't restrict the LoST client to be end device (UA). As discussed, >> LoST queries could be done node by node. As an example, LoST clients >> could take the form of near or far proxies (ESRPs) for stepwise >> location-to-uri resolution, whether done in a by-value or by-reference >> model, or the PSAP UA (CPE), in case of PSAP transfer, etc. >> >> I guess my main point is that (in many cases) this notion of LoST >> > client > >> decision making is a client-heavy approach, done in an environment >> > where > >> clients outnumber servers by 4-1 (um=orders of magnitude!). >> >> Roger. >> >> >> >>> -----Original Message----- >>> From: Tom-PT Taylor [mailto:taylor@nortel.com] >>> Sent: Wednesday, June 07, 2006 12:23 PM >>> To: Roger Marshall >>> Cc: Hannes Tschofenig; ecrit@ietf.org >>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify >>> civicand geospatialinfointo the query? >>> >>> You seem to be assuming that the LoST client is the user >>> terminal, and at the same time assuming that it has to parse >>> PIDF-LO. This doesn't make sense to me -- won't it be the >>> originator of the PIDF-LO and have the raw data in hand? >>> >>> Roger Marshall wrote: >>> >>>> I admit that this theme is somewhat of a tangent to the subject, >>>> > but > >>>> can the authors of LoST help me understand the reasons for not >>>> > using > >>>> the PIDF-LO. >>>> >>>> Is it the overhead? Is the PIDF-LO not adequate to convey location >>>> some how? >>>> >>>> As an example, if the PIDF-LO format is changed >>>> >>> significantly in some >>> >>>> way, it will mandate a s/w change to ~10^8 clients vs. only ~10^2 - >>>> 10^4 server instances. >>>> >>>> It seems to me that as the PIDF-LO undergoes changes over time, >>>> > that > >>>> the choice between having to modify client software vs. server >>>> software instances represents a huge difference in effort. >>>> >>>> >>>> Roger Marshall >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>> Sent: Monday, June 05, 2006 2:24 PM >>>>> To: Roger Marshall >>>>> Cc: Brian Rosen; ecrit@ietf.org >>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >>>>> geospatialinfointo the query? >>>>> >>>>> Hi Roger, >>>>> >>>>> Roger Marshall wrote: >>>>> >>>>>> Hannes: Thanks for clarifying. >>>>>> >>>>>> I think it's a bad idea to withold location information from >>>>>> >>>>> the LoST >>>>> >>>>>> server. >>>>>> >>>>>> To suggest that we restrict the client, allowing only one to >>>>>> >>>>> be sent, >>>>> >>>>>> sounds to me like we're placing a constraint on the PIDF-LO, >>>>>> >>>>> saying it >>>>> >>>>>> can't have both (assuming LoST reuses the PIDF-LO). I >>>>>> >>> don't think we >>> >>>>>> can get away with that. If the PIDF-LO has both, how is it >>>>>> >>>>> that we can >>>>> >>>>>> glibly strip one out? To do so would be unreasonable. >>>>>> >>>>> To clarify: >>>>> >>>>> * You can send as many queries as you want but not with the same >>>>> message. Different location information => different query >>>>> >>>>> * We don't use a PIDF-LO in LoST. We use the raw location info. >>>>> >>>>> >>>>>> Since the client can have both civic and geo in the >>>>>> >>> PIDF-LO, it can >>> >>>>>> also send both to the server. What am I missing? >>>>>> >>>>> None of the proposals ever used a PIDF-LO as input; just >>>>> >>> location info. >>> >>>>>> It's the LoST server's job to pick one, not the client's. >>>>>> >>>>> At the PSAP and the emergency routing proxy I agree with you. >>>>> >>>>> >>>>>> So, the requirement I would support is as follows: >>>>>> >>>>>> Rx' LoST client SHALL query with either civic or geo. >>>>>> >>>>> That's fine. >>>>> >>>>> >>>>> >>>>>> Ry' LoST client SHOULD query with *both* civic and geo. When >>>>>> > LoST > >>>>>> server receives both civic and geo, the server SHOULD try >>>>>> >>> to use the >>> >>>>>> geo first. The LoST server response SHALL indicate which data >>>>>> > was > >>>>>> used (either geo or civic). >>>>>> >>>>> I guess you will not support for this one based on the >>>>> >>> response I saw >>> >>>>> on the list so far. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> >>>>>> -roger. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>> Sent: Monday, June 05, 2006 1:50 PM >>>>>>> To: Roger Marshall >>>>>>> Cc: Brian Rosen; ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >>>>>>> geospatialinfointo the query? >>>>>>> >>>>>>> Hi Roger, >>>>>>> >>>>>>> I think the current suggestion is that the LoST client just >>>>>>> > picks > >>>>>>> whatever he wants and then uses the mapping protocol to >>>>>>> >>> trigger the >>> >>>>>>> resolution. >>>>>>> >>>>>>> Using geo and civic might be, from a certain point of view, >>>>>>> >>>>> just be an >>>>> >>>>>>> optimization. The LoST client can always trigger separate >>>>>>> >>>>> queries with >>>>> >>>>>>> all the location info it has. >>>>>>> >>>>>>> Ciao >>>>>>> Hannes >>>>>>> >>>>>>> Roger Marshall wrote: >>>>>>> >>>>>>> >>>>>>>> I don't disagree that we ask the LoST server to pick one and >>>>>>>> >>>>>>> use it. >>>>>>> >>>>>>> >>>>>>>> We need to be consistent though, and so therefore, I propose >>>>>>>> >>>>>>> that the >>>>>>> >>>>>>> >>>>>>>> LoST server always picks the geo over the civic and returns >>>>>>>> >>>>>>> a flag in >>>>>>> >>>>>>> >>>>>>>> the response stating that the geo was used to perform mapping. >>>>>>>> >>>>>>>> Roger. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>> Sent: Monday, June 05, 2006 1:39 PM >>>>>>>>> To: Brian Rosen >>>>>>>>> Cc: ecrit@ietf.org >>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify >>>>>>>>> >>> civic and >>> >>>>>>>>> geospatialinfointo the query? >>>>>>>>> >>>>>>>>> It seems that we closed this issue. >>>>>>>>> >>>>>>>>> Everyone seems to be in favor for a civic OR geospatial. >>>>>>>>> Extensions possible for future applications. >>>>>>>>> >>>>>>>>> Ciao >>>>>>>>> Hannes >>>>>>>>> >>>>>>>>> Brian Rosen wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> I think this is the issue. There is no guidance we >>>>>>>>>> >>> can give the >>> >>>>>>>>>> server to tell it how to resolve what to do when both >>>>>>>>>> >>>>>>> locations are >>>>>>> >>>>>>> >>>>>>>>>> valid but the URI for the geo does match the URI for the >>>>>>>>>> > civic. > >>>>>>>>>> This happens a lot when you are near boundaries because the >>>>>>>>>> >>>>>>>>> precision >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> and accuracy of the two methods differ. >>>>>>>>>> >>>>>>>>>> I think you pick ONE and use it. >>>>>>>>>> >>>>>>>>>> Even if you send more than one along, the PSAP has to know >>>>>>>>>> >>>>>>> which one >>>>>>> >>>>>>> >>>>>>>>>> you used to route. It's going to continue to use that >>>>>>>>>> >>>>>>> until a human >>>>>>> >>>>>>> >>>>>>>>>> says otherwise. >>>>>>>>>> >>>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>>>>>>> Sent: Monday, June 05, 2006 3:55 PM >>>>>>>>>> To: Andrew Newton >>>>>>>>>> Cc: ecrit@ietf.org >>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify >>>>>>>>>> >>> civic and >>> >>>>>>>>>> geospatialinfo into the query? >>>>>>>>>> >>>>>>>>>> At the PSAP, we have a human that can look at this >>>>>>>>>> >>>>> information and >>>>> >>>>>>>>>> make decisions (and maybe even ask if there's a >>>>>>>>>> >>>>> discrepancy). That >>>>> >>>>>>>>>> seems a stretch for the LoST server. >>>>>>>>>> >>>>>>>>>> Andrew Newton wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> In all of these dual-information cases, I don't see how >>>>>>>>>>>> anybody except the seeker can make any determination which >>>>>>>>>>>> type of information is better, more accurate, more >>>>>>>>>>>> >>> recent, etc. >>> >>>>>>>>>>> Would we want the seeker to determine which information it >>>>>>>>>>> >>>>>>> feels is >>>>>>> >>>>>>> >>>>>>>>>>> best to provide to the PSAP? I've always heard that the >>>>>>>>>>> >>>>>>>>> answer would be no: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> provide both to the PSAP. So why then would we not >>>>>>>>>>> >>>>>>> provide the same >>>>>>> >>>>>>> >>>>>>>>>>> information when determining which PSAP to contact? >>>>>>>>>>> >>>>>>>>>>> -andy >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Ecrit mailing list >>>>>>>>>> Ecrit@ietf.org >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Ecrit mailing list >>>>>>>>>> Ecrit@ietf.org >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Ecrit mailing list >>>>>>>>> Ecrit@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>> >>>>>>>>> >>>>>>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 19:32:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo7Vk-0003GO-Pz; Wed, 07 Jun 2006 19:32:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo7Vk-0003GJ-8Z for ecrit@ietf.org; Wed, 07 Jun 2006 19:32:28 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo7Vi-00035G-Oj for ecrit@ietf.org; Wed, 07 Jun 2006 19:32:28 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k57NWLK10988; Wed, 7 Jun 2006 19:32:22 -0400 (EDT) Received: from [127.0.0.1] ([47.130.17.72] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 19:32:15 -0400 Message-ID: <448761F7.3030204@nortel.com> Date: Wed, 07 Jun 2006 19:32:07 -0400 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Ecrit] [issue2] Is it allowed to specifycivicand geospatialinfointo the query? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2006 23:32:15.0318 (UTC) FILETIME=[9BF36F60:01C68A8A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org If I were a programmer faced with making such a decision in the call server, I would always choose the first location I found in the PIDF-LO. That's simple enough. Winterbottom, James wrote: > I agree with Roger here. > In the immediate future, and I suspect that for quite some time, routing > decisions based on location will come from centralized call server > implementations. If the call server gets a PIDF-LO it will, at best, > simply grab everything in every location-info element and send it > upwards, unless you are suggesting that the call server make the > decision about which location to use. I would argue that the call-server > is in an even less good position to make this decision than the LoST > server. At least the LoST server is already required to have some rules > and information with regards to making routing decisions. > > Cheers > James > >> -----Original Message----- >> From: Roger Marshall [mailto:RMarshall@telecomsys.com] >> Sent: Thursday, 8 June 2006 6:14 AM >> To: Tom-PT Taylor >> Cc: ecrit@ietf.org >> Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivicand >> geospatialinfointo the query? >> >> Tom: >> I don't restrict the LoST client to be end device (UA). As discussed, >> LoST queries could be done node by node. As an example, LoST clients >> could take the form of near or far proxies (ESRPs) for stepwise >> location-to-uri resolution, whether done in a by-value or by-reference >> model, or the PSAP UA (CPE), in case of PSAP transfer, etc. >> >> I guess my main point is that (in many cases) this notion of LoST > client >> decision making is a client-heavy approach, done in an environment > where >> clients outnumber servers by 4-1 (um=orders of magnitude!). >> >> Roger. >> >> >>> -----Original Message----- >>> From: Tom-PT Taylor [mailto:taylor@nortel.com] >>> Sent: Wednesday, June 07, 2006 12:23 PM >>> To: Roger Marshall >>> Cc: Hannes Tschofenig; ecrit@ietf.org >>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify >>> civicand geospatialinfointo the query? >>> >>> You seem to be assuming that the LoST client is the user >>> terminal, and at the same time assuming that it has to parse >>> PIDF-LO. This doesn't make sense to me -- won't it be the >>> originator of the PIDF-LO and have the raw data in hand? >>> >>> Roger Marshall wrote: >>>> I admit that this theme is somewhat of a tangent to the subject, > but >>>> can the authors of LoST help me understand the reasons for not > using >>>> the PIDF-LO. >>>> >>>> Is it the overhead? Is the PIDF-LO not adequate to convey location >>>> some how? >>>> >>>> As an example, if the PIDF-LO format is changed >>> significantly in some >>>> way, it will mandate a s/w change to ~10^8 clients vs. only ~10^2 - >>>> 10^4 server instances. >>>> >>>> It seems to me that as the PIDF-LO undergoes changes over time, > that >>>> the choice between having to modify client software vs. server >>>> software instances represents a huge difference in effort. >>>> >>>> >>>> Roger Marshall >>>> >>>> >>>>> -----Original Message----- >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>> Sent: Monday, June 05, 2006 2:24 PM >>>>> To: Roger Marshall >>>>> Cc: Brian Rosen; ecrit@ietf.org >>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >>>>> geospatialinfointo the query? >>>>> >>>>> Hi Roger, >>>>> >>>>> Roger Marshall wrote: >>>>>> Hannes: Thanks for clarifying. >>>>>> >>>>>> I think it's a bad idea to withold location information from >>>>> the LoST >>>>>> server. >>>>>> >>>>>> To suggest that we restrict the client, allowing only one to >>>>> be sent, >>>>>> sounds to me like we're placing a constraint on the PIDF-LO, >>>>> saying it >>>>>> can't have both (assuming LoST reuses the PIDF-LO). I >>> don't think we >>>>>> can get away with that. If the PIDF-LO has both, how is it >>>>> that we can >>>>>> glibly strip one out? To do so would be unreasonable. >>>>> To clarify: >>>>> >>>>> * You can send as many queries as you want but not with the same >>>>> message. Different location information => different query >>>>> >>>>> * We don't use a PIDF-LO in LoST. We use the raw location info. >>>>> >>>>>> Since the client can have both civic and geo in the >>> PIDF-LO, it can >>>>>> also send both to the server. What am I missing? >>>>> None of the proposals ever used a PIDF-LO as input; just >>> location info. >>>>>> It's the LoST server's job to pick one, not the client's. >>>>> At the PSAP and the emergency routing proxy I agree with you. >>>>> >>>>>> So, the requirement I would support is as follows: >>>>>> >>>>>> Rx' LoST client SHALL query with either civic or geo. >>>>> That's fine. >>>>> >>>>> >>>>>> Ry' LoST client SHOULD query with *both* civic and geo. When > LoST >>>>>> server receives both civic and geo, the server SHOULD try >>> to use the >>>>>> geo first. The LoST server response SHALL indicate which data > was >>>>>> used (either geo or civic). >>>>> I guess you will not support for this one based on the >>> response I saw >>>>> on the list so far. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>>> -roger. >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>> Sent: Monday, June 05, 2006 1:50 PM >>>>>>> To: Roger Marshall >>>>>>> Cc: Brian Rosen; ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >>>>>>> geospatialinfointo the query? >>>>>>> >>>>>>> Hi Roger, >>>>>>> >>>>>>> I think the current suggestion is that the LoST client just > picks >>>>>>> whatever he wants and then uses the mapping protocol to >>> trigger the >>>>>>> resolution. >>>>>>> >>>>>>> Using geo and civic might be, from a certain point of view, >>>>> just be an >>>>>>> optimization. The LoST client can always trigger separate >>>>> queries with >>>>>>> all the location info it has. >>>>>>> >>>>>>> Ciao >>>>>>> Hannes >>>>>>> >>>>>>> Roger Marshall wrote: >>>>>>> >>>>>>>> I don't disagree that we ask the LoST server to pick one and >>>>>>> use it. >>>>>>> >>>>>>>> We need to be consistent though, and so therefore, I propose >>>>>>> that the >>>>>>> >>>>>>>> LoST server always picks the geo over the civic and returns >>>>>>> a flag in >>>>>>> >>>>>>>> the response stating that the geo was used to perform mapping. >>>>>>>> >>>>>>>> Roger. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>> Sent: Monday, June 05, 2006 1:39 PM >>>>>>>>> To: Brian Rosen >>>>>>>>> Cc: ecrit@ietf.org >>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify >>> civic and >>>>>>>>> geospatialinfointo the query? >>>>>>>>> >>>>>>>>> It seems that we closed this issue. >>>>>>>>> >>>>>>>>> Everyone seems to be in favor for a civic OR geospatial. >>>>>>>>> Extensions possible for future applications. >>>>>>>>> >>>>>>>>> Ciao >>>>>>>>> Hannes >>>>>>>>> >>>>>>>>> Brian Rosen wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> I think this is the issue. There is no guidance we >>> can give the >>>>>>>>>> server to tell it how to resolve what to do when both >>>>>>> locations are >>>>>>> >>>>>>>>>> valid but the URI for the geo does match the URI for the > civic. >>>>>>>>>> This happens a lot when you are near boundaries because the >>>>>>>>> precision >>>>>>>>> >>>>>>>>> >>>>>>>>>> and accuracy of the two methods differ. >>>>>>>>>> >>>>>>>>>> I think you pick ONE and use it. >>>>>>>>>> >>>>>>>>>> Even if you send more than one along, the PSAP has to know >>>>>>> which one >>>>>>> >>>>>>>>>> you used to route. It's going to continue to use that >>>>>>> until a human >>>>>>> >>>>>>>>>> says otherwise. >>>>>>>>>> >>>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>>>>>>> Sent: Monday, June 05, 2006 3:55 PM >>>>>>>>>> To: Andrew Newton >>>>>>>>>> Cc: ecrit@ietf.org >>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify >>> civic and >>>>>>>>>> geospatialinfo into the query? >>>>>>>>>> >>>>>>>>>> At the PSAP, we have a human that can look at this >>>>> information and >>>>>>>>>> make decisions (and maybe even ask if there's a >>>>> discrepancy). That >>>>>>>>>> seems a stretch for the LoST server. >>>>>>>>>> >>>>>>>>>> Andrew Newton wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> In all of these dual-information cases, I don't see how >>>>>>>>>>>> anybody except the seeker can make any determination which >>>>>>>>>>>> type of information is better, more accurate, more >>> recent, etc. >>>>>>>>>>> Would we want the seeker to determine which information it >>>>>>> feels is >>>>>>> >>>>>>>>>>> best to provide to the PSAP? I've always heard that the >>>>>>>>> answer would be no: >>>>>>>>> >>>>>>>>> >>>>>>>>>>> provide both to the PSAP. So why then would we not >>>>>>> provide the same >>>>>>> >>>>>>>>>>> information when determining which PSAP to contact? >>>>>>>>>>> >>>>>>>>>>> -andy >>>>>>>>>> _______________________________________________ >>>>>>>>>> Ecrit mailing list >>>>>>>>>> Ecrit@ietf.org >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Ecrit mailing list >>>>>>>>>> Ecrit@ietf.org >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Ecrit mailing list >>>>>>>>> Ecrit@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>> >>>>>>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>> >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 19:55:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo7sP-0003s0-W0; Wed, 07 Jun 2006 19:55:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo7sO-0003rr-8V for ecrit@ietf.org; Wed, 07 Jun 2006 19:55:52 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo7sN-0005mO-1o for ecrit@ietf.org; Wed, 07 Jun 2006 19:55:52 -0400 Received: from [192.168.0.41] (pool-138-89-46-232.mad.east.verizon.net [138.89.46.232]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k57Ntchl007936 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 7 Jun 2006 19:55:41 -0400 (EDT) In-Reply-To: <448761F7.3030204@nortel.com> References: <448761F7.3030204@nortel.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4103F191-F253-49BE-A0A8-C3E8960E4A45@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] [issue2] Is it allowed to specifycivicand geospatialinfointo the query? Date: Wed, 7 Jun 2006 19:55:36 -0400 To: "Tom-PT Taylor" X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org In many cases, the call server (I assume you mean SIP proxy) might at least have obtained the information, so it has a better clue where it came from (subscriber record? user entered?) and thus might have a chance to pick the "best" one. As likely as Tom's predicted outcome is the other one: programmers will pick whatever they feel like it or make it configurable, so that the outcome will depend on which version of the resolver software a particular site is running and the answers may differ as you change ISPs. We need to remember that the location information will invariably be split after the first resolver, since the hierarchy for geo and civic may differ. I just don't see a corporate LoST resolver doing much informed thinking about the merits of different location formats, particularly since there's nothing concrete and algorithmic to go by to guide the choice when it reaches the resolver. On Jun 7, 2006, at 7:32 PM, Tom-PT Taylor wrote: > If I were a programmer faced with making such a decision in the > call server, I would always choose the first location I found in > the PIDF-LO. That's simple enough. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 19:57:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo7uI-0004Il-1g; Wed, 07 Jun 2006 19:57:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo7uH-0004Ig-4w for ecrit@ietf.org; Wed, 07 Jun 2006 19:57:49 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo7uE-0005zq-HA for ecrit@ietf.org; Wed, 07 Jun 2006 19:57:49 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 18:58:12 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 07 Jun 2006 18:58:12 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 18:58:11 -0500 Message-ID: From: "Winterbottom, James" To: Date: Wed, 7 Jun 2006 18:58:07 -0500 Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivicand geospatialinfointo the query? MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 07 Jun 2006 23:58:11.0704 (UTC) FILETIME=[3BA11780:01C68A8E] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <44875C62.2090907@ntt-at.com> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] [issue2] Is it allowed to specifycivicand geospatialinfointo the query? Thread-Index: AcaKjIgW3FaDRVKvT3y/OHB8bxSmwAAAFi+A X-Spam-Score: 0.0 (/) X-Scan-Signature: 64b72a8e61417554b4b727cb14e7034d 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 Shida, The problem is, as Martin pointed out, one of cardinality. In a single PIDF-LO I and have multiple tuples, and in each tuple I can have multiple geopriv objects, and in each location-info element within a geopriv tuple I can have multiple location representations. Which do I choose? The provided-by component does not help at all in the last case since the provided-by element applies to the whole geopriv component. I think that if the representation is legal inside a location-info element, then the LoST server needs to handle it rather than expecting other nodes to dissect the location down to something that it thinks that the LoST MIGHT be able to handle. Cheers James > -----Original Message----- > From: Shida Schubert [mailto:shida@ntt-at.com] > Sent: Thursday, 8 June 2006 9:08 AM > To: Winterbottom, James > Cc: Roger Marshall; Tom-PT Taylor; ecrit@ietf.org > Subject: Re: [Ecrit] [issue2] Is it allowed to specifycivicand > geospatialinfointo the query? >=20 >=20 > I am really LoST here and I hope I am the only one. >=20 > Is PIDF-LO used for LoST query or not and if not where is > this written? >=20 > Anyhow, I think we are saying that LoST client whether it's > UAC or Proxy needs to decide on the best suited location to be > used for querying LoST server. This best suited location will vary > depending on the implementation and deployment scenario. >=20 > For example, if UAC doesn't support the LoST protocol, and it's > the proxy that needs to query the LoST server on behalf of > the UAC If there is a PIDF-LO inside the INVITE, the proxy needs > to strip one of the location element in PIDF-LO if more than one > is present and query the LoST server to obtain the PSAP URI to > route a call. >=20 > I think if UAC can't make the decision, proxy will generally have a > better chance of knowing which location is more accurate for > UAC (Of course there are a lot of corner cases to this.. VPN + client > not supporting location etc.) than the LoST server as proxy will > have a better idea of where the call has been routed thus far. >=20 > I understand that the LoST server only gets service-URN and > location. It does not receive any via header or route header to help > aid with the decision of which location might be more appropriate. > (If PIDF-LO with "provided-by" is present via/route header might > be used to prioritize the location used.) >=20 > Regards > Shida >=20 > Winterbottom, James wrote: > > I agree with Roger here. > > In the immediate future, and I suspect that for quite some time, routing > > decisions based on location will come from centralized call server > > implementations. If the call server gets a PIDF-LO it will, at best, > > simply grab everything in every location-info element and send it > > upwards, unless you are suggesting that the call server make the > > decision about which location to use. I would argue that the call-server > > is in an even less good position to make this decision than the LoST > > server. At least the LoST server is already required to have some rules > > and information with regards to making routing decisions. > > > > Cheers > > James > > > > > >> -----Original Message----- > >> From: Roger Marshall [mailto:RMarshall@telecomsys.com] > >> Sent: Thursday, 8 June 2006 6:14 AM > >> To: Tom-PT Taylor > >> Cc: ecrit@ietf.org > >> Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivicand > >> geospatialinfointo the query? > >> > >> Tom: > >> I don't restrict the LoST client to be end device (UA). As discussed, > >> LoST queries could be done node by node. As an example, LoST clients > >> could take the form of near or far proxies (ESRPs) for stepwise > >> location-to-uri resolution, whether done in a by-value or by-reference > >> model, or the PSAP UA (CPE), in case of PSAP transfer, etc. > >> > >> I guess my main point is that (in many cases) this notion of LoST > >> > > client > > > >> decision making is a client-heavy approach, done in an environment > >> > > where > > > >> clients outnumber servers by 4-1 (um=3Dorders of magnitude!). > >> > >> Roger. > >> > >> > >> > >>> -----Original Message----- > >>> From: Tom-PT Taylor [mailto:taylor@nortel.com] > >>> Sent: Wednesday, June 07, 2006 12:23 PM > >>> To: Roger Marshall > >>> Cc: Hannes Tschofenig; ecrit@ietf.org > >>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify > >>> civicand geospatialinfointo the query? > >>> > >>> You seem to be assuming that the LoST client is the user > >>> terminal, and at the same time assuming that it has to parse > >>> PIDF-LO. This doesn't make sense to me -- won't it be the > >>> originator of the PIDF-LO and have the raw data in hand? > >>> > >>> Roger Marshall wrote: > >>> > >>>> I admit that this theme is somewhat of a tangent to the subject, > >>>> > > but > > > >>>> can the authors of LoST help me understand the reasons for not > >>>> > > using > > > >>>> the PIDF-LO. > >>>> > >>>> Is it the overhead? Is the PIDF-LO not adequate to convey location > >>>> some how? > >>>> > >>>> As an example, if the PIDF-LO format is changed > >>>> > >>> significantly in some > >>> > >>>> way, it will mandate a s/w change to ~10^8 clients vs. only ~10^2 - > >>>> 10^4 server instances. > >>>> > >>>> It seems to me that as the PIDF-LO undergoes changes over time, > >>>> > > that > > > >>>> the choice between having to modify client software vs. server > >>>> software instances represents a huge difference in effort. > >>>> > >>>> > >>>> Roger Marshall > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>> Sent: Monday, June 05, 2006 2:24 PM > >>>>> To: Roger Marshall > >>>>> Cc: Brian Rosen; ecrit@ietf.org > >>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and > >>>>> geospatialinfointo the query? > >>>>> > >>>>> Hi Roger, > >>>>> > >>>>> Roger Marshall wrote: > >>>>> > >>>>>> Hannes: Thanks for clarifying. > >>>>>> > >>>>>> I think it's a bad idea to withold location information from > >>>>>> > >>>>> the LoST > >>>>> > >>>>>> server. > >>>>>> > >>>>>> To suggest that we restrict the client, allowing only one to > >>>>>> > >>>>> be sent, > >>>>> > >>>>>> sounds to me like we're placing a constraint on the PIDF-LO, > >>>>>> > >>>>> saying it > >>>>> > >>>>>> can't have both (assuming LoST reuses the PIDF-LO). I > >>>>>> > >>> don't think we > >>> > >>>>>> can get away with that. If the PIDF-LO has both, how is it > >>>>>> > >>>>> that we can > >>>>> > >>>>>> glibly strip one out? To do so would be unreasonable. > >>>>>> > >>>>> To clarify: > >>>>> > >>>>> * You can send as many queries as you want but not with the same > >>>>> message. Different location information =3D> different query > >>>>> > >>>>> * We don't use a PIDF-LO in LoST. We use the raw location info. > >>>>> > >>>>> > >>>>>> Since the client can have both civic and geo in the > >>>>>> > >>> PIDF-LO, it can > >>> > >>>>>> also send both to the server. What am I missing? > >>>>>> > >>>>> None of the proposals ever used a PIDF-LO as input; just > >>>>> > >>> location info. > >>> > >>>>>> It's the LoST server's job to pick one, not the client's. > >>>>>> > >>>>> At the PSAP and the emergency routing proxy I agree with you. > >>>>> > >>>>> > >>>>>> So, the requirement I would support is as follows: > >>>>>> > >>>>>> Rx' LoST client SHALL query with either civic or geo. > >>>>>> > >>>>> That's fine. > >>>>> > >>>>> > >>>>> > >>>>>> Ry' LoST client SHOULD query with *both* civic and geo. When > >>>>>> > > LoST > > > >>>>>> server receives both civic and geo, the server SHOULD try > >>>>>> > >>> to use the > >>> > >>>>>> geo first. The LoST server response SHALL indicate which data > >>>>>> > > was > > > >>>>>> used (either geo or civic). > >>>>>> > >>>>> I guess you will not support for this one based on the > >>>>> > >>> response I saw > >>> > >>>>> on the list so far. > >>>>> > >>>>> Ciao > >>>>> Hannes > >>>>> > >>>>> > >>>>>> -roger. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>>>> Sent: Monday, June 05, 2006 1:50 PM > >>>>>>> To: Roger Marshall > >>>>>>> Cc: Brian Rosen; ecrit@ietf.org > >>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and > >>>>>>> geospatialinfointo the query? > >>>>>>> > >>>>>>> Hi Roger, > >>>>>>> > >>>>>>> I think the current suggestion is that the LoST client just > >>>>>>> > > picks > > > >>>>>>> whatever he wants and then uses the mapping protocol to > >>>>>>> > >>> trigger the > >>> > >>>>>>> resolution. > >>>>>>> > >>>>>>> Using geo and civic might be, from a certain point of view, > >>>>>>> > >>>>> just be an > >>>>> > >>>>>>> optimization. The LoST client can always trigger separate > >>>>>>> > >>>>> queries with > >>>>> > >>>>>>> all the location info it has. > >>>>>>> > >>>>>>> Ciao > >>>>>>> Hannes > >>>>>>> > >>>>>>> Roger Marshall wrote: > >>>>>>> > >>>>>>> > >>>>>>>> I don't disagree that we ask the LoST server to pick one and > >>>>>>>> > >>>>>>> use it. > >>>>>>> > >>>>>>> > >>>>>>>> We need to be consistent though, and so therefore, I propose > >>>>>>>> > >>>>>>> that the > >>>>>>> > >>>>>>> > >>>>>>>> LoST server always picks the geo over the civic and returns > >>>>>>>> > >>>>>>> a flag in > >>>>>>> > >>>>>>> > >>>>>>>> the response stating that the geo was used to perform mapping. > >>>>>>>> > >>>>>>>> Roger. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>>>>>> Sent: Monday, June 05, 2006 1:39 PM > >>>>>>>>> To: Brian Rosen > >>>>>>>>> Cc: ecrit@ietf.org > >>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify > >>>>>>>>> > >>> civic and > >>> > >>>>>>>>> geospatialinfointo the query? > >>>>>>>>> > >>>>>>>>> It seems that we closed this issue. > >>>>>>>>> > >>>>>>>>> Everyone seems to be in favor for a civic OR geospatial. > >>>>>>>>> Extensions possible for future applications. > >>>>>>>>> > >>>>>>>>> Ciao > >>>>>>>>> Hannes > >>>>>>>>> > >>>>>>>>> Brian Rosen wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> I think this is the issue. There is no guidance we > >>>>>>>>>> > >>> can give the > >>> > >>>>>>>>>> server to tell it how to resolve what to do when both > >>>>>>>>>> > >>>>>>> locations are > >>>>>>> > >>>>>>> > >>>>>>>>>> valid but the URI for the geo does match the URI for the > >>>>>>>>>> > > civic. > > > >>>>>>>>>> This happens a lot when you are near boundaries because the > >>>>>>>>>> > >>>>>>>>> precision > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> and accuracy of the two methods differ. > >>>>>>>>>> > >>>>>>>>>> I think you pick ONE and use it. > >>>>>>>>>> > >>>>>>>>>> Even if you send more than one along, the PSAP has to know > >>>>>>>>>> > >>>>>>> which one > >>>>>>> > >>>>>>> > >>>>>>>>>> you used to route. It's going to continue to use that > >>>>>>>>>> > >>>>>>> until a human > >>>>>>> > >>>>>>> > >>>>>>>>>> says otherwise. > >>>>>>>>>> > >>>>>>>>>> Brian > >>>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>>>>>>>>> Sent: Monday, June 05, 2006 3:55 PM > >>>>>>>>>> To: Andrew Newton > >>>>>>>>>> Cc: ecrit@ietf.org > >>>>>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify > >>>>>>>>>> > >>> civic and > >>> > >>>>>>>>>> geospatialinfo into the query? > >>>>>>>>>> > >>>>>>>>>> At the PSAP, we have a human that can look at this > >>>>>>>>>> > >>>>> information and > >>>>> > >>>>>>>>>> make decisions (and maybe even ask if there's a > >>>>>>>>>> > >>>>> discrepancy). That > >>>>> > >>>>>>>>>> seems a stretch for the LoST server. > >>>>>>>>>> > >>>>>>>>>> Andrew Newton wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> In all of these dual-information cases, I don't see how > >>>>>>>>>>>> anybody except the seeker can make any determination which > >>>>>>>>>>>> type of information is better, more accurate, more > >>>>>>>>>>>> > >>> recent, etc. > >>> > >>>>>>>>>>> Would we want the seeker to determine which information it > >>>>>>>>>>> > >>>>>>> feels is > >>>>>>> > >>>>>>> > >>>>>>>>>>> best to provide to the PSAP? I've always heard that the > >>>>>>>>>>> > >>>>>>>>> answer would be no: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> provide both to the PSAP. So why then would we not > >>>>>>>>>>> > >>>>>>> provide the same > >>>>>>> > >>>>>>> > >>>>>>>>>>> information when determining which PSAP to contact? > >>>>>>>>>>> > >>>>>>>>>>> -andy > >>>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Ecrit mailing list > >>>>>>>>>> Ecrit@ietf.org > >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Ecrit mailing list > >>>>>>>>>> Ecrit@ietf.org > >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Ecrit mailing list > >>>>>>>>> Ecrit@ietf.org > >>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>> > >>>> > >>> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > >> > > > > ------------------------------------------------------------------------ > ------------------------ > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > ------------------------------------------------------------------------ > ------------------------ > > [mf2] > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > >=20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 20:07:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo844-0003SC-Ov; Wed, 07 Jun 2006 20:07:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo843-0003S7-G7 for ecrit@ietf.org; Wed, 07 Jun 2006 20:07:55 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo842-0007BC-8r for ecrit@ietf.org; Wed, 07 Jun 2006 20:07:55 -0400 Received: from [192.168.0.41] (pool-138-89-46-232.mad.east.verizon.net [138.89.46.232]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k5807e46009026 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 7 Jun 2006 20:07:41 -0400 (EDT) In-Reply-To: <8C837214C95C864C9F34F3635C2A657505191887@SEA-EXCHVS-2.telecomsys.com> References: <8C837214C95C864C9F34F3635C2A657505191887@SEA-EXCHVS-2.telecomsys.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8FFB15E2-C546-4D94-8EBD-5F145E74169D@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] [issue9] LoST Response with PSAP Preference Date: Wed, 7 Jun 2006 20:07:37 -0400 To: "Roger Marshall" X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Storing user profiles on LoST servers hasn't really been part of the discussion so far. I wonder if there's a simple label we can apply to URLs, such as "public" and "private" or "campus" (and maybe a human-readable string since the decision which to call seems rather hard to automate). By the way, the dial strings for each such service would also likely differ. That, however, seems to be a somewhat different issue from using multiple URLs for fail-over routing. It seems unwise to commingle the two issues. On Jun 7, 2006, at 7:01 PM, Roger Marshall wrote: > When walking onto a campus, a call for emergency services shouldn't > result in two different scenarios, depending on which device/media > you're using. Though this is what happens in today's world. Today, > PSAP routing is inconsistent by technology, (you get campus PSAP when > using wired vs. city PSAP when using wireless). I think the > inconsistency should be fixed and it seems to me that LoST could help > fix it. > > I'm not promoting call-time user interaction with the returned set of > URIs, but rather when multiples are returned, that the device selects > the first one, and if for some reason it doesn't work, then the device > selects the second URI to route the call. The order in which the URIs > are returned is a LoST Server setting (based on jurisdiction > agreement). > > On the other hand, it now also occurs to me that we might want to > consider a user specified profile driven return order under certain > circumstances (let's say there is no way you want campus police to > come > to your aid). This one would probably be less controversial in a > commercial context for example, where you might want to exclude one > brand of gas station from being included in the returned list (e.g., > since they had a worse track record with oil-spills). > > > Roger Marshall > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 20:56:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo8pI-0003Yt-Lf; Wed, 07 Jun 2006 20:56:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo8pH-0003Uo-QU for ecrit@ietf.org; Wed, 07 Jun 2006 20:56:43 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo8pG-0007wx-EM for ecrit@ietf.org; Wed, 07 Jun 2006 20:56:43 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k580udU27690; Wed, 7 Jun 2006 20:56:39 -0400 (EDT) Received: from [127.0.0.1] ([47.130.17.72] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 20:56:08 -0400 Message-ID: <448775A1.4040007@nortel.com> Date: Wed, 07 Jun 2006 20:56:01 -0400 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Thomson, Martin [Business:EXTRNL:ANDREW]" Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfointo the query? References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2006 00:56:08.0926 (UTC) FILETIME=[54370FE0:01C68A96] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org OK, I've looked over the draft, and the rules make sense. I would still, as the "call server" programmer, choose the first location-info element and send only it. There's no way we should expect the mapping server to wade through potentially many objects when (within our charter) it makes sense to reply to only one of them. Thomson, Martin [Business:EXTRNL:ANDREW] wrote: > I'd like to clarify my position, because I think that this discussion > has headed off course a little. > > Firstly, I'd recommend that people read the PDIF-LO [sic] profile > draft. That draft talks about cardinality and I think that it is > extremely important to this discussion. > > http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile-04.txt > > This document notes that it is possible to have civic and geodetic > that together form a complex to describe a single location. The > example used is a set of 2-dimensional coordinates with an altitude > expressed in building floors. This is the reason that I support > both, not because I see that the LoST server being able to make > intelligent decisions about multiple conflicting pieces of > information. > > Here's how I see this working. The seeker has a PIDF-LO. They apply > the selection methods described in the above document to select a > single tuple that contains location information. > (XPath="/presence/tuple[status/geopriv][1]") > > Whatever location information that tuple contains, be it geodetic or > civic, the seeker lifts the contents of the location-info element and > puts it in an appropriate LoST query. > > Here are the applicable rules: > > Rule #1: A geopriv element MUST describe a discrete location. Rule > #4: Providing more than one location in a single > element SHOULD be avoided where possible. Rule #5: When providing > more than one location in a single element the > locations MUST be provided by a common source. Rule #6: Providing > more than one location in a single element SHOULD > only be done if they form a complex to describe the same location. > For example, a geodetic location describing a point, and a civic > location indicating the floor in a building. Rule #8: Where a PIDF > document contains more than one tuple containing a status element > with a geopriv location element , the priority of tuples SHOULD be > based on tuple position within the PIDF document. That is to say, > the tuple with the highest priority location occurs earliest in the > PIDF document. Initial priority SHOULD be determined by the > originating UA, the final priority MAY be determined by a proxy along > the way, or the UAS. > > >> -----Original Message----- From: Hannes Tschofenig >> [mailto:hannes.tschofenig@siemens.com] Sent: Wednesday, 7 June 2006 >> 9:30 PM To: ecrit@ietf.org Subject: [Ecrit] [issue2] Is it allowed >> to specify civic and geospatial infointo the query? >> >> >> Hannes Tschofenig added the comment: >> >> TENTATIVE SUMMARY: >> >> Here is the update: >> >> * Either civic OR geospatial in a LoST query >> >> Marc, Henning, Shida, Richard, Brian, John Schnizlein, Byron Smith, >> >> >> >> * Both civic AND geospatial possible in a LoST query >> >> Roger, Martin, Andy, James W. >> >> These folks don't seem to take a clear position: >> >> John Hearty, Jean-Francois, Clive D.W. Feather >> >> __________________________________________________ LoST Issue >> Tracker >> >> __________________________________________________ >> >> _______________________________________________ Ecrit mailing list >> Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise private information. If you > have received it in error, please notify the sender immediately and > delete the original. Any unauthorized use of this email is > prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > > ------------------------------------------------------------------------ > > > _______________________________________________ Ecrit mailing list > Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 21:55:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo9kT-0001KG-V5; Wed, 07 Jun 2006 21:55:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo9kS-0001K7-Nz for ecrit@ietf.org; Wed, 07 Jun 2006 21:55:48 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo9kR-0004wC-9a for ecrit@ietf.org; Wed, 07 Jun 2006 21:55:48 -0400 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.6.118]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k581mJt19137; Wed, 7 Jun 2006 19:48:19 -0600 Message-ID: <448783FC.2040400@ntt-at.com> Date: Wed, 07 Jun 2006 18:57:16 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Tom-PT Taylor Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfointo the query? References: <448775A1.4040007@nortel.com> In-Reply-To: <448775A1.4040007@nortel.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Tom; According to what I understand the issue still remains because Rule#5 and Rule#6 allows a compound location information composed of both geo and civic in single element. Two of which location type is a supplementary location info(floor or altitude) that can be dropped from the LoST query is probably not easy to find out. I guess we can't expect all the intermediary that supports LoST client functionality, the ability to compute the two location inside one element to seek out the proper location information to submit with the LoST query. I think I understand the problem, but I still feel very uncomfortable to send more than one location to LoST server in a single query. I'd rather loose the ability to express the flexibility the pidf-lo-profile has about including more than one location. If more than one location needs to be included in single location-info element, may be we can define a new element or an attribute to an "tuple" element to express that a location information A adds additional info to location information B? Thanks & Regards Shida Tom-PT Taylor wrote: > OK, I've looked over the draft, and the rules make sense. I would > still, as the "call server" programmer, choose the first location-info > element and send only it. There's no way we should expect the mapping > server to wade through potentially many objects when (within our > charter) it makes sense to reply to only one of them. > > Thomson, Martin [Business:EXTRNL:ANDREW] wrote: >> I'd like to clarify my position, because I think that this discussion >> has headed off course a little. >> >> Firstly, I'd recommend that people read the PDIF-LO [sic] profile >> draft. That draft talks about cardinality and I think that it is >> extremely important to this discussion. >> >> http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile-04.txt >> >> This document notes that it is possible to have civic and geodetic >> that together form a complex to describe a single location. The >> example used is a set of 2-dimensional coordinates with an altitude >> expressed in building floors. This is the reason that I support >> both, not because I see that the LoST server being able to make >> intelligent decisions about multiple conflicting pieces of >> information. >> >> Here's how I see this working. The seeker has a PIDF-LO. They apply >> the selection methods described in the above document to select a >> single tuple that contains location information. >> (XPath="/presence/tuple[status/geopriv][1]") >> >> Whatever location information that tuple contains, be it geodetic or >> civic, the seeker lifts the contents of the location-info element and >> puts it in an appropriate LoST query. >> >> Here are the applicable rules: >> >> Rule #1: A geopriv element MUST describe a discrete location. Rule >> #4: Providing more than one location in a single >> element SHOULD be avoided where possible. Rule #5: When providing >> more than one location in a single element the >> locations MUST be provided by a common source. Rule #6: Providing >> more than one location in a single element SHOULD >> only be done if they form a complex to describe the same location. >> For example, a geodetic location describing a point, and a civic >> location indicating the floor in a building. Rule #8: Where a PIDF >> document contains more than one tuple containing a status element >> with a geopriv location element , the priority of tuples SHOULD be >> based on tuple position within the PIDF document. That is to say, >> the tuple with the highest priority location occurs earliest in the >> PIDF document. Initial priority SHOULD be determined by the >> originating UA, the final priority MAY be determined by a proxy along >> the way, or the UAS. >> >> >>> -----Original Message----- From: Hannes Tschofenig >>> [mailto:hannes.tschofenig@siemens.com] Sent: Wednesday, 7 June 2006 >>> 9:30 PM To: ecrit@ietf.org Subject: [Ecrit] [issue2] Is it allowed >>> to specify civic and geospatial infointo the query? >>> >>> >>> Hannes Tschofenig added the comment: >>> >>> TENTATIVE SUMMARY: >>> >>> Here is the update: >>> >>> * Either civic OR geospatial in a LoST query >>> >>> Marc, Henning, Shida, Richard, Brian, John Schnizlein, Byron Smith, >>> >>> >>> >>> * Both civic AND geospatial possible in a LoST query >>> >>> Roger, Martin, Andy, James W. >>> >>> These folks don't seem to take a clear position: >>> >>> John Hearty, Jean-Francois, Clive D.W. Feather >>> >>> __________________________________________________ LoST Issue >>> Tracker >>> >>> __________________________________________________ >>> >>> _______________________________________________ Ecrit mailing list >>> Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit >> >> ------------------------------------------------------------------------------------------------ >> >> This message is for the designated recipient only and may contain >> privileged, proprietary, or otherwise private information. If you >> have received it in error, please notify the sender immediately and >> delete the original. Any unauthorized use of this email is >> prohibited. >> ------------------------------------------------------------------------------------------------ >> >> [mf2] >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ Ecrit mailing list >> Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 07 23:35:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoBIb-0002CU-R3; Wed, 07 Jun 2006 23:35:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoBIb-0002CO-3r for ecrit@ietf.org; Wed, 07 Jun 2006 23:35:09 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoBIZ-0007ig-Lo for ecrit@ietf.org; Wed, 07 Jun 2006 23:35:09 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 22:35:34 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 07 Jun 2006 22:35:33 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 22:35:32 -0500 Message-ID: From: "Thomson, Martin" To: , "Tom-PT Taylor" Date: Wed, 7 Jun 2006 22:35:29 -0500 Subject: RE: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfointo the query? MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 08 Jun 2006 03:35:32.0308 (UTC) FILETIME=[986F5940:01C68AAC] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <448783FC.2040400@ntt-at.com> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfointo the query? Thread-Index: AcaKnqd2asroiLOtSPiHFj9Qgp1KvgAC4SBA X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1929854499==" Errors-To: ecrit-bounces@ietf.org --===============1929854499== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message SXQgaXMgYmV0dGVyIHRvIHRoaW5rIG9mIGFueXRoaW5nIHRoYXQgYXBwZWFycyB3aXRoaW4gYSBz aW5nbGUgPGxvY2F0aW9uLWluZm8+IGVsZW1lbnQgYXMgYSBzaW5nbGUgbG9jYXRpb24uICBZb3Ug YXJlbid0IHNlbmRpbmcgbW9yZSB0aGFuIG9uZSBsb2NhdGlvbiB0byB0aGUgTG9TVCBzZXJ2ZXIu ICBJZiB5b3UgdGhpbmsgYWJvdXQgaXQgYXMgYSBzaW5nbGUgImxvY2F0aW9uIiB3aXRoIG11bHRp cGxlIHBhcnRzIChlbGVtZW50cyksIHRoZSBmZWFycyBhYm91dCBtdWx0aXBsZSByZXNwb25zZXMg ZGlzYXBwZWFyLg0KDQpUaGUgb25seSB2YWxpZCBjb25jZXJuIHRoYXQgcmVtYWlucyBpcyBMb1NU IHNlcnZlciBjb21wbGV4aXR5LiAgQnV0IHdoZW4geW91IHNjcmF0Y2ggYmVuZWF0aCB0aGUgc3Vy ZmFjZSBhIGxpdHRsZSwgdGhpcyBiZWdpbnMgdG8gYmUgbGVzcyBvZiBhIHNvdXJjZSBvZiBpbnRl c3RpbmFsIHRvcm1lbnQuICBJZiB3ZSBjb25zaWRlciB0aGUgb2NjYXNpb25zIHdoZXJlIHRoaXMg Y29tcG9zaXRlIGxvY2F0aW9uIGlzIHBvc3NpYmxlLCBpdCBxdWlja2x5IHJlc29sdmVzIGRvd24g dG8gdGhlIGZsb29ycyBhbHRpdHVkZSBjYXNlLCBhbmQgbm90IGEgd2hvbGUgbG90IG1vcmUuICBJ biBvdGhlciB3b3JkcywgSSBjYW4ndCB0aGluayBvZiBhIGdvb2QgYWx0ZXJuYXRpdmUgZXhhbXBs ZS4gIFRoYXQgbWVhbnMgdGhhdCB0aGUgTG9TVCBzZXJ2ZXIgY2FuIHNhZmVseSBpZ25vcmUgdGhl ICI8Y2l2aWNBZGRyZXNzPjxGTFI+MjwvRkxSPjwvY2l2aWNBZGRyZXNzPiIgdGhhdCBnb2VzIGFs b25nIHdpdGggdGhlIGdlb2RldGljIGluZm9ybWF0aW9uLCBleGNlcHQgd2hlcmUgeW91IGhhdmUg dGhlIHdlaXJkIGNhc2Ugd2hlcmUgdGhlIGJvdHRvbS1mbG9vciBjaW5lbWEgaXMgc2VydmVkIGJ5 IGEgZGlmZmVyZW50IFBTQVAgdG8gdGhlIHVwcGVyLWZsb29ycyAobm90IG15IGV4YW1wbGUpLg0K DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU2hpZGEgU2NodWJlcnQg W21haWx0bzpzaGlkYUBudHQtYXQuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgOCBKdW5lIDIwMDYg MTE6NTcgQU0NCj4gVG86IFRvbS1QVCBUYXlsb3INCj4gQ2M6IFRob21zb24sIE1hcnRpbjsgZWNy aXRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtFY3JpdF0gW2lzc3VlMl0gSXMgaXQgYWxsb3dl ZCB0byBzcGVjaWZ5IGNpdmljIGFuZA0KPiBnZW9zcGF0aWFsaW5mb2ludG8gdGhlIHF1ZXJ5Pw0K PiANCj4gDQo+IEhpIFRvbTsNCj4gDQo+IEFjY29yZGluZyB0byB3aGF0IEkgdW5kZXJzdGFuZCB0 aGUgaXNzdWUgc3RpbGwgcmVtYWlucyBiZWNhdXNlDQo+IFJ1bGUjNSBhbmQgUnVsZSM2IGFsbG93 cyBhIGNvbXBvdW5kIGxvY2F0aW9uIGluZm9ybWF0aW9uIGNvbXBvc2VkIG9mDQo+IGJvdGggZ2Vv IGFuZCBjaXZpYyBpbiBzaW5nbGUgPGxvY2F0aW9uLWluZm8+IGVsZW1lbnQuDQo+IA0KPiBUd28g b2Ygd2hpY2ggbG9jYXRpb24gdHlwZSBpcyBhIHN1cHBsZW1lbnRhcnkgbG9jYXRpb24gaW5mbyhm bG9vciBvcg0KPiBhbHRpdHVkZSkNCj4gdGhhdCBjYW4gYmUgZHJvcHBlZCBmcm9tIHRoZSBMb1NU IHF1ZXJ5IGlzIHByb2JhYmx5IG5vdCBlYXN5IHRvIGZpbmQgb3V0Lg0KPiBJIGd1ZXNzIHdlIGNh bid0IGV4cGVjdCBhbGwgdGhlIGludGVybWVkaWFyeSB0aGF0IHN1cHBvcnRzIExvU1QgY2xpZW50 DQo+IGZ1bmN0aW9uYWxpdHksDQo+IHRoZSBhYmlsaXR5IHRvIGNvbXB1dGUgdGhlIHR3byBsb2Nh dGlvbiBpbnNpZGUgb25lIDxsb2NhdGlvbi1pbmZvPg0KPiBlbGVtZW50IHRvDQo+IHNlZWsgb3V0 IHRoZSBwcm9wZXIgbG9jYXRpb24gaW5mb3JtYXRpb24gdG8gc3VibWl0IHdpdGggdGhlIExvU1Qg cXVlcnkuDQo+IA0KPiBJIHRoaW5rIEkgdW5kZXJzdGFuZCB0aGUgcHJvYmxlbSwgYnV0IEkgc3Rp bGwgZmVlbCB2ZXJ5IHVuY29tZm9ydGFibGUgdG8NCj4gc2VuZA0KPiBtb3JlIHRoYW4gb25lIGxv Y2F0aW9uIHRvIExvU1Qgc2VydmVyIGluIGEgc2luZ2xlIHF1ZXJ5LiBJJ2QgcmF0aGVyDQo+IGxv b3NlIHRoZQ0KPiBhYmlsaXR5IHRvIGV4cHJlc3MgdGhlIGZsZXhpYmlsaXR5IHRoZSBwaWRmLWxv LXByb2ZpbGUgaGFzIGFib3V0DQo+IGluY2x1ZGluZyBtb3JlDQo+IHRoYW4gb25lIGxvY2F0aW9u Lg0KPiANCj4gSWYgbW9yZSB0aGFuIG9uZSBsb2NhdGlvbiBuZWVkcyB0byBiZSBpbmNsdWRlZCBp biBzaW5nbGUgbG9jYXRpb24taW5mbw0KPiBlbGVtZW50LA0KPiBtYXkgYmUgd2UgY2FuIGRlZmlu ZSBhIG5ldyBlbGVtZW50IG9yIGFuIGF0dHJpYnV0ZSB0byBhbiAidHVwbGUiIGVsZW1lbnQNCj4g dG8gZXhwcmVzcyB0aGF0IGEgbG9jYXRpb24gaW5mb3JtYXRpb24gQSBhZGRzIGFkZGl0aW9uYWwg aW5mbyB0byBsb2NhdGlvbg0KPiBpbmZvcm1hdGlvbiBCPw0KPiANCj4gVGhhbmtzICYgUmVnYXJk cw0KPiBTaGlkYQ0KPiANCj4gVG9tLVBUIFRheWxvciB3cm90ZToNCj4gPiBPSywgSSd2ZSBsb29r ZWQgb3ZlciB0aGUgZHJhZnQsIGFuZCB0aGUgcnVsZXMgbWFrZSBzZW5zZS4gSSB3b3VsZA0KPiA+ IHN0aWxsLCBhcyB0aGUgImNhbGwgc2VydmVyIiBwcm9ncmFtbWVyLCBjaG9vc2UgdGhlIGZpcnN0 IGxvY2F0aW9uLWluZm8NCj4gPiBlbGVtZW50IGFuZCBzZW5kIG9ubHkgaXQuIFRoZXJlJ3Mgbm8g d2F5IHdlIHNob3VsZCBleHBlY3QgdGhlIG1hcHBpbmcNCj4gPiBzZXJ2ZXIgdG8gd2FkZSB0aHJv dWdoIHBvdGVudGlhbGx5IG1hbnkgb2JqZWN0cyB3aGVuICh3aXRoaW4gb3VyDQo+ID4gY2hhcnRl cikgaXQgbWFrZXMgc2Vuc2UgdG8gcmVwbHkgdG8gb25seSBvbmUgb2YgdGhlbS4NCj4gPg0KPiA+ IFRob21zb24sIE1hcnRpbiBbQnVzaW5lc3M6RVhUUk5MOkFORFJFV10gd3JvdGU6DQo+ID4+IEkn ZCBsaWtlIHRvIGNsYXJpZnkgbXkgcG9zaXRpb24sIGJlY2F1c2UgSSB0aGluayB0aGF0IHRoaXMg ZGlzY3Vzc2lvbg0KPiA+PiBoYXMgaGVhZGVkIG9mZiBjb3Vyc2UgYSBsaXR0bGUuDQo+ID4+DQo+ ID4+IEZpcnN0bHksIEknZCByZWNvbW1lbmQgdGhhdCBwZW9wbGUgcmVhZCB0aGUgUERJRi1MTyBb c2ljXSBwcm9maWxlDQo+ID4+IGRyYWZ0LiBUaGF0IGRyYWZ0IHRhbGtzIGFib3V0IGNhcmRpbmFs aXR5IGFuZCBJIHRoaW5rIHRoYXQgaXQgaXMNCj4gPj4gZXh0cmVtZWx5IGltcG9ydGFudCB0byB0 aGlzIGRpc2N1c3Npb24uDQo+ID4+DQo+ID4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtZ2VvcHJpdi1wZGlmLWxvLXByb2ZpbGUtMDQudHh0DQo+ID4+DQo+ID4+IFRoaXMg ZG9jdW1lbnQgbm90ZXMgdGhhdCBpdCBpcyBwb3NzaWJsZSB0byBoYXZlIGNpdmljIGFuZCBnZW9k ZXRpYw0KPiA+PiB0aGF0IHRvZ2V0aGVyIGZvcm0gYSBjb21wbGV4IHRvIGRlc2NyaWJlIGEgc2lu Z2xlIGxvY2F0aW9uLiBUaGUNCj4gPj4gZXhhbXBsZSB1c2VkIGlzIGEgc2V0IG9mIDItZGltZW5z aW9uYWwgY29vcmRpbmF0ZXMgd2l0aCBhbiBhbHRpdHVkZQ0KPiA+PiBleHByZXNzZWQgaW4gYnVp bGRpbmcgZmxvb3JzLiBUaGlzIGlzIHRoZSByZWFzb24gdGhhdCBJIHN1cHBvcnQNCj4gPj4gYm90 aCwgbm90IGJlY2F1c2UgSSBzZWUgdGhhdCB0aGUgTG9TVCBzZXJ2ZXIgYmVpbmcgYWJsZSB0byBt YWtlDQo+ID4+IGludGVsbGlnZW50IGRlY2lzaW9ucyBhYm91dCBtdWx0aXBsZSBjb25mbGljdGlu ZyBwaWVjZXMgb2YNCj4gPj4gaW5mb3JtYXRpb24uDQo+ID4+DQo+ID4+IEhlcmUncyBob3cgSSBz ZWUgdGhpcyB3b3JraW5nLiBUaGUgc2Vla2VyIGhhcyBhIFBJREYtTE8uIFRoZXkgYXBwbHkNCj4g Pj4gdGhlIHNlbGVjdGlvbiBtZXRob2RzIGRlc2NyaWJlZCBpbiB0aGUgYWJvdmUgZG9jdW1lbnQg dG8gc2VsZWN0IGENCj4gPj4gc2luZ2xlIHR1cGxlIHRoYXQgY29udGFpbnMgbG9jYXRpb24gaW5m b3JtYXRpb24uDQo+ID4+IChYUGF0aD0iL3ByZXNlbmNlL3R1cGxlW3N0YXR1cy9nZW9wcml2XVsx XSIpDQo+ID4+DQo+ID4+IFdoYXRldmVyIGxvY2F0aW9uIGluZm9ybWF0aW9uIHRoYXQgdHVwbGUg Y29udGFpbnMsIGJlIGl0IGdlb2RldGljIG9yDQo+ID4+IGNpdmljLCB0aGUgc2Vla2VyIGxpZnRz IHRoZSBjb250ZW50cyBvZiB0aGUgbG9jYXRpb24taW5mbyBlbGVtZW50IGFuZA0KPiA+PiBwdXRz IGl0IGluIGFuIGFwcHJvcHJpYXRlIExvU1QgcXVlcnkuDQo+ID4+DQo+ID4+IEhlcmUgYXJlIHRo ZSBhcHBsaWNhYmxlIHJ1bGVzOg0KPiA+Pg0KPiA+PiBSdWxlICMxOiBBIGdlb3ByaXYgZWxlbWVu dCBNVVNUIGRlc2NyaWJlIGEgZGlzY3JldGUgbG9jYXRpb24uIFJ1bGUNCj4gPj4gIzQ6IFByb3Zp ZGluZyBtb3JlIHRoYW4gb25lIGxvY2F0aW9uIGluIGEgc2luZ2xlIDxsb2NhdGlvbi1pbmZvPg0K PiA+PiBlbGVtZW50IFNIT1VMRCBiZSBhdm9pZGVkIHdoZXJlIHBvc3NpYmxlLiBSdWxlICM1OiBX aGVuIHByb3ZpZGluZw0KPiA+PiBtb3JlIHRoYW4gb25lIGxvY2F0aW9uIGluIGEgc2luZ2xlIDxs b2NhdGlvbi0gaW5mbz4gZWxlbWVudCB0aGUNCj4gPj4gbG9jYXRpb25zIE1VU1QgYmUgcHJvdmlk ZWQgYnkgYSBjb21tb24gc291cmNlLiBSdWxlICM2OiBQcm92aWRpbmcNCj4gPj4gbW9yZSB0aGFu IG9uZSBsb2NhdGlvbiBpbiBhIHNpbmdsZSA8bG9jYXRpb24taW5mbz4gZWxlbWVudCBTSE9VTEQN Cj4gPj4gb25seSBiZSBkb25lIGlmIHRoZXkgZm9ybSBhIGNvbXBsZXggdG8gZGVzY3JpYmUgdGhl IHNhbWUgbG9jYXRpb24uDQo+ID4+IEZvciBleGFtcGxlLCBhIGdlb2RldGljIGxvY2F0aW9uIGRl c2NyaWJpbmcgYSBwb2ludCwgYW5kIGEgY2l2aWMNCj4gPj4gbG9jYXRpb24gaW5kaWNhdGluZyB0 aGUgZmxvb3IgaW4gYSBidWlsZGluZy4gUnVsZSAjODogV2hlcmUgYSBQSURGDQo+ID4+IGRvY3Vt ZW50IGNvbnRhaW5zIG1vcmUgdGhhbiBvbmUgdHVwbGUgY29udGFpbmluZyBhIHN0YXR1cyBlbGVt ZW50DQo+ID4+IHdpdGggYSBnZW9wcml2IGxvY2F0aW9uIGVsZW1lbnQgLCB0aGUgcHJpb3JpdHkg b2YgdHVwbGVzIFNIT1VMRCBiZQ0KPiA+PiBiYXNlZCBvbiB0dXBsZSBwb3NpdGlvbiB3aXRoaW4g dGhlIFBJREYgZG9jdW1lbnQuIFRoYXQgaXMgdG8gc2F5LA0KPiA+PiB0aGUgdHVwbGUgd2l0aCB0 aGUgaGlnaGVzdCBwcmlvcml0eSBsb2NhdGlvbiBvY2N1cnMgZWFybGllc3QgaW4gdGhlDQo+ID4+ IFBJREYgZG9jdW1lbnQuIEluaXRpYWwgcHJpb3JpdHkgU0hPVUxEIGJlIGRldGVybWluZWQgYnkg dGhlDQo+ID4+IG9yaWdpbmF0aW5nIFVBLCB0aGUgZmluYWwgcHJpb3JpdHkgTUFZIGJlIGRldGVy bWluZWQgYnkgYSBwcm94eSBhbG9uZw0KPiA+PiB0aGUgd2F5LCBvciB0aGUgVUFTLg0KPiA+Pg0K PiA+Pg0KPiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogSGFubmVzIFRzY2hv ZmVuaWcNCj4gPj4+IFttYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAc2llbWVucy5jb21dIFNlbnQ6 IFdlZG5lc2RheSwgNyBKdW5lIDIwMDYNCj4gPj4+IDk6MzAgUE0gVG86IGVjcml0QGlldGYub3Jn IFN1YmplY3Q6IFtFY3JpdF0gW2lzc3VlMl0gSXMgaXQgYWxsb3dlZA0KPiA+Pj4gdG8gc3BlY2lm eSBjaXZpYyBhbmQgZ2Vvc3BhdGlhbCBpbmZvaW50byB0aGUgcXVlcnk/DQo+ID4+Pg0KPiA+Pj4N Cj4gPj4+IEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0PiBhZGRl ZCB0aGUgY29tbWVudDoNCj4gPj4+DQo+ID4+PiBURU5UQVRJVkUgU1VNTUFSWToNCj4gPj4+DQo+ ID4+PiBIZXJlIGlzIHRoZSB1cGRhdGU6DQo+ID4+Pg0KPiA+Pj4gKiBFaXRoZXIgY2l2aWMgT1Ig Z2Vvc3BhdGlhbCBpbiBhIExvU1QgcXVlcnkNCj4gPj4+DQo+ID4+PiBNYXJjLCBIZW5uaW5nLCBT aGlkYSwgUmljaGFyZCwgQnJpYW4sIEpvaG4gU2Nobml6bGVpbiwgQnlyb24gU21pdGgsDQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAqIEJvdGggY2l2aWMgQU5EIGdlb3NwYXRpYWwgcG9zc2li bGUgaW4gYSBMb1NUIHF1ZXJ5DQo+ID4+Pg0KPiA+Pj4gUm9nZXIsIE1hcnRpbiwgQW5keSwgSmFt ZXMgVy4NCj4gPj4+DQo+ID4+PiBUaGVzZSBmb2xrcyBkb24ndCBzZWVtIHRvIHRha2UgYSBjbGVh ciBwb3NpdGlvbjoNCj4gPj4+DQo+ID4+PiBKb2huIEhlYXJ0eSwgSmVhbi1GcmFuY29pcywgQ2xp dmUgRC5XLiBGZWF0aGVyDQo+ID4+Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18gTG9TVCBJc3N1ZQ0KPiA+Pj4gVHJhY2tlciA8aGFubmVz LnRzY2hvZmVuaWdAc2llbWVucy5jb20+DQo+ID4+PiA8aHR0cDovL3d3dy50c2Nob2ZlbmlnLmNv bTo4MDgwL2xvc3QvaXNzdWUyPg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPj4+DQo+ID4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXyBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gPj4+IEVjcml0 QGlldGYub3JnIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+ ID4+DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g Pj4NCj4gPj4gVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25s eSBhbmQgbWF5IGNvbnRhaW4NCj4gPj4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVy d2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiBJZiB5b3UNCj4gPj4gaGF2ZSByZWNlaXZlZCBpdCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZA0KPiA+PiBk ZWxldGUgdGhlIG9yaWdpbmFsLiBBbnkgdW5hdXRob3JpemVkIHVzZSBvZiB0aGlzIGVtYWlsIGlz DQo+ID4+IHByb2hpYml0ZWQuDQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gPj4NCj4gPj4gW21mMl0NCj4gPj4NCj4gPj4NCj4gPj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gLQ0KPiA+Pg0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXyBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gPj4gRWNyaXRAaWV0Zi5v cmcgaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4gPg0KPiA+ DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gPiBFY3JpdEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3 MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+ID4NCj4gPg0KPiANCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRo ZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwg cHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3Ug aGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1l ZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9m DQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClttZjJd --===============1929854499== 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 --===============1929854499==-- From ecrit-bounces@ietf.org Thu Jun 08 02:20:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoDse-0002Zd-Cr; Thu, 08 Jun 2006 02:20:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoDsc-0002ZY-PU for ecrit@ietf.org; Thu, 08 Jun 2006 02:20:30 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoDsZ-0003Qh-7m for ecrit@ietf.org; Thu, 08 Jun 2006 02:20:30 -0400 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.6.118]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k586BQR18477; Thu, 8 Jun 2006 00:11:48 -0600 Message-ID: <4487C1A4.7010809@ntt-at.com> Date: Wed, 07 Jun 2006 23:20:20 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Thomson, Martin" Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfointo the query? References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Tom; I agree with you to some extent but I am still not comfortable. As long as the two information really supplement each other, and one of the information is sufficient to find the proper PSAP URI and both information only resolves to one PSAP URI if both were queried, I might be able to live with that. Just out of curiosity. Assuming LoST supports query with location information with two location type as long as it is a compound location information where two information supplement each other, what would happen if LoST server that was queried did not support geo and it happend to have the supplementary information in geo(latitude)? If it does not understand civic location format, it is unable to identify the information to be used to find the proper PSAP and might proceed to query the database using the location info provided in geo format(only latitude info. I guess it could return an error stating that it's an invalid location as well as default uri for the service requested(e.g. Default PSAP URI for the region LoST server is responsible)... Regards Shida Thomson, Martin wrote: > It is better to think of anything that appears within a single element as a single location. You aren't sending more than one location to the LoST server. If you think about it as a single "location" with multiple parts (elements), the fears about multiple responses disappear. > > The only valid concern that remains is LoST server complexity. But when you scratch beneath the surface a little, this begins to be less of a source of intestinal torment. If we consider the occasions where this composite location is possible, it quickly resolves down to the floors altitude case, and not a whole lot more. In other words, I can't think of a good alternative example. That means that the LoST server can safely ignore the "2" that goes along with the geodetic information, except where you have the weird case where the bottom-floor cinema is served by a different PSAP to the upper-floors (not my example). > > > >> -----Original Message----- >> From: Shida Schubert [mailto:shida@ntt-at.com] >> Sent: Thursday, 8 June 2006 11:57 AM >> To: Tom-PT Taylor >> Cc: Thomson, Martin; ecrit@ietf.org >> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >> geospatialinfointo the query? >> >> >> Hi Tom; >> >> According to what I understand the issue still remains because >> Rule#5 and Rule#6 allows a compound location information composed of >> both geo and civic in single element. >> >> Two of which location type is a supplementary location info(floor or >> altitude) >> that can be dropped from the LoST query is probably not easy to find out. >> I guess we can't expect all the intermediary that supports LoST client >> functionality, >> the ability to compute the two location inside one >> element to >> seek out the proper location information to submit with the LoST query. >> >> I think I understand the problem, but I still feel very uncomfortable to >> send >> more than one location to LoST server in a single query. I'd rather >> loose the >> ability to express the flexibility the pidf-lo-profile has about >> including more >> than one location. >> >> If more than one location needs to be included in single location-info >> element, >> may be we can define a new element or an attribute to an "tuple" element >> to express that a location information A adds additional info to location >> information B? >> >> Thanks & Regards >> Shida >> >> Tom-PT Taylor wrote: >> >>> OK, I've looked over the draft, and the rules make sense. I would >>> still, as the "call server" programmer, choose the first location-info >>> element and send only it. There's no way we should expect the mapping >>> server to wade through potentially many objects when (within our >>> charter) it makes sense to reply to only one of them. >>> >>> Thomson, Martin [Business:EXTRNL:ANDREW] wrote: >>> >>>> I'd like to clarify my position, because I think that this discussion >>>> has headed off course a little. >>>> >>>> Firstly, I'd recommend that people read the PDIF-LO [sic] profile >>>> draft. That draft talks about cardinality and I think that it is >>>> extremely important to this discussion. >>>> >>>> http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile-04.txt >>>> >>>> This document notes that it is possible to have civic and geodetic >>>> that together form a complex to describe a single location. The >>>> example used is a set of 2-dimensional coordinates with an altitude >>>> expressed in building floors. This is the reason that I support >>>> both, not because I see that the LoST server being able to make >>>> intelligent decisions about multiple conflicting pieces of >>>> information. >>>> >>>> Here's how I see this working. The seeker has a PIDF-LO. They apply >>>> the selection methods described in the above document to select a >>>> single tuple that contains location information. >>>> (XPath="/presence/tuple[status/geopriv][1]") >>>> >>>> Whatever location information that tuple contains, be it geodetic or >>>> civic, the seeker lifts the contents of the location-info element and >>>> puts it in an appropriate LoST query. >>>> >>>> Here are the applicable rules: >>>> >>>> Rule #1: A geopriv element MUST describe a discrete location. Rule >>>> #4: Providing more than one location in a single >>>> element SHOULD be avoided where possible. Rule #5: When providing >>>> more than one location in a single element the >>>> locations MUST be provided by a common source. Rule #6: Providing >>>> more than one location in a single element SHOULD >>>> only be done if they form a complex to describe the same location. >>>> For example, a geodetic location describing a point, and a civic >>>> location indicating the floor in a building. Rule #8: Where a PIDF >>>> document contains more than one tuple containing a status element >>>> with a geopriv location element , the priority of tuples SHOULD be >>>> based on tuple position within the PIDF document. That is to say, >>>> the tuple with the highest priority location occurs earliest in the >>>> PIDF document. Initial priority SHOULD be determined by the >>>> originating UA, the final priority MAY be determined by a proxy along >>>> the way, or the UAS. >>>> >>>> >>>> >>>>> -----Original Message----- From: Hannes Tschofenig >>>>> [mailto:hannes.tschofenig@siemens.com] Sent: Wednesday, 7 June 2006 >>>>> 9:30 PM To: ecrit@ietf.org Subject: [Ecrit] [issue2] Is it allowed >>>>> to specify civic and geospatial infointo the query? >>>>> >>>>> >>>>> Hannes Tschofenig added the comment: >>>>> >>>>> TENTATIVE SUMMARY: >>>>> >>>>> Here is the update: >>>>> >>>>> * Either civic OR geospatial in a LoST query >>>>> >>>>> Marc, Henning, Shida, Richard, Brian, John Schnizlein, Byron Smith, >>>>> >>>>> >>>>> >>>>> * Both civic AND geospatial possible in a LoST query >>>>> >>>>> Roger, Martin, Andy, James W. >>>>> >>>>> These folks don't seem to take a clear position: >>>>> >>>>> John Hearty, Jean-Francois, Clive D.W. Feather >>>>> >>>>> __________________________________________________ LoST Issue >>>>> Tracker >>>>> >>>>> __________________________________________________ >>>>> >>>>> _______________________________________________ Ecrit mailing list >>>>> Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit >>>>> >>>> ----------------------------------------------------------------------- >>>> >> ------------------------- >> >>>> This message is for the designated recipient only and may contain >>>> privileged, proprietary, or otherwise private information. If you >>>> have received it in error, please notify the sender immediately and >>>> delete the original. Any unauthorized use of this email is >>>> prohibited. >>>> ----------------------------------------------------------------------- >>>> >> ------------------------- >> >>>> [mf2] >>>> >>>> >>>> ----------------------------------------------------------------------- >>>> >> - >> >>>> _______________________________________________ Ecrit mailing list >>>> Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit >>>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >>> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 08 03:17:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoElX-0002NK-4p; Thu, 08 Jun 2006 03:17:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoElV-0002NE-FW for ecrit@ietf.org; Thu, 08 Jun 2006 03:17:13 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoElT-0002Eb-UT for ecrit@ietf.org; Thu, 08 Jun 2006 03:17:13 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 02:17:32 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 08 Jun 2006 02:17:31 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 02:17:31 -0500 Message-ID: From: "Thomson, Martin" To: Date: Thu, 8 Jun 2006 02:17:27 -0500 Subject: RE: [Ecrit] [issue2] Is it allowed to specify civicand geospatialinfointo the query? MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 08 Jun 2006 07:17:31.0116 (UTC) FILETIME=[9B102AC0:01C68ACB] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <4487C1A4.7010809@ntt-at.com> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] [issue2] Is it allowed to specify civicand geospatialinfointo the query? Thread-Index: AcaKw64NO+B2qmvJQ2WR9ugoXDTYtwABumzw X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1678200361==" Errors-To: ecrit-bounces@ietf.org --===============1678200361== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message SSB0aGluayB0aGF0IHlvdSBtZWFudCB0byBhc2sgbWUsIHNvIEknbGwgYW5zd2VyLiAgSSdtIG5v dCBzdXJlIGlmIHRoYXQncyBhIGdvb2QgdGhpbmcgb3Igbm90IHRvIGJlIG1pc3Rha2VuIGZvciBU b20gOykNCg0KSSdtIG5vdCBzdXJlIGlmIEkgdW5kZXJzdGFuZCB5b3VyIHNjZW5hcmlvLiAgRG8g eW91IGhhdmUgYSBzZXJ2ZXIgdGhhdCBkb2Vzbid0IHN1cHBvcnQgZ2VvLCBidXQgaGFzIGV4dHJh IGluZm9ybWF0aW9uIHRoYXQgaXQgY2FuIHVzZT8NCg0KVGhlIG9ubHkgc2NlbmFyaW9zIHRoYXQg SSBjYW4gc2VlIGFyaXNpbmcgZnJvbSB0aGlzIGFyZSB0aG9zZSB3aGVyZSBvbmUgcGllY2UgaXMg bm90IHVuZGVyc3Rvb2QgKGVpdGhlciB0aGUgZ2VvLCBvciBjaXZpYyBwYXJ0KS4gIFR3byB0aGlu Z3MgY2FuIGhhcHBlbg0KDQogIC0gdGhlIG90aGVyIHBpZWNlcyBhcmUgc3VmZmljaWVudCB0byBn ZXQgYSByZXN1bHQgKEkgZG9uJ3QgdW5kZXJzdGFuZCBjaXZpYywgYnV0IEkgZG9uJ3QgY2FyZSBh Ym91dCBhbHRpdHVkZSksIG9yDQoNCiAgLSB0aGUgb3RoZXIgcGllY2VzIGFyZSBwcmV0dHkgYW1i aWd1b3VzIChJIGRvbid0IHVuZGVyc3RhbmQgZ2VvLCBhbmQgdGhlIHNlY29uZCBmbG9vciBhbnl3 aGVyZSBvbiB0aGUgcGxhbmV0IGlzbid0IHNwZWNpZmljIGVub3VnaCBmb3IgbWUpLg0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFNoaWRhIFNjaHViZXJ0IFttYWlsdG86 c2hpZGFAbnR0LWF0LmNvbV0NCj4gU2VudDogVGh1cnNkYXksIDggSnVuZSAyMDA2IDQ6MjAgUE0N Cj4gVG86IFRob21zb24sIE1hcnRpbg0KPiBDYzogZWNyaXRAaWV0Zi5vcmcNCj4gU3ViamVjdDog UmU6IFtFY3JpdF0gW2lzc3VlMl0gSXMgaXQgYWxsb3dlZCB0byBzcGVjaWZ5IGNpdmljYW5kDQo+ IGdlb3NwYXRpYWxpbmZvaW50byB0aGUgcXVlcnk/DQo+IA0KPiANCj4gSGkgVG9tOw0KPiANCj4g SSBhZ3JlZSB3aXRoIHlvdSB0byBzb21lIGV4dGVudCBidXQgSSBhbSBzdGlsbCBub3QgY29tZm9y dGFibGUuDQo+IA0KPiBBcyBsb25nIGFzIHRoZSB0d28gaW5mb3JtYXRpb24gcmVhbGx5IHN1cHBs ZW1lbnQgZWFjaCBvdGhlciwgYW5kIG9uZSBvZg0KPiB0aGUgaW5mb3JtYXRpb24gaXMgc3VmZmlj aWVudCB0byBmaW5kIHRoZSBwcm9wZXIgUFNBUCBVUkkgYW5kIGJvdGgNCj4gaW5mb3JtYXRpb24g b25seSByZXNvbHZlcyB0byBvbmUgUFNBUCBVUkkgaWYgYm90aCB3ZXJlIHF1ZXJpZWQsIEkgbWln aHQNCj4gYmUgYWJsZSB0byBsaXZlIHdpdGggdGhhdC4NCj4gDQo+IEp1c3Qgb3V0IG9mIGN1cmlv c2l0eS4gQXNzdW1pbmcgTG9TVCBzdXBwb3J0cyBxdWVyeSB3aXRoIGxvY2F0aW9uDQo+IGluZm9y bWF0aW9uIHdpdGggdHdvIGxvY2F0aW9uIHR5cGUgYXMgbG9uZyBhcyBpdCBpcyBhIGNvbXBvdW5k IGxvY2F0aW9uDQo+IGluZm9ybWF0aW9uIHdoZXJlIHR3byBpbmZvcm1hdGlvbiBzdXBwbGVtZW50 IGVhY2ggb3RoZXIsIHdoYXQgd291bGQNCj4gaGFwcGVuIGlmIExvU1Qgc2VydmVyIHRoYXQgd2Fz IHF1ZXJpZWQgZGlkIG5vdCBzdXBwb3J0IGdlbyBhbmQgaXQNCj4gaGFwcGVuZCB0byBoYXZlIHRo ZSBzdXBwbGVtZW50YXJ5IGluZm9ybWF0aW9uIGluIGdlbyhsYXRpdHVkZSk/DQo+DQo+IElmIGl0 IGRvZXMgbm90IHVuZGVyc3RhbmQgY2l2aWMgbG9jYXRpb24gZm9ybWF0LCBpdCBpcyB1bmFibGUg dG8gaWRlbnRpZnkNCj4gdGhlIGluZm9ybWF0aW9uIHRvIGJlIHVzZWQgdG8gZmluZCB0aGUgcHJv cGVyIFBTQVAgYW5kIG1pZ2h0IHByb2NlZWQgdG8NCj4gcXVlcnkgdGhlIGRhdGFiYXNlIHVzaW5n IHRoZSBsb2NhdGlvbiBpbmZvIHByb3ZpZGVkIGluIGdlbyBmb3JtYXQob25seQ0KPiBsYXRpdHVk ZSBpbmZvLg0KPiANCj4gSSBndWVzcyBpdCBjb3VsZCByZXR1cm4gYW4gZXJyb3Igc3RhdGluZyB0 aGF0IGl0J3MgYW4gaW52YWxpZCBsb2NhdGlvbg0KPiBhcyB3ZWxsIGFzIGRlZmF1bHQgdXJpIGZv ciB0aGUgc2VydmljZSByZXF1ZXN0ZWQoZS5nLiBEZWZhdWx0IFBTQVAgVVJJDQo+IGZvciB0aGUN Cj4gcmVnaW9uIExvU1Qgc2VydmVyIGlzIHJlc3BvbnNpYmxlKS4uLg0KPiANCj4gUmVnYXJkcw0K PiBTaGlkYQ0KPiANCj4gVGhvbXNvbiwgTWFydGluIHdyb3RlOg0KPiA+IEl0IGlzIGJldHRlciB0 byB0aGluayBvZiBhbnl0aGluZyB0aGF0IGFwcGVhcnMgd2l0aGluIGEgc2luZ2xlDQo+IDxsb2Nh dGlvbi1pbmZvPiBlbGVtZW50IGFzIGEgc2luZ2xlIGxvY2F0aW9uLiAgWW91IGFyZW4ndCBzZW5k aW5nIG1vcmUNCj4gdGhhbiBvbmUgbG9jYXRpb24gdG8gdGhlIExvU1Qgc2VydmVyLiAgSWYgeW91 IHRoaW5rIGFib3V0IGl0IGFzIGEgc2luZ2xlDQo+ICJsb2NhdGlvbiIgd2l0aCBtdWx0aXBsZSBw YXJ0cyAoZWxlbWVudHMpLCB0aGUgZmVhcnMgYWJvdXQgbXVsdGlwbGUNCj4gcmVzcG9uc2VzIGRp c2FwcGVhci4NCj4gPg0KPiA+IFRoZSBvbmx5IHZhbGlkIGNvbmNlcm4gdGhhdCByZW1haW5zIGlz IExvU1Qgc2VydmVyIGNvbXBsZXhpdHkuICBCdXQgd2hlbg0KPiB5b3Ugc2NyYXRjaCBiZW5lYXRo IHRoZSBzdXJmYWNlIGEgbGl0dGxlLCB0aGlzIGJlZ2lucyB0byBiZSBsZXNzIG9mIGENCj4gc291 cmNlIG9mIGludGVzdGluYWwgdG9ybWVudC4gIElmIHdlIGNvbnNpZGVyIHRoZSBvY2Nhc2lvbnMg d2hlcmUgdGhpcw0KPiBjb21wb3NpdGUgbG9jYXRpb24gaXMgcG9zc2libGUsIGl0IHF1aWNrbHkg cmVzb2x2ZXMgZG93biB0byB0aGUgZmxvb3JzDQo+IGFsdGl0dWRlIGNhc2UsIGFuZCBub3QgYSB3 aG9sZSBsb3QgbW9yZS4gIEluIG90aGVyIHdvcmRzLCBJIGNhbid0IHRoaW5rIG9mDQo+IGEgZ29v ZCBhbHRlcm5hdGl2ZSBleGFtcGxlLiAgVGhhdCBtZWFucyB0aGF0IHRoZSBMb1NUIHNlcnZlciBj YW4gc2FmZWx5DQo+IGlnbm9yZSB0aGUgIjxjaXZpY0FkZHJlc3M+PEZMUj4yPC9GTFI+PC9jaXZp Y0FkZHJlc3M+IiB0aGF0IGdvZXMgYWxvbmcNCj4gd2l0aCB0aGUgZ2VvZGV0aWMgaW5mb3JtYXRp b24sIGV4Y2VwdCB3aGVyZSB5b3UgaGF2ZSB0aGUgd2VpcmQgY2FzZSB3aGVyZQ0KPiB0aGUgYm90 dG9tLWZsb29yIGNpbmVtYSBpcyBzZXJ2ZWQgYnkgYSBkaWZmZXJlbnQgUFNBUCB0byB0aGUgdXBw ZXItZmxvb3JzDQo+IChub3QgbXkgZXhhbXBsZSkuDQo+ID4NCj4gPg0KPiA+DQo+ID4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IFNoaWRhIFNjaHViZXJ0IFttYWlsdG86 c2hpZGFAbnR0LWF0LmNvbV0NCj4gPj4gU2VudDogVGh1cnNkYXksIDggSnVuZSAyMDA2IDExOjU3 IEFNDQo+ID4+IFRvOiBUb20tUFQgVGF5bG9yDQo+ID4+IENjOiBUaG9tc29uLCBNYXJ0aW47IGVj cml0QGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbRWNyaXRdIFtpc3N1ZTJdIElzIGl0IGFs bG93ZWQgdG8gc3BlY2lmeSBjaXZpYyBhbmQNCj4gPj4gZ2Vvc3BhdGlhbGluZm9pbnRvIHRoZSBx dWVyeT8NCj4gPj4NCj4gPj4NCj4gPj4gSGkgVG9tOw0KPiA+Pg0KPiA+PiBBY2NvcmRpbmcgdG8g d2hhdCBJIHVuZGVyc3RhbmQgdGhlIGlzc3VlIHN0aWxsIHJlbWFpbnMgYmVjYXVzZQ0KPiA+PiBS dWxlIzUgYW5kIFJ1bGUjNiBhbGxvd3MgYSBjb21wb3VuZCBsb2NhdGlvbiBpbmZvcm1hdGlvbiBj b21wb3NlZCBvZg0KPiA+PiBib3RoIGdlbyBhbmQgY2l2aWMgaW4gc2luZ2xlIDxsb2NhdGlvbi1p bmZvPiBlbGVtZW50Lg0KPiA+Pg0KPiA+PiBUd28gb2Ygd2hpY2ggbG9jYXRpb24gdHlwZSBpcyBh IHN1cHBsZW1lbnRhcnkgbG9jYXRpb24gaW5mbyhmbG9vciBvcg0KPiA+PiBhbHRpdHVkZSkNCj4g Pj4gdGhhdCBjYW4gYmUgZHJvcHBlZCBmcm9tIHRoZSBMb1NUIHF1ZXJ5IGlzIHByb2JhYmx5IG5v dCBlYXN5IHRvIGZpbmQNCj4gb3V0Lg0KPiA+PiBJIGd1ZXNzIHdlIGNhbid0IGV4cGVjdCBhbGwg dGhlIGludGVybWVkaWFyeSB0aGF0IHN1cHBvcnRzIExvU1QgY2xpZW50DQo+ID4+IGZ1bmN0aW9u YWxpdHksDQo+ID4+IHRoZSBhYmlsaXR5IHRvIGNvbXB1dGUgdGhlIHR3byBsb2NhdGlvbiBpbnNp ZGUgb25lIDxsb2NhdGlvbi1pbmZvPg0KPiA+PiBlbGVtZW50IHRvDQo+ID4+IHNlZWsgb3V0IHRo ZSBwcm9wZXIgbG9jYXRpb24gaW5mb3JtYXRpb24gdG8gc3VibWl0IHdpdGggdGhlIExvU1QgcXVl cnkuDQo+ID4+DQo+ID4+IEkgdGhpbmsgSSB1bmRlcnN0YW5kIHRoZSBwcm9ibGVtLCBidXQgSSBz dGlsbCBmZWVsIHZlcnkgdW5jb21mb3J0YWJsZQ0KPiB0bw0KPiA+PiBzZW5kDQo+ID4+IG1vcmUg dGhhbiBvbmUgbG9jYXRpb24gdG8gTG9TVCBzZXJ2ZXIgaW4gYSBzaW5nbGUgcXVlcnkuIEknZCBy YXRoZXINCj4gPj4gbG9vc2UgdGhlDQo+ID4+IGFiaWxpdHkgdG8gZXhwcmVzcyB0aGUgZmxleGli aWxpdHkgdGhlIHBpZGYtbG8tcHJvZmlsZSBoYXMgYWJvdXQNCj4gPj4gaW5jbHVkaW5nIG1vcmUN Cj4gPj4gdGhhbiBvbmUgbG9jYXRpb24uDQo+ID4+DQo+ID4+IElmIG1vcmUgdGhhbiBvbmUgbG9j YXRpb24gbmVlZHMgdG8gYmUgaW5jbHVkZWQgaW4gc2luZ2xlIGxvY2F0aW9uLWluZm8NCj4gPj4g ZWxlbWVudCwNCj4gPj4gbWF5IGJlIHdlIGNhbiBkZWZpbmUgYSBuZXcgZWxlbWVudCBvciBhbiBh dHRyaWJ1dGUgdG8gYW4gInR1cGxlIg0KPiBlbGVtZW50DQo+ID4+IHRvIGV4cHJlc3MgdGhhdCBh IGxvY2F0aW9uIGluZm9ybWF0aW9uIEEgYWRkcyBhZGRpdGlvbmFsIGluZm8gdG8NCj4gbG9jYXRp b24NCj4gPj4gaW5mb3JtYXRpb24gQj8NCj4gPj4NCj4gPj4gVGhhbmtzICYgUmVnYXJkcw0KPiA+ PiBTaGlkYQ0KPiA+Pg0KPiA+PiBUb20tUFQgVGF5bG9yIHdyb3RlOg0KPiA+Pg0KPiA+Pj4gT0ss IEkndmUgbG9va2VkIG92ZXIgdGhlIGRyYWZ0LCBhbmQgdGhlIHJ1bGVzIG1ha2Ugc2Vuc2UuIEkg d291bGQNCj4gPj4+IHN0aWxsLCBhcyB0aGUgImNhbGwgc2VydmVyIiBwcm9ncmFtbWVyLCBjaG9v c2UgdGhlIGZpcnN0IGxvY2F0aW9uLWluZm8NCj4gPj4+IGVsZW1lbnQgYW5kIHNlbmQgb25seSBp dC4gVGhlcmUncyBubyB3YXkgd2Ugc2hvdWxkIGV4cGVjdCB0aGUgbWFwcGluZw0KPiA+Pj4gc2Vy dmVyIHRvIHdhZGUgdGhyb3VnaCBwb3RlbnRpYWxseSBtYW55IG9iamVjdHMgd2hlbiAod2l0aGlu IG91cg0KPiA+Pj4gY2hhcnRlcikgaXQgbWFrZXMgc2Vuc2UgdG8gcmVwbHkgdG8gb25seSBvbmUg b2YgdGhlbS4NCj4gPj4+DQo+ID4+PiBUaG9tc29uLCBNYXJ0aW4gW0J1c2luZXNzOkVYVFJOTDpB TkRSRVddIHdyb3RlOg0KPiA+Pj4NCj4gPj4+PiBJJ2QgbGlrZSB0byBjbGFyaWZ5IG15IHBvc2l0 aW9uLCBiZWNhdXNlIEkgdGhpbmsgdGhhdCB0aGlzIGRpc2N1c3Npb24NCj4gPj4+PiBoYXMgaGVh ZGVkIG9mZiBjb3Vyc2UgYSBsaXR0bGUuDQo+ID4+Pj4NCj4gPj4+PiBGaXJzdGx5LCBJJ2QgcmVj b21tZW5kIHRoYXQgcGVvcGxlIHJlYWQgdGhlIFBESUYtTE8gW3NpY10gcHJvZmlsZQ0KPiA+Pj4+ IGRyYWZ0LiBUaGF0IGRyYWZ0IHRhbGtzIGFib3V0IGNhcmRpbmFsaXR5IGFuZCBJIHRoaW5rIHRo YXQgaXQgaXMNCj4gPj4+PiBleHRyZW1lbHkgaW1wb3J0YW50IHRvIHRoaXMgZGlzY3Vzc2lvbi4N Cj4gPj4+Pg0KPiA+Pj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZ2Vv cHJpdi1wZGlmLWxvLXByb2ZpbGUtMDQudHh0DQo+ID4+Pj4NCj4gPj4+PiBUaGlzIGRvY3VtZW50 IG5vdGVzIHRoYXQgaXQgaXMgcG9zc2libGUgdG8gaGF2ZSBjaXZpYyBhbmQgZ2VvZGV0aWMNCj4g Pj4+PiB0aGF0IHRvZ2V0aGVyIGZvcm0gYSBjb21wbGV4IHRvIGRlc2NyaWJlIGEgc2luZ2xlIGxv Y2F0aW9uLiBUaGUNCj4gPj4+PiBleGFtcGxlIHVzZWQgaXMgYSBzZXQgb2YgMi1kaW1lbnNpb25h bCBjb29yZGluYXRlcyB3aXRoIGFuIGFsdGl0dWRlDQo+ID4+Pj4gZXhwcmVzc2VkIGluIGJ1aWxk aW5nIGZsb29ycy4gVGhpcyBpcyB0aGUgcmVhc29uIHRoYXQgSSBzdXBwb3J0DQo+ID4+Pj4gYm90 aCwgbm90IGJlY2F1c2UgSSBzZWUgdGhhdCB0aGUgTG9TVCBzZXJ2ZXIgYmVpbmcgYWJsZSB0byBt YWtlDQo+ID4+Pj4gaW50ZWxsaWdlbnQgZGVjaXNpb25zIGFib3V0IG11bHRpcGxlIGNvbmZsaWN0 aW5nIHBpZWNlcyBvZg0KPiA+Pj4+IGluZm9ybWF0aW9uLg0KPiA+Pj4+DQo+ID4+Pj4gSGVyZSdz IGhvdyBJIHNlZSB0aGlzIHdvcmtpbmcuIFRoZSBzZWVrZXIgaGFzIGEgUElERi1MTy4gVGhleSBh cHBseQ0KPiA+Pj4+IHRoZSBzZWxlY3Rpb24gbWV0aG9kcyBkZXNjcmliZWQgaW4gdGhlIGFib3Zl IGRvY3VtZW50IHRvIHNlbGVjdCBhDQo+ID4+Pj4gc2luZ2xlIHR1cGxlIHRoYXQgY29udGFpbnMg bG9jYXRpb24gaW5mb3JtYXRpb24uDQo+ID4+Pj4gKFhQYXRoPSIvcHJlc2VuY2UvdHVwbGVbc3Rh dHVzL2dlb3ByaXZdWzFdIikNCj4gPj4+Pg0KPiA+Pj4+IFdoYXRldmVyIGxvY2F0aW9uIGluZm9y bWF0aW9uIHRoYXQgdHVwbGUgY29udGFpbnMsIGJlIGl0IGdlb2RldGljIG9yDQo+ID4+Pj4gY2l2 aWMsIHRoZSBzZWVrZXIgbGlmdHMgdGhlIGNvbnRlbnRzIG9mIHRoZSBsb2NhdGlvbi1pbmZvIGVs ZW1lbnQgYW5kDQo+ID4+Pj4gcHV0cyBpdCBpbiBhbiBhcHByb3ByaWF0ZSBMb1NUIHF1ZXJ5Lg0K PiA+Pj4+DQo+ID4+Pj4gSGVyZSBhcmUgdGhlIGFwcGxpY2FibGUgcnVsZXM6DQo+ID4+Pj4NCj4g Pj4+PiBSdWxlICMxOiBBIGdlb3ByaXYgZWxlbWVudCBNVVNUIGRlc2NyaWJlIGEgZGlzY3JldGUg bG9jYXRpb24uIFJ1bGUNCj4gPj4+PiAjNDogUHJvdmlkaW5nIG1vcmUgdGhhbiBvbmUgbG9jYXRp b24gaW4gYSBzaW5nbGUgPGxvY2F0aW9uLWluZm8+DQo+ID4+Pj4gZWxlbWVudCBTSE9VTEQgYmUg YXZvaWRlZCB3aGVyZSBwb3NzaWJsZS4gUnVsZSAjNTogV2hlbiBwcm92aWRpbmcNCj4gPj4+PiBt b3JlIHRoYW4gb25lIGxvY2F0aW9uIGluIGEgc2luZ2xlIDxsb2NhdGlvbi0gaW5mbz4gZWxlbWVu dCB0aGUNCj4gPj4+PiBsb2NhdGlvbnMgTVVTVCBiZSBwcm92aWRlZCBieSBhIGNvbW1vbiBzb3Vy Y2UuIFJ1bGUgIzY6IFByb3ZpZGluZw0KPiA+Pj4+IG1vcmUgdGhhbiBvbmUgbG9jYXRpb24gaW4g YSBzaW5nbGUgPGxvY2F0aW9uLWluZm8+IGVsZW1lbnQgU0hPVUxEDQo+ID4+Pj4gb25seSBiZSBk b25lIGlmIHRoZXkgZm9ybSBhIGNvbXBsZXggdG8gZGVzY3JpYmUgdGhlIHNhbWUgbG9jYXRpb24u DQo+ID4+Pj4gRm9yIGV4YW1wbGUsIGEgZ2VvZGV0aWMgbG9jYXRpb24gZGVzY3JpYmluZyBhIHBv aW50LCBhbmQgYSBjaXZpYw0KPiA+Pj4+IGxvY2F0aW9uIGluZGljYXRpbmcgdGhlIGZsb29yIGlu IGEgYnVpbGRpbmcuIFJ1bGUgIzg6IFdoZXJlIGEgUElERg0KPiA+Pj4+IGRvY3VtZW50IGNvbnRh aW5zIG1vcmUgdGhhbiBvbmUgdHVwbGUgY29udGFpbmluZyBhIHN0YXR1cyBlbGVtZW50DQo+ID4+ Pj4gd2l0aCBhIGdlb3ByaXYgbG9jYXRpb24gZWxlbWVudCAsIHRoZSBwcmlvcml0eSBvZiB0dXBs ZXMgU0hPVUxEIGJlDQo+ID4+Pj4gYmFzZWQgb24gdHVwbGUgcG9zaXRpb24gd2l0aGluIHRoZSBQ SURGIGRvY3VtZW50LiBUaGF0IGlzIHRvIHNheSwNCj4gPj4+PiB0aGUgdHVwbGUgd2l0aCB0aGUg aGlnaGVzdCBwcmlvcml0eSBsb2NhdGlvbiBvY2N1cnMgZWFybGllc3QgaW4gdGhlDQo+ID4+Pj4g UElERiBkb2N1bWVudC4gSW5pdGlhbCBwcmlvcml0eSBTSE9VTEQgYmUgZGV0ZXJtaW5lZCBieSB0 aGUNCj4gPj4+PiBvcmlnaW5hdGluZyBVQSwgdGhlIGZpbmFsIHByaW9yaXR5IE1BWSBiZSBkZXRl cm1pbmVkIGJ5IGEgcHJveHkgYWxvbmcNCj4gPj4+PiB0aGUgd2F5LCBvciB0aGUgVUFTLg0KPiA+ Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBG cm9tOiBIYW5uZXMgVHNjaG9mZW5pZw0KPiA+Pj4+PiBbbWFpbHRvOmhhbm5lcy50c2Nob2Zlbmln QHNpZW1lbnMuY29tXSBTZW50OiBXZWRuZXNkYXksIDcgSnVuZSAyMDA2DQo+ID4+Pj4+IDk6MzAg UE0gVG86IGVjcml0QGlldGYub3JnIFN1YmplY3Q6IFtFY3JpdF0gW2lzc3VlMl0gSXMgaXQgYWxs b3dlZA0KPiA+Pj4+PiB0byBzcGVjaWZ5IGNpdmljIGFuZCBnZW9zcGF0aWFsIGluZm9pbnRvIHRo ZSBxdWVyeT8NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gSGFubmVzIFRzY2hvZmVuaWcgPEhh bm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQ+IGFkZGVkIHRoZSBjb21tZW50Og0KPiA+Pj4+Pg0KPiA+ Pj4+PiBURU5UQVRJVkUgU1VNTUFSWToNCj4gPj4+Pj4NCj4gPj4+Pj4gSGVyZSBpcyB0aGUgdXBk YXRlOg0KPiA+Pj4+Pg0KPiA+Pj4+PiAqIEVpdGhlciBjaXZpYyBPUiBnZW9zcGF0aWFsIGluIGEg TG9TVCBxdWVyeQ0KPiA+Pj4+Pg0KPiA+Pj4+PiBNYXJjLCBIZW5uaW5nLCBTaGlkYSwgUmljaGFy ZCwgQnJpYW4sIEpvaG4gU2Nobml6bGVpbiwgQnlyb24gU21pdGgsDQo+ID4+Pj4+DQo+ID4+Pj4+ DQo+ID4+Pj4+DQo+ID4+Pj4+ICogQm90aCBjaXZpYyBBTkQgZ2Vvc3BhdGlhbCBwb3NzaWJsZSBp biBhIExvU1QgcXVlcnkNCj4gPj4+Pj4NCj4gPj4+Pj4gUm9nZXIsIE1hcnRpbiwgQW5keSwgSmFt ZXMgVy4NCj4gPj4+Pj4NCj4gPj4+Pj4gVGhlc2UgZm9sa3MgZG9uJ3Qgc2VlbSB0byB0YWtlIGEg Y2xlYXIgcG9zaXRpb246DQo+ID4+Pj4+DQo+ID4+Pj4+IEpvaG4gSGVhcnR5LCBKZWFuLUZyYW5j b2lzLCBDbGl2ZSBELlcuIEZlYXRoZXINCj4gPj4+Pj4NCj4gPj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gTG9TVCBJc3N1ZQ0KPiA+Pj4+PiBU cmFja2VyIDxoYW5uZXMudHNjaG9mZW5pZ0BzaWVtZW5zLmNvbT4NCj4gPj4+Pj4gPGh0dHA6Ly93 d3cudHNjaG9mZW5pZy5jb206ODA4MC9sb3N0L2lzc3VlMj4NCj4gPj4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+Pj4NCj4gPj4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gRWNyaXQgbWFp bGluZyBsaXN0DQo+ID4+Pj4+IEVjcml0QGlldGYub3JnIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+ID4+Pj4+DQo+ID4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0t DQo+ID4+Pj4NCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pg0KPiA+Pj4+IFRo aXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heSBj b250YWluDQo+ID4+Pj4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2 YXRlIGluZm9ybWF0aW9uLiBJZiB5b3UNCj4gPj4+PiBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kDQo+ID4+Pj4gZGVsZXRl IHRoZSBvcmlnaW5hbC4gQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YgdGhpcyBlbWFpbCBpcw0KPiA+ Pj4+IHByb2hpYml0ZWQuDQo+ID4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+ID4+Pj4NCj4gPj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pg0KPiA+Pj4+IFttZjJdDQo+ID4+Pj4NCj4g Pj4+Pg0KPiA+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPiA+Pj4+DQo+ID4+IC0NCj4gPj4NCj4g Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBFY3Jp dCBtYWlsaW5nIGxpc3QNCj4gPj4+PiBFY3JpdEBpZXRmLm9yZyBodHRwczovL3d3dzEuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KPiA+Pj4+DQo+ID4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gRWNyaXQgbWFpbGluZyBsaXN0 DQo+ID4+PiBFY3JpdEBpZXRmLm9yZw0KPiA+Pj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZWNyaXQNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPg0KPiA+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBUaGlzIG1lc3NhZ2UgaXMg Zm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCj4gPiBjb250YWluIHBy aXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4N Cj4gPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyDQo+ID4gaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5h dXRob3JpemVkIHVzZSBvZg0KPiA+IHRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCj4gPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gW21mMl0NCj4gPg0K PiA+DQo+ID4NCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNp Z25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJp ZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSBy ZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVs eSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlz IGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClttZjJd --===============1678200361== 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 --===============1678200361==-- From ecrit-bounces@ietf.org Thu Jun 08 03:47:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoFEc-0002vd-OZ; Thu, 08 Jun 2006 03:47:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoFEb-0002ux-T3 for ecrit@ietf.org; Thu, 08 Jun 2006 03:47:17 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoFEZ-0007Rt-IF for ecrit@ietf.org; Thu, 08 Jun 2006 03:47:17 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FoFEV-0003F9-0E; Thu, 08 Jun 2006 02:47:12 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Roger Marshall'" Subject: RE: [Ecrit] [issue9] LoST Response with PSAP Preference Date: Thu, 8 Jun 2006 03:47:05 -0400 Message-ID: <000a01c68acf$c1a49550$3932a8c0@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: AcaKj5WDKQDqM0RnQ8+thgY/2zOMCAAP0QYg In-Reply-To: <8FFB15E2-C546-4D94-8EBD-5F145E74169D@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: 25620135586de10c627e3628c432b04a 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 Sorry to chime in late here; I'm in Europe with intermittent Internet access. This whole line of thinking is incorrect in my opinion. There can only be ONE call center that takes the call. It cannot be the caller's opinion which one that is. There has to be a uniform rule. The campus notifies the PSAP or the PSAP notifies the campus. They have to agree on the rule. There may be a need for a mechanism whereby one entity notifies the other entity, but that is outside the scope of ecrit right now. There is only one entity that populates the data for a given location in the database. That entity gets to choose what goes in there. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Wednesday, June 07, 2006 8:08 PM To: Roger Marshall Cc: ecrit@ietf.org Subject: Re: [Ecrit] [issue9] LoST Response with PSAP Preference Storing user profiles on LoST servers hasn't really been part of the discussion so far. I wonder if there's a simple label we can apply to URLs, such as "public" and "private" or "campus" (and maybe a human-readable string since the decision which to call seems rather hard to automate). By the way, the dial strings for each such service would also likely differ. That, however, seems to be a somewhat different issue from using multiple URLs for fail-over routing. It seems unwise to commingle the two issues. On Jun 7, 2006, at 7:01 PM, Roger Marshall wrote: > When walking onto a campus, a call for emergency services shouldn't > result in two different scenarios, depending on which device/media > you're using. Though this is what happens in today's world. Today, > PSAP routing is inconsistent by technology, (you get campus PSAP when > using wired vs. city PSAP when using wireless). I think the > inconsistency should be fixed and it seems to me that LoST could help > fix it. > > I'm not promoting call-time user interaction with the returned set of > URIs, but rather when multiples are returned, that the device selects > the first one, and if for some reason it doesn't work, then the device > selects the second URI to route the call. The order in which the URIs > are returned is a LoST Server setting (based on jurisdiction > agreement). > > On the other hand, it now also occurs to me that we might want to > consider a user specified profile driven return order under certain > circumstances (let's say there is no way you want campus police to > come > to your aid). This one would probably be less controversial in a > commercial context for example, where you might want to exclude one > brand of gas station from being included in the returned list (e.g., > since they had a worse track record with oil-spills). > > > Roger Marshall > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 08 04:00:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoFRE-0004tB-Qt; Thu, 08 Jun 2006 04:00:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoFRD-0004t1-M8 for ecrit@ietf.org; Thu, 08 Jun 2006 04:00:19 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoFRC-0008JG-9W for ecrit@ietf.org; Thu, 08 Jun 2006 04:00:19 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML2ov-1FoFRB04lq-0000jR; Thu, 08 Jun 2006 10:00:17 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Thu, 08 Jun 2006 07:56:00 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1149753360.14.0.917436427178.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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ecrit] [issue2] Is it allowed to specify civic and geospatial info into the query? 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: TENTATIVE SUMMARY: Here is another update.=20 * Either civic OR geospatial in a LoST query=20 Marc, Henning, Shida, Richard, Brian, John Schnizlein, Byron Smith, Clive D= .W.=20 Feather, Tom * Both civic AND geospatial possible in a LoST query=20 Roger, Martin, Andy, James W. These folks don't seem to take a clear position: John Hearty, Jean-Francois __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 08 04:04:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoFVJ-0007Nq-0y; Thu, 08 Jun 2006 04:04:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoFVI-0007J6-Ei for ecrit@ietf.org; Thu, 08 Jun 2006 04:04:32 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoFVH-0000V2-2H for ecrit@ietf.org; Thu, 08 Jun 2006 04:04:32 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1FoFVG1vGX-0005td; Thu, 08 Jun 2006 10:04:30 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Thu, 08 Jun 2006 08:00:13 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1149753613.52.0.309041285279.issue10@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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ecrit] [issue10] Extensibility of the LoST Query 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 New submission from Hannes Tschofenig : Roger says: > > I proposed that LoST clients may be allowed to include special > attributes (not defined here, but which may be defined later) in the > LoST request. I would also say that the requirement for the LoST server > is that they could ignore these special attributes. Henning responds: I agree that we should be able to include additional query attributes beyon= d=20 the service identifier and location. As with most extensions, there are=20 probably two options: - ignore if you don't understand them (and maybe indicate the ones the serv= er=20 did take into account) - refuse the request if a server doesn't understand a particular qualifier For simplicity and because of the nature of what we're trying to do, I'm=20 inclined to only support the former. ---------- assignedto: hannes messages: 25 nosy: ecrit, hannes priority: critical status: chatting title: Extensibility of the LoST Query __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 08 04:08:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoFYr-0000dJ-Q2; Thu, 08 Jun 2006 04:08:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoFYq-0000d9-DU for ecrit@ietf.org; Thu, 08 Jun 2006 04:08:12 -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 1FoFYp-0000bz-0E for ecrit@ietf.org; Thu, 08 Jun 2006 04:08:12 -0400 Received: (qmail invoked by alias); 08 Jun 2006 08:08:07 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp042) with SMTP; 08 Jun 2006 10:08:07 +0200 X-Authenticated: #29516787 Message-ID: <4487DAE6.8030103@gmx.net> Date: Thu, 08 Jun 2006 10:08:06 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Thomson, Martin" Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfointo the query? References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Martin, Thomson, Martin wrote: ~snip~ > The only valid concern that remains is LoST server complexity. But > when you scratch beneath the surface a little, this begins to be less > of a source of intestinal torment. If we consider the occasions > where this composite location is possible, it quickly resolves down > to the floors altitude case, and not a whole lot more. In other > words, I can't think of a good alternative example. That means that > the LoST server can safely ignore the > "2" that goes along with the > geodetic information, except where you have the weird case where the > bottom-floor cinema is served by a different PSAP to the upper-floors > (not my example). It seems that there is no real use case here where composite location is useful. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 08 06:31:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoHnf-0002Y6-K8; Thu, 08 Jun 2006 06:31:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoHne-0002Un-J8 for ecrit@ietf.org; Thu, 08 Jun 2006 06:31:38 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoHnc-00014M-AQ for ecrit@ietf.org; Thu, 08 Jun 2006 06:31:38 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 05:32:02 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 08 Jun 2006 05:32:02 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 05:32:01 -0500 Message-ID: From: "Winterbottom, James" To: "Hannes Tschofenig" , "Thomson, Martin" Date: Thu, 8 Jun 2006 05:31:36 -0500 Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivic and geospatialinfointo the query? MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 08 Jun 2006 10:32:01.0398 (UTC) FILETIME=[C717E160:01C68AE6] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <4487DAE6.8030103@gmx.net> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] [issue2] Is it allowed to specifycivic and geospatialinfointo the query? Thread-Index: AcaK0ra0d9t5Q7GNSiqYibijsfMAzQAE7s4g X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This is not quite true. There is a case where a composite value is very useful for the purposes of services dispatch. The problem is that the end-point may well not be able to make a discernable difference for the purposes of what is required for route determination. Are we now suggesting that a location should consist of 2 different geopriv objects, one for route determination and one for dispatch? > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Thursday, 8 June 2006 6:08 PM > To: Thomson, Martin > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] [issue2] Is it allowed to specifycivic and > geospatialinfointo the query? >=20 > Hi Martin, >=20 > Thomson, Martin wrote: > ~snip~ >=20 > > The only valid concern that remains is LoST server complexity. But > > when you scratch beneath the surface a little, this begins to be less > > of a source of intestinal torment. If we consider the occasions > > where this composite location is possible, it quickly resolves down > > to the floors altitude case, and not a whole lot more. In other > > words, I can't think of a good alternative example. That means that > > the LoST server can safely ignore the > > "2" that goes along with the > > geodetic information, except where you have the weird case where the > > bottom-floor cinema is served by a different PSAP to the upper-floors > > (not my example). >=20 > It seems that there is no real use case here where composite location is > useful. >=20 > Ciao > Hannes >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 08 06:41:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoHwp-0006KX-FT; Thu, 08 Jun 2006 06:41:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoHwo-0006KS-Pw for ecrit@ietf.org; Thu, 08 Jun 2006 06:41:06 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FoHwn-0002Bp-C3 for ecrit@ietf.org; Thu, 08 Jun 2006 06:41:06 -0400 Received: (qmail invoked by alias); 08 Jun 2006 10:34:23 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp014) with SMTP; 08 Jun 2006 12:34:23 +0200 X-Authenticated: #29516787 Message-ID: <4487FD2F.9090701@gmx.net> Date: Thu, 08 Jun 2006 12:34:23 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Ecrit] [issue2] Is it allowed to specifycivic and geospatialinfointo the query? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: ecrit@ietf.org, "Thomson, Martin" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi James, Winterbottom, James wrote: > This is not quite true. > There is a case where a composite value is very useful for the purposes > of services dispatch. The problem is that the end-point may well not be > able to make a discernable difference for the purposes of what is > required for route determination. > > Are we now suggesting that a location should consist of 2 different > geopriv objects, one for route determination and one for dispatch? > No. We are just trying to figure out what info we need to dump into the LoST query. Ciao Hannes > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: Thursday, 8 June 2006 6:08 PM >>To: Thomson, Martin >>Cc: ecrit@ietf.org >>Subject: Re: [Ecrit] [issue2] Is it allowed to specifycivic and >>geospatialinfointo the query? >> >>Hi Martin, >> >>Thomson, Martin wrote: >>~snip~ >> >> >>>The only valid concern that remains is LoST server complexity. But >>>when you scratch beneath the surface a little, this begins to be > > less > >>>of a source of intestinal torment. If we consider the occasions >>>where this composite location is possible, it quickly resolves down >>>to the floors altitude case, and not a whole lot more. In other >>>words, I can't think of a good alternative example. That means that >>>the LoST server can safely ignore the >>>"2" that goes along with the >>>geodetic information, except where you have the weird case where the >>>bottom-floor cinema is served by a different PSAP to the > > upper-floors > >>>(not my example). >> >>It seems that there is no real use case here where composite location > > is > >>useful. >> >>Ciao >>Hannes >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit > > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 08 06:54:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoI9g-0007OT-6k; Thu, 08 Jun 2006 06:54:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoI9e-0007OI-Vg for ecrit@ietf.org; Thu, 08 Jun 2006 06:54:22 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoI9d-00049L-M8 for ecrit@ietf.org; Thu, 08 Jun 2006 06:54:22 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 05:54:48 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 08 Jun 2006 05:54:48 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 05:54:47 -0500 Message-ID: From: "Winterbottom, James" To: "Hannes Tschofenig" Date: Thu, 8 Jun 2006 05:54:18 -0500 Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivic and geospatialinfointo the query? MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 08 Jun 2006 10:54:47.0616 (UTC) FILETIME=[F56C3400:01C68AE9] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <4487FD2F.9090701@gmx.net> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] [issue2] Is it allowed to specifycivic and geospatialinfointo the query? Thread-Index: AcaK5x28HAzWzOx6QT2Kplmq8jhdtQAAgRng X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: ecrit@ietf.org, "Thomson, Martin" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Hannes, The more specific you make the requirements on what can be passed to the LoST server, the more intelligent and aware of the local policies you need to make the end-point. This is a bad idea, and something that policies in the LoST server should resolve. Either the routing and dispatch information is the same, or it is not. And if it is not then the end-point should be able to retrieve them or otherwise determine them independently and they should be flagged as such. To date, while it has not been categorically stated, I have had the assumption that what I route on is what I deliver to the PSAP. Cheers James > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Thursday, 8 June 2006 8:34 PM > To: Winterbottom, James > Cc: Thomson, Martin; ecrit@ietf.org > Subject: Re: [Ecrit] [issue2] Is it allowed to specifycivic and > geospatialinfointo the query? >=20 > Hi James, >=20 > Winterbottom, James wrote: > > This is not quite true. > > There is a case where a composite value is very useful for the purposes > > of services dispatch. The problem is that the end-point may well not be > > able to make a discernable difference for the purposes of what is > > required for route determination. > > > > Are we now suggesting that a location should consist of 2 different > > geopriv objects, one for route determination and one for dispatch? > > >=20 > No. We are just trying to figure out what info we need to dump into the > LoST query. >=20 > Ciao > Hannes >=20 >=20 > > > > > >>-----Original Message----- > >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>Sent: Thursday, 8 June 2006 6:08 PM > >>To: Thomson, Martin > >>Cc: ecrit@ietf.org > >>Subject: Re: [Ecrit] [issue2] Is it allowed to specifycivic and > >>geospatialinfointo the query? > >> > >>Hi Martin, > >> > >>Thomson, Martin wrote: > >>~snip~ > >> > >> > >>>The only valid concern that remains is LoST server complexity. But > >>>when you scratch beneath the surface a little, this begins to be > > > > less > > > >>>of a source of intestinal torment. If we consider the occasions > >>>where this composite location is possible, it quickly resolves down > >>>to the floors altitude case, and not a whole lot more. In other > >>>words, I can't think of a good alternative example. That means that > >>>the LoST server can safely ignore the > >>>"2" that goes along with the > >>>geodetic information, except where you have the weird case where the > >>>bottom-floor cinema is served by a different PSAP to the > > > > upper-floors > > > >>>(not my example). > >> > >>It seems that there is no real use case here where composite location > > > > is > > > >>useful. > >> > >>Ciao > >>Hannes > >> > >>_______________________________________________ > >>Ecrit mailing list > >>Ecrit@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > ------------------------------------------------------------------------ > ------------------------ > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > ------------------------------------------------------------------------ > ------------------------ > > [mf2] > > > > >=20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 08 08:00:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoJB6-00044G-6W; Thu, 08 Jun 2006 07:59:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoJB3-00044B-VV for ecrit@ietf.org; Thu, 08 Jun 2006 07:59:53 -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 1FoJB2-00039E-Fx for ecrit@ietf.org; Thu, 08 Jun 2006 07:59:53 -0400 Received: (qmail invoked by alias); 08 Jun 2006 11:59:51 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp001) with SMTP; 08 Jun 2006 13:59:51 +0200 X-Authenticated: #29516787 Message-ID: <44881136.3060000@gmx.net> Date: Thu, 08 Jun 2006 13:59:50 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Ecrit] [issue2] Is it allowed to specifycivic and geospatialinfointo the query? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: ecrit@ietf.org, "Thomson, Martin" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi James, Winterbottom, James wrote: > Hi Hannes, > > The more specific you make the requirements on what can be passed to the > LoST server, the more intelligent and aware of the local policies you > need to make the end-point. This is a bad idea, and something that > policies in the LoST server should resolve. If I look at the list of people that support the idea of passing either geo OR civic (but not both) then I recognize that it is quite long in the meanwhile. > Either the routing and dispatch information is the same, or it is not. > And if it is not then the end-point should be able to retrieve them or > otherwise determine them independently and they should be flagged as > such. To date, while it has not been categorically stated, I have had > the assumption that what I route on is what I deliver to the PSAP. I think we have two different cases here: (a) composite location info (mixed civic and geo) (b) multiple different location infos (possibly from different sources) Most of the responses to the mailing list thread referred to (b) where you obtain location info using different protocols, potentially at different points in time and also via different (virtual) interfaces. It is quite reasonable to have multiple geo location objects that may be available to the LoST client. I had the impression that people argued that you should send a separate query for each location object. This makes sense to me. These scenario for (a) is a bit different: We can obviously construct scenarios where the composite location info makes sense. The question, however, is whether these scenarios are important for us. We add more complexity with increased functionality. Ciao Hannes > > Cheers > James > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: Thursday, 8 June 2006 8:34 PM >>To: Winterbottom, James >>Cc: Thomson, Martin; ecrit@ietf.org >>Subject: Re: [Ecrit] [issue2] Is it allowed to specifycivic and >>geospatialinfointo the query? >> >>Hi James, >> >>Winterbottom, James wrote: >> >>>This is not quite true. >>>There is a case where a composite value is very useful for the > > purposes > >>>of services dispatch. The problem is that the end-point may well not > > be > >>>able to make a discernable difference for the purposes of what is >>>required for route determination. >>> >>>Are we now suggesting that a location should consist of 2 different >>>geopriv objects, one for route determination and one for dispatch? >>> >> >>No. We are just trying to figure out what info we need to dump into > > the > >>LoST query. >> >>Ciao >>Hannes >> >> >> >>> >>>>-----Original Message----- >>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>Sent: Thursday, 8 June 2006 6:08 PM >>>>To: Thomson, Martin >>>>Cc: ecrit@ietf.org >>>>Subject: Re: [Ecrit] [issue2] Is it allowed to specifycivic and >>>>geospatialinfointo the query? >>>> >>>>Hi Martin, >>>> >>>>Thomson, Martin wrote: >>>>~snip~ >>>> >>>> >>>> >>>>>The only valid concern that remains is LoST server complexity. But >>>>>when you scratch beneath the surface a little, this begins to be >>> >>>less >>> >>> >>>>>of a source of intestinal torment. If we consider the occasions >>>>>where this composite location is possible, it quickly resolves down >>>>>to the floors altitude case, and not a whole lot more. In other >>>>>words, I can't think of a good alternative example. That means > > that > >>>>>the LoST server can safely ignore the >>>>>"2" that goes along with > > the > >>>>>geodetic information, except where you have the weird case where > > the > >>>>>bottom-floor cinema is served by a different PSAP to the >>> >>>upper-floors >>> >>> >>>>>(not my example). >>>> >>>>It seems that there is no real use case here where composite > > location > >>>is >>> >>> >>>>useful. >>>> >>>>Ciao >>>>Hannes >>>> >>>>_______________________________________________ >>>>Ecrit mailing list >>>>Ecrit@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >>> > ------------------------------------------------------------------------ > >>------------------------ >> >>>This message is for the designated recipient only and may >>>contain privileged, proprietary, or otherwise private information. >>>If you have received it in error, please notify the sender >>>immediately and delete the original. Any unauthorized use of >>>this email is prohibited. >>> > > ------------------------------------------------------------------------ > >>------------------------ >> >>>[mf2] >>> >>> >> > > ------------------------------------------------------------------------------------------------ > 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 Jun 08 08:54:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoK1T-0003Jh-R3; Thu, 08 Jun 2006 08:54:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoK1S-0003Jc-S4 for ecrit@ietf.org; Thu, 08 Jun 2006 08:54:02 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoK1R-0001C5-5K for ecrit@ietf.org; Thu, 08 Jun 2006 08:54:02 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 08 Jun 2006 05:54:00 -0700 X-IronPort-AV: i="4.05,220,1146466800"; d="scan'208"; a="1821992363:sNHT36783620" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k58Cs0vc012072; Thu, 8 Jun 2006 05:54:00 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k58Cs0cL000353; Thu, 8 Jun 2006 05:54:00 -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.211); Thu, 8 Jun 2006 05:54:00 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 05:53:59 -0700 From: "Marc Linsner" To: "'Thomson, Martin'" , , "'Tom-PT Taylor'" Subject: RE: [Ecrit] [issue2] Is it allowed to specify civicand geospatialinfointo the query? Date: Thu, 8 Jun 2006 08:53:58 -0400 Message-ID: <003c01c68afa$9c57ba90$2c0d0d0a@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.2869 In-Reply-To: Thread-Index: AcaKnqd2asroiLOtSPiHFj9Qgp1KvgAC4SBAABK24QA= X-OriginalArrivalTime: 08 Jun 2006 12:53:59.0584 (UTC) FILETIME=[9C53EA00:01C68AFA] DKIM-Signature: a=rsa-sha1; q=dns; l=10020; t=1149771240; x=1150635240; c=relaxed/simple; s=sjdkim5001; 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]=20[issue2]=20Is=20it=20allowed=20to=20specify=20civicand =09geospatialinfointo=20the=20query?; X=v=3Dcisco.com=3B=20h=3Dp/XbRvyDc+zjtYgVmedhTVu4aA0=3D; b=Jh3Ohka3OmsnA37cDNufGn7R5h5xz1tyrZNbRC3aBpBILFH46RRp12NXmAvrmHpaYVr8S2xe 7juKlunVEm9vqN+h1XdXV2btZAt0dxhQb5IMr369P3oQ9AaNrUXh6WOz; Authentication-Results: sj-dkim-5.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 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 issue of a having a complex location, geo for horizontal and civic for vertical, IMO, is an IETF/GeoPriv self-inflicted problem. Discussions pre-RFC3825 concluded the vertical component of 3-dimensional geo coordinates, in their native form (feet/meters), were not very helpful for the emergency services call routing and dispatching use cases. Hence, the measurement unit concept within the RFC3825 location information that allows expressing the vertical information in units other than normal feet/meters associated with geo representations. When GeoPriv created RFC4119, this concept of expressing the vertical component of a geo representation in units other than the geo-normal feet/meters did not carry forward from RFC3825 into RFC4119. IMO, admittedly biased, this was a mistake. So, here we are trying to deal with: 1) Accept emergency call routing on 2-dimensional info only because we believe LoST is too stupid to deal with complex location representations. 2) Create the LoST query that mandates a single location, but can include both geo and civic field(s). (I believe that we can give guidance to make this workable.) 3) Change RFC4119 to allow the vertical measurement unit concept within a geo representation. If anyone can think of other cases where we will have complex representations, we need to discuss them now. -Marc- > > It is better to think of anything that appears within a > single element as a single location. You > aren't sending more than one location to the LoST server. If > you think about it as a single "location" with multiple parts > (elements), the fears about multiple responses disappear. > > The only valid concern that remains is LoST server > complexity. But when you scratch beneath the surface a > little, this begins to be less of a source of intestinal > torment. If we consider the occasions where this composite > location is possible, it quickly resolves down to the floors > altitude case, and not a whole lot more. In other words, I > can't think of a good alternative example. That means that > the LoST server can safely ignore the > "2" that goes along > with the geodetic information, except where you have the > weird case where the bottom-floor cinema is served by a > different PSAP to the upper-floors (not my example). > > > > -----Original Message----- > > From: Shida Schubert [mailto:shida@ntt-at.com] > > Sent: Thursday, 8 June 2006 11:57 AM > > To: Tom-PT Taylor > > Cc: Thomson, Martin; ecrit@ietf.org > > Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and > > geospatialinfointo the query? > > > > > > Hi Tom; > > > > According to what I understand the issue still remains because > > Rule#5 and Rule#6 allows a compound location information > composed of > > both geo and civic in single element. > > > > Two of which location type is a supplementary location info(floor or > > altitude) > > that can be dropped from the LoST query is probably not > easy to find out. > > I guess we can't expect all the intermediary that supports > LoST client > > functionality, the ability to compute the two location inside one > > element to seek out the proper location > information to > > submit with the LoST query. > > > > I think I understand the problem, but I still feel very > uncomfortable > > to send more than one location to LoST server in a single > query. I'd > > rather loose the ability to express the flexibility the > > pidf-lo-profile has about including more than one location. > > > > If more than one location needs to be included in single > location-info > > element, may be we can define a new element or an attribute to an > > "tuple" element to express that a location information A adds > > additional info to location information B? > > > > Thanks & Regards > > Shida > > > > Tom-PT Taylor wrote: > > > OK, I've looked over the draft, and the rules make sense. I would > > > still, as the "call server" programmer, choose the first > > > location-info element and send only it. There's no way we should > > > expect the mapping server to wade through potentially > many objects > > > when (within our > > > charter) it makes sense to reply to only one of them. > > > > > > Thomson, Martin [Business:EXTRNL:ANDREW] wrote: > > >> I'd like to clarify my position, because I think that this > > >> discussion has headed off course a little. > > >> > > >> Firstly, I'd recommend that people read the PDIF-LO > [sic] profile > > >> draft. That draft talks about cardinality and I think that it is > > >> extremely important to this discussion. > > >> > > >> > http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile-04.tx > > >> t > > >> > > >> This document notes that it is possible to have civic > and geodetic > > >> that together form a complex to describe a single location. The > > >> example used is a set of 2-dimensional coordinates with > an altitude > > >> expressed in building floors. This is the reason that I support > > >> both, not because I see that the LoST server being able to make > > >> intelligent decisions about multiple conflicting pieces of > > >> information. > > >> > > >> Here's how I see this working. The seeker has a PIDF-LO. > They apply > > >> the selection methods described in the above document to > select a > > >> single tuple that contains location information. > > >> (XPath="/presence/tuple[status/geopriv][1]") > > >> > > >> Whatever location information that tuple contains, be it > geodetic > > >> or civic, the seeker lifts the contents of the location-info > > >> element and puts it in an appropriate LoST query. > > >> > > >> Here are the applicable rules: > > >> > > >> Rule #1: A geopriv element MUST describe a discrete > location. Rule > > >> #4: Providing more than one location in a single > > >> element SHOULD be avoided where possible. Rule #5: When > providing > > >> more than one location in a single element the > > >> locations MUST be provided by a common source. Rule #6: > Providing > > >> more than one location in a single > element SHOULD > > >> only be done if they form a complex to describe the same > location. > > >> For example, a geodetic location describing a point, and a civic > > >> location indicating the floor in a building. Rule #8: > Where a PIDF > > >> document contains more than one tuple containing a > status element > > >> with a geopriv location element , the priority of tuples > SHOULD be > > >> based on tuple position within the PIDF document. That > is to say, > > >> the tuple with the highest priority location occurs > earliest in the > > >> PIDF document. Initial priority SHOULD be determined by the > > >> originating UA, the final priority MAY be determined by a proxy > > >> along the way, or the UAS. > > >> > > >> > > >>> -----Original Message----- From: Hannes Tschofenig > > >>> [mailto:hannes.tschofenig@siemens.com] Sent: Wednesday, 7 June > > >>> 2006 9:30 PM To: ecrit@ietf.org Subject: [Ecrit] [issue2] Is it > > >>> allowed to specify civic and geospatial infointo the query? > > >>> > > >>> > > >>> Hannes Tschofenig added the comment: > > >>> > > >>> TENTATIVE SUMMARY: > > >>> > > >>> Here is the update: > > >>> > > >>> * Either civic OR geospatial in a LoST query > > >>> > > >>> Marc, Henning, Shida, Richard, Brian, John Schnizlein, Byron > > >>> Smith, > > >>> > > >>> > > >>> > > >>> * Both civic AND geospatial possible in a LoST query > > >>> > > >>> Roger, Martin, Andy, James W. > > >>> > > >>> These folks don't seem to take a clear position: > > >>> > > >>> John Hearty, Jean-Francois, Clive D.W. Feather > > >>> > > >>> __________________________________________________ LoST Issue > > >>> Tracker > > >>> > > >>> __________________________________________________ > > >>> > > >>> _______________________________________________ Ecrit > mailing list > > >>> Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit > > >> > > >> > ------------------------------------------------------------------- > > >> ---- > > ------------------------- > > >> > > >> This message is for the designated recipient only and > may contain > > >> privileged, proprietary, or otherwise private > information. If you > > >> have received it in error, please notify the sender > immediately and > > >> delete the original. Any unauthorized use of this email is > > >> prohibited. > > >> > ------------------------------------------------------------------- > > >> ---- > > ------------------------- > > >> > > >> [mf2] > > >> > > >> > > >> > ------------------------------------------------------------------- > > >> ---- > > - > > >> > > >> > > >> _______________________________________________ Ecrit > mailing list > > >> Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 08 10:38:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoLeH-0006UY-MA; Thu, 08 Jun 2006 10:38:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoLeG-0006UQ-O3 for ecrit@ietf.org; Thu, 08 Jun 2006 10:38:12 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoLeF-0001lR-GI for ecrit@ietf.org; Thu, 08 Jun 2006 10:38:12 -0400 Received: from [192.168.0.41] (pool-138-89-46-232.mad.east.verizon.net [138.89.46.232]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k58Dd6k1018332 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 8 Jun 2006 09:39:07 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5A8A4AC9-8F41-4878-8FCC-C4D4002C6175@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfointo the query? Date: Thu, 8 Jun 2006 09:39:02 -0400 To: "Thomson, Martin" X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I have no objection to having a "hybrid" address if it is indeed logically a single address which can never, ever lead to two different PSAPs. As Marc notes, one has to ask if this is really the best way to organize location information since we are now commingling two very different cases: (1) a (purportedly) single location determined by two different mechanisms, i.e., with the potential that civic and geo are actually not referring to the same point or building due to measurement errors of various sorts; (2) a hybrid location, where x and y coordinates are specified in geo and z coordinates in "civic" (floors) Plus, there are then the various civic "enhancements" such as building names, suite number or tenant name that are useful in practice, so they might also get thrown in for model (2). Maybe this is a geopriv topic, but this strikes me as a recipe for confusion. Having to pick apart the various cases of - geo has altitude, civic has (only) a floor, but maybe also a building name -> could be (1) or (2) - geo has no altitude, civic has only floor (but maybe also building name and tenant or house number) -> (2) - geo has no altitude, but civic has street-level addressing -> (1) - and plenty more seems to lead to lots of special cases that are likely to increase as we add more elements to either civic or geo. Henning On Jun 7, 2006, at 11:35 PM, Thomson, Martin wrote: > It is better to think of anything that appears within a single > element as a single location. You aren't sending > more than one location to the LoST server. If you think about it > as a single "location" with multiple parts (elements), the fears > about multiple responses disappear. > > The only valid concern that remains is LoST server complexity. But > when you scratch beneath the surface a little, this begins to be > less of a source of intestinal torment. If we consider the > occasions where this composite location is possible, it quickly > resolves down to the floors altitude case, and not a whole lot > more. In other words, I can't think of a good alternative > example. That means that the LoST server can safely ignore the > "2" that goes along with > the geodetic information, except where you have the weird case > where the bottom-floor cinema is served by a different PSAP to the > upper-floors (not my example). > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 08 11:27:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoMQH-0003o9-PT; Thu, 08 Jun 2006 11:27:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoMQG-0003nv-R2 for ecrit@ietf.org; Thu, 08 Jun 2006 11:27:48 -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 1FoLMq-0008Qz-Nl for ecrit@ietf.org; Thu, 08 Jun 2006 10:20:12 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoKjE-0007mg-RG for ecrit@ietf.org; Thu, 08 Jun 2006 09:39:17 -0400 Received: from [192.168.0.41] (pool-138-89-46-232.mad.east.verizon.net [138.89.46.232]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k58Dd6k1018332 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 8 Jun 2006 09:39:07 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5A8A4AC9-8F41-4878-8FCC-C4D4002C6175@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfointo the query? Date: Thu, 8 Jun 2006 09:39:02 -0400 To: "Thomson, Martin" X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: -1.9 (-) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I have no objection to having a "hybrid" address if it is indeed logically a single address which can never, ever lead to two different PSAPs. As Marc notes, one has to ask if this is really the best way to organize location information since we are now commingling two very different cases: (1) a (purportedly) single location determined by two different mechanisms, i.e., with the potential that civic and geo are actually not referring to the same point or building due to measurement errors of various sorts; (2) a hybrid location, where x and y coordinates are specified in geo and z coordinates in "civic" (floors) Plus, there are then the various civic "enhancements" such as building names, suite number or tenant name that are useful in practice, so they might also get thrown in for model (2). Maybe this is a geopriv topic, but this strikes me as a recipe for confusion. Having to pick apart the various cases of - geo has altitude, civic has (only) a floor, but maybe also a building name -> could be (1) or (2) - geo has no altitude, civic has only floor (but maybe also building name and tenant or house number) -> (2) - geo has no altitude, but civic has street-level addressing -> (1) - and plenty more seems to lead to lots of special cases that are likely to increase as we add more elements to either civic or geo. Henning On Jun 7, 2006, at 11:35 PM, Thomson, Martin wrote: > It is better to think of anything that appears within a single > element as a single location. You aren't sending > more than one location to the LoST server. If you think about it > as a single "location" with multiple parts (elements), the fears > about multiple responses disappear. > > The only valid concern that remains is LoST server complexity. But > when you scratch beneath the surface a little, this begins to be > less of a source of intestinal torment. If we consider the > occasions where this composite location is possible, it quickly > resolves down to the floors altitude case, and not a whole lot > more. In other words, I can't think of a good alternative > example. That means that the LoST server can safely ignore the > "2" that goes along with > the geodetic information, except where you have the weird case > where the bottom-floor cinema is served by a different PSAP to the > upper-floors (not my example). > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 08 12:28:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoNMX-0003fL-MZ; Thu, 08 Jun 2006 12:28:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoNMV-0003ZC-VK for ecrit@ietf.org; Thu, 08 Jun 2006 12:27:59 -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 1FoNMU-0001fY-Ot for ecrit@ietf.org; Thu, 08 Jun 2006 12:27:59 -0400 Received: from [10.0.1.103] ([::ffff:68.106.115.242]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Thu, 08 Jun 2006 12:28:25 -0400 id 01588104.4488502A.00000CD8 In-Reply-To: <5A8A4AC9-8F41-4878-8FCC-C4D4002C6175@cs.columbia.edu> References: <5A8A4AC9-8F41-4878-8FCC-C4D4002C6175@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v750) Message-Id: From: Andrew Newton Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfointo the query? Date: Thu, 8 Jun 2006 12:27:56 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ecrit@ietf.org, "Thomson, Martin" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1937579975==" Errors-To: ecrit-bounces@ietf.org --===============1937579975== Content-Type: multipart/alternative; boundary=Apple-Mail-5--321814837 --Apple-Mail-5--321814837 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jun 8, 2006, at 9:39 AM, Henning Schulzrinne wrote: > I have no objection to having a "hybrid" address if it is indeed > logically a single address which can never, ever lead to two > different PSAPs. That works for me. -andy --Apple-Mail-5--321814837 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=US-ASCII
On Jun 8, 2006, at 9:39 AM, Henning Schulzrinne wrote:

I have no objection to having a "hybrid" address if it is indeed logically a single address which can never, ever lead to two different PSAPs.


That works for me.

-andy
--Apple-Mail-5--321814837-- --===============1937579975== 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 --===============1937579975==-- From ecrit-bounces@ietf.org Thu Jun 08 12:33:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoNRy-0007Qr-DL; Thu, 08 Jun 2006 12:33:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoNRx-0007Qm-6I for ecrit@ietf.org; Thu, 08 Jun 2006 12:33:37 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoNRv-0001vm-MB for ecrit@ietf.org; Thu, 08 Jun 2006 12:33:37 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k58GXWCB024254; Thu, 8 Jun 2006 11:33:33 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 8 Jun 2006 17:33:32 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0132CB572@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Thomson, Martin" , shida@ntt-at.com Subject: =?UTF-8?B?UkU6IFtFY3JpdF0gW2lzc3VlMl0gSXMgaXQgYWxsb3dlZCB0byBz?= =?UTF-8?B?cGVjaWZ5IGNpdmljYW5kCWdlb3NwYXRpYWxpbmZvaW50byB0aGUgcXVlcnk/?= Date: Thu, 8 Jun 2006 17:33:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: e95407604bef3289cd27cb4f3b3a35b4 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This seems to me to getting back to the real issue of which entity is responsible for ensuring that the information is representing one unambiguous location, and which entity has to take what action if it doesn't. This could be any of (if I understand the terms in the requirements document correctly): The calling user The emergency service routeing proxy (or mapping client) The mapping server. Certainly we place constraints on the calling user, by specifying a syntax for the location object, but that does not prevent it being ambiguous. I would also suggest that whatever we agree must always produce the same result. Tom has made the suggestion that in cases of ambiguity, simplicity would argue for the mapping server to take the first of any ambiguous values. If I wrote my software a different way, I am sure I could argue that the simplest implementation would be to take the last of any ambiguous values. But I am not convinced it is the function of the mapping server to sort out ambiguity in the first place. regards Keith > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: 08 June 2006 08:17 > To: shida@ntt-at.com > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] [issue2] Is it allowed to specify civicand > geospatialinfointo the query? > > > I think that you meant to ask me, so I'll answer. I'm not > sure if that's a good thing or not to be mistaken for Tom ;) > > I'm not sure if I understand your scenario. Do you have a > server that doesn't support geo, but has extra information > that it can use? > > The only scenarios that I can see arising from this are those > where one piece is not understood (either the geo, or civic > part). Two things can happen > > - the other pieces are sufficient to get a result (I don't > understand civic, but I don't care about altitude), or > > - the other pieces are pretty ambiguous (I don't understand > geo, and the second floor anywhere on the planet isn't > specific enough for me). > > > -----Original Message----- > > From: Shida Schubert [mailto:shida@ntt-at.com] > > Sent: Thursday, 8 June 2006 4:20 PM > > To: Thomson, Martin > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] [issue2] Is it allowed to specify civicand > > geospatialinfointo the query? > > > > > > Hi Tom; > > > > I agree with you to some extent but I am still not comfortable. > > > > As long as the two information really supplement each > other, and one of > > the information is sufficient to find the proper PSAP URI and both > > information only resolves to one PSAP URI if both were > queried, I might > > be able to live with that. > > > > Just out of curiosity. Assuming LoST supports query with location > > information with two location type as long as it is a > compound location > > information where two information supplement each other, what would > > happen if LoST server that was queried did not support geo and it > > happend to have the supplementary information in geo(latitude)? > > > > If it does not understand civic location format, it is > unable to identify > > the information to be used to find the proper PSAP and > might proceed to > > query the database using the location info provided in geo > format(only > > latitude info. > > > > I guess it could return an error stating that it's an > invalid location > > as well as default uri for the service requested(e.g. > Default PSAP URI > > for the > > region LoST server is responsible)... > > > > Regards > > Shida > > > > Thomson, Martin wrote: > > > It is better to think of anything that appears within a single > > element as a single location. You aren't > sending more > > than one location to the LoST server. If you think about > it as a single > > "location" with multiple parts (elements), the fears about multiple > > responses disappear. > > > > > > The only valid concern that remains is LoST server > complexity. But when > > you scratch beneath the surface a little, this begins to be > less of a > > source of intestinal torment. If we consider the occasions > where this > > composite location is possible, it quickly resolves down to > the floors > > altitude case, and not a whole lot more. In other words, I > can't think of > > a good alternative example. That means that the LoST > server can safely > > ignore the "2" that > goes along > > with the geodetic information, except where you have the > weird case where > > the bottom-floor cinema is served by a different PSAP to > the upper-floors > > (not my example). > > > > > > > > > > > >> -----Original Message----- > > >> From: Shida Schubert [mailto:shida@ntt-at.com] > > >> Sent: Thursday, 8 June 2006 11:57 AM > > >> To: Tom-PT Taylor > > >> Cc: Thomson, Martin; ecrit@ietf.org > > >> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and > > >> geospatialinfointo the query? > > >> > > >> > > >> Hi Tom; > > >> > > >> According to what I understand the issue still remains because > > >> Rule#5 and Rule#6 allows a compound location information > composed of > > >> both geo and civic in single element. > > >> > > >> Two of which location type is a supplementary location > info(floor or > > >> altitude) > > >> that can be dropped from the LoST query is probably not > easy to find > > out. > > >> I guess we can't expect all the intermediary that > supports LoST client > > >> functionality, > > >> the ability to compute the two location inside one > > > >> element to > > >> seek out the proper location information to submit with > the LoST query. > > >> > > >> I think I understand the problem, but I still feel very > uncomfortable > > to > > >> send > > >> more than one location to LoST server in a single query. > I'd rather > > >> loose the > > >> ability to express the flexibility the pidf-lo-profile has about > > >> including more > > >> than one location. > > >> > > >> If more than one location needs to be included in single > location-info > > >> element, > > >> may be we can define a new element or an attribute to an "tuple" > > element > > >> to express that a location information A adds additional info to > > location > > >> information B? > > >> > > >> Thanks & Regards > > >> Shida > > >> > > >> Tom-PT Taylor wrote: > > >> > > >>> OK, I've looked over the draft, and the rules make > sense. I would > > >>> still, as the "call server" programmer, choose the > first location-info > > >>> element and send only it. There's no way we should > expect the mapping > > >>> server to wade through potentially many objects when (within our > > >>> charter) it makes sense to reply to only one of them. > > >>> > > >>> Thomson, Martin [Business:EXTRNL:ANDREW] wrote: > > >>> > > >>>> I'd like to clarify my position, because I think that > this discussion > > >>>> has headed off course a little. > > >>>> > > >>>> Firstly, I'd recommend that people read the PDIF-LO > [sic] profile > > >>>> draft. That draft talks about cardinality and I think > that it is > > >>>> extremely important to this discussion. > > >>>> > > >>>> > http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile-04.txt > > >>>> > > >>>> This document notes that it is possible to have civic > and geodetic > > >>>> that together form a complex to describe a single location. The > > >>>> example used is a set of 2-dimensional coordinates > with an altitude > > >>>> expressed in building floors. This is the reason that I support > > >>>> both, not because I see that the LoST server being able to make > > >>>> intelligent decisions about multiple conflicting pieces of > > >>>> information. > > >>>> > > >>>> Here's how I see this working. The seeker has a > PIDF-LO. They apply > > >>>> the selection methods described in the above document > to select a > > >>>> single tuple that contains location information. > > >>>> (XPath="/presence/tuple[status/geopriv][1]") > > >>>> > > >>>> Whatever location information that tuple contains, be > it geodetic or > > >>>> civic, the seeker lifts the contents of the > location-info element and > > >>>> puts it in an appropriate LoST query. > > >>>> > > >>>> Here are the applicable rules: > > >>>> > > >>>> Rule #1: A geopriv element MUST describe a discrete > location. Rule > > >>>> #4: Providing more than one location in a single > > > >>>> element SHOULD be avoided where possible. Rule #5: > When providing > > >>>> more than one location in a single element the > > >>>> locations MUST be provided by a common source. Rule > #6: Providing > > >>>> more than one location in a single > element SHOULD > > >>>> only be done if they form a complex to describe the > same location. > > >>>> For example, a geodetic location describing a point, > and a civic > > >>>> location indicating the floor in a building. Rule #8: > Where a PIDF > > >>>> document contains more than one tuple containing a > status element > > >>>> with a geopriv location element , the priority of > tuples SHOULD be > > >>>> based on tuple position within the PIDF document. That > is to say, > > >>>> the tuple with the highest priority location occurs > earliest in the > > >>>> PIDF document. Initial priority SHOULD be determined by the > > >>>> originating UA, the final priority MAY be determined > by a proxy along > > >>>> the way, or the UAS. > > >>>> > > >>>> > > >>>> > > >>>>> -----Original Message----- From: Hannes Tschofenig > > >>>>> [mailto:hannes.tschofenig@siemens.com] Sent: > Wednesday, 7 June 2006 > > >>>>> 9:30 PM To: ecrit@ietf.org Subject: [Ecrit] [issue2] > Is it allowed > > >>>>> to specify civic and geospatial infointo the query? > > >>>>> > > >>>>> > > >>>>> Hannes Tschofenig added > the comment: > > >>>>> > > >>>>> TENTATIVE SUMMARY: > > >>>>> > > >>>>> Here is the update: > > >>>>> > > >>>>> * Either civic OR geospatial in a LoST query > > >>>>> > > >>>>> Marc, Henning, Shida, Richard, Brian, John > Schnizlein, Byron Smith, > > >>>>> > > >>>>> > > >>>>> > > >>>>> * Both civic AND geospatial possible in a LoST query > > >>>>> > > >>>>> Roger, Martin, Andy, James W. > > >>>>> > > >>>>> These folks don't seem to take a clear position: > > >>>>> > > >>>>> John Hearty, Jean-Francois, Clive D.W. Feather > > >>>>> > > >>>>> __________________________________________________ LoST Issue > > >>>>> Tracker > > >>>>> > > >>>>> __________________________________________________ > > >>>>> > > >>>>> _______________________________________________ Ecrit > mailing list > > >>>>> Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit > > >>>>> > > >>>> > --------------------------------------------------------------------- > > -- > > >>>> > > >> ------------------------- > > >> > > >>>> This message is for the designated recipient only and > may contain > > >>>> privileged, proprietary, or otherwise private > information. If you > > >>>> have received it in error, please notify the sender > immediately and > > >>>> delete the original. Any unauthorized use of this email is > > >>>> prohibited. > > >>>> > --------------------------------------------------------------------- > > -- > > >>>> > > >> ------------------------- > > >> > > >>>> [mf2] > > >>>> > > >>>> > > >>>> > --------------------------------------------------------------------- > > -- > > >>>> > > >> - > > >> > > >>>> _______________________________________________ Ecrit > mailing list > > >>>> Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit > > >>>> > > >>> _______________________________________________ > > >>> Ecrit mailing list > > >>> Ecrit@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/ecrit > > >>> > > >>> > > >>> > > > > > > > -------------------------------------------------------------- > ---------- > > ------------------------ > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > -------------------------------------------------------------- > ---------- > > ------------------------ > > > [mf2] > > > > > > > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------- > ---------------------------------- > 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 Jun 08 12:44:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoNcE-0001Ag-VK; Thu, 08 Jun 2006 12:44:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoNcE-0001Ab-5O for ecrit@ietf.org; Thu, 08 Jun 2006 12:44:14 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoNcC-0004Sr-Ti for ecrit@ietf.org; Thu, 08 Jun 2006 12:44:14 -0400 Received: from lion.cs.columbia.edu (IDENT:8OqeLPCHbLTqiPGjtiPT1Mble0+Ixmqy@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k58GeRX6029440 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 8 Jun 2006 12:44:12 -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 k58GeOBB014649 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 8 Jun 2006 12:40:25 -0400 Message-ID: <448852F3.8000602@cs.columbia.edu> Date: Thu, 08 Jun 2006 12:40:19 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfointo the query? References: <5A8A4AC9-8F41-4878-8FCC-C4D4002C6175@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ecrit@ietf.org, "Thomson, Martin" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Now that we seem to be approaching a common understanding of the problem space, based on Hannes' observation, we should probably step back and ask if LoST needs to solve this. (I think hybrid addresses are quite useful for dispatch.) Thus, maybe the question can be re-stated: Do we need to support the case that the location is specified primarily in geo coordinates, but PSAP resolution depends on the floor or suite number (specified in the civic part)? I suspect none of the existing MSAG/ALI databases support this, but if this is a feature that 911 operators have asked for for years, it might be worth the extra specification complexity and additional error cases ("You have specified a street name together with a geo address. Only a floor number is allowed.") Are there any other practically-relevant cases of hybrid addresses? Andrew Newton wrote: > > On Jun 8, 2006, at 9:39 AM, Henning Schulzrinne wrote: > >> I have no objection to having a "hybrid" address if it is indeed >> logically a single address which can never, ever lead to two different >> PSAPs. >> > > That works for me. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 08 14:30:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoPHJ-0000Mh-BI; Thu, 08 Jun 2006 14:30:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoPHI-0000Mc-Sq for ecrit@ietf.org; Thu, 08 Jun 2006 14:30:44 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoPHH-00087J-JJ for ecrit@ietf.org; Thu, 08 Jun 2006 14:30:44 -0400 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.6.118]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k58IUC121385; Thu, 8 Jun 2006 12:30:12 -0600 Message-ID: <44886ECF.4090805@ntt-at.com> Date: Thu, 08 Jun 2006 11:39:11 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfointo the query? References: <5A8A4AC9-8F41-4878-8FCC-C4D4002C6175@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ecrit@ietf.org, "Thomson, Martin" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org As I noted on my e-mail I sent yesterday, as long as two information really supplement each other and lead to only one PSAP URI, I am okay with this too. Regards Shida Andrew Newton wrote: > > On Jun 8, 2006, at 9:39 AM, Henning Schulzrinne wrote: > >> I have no objection to having a "hybrid" address if it is indeed >> logically a single address which can never, ever lead to two >> different PSAPs. >> > > That works for me. > > -andy > ------------------------------------------------------------------------ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 08 14:33:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoPJp-0002SS-4R; Thu, 08 Jun 2006 14:33:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoPJn-0002SN-Pg for ecrit@ietf.org; Thu, 08 Jun 2006 14:33:19 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoPJm-0008B6-5I for ecrit@ietf.org; Thu, 08 Jun 2006 14:33:19 -0400 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.6.118]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k58IXH822422; Thu, 8 Jun 2006 12:33:17 -0600 Message-ID: <44886F82.1070806@ntt-at.com> Date: Thu, 08 Jun 2006 11:42:10 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Thomson, Martin" Subject: Re: [Ecrit] [issue2] Is it allowed to specify civicand geospatialinfointo the query? References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Martin; I looked at the requirement again and saw that it's mandatory to understand both Civic and Geo for the mapping protocol so the concern I had would not arise. Regards Shida Thomson, Martin wrote: > I think that you meant to ask me, so I'll answer. I'm not sure if that's a good thing or not to be mistaken for Tom ;) > > I'm not sure if I understand your scenario. Do you have a server that doesn't support geo, but has extra information that it can use? > > The only scenarios that I can see arising from this are those where one piece is not understood (either the geo, or civic part). Two things can happen > > - the other pieces are sufficient to get a result (I don't understand civic, but I don't care about altitude), or > > - the other pieces are pretty ambiguous (I don't understand geo, and the second floor anywhere on the planet isn't specific enough for me). > > >> -----Original Message----- >> From: Shida Schubert [mailto:shida@ntt-at.com] >> Sent: Thursday, 8 June 2006 4:20 PM >> To: Thomson, Martin >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civicand >> geospatialinfointo the query? >> >> >> Hi Tom; >> >> I agree with you to some extent but I am still not comfortable. >> >> As long as the two information really supplement each other, and one of >> the information is sufficient to find the proper PSAP URI and both >> information only resolves to one PSAP URI if both were queried, I might >> be able to live with that. >> >> Just out of curiosity. Assuming LoST supports query with location >> information with two location type as long as it is a compound location >> information where two information supplement each other, what would >> happen if LoST server that was queried did not support geo and it >> happend to have the supplementary information in geo(latitude)? >> >> If it does not understand civic location format, it is unable to identify >> the information to be used to find the proper PSAP and might proceed to >> query the database using the location info provided in geo format(only >> latitude info. >> >> I guess it could return an error stating that it's an invalid location >> as well as default uri for the service requested(e.g. Default PSAP URI >> for the >> region LoST server is responsible)... >> >> Regards >> Shida >> >> Thomson, Martin wrote: >> >>> It is better to think of anything that appears within a single >>> >> element as a single location. You aren't sending more >> than one location to the LoST server. If you think about it as a single >> "location" with multiple parts (elements), the fears about multiple >> responses disappear. >> >>> The only valid concern that remains is LoST server complexity. But when >>> >> you scratch beneath the surface a little, this begins to be less of a >> source of intestinal torment. If we consider the occasions where this >> composite location is possible, it quickly resolves down to the floors >> altitude case, and not a whole lot more. In other words, I can't think of >> a good alternative example. That means that the LoST server can safely >> ignore the "2" that goes along >> with the geodetic information, except where you have the weird case where >> the bottom-floor cinema is served by a different PSAP to the upper-floors >> (not my example). >> >>> >>> >>>> -----Original Message----- >>>> From: Shida Schubert [mailto:shida@ntt-at.com] >>>> Sent: Thursday, 8 June 2006 11:57 AM >>>> To: Tom-PT Taylor >>>> Cc: Thomson, Martin; ecrit@ietf.org >>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and >>>> geospatialinfointo the query? >>>> >>>> >>>> Hi Tom; >>>> >>>> According to what I understand the issue still remains because >>>> Rule#5 and Rule#6 allows a compound location information composed of >>>> both geo and civic in single element. >>>> >>>> Two of which location type is a supplementary location info(floor or >>>> altitude) >>>> that can be dropped from the LoST query is probably not easy to find >>>> >> out. >> >>>> I guess we can't expect all the intermediary that supports LoST client >>>> functionality, >>>> the ability to compute the two location inside one >>>> element to >>>> seek out the proper location information to submit with the LoST query. >>>> >>>> I think I understand the problem, but I still feel very uncomfortable >>>> >> to >> >>>> send >>>> more than one location to LoST server in a single query. I'd rather >>>> loose the >>>> ability to express the flexibility the pidf-lo-profile has about >>>> including more >>>> than one location. >>>> >>>> If more than one location needs to be included in single location-info >>>> element, >>>> may be we can define a new element or an attribute to an "tuple" >>>> >> element >> >>>> to express that a location information A adds additional info to >>>> >> location >> >>>> information B? >>>> >>>> Thanks & Regards >>>> Shida >>>> >>>> Tom-PT Taylor wrote: >>>> >>>> >>>>> OK, I've looked over the draft, and the rules make sense. I would >>>>> still, as the "call server" programmer, choose the first location-info >>>>> element and send only it. There's no way we should expect the mapping >>>>> server to wade through potentially many objects when (within our >>>>> charter) it makes sense to reply to only one of them. >>>>> >>>>> Thomson, Martin [Business:EXTRNL:ANDREW] wrote: >>>>> >>>>> >>>>>> I'd like to clarify my position, because I think that this discussion >>>>>> has headed off course a little. >>>>>> >>>>>> Firstly, I'd recommend that people read the PDIF-LO [sic] profile >>>>>> draft. That draft talks about cardinality and I think that it is >>>>>> extremely important to this discussion. >>>>>> >>>>>> http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile-04.txt >>>>>> >>>>>> This document notes that it is possible to have civic and geodetic >>>>>> that together form a complex to describe a single location. The >>>>>> example used is a set of 2-dimensional coordinates with an altitude >>>>>> expressed in building floors. This is the reason that I support >>>>>> both, not because I see that the LoST server being able to make >>>>>> intelligent decisions about multiple conflicting pieces of >>>>>> information. >>>>>> >>>>>> Here's how I see this working. The seeker has a PIDF-LO. They apply >>>>>> the selection methods described in the above document to select a >>>>>> single tuple that contains location information. >>>>>> (XPath="/presence/tuple[status/geopriv][1]") >>>>>> >>>>>> Whatever location information that tuple contains, be it geodetic or >>>>>> civic, the seeker lifts the contents of the location-info element and >>>>>> puts it in an appropriate LoST query. >>>>>> >>>>>> Here are the applicable rules: >>>>>> >>>>>> Rule #1: A geopriv element MUST describe a discrete location. Rule >>>>>> #4: Providing more than one location in a single >>>>>> element SHOULD be avoided where possible. Rule #5: When providing >>>>>> more than one location in a single element the >>>>>> locations MUST be provided by a common source. Rule #6: Providing >>>>>> more than one location in a single element SHOULD >>>>>> only be done if they form a complex to describe the same location. >>>>>> For example, a geodetic location describing a point, and a civic >>>>>> location indicating the floor in a building. Rule #8: Where a PIDF >>>>>> document contains more than one tuple containing a status element >>>>>> with a geopriv location element , the priority of tuples SHOULD be >>>>>> based on tuple position within the PIDF document. That is to say, >>>>>> the tuple with the highest priority location occurs earliest in the >>>>>> PIDF document. Initial priority SHOULD be determined by the >>>>>> originating UA, the final priority MAY be determined by a proxy along >>>>>> the way, or the UAS. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- From: Hannes Tschofenig >>>>>>> [mailto:hannes.tschofenig@siemens.com] Sent: Wednesday, 7 June 2006 >>>>>>> 9:30 PM To: ecrit@ietf.org Subject: [Ecrit] [issue2] Is it allowed >>>>>>> to specify civic and geospatial infointo the query? >>>>>>> >>>>>>> >>>>>>> Hannes Tschofenig added the comment: >>>>>>> >>>>>>> TENTATIVE SUMMARY: >>>>>>> >>>>>>> Here is the update: >>>>>>> >>>>>>> * Either civic OR geospatial in a LoST query >>>>>>> >>>>>>> Marc, Henning, Shida, Richard, Brian, John Schnizlein, Byron Smith, >>>>>>> >>>>>>> >>>>>>> >>>>>>> * Both civic AND geospatial possible in a LoST query >>>>>>> >>>>>>> Roger, Martin, Andy, James W. >>>>>>> >>>>>>> These folks don't seem to take a clear position: >>>>>>> >>>>>>> John Hearty, Jean-Francois, Clive D.W. Feather >>>>>>> >>>>>>> __________________________________________________ LoST Issue >>>>>>> Tracker >>>>>>> >>>>>>> __________________________________________________ >>>>>>> >>>>>>> _______________________________________________ Ecrit mailing list >>>>>>> Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> >> -- >> >>>> ------------------------- >>>> >>>> >>>>>> This message is for the designated recipient only and may contain >>>>>> privileged, proprietary, or otherwise private information. If you >>>>>> have received it in error, please notify the sender immediately and >>>>>> delete the original. Any unauthorized use of this email is >>>>>> prohibited. >>>>>> --------------------------------------------------------------------- >>>>>> >> -- >> >>>> ------------------------- >>>> >>>> >>>>>> [mf2] >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> >> -- >> >>>> - >>>> >>>> >>>>>> _______________________________________________ Ecrit mailing list >>>>>> Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> >>>>> >>>>> >>> ------------------------------------------------------------------------ >>> >> ------------------------ >> >>> This message is for the designated recipient only and may >>> contain privileged, proprietary, or otherwise private information. >>> If you have received it in error, please notify the sender >>> immediately and delete the original. Any unauthorized use of >>> this email is prohibited. >>> ------------------------------------------------------------------------ >>> >> ------------------------ >> >>> [mf2] >>> >>> >>> >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> > > ------------------------------------------------------------------------------------------------ > 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 Jun 08 16:51:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoRTp-00069u-Dk; Thu, 08 Jun 2006 16:51:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoRTn-00069f-Rz for ecrit@ietf.org; Thu, 08 Jun 2006 16:51:47 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoRTn-0003BJ-Cz for ecrit@ietf.org; Thu, 08 Jun 2006 16:51:47 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 8 Jun 2006 13:51:45 -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] [issue9] LoST Response with PSAP Preference Date: Thu, 8 Jun 2006 13:51:44 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575051D9A15@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [issue9] LoST Response with PSAP Preference Thread-Index: AcaKj5WDKQDqM0RnQ8+thgY/2zOMCAAP0QYgABWwMaA= From: "Roger Marshall" To: "Brian Rosen" , "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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 would agree that emergency context routing would be easier IF there were always only one call center for a given location, but I anticipate that in some areas this will never be the case. Nor do I believe that an assortment of dial strings will make the problem simpler for the user. Example_1, today the airport announcements that bellow, "If you have an emergency, call '9-1-1'", which summons airport personnel, not county - whereas if you dial '9-1-1' on your cell phone while in the same airport, you get the county PSAP. I don't think the airport will change their policy, and I would hope that a mobile location based query to LoST returns the Airport's URI for all cellular calls made on the premises, but it may never happen (I'm guessing that the county would probably NOT want to give up ownership over this airport (cellular), or any number of corporate or university campus sites as well. Example_2, The previously used Gaza strip example, if a person made an emergency call for help while visiting Gaza, there may be a user-preferred question as to which Emergency Svc is summoned, PLO or the Israeli, depending on the person's citizenship. Maybe this problem of jurisdictional boundary overlays won't be solved by some fancy feature in the LoST protocol in the short term, but I predict that it won't just go away. -Roger. >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net]=20 >Sent: Thursday, June 08, 2006 12:47 AM >To: 'Henning Schulzrinne'; Roger Marshall >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] [issue9] LoST Response with PSAP Preference > >Sorry to chime in late here; I'm in Europe with intermittent=20 >Internet access. > >This whole line of thinking is incorrect in my opinion. > >There can only be ONE call center that takes the call.=20 >=20 >It cannot be the caller's opinion which one that is. There=20 >has to be a uniform rule. The campus notifies the PSAP or the=20 >PSAP notifies the campus. >They have to agree on the rule. > >There may be a need for a mechanism whereby one entity=20 >notifies the other entity, but that is outside the scope of=20 >ecrit right now. > >There is only one entity that populates the data for a given=20 >location in the database. That entity gets to choose what=20 >goes in there. > >Brian > >-----Original Message----- >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >Sent: Wednesday, June 07, 2006 8:08 PM >To: Roger Marshall >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] [issue9] LoST Response with PSAP Preference > >Storing user profiles on LoST servers hasn't really been part=20 >of the discussion so far. > >I wonder if there's a simple label we can apply to URLs, such=20 >as "public" and "private" or "campus" (and maybe a=20 >human-readable string since the decision which to call seems=20 >rather hard to automate). By the way, the dial strings for=20 >each such service would also likely differ. > >That, however, seems to be a somewhat different issue from=20 >using multiple URLs for fail-over routing. It seems unwise to=20 >commingle the two issues. > >On Jun 7, 2006, at 7:01 PM, Roger Marshall wrote: > >> When walking onto a campus, a call for emergency services shouldn't=20 >> result in two different scenarios, depending on which device/media=20 >> you're using. Though this is what happens in today's world. Today,=20 >> PSAP routing is inconsistent by technology, (you get campus=20 >PSAP when=20 >> using wired vs. city PSAP when using wireless). I think the=20 >> inconsistency should be fixed and it seems to me that LoST=20 >could help=20 >> fix it. >> >> I'm not promoting call-time user interaction with the=20 >returned set of=20 >> URIs, but rather when multiples are returned, that the=20 >device selects=20 >> the first one, and if for some reason it doesn't work, then=20 >the device=20 >> selects the second URI to route the call. The order in=20 >which the URIs=20 >> are returned is a LoST Server setting (based on jurisdiction=20 >> agreement). >> >> On the other hand, it now also occurs to me that we might want to=20 >> consider a user specified profile driven return order under certain=20 >> circumstances (let's say there is no way you want campus police to=20 >> come to your aid). This one would probably be less=20 >controversial in a=20 >> commercial context for example, where you might want to exclude one=20 >> brand of gas station from being included in the returned list (e.g.,=20 >> since they had a worse track record with oil-spills). >> >> >> Roger Marshall >> > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 08 17:20:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoRvl-0007fD-Ny; Thu, 08 Jun 2006 17:20:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoRvk-0007dG-Fa for ecrit@ietf.org; Thu, 08 Jun 2006 17:20:40 -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 1FoRvj-0005MS-T0 for ecrit@ietf.org; Thu, 08 Jun 2006 17:20:40 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 08 Jun 2006 14:20:39 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k58LKd0L026985; Thu, 8 Jun 2006 14:20:39 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k58LKalE003066; Thu, 8 Jun 2006 14:20:38 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 14:20:38 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 14:20:37 -0700 From: "Marc Linsner" To: "'Roger Marshall'" Subject: RE: [Ecrit] [issue9] LoST Response with PSAP Preference Date: Thu, 8 Jun 2006 17:20:36 -0400 Message-ID: <00fe01c68b41$63321700$2c0d0d0a@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.2869 In-Reply-To: <8C837214C95C864C9F34F3635C2A6575051D9A15@SEA-EXCHVS-2.telecomsys.com> Thread-Index: AcaKj5WDKQDqM0RnQ8+thgY/2zOMCAAP0QYgABWwMaAABh+ncA== X-OriginalArrivalTime: 08 Jun 2006 21:20:37.0656 (UTC) FILETIME=[62FD9980:01C68B41] DKIM-Signature: a=rsa-sha1; q=dns; l=6216; t=1149801639; x=1150665639; c=relaxed/simple; s=sjdkim3001; 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]=20[issue9]=20LoST=20Response=20with=20PSAP=20Preference; X=v=3Dcisco.com=3B=20h=3DiBs1mGIMlT5aufQTqcx2HmGil2M=3D; b=fMrChydVtViE5XV57qwr8fbWg4Mh+5jcuXo48tL7In3l6sSNTgJ8CiFNPqiaQhdRVxy7/KGp Gj/RxPaB6vid7mC5s9oaxAoOksRYkPrnyD2QJNutRY+4dqBCcB52gqQj; 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: cd3fc8e909678b38737fc606dec187f0 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 Roger, We have NOT seen a requirement for different routing for the same location. Your example #1 is a legacy problem due to inferior mechanisms in cellular end-point location. As you well know, (almost) all cellular calls are routed based on cell tower location, not caller location. In example #1, the cell tower that is utilized at the airport most likely covers an area of the county outside the airport. Since the airport PSAP can't handle emergencies outside of the airport, the only logical choice is to route *all* calls from that particular cell tower to the county. There is nothing the IETF can do to enhance cellular endpoint location timing, the root of the real problem here. As you noted, wireline phones within the airport are routed properly to the airport PSAP. So the point is that LoST will handle your airport example, given that the LoST client knows where he is located in the time envelope of a 911 call setup. With regards to your second example, maybe we should add ethnicity tags to LoST?? (just kidding!) -Marc- > > I would agree that emergency context routing would be easier > IF there were always only one call center for a given > location, but I anticipate that in some areas this will never > be the case. Nor do I believe that an assortment of dial > strings will make the problem simpler for the user. > > Example_1, today the airport announcements that bellow, "If > you have an emergency, call '9-1-1'", which summons airport > personnel, not county - whereas if you dial '9-1-1' on your > cell phone while in the same airport, you get the county > PSAP. I don't think the airport will change their policy, > and I would hope that a mobile location based query to LoST > returns the Airport's URI for all cellular calls made on the > premises, but it may never happen (I'm guessing that the > county would probably NOT want to give up ownership over this > airport (cellular), or any number of corporate or university > campus sites as well. > > Example_2, The previously used Gaza strip example, if a > person made an emergency call for help while visiting Gaza, > there may be a user-preferred question as to which Emergency > Svc is summoned, PLO or the Israeli, depending on the > person's citizenship. > > Maybe this problem of jurisdictional boundary overlays won't > be solved by some fancy feature in the LoST protocol in the > short term, but I predict that it won't just go away. > > -Roger. > > > >-----Original Message----- > >From: Brian Rosen [mailto:br@brianrosen.net] > >Sent: Thursday, June 08, 2006 12:47 AM > >To: 'Henning Schulzrinne'; Roger Marshall > >Cc: ecrit@ietf.org > >Subject: RE: [Ecrit] [issue9] LoST Response with PSAP Preference > > > >Sorry to chime in late here; I'm in Europe with intermittent > Internet > >access. > > > >This whole line of thinking is incorrect in my opinion. > > > >There can only be ONE call center that takes the call. > > > >It cannot be the caller's opinion which one that is. There > has to be a > >uniform rule. The campus notifies the PSAP or the PSAP notifies the > >campus. > >They have to agree on the rule. > > > >There may be a need for a mechanism whereby one entity notifies the > >other entity, but that is outside the scope of ecrit right now. > > > >There is only one entity that populates the data for a given > location > >in the database. That entity gets to choose what goes in there. > > > >Brian > > > >-----Original Message----- > >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >Sent: Wednesday, June 07, 2006 8:08 PM > >To: Roger Marshall > >Cc: ecrit@ietf.org > >Subject: Re: [Ecrit] [issue9] LoST Response with PSAP Preference > > > >Storing user profiles on LoST servers hasn't really been part of the > >discussion so far. > > > >I wonder if there's a simple label we can apply to URLs, such as > >"public" and "private" or "campus" (and maybe a > human-readable string > >since the decision which to call seems rather hard to > automate). By the > >way, the dial strings for each such service would also likely differ. > > > >That, however, seems to be a somewhat different issue from using > >multiple URLs for fail-over routing. It seems unwise to > commingle the > >two issues. > > > >On Jun 7, 2006, at 7:01 PM, Roger Marshall wrote: > > > >> When walking onto a campus, a call for emergency services > shouldn't > >> result in two different scenarios, depending on which device/media > >> you're using. Though this is what happens in today's > world. Today, > >> PSAP routing is inconsistent by technology, (you get campus > >PSAP when > >> using wired vs. city PSAP when using wireless). I think the > >> inconsistency should be fixed and it seems to me that LoST > >could help > >> fix it. > >> > >> I'm not promoting call-time user interaction with the > >returned set of > >> URIs, but rather when multiples are returned, that the > >device selects > >> the first one, and if for some reason it doesn't work, then > >the device > >> selects the second URI to route the call. The order in > >which the URIs > >> are returned is a LoST Server setting (based on jurisdiction > >> agreement). > >> > >> On the other hand, it now also occurs to me that we might want to > >> consider a user specified profile driven return order > under certain > >> circumstances (let's say there is no way you want campus police to > >> come to your aid). This one would probably be less > >controversial in a > >> commercial context for example, where you might want to > exclude one > >> brand of gas station from being included in the returned > list (e.g., > >> since they had a worse track record with oil-spills). > >> > >> > >> Roger Marshall > >> > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 08 17:34:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoS9D-0008U1-El; Thu, 08 Jun 2006 17:34:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoS9C-0008M5-3m for ecrit@ietf.org; Thu, 08 Jun 2006 17:34:34 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoS9B-0006m9-HN for ecrit@ietf.org; Thu, 08 Jun 2006 17:34:34 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 8 Jun 2006 14:34:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] [issue9] LoST Response with PSAP Preference Date: Thu, 8 Jun 2006 14:34:30 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575051D9A8B@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [issue9] LoST Response with PSAP Preference Thread-Index: AcaKj5WDKQDqM0RnQ8+thgY/2zOMCAAP0QYgABWwMaAABh+ncAABOv1Q From: "Roger Marshall" To: "Marc Linsner" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 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 Marc: Don't laugh too much, the requirements draft has text that already comes close: (Step 3, following Figure 1.) "(3) The emergency caller might need to consult a mapping service to determine the PSAP (or other relevant information) that is appropriate for the physical location of the emergency caller, possibly considering other attributes such as appropriate language support by the emergency call taker." -roger. =20 >-----Original Message----- >From: Marc Linsner [mailto:mlinsner@cisco.com]=20 >Sent: Thursday, June 08, 2006 2:21 PM >To: Roger Marshall >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] [issue9] LoST Response with PSAP Preference > >Roger,=20 > >We have NOT seen a requirement for different routing for the=20 >same location. > >Your example #1 is a legacy problem due to inferior mechanisms=20 >in cellular end-point location. As you well know, (almost)=20 >all cellular calls are routed based on cell tower location,=20 >not caller location. In example #1, the cell tower that is=20 >utilized at the airport most likely covers an area of the=20 >county outside the airport. Since the airport PSAP can't=20 >handle emergencies outside of the airport, the only logical=20 >choice is to route >*all* calls from that particular cell tower to the county. =20 >There is nothing the IETF can do to enhance cellular endpoint=20 >location timing, the root of the real problem here. As you=20 >noted, wireline phones within the airport are routed properly=20 >to the airport PSAP. > >So the point is that LoST will handle your airport example,=20 >given that the LoST client knows where he is located in the=20 >time envelope of a 911 call setup. > >With regards to your second example, maybe we should add=20 >ethnicity tags to LoST?? (just kidding!) > >-Marc- > > > >>=20 >> I would agree that emergency context routing would be easier=20 >IF there=20 >> were always only one call center for a given location, but I=20 >> anticipate that in some areas this will never be the case. Nor do I=20 >> believe that an assortment of dial strings will make the problem=20 >> simpler for the user. >>=20 >> Example_1, today the airport announcements that bellow, "If you have=20 >> an emergency, call '9-1-1'", which summons airport personnel, not=20 >> county - whereas if you dial '9-1-1' on your cell phone while in the=20 >> same airport, you get the county PSAP. I don't think the=20 >airport will=20 >> change their policy, and I would hope that a mobile location based=20 >> query to LoST returns the Airport's URI for all cellular=20 >calls made on=20 >> the premises, but it may never happen (I'm guessing that the county=20 >> would probably NOT want to give up ownership over this airport=20 >> (cellular), or any number of corporate or university campus sites as=20 >> well. >>=20 >> Example_2, The previously used Gaza strip example, if a=20 >person made an=20 >> emergency call for help while visiting Gaza, there may be a=20 >> user-preferred question as to which Emergency Svc is=20 >summoned, PLO or=20 >> the Israeli, depending on the person's citizenship. >>=20 >> Maybe this problem of jurisdictional boundary overlays won't=20 >be solved=20 >> by some fancy feature in the LoST protocol in the short term, but I=20 >> predict that it won't just go away. >>=20 >> -Roger. >>=20 >>=20 >> >-----Original Message----- >> >From: Brian Rosen [mailto:br@brianrosen.net] >> >Sent: Thursday, June 08, 2006 12:47 AM >> >To: 'Henning Schulzrinne'; Roger Marshall >> >Cc: ecrit@ietf.org >> >Subject: RE: [Ecrit] [issue9] LoST Response with PSAP Preference >> > >> >Sorry to chime in late here; I'm in Europe with intermittent >> Internet >> >access. >> > >> >This whole line of thinking is incorrect in my opinion. >> > >> >There can only be ONE call center that takes the call.=20 >> >=20 >> >It cannot be the caller's opinion which one that is. There >> has to be a >> >uniform rule. The campus notifies the PSAP or the PSAP=20 >notifies the=20 >> >campus. >> >They have to agree on the rule. >> > >> >There may be a need for a mechanism whereby one entity notifies the=20 >> >other entity, but that is outside the scope of ecrit right now. >> > >> >There is only one entity that populates the data for a given >> location >> >in the database. That entity gets to choose what goes in there. >> > >> >Brian >> > >> >-----Original Message----- >> >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> >Sent: Wednesday, June 07, 2006 8:08 PM >> >To: Roger Marshall >> >Cc: ecrit@ietf.org >> >Subject: Re: [Ecrit] [issue9] LoST Response with PSAP Preference >> > >> >Storing user profiles on LoST servers hasn't really been=20 >part of the=20 >> >discussion so far. >> > >> >I wonder if there's a simple label we can apply to URLs, such as=20 >> >"public" and "private" or "campus" (and maybe a >> human-readable string >> >since the decision which to call seems rather hard to >> automate). By the >> >way, the dial strings for each such service would also=20 >likely differ. >> > >> >That, however, seems to be a somewhat different issue from using=20 >> >multiple URLs for fail-over routing. It seems unwise to >> commingle the >> >two issues. >> > >> >On Jun 7, 2006, at 7:01 PM, Roger Marshall wrote: >> > >> >> When walking onto a campus, a call for emergency services >> shouldn't >> >> result in two different scenarios, depending on which=20 >device/media=20 >> >> you're using. Though this is what happens in today's >> world. Today, >> >> PSAP routing is inconsistent by technology, (you get campus >> >PSAP when >> >> using wired vs. city PSAP when using wireless). I think the=20 >> >> inconsistency should be fixed and it seems to me that LoST >> >could help >> >> fix it. >> >> >> >> I'm not promoting call-time user interaction with the >> >returned set of >> >> URIs, but rather when multiples are returned, that the >> >device selects >> >> the first one, and if for some reason it doesn't work, then >> >the device >> >> selects the second URI to route the call. The order in >> >which the URIs >> >> are returned is a LoST Server setting (based on jurisdiction=20 >> >> agreement). >> >> >> >> On the other hand, it now also occurs to me that we might want to=20 >> >> consider a user specified profile driven return order >> under certain >> >> circumstances (let's say there is no way you want campus=20 >police to=20 >> >> come to your aid). This one would probably be less >> >controversial in a >> >> commercial context for example, where you might want to >> exclude one >> >> brand of gas station from being included in the returned >> list (e.g., >> >> since they had a worse track record with oil-spills). >> >> >> >> >> >> Roger Marshall >> >> >> > >> >_______________________________________________ >> >Ecrit mailing list >> >Ecrit@ietf.org >> >https://www1.ietf.org/mailman/listinfo/ecrit >> > >> > >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 08 20:42:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV5C-0006Hf-EX; Thu, 08 Jun 2006 20:42:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV5B-0006C9-7A for ecrit@ietf.org; Thu, 08 Jun 2006 20:42:37 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoV5A-0004El-OZ for ecrit@ietf.org; Thu, 08 Jun 2006 20:42:37 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FoV50-0003eB-1C; Thu, 08 Jun 2006 19:42:26 -0500 From: "Brian Rosen" To: "'Roger Marshall'" , "'Marc Linsner'" Subject: RE: [Ecrit] [issue9] LoST Response with PSAP Preference Date: Thu, 8 Jun 2006 20:42:31 -0400 Message-ID: <01b401c68b5d$995b3a70$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: <8C837214C95C864C9F34F3635C2A6575051D9A8B@SEA-EXCHVS-2.telecomsys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaKj5WDKQDqM0RnQ8+thgY/2zOMCAAP0QYgABWwMaAABh+ncAABOv1QAAaV+iA= 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: ff0adf256e4dd459cc25215cfa732ac1 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I have been a little concerned about disputed territory for a couple of years now. I don't think it's a big problem, but it's a problem. My preferred solution is to supply the country name in the location. That will disambiguate any disputed territory issues. Brian -----Original Message----- From: Roger Marshall [mailto:RMarshall@telecomsys.com] Sent: Thursday, June 08, 2006 5:35 PM To: Marc Linsner Cc: ecrit@ietf.org Subject: RE: [Ecrit] [issue9] LoST Response with PSAP Preference Marc: Don't laugh too much, the requirements draft has text that already comes close: (Step 3, following Figure 1.) "(3) The emergency caller might need to consult a mapping service to determine the PSAP (or other relevant information) that is appropriate for the physical location of the emergency caller, possibly considering other attributes such as appropriate language support by the emergency call taker." -roger. >-----Original Message----- >From: Marc Linsner [mailto:mlinsner@cisco.com] >Sent: Thursday, June 08, 2006 2:21 PM >To: Roger Marshall >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] [issue9] LoST Response with PSAP Preference > >Roger, > >We have NOT seen a requirement for different routing for the >same location. > >Your example #1 is a legacy problem due to inferior mechanisms >in cellular end-point location. As you well know, (almost) >all cellular calls are routed based on cell tower location, >not caller location. In example #1, the cell tower that is >utilized at the airport most likely covers an area of the >county outside the airport. Since the airport PSAP can't >handle emergencies outside of the airport, the only logical >choice is to route >*all* calls from that particular cell tower to the county. >There is nothing the IETF can do to enhance cellular endpoint >location timing, the root of the real problem here. As you >noted, wireline phones within the airport are routed properly >to the airport PSAP. > >So the point is that LoST will handle your airport example, >given that the LoST client knows where he is located in the >time envelope of a 911 call setup. > >With regards to your second example, maybe we should add >ethnicity tags to LoST?? (just kidding!) > >-Marc- > > > >> >> I would agree that emergency context routing would be easier >IF there >> were always only one call center for a given location, but I >> anticipate that in some areas this will never be the case. Nor do I >> believe that an assortment of dial strings will make the problem >> simpler for the user. >> >> Example_1, today the airport announcements that bellow, "If you have >> an emergency, call '9-1-1'", which summons airport personnel, not >> county - whereas if you dial '9-1-1' on your cell phone while in the >> same airport, you get the county PSAP. I don't think the >airport will >> change their policy, and I would hope that a mobile location based >> query to LoST returns the Airport's URI for all cellular >calls made on >> the premises, but it may never happen (I'm guessing that the county >> would probably NOT want to give up ownership over this airport >> (cellular), or any number of corporate or university campus sites as >> well. >> >> Example_2, The previously used Gaza strip example, if a >person made an >> emergency call for help while visiting Gaza, there may be a >> user-preferred question as to which Emergency Svc is >summoned, PLO or >> the Israeli, depending on the person's citizenship. >> >> Maybe this problem of jurisdictional boundary overlays won't >be solved >> by some fancy feature in the LoST protocol in the short term, but I >> predict that it won't just go away. >> >> -Roger. >> >> >> >-----Original Message----- >> >From: Brian Rosen [mailto:br@brianrosen.net] >> >Sent: Thursday, June 08, 2006 12:47 AM >> >To: 'Henning Schulzrinne'; Roger Marshall >> >Cc: ecrit@ietf.org >> >Subject: RE: [Ecrit] [issue9] LoST Response with PSAP Preference >> > >> >Sorry to chime in late here; I'm in Europe with intermittent >> Internet >> >access. >> > >> >This whole line of thinking is incorrect in my opinion. >> > >> >There can only be ONE call center that takes the call. >> > >> >It cannot be the caller's opinion which one that is. There >> has to be a >> >uniform rule. The campus notifies the PSAP or the PSAP >notifies the >> >campus. >> >They have to agree on the rule. >> > >> >There may be a need for a mechanism whereby one entity notifies the >> >other entity, but that is outside the scope of ecrit right now. >> > >> >There is only one entity that populates the data for a given >> location >> >in the database. That entity gets to choose what goes in there. >> > >> >Brian >> > >> >-----Original Message----- >> >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> >Sent: Wednesday, June 07, 2006 8:08 PM >> >To: Roger Marshall >> >Cc: ecrit@ietf.org >> >Subject: Re: [Ecrit] [issue9] LoST Response with PSAP Preference >> > >> >Storing user profiles on LoST servers hasn't really been >part of the >> >discussion so far. >> > >> >I wonder if there's a simple label we can apply to URLs, such as >> >"public" and "private" or "campus" (and maybe a >> human-readable string >> >since the decision which to call seems rather hard to >> automate). By the >> >way, the dial strings for each such service would also >likely differ. >> > >> >That, however, seems to be a somewhat different issue from using >> >multiple URLs for fail-over routing. It seems unwise to >> commingle the >> >two issues. >> > >> >On Jun 7, 2006, at 7:01 PM, Roger Marshall wrote: >> > >> >> When walking onto a campus, a call for emergency services >> shouldn't >> >> result in two different scenarios, depending on which >device/media >> >> you're using. Though this is what happens in today's >> world. Today, >> >> PSAP routing is inconsistent by technology, (you get campus >> >PSAP when >> >> using wired vs. city PSAP when using wireless). I think the >> >> inconsistency should be fixed and it seems to me that LoST >> >could help >> >> fix it. >> >> >> >> I'm not promoting call-time user interaction with the >> >returned set of >> >> URIs, but rather when multiples are returned, that the >> >device selects >> >> the first one, and if for some reason it doesn't work, then >> >the device >> >> selects the second URI to route the call. The order in >> >which the URIs >> >> are returned is a LoST Server setting (based on jurisdiction >> >> agreement). >> >> >> >> On the other hand, it now also occurs to me that we might want to >> >> consider a user specified profile driven return order >> under certain >> >> circumstances (let's say there is no way you want campus >police to >> >> come to your aid). This one would probably be less >> >controversial in a >> >> commercial context for example, where you might want to >> exclude one >> >> brand of gas station from being included in the returned >> list (e.g., >> >> since they had a worse track record with oil-spills). >> >> >> >> >> >> Roger Marshall >> >> >> > >> >_______________________________________________ >> >Ecrit mailing list >> >Ecrit@ietf.org >> >https://www1.ietf.org/mailman/listinfo/ecrit >> > >> > >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 08 20:47:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV9g-0007Et-Pf; Thu, 08 Jun 2006 20:47:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV9f-0007Ee-Es for ecrit@ietf.org; Thu, 08 Jun 2006 20:47:15 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoV9e-00055V-8C for ecrit@ietf.org; Thu, 08 Jun 2006 20:47:15 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 19:47:41 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 08 Jun 2006 19:47:41 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 19:47:40 -0500 Message-ID: From: "Thomson, Martin" To: "Brian Rosen" , "Roger Marshall" , "Marc Linsner" Date: Thu, 8 Jun 2006 19:46:02 -0500 Subject: RE: [Ecrit] [issue9] LoST Response with PSAP Preference -> [issue2]? MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 09 Jun 2006 00:47:40.0626 (UTC) FILETIME=[4FA86320:01C68B5E] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <01b401c68b5d$995b3a70$640fa8c0@cis.neustar.com> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] [issue9] LoST Response with PSAP Preference -> [issue2]? Thread-Index: AcaKj5WDKQDqM0RnQ8+thgY/2zOMCAAP0QYgABWwMaAABh+ncAABOv1QAAaV+iAAAB4voA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0670299345==" Errors-To: ecrit-bounces@ietf.org --===============0670299345== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message QnJpYW4sDQoNCkhhdmUgeW91IGp1c3QgcHJvdmlkZWQgdXMgd2l0aCBhbm90aGVyIHBvc3NpYmxl IHVzZSBmb3IgY29tcG9zaXRlIChjaXZpYytnZW8pIGxvY2F0aW9uIGluZm9ybWF0aW9uPyAgYy5m LiBIZW5uaW5nJ3MgZW1haWwgb24gaXNzdWUgMi4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogQnJpYW4gUm9zZW4gW21haWx0bzpickBicmlhbnJvc2VuLm5ldF0NCj4g U2VudDogRnJpZGF5LCA5IEp1bmUgMjAwNiAxMDo0MyBBTQ0KPiBUbzogJ1JvZ2VyIE1hcnNoYWxs JzsgJ01hcmMgTGluc25lcicNCj4gQ2M6IGVjcml0QGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBb RWNyaXRdIFtpc3N1ZTldIExvU1QgUmVzcG9uc2Ugd2l0aCBQU0FQIFByZWZlcmVuY2UNCj4gDQo+ IEkgaGF2ZSBiZWVuIGEgbGl0dGxlIGNvbmNlcm5lZCBhYm91dCBkaXNwdXRlZCB0ZXJyaXRvcnkg Zm9yIGEgY291cGxlIG9mDQo+IHllYXJzIG5vdy4gIEkgZG9uJ3QgdGhpbmsgaXQncyBhIGJpZyBw cm9ibGVtLCBidXQgaXQncyBhIHByb2JsZW0uICBNeQ0KPiBwcmVmZXJyZWQgc29sdXRpb24gaXMg dG8gc3VwcGx5IHRoZSBjb3VudHJ5IG5hbWUgaW4gdGhlIGxvY2F0aW9uLiAgVGhhdA0KPiB3aWxs DQo+IGRpc2FtYmlndWF0ZSBhbnkgZGlzcHV0ZWQgdGVycml0b3J5IGlzc3Vlcy4NCj4gDQo+IEJy aWFuDQo+IA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1l c3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRh aW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0 aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1 dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJd --===============0670299345== 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 --===============0670299345==-- From ecrit-bounces@ietf.org Thu Jun 08 21:34:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoVtK-0002OS-Ea; Thu, 08 Jun 2006 21:34:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoVtI-0002MC-Sd for ecrit@ietf.org; Thu, 08 Jun 2006 21:34:24 -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 1FoVXi-0001Fd-RH for ecrit@ietf.org; Thu, 08 Jun 2006 21:12:06 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoVIg-0004Yb-L9 for ecrit@ietf.org; Thu, 08 Jun 2006 20:56:35 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 08 Jun 2006 17:56:34 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,221,1146466800"; d="scan'208"; a="29093715:sNHT20380352" Received: from [68.49.184.222] (rtp-vpn4-65.cisco.com [10.82.208.65]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k590uXYL027080; Thu, 8 Jun 2006 20:56:33 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9e21c0b3e1a83f670202df21e47f8935@cisco.com> Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Ecrit] [issue9] LoST Response with PSAP Preference -> [issue2]? Date: Thu, 8 Jun 2006 20:56:28 -0400 To: "Thomson, Martin" X-Mailer: Apple Mail (2.624) X-Spam-Score: -2.3 (--) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 How does a host with cellular network access (and its best location estimate) know which side of the wall/fence it is on along the winding boarder between Israel and Palestine? Seriously, (although I can appreciate the use of humor) the fantasy that any protocol or effort of the IETF can resolve issues inherent in disputed territory should not influence our technical effort. John On Jun 8, 2006, at 8:46 PM, Thomson, Martin wrote: > > Have you just provided us with another possible use for composite > (civic+geo) location information? c.f. Henning's email on issue 2. > >> From: Brian Rosen [mailto:br@brianrosen.net] >> >> I have been a little concerned about disputed territory for a couple >> of >> years now. I don't think it's a big problem, but it's a problem. My >> preferred solution is to supply the country name in the location. >> That >> will disambiguate any disputed territory issues. >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 08 21:56:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoWEV-0005oe-HU; Thu, 08 Jun 2006 21:56:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoWEU-0005oZ-3B for ecrit@ietf.org; Thu, 08 Jun 2006 21:56:18 -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 1FoVHc-0006MG-MV for ecrit@ietf.org; Thu, 08 Jun 2006 20:55:28 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoV8Z-0004Q2-QU for ecrit@ietf.org; Thu, 08 Jun 2006 20:46:10 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FoV8M-0003ml-UQ; Thu, 08 Jun 2006 19:45:55 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , "'Thomson, Martin'" , , "'Tom-PT Taylor'" Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivicand geospatialinfointo the query? Date: Thu, 8 Jun 2006 20:46:00 -0400 Message-ID: <01b501c68b5e$15a4b3e0$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: <003c01c68afa$9c57ba90$2c0d0d0a@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaKnqd2asroiLOtSPiHFj9Qgp1KvgAC4SBAABK24QAAGjlTsA== 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: -2.5 (--) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 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 just supplied one: country with a geo. Used in disputed territory. Works really well in nearly every case (doesn't work with GPS and no assist). -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Thursday, June 08, 2006 8:54 AM To: 'Thomson, Martin'; shida@ntt-at.com; 'Tom-PT Taylor' Cc: ecrit@ietf.org Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivicand geospatialinfointo the query? The issue of a having a complex location, geo for horizontal and civic for vertical, IMO, is an IETF/GeoPriv self-inflicted problem. Discussions pre-RFC3825 concluded the vertical component of 3-dimensional geo coordinates, in their native form (feet/meters), were not very helpful for the emergency services call routing and dispatching use cases. Hence, the measurement unit concept within the RFC3825 location information that allows expressing the vertical information in units other than normal feet/meters associated with geo representations. When GeoPriv created RFC4119, this concept of expressing the vertical component of a geo representation in units other than the geo-normal feet/meters did not carry forward from RFC3825 into RFC4119. IMO, admittedly biased, this was a mistake. So, here we are trying to deal with: 1) Accept emergency call routing on 2-dimensional info only because we believe LoST is too stupid to deal with complex location representations. 2) Create the LoST query that mandates a single location, but can include both geo and civic field(s). (I believe that we can give guidance to make this workable.) 3) Change RFC4119 to allow the vertical measurement unit concept within a geo representation. If anyone can think of other cases where we will have complex representations, we need to discuss them now. -Marc- > > It is better to think of anything that appears within a > single element as a single location. You > aren't sending more than one location to the LoST server. If > you think about it as a single "location" with multiple parts > (elements), the fears about multiple responses disappear. > > The only valid concern that remains is LoST server > complexity. But when you scratch beneath the surface a > little, this begins to be less of a source of intestinal > torment. If we consider the occasions where this composite > location is possible, it quickly resolves down to the floors > altitude case, and not a whole lot more. In other words, I > can't think of a good alternative example. That means that > the LoST server can safely ignore the > "2" that goes along > with the geodetic information, except where you have the > weird case where the bottom-floor cinema is served by a > different PSAP to the upper-floors (not my example). > > > > -----Original Message----- > > From: Shida Schubert [mailto:shida@ntt-at.com] > > Sent: Thursday, 8 June 2006 11:57 AM > > To: Tom-PT Taylor > > Cc: Thomson, Martin; ecrit@ietf.org > > Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and > > geospatialinfointo the query? > > > > > > Hi Tom; > > > > According to what I understand the issue still remains because > > Rule#5 and Rule#6 allows a compound location information > composed of > > both geo and civic in single element. > > > > Two of which location type is a supplementary location info(floor or > > altitude) > > that can be dropped from the LoST query is probably not > easy to find out. > > I guess we can't expect all the intermediary that supports > LoST client > > functionality, the ability to compute the two location inside one > > element to seek out the proper location > information to > > submit with the LoST query. > > > > I think I understand the problem, but I still feel very > uncomfortable > > to send more than one location to LoST server in a single > query. I'd > > rather loose the ability to express the flexibility the > > pidf-lo-profile has about including more than one location. > > > > If more than one location needs to be included in single > location-info > > element, may be we can define a new element or an attribute to an > > "tuple" element to express that a location information A adds > > additional info to location information B? > > > > Thanks & Regards > > Shida > > > > Tom-PT Taylor wrote: > > > OK, I've looked over the draft, and the rules make sense. I would > > > still, as the "call server" programmer, choose the first > > > location-info element and send only it. There's no way we should > > > expect the mapping server to wade through potentially > many objects > > > when (within our > > > charter) it makes sense to reply to only one of them. > > > > > > Thomson, Martin [Business:EXTRNL:ANDREW] wrote: > > >> I'd like to clarify my position, because I think that this > > >> discussion has headed off course a little. > > >> > > >> Firstly, I'd recommend that people read the PDIF-LO > [sic] profile > > >> draft. That draft talks about cardinality and I think that it is > > >> extremely important to this discussion. > > >> > > >> > http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile-04.tx > > >> t > > >> > > >> This document notes that it is possible to have civic > and geodetic > > >> that together form a complex to describe a single location. The > > >> example used is a set of 2-dimensional coordinates with > an altitude > > >> expressed in building floors. This is the reason that I support > > >> both, not because I see that the LoST server being able to make > > >> intelligent decisions about multiple conflicting pieces of > > >> information. > > >> > > >> Here's how I see this working. The seeker has a PIDF-LO. > They apply > > >> the selection methods described in the above document to > select a > > >> single tuple that contains location information. > > >> (XPath="/presence/tuple[status/geopriv][1]") > > >> > > >> Whatever location information that tuple contains, be it > geodetic > > >> or civic, the seeker lifts the contents of the location-info > > >> element and puts it in an appropriate LoST query. > > >> > > >> Here are the applicable rules: > > >> > > >> Rule #1: A geopriv element MUST describe a discrete > location. Rule > > >> #4: Providing more than one location in a single > > >> element SHOULD be avoided where possible. Rule #5: When > providing > > >> more than one location in a single element the > > >> locations MUST be provided by a common source. Rule #6: > Providing > > >> more than one location in a single > element SHOULD > > >> only be done if they form a complex to describe the same > location. > > >> For example, a geodetic location describing a point, and a civic > > >> location indicating the floor in a building. Rule #8: > Where a PIDF > > >> document contains more than one tuple containing a > status element > > >> with a geopriv location element , the priority of tuples > SHOULD be > > >> based on tuple position within the PIDF document. That > is to say, > > >> the tuple with the highest priority location occurs > earliest in the > > >> PIDF document. Initial priority SHOULD be determined by the > > >> originating UA, the final priority MAY be determined by a proxy > > >> along the way, or the UAS. > > >> > > >> > > >>> -----Original Message----- From: Hannes Tschofenig > > >>> [mailto:hannes.tschofenig@siemens.com] Sent: Wednesday, 7 June > > >>> 2006 9:30 PM To: ecrit@ietf.org Subject: [Ecrit] [issue2] Is it > > >>> allowed to specify civic and geospatial infointo the query? > > >>> > > >>> > > >>> Hannes Tschofenig added the comment: > > >>> > > >>> TENTATIVE SUMMARY: > > >>> > > >>> Here is the update: > > >>> > > >>> * Either civic OR geospatial in a LoST query > > >>> > > >>> Marc, Henning, Shida, Richard, Brian, John Schnizlein, Byron > > >>> Smith, > > >>> > > >>> > > >>> > > >>> * Both civic AND geospatial possible in a LoST query > > >>> > > >>> Roger, Martin, Andy, James W. > > >>> > > >>> These folks don't seem to take a clear position: > > >>> > > >>> John Hearty, Jean-Francois, Clive D.W. Feather > > >>> > > >>> __________________________________________________ LoST Issue > > >>> Tracker > > >>> > > >>> __________________________________________________ > > >>> > > >>> _______________________________________________ Ecrit > mailing list > > >>> Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit > > >> > > >> > ------------------------------------------------------------------- > > >> ---- > > ------------------------- > > >> > > >> This message is for the designated recipient only and > may contain > > >> privileged, proprietary, or otherwise private > information. If you > > >> have received it in error, please notify the sender > immediately and > > >> delete the original. Any unauthorized use of this email is > > >> prohibited. > > >> > ------------------------------------------------------------------- > > >> ---- > > ------------------------- > > >> > > >> [mf2] > > >> > > >> > > >> > ------------------------------------------------------------------- > > >> ---- > > - > > >> > > >> > > >> _______________________________________________ Ecrit > mailing list > > >> Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 08 22:34:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoWpH-0002N2-V4; Thu, 08 Jun 2006 22:34:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoWpH-0002MX-22 for ecrit@ietf.org; Thu, 08 Jun 2006 22:34:19 -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 1FoVXg-0001E5-Nk for ecrit@ietf.org; Thu, 08 Jun 2006 21:12:04 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoVJr-0004dl-UT for ecrit@ietf.org; Thu, 08 Jun 2006 20:57:49 -0400 Received: from [192.168.0.41] (pool-138-89-46-232.mad.east.verizon.net [138.89.46.232]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k590uqaF003698 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 8 Jun 2006 20:56:53 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] [issue9] LoST Response with PSAP Preference -> [issue2]? Date: Thu, 8 Jun 2006 20:56:47 -0400 To: "Thomson, Martin" X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: -2.3 (--) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 A different solution for the "East Jerusalem" problem is that the service provider routes the LoST request to the politically appropriate venue. An Israeli service provider and a Palestinian one would have different boundaries in their database. (Maybe that boundary would depend on whether the server is affiliated with Hamas or Fatah...) The problem with the country code is that an end system using GPS has no way to obtain such a code automatically. You'd have to assume that ISPs would provide country code information via DHCP, say. On Jun 8, 2006, at 8:46 PM, Thomson, Martin wrote: > Brian, > > Have you just provided us with another possible use for composite > (civic+geo) location information? c.f. Henning's email on issue 2. > >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Friday, 9 June 2006 10:43 AM >> To: 'Roger Marshall'; 'Marc Linsner' >> Cc: ecrit@ietf.org >> Subject: RE: [Ecrit] [issue9] LoST Response with PSAP Preference >> >> I have been a little concerned about disputed territory for a >> couple of >> years now. I don't think it's a big problem, but it's a problem. My >> preferred solution is to supply the country name in the location. >> That >> will >> disambiguate any disputed territory issues. >> >> Brian >> > ---------------------------------------------------------------------- > -------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ---------------------------------------------------------------------- > -------------------------- > [mf2]_______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 09 10:58:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoiRV-0003zb-Fp; Fri, 09 Jun 2006 10:58:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoiRU-0003v4-IK for ecrit@ietf.org; Fri, 09 Jun 2006 10:58:32 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FoiRT-0001Xx-A1 for ecrit@ietf.org; Fri, 09 Jun 2006 10:58:32 -0400 Received: (qmail invoked by alias); 09 Jun 2006 14:58:29 -0000 Received: from p549849E7.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.73.231] by mail.gmx.net (mp038) with SMTP; 09 Jun 2006 16:58:29 +0200 X-Authenticated: #29516787 Message-ID: <44898C95.90900@gmx.net> Date: Fri, 09 Jun 2006 16:58:29 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ecrit] LoST Snapshot X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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, based on the discussions over the past few weeks/months we have updated the LoST draft. Please find the most recent snapshot here: http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/ You can also find the XML schema and instance documents there. More updates will follow. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 09 12:48:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FokA1-0004V1-Vl; Fri, 09 Jun 2006 12:48:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FokA1-0004Uw-4s for ecrit@ietf.org; Fri, 09 Jun 2006 12:48:37 -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 1Fok9z-0006D5-Oj for ecrit@ietf.org; Fri, 09 Jun 2006 12:48:37 -0400 Received: (qmail invoked by alias); 09 Jun 2006 16:48:34 -0000 Received: from p549849E7.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.73.231] by mail.gmx.net (mp029) with SMTP; 09 Jun 2006 18:48:34 +0200 X-Authenticated: #29516787 Message-ID: <4489A661.7070005@gmx.net> Date: Fri, 09 Jun 2006 18:48:33 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [Ecrit] Validation Functionality in LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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, consider the following example: Germany Bavaria Munich Neu Perlach 96 81675 urn:service:sos.police This is a query with civic location information and 'validation' enabled. Based on this query the following response is generated: Munich Police Department Germany Bavaria Munich Germany Bavaria Munich Neu Perlach 81675 sip:munich-police@example.com xmpp:munich-police@example.com 110 The validation element indicates that the civic address could be compared against a database and the indicated fields returned a match. Note that one child element, namely house number (i.e., 96) couldn't be matched and is therefore not included in the response. Is this the functionality we are looking for? What would be a resonable response for geospatial information? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jun 10 04:04:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoySd-0003ju-27; Sat, 10 Jun 2006 04:04:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoySc-0003i7-Iy for ecrit@ietf.org; Sat, 10 Jun 2006 04:04:46 -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 1FoySa-0002eW-5F for ecrit@ietf.org; Sat, 10 Jun 2006 04:04:46 -0400 Received: (qmail invoked by alias); 10 Jun 2006 08:04:42 -0000 Received: from p54987D3C.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.125.60] by mail.gmx.net (mp018) with SMTP; 10 Jun 2006 10:04:42 +0200 X-Authenticated: #29516787 Message-ID: <448A7D19.3090309@gmx.net> Date: Sat, 10 Jun 2006 10:04:41 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ecrit] Updated Draft: "Requirements for Emergency Context Resolution with Internet Technologies" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, Roger has submitted a final update to the requirements draft. Please find it at: http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-09.txt Here is a diff to the previous version: http://www.ietf-ecrit.org/cache/Diff_draft-ietf-ecrit-requirements-09_10.htm As you can see the last update only deals with editorial aspects. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jun 10 04:30:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foyro-0006B2-Hn; Sat, 10 Jun 2006 04:30:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foyrn-0006Ax-52 for ecrit@ietf.org; Sat, 10 Jun 2006 04:30:47 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Foyrl-0003dL-OC for ecrit@ietf.org; Sat, 10 Jun 2006 04:30:47 -0400 Received: (qmail invoked by alias); 10 Jun 2006 08:30:44 -0000 Received: from p54987D3C.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.125.60] by mail.gmx.net (mp030) with SMTP; 10 Jun 2006 10:30:44 +0200 X-Authenticated: #29516787 Message-ID: <448A8334.5060601@gmx.net> Date: Sat, 10 Jun 2006 10:30:44 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Ecrit] ECRIT Status X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, here are our goals and milestones from the charter: * Mar 2006 A Standards Track RFC describing how to identify a session set-up request is to an emergency response center * Mar 2006 Informational RFC containing terminology definitions and the requirements * May 2006 An Informational document describing the threats and security requirements Roger has submitted another version of the requirements draft. The requirements work is done. We received a lot of WGLC comments and Roger incorporated all of them. The draft-ietf-ecrit-service-urn-03 is also ready. There was plenty of discussion around the document over the last few months and Henning incorporated them with the last draft update. No more comments showed up. The WGLC of the security threats draft lead to good feedback. Tom is currently working on the draft update. A second WGLC is not necessary. It seems that we are able to finalize these three documents before the next IETF meeting. Thanks for the hard work. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jun 11 13:02:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpTKZ-0003CS-NC; Sun, 11 Jun 2006 13:02:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpTKY-0003CN-Mp for ecrit@ietf.org; Sun, 11 Jun 2006 13:02:30 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpTKX-0001Rj-E5 for ecrit@ietf.org; Sun, 11 Jun 2006 13:02:30 -0400 Received: from [192.168.0.41] (pool-138-89-46-232.mad.east.verizon.net [138.89.46.232]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k5BH2PPx003641 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sun, 11 Jun 2006 13:02:25 -0400 (EDT) In-Reply-To: <4489A661.7070005@gmx.net> References: <4489A661.7070005@gmx.net> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Validation Functionality in LoST Date: Sun, 11 Jun 2006 13:02:22 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 this is somewhat more complicated than necessary. By definition, validated information is the same as that provided by the querier, so it would be sufficient to say something like country A1 A3 For geo, the only validation would be that the combination of long/ lat exists on planet earth. It would be helpful to return a bit more detail about the PSAP, e.g., the country it is located in. That way, if I flip longitude and latitude, I might get a clue that maybe that equatorial-African PSAP doesn't quite make sense when I'm querying from Greenwich, England. On Jun 9, 2006, at 12:48 PM, Hannes Tschofenig wrote: > Hi all, > > consider the following example: > > > xmlns:p2="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="urn:ietf:params:xml:ns:lost1 schema4lost.xsd"> > > Germany > Bavaria > Munich > Neu Perlach > 96 > 81675 > > urn:service:sos.police > > > This is a query with civic location information and 'validation' > enabled. Based on this query the following response is generated: > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:p2="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" > xsi:schemaLocation="urn:ietf:params:xml:ns:lost1 schema4lost.xsd"> > Munich Police Department > > Germany > Bavaria > Munich > > > Germany > Bavaria > Munich > Neu Perlach > 81675 > > sip:munich-police@example.com > xmpp:munich-police@example.com > 110 > > > The validation element indicates that the civic address could be > compared against a database and the indicated fields returned a > match. Note that one child element, namely house number (i.e., > 96) couldn't be matched and is therefore not > included in the response. > > > Is this the functionality we are looking for? > What would be a resonable response for geospatial information? > > Ciao > Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jun 11 16:43:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpWmE-0001pQ-Cq; Sun, 11 Jun 2006 16:43:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpWmD-0001pL-DX for ecrit@ietf.org; Sun, 11 Jun 2006 16:43:17 -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 1FpWmC-0005sl-3r for ecrit@ietf.org; Sun, 11 Jun 2006 16:43:17 -0400 Received: from [10.0.1.103] ([::ffff:68.106.115.242]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Sun, 11 Jun 2006 16:43:41 -0400 id 0158801C.448C807D.000067F4 In-Reply-To: References: <4489A661.7070005@gmx.net> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Validation Functionality in LoST Date: Sun, 11 Jun 2006 16:43:11 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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 With the version that lists the elements and their contents, it perhaps offers a means for the validation to correct one of the data items... say if it were typosed or something. I'm not sure if that is important or not. Otherwise, just listing the element names is fine by me. -andy On Jun 11, 2006, at 1:02 PM, Henning Schulzrinne wrote: > I think this is somewhat more complicated than necessary. By > definition, validated information is the same as that provided by > the querier, so it would be sufficient to say something like > > country A1 A3 > > For geo, the only validation would be that the combination of long/ > lat exists on planet earth. It would be helpful to return a bit > more detail about the PSAP, e.g., the country it is located in. > That way, if I flip longitude and latitude, I might get a clue that > maybe that equatorial-African PSAP doesn't quite make sense when > I'm querying from Greenwich, England. > > > On Jun 9, 2006, at 12:48 PM, Hannes Tschofenig wrote: > >> Hi all, >> >> consider the following example: >> >> >> > xmlns:p2="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> xsi:schemaLocation="urn:ietf:params:xml:ns:lost1 schema4lost.xsd"> >> >> Germany >> Bavaria >> Munich >> Neu Perlach >> 96 >> 81675 >> >> urn:service:sos.police >> >> >> This is a query with civic location information and 'validation' >> enabled. Based on this query the following response is generated: >> >> >> > xmlns="urn:ietf:params:xml:ns:lost1" >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> xmlns:p2="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" >> xsi:schemaLocation="urn:ietf:params:xml:ns:lost1 schema4lost.xsd"> >> Munich Police Department >> >> Germany >> Bavaria >> Munich >> >> >> Germany >> Bavaria >> Munich >> Neu Perlach >> 81675 >> >> sip:munich-police@example.com >> xmpp:munich-police@example.com >> 110 >> >> >> The validation element indicates that the civic address could be >> compared against a database and the indicated fields returned a >> match. Note that one child element, namely house number (i.e., >> 96) couldn't be matched and is therefore not >> included in the response. >> >> >> Is this the functionality we are looking for? >> What would be a resonable response for geospatial information? >> >> Ciao >> Hannes >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jun 11 17:03:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpX5c-0004qG-Pe; Sun, 11 Jun 2006 17:03:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpX5c-0004qB-Ck for ecrit@ietf.org; Sun, 11 Jun 2006 17:03:20 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpX5b-0007eD-6f for ecrit@ietf.org; Sun, 11 Jun 2006 17:03:20 -0400 Received: from [192.168.0.41] (pool-138-89-46-232.mad.east.verizon.net [138.89.46.232]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k5BL3Cev014948 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sun, 11 Jun 2006 17:03:13 -0400 (EDT) In-Reply-To: References: <4489A661.7070005@gmx.net> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3084344C-3440-4A78-9046-45004C5B76B5@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Validation Functionality in LoST Date: Sun, 11 Jun 2006 17:03:14 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Returning a "normalized" address is something that the USPS does on their web site. As a server-optional feature, this seems somewhat useful, as long as we don't get too fancy (such as offering 10 choices of what the address might have been). On Jun 11, 2006, at 4:43 PM, Andrew Newton wrote: > With the version that lists the elements and their contents, it > perhaps offers a means for the validation to correct one of the > data items... say if it were typosed or something. I'm not sure if > that is important or not. Otherwise, just listing the element > names is fine by me. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jun 11 18:15:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpYDr-000332-VG; Sun, 11 Jun 2006 18:15:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpYDq-00032x-Ll for ecrit@ietf.org; Sun, 11 Jun 2006 18:15:54 -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 1FpYDm-0004tr-Ek for ecrit@ietf.org; Sun, 11 Jun 2006 18:15:54 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Sun, 11 Jun 2006 18:16:15 -0400 id 015880B3.448C9630.0000757D Message-ID: <448C9607.1090405@hxr.us> Date: Sun, 11 Jun 2006 18:15:35 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Validation Functionality in LoST References: <4489A661.7070005@gmx.net> <3084344C-3440-4A78-9046-45004C5B76B5@cs.columbia.edu> In-Reply-To: <3084344C-3440-4A78-9046-45004C5B76B5@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: 7bac9cb154eb5790ae3b2913587a40de Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning Schulzrinne wrote: > As a server-optional feature, this seems somewhat > useful, as long as we don't get too fancy (such as offering 10 choices > of what the address might have been). I agree. If it gets any more "fancy" than this, then we need to drop back to just listing the elements. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 12 10:55:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpnpQ-0005vB-5W; Mon, 12 Jun 2006 10:55:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpnpP-0005v6-Da for ecrit@ietf.org; Mon, 12 Jun 2006 10:55:43 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpnpN-0007XJ-0d for ecrit@ietf.org; Mon, 12 Jun 2006 10:55:43 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Mon, 12 Jun 2006 07:55:40 -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] Updated Draft: "Requirements for Emergency Context Resolution with Internet Technologies" Date: Mon, 12 Jun 2006 07:55:31 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575051DA334@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Updated Draft: "Requirements for Emergency Context Resolution with Internet Technologies" Thread-Index: AcaMZI/7+7aULhorRYOOe7IOF3tLLgBy2hTg From: "Roger Marshall" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Minor correction to referenced link for final requirements version: Please use the link for -10: http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-10.txt Thanks. Roger Marshall. >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 >Sent: Saturday, June 10, 2006 1:05 AM >To: ecrit@ietf.org >Subject: [Ecrit] Updated Draft: "Requirements for Emergency=20 >Context Resolution with Internet Technologies" > >Hi all, > >Roger has submitted a final update to the requirements draft. > >Please find it at: >http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-09.txt > >Here is a diff to the previous version: >http://www.ietf-ecrit.org/cache/Diff_draft-ietf-ecrit-requireme nts-09_10.htm > >As you can see the last update only deals with editorial aspects. > >Ciao >Hannes > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 12 15:04:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fprhq-0006vy-9U; Mon, 12 Jun 2006 15:04:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fprhp-0006vm-2O for ecrit@ietf.org; Mon, 12 Jun 2006 15:04:09 -0400 Received: from qfe1.f10207-20.atlanta2.level3.net ([67.72.93.25] helo=f10207-20.adc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fprhn-0008VO-Ov for ecrit@ietf.org; Mon, 12 Jun 2006 15:04:09 -0400 Received: from machine77.Level3.com (qfe0.f4ff49-08.idc1.oss.level3.com [10.1.156.103]) by f10207-20.adc1.level3.com (8.12.10/8.12.10) with ESMTP id k5CJ446r012032 for ; Mon, 12 Jun 2006 19:04:05 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id A1E1478B473 for ; Mon, 12 Jun 2006 19:04:03 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner3.l3.com (Postfix) with SMTP id 676A778B431 for ; Mon, 12 Jun 2006 19:04:03 +0000 (GMT) Received: from idc1exc0004.corp.global.level3.com ([10.1.9.15]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Jun 2006 13:04:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] [issue2] Is it allowed to specify civicand geospatialinfointo the query? Date: Mon, 12 Jun 2006 13:04:02 -0600 Message-ID: <3F75233A2E57CC468B35F3B1FAF71EC003DF95D8@idc1exc0004.corp.global.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [issue2] Is it allowed to specify civicand geospatialinfointo the query? Thread-Index: AcaLCT4+37NoaaRwQTWWx/hhDZC9CQDSLXKA From: "Hearty, John" To: X-OriginalArrivalTime: 12 Jun 2006 19:04:03.0269 (UTC) FILETIME=[F8685F50:01C68E52] X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org >(1) a (purportedly) single location determined by two different =20 >mechanisms, i.e., with the potential that civic and geo are actually =20 >not referring to the same point or building due to measurement errors =20 >of various sorts; This is the case I was thinking of. However, I can't think of any reasons why the LoST server would want to take the less accurate location into account when determining an answer. If someone can think of a good reason, then it makes sense to allow both in one query. If not, one or the other in a single query makes the most sense to me for this case. John -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Thursday, June 08, 2006 7:39 AM To: Thomson, Martin Cc: ecrit@ietf.org Subject: Re: [Ecrit] [issue2] Is it allowed to specify civicand geospatialinfointo the query? I have no objection to having a "hybrid" address if it is indeed =20 logically a single address which can never, ever lead to two =20 different PSAPs. As Marc notes, one has to ask if this is really the =20 best way to organize location information since we are now =20 commingling two very different cases: (1) a (purportedly) single location determined by two different =20 mechanisms, i.e., with the potential that civic and geo are actually =20 not referring to the same point or building due to measurement errors =20 of various sorts; (2) a hybrid location, where x and y coordinates are specified in geo =20 and z coordinates in "civic" (floors) Plus, there are then the various civic "enhancements" such as =20 building names, suite number or tenant name that are useful in =20 practice, so they might also get thrown in for model (2). Maybe this is a geopriv topic, but this strikes me as a recipe for =20 confusion. Having to pick apart the various cases of - geo has altitude, civic has (only) a floor, but maybe also a =20 building name -> could be (1) or (2) - geo has no altitude, civic has only floor (but maybe also building =20 name and tenant or house number) -> (2) - geo has no altitude, but civic has street-level addressing -> (1) - and plenty more seems to lead to lots of special cases that are likely to increase as =20 we add more elements to either civic or geo. Henning On Jun 7, 2006, at 11:35 PM, Thomson, Martin wrote: > It is better to think of anything that appears within a single =20 > element as a single location. You aren't sending =20 > more than one location to the LoST server. If you think about it =20 > as a single "location" with multiple parts (elements), the fears =20 > about multiple responses disappear. > > The only valid concern that remains is LoST server complexity. But =20 > when you scratch beneath the surface a little, this begins to be =20 > less of a source of intestinal torment. If we consider the =20 > occasions where this composite location is possible, it quickly =20 > resolves down to the floors altitude case, and not a whole lot =20 > more. In other words, I can't think of a good alternative =20 > example. That means that the LoST server can safely ignore the =20 > "2" that goes along with =20 > the geodetic information, except where you have the weird case =20 > where the bottom-floor cinema is served by a different PSAP to the =20 > upper-floors (not my example). > _______________________________________________ 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 Jun 12 15:14:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fprrn-00024r-Ig; Mon, 12 Jun 2006 15:14:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fprrm-00024X-No for ecrit@ietf.org; Mon, 12 Jun 2006 15:14:26 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fprrl-00015N-Cg for ecrit@ietf.org; Mon, 12 Jun 2006 15:14:26 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Fprrc-0000kK-5n; Mon, 12 Jun 2006 14:14:16 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Hannes Tschofenig'" Subject: RE: [Ecrit] Validation Functionality in LoST Date: Mon, 12 Jun 2006 15:14:20 -0400 Message-ID: <063d01c68e54$6a319830$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaNeNcKopO2XHF+QbS8sAgaSmBZegA2qyfQ 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: 825e642946eda55cd9bc654a36dab8c2 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think this is fine, but we may need a little more intelligence. Consider the following cases: Country, State/Province (A1), City(A3), Street and House Number correct, County (A2) wrong Country, State/Province, Street and House number correct, county missing, city wrong County, State/Province, County, City, House Number correct, Street wrong In the first case, (wrong county) the ideal response would be to respond with the fields that are correct, meaning the county would not be in the list. In the second case it would probably not be a good idea to respond with anything but Country & State. If the City is wrong, you probably don't look at the Street. In the final case, you definitely don't return the House Number if the street name is wrong. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Sunday, June 11, 2006 1:02 PM To: Hannes Tschofenig Cc: ecrit@ietf.org Subject: Re: [Ecrit] Validation Functionality in LoST I think this is somewhat more complicated than necessary. By definition, validated information is the same as that provided by the querier, so it would be sufficient to say something like country A1 A3 For geo, the only validation would be that the combination of long/ lat exists on planet earth. It would be helpful to return a bit more detail about the PSAP, e.g., the country it is located in. That way, if I flip longitude and latitude, I might get a clue that maybe that equatorial-African PSAP doesn't quite make sense when I'm querying from Greenwich, England. On Jun 9, 2006, at 12:48 PM, Hannes Tschofenig wrote: > Hi all, > > consider the following example: > > > xmlns:p2="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="urn:ietf:params:xml:ns:lost1 schema4lost.xsd"> > > Germany > Bavaria > Munich > Neu Perlach > 96 > 81675 > > urn:service:sos.police > > > This is a query with civic location information and 'validation' > enabled. Based on this query the following response is generated: > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:p2="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" > xsi:schemaLocation="urn:ietf:params:xml:ns:lost1 schema4lost.xsd"> > Munich Police Department > > Germany > Bavaria > Munich > > > Germany > Bavaria > Munich > Neu Perlach > 81675 > > sip:munich-police@example.com > xmpp:munich-police@example.com > 110 > > > The validation element indicates that the civic address could be > compared against a database and the indicated fields returned a > match. Note that one child element, namely house number (i.e., > 96) couldn't be matched and is therefore not > included in the response. > > > Is this the functionality we are looking for? > What would be a resonable response for geospatial information? > > Ciao > Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 12 15:18:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fprvq-0007HQ-IW; Mon, 12 Jun 2006 15:18:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fprvp-0007Dj-Nh for ecrit@ietf.org; Mon, 12 Jun 2006 15:18:37 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fprvo-0001R0-CL for ecrit@ietf.org; Mon, 12 Jun 2006 15:18:37 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Fprvg-00016e-6u; Mon, 12 Jun 2006 14:18:28 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Validation Functionality in LoST Date: Mon, 12 Jun 2006 15:18:32 -0400 Message-ID: <063e01c68e55$006c26d0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaNl6qxmdPEY2rdSSGaLu8ojDNU8AAvMNUw 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: b132cb3ed2d4be2017585bf6859e1ede Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I have direct, relevant experience doing exactly this. It's hard, but worthwhile. Agree that you don't want to respond with a lot of possible answers. 10 is maybe too big, 5 might be closer. There is a lot of subtlety in how you do this. None-the-less, I think it's very worthwhile to try. I could try to write a fairly clear algorithm for how you would do this with U.S. style addresses, and then we can see what we say for others. Brian -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Sunday, June 11, 2006 4:43 PM To: Henning Schulzrinne Cc: ecrit@ietf.org Subject: Re: [Ecrit] Validation Functionality in LoST With the version that lists the elements and their contents, it perhaps offers a means for the validation to correct one of the data items... say if it were typosed or something. I'm not sure if that is important or not. Otherwise, just listing the element names is fine by me. -andy On Jun 11, 2006, at 1:02 PM, Henning Schulzrinne wrote: > I think this is somewhat more complicated than necessary. By > definition, validated information is the same as that provided by > the querier, so it would be sufficient to say something like > > country A1 A3 > > For geo, the only validation would be that the combination of long/ > lat exists on planet earth. It would be helpful to return a bit > more detail about the PSAP, e.g., the country it is located in. > That way, if I flip longitude and latitude, I might get a clue that > maybe that equatorial-African PSAP doesn't quite make sense when > I'm querying from Greenwich, England. > > > On Jun 9, 2006, at 12:48 PM, Hannes Tschofenig wrote: > >> Hi all, >> >> consider the following example: >> >> >> > xmlns:p2="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> xsi:schemaLocation="urn:ietf:params:xml:ns:lost1 schema4lost.xsd"> >> >> Germany >> Bavaria >> Munich >> Neu Perlach >> 96 >> 81675 >> >> urn:service:sos.police >> >> >> This is a query with civic location information and 'validation' >> enabled. Based on this query the following response is generated: >> >> >> > xmlns="urn:ietf:params:xml:ns:lost1" >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> xmlns:p2="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" >> xsi:schemaLocation="urn:ietf:params:xml:ns:lost1 schema4lost.xsd"> >> Munich Police Department >> >> Germany >> Bavaria >> Munich >> >> >> Germany >> Bavaria >> Munich >> Neu Perlach >> 81675 >> >> sip:munich-police@example.com >> xmpp:munich-police@example.com >> 110 >> >> >> The validation element indicates that the civic address could be >> compared against a database and the indicated fields returned a >> match. Note that one child element, namely house number (i.e., >> 96) couldn't be matched and is therefore not >> included in the response. >> >> >> Is this the functionality we are looking for? >> What would be a resonable response for geospatial information? >> >> Ciao >> Hannes >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 12 15:26:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fps3c-0003eA-Qv; Mon, 12 Jun 2006 15:26:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fps3b-0003e5-RY for ecrit@ietf.org; Mon, 12 Jun 2006 15:26:39 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fps3a-0001xh-Ky for ecrit@ietf.org; Mon, 12 Jun 2006 15:26:39 -0400 Received: from lion.cs.columbia.edu (IDENT:TrxkxCjh2Xh58V1EukTaup0QFKrQtXhn@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k5CJQRX6008196 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 12 Jun 2006 15:26:28 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k5CJQRBB014895 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Jun 2006 15:26:27 -0400 Message-ID: <448DBFDE.30803@cs.columbia.edu> Date: Mon, 12 Jun 2006 15:26:22 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Validation Functionality in LoST References: <063e01c68e55$006c26d0$640fa8c0@cis.neustar.com> In-Reply-To: <063e01c68e55$006c26d0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This seems like a separate functionality, i.e., not something returned by the standard query, but by some other request type. Only some servers are likely to implement such functionality. Once you have 5, you have to allow essentially an infinite number of responses. For anything other than 0 or 1, the user has to decide which one to pick, so it can't be automated. Brian Rosen wrote: > I have direct, relevant experience doing exactly this. It's hard, but > worthwhile. Agree that you don't want to respond with a lot of possible > answers. 10 is maybe too big, 5 might be closer. There is a lot of > subtlety in how you do this. None-the-less, I think it's very worthwhile to > try. > > I could try to write a fairly clear algorithm for how you would do this with > U.S. style addresses, and then we can see what we say for others. > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 12 15:36:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpsDK-0005tZ-1P; Mon, 12 Jun 2006 15:36:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpsDJ-0005tP-0A for ecrit@ietf.org; Mon, 12 Jun 2006 15:36:41 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpsDH-0003YH-P8 for ecrit@ietf.org; Mon, 12 Jun 2006 15:36:40 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FpsD9-0002Da-Jd; Mon, 12 Jun 2006 14:36:32 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] Validation Functionality in LoST Date: Mon, 12 Jun 2006 15:36:34 -0400 Message-ID: <064701c68e57$85de86d0$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: <448DBFDE.30803@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaOVhu3gUHyg3FQQ/CmSH0OYbql/QAARusA 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: 52e1467c2184c31006318542db5614d5 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'm fine if it's a separate query. I think you DO want a human to look at it, even if it's only one possibility. There are too many cases where there may only be one choice, but it's the wrong choice. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, June 12, 2006 3:26 PM To: Brian Rosen Cc: 'Andrew Newton'; ecrit@ietf.org Subject: Re: [Ecrit] Validation Functionality in LoST This seems like a separate functionality, i.e., not something returned by the standard query, but by some other request type. Only some servers are likely to implement such functionality. Once you have 5, you have to allow essentially an infinite number of responses. For anything other than 0 or 1, the user has to decide which one to pick, so it can't be automated. Brian Rosen wrote: > I have direct, relevant experience doing exactly this. It's hard, but > worthwhile. Agree that you don't want to respond with a lot of possible > answers. 10 is maybe too big, 5 might be closer. There is a lot of > subtlety in how you do this. None-the-less, I think it's very worthwhile to > try. > > I could try to write a fairly clear algorithm for how you would do this with > U.S. style addresses, and then we can see what we say for others. > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 12 15:50:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpsQK-0007Fy-NZ; Mon, 12 Jun 2006 15:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpsQF-0007Dy-AN; Mon, 12 Jun 2006 15:50:03 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpsQE-0005sK-5M; Mon, 12 Jun 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5CJo1WR001053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FpsQD-0006gq-PY; Mon, 12 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 12 Jun 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-requirements-10.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Requirements for Emergency Context Resolution with Internet Technologies Author(s) : H. Schulzrinne, R. Marshall Filename : draft-ietf-ecrit-requirements-10.txt Pages : 31 Date : 2006-6-12 This document enumerates requirements for the context resolution of emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-requirements-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-requirements-10.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-6-12105453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-requirements-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-requirements-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-12105453.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 Mon Jun 12 16:02:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpscU-0002AW-BD; Mon, 12 Jun 2006 16:02:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpsQd-0007tz-Op for ecrit@ietf.org; Mon, 12 Jun 2006 15:50:28 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpsQd-0005wV-6x for ecrit@ietf.org; Mon, 12 Jun 2006 15:50:27 -0400 Received: from lion.cs.columbia.edu (IDENT:rmruOkbP0EKaH61HV7ljUUcw9Kmz4w0N@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k5CJoCX6014781 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 12 Jun 2006 15:50:15 -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 k5CJoCBB016481 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Jun 2006 15:50:12 -0400 Message-ID: <448DC56F.1000201@cs.columbia.edu> Date: Mon, 12 Jun 2006 15:50:07 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Validation Functionality in LoST References: <063d01c68e54$6a319830$640fa8c0@cis.neustar.com> In-Reply-To: <063d01c68e54$6a319830$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'm interpreting the examples as below as that a list of validated elements would be sufficient. Clearly, the server has to be smarter and not just do an element-by-element comparison. In most cases, elements below the "wrong" element can never be right. Counties, at least in the US, are exceptions since they are not necessary for uniqueness. Obviously, the use of A2 may vary across countries, so we can probably only provide general guidance to implementors, such as "in general, anything below the wrong element is not returned in the list, except where the element is not necessary to make an address unique." Brian Rosen wrote: > I think this is fine, but we may need a little more intelligence. Consider > the following cases: > > Country, State/Province (A1), City(A3), Street and House Number correct, > County (A2) wrong > > Country, State/Province, Street and House number correct, county missing, > city wrong > > County, State/Province, County, City, House Number correct, Street wrong > > In the first case, (wrong county) the ideal response would be to respond > with the fields that are correct, meaning the county would not be in the > list. > > In the second case it would probably not be a good idea to respond with > anything but Country & State. If the City is wrong, you probably don't look > at the Street. > > In the final case, you definitely don't return the House Number if the > street name is wrong. > > Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 12 16:56:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FptS9-00046t-DR; Mon, 12 Jun 2006 16:56:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FptS7-000462-Oe for ecrit@ietf.org; Mon, 12 Jun 2006 16:56: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 1FptS6-0005IY-94 for ecrit@ietf.org; Mon, 12 Jun 2006 16:56:03 -0400 Received: (qmail invoked by alias); 12 Jun 2006 20:56:00 -0000 Received: from p54986EEF.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.110.239] by mail.gmx.net (mp031) with SMTP; 12 Jun 2006 22:56:00 +0200 X-Authenticated: #29516787 Message-ID: <448DD4DF.7040605@gmx.net> Date: Mon, 12 Jun 2006 22:55:59 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Validation Functionality in LoST References: <063e01c68e55$006c26d0$640fa8c0@cis.neustar.com> In-Reply-To: <063e01c68e55$006c26d0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab 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 Looking forward to see your algorithm. Brian Rosen wrote: > I have direct, relevant experience doing exactly this. It's hard, but > worthwhile. Agree that you don't want to respond with a lot of possible > answers. 10 is maybe too big, 5 might be closer. There is a lot of > subtlety in how you do this. None-the-less, I think it's very worthwhile to > try. > > I could try to write a fairly clear algorithm for how you would do this with > U.S. style addresses, and then we can see what we say for others. > > Brian > > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Sunday, June 11, 2006 4:43 PM > To: Henning Schulzrinne > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Validation Functionality in LoST > > With the version that lists the elements and their contents, it > perhaps offers a means for the validation to correct one of the data > items... say if it were typosed or something. I'm not sure if that > is important or not. Otherwise, just listing the element names is > fine by me. > > -andy > > On Jun 11, 2006, at 1:02 PM, Henning Schulzrinne wrote: > > >>I think this is somewhat more complicated than necessary. By >>definition, validated information is the same as that provided by >>the querier, so it would be sufficient to say something like >> >>country A1 A3 >> >>For geo, the only validation would be that the combination of long/ >>lat exists on planet earth. It would be helpful to return a bit >>more detail about the PSAP, e.g., the country it is located in. >>That way, if I flip longitude and latitude, I might get a clue that >>maybe that equatorial-African PSAP doesn't quite make sense when >>I'm querying from Greenwich, England. >> >> >>On Jun 9, 2006, at 12:48 PM, Hannes Tschofenig wrote: >> >> >>>Hi all, >>> >>>consider the following example: >>> >>> >>>>> xmlns:p2="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >>>xsi:schemaLocation="urn:ietf:params:xml:ns:lost1 schema4lost.xsd"> >>> >>> Germany >>> Bavaria >>> Munich >>> Neu Perlach >>> 96 >>> 81675 >>> >>> urn:service:sos.police >>> >>> >>>This is a query with civic location information and 'validation' >>>enabled. Based on this query the following response is generated: >>> >>> >>>>>xmlns="urn:ietf:params:xml:ns:lost1" >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >>> xmlns:p2="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" >>>xsi:schemaLocation="urn:ietf:params:xml:ns:lost1 schema4lost.xsd"> >>> Munich Police Department >>> >>> Germany >>> Bavaria >>> Munich >>> >>> >>> Germany >>> Bavaria >>> Munich >>> Neu Perlach >>> 81675 >>> >>> sip:munich-police@example.com >>> xmpp:munich-police@example.com >>> 110 >>> >>> >>>The validation element indicates that the civic address could be >>>compared against a database and the indicated fields returned a >>>match. Note that one child element, namely house number (i.e., >>>96) couldn't be matched and is therefore not >>>included in the response. >>> >>> >>>Is this the functionality we are looking for? >>>What would be a resonable response for geospatial information? >>> >>>Ciao >>>Hannes >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ecrit >> >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 12 19:50:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpwAZ-00043n-K3; Mon, 12 Jun 2006 19:50:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpwAY-00043h-M5 for ecrit@ietf.org; Mon, 12 Jun 2006 19:50:06 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpwAX-00009H-DK for ecrit@ietf.org; Mon, 12 Jun 2006 19:50:06 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Jun 2006 18:50:34 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 12 Jun 2006 18:50:33 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Jun 2006 18:50:33 -0500 Message-ID: From: "Thomson, Martin" To: "Brian Rosen" , "Henning Schulzrinne" Date: Mon, 12 Jun 2006 18:49:45 -0500 Subject: RE: [Ecrit] Validation Functionality in LoST MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 12 Jun 2006 23:50:33.0396 (UTC) FILETIME=[FE859740:01C68E7A] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <064701c68e57$85de86d0$640fa8c0@cis.neustar.com> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Validation Functionality in LoST Thread-Index: AcaOVhu3gUHyg3FQQ/CmSH0OYbql/QAARusAAAiGe3A= X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0728111524==" Errors-To: ecrit-bounces@ietf.org --===============0728111524== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message SSBhZ3JlZSwgaWYgeW91IGhhdmUgYSBwcm9ibGVtLCB5b3UgY2FuJ3QgcmVseSBvbiB0aGUgYXV0 b21hdGljIHNvbHV0aW9uLiAgDQoNCkkgaGF2ZSB1c2VkIHRoZXNlIGF1dG9tYXRlZCAieW91LW1l YW50LXRoaXMtYWRkcmVzcyIgc2VydmljZXMgYSBsaXR0bGUgcmVjZW50bHkgYW5kIHVubGVzcyB0 aGV5IGFjdHVhbGx5IHJlc29sdmUgdG8gb25lIGFkZHJlc3MsIHRoZXkgdGVuZCB0byBiZSBhIGxp dHRsZSBudXRzLiAgSW4gbXkgY2FzZSwgSSBncmV3IHVwIHVzaW5nIG9uZSBzdWJ1cmIgbmFtZSB0 aGF0IGlzIG5vIGxvbmdlciB0aGUgb2ZmaWNpYWxseSBzYW5jdGlvbmVkIHN1YnVyYiBmb3IgdGhh dCBzdHJlZXQsIHNvIHdoZW4gSSB1c2UgdGhlIG9sZCBzdWJ1cmIgbmFtZSwgSSBnZXQgYSBsaXN0 IG9mIDEwIHdvZWZ1bGx5IGluYWNjdXJhdGUgYWx0ZXJuYXRpdmVzLiAgVGhlIHByb2JsZW0gaXMg dGhhdCB0aGUgYWxnb3JpdGhtIGhhcyB0byBhc3N1bWUgdGhhdCB5b3UgaGF2ZSBtYWRlIGEgbWlz dGFrZSBpbiBhbnkgZmllbGQsIHdoaWNoIGxlYWRzIHRvIHNvbWUgaW50ZXJlc3RpbmcgYWx0ZXJu YXRpdmVzLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJyaWFuIFJv c2VuIFttYWlsdG86YnJAYnJpYW5yb3Nlbi5uZXRdDQo+IFNlbnQ6IFR1ZXNkYXksIDEzIEp1bmUg MjAwNiA1OjM3IEFNDQo+IFRvOiAnSGVubmluZyBTY2h1bHpyaW5uZScNCj4gQ2M6IGVjcml0QGll dGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbRWNyaXRdIFZhbGlkYXRpb24gRnVuY3Rpb25hbGl0eSBp biBMb1NUDQo+IA0KPiBJJ20gZmluZSBpZiBpdCdzIGEgc2VwYXJhdGUgcXVlcnkuICBJIHRoaW5r IHlvdSBETyB3YW50IGEgaHVtYW4gdG8gbG9vayBhdA0KPiBpdCwgZXZlbiBpZiBpdCdzIG9ubHkg b25lIHBvc3NpYmlsaXR5LiAgVGhlcmUgYXJlIHRvbyBtYW55IGNhc2VzIHdoZXJlDQo+IHRoZXJl DQo+IG1heSBvbmx5IGJlIG9uZSBjaG9pY2UsIGJ1dCBpdCdzIHRoZSB3cm9uZyBjaG9pY2UuDQo+ IA0KPiBCcmlhbg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSGVu bmluZyBTY2h1bHpyaW5uZSBbbWFpbHRvOmhnc0Bjcy5jb2x1bWJpYS5lZHVdDQo+IFNlbnQ6IE1v bmRheSwgSnVuZSAxMiwgMjAwNiAzOjI2IFBNDQo+IFRvOiBCcmlhbiBSb3Nlbg0KPiBDYzogJ0Fu ZHJldyBOZXd0b24nOyBlY3JpdEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0Vjcml0XSBWYWxp ZGF0aW9uIEZ1bmN0aW9uYWxpdHkgaW4gTG9TVA0KPiANCj4gVGhpcyBzZWVtcyBsaWtlIGEgc2Vw YXJhdGUgZnVuY3Rpb25hbGl0eSwgaS5lLiwgbm90IHNvbWV0aGluZyByZXR1cm5lZA0KPiBieSB0 aGUgc3RhbmRhcmQgcXVlcnksIGJ1dCBieSBzb21lIG90aGVyIHJlcXVlc3QgdHlwZS4gT25seSBz b21lIHNlcnZlcnMNCj4gYXJlIGxpa2VseSB0byBpbXBsZW1lbnQgc3VjaCBmdW5jdGlvbmFsaXR5 Lg0KPiANCj4gT25jZSB5b3UgaGF2ZSA1LCB5b3UgaGF2ZSB0byBhbGxvdyBlc3NlbnRpYWxseSBh biBpbmZpbml0ZSBudW1iZXIgb2YNCj4gcmVzcG9uc2VzLiBGb3IgYW55dGhpbmcgb3RoZXIgdGhh biAwIG9yIDEsIHRoZSB1c2VyIGhhcyB0byBkZWNpZGUgd2hpY2gNCj4gb25lIHRvIHBpY2ssIHNv IGl0IGNhbid0IGJlIGF1dG9tYXRlZC4NCj4gDQo+IEJyaWFuIFJvc2VuIHdyb3RlOg0KPiA+IEkg aGF2ZSBkaXJlY3QsIHJlbGV2YW50IGV4cGVyaWVuY2UgZG9pbmcgZXhhY3RseSB0aGlzLiAgSXQn cyBoYXJkLCBidXQNCj4gPiB3b3J0aHdoaWxlLiAgQWdyZWUgdGhhdCB5b3UgZG9uJ3Qgd2FudCB0 byByZXNwb25kIHdpdGggYSBsb3Qgb2YgcG9zc2libGUNCj4gPiBhbnN3ZXJzLiAgMTAgaXMgbWF5 YmUgdG9vIGJpZywgNSBtaWdodCBiZSBjbG9zZXIuICBUaGVyZSBpcyBhIGxvdCBvZg0KPiA+IHN1 YnRsZXR5IGluIGhvdyB5b3UgZG8gdGhpcy4gIE5vbmUtdGhlLWxlc3MsIEkgdGhpbmsgaXQncyB2 ZXJ5DQo+IHdvcnRod2hpbGUNCj4gdG8NCj4gPiB0cnkuDQo+ID4NCj4gPiBJIGNvdWxkIHRyeSB0 byB3cml0ZSBhIGZhaXJseSBjbGVhciBhbGdvcml0aG0gZm9yIGhvdyB5b3Ugd291bGQgZG8gdGhp cw0KPiB3aXRoDQo+ID4gVS5TLiBzdHlsZSBhZGRyZXNzZXMsIGFuZCB0aGVuIHdlIGNhbiBzZWUg d2hhdCB3ZSBzYXkgZm9yIG90aGVycy4NCj4gPg0KPiA+IEJyaWFuDQo+ID4NCj4gDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBFY3JpdCBt YWlsaW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZWNyaXQNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5 IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBw cml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmln aW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQu DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJd --===============0728111524== 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 --===============0728111524==-- From ecrit-bounces@ietf.org Wed Jun 14 07:17:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqTN8-0003nF-2A; Wed, 14 Jun 2006 07:17:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqTN6-0003mZ-QY for ecrit@ietf.org; Wed, 14 Jun 2006 07:17:16 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqTN4-00080I-Ed for ecrit@ietf.org; Wed, 14 Jun 2006 07:17:16 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTPœ id k5EBGsZ6003180Wed, 14 Jun 2006 11:16:56 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1FqTDE-0006kY-00; Wed, 14 Jun 2006 12:07:04 +0100 Date: Wed, 14 Jun 2006 12:07:04 +0100 From: "Clive D.W. Feather" To: Henning Schulzrinne Subject: Re: [Ecrit] Validation Functionality in LoST Message-ID: <20060614110704.GO4560@finch-staff-1.thus.net> References: <4489A661.7070005@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i 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 Henning Schulzrinne said: > For geo, the only validation would be that the combination of long/ > lat exists on planet earth. It would be helpful to return a bit more > detail about the PSAP, e.g., the country it is located in. That way, > if I flip longitude and latitude, I might get a clue that maybe that > equatorial-African PSAP doesn't quite make sense when I'm querying > from Greenwich, England. Nitpick: depending on your sign convention, you'll get either somewhere *off* equatorial Africa (about midway between Mogadishu and the Seychelles) or somewhere near Santana, Brazil, just north of the mouth of the Amazon. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 15 04:47:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqnVl-0003ht-PU; Thu, 15 Jun 2006 04:47:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqnVk-0003ho-Vv for ecrit@ietf.org; Thu, 15 Jun 2006 04:47:32 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FqnVj-0001e5-Ic for ecrit@ietf.org; Thu, 15 Jun 2006 04:47:32 -0400 Received: (qmail invoked by alias); 15 Jun 2006 08:47:29 -0000 Received: from p54986F41.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.111.65] by mail.gmx.net (mp039) with SMTP; 15 Jun 2006 10:47:29 +0200 X-Authenticated: #29516787 Message-ID: <44911E9F.5070001@gmx.net> Date: Thu, 15 Jun 2006 10:47:27 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 1.2 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ecrit] draft-polk-dhc-emergency-dialstring-option-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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 would like get some feedback regarding a draft published by James and Brian in Feb. 2006: http://www.ietf.org/internet-drafts/draft-polk-dhc-emergency-dialstring-option-00.txt Do we want/need such a solution? Ciao Hannes PS: Henning provided feedback some time back http://www1.ietf.org/mail-archive/web/ecrit/current/msg01578.html but I don't recall a conclusion. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 15 15:06:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqxAj-0001Ql-JC; Thu, 15 Jun 2006 15:06:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqxAi-0001Ng-Gj for ecrit@ietf.org; Thu, 15 Jun 2006 15:06:28 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqxAh-0007nM-5y for ecrit@ietf.org; Thu, 15 Jun 2006 15:06:28 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 15 Jun 2006 12:06:26 -0700 X-IronPort-AV: i="4.06,138,1149490800"; d="scan'208"; a="1826415158:sNHT31806220" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5FJ6Qwm020140; Thu, 15 Jun 2006 12:06:26 -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 k5FJ6QCU003746; Thu, 15 Jun 2006 12:06:26 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Jun 2006 12:06:26 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.20.94]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Jun 2006 12:06:25 -0700 Message-Id: <4.3.2.7.2.20060615135503.02759d10@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Jun 2006 14:06:23 -0500 To: Hannes Tschofenig , ecrit@ietf.org From: "James M. Polk" Subject: Re: [Ecrit] draft-polk-dhc-emergency-dialstring-option-00 In-Reply-To: <44911E9F.5070001@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 15 Jun 2006 19:06:25.0867 (UTC) FILETIME=[CCA459B0:01C690AE] DKIM-Signature: a=rsa-sha1; q=dns; l=1575; t=1150398386; x=1151262386; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Ecrit]=20draft-polk-dhc-emergency-dialstring-option-00; X=v=3Dcisco.com=3B=20h=3DC9eZ5/XL3peNT33nD2Rk93/tn9w=3D; b=NfVPJVu84NbI9wzNcRUtw6UJF/XZcou0gal6G1f4X4xe9VkiCI4O6FXsMSZ8mpcmmlbaT3EN JwqPGEDU2mk4D241dd5UYrFNkHwkfDICYIm5CFDc2acFlKwX9fc1hbD5; Authentication-Results: sj-dkim-2.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 10:47 AM 6/15/2006 +0200, Hannes Tschofenig wrote: >Hi all, > >I would like get some feedback regarding a draft published by James and >Brian in Feb. 2006: > >http://www.ietf.org/internet-drafts/draft-polk-dhc-emergency-dialstring-option-00.txt > >Do we want/need such a solution? FYI -- I have -01 about to come out in the next few days. But I do not have any major changes planned since the discussion in February was centered about this ID somehow inventing a new protocol (??). I didn't understand what Henning said then, though I think I knew what he meant. He was focusing on the residential user, which I do not believe will move out of a country too often (necessitating a new dialstring download). I do see this extension to an existing mechanism being useful in an Enterprise where users from different areas travel to other in-enterprise sites. This can also be useful in more public coffee-shop type scenarios. I also see no reason why requiring a replacement of an existing, old Linksys router to take advantage of this extension should prevent it from being developed and standardized for when that router is replaced. We have the exact same issue wrt Location using this same protocol in that router... >Ciao >Hannes > >PS: Henning provided feedback some time back >http://www1.ietf.org/mail-archive/web/ecrit/current/msg01578.html >but I don't recall a conclusion. > >_______________________________________________ >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 Jun 15 15:58:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqxzO-0006u8-7j; Thu, 15 Jun 2006 15:58:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqxzN-0006u3-6k for ecrit@ietf.org; Thu, 15 Jun 2006 15:58:49 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqxzL-0004JI-UJ for ecrit@ietf.org; Thu, 15 Jun 2006 15:58:49 -0400 Received: from lion.cs.columbia.edu (IDENT:HVHGO2FOx4/RlVAOSjW/vQLI9W5pLcys@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k5FJwhX6009243 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 15 Jun 2006 15:58:44 -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 k5FJwhBB024515 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 15 Jun 2006 15:58:43 -0400 Message-ID: <4491BBED.40002@cs.columbia.edu> Date: Thu, 15 Jun 2006 15:58:37 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ecrit] draft-polk-dhc-emergency-dialstring-option-00 References: <4.3.2.7.2.20060615135503.02759d10@email.cisco.com> In-Reply-To: <4.3.2.7.2.20060615135503.02759d10@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 1.1 (+) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 re-iterate my concern, particularly based on the recent consensus in the LoST discussion: LoST will have a dialstring element which will allow to map services (sos and other) and locations to dial strings. I'm missing why we need a second mechanism. A second mechanism presumably means that all clients need to implement both since they'll never know which service will be implemented in any particular environment. (And if that isn't the case, the "environment" [ITSP, corporation, etc.] won't know which one the client is implementing, so they have to provide both.) Sometimes we need to have two means to do roughly the same thing since the requirements of different environments are so substantially different that no single solution works well in both types of environments (BGP vs. OSPF, say). This doesn't seem to be such a case. Henning James M. Polk wrote: > At 10:47 AM 6/15/2006 +0200, Hannes Tschofenig wrote: >> Hi all, >> >> I would like get some feedback regarding a draft published by James >> and Brian in Feb. 2006: >> >> http://www.ietf.org/internet-drafts/draft-polk-dhc-emergency-dialstring-option-00.txt >> >> >> Do we want/need such a solution? > > FYI -- I have -01 about to come out in the next few days. But I do not > have any major changes planned since the discussion in February was > centered about this ID somehow inventing a new protocol (??). I didn't > understand what Henning said then, though I think I knew what he meant. > He was focusing on the residential user, which I do not believe will > move out of a country too often (necessitating a new dialstring > download). I do see this extension to an existing mechanism being > useful in an Enterprise where users from different areas travel to other > in-enterprise sites. This can also be useful in more public coffee-shop > type scenarios. > > I also see no reason why requiring a replacement of an existing, old > Linksys router to take advantage of this extension should prevent it > from being developed and standardized for when that router is replaced. > We have the exact same issue wrt Location using this same protocol in > that router... > > >> Ciao >> Hannes >> >> PS: Henning provided feedback some time back >> http://www1.ietf.org/mail-archive/web/ecrit/current/msg01578.html >> but I don't recall a conclusion. >> >> _______________________________________________ >> 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 Jun 16 10:27:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFIH-0003WL-B5; Fri, 16 Jun 2006 10:27:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFIG-0003UG-Su for ecrit@ietf.org; Fri, 16 Jun 2006 10:27:28 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrFIF-0000v5-EO for ecrit@ietf.org; Fri, 16 Jun 2006 10:27:28 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k5GENQvM012942; Fri, 16 Jun 2006 08:23:26 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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] draft-polk-dhc-emergency-dialstring-option-00 Date: Fri, 16 Jun 2006 08:23:26 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-polk-dhc-emergency-dialstring-option-00 Thread-Index: AcaQtiMZFzWLR0MJSkyHbEW+RK7KsAAdibfg From: "Jean-Francois Mule" To: "Henning Schulzrinne" , "James M. Polk" X-Approved: ondar X-Spam-Score: 1.1 (+) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Both mechanisms seem to answer the same high-level requirements (Id4.) and both have pros and cons. I am not sure there has to be only one mechanism for getting the local dial string and providing some flexibility to some network operators & enterprises may help achieve the end goal: facilitate the dissemination of the local dialstring so that the UA can apply the special procedures. There are networks where the DHCP option would be an easy add-on while waiting for a ubiquitous ecrit mapping service, the finalization and implementation of the LoST protocol in UAs. Plus in some deployment architectures (3gpp for e.g.), it may be a proxy in the network that does the mapping resolution (not all UAs may have to implement LoST). DHCP also offers some advantages in enterprise environments (dial 9-911 in a US office but 0,112 in some office places in Europe). With LoST, you get the local dialstring as 911 or 112 and then the phone's dial plan needs to be applied (and localized properly...). In terms of implementation complexity, I'd say quite low on both the client and server side if support for DHCP is available: requesting an option in DHCPv4 option 55 or the DHCPv6 ORO is something all DHCP clients should have hooks for, then there is no difference between passing the returned DHCP or LoST value. Also a client knows right away whether the DHCP server supports it or not...=20 Jean-Francois. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, June 15, 2006 1:59 PM > To: James M. Polk > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] draft-polk-dhc-emergency-dialstring-option-00 >=20 > I re-iterate my concern, particularly based on the recent consensus in > the LoST discussion: LoST will have a dialstring element which will > allow to map services (sos and other) and locations to dial strings. > I'm > missing why we need a second mechanism. A second mechanism presumably > means that all clients need to implement both since they'll never know > which service will be implemented in any particular environment. (And > if > that isn't the case, the "environment" [ITSP, corporation, etc.] won't > know which one the client is implementing, so they have to provide > both.) >=20 > Sometimes we need to have two means to do roughly the same thing since > the requirements of different environments are so substantially > different that no single solution works well in both types of > environments (BGP vs. OSPF, say). This doesn't seem to be such a case. >=20 > Henning >=20 > James M. Polk wrote: > > At 10:47 AM 6/15/2006 +0200, Hannes Tschofenig wrote: > >> Hi all, > >> > >> I would like get some feedback regarding a draft published by James > >> and Brian in Feb. 2006: > >> > >> http://www.ietf.org/internet-drafts/draft-polk-dhc-emergency- > dialstring-option-00.txt > >> > >> > >> Do we want/need such a solution? > > > > FYI -- I have -01 about to come out in the next few days. But I do > not > > have any major changes planned since the discussion in February was > > centered about this ID somehow inventing a new protocol (??). I > didn't > > understand what Henning said then, though I think I knew what he > meant. > > He was focusing on the residential user, which I do not believe will > > move out of a country too often (necessitating a new dialstring > > download). I do see this extension to an existing mechanism being > > useful in an Enterprise where users from different areas travel to > other > > in-enterprise sites. This can also be useful in more public coffee- > shop > > type scenarios. > > > > I also see no reason why requiring a replacement of an existing, old > > Linksys router to take advantage of this extension should prevent it > > from being developed and standardized for when that router is > replaced. > > We have the exact same issue wrt Location using this same protocol > in > > that router... > > > > > >> Ciao > >> Hannes > >> > >> PS: Henning provided feedback some time back > >> http://www1.ietf.org/mail-archive/web/ecrit/current/msg01578.html > >> but I don't recall a conclusion. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 16 10:41:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFVp-00045G-TK; Fri, 16 Jun 2006 10:41:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFVn-000455-Tl for ecrit@ietf.org; Fri, 16 Jun 2006 10:41:27 -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 1FrFVm-0002kM-NS for ecrit@ietf.org; Fri, 16 Jun 2006 10:41:27 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Fri, 16 Jun 2006 10:36:28 -0400 id 0158801A.4492C1EC.0000596E Message-ID: <4492C1CA.2060807@hxr.us> Date: Fri, 16 Jun 2006 10:35:54 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] draft-polk-dhc-emergency-dialstring-option-00 References: <4.3.2.7.2.20060615135503.02759d10@email.cisco.com> <4491BBED.40002@cs.columbia.edu> In-Reply-To: <4491BBED.40002@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning Schulzrinne wrote: > I re-iterate my concern, particularly based on the recent consensus in > the LoST discussion: LoST will have a dialstring element which will > allow to map services (sos and other) and locations to dial strings. I'm > missing why we need a second mechanism. A second mechanism presumably > means that all clients need to implement both since they'll never know > which service will be implemented in any particular environment. (And if > that isn't the case, the "environment" [ITSP, corporation, etc.] won't > know which one the client is implementing, so they have to provide both.) > > Sometimes we need to have two means to do roughly the same thing since > the requirements of different environments are so substantially > different that no single solution works well in both types of > environments (BGP vs. OSPF, say). This doesn't seem to be such a case. I'm in agreement here with Henning. This seems to be the case where we can get away with one mechanism regardless of environment. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 19 03:55:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsEbH-0005jX-DG; Mon, 19 Jun 2006 03:55:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsEbG-0005hy-8p for ecrit@ietf.org; Mon, 19 Jun 2006 03:55:10 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsEbE-00085r-Ov for ecrit@ietf.org; Mon, 19 Jun 2006 03:55:10 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k5J7t7Cn017959 for ; Mon, 19 Jun 2006 09:55:07 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k5J7t7Tj021716 for ; Mon, 19 Jun 2006 09:55:07 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 09:55:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jun 2006 09:55:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-polk-ecrit-lost-server-uri-00.txt Thread-Index: AcaTdJBznBcs/OVlR+69GZzKsBj/dA== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 19 Jun 2006 07:55:07.0201 (UTC) FILETIME=[AE56AB10:01C69375] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Subject: [Ecrit] draft-polk-ecrit-lost-server-uri-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1749108878==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1749108878== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69375.AE10B4F3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69375.AE10B4F3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 James submitted a new draft: Learning the Initial Location-to-Service Translation (LoST) Uniform Resource Identifier (URI) During Session Initiation Protocol (SIP) Registration draft-polk-ecrit-lost-server-uri-00 Abstract A Location-to-Service Translation protocol (LoST) Server is used to=20 resolve or map a given location with an appropriate Public Safety=20 Answering Point (PSAP) Uniform Resource Identifier (URI) for that=20 location. This query is conceivably performed on two occasions:=20 prior to making an emergency call, and during an emergency call. =20 This document specifies a new Session Initiation Protocol (SIP)=20 header, returned in a SIP Registration transaction, indicating to a=20 SIP user agent the appropriate LoST Server's URI to send this query=20 to. http://www.ietf-ecrit.org/cache/draft-polk-ecrit-lost-server-uri-00.txt Ciao Hannes ------_=_NextPart_001_01C69375.AE10B4F3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-polk-ecrit-lost-server-uri-00.txt

Hi all,

James submitted a new draft:


       = Learning the Initial Location-to-Service Translation (LoST)
       = Uniform Resource Identifier (URI) During Session Initiation
         &nbs= p;            = Protocol (SIP) Registration
         &nbs= p;        = draft-polk-ecrit-lost-server-uri-00

Abstract

   A Location-to-Service = Translation protocol (LoST) Server is used to
   resolve or map a given = location with an appropriate Public Safety
   Answering Point (PSAP) = Uniform Resource Identifier (URI) for that
   location.  This = query is conceivably performed on two occasions:
   prior to making an = emergency call, and during an emergency call. 
   This document specifies a = new Session Initiation Protocol (SIP)
   header, returned in a SIP = Registration transaction, indicating to a
   SIP user agent the = appropriate LoST Server's URI to send this query
   to.


http://www.ietf-ecrit.org/cache/draft-polk-ecrit-lost-serv= er-uri-00.txt

Ciao
Hannes


------_=_NextPart_001_01C69375.AE10B4F3-- --===============1749108878== 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 --===============1749108878==-- From ecrit-bounces@ietf.org Mon Jun 19 03:55:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsEbG-0005hu-6f; Mon, 19 Jun 2006 03:55:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsEbF-0005hp-OF for ecrit@ietf.org; Mon, 19 Jun 2006 03:55:09 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsEbE-00085k-6T for ecrit@ietf.org; Mon, 19 Jun 2006 03:55:09 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k5J7t7Lh017954 for ; Mon, 19 Jun 2006 09:55:07 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k5J7t75H019241 for ; Mon, 19 Jun 2006 09:55:07 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 09:55:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jun 2006 09:55:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-polk-dhc-ecrit-uri-psap-esrp-00.txt Thread-Index: AcaTdJKmwQn8A2wjRcuOVC1Ni7a4oA== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 19 Jun 2006 07:55:07.0044 (UTC) FILETIME=[AE3EB640:01C69375] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Subject: [Ecrit] draft-polk-dhc-ecrit-uri-psap-esrp-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1965725877==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1965725877== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69375.AE098DEB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69375.AE098DEB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 James submitted a new draft: A Dynamic Host Configuration Protocol Option for Requesting and Receiving a Uniform Resource Identifier of a Public Safety Answering Point or Emergency Services Routing Proxy Abstract This document defines a new Dynamic Host Configuration Protocol=20 (DHC) Option for client requesting and/or receiving a Public Safety=20 Answering Point (PSAP) or Emergency Services Routing Proxy (ESRP)=20 URI to be used by higher layer protocols during emergency calling. =20 In some network models, an ESRP URI and a PSAP URI will be=20 equivalent from the client's point of view, therefore this document=20 purposely vague differentiating between the two, as the difference=20 does not matter to DHCP. http://www.ietf-ecrit.org/cache/draft-polk-dhc-ecrit-uri-psap-esrp-00.tx t Ciao Hannes ------_=_NextPart_001_01C69375.AE098DEB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-polk-dhc-ecrit-uri-psap-esrp-00.txt

Hi all,

James submitted a new draft:

         &nbs= p;  A Dynamic Host Configuration Protocol Option for
         = Requesting and Receiving a Uniform Resource Identifier
        of a Public = Safety Answering Point or Emergency Services
         &nbs= p;            = ;       Routing Proxy


Abstract

   This document defines a = new Dynamic Host Configuration Protocol
   (DHC) Option for client = requesting and/or receiving a Public Safety
   Answering Point (PSAP) or = Emergency Services Routing Proxy (ESRP)
   URI to be used by higher = layer protocols during emergency calling. 
   In some network models, = an ESRP URI and a PSAP URI will be
   equivalent from the = client's point of view, therefore this document
   purposely vague = differentiating between the two, as the difference
   does not matter to = DHCP.


http://www.ietf-ecrit.org/cache/draft-polk-dhc-ecrit-uri-p= sap-esrp-00.txt

Ciao
Hannes

------_=_NextPart_001_01C69375.AE098DEB-- --===============1965725877== 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 --===============1965725877==-- From ecrit-bounces@ietf.org Mon Jun 19 03:55:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsEbH-0005kB-JM; Mon, 19 Jun 2006 03:55:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsEbG-0005iB-PJ for ecrit@ietf.org; Mon, 19 Jun 2006 03:55:10 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsEbF-00085t-9s for ecrit@ietf.org; Mon, 19 Jun 2006 03:55:10 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k5J7t8LO017966 for ; Mon, 19 Jun 2006 09:55:08 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k5J7t7Tn021716 for ; Mon, 19 Jun 2006 09:55:08 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 09:55:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jun 2006 09:55:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-polk-dhc-ecrit-lost-server-uri-00.txt Thread-Index: AcaTdI8vtA6Q2IzUQVOzXe24ifEqwg== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 19 Jun 2006 07:55:07.0482 (UTC) FILETIME=[AE818BA0:01C69375] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Subject: [Ecrit] draft-polk-dhc-ecrit-lost-server-uri-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2135729531==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============2135729531== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69375.AE1F0303" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69375.AE1F0303 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 James submitted a new draft: A Dynamic Host Configuration Protocol Option for Requesting and Receiving a Uniform Resource Identifier for a Location-to-Service Translation (LoST) Server Abstract This document defines a new Dynamic Host Configuration Protocol=20 (DHC) Option to deliver a Location-to-Service Translation (LoST)=20 Protocol URI to a client. This SIP(S)-URI will be become the=20 destination URI in any call set-up message to a Public Safety=20 Answering Point (PSAP) in times of an emergency. http://www.ietf-ecrit.org/cache/draft-polk-dhc-ecrit-lost-server-uri-00. txt Ciao Hannes ------_=_NextPart_001_01C69375.AE1F0303 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-polk-dhc-ecrit-lost-server-uri-00.txt

Hi all,

James submitted a new draft:


         &nbs= p;  A Dynamic Host Configuration Protocol Option for
         = Requesting and Receiving a Uniform Resource Identifier
         &nbs= p; for a Location-to-Service Translation (LoST) Server


Abstract

   This document defines a = new Dynamic Host Configuration Protocol
   (DHC) Option to deliver a = Location-to-Service Translation (LoST)
   Protocol URI to a = client.  This SIP(S)-URI will be become the
   destination URI in any = call set-up message to a Public Safety
   Answering Point (PSAP) in = times of an emergency.

http://www.ietf-ecrit.org/cache/draft-polk-dhc-ecrit-lost-= server-uri-00.txt


Ciao
Hannes


------_=_NextPart_001_01C69375.AE1F0303-- --===============2135729531== 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 --===============2135729531==-- From ecrit-bounces@ietf.org Mon Jun 19 04:14:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsEuI-00065b-PP; Mon, 19 Jun 2006 04:14:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsEuI-00065U-AG for ecrit@ietf.org; Mon, 19 Jun 2006 04:14:50 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsEuG-00018z-Se for ecrit@ietf.org; Mon, 19 Jun 2006 04:14:50 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k5J8Elqn012009 for ; Mon, 19 Jun 2006 10:14:47 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k5J8EkCD010215 for ; Mon, 19 Jun 2006 10:14:47 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 10:14:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Jun 2006 10:14:39 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LoST: A Location-to-Service Translation Protocol Thread-Index: AcaTeEDnsKc1pdTCS4CAcPZ6/V9/zAAAArow From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 19 Jun 2006 08:14:46.0852 (UTC) FILETIME=[6D772040:01C69378] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ecrit] LoST: A Location-to-Service Translation Protocol X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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,=20 LoST was submitted.=20 Abstract=20 This document describes an XML-based protocol for mapping service identifiers and geospatial or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate PSAP for emergency services. http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-lost-00.txt Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 19 09:36:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsJvB-0001OC-Di; Mon, 19 Jun 2006 09:36:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsJvA-0001O0-EE for ecrit@ietf.org; Mon, 19 Jun 2006 09:36:04 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FsJv7-0001ai-Vz for ecrit@ietf.org; Mon, 19 Jun 2006 09:36:04 -0400 Received: (qmail invoked by alias); 19 Jun 2006 13:36:00 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp017) with SMTP; 19 Jun 2006 15:36:00 +0200 X-Authenticated: #29516787 Message-ID: <4496A83B.8070002@gmx.net> Date: Mon, 19 Jun 2006 15:35:55 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Ecrit] Framework for Emergency Calling in Internet Multimedia X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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, as part of the ECRIT architecture design team the following draft was produced: Title Framework for Emergency Calling in Internet Multimedia Abstract Summoning emergency help by the public is a core feature of telephone networks. This document describes a framework of how various IETF protocols 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. The draft can be found at: http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-emergency-framework-00.txt http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-emergency-framework-00.html The design team mailing list can be found at: https://zeke.ecotroph.net/mailman/listinfo/ecrit-arch The chairs would particularly like to the thank Brian, James, Henning and Andy for their draft editing work. Furthermore, the chairs would also like to thank the entire design team members for their work. Brian and James are leading the design team and will continue the design team activity. Discussions about the next steps will be discussed in Montreal. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 19 19:02:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsSbz-0000O7-Uh; Mon, 19 Jun 2006 18:52:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsSZT-0003ro-Gi for ecrit@ietf.org; Mon, 19 Jun 2006 18:50:15 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsSZR-00044N-3p for ecrit@ietf.org; Mon, 19 Jun 2006 18:50:15 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 17:50:12 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 19 Jun 2006 17:50:12 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 17:50:45 -0500 Message-ID: From: "Winterbottom, James" To: "Tschofenig, Hannes" , Date: Mon, 19 Jun 2006 17:50:43 -0500 Subject: RE: [Ecrit] draft-polk-dhc-ecrit-lost-server-uri-00.txt MIME-Version: 1.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 19 Jun 2006 22:50:45.0804 (UTC) FILETIME=[CD0ABEC0:01C693F2] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] draft-polk-dhc-ecrit-lost-server-uri-00.txt Thread-Index: AcaTdI8vtA6Q2IzUQVOzXe24ifEqwgAfi4tA X-Spam-Score: 0.1 (/) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb 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="===============0725352917==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0725352917== Content-Type: multipart/alternative; boundary="--=_NextPart_ST_17_50_12_Monday_June_19_2006_22526" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ----=_NextPart_ST_17_50_12_Monday_June_19_2006_22526 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It seems that the actual link to this document is: =20 http://www.ietf-ecrit.org/cache/draft-polk-dhc-ecrit-lost-server-uri-00. txt.txt =20 =20 =20 ________________________________ From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 Sent: Monday, 19 June 2006 5:55 PM To: ecrit@ietf.org Subject: [Ecrit] draft-polk-dhc-ecrit-lost-server-uri-00.txt =20 Hi all,=20 James submitted a new draft:=20 =20 A Dynamic Host Configuration Protocol Option for=20 Requesting and Receiving a Uniform Resource Identifier=20 for a Location-to-Service Translation (LoST) Server=20 =20 Abstract=20 This document defines a new Dynamic Host Configuration Protocol=20 (DHC) Option to deliver a Location-to-Service Translation (LoST)=20 Protocol URI to a client. This SIP(S)-URI will be become the=20 destination URI in any call set-up message to a Public Safety=20 Answering Point (PSAP) in times of an emergency.=20 http://www.ietf-ecrit.org/cache/draft-polk-dhc-ecrit-lost-server-uri-00. txt =20 =20 Ciao=20 Hannes=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] ----=_NextPart_ST_17_50_12_Monday_June_19_2006_22526 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-polk-dhc-ecrit-lost-server-uri-00.txt

It seems that the actual link to this document is:

 

http://www.ietf-ecrit.org/cache/draft-polk-dhc-ecrit-lost-ser= ver-uri-00.txt.txt

 

 

 

From: Tschofen= ig, Hannes [mailto:hannes.tschofenig@siemens.com]
Sent: Monday, 19 June 2006 5= :55 PM
To: ecrit@ietf.org
Subject: [Ecrit] draft-polk-dhc-ecrit-lost-server-uri-00.txt

 

Hi all,

James submitted a new draft:

 

            A Dynamic Host Configuration Protocol Option for
         Requesting and Receiving a Uniform Resource Identifier
           for a Location-to-Service Translation (LoST) Server

 

Abstract

   This document defines a new Dynamic Host Configuration Protocol
   (DHC) Option to deliver a Location-to-Service Translation (LoST)
   Protocol URI to a client.  This SIP(S)-URI will be become the <= /font>
   destination URI in any call set-up message to a Public Safety
   Answering Point (PSAP) in times of an emergency. <= /p>

ht= tp://www.ietf-ecrit.org/cache/draft-polk-dhc-ecrit-lost-server-uri-00.txt

 

Ciao
Hannes

 


-----------------------------------------------------------------------= -------------------------
This message is for the designated recipient o= nly and may
contain privileged, proprietary, or otherwise private inform= ation.
If you have received it in error, please notify the sender
i= mmediately and delete the original. Any unauthorized use of
this email = is prohibited.
---------------------------------------------------------= ---------------------------------------
[mf2] ----=_NextPart_ST_17_50_12_Monday_June_19_2006_22526-- --===============0725352917== 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 --===============0725352917==-- From ecrit-bounces@ietf.org Mon Jun 19 19:47:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTSw-0004jf-WA; Mon, 19 Jun 2006 19:47:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTSv-0004gj-Ke for ecrit@ietf.org; Mon, 19 Jun 2006 19:47:33 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsTSu-0002Yf-AT for ecrit@ietf.org; Mon, 19 Jun 2006 19:47:33 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5JNlTog022596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Jun 2006 16:47:30 -0700 Received: from [129.46.225.24] (dhcp-campbell-28.qualcomm.com [129.46.225.24]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5JNlRV0027315; Mon, 19 Jun 2006 16:47:28 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 19 Jun 2006 16:47:26 -0700 To: "Winterbottom, James" , "Tschofenig, Hannes" , From: Ted Hardie Subject: RE: [Ecrit] draft-polk-dhc-ecrit-lost-server-uri-00.txt Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 5:50 PM -0500 6/19/06, Winterbottom, James wrote: >Content-Type: multipart/alternative; > boundary="--=_NextPart_ST_17_50_12_Monday_June_19_2006_22526" >Content-class: urn:content-classes:message > >It seems that the actual link to this document is: > >http://www.ietf-ecrit.org/cache/draft-polk-dhc-ecrit-lost-server-uri-00.txt.txt > > Do you think the LoST protocol draft should define a URI scheme, then, or should we do that in an independent draft? Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 19 19:50:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTVe-0006ab-Tl; Mon, 19 Jun 2006 19:50:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTVd-0006aW-7z for ecrit@ietf.org; Mon, 19 Jun 2006 19:50:21 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsTVc-0002d2-0Z for ecrit@ietf.org; Mon, 19 Jun 2006 19:50:21 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 18:50:19 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 19 Jun 2006 18:50:18 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 18:50:52 -0500 Message-ID: From: "Winterbottom, James" To: "Ted Hardie" , "Tschofenig, Hannes" , Date: Mon, 19 Jun 2006 18:50:49 -0500 Subject: RE: [Ecrit] draft-polk-dhc-ecrit-lost-server-uri-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 19 Jun 2006 23:50:52.0732 (UTC) FILETIME=[32F047C0:01C693FB] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] draft-polk-dhc-ecrit-lost-server-uri-00.txt Thread-Index: AcaT+rvXURbAjfh6RoiiI47ReIZ2kQAAGiNQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think that the thread would be easier to follow if it were in the LoST protocol draft. > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Tuesday, 20 June 2006 9:47 AM > To: Winterbottom, James; Tschofenig, Hannes; ecrit@ietf.org > Subject: RE: [Ecrit] draft-polk-dhc-ecrit-lost-server-uri-00.txt >=20 > At 5:50 PM -0500 6/19/06, Winterbottom, James wrote: > >Content-Type: multipart/alternative; > > boundary=3D"--=3D_NextPart_ST_17_50_12_Monday_June_19_2006_22526" > >Content-class: urn:content-classes:message > > > >It seems that the actual link to this document is: > > > > 00.txt.txt>http://www.ietf-ecrit.org/cache/draft-polk-dhc-ecrit-lost- > server-uri-00.txt.txt > > > > >=20 > Do you think the LoST protocol draft should define a URI scheme, then, or > should we do that in an independent draft? > Ted ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 20 15:50:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsmFH-0002dD-SI; Tue, 20 Jun 2006 15:50:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsmEe-0001SR-5S; Tue, 20 Jun 2006 15:50: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 1FsmEe-0003UG-2z; Tue, 20 Jun 2006 15:50:04 -0400 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FsmEc-0003Xp-Jj; Tue, 20 Jun 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5KJo2Hp001308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FsmEc-0003bU-3a; Tue, 20 Jun 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, 20 Jun 2006 15:50:02 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-lost-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 : LoST: A Location-to-Service Translation Protocol Author(s) : T. Hardie, et al. Filename : draft-ietf-ecrit-lost-00.txt Pages : 31 Date : 2006-6-20 This document describes an XML-based protocol for mapping service identifiers and geospatial 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-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-lost-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-lost-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-6-20115005.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-lost-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-lost-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-20115005.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 Jun 21 09:57:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3Ce-0000yk-JL; Wed, 21 Jun 2006 09:57:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3Cd-0000yf-Ji for ecrit@ietf.org; Wed, 21 Jun 2006 09:57:07 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft3Cc-0006Or-81 for ecrit@ietf.org; Wed, 21 Jun 2006 09:57:07 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1Ft3Cb1vD7-0001Cm; Wed, 21 Jun 2006 15:57:05 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Wed, 21 Jun 2006 13:52:20 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1150897940.3.0.0589902861765.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: 93238566e09e6e262849b4f805833007 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 New submission from Hannes Tschofenig : Ted wrote: We've talked in the past about the protocol providing a pointer to other Lo= ST=20 servers if it is not the appropriate responder. We need to set out the=20 semantics of that (i.e., is it a "plain" referral, or does it contain any o= f=20 the reasons for why the referral occurred). ---------- assignedto: hannes messages: 26 nosy: ecrit, hannes priority: critical status: chatting title: Referral Protocol Mechanisms __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 21 10:04:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3JJ-0004Zk-UL; Wed, 21 Jun 2006 10:04:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3JI-0004Zf-J5 for ecrit@ietf.org; Wed, 21 Jun 2006 10:04:00 -0400 Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft3JH-0006oQ-6n for ecrit@ietf.org; Wed, 21 Jun 2006 10:04:00 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1Ft3JG1szO-0001Dl; Wed, 21 Jun 2006 16:03:58 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Wed, 21 Jun 2006 13:59:08 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1150898348.32.0.677981010753.issue12@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: 97adf591118a232206bdb5a27b217034 Subject: [Ecrit] [issue12] Validation Response 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 New submission from Hannes Tschofenig : Ted wrote:=20 > I think it we be good to update the validate response so that it > is not a concatenation; I think that will be harder to use than a > response which lists the elements independently. Hannes: Do you have the following change in mind:=20 country A1 A3 A6 PC to country A1 A3 A6 PC ---------- assignedto: hannes messages: 27 nosy: ecrit, hannes priority: critical status: chatting title: Validation Response __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 21 10:05:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3Kd-00050z-Gq; Wed, 21 Jun 2006 10:05:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3Kd-00050p-0C for ecrit@ietf.org; Wed, 21 Jun 2006 10:05:23 -0400 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft3Kb-0007FH-JW for ecrit@ietf.org; Wed, 21 Jun 2006 10:05:22 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1Ft3Kb0Krl-00045N; Wed, 21 Jun 2006 16:05:21 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Wed, 21 Jun 2006 14:00:35 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1150898435.98.0.429977726683.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: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ecrit] [issue2] Is it allowed to specify civic and geospatial info into the query? 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: The composite location aspect is not yet addressed in the -00 draft version (geo +civic/civic+geo). __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 21 10:07:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3N2-0006c7-CW; Wed, 21 Jun 2006 10:07:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3N0-0006bo-96 for ecrit@ietf.org; Wed, 21 Jun 2006 10:07:50 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft3My-0007IV-SN for ecrit@ietf.org; Wed, 21 Jun 2006 10:07:50 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1Ft3My1TyI-0001q8; Wed, 21 Jun 2006 16:07:48 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Wed, 21 Jun 2006 14:03:03 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1150898583.21.0.136809043482.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] Dial Strings 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: Currently a separate dialstring element is specified in the -00 draft versi= on. Is the KPML dialstring notation useful? __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 21 10:08:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3Np-0000MH-M5; Wed, 21 Jun 2006 10:08:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3No-0000FX-C0 for ecrit@ietf.org; Wed, 21 Jun 2006 10:08:40 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft3Nm-0007Jr-V9 for ecrit@ietf.org; Wed, 21 Jun 2006 10:08:40 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1Ft3Nm1fYT-0007j6; Wed, 21 Jun 2006 16:08:38 +0200 Content-Type: text/plain; charset=utf-8 To: ecrit@ietf.org From: Hannes Tschofenig Date: Wed, 21 Jun 2006 14:03:53 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1150898633.3.0.688169640644.issue13@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: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ecrit] [issue13] XML Schema vs. Relax NG 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 New submission from Hannes Tschofenig : Draft version -00 contains an XML schema.=20 Would it be useful to switch to Relax NG? ---------- assignedto: hannes messages: 30 nosy: ecrit, hannes priority: critical status: chatting title: XML Schema vs. Relax NG __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 21 11:53:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft50n-00050u-7s; Wed, 21 Jun 2006 11:53:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft50m-00050p-El for Ecrit@ietf.org; Wed, 21 Jun 2006 11:53:00 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft50l-0002RY-8U for Ecrit@ietf.org; Wed, 21 Jun 2006 11:53:00 -0400 Received: by py-out-1112.google.com with SMTP id c31so1889515pyd for ; Wed, 21 Jun 2006 08:52:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=msGmXvNJEFPeAsKh1PyMtSsug797RfyVEIvJBp95mX3aVjGA6VcdeerMP1Iqg7zOXH4FKYLZGMlbr4/qH8zMuPUuK4cBJ/FFYfNuORkOWF3TOOs4A3fLFAH4UcPidyxZyNM15Bib8ZfL3Bw7CRnmmGz5iUxt4TnYwTZneOpcaBM= Received: by 10.35.14.1 with SMTP id r1mr11171786pyi; Wed, 21 Jun 2006 08:52:58 -0700 (PDT) Received: by 10.35.81.17 with HTTP; Wed, 21 Jun 2006 08:52:58 -0700 (PDT) Message-ID: <953beacc0606210852o10f37476x19c0e9494c6f6097@mail.gmail.com> Date: Wed, 21 Jun 2006 08:52:58 -0700 From: "Rohan Mahy" To: Ecrit@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Subject: [Ecrit] beagle honored for calling 911 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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 for the off-topic post, but I couldn't resist: http://www.npr.org/templates/story/story.php?storyId=5497564 thanks, -rohan _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 21 12:11:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5In-0008OL-Gr; Wed, 21 Jun 2006 12:11:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5Il-0008EI-LQ for Ecrit@ietf.org; Wed, 21 Jun 2006 12:11:35 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft5Gw-0004Fy-6m for Ecrit@ietf.org; Wed, 21 Jun 2006 12:09:45 -0400 Received: from lion.cs.columbia.edu (IDENT:w4cJl9kVR7+pWC0Y2HWAyVNEQU0jRKLc@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k5LG9KSM005162 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 21 Jun 2006 12:09:34 -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 k5LG9IBB020442 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 21 Jun 2006 12:09:19 -0400 Message-ID: <44996F29.4040006@cs.columbia.edu> Date: Wed, 21 Jun 2006 12:09:13 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Ecrit] beagle honored for calling 911 References: <953beacc0606210852o10f37476x19c0e9494c6f6097@mail.gmail.com> In-Reply-To: <953beacc0606210852o10f37476x19c0e9494c6f6097@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Actually, it's very much on topic. It shows that single-button "SOS" invocation does have its advantages. I don't think Belle would have been able to negotiate a "did you really mean to call 911" menu option :-) Rohan Mahy wrote: > Apologies for the off-topic post, but I couldn't resist: > > http://www.npr.org/templates/story/story.php?storyId=5497564 > > thanks, > -rohan > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 21 12:52:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5wc-0002Kt-HM; Wed, 21 Jun 2006 12:52:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5wc-0002Ko-5H for Ecrit@ietf.org; Wed, 21 Jun 2006 12:52:46 -0400 Received: from imo-d04.mx.aol.com ([205.188.157.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft5wa-0001vY-UQ for Ecrit@ietf.org; Wed, 21 Jun 2006 12:52:46 -0400 Received: from FrancisDomoney@aol.com by imo-d04.mx.aol.com (mail_out_v38_r7.5.) id 7.31e.5bf1199 (29678); Wed, 21 Jun 2006 12:48:47 -0400 (EDT) From: FrancisDomoney@aol.com Message-ID: <31e.5bf1199.31cad26d@aol.com> Date: Wed, 21 Jun 2006 12:48:45 EDT Subject: Re: [Ecrit] beagle honored for calling 911 To: hgs@cs.columbia.edu, rohan.mahy@gmail.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5011 X-Spam-Flag: NO X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0177920256==" Errors-To: ecrit-bounces@ietf.org --===============0177920256== Content-Type: multipart/alternative; boundary="-----------------------------1150908525" -------------------------------1150908525 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Guys We looked at single button emergency calling when we were buidling early mobile networks in UK. Phones in briefcases drive the emergency servcies nuts by accidentally calling them. Worse still it ties up channels and causes the emergency services to congest. Regards Frank Domoney -------------------------------1150908525 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Guys
 
We looked at single button emergency calling when we were buidling earl= y=20 mobile networks in UK.
 
Phones in briefcases drive the emergency servcies nuts by accidentally=20 calling them.
 
Worse still it ties up channels and causes the emergency services to=20 congest.
 
Regards
 
Frank Domoney
 -------------------------------1150908525-- --===============0177920256== 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 --===============0177920256==-- From ecrit-bounces@ietf.org Wed Jun 21 14:39:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft7c7-0004q3-NL; Wed, 21 Jun 2006 14:39:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft7c7-0004ms-0G for Ecrit@ietf.org; Wed, 21 Jun 2006 14:39:43 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft7c4-0002qL-JS for Ecrit@ietf.org; Wed, 21 Jun 2006 14:39:42 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Ft7bv-0002Af-Jd; Wed, 21 Jun 2006 13:39:32 -0500 From: "Brian Rosen" To: , , Subject: RE: [Ecrit] beagle honored for calling 911 Date: Wed, 21 Jun 2006 14:39:33 -0400 Message-ID: <00ad01c69562$0d040a20$b801a8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <31e.5bf1199.31cad26d@aol.com> Thread-Index: AcaVUx7oaOO4wuDXQKug3oj1eL9MLAADqUkg 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: 9f79b8e383fd3af2b1b5b1d0910f6094 Cc: Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0782357634==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0782357634== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AE_01C69540.85F26A20" This is a multi-part message in MIME format. ------=_NextPart_000_00AE_01C69540.85F26A20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Single button emergency call is a big no-no. There have been several waves of such things, all dramatically bad. I'm not sure if button plus confirmation would work. In theory, it would, but when you are stressed, the confirmation may cause more problems than it is worth. Brian _____ From: FrancisDomoney@aol.com [mailto:FrancisDomoney@aol.com] Sent: Wednesday, June 21, 2006 12:49 PM To: hgs@cs.columbia.edu; rohan.mahy@gmail.com Cc: Ecrit@ietf.org Subject: Re: [Ecrit] beagle honored for calling 911 Guys We looked at single button emergency calling when we were buidling early mobile networks in UK. Phones in briefcases drive the emergency servcies nuts by accidentally calling them. Worse still it ties up channels and causes the emergency services to congest. Regards Frank Domoney ------=_NextPart_000_00AE_01C69540.85F26A20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Single button emergency call is a = big no-no.  There have been several waves of such things, all = dramatically bad. 

 

I’m not sure if button plus confirmation would work.  In theory, it would, but when you are = stressed, the confirmation may cause more problems than it is = worth.

 

Brian

 

From: FrancisDomoney@aol.com [mailto:FrancisDomoney@aol.com]
Sent: Wednesday, June 21, = 2006 12:49 PM
To: hgs@cs.columbia.edu; rohan.mahy@gmail.com
Cc: Ecrit@ietf.org
Subject: Re: [Ecrit] = beagle honored for calling 911

 

Guys

 

=

We looked at single button = emergency calling when we were buidling early mobile networks in = UK.=

 

=

Phones in briefcases drive the = emergency servcies nuts by accidentally calling them.

 

=

Worse still it ties up channels = and causes the emergency services to congest.

 

=

Regards

 

=

Frank = Domoney

------=_NextPart_000_00AE_01C69540.85F26A20-- --===============0782357634== 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 --===============0782357634==-- From ecrit-bounces@ietf.org Wed Jun 21 14:47:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft7ja-0001xm-7t; Wed, 21 Jun 2006 14:47:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft7jY-0001xh-Gj for Ecrit@ietf.org; Wed, 21 Jun 2006 14:47:24 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft7jV-0004L3-02 for Ecrit@ietf.org; Wed, 21 Jun 2006 14:47:24 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 21 Jun 2006 11:47:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] beagle honored for calling 911 Date: Wed, 21 Jun 2006 11:47:19 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657505313919@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] beagle honored for calling 911 Thread-Index: AcaVUx7oaOO4wuDXQKug3oj1eL9MLAADqUkgAABQhzA= From: "Roger Marshall" To: "Brian Rosen" , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0740228869==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0740228869== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69563.1FB7DACC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69563.1FB7DACC Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Then, I guess this fellow would have to say: bad dog! ________________________________ From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, June 21, 2006 11:40 AM To: FrancisDomoney@aol.com; hgs@cs.columbia.edu; rohan.mahy@gmail.com Cc: Ecrit@ietf.org Subject: RE: [Ecrit] beagle honored for calling 911 =09 =09 Single button emergency call is a big no-no. There have been several waves of such things, all dramatically bad. =20 =20 I'm not sure if button plus confirmation would work. In theory, it would, but when you are stressed, the confirmation may cause more problems than it is worth. =20 Brian =20 =09 ________________________________ From: FrancisDomoney@aol.com [mailto:FrancisDomoney@aol.com]=20 Sent: Wednesday, June 21, 2006 12:49 PM To: hgs@cs.columbia.edu; rohan.mahy@gmail.com Cc: Ecrit@ietf.org Subject: Re: [Ecrit] beagle honored for calling 911 =20 Guys =20 We looked at single button emergency calling when we were buidling early mobile networks in UK. =20 Phones in briefcases drive the emergency servcies nuts by accidentally calling them. =20 Worse still it ties up channels and causes the emergency services to congest. =20 Regards =20 Frank Domoney ------_=_NextPart_001_01C69563.1FB7DACC Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Then, I guess this fellow would have to say: = bad=20 dog!

From: Brian Rosen = [mailto:br@brianrosen.net]=20
Sent: Wednesday, June 21, 2006 11:40 AM
To:=20 FrancisDomoney@aol.com; hgs@cs.columbia.edu;=20 rohan.mahy@gmail.com
Cc: Ecrit@ietf.org
Subject: = RE:=20 [Ecrit] beagle honored for calling 911

Single = button=20 emergency call is a big no-no.  There have been several waves of = such=20 things, all dramatically bad. 

 

I’m = not sure if=20 button plus confirmation would work.  In theory, it would, but = when you=20 are stressed, the confirmation may cause more problems than it is=20 worth.

 

Brian

 

From:=20 FrancisDomoney@aol.com [mailto:FrancisDomoney@aol.com]
Sent: Wednesday, June 21, 2006 = 12:49=20 PM
To: = hgs@cs.columbia.edu;=20 rohan.mahy@gmail.com
Cc:=20 Ecrit@ietf.org
Subject: Re:=20 [Ecrit] beagle honored for calling = 911

 

Guys

 

We looked = at single=20 button emergency calling when we were buidling early mobile networks = in=20 UK.=

 

Phones in = briefcases=20 drive the emergency servcies nuts by accidentally calling=20 them.

 

Worse = still it ties=20 up channels and causes the emergency services to=20 congest.

 

Regards

 

Frank=20 = Domoney

------_=_NextPart_001_01C69563.1FB7DACC-- --===============0740228869== 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 --===============0740228869==-- From ecrit-bounces@ietf.org Wed Jun 21 15:13:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft88t-0001uU-AH; Wed, 21 Jun 2006 15:13:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft88r-0001uP-US for Ecrit@ietf.org; Wed, 21 Jun 2006 15:13:33 -0400 Received: from imo-m28.mx.aol.com ([64.12.137.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft88q-0007Tg-Jv for Ecrit@ietf.org; Wed, 21 Jun 2006 15:13:33 -0400 Received: from Rockford9@aol.com by imo-m28.mx.aol.com (mail_out_v38_r7.5.) id w.215.179329fb (33856); Wed, 21 Jun 2006 15:12:56 -0400 (EDT) From: Rockford9@aol.com Message-ID: <215.179329fb.31caf437@aol.com> Date: Wed, 21 Jun 2006 15:12:55 EDT Subject: Re: [Ecrit] beagle honored for calling 911 To: br@brianrosen.net, FrancisDomoney@aol.com, hgs@cs.columbia.edu, rohan.mahy@gmail.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5026 X-Spam-Flag: NO X-Spam-Score: 0.2 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1698706678==" Errors-To: ecrit-bounces@ietf.org --===============1698706678== Content-Type: multipart/alternative; boundary="-----------------------------1150917175" -------------------------------1150917175 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: en =20 What is bad is to program devices to automatically have a one-button access=20= =20 feature, whether a customer wants or even knows it is there. =20 There are justifications for having a programmable feature with =20 communications devices for setting such. This story is a good example of on= e. =20 As with many things, deciding everything should just be one way or another =20 with no possible middle ground in certain instances, may not be best approa= ch. =20 Rick =20 In a message dated 6/21/2006 2:40:13 PM Eastern Daylight Time, =20 br@brianrosen.net writes: =20 Single button emergency call is a big no-no. There have been several waves= =20 of such things, all dramatically bad. =20 I=E2=80=99m not sure if button plus confirmation would work. In theory, it= would,=20 but when you are stressed, the confirmation may cause more problems than it= is=20 worth.=20 Brian=20 =20 =20 ____________________________________ =20 From: FrancisDomoney@aol.com [mailto:FrancisDomoney@aol.com]=20 Sent: Wednesday, June 21, 2006 12:49 PM To: hgs@cs.columbia.edu; rohan.mahy@gmail.com Cc: Ecrit@ietf.org Subject: Re: [Ecrit] beagle honored for calling 911 =20 =20 Guys =20 =20 We looked at single button emergency calling when we were buidling early=20 mobile networks in UK. =20 =20 Phones in briefcases drive the emergency servcies nuts by accidentally=20 calling them. =20 =20 Worse still it ties up channels and causes the emergency services to =20 congest. =20 =20 Regards =20 =20 Frank Domoney _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit -------------------------------1150917175 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: en
What is bad is to program devices to automatically have a one-button ac= cess=20 feature, whether a customer wants or even knows it is there.
 
There are justifications for having a programmable feature with=20 communications devices for setting such. This story is a good example of=20 one.
 
As with many things, deciding everything should just be one way or anot= her=20 with no possible middle ground in certain instances, may not be best=20 approach.
 
Rick
 
In a message dated 6/21/2006 2:40:13 PM Eastern Daylight Time,=20 br@brianrosen.net writes:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>

Single button=20 emergency call is a big no-no.  There have been several waves of such= =20 things, all dramatically bad. 

 

I=E2=80=99m not= sure if=20 button plus confirmation would work.  In theory, it would, but when y= ou=20 are stressed, the confirmation may cause more problems than it is=20 worth.

 

Brian

 

From:Sent: Wednesday, June 21, 2006 12:4= 9=20 PM
To: hgs@cs.columbia.= edu;=20 rohan.mahy@gmail.com
Cc:=20 Ecrit@ietf.org
Subject:= Re:=20 [Ecrit] beagle honored for calling 911

 

Guys

 

We looked at s= ingle=20 button emergency calling when we were buidling early mobile networks in=20 UK.<= /P>

 

Phones in brie= fcases=20 drive the emergency servcies nuts by accidentally calling=20 them.

 

Worse still it= ties=20 up channels and causes the emergency services to=20 congest.

 

Regards

 

Frank=20 Domoney



____________= ___________________________________
Ecrit=20 mailing=20 list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit
=
 
-------------------------------1150917175-- --===============1698706678== 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 --===============1698706678==-- From ecrit-bounces@ietf.org Wed Jun 21 18:09:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtAsk-0003ck-7z; Wed, 21 Jun 2006 18:09:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtAsi-0003XZ-Vm for ecrit@ietf.org; Wed, 21 Jun 2006 18:09:04 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtAsh-0003Ok-Ne for ecrit@ietf.org; Wed, 21 Jun 2006 18:09:04 -0400 Received: from lion.cs.columbia.edu (IDENT:vDOFZ1axoyg7HbXwYqNPzZO+ngv/px0d@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k5LM5ISM007478 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 21 Jun 2006 18:09:03 -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 k5LM5FBB010715 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 21 Jun 2006 18:05:16 -0400 Message-ID: <4499C296.7080202@cs.columbia.edu> Date: Wed, 21 Jun 2006 18:05:10 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: LoST Issue Tracker Subject: Re: [Ecrit] [issue11] Referral Protocol Mechanisms References: <1150897940.3.0.0589902861765.issue11@http://www.tschofenig.priv.at> In-Reply-To: <1150897940.3.0.0589902861765.issue11@http://www.tschofenig.priv.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org There are probably two ways to do this: (1) The response simply contains a domain name that is then resolved in the same S-NAPTR fashion as before; no new URL schema is needed. (2) We define a URL schema. However, a URL makes sense mostly if it is self-sufficient, rather than just specifying the server. Just clicking on lost:server.example.com isn't too useful and doesn't really define a resource. The reason indication seems to be orthogonal to this; a mechanism similar to SIP and HTTP, with numeric and textual reason codes should be able to address this across the spectrum of responses. Hannes Tschofenig wrote: > New submission from Hannes Tschofenig : > > Ted wrote: > > We've talked in the past about the protocol providing a pointer to other LoST > servers if it is not the appropriate responder. We need to set out the > semantics of that (i.e., is it a "plain" referral, or does it contain any of > the reasons for why the referral occurred). > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 22 02:05:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtIJf-0002E1-Tt; Thu, 22 Jun 2006 02:05:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtIJe-0002Dw-Jc for ecrit@ietf.org; Thu, 22 Jun 2006 02:05:22 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtIJc-00048U-AQ for ecrit@ietf.org; Thu, 22 Jun 2006 02:05:22 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Jun 2006 23:05:20 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,164,1149490800"; d="scan'208"; a="30208522:sNHT22989924" 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 k5M65Hno023713; Thu, 22 Jun 2006 02:05:17 -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.211); Thu, 22 Jun 2006 02:05:17 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.70]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Jun 2006 02:05:16 -0400 Message-Id: <4.3.2.7.2.20060622010414.02999628@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Jun 2006 01:05:15 -0500 To: "Winterbottom, James" , "Ted Hardie" , "Tschofenig, Hannes" , From: "James M. Polk" Subject: RE: [Ecrit] draft-polk-dhc-ecrit-lost-server-uri-00.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 22 Jun 2006 06:05:16.0999 (UTC) FILETIME=[D582E570:01C695C1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 06:50 PM 6/19/2006 -0500, Winterbottom, James wrote: >I think that the thread would be easier to follow if it were in the LoST >protocol draft. James - I do not understand this comment. Can you rephrase it please? > > -----Original Message----- > > From: Ted Hardie [mailto:hardie@qualcomm.com] > > Sent: Tuesday, 20 June 2006 9:47 AM > > To: Winterbottom, James; Tschofenig, Hannes; ecrit@ietf.org > > Subject: RE: [Ecrit] draft-polk-dhc-ecrit-lost-server-uri-00.txt > > > > At 5:50 PM -0500 6/19/06, Winterbottom, James wrote: > > >Content-Type: multipart/alternative; > > > boundary="--=_NextPart_ST_17_50_12_Monday_June_19_2006_22526" > > >Content-class: urn:content-classes:message > > > > > >It seems that the actual link to this document is: > > > > > > > > 00.txt.txt>http://www.ietf-ecrit.org/cache/draft-polk-dhc-ecrit-lost- > > server-uri-00.txt.txt > > > > > > > > > > Do you think the LoST protocol draft should define a URI scheme, then, >or > > should we do that in an independent draft? > > Ted > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 22 02:14:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtISe-0001R0-Dt; Thu, 22 Jun 2006 02:14:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtISd-0001Qu-Kj for ecrit@ietf.org; Thu, 22 Jun 2006 02:14:39 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtISb-0004e9-BD for ecrit@ietf.org; Thu, 22 Jun 2006 02:14:39 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 01:15:11 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 22 Jun 2006 01:15:11 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 01:15:11 -0500 Message-ID: From: "Winterbottom, James" To: "James M. Polk" , "Ted Hardie" , "Tschofenig, Hannes" , Date: Thu, 22 Jun 2006 01:14:33 -0500 Subject: RE: [Ecrit] draft-polk-dhc-ecrit-lost-server-uri-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 22 Jun 2006 06:15:11.0022 (UTC) FILETIME=[37939CE0:01C695C3] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <4.3.2.7.2.20060622010414.02999628@email.cisco.com> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] draft-polk-dhc-ecrit-lost-server-uri-00.txt Thread-Index: AcaVwdj134hflWFhRzONt2bHRSffqAAAPaDQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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 Searching a single document for the things you are looking for is much easier than having to go searching through multiple documents. Unless you see that the new URI scheme is going to be massive, I suggest putting it in the same document as the LoST specification. On a separate note, for the DHCP draft, are you planning on having a section for IPv6 DHC URI discovery? Cheers James > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Thursday, 22 June 2006 4:05 PM > To: Winterbottom, James; Ted Hardie; Tschofenig, Hannes; ecrit@ietf.org > Subject: RE: [Ecrit] draft-polk-dhc-ecrit-lost-server-uri-00.txt >=20 > At 06:50 PM 6/19/2006 -0500, Winterbottom, James wrote: > >I think that the thread would be easier to follow if it were in the LoST > >protocol draft. >=20 > James - I do not understand this comment. Can you rephrase it please? >=20 >=20 >=20 > > > -----Original Message----- > > > From: Ted Hardie [mailto:hardie@qualcomm.com] > > > Sent: Tuesday, 20 June 2006 9:47 AM > > > To: Winterbottom, James; Tschofenig, Hannes; ecrit@ietf.org > > > Subject: RE: [Ecrit] draft-polk-dhc-ecrit-lost-server-uri-00.txt > > > > > > At 5:50 PM -0500 6/19/06, Winterbottom, James wrote: > > > >Content-Type: multipart/alternative; > > > > boundary=3D"--=3D_NextPart_ST_17_50_12_Monday_June_19_2006_22526" > > > >Content-class: urn:content-classes:message > > > > > > > >It seems that the actual link to this document is: > > > > > > > > > > > > 00.txt.txt>http://www.ietf-ecrit.org/cache/draft-polk-dhc-ecrit-lost- > > > server-uri-00.txt.txt > > > > > > > > > > > > > > Do you think the LoST protocol draft should define a URI scheme, then, > >or > > > should we do that in an independent draft? > > > Ted > > > >----------------------------------------------------------------------- -- > ----------------------- > >This message is for the designated recipient only and may > >contain privileged, proprietary, or otherwise private information. > >If you have received it in error, please notify the sender > >immediately and delete the original. Any unauthorized use of > >this email is prohibited. > >----------------------------------------------------------------------- -- > ----------------------- > >[mf2] > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 22 02:24:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtIbq-0000ND-Ix; Thu, 22 Jun 2006 02:24:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtIbp-0000N8-Mk for ecrit@ietf.org; Thu, 22 Jun 2006 02:24:09 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtIbn-0004zY-Cs for ecrit@ietf.org; Thu, 22 Jun 2006 02:24:09 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 22 Jun 2006 02:24:07 -0400 X-IronPort-AV: i="4.06,164,1149480000"; d="scan'208"; a="90744852:sNHT33409612" 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 k5M6O6no025886; Thu, 22 Jun 2006 02:24:06 -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.211); Thu, 22 Jun 2006 02:24:06 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.70]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Jun 2006 02:24:06 -0400 Message-Id: <4.3.2.7.2.20060622012003.03e0ff78@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Jun 2006 01:24:04 -0500 To: "Winterbottom, James" , "Ted Hardie" , "Tschofenig, Hannes" , From: "James M. Polk" Subject: RE: [Ecrit] draft-polk-dhc-ecrit-lost-server-uri-00.txt In-Reply-To: References: <4.3.2.7.2.20060622010414.02999628@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 22 Jun 2006 06:24:06.0218 (UTC) FILETIME=[76940AA0:01C695C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 01:14 AM 6/22/2006 -0500, Winterbottom, James wrote: >Searching a single document for the things you are looking for is much >easier than having to go searching through multiple documents. Unless >you see that the new URI scheme is going to be massive, I suggest >putting it in the same document as the LoST specification. That belongs in the LoST doc, and this doc will refer to that. >On a separate note, for the DHCP draft, are you planning on having a >section for IPv6 DHC URI discovery? I can. >Cheers >James > > > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Thursday, 22 June 2006 4:05 PM > > To: Winterbottom, James; Ted Hardie; Tschofenig, Hannes; >ecrit@ietf.org > > Subject: RE: [Ecrit] draft-polk-dhc-ecrit-lost-server-uri-00.txt > > > > At 06:50 PM 6/19/2006 -0500, Winterbottom, James wrote: > > >I think that the thread would be easier to follow if it were in the >LoST > > >protocol draft. > > > > James - I do not understand this comment. Can you rephrase it please? > > > > > > > > > > -----Original Message----- > > > > From: Ted Hardie [mailto:hardie@qualcomm.com] > > > > Sent: Tuesday, 20 June 2006 9:47 AM > > > > To: Winterbottom, James; Tschofenig, Hannes; ecrit@ietf.org > > > > Subject: RE: [Ecrit] draft-polk-dhc-ecrit-lost-server-uri-00.txt > > > > > > > > At 5:50 PM -0500 6/19/06, Winterbottom, James wrote: > > > > >Content-Type: multipart/alternative; > > > > > >boundary="--=_NextPart_ST_17_50_12_Monday_June_19_2006_22526" > > > > >Content-class: urn:content-classes:message > > > > > > > > > >It seems that the actual link to this document is: > > > > > > > > > > > > > > > > > >00.txt.txt>http://www.ietf-ecrit.org/cache/draft-polk-dhc-ecrit-lost- > > > > server-uri-00.txt.txt > > > > > > > > > > > > > > > > > > Do you think the LoST protocol draft should define a URI scheme, >then, > > >or > > > > should we do that in an independent draft? > > > > Ted > > > > > > >----------------------------------------------------------------------- >-- > > ----------------------- > > >This message is for the designated recipient only and may > > >contain privileged, proprietary, or otherwise private information. > > >If you have received it in error, please notify the sender > > >immediately and delete the original. Any unauthorized use of > > >this email is prohibited. > > > >----------------------------------------------------------------------- >-- > > ----------------------- > > >[mf2] > > > > > >_______________________________________________ > > >Ecrit mailing list > > >Ecrit@ietf.org > > >https://www1.ietf.org/mailman/listinfo/ecrit > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 22 03:26:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtJa4-0006vh-4y; Thu, 22 Jun 2006 03:26:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtJa3-0006vY-3D for Ecrit@ietf.org; Thu, 22 Jun 2006 03:26:23 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtJa0-0004gh-OE for Ecrit@ietf.org; Thu, 22 Jun 2006 03:26:23 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTPœ id k5M7Pu80025113Thu, 22 Jun 2006 07:25:57 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1FtJZc-000Knx-00; Thu, 22 Jun 2006 08:25:56 +0100 Date: Thu, 22 Jun 2006 08:25:56 +0100 From: "Clive D.W. Feather" To: Brian Rosen Subject: Re: [Ecrit] beagle honored for calling 911 Message-ID: <20060622072556.GB79632@finch-staff-1.thus.net> References: <31e.5bf1199.31cad26d@aol.com> <00ad01c69562$0d040a20$b801a8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00ad01c69562$0d040a20$b801a8c0@cis.neustar.com> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Ecrit@ietf.org, FrancisDomoney@aol.com X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian Rosen said: > Single button emergency call is a big no-no. There have been several waves > of such things, all dramatically bad. > > I'm not sure if button plus confirmation would work. In theory, it would, > but when you are stressed, the confirmation may cause more problems than it > is worth. As I understand it, the false emergency calls in the UK are due to phones that require four button presses (112 or 999 followed by ), so that wouldn't solve it. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 22 12:20:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtRvG-0007Nj-Ob; Thu, 22 Jun 2006 12:20:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtRvF-0007DK-0t for Ecrit@ietf.org; Thu, 22 Jun 2006 12:20:49 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtRvD-0007Tz-PY for Ecrit@ietf.org; Thu, 22 Jun 2006 12:20:49 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FtRv7-00032l-2g; Thu, 22 Jun 2006 11:20:41 -0500 From: "Brian Rosen" To: "'Clive D.W. Feather'" Subject: RE: [Ecrit] beagle honored for calling 911 Date: Thu, 22 Jun 2006 12:20:41 -0400 Message-ID: <03ea01c69617$d2496f40$b801a8c0@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 In-Reply-To: <20060622072556.GB79632@finch-staff-1.thus.net> Thread-Index: AcaVzRuRm6gQeKm+TjSEm7DKRwVBnQASm6Kg 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Ecrit@ietf.org, FrancisDomoney@aol.com X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org There is always some false emergency call rate. I am told the rate for countries with the same digit repeated (9-9-9) is higher than in countries with different digits (9-1-1). One button press caused the false alarm rate to skyrocket. Brian -----Original Message----- From: Clive D.W. Feather [mailto:clive@demon.net] Sent: Thursday, June 22, 2006 3:26 AM To: Brian Rosen Cc: FrancisDomoney@aol.com; hgs@cs.columbia.edu; rohan.mahy@gmail.com; Ecrit@ietf.org Subject: Re: [Ecrit] beagle honored for calling 911 Brian Rosen said: > Single button emergency call is a big no-no. There have been several waves > of such things, all dramatically bad. > > I'm not sure if button plus confirmation would work. In theory, it would, > but when you are stressed, the confirmation may cause more problems than it > is worth. As I understand it, the false emergency calls in the UK are due to phones that require four button presses (112 or 999 followed by ), so that wouldn't solve it. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 26 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 1Fulws-0003q1-8W; Mon, 26 Jun 2006 03:55:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fulwr-0003gF-4u for ecrit@ietf.org; Mon, 26 Jun 2006 03:55:57 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fulwn-000687-SI for ecrit@ietf.org; Mon, 26 Jun 2006 03:55:57 -0400 Received: (qmail invoked by alias); 26 Jun 2006 07:49:11 -0000 Received: from p5498666B.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.102.107] by mail.gmx.net (mp028) with SMTP; 26 Jun 2006 09:49:11 +0200 X-Authenticated: #29516787 Message-ID: <449F9170.8000401@gmx.net> Date: Mon, 26 Jun 2006 09:49:04 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Ecrit] draft-ietf-ecrit-security-threats-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 Hi all, Tom submitted an update of the security threats draft: http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-security-threats-02.txt Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 26 10:53:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FusTE-00081w-1m; Mon, 26 Jun 2006 10:53:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FusTC-00080q-P1 for Ecrit@ietf.org; Mon, 26 Jun 2006 10:53:46 -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 1Fus2O-0004VJ-Nf for Ecrit@ietf.org; Mon, 26 Jun 2006 10:26:04 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FurrF-0007N0-Bq for Ecrit@ietf.org; Mon, 26 Jun 2006 10:14:34 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5QEDXmT012284 for ; Mon, 26 Jun 2006 14:13:33 GMT Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 10:13:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Jun 2006 10:13:23 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New phonebcp draft was submitted Thread-Index: AcaZJOG7R99GWhJvST+3xZTfhyEfKgABYEFQ From: "Rosen, Brian" To: X-OriginalArrivalTime: 26 Jun 2006 14:13:32.0927 (UTC) FILETIME=[B4E5C0F0:01C6992A] X-Spam-Score: -2.6 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ecrit] New phonebcp draft was submitted X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I submitted an update to the phonebcp draft before the deadline.=A0 I = incorporated nearly all of the changes suggested on the list.=A0 I did = not add a lot of wording about frequency of calls from mobiles as = suggested by James.=A0 I also did not delete the section on specific = protocols phones must implement for location acquisition as suggested by = Patty.=A0 I'll bring up that issue at the meeting; basically, I believe = we must have a list that all phones must implement, and access network = must choose one from that list.=A0 Otherwise, we will have no = interoperability.=A0 The list at present would be DHCP and the L7 = protocol (HELD or whatever).=A0 I think we want to have a discussion on = whether LLDP-MED is on that list. Until it appears in the archives, you can find it at: http://www.brianrosen.net/internet-drafts/draft-rosen-ecrit-phonebcp-01.t= xt http://www.brianrosen.net/internet-drafts/draft-rosen-ecrit-phonebcp-01.h= tml Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 26 13:33:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuuxH-0002Cp-38; Mon, 26 Jun 2006 13:32:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuuxF-0002Cj-Ml for Ecrit@ietf.org; Mon, 26 Jun 2006 13:32:57 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuuxE-0003oc-4p for Ecrit@ietf.org; Mon, 26 Jun 2006 13:32:57 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id BD44B2001F; Mon, 26 Jun 2006 13:32:55 -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 25094-04; Mon, 26 Jun 2006 13:32:55 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 1E0E22001C; Mon, 26 Jun 2006 13:32:55 -0400 (EDT) To: "Rosen, Brian" Subject: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft was submitted) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: peter_blatherwick@mitel.com Date: Mon, 26 Jun 2006 13:33:10 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 06/26/2006 01:32:53 PM, Serialize complete at 06/26/2006 01:32:53 PM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.8 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1751751708==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============1751751708== Content-Type: multipart/alternative; boundary="=_alternative 00606C0185257199_=" This is a multipart message in MIME format. --=_alternative 00606C0185257199_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian, list,=20 > ... I think we want to have a discussion on whether LLDP-MED is on that l= ist. As might be expected, I definitely support LLDP-MED as one on that list of = location methods. Some key points in favour I believe are:=20 o LLDP-MED works at Layer 2, which is where real location comes from.=20 Closest to source is better.=20 o Access network elements (L2 switches typically) need to be configured=20 anyway, and while the admin is touching them, location can be entered=20 readily.=20 o Wire map associated with L2 access needs to be created and maintained=20 anyway. (DHCP method would require it to be put in a different, possibly=20 unrelated dB.)=20 o Simple and direct, no intermediate mechanisms needed. (Eg. no need to=20 turn on DHCP relay, insert DHCP relay agent sub-options, etc.) Less=20 dependancies is better.=20 o No need for any additional interfaces in LLDP-MED method -- all=20 interfaces are already defined. In DHCP method (and presumably L7 also ?) = an interface to DHCP server, to interface to the wiremap dB, would need to = be defined to have a fully standards-based approach. (In LLDP-MED, the=20 wiremap dB interface is effectively done through SNMP and the defined=20 MIBs, and the data becomes distributed across the L2 infrastructure.)=20 o Can be made to work with wireless mobility as well. Currently, LLDP-MED = can locate down to the Access Point only (since the wireless environment=20 does not yet have a standard way to do triangulation or similar), however=20 would be relatively straight-forward to extend to higher accuracy. (DHCP=20 is completely inappropriate for wireless mobility IMHO.)=20 Personally, I think above points make best case to use LLDP-MED in a=20 managed enterprise environment. That's a BIG market segment! Other=20 methods may be more appropriate in different environments.=20 BTW for those not familiar, among many other things, LLDP-MED provide an=20 L2 mechanism for location conveyance, 100% data compatible by design with=20 the DHCP methods (both geolocation and civic). The spec, (formally=20 ANSI/TIA-1057), can be found at:=20 =20 http://www.tiaonline.org/standards/technology/voip/documents/ANSI-TIA-1057= =5Ffinal=5Ffor=5Fpublication.pdf Cheers, Peter Blatherwick "Rosen, Brian" 26.06.06 10:13 =20 To: cc:=20 Subject: [Ecrit] New phonebcp draft was submitted I submitted an update to the phonebcp draft before the deadline.=A0 I=20 incorporated nearly all of the changes suggested on the list.=A0 I did not = add a lot of wording about frequency of calls from mobiles as suggested by = James.=A0 I also did not delete the section on specific protocols phones=20 must implement for location acquisition as suggested by Patty.=A0 I'll brin= g=20 up that issue at the meeting; basically, I believe we must have a list=20 that all phones must implement, and access network must choose one from=20 that list.=A0 Otherwise, we will have no interoperability.=A0 The list at=20 present would be DHCP and the L7 protocol (HELD or whatever).=A0 I think we= =20 want to have a discussion on whether LLDP-MED is on that list. Until it appears in the archives, you can find it at: http://www.brianrosen.net/internet-drafts/draft-rosen-ecrit-phonebcp-01.txt http://www.brianrosen.net/internet-drafts/draft-rosen-ecrit-phonebcp-01.html Brian =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --=_alternative 00606C0185257199_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Brian, list,  

> ... I think we want to have a discussion on whether LLDP-MED i= s on that list.

As might be expected, I definitely s= upport LLDP-MED as one on that list of location methods.  Some key poi= nts in favour I believe are:  

o LLDP-MED works at Layer 2, which i= s where real location comes from.  Closest to source is better.  =

o Access network elements (L2 switch= es typically) need to be configured anyway, and while the admin is touching= them, location can be entered readily.  

o Wire map associated with L2 access= needs to be created and maintained anyway.  (DHCP method would requir= e it to be put in a different, possibly unrelated dB.)  

o Simple and direct, no intermediate= mechanisms needed. (Eg. no need to turn on DHCP relay, insert DHCP relay a= gent sub-options, etc.)  Less dependancies is better.    

o No need for any additional interfa= ces in LLDP-MED method -- all interfaces are already defined.  In DHCP= method (and presumably L7 also ?) an interface to DHCP server, to interfac= e to the wiremap dB, would need to be defined to have a fully standards-bas= ed approach.   (In LLDP-MED, the wiremap dB interface is effectively d= one through SNMP and the defined MIBs, and the data becomes distributed acr= oss the L2 infrastructure.)  

o Can be made to work with wireless = mobility as well.  Currently, LLDP-MED can locate down to the Access P= oint only (since the wireless environment does not yet have a standard way = to do triangulation or similar), however would be relatively straight-forwa= rd to extend to higher accuracy.  (DHCP is completely inappropriate fo= r wireless mobility IMHO.)  

Personally, I think above points mak= e best case to use LLDP-MED in a managed enterprise environment.  That= 's a BIG market segment!  Other methods may be more appropriate in dif= ferent environments.  

BTW for those not familiar, among ma= ny other things, LLDP-MED provide an L2 mechanism for location conveyance, = 100% data compatible by design with the DHCP methods (both geolocation and = civic).  The spec, (formally ANSI/TIA-1057), can be found at:
  http://www.tiaonline.org/stan= dards/technology/voip/documents/ANSI-TIA-1057=5Ffinal=5Ffor=5Fpublication.p= df

Cheers,
Peter Blatherwick




"Rosen, Brian" <Bria= n.Rosen@neustar.biz>

26.06.06 10:13

       
        To: &nbs= p;      <Ecrit@ietf.org>
        cc: &nbs= p;      
        Subject:=        [Ecrit] New phonebcp draft was submitted=



I submitted an update to the phoneb= cp draft before the deadline.=A0 I incorporated nearly all of the changes s= uggested on the list.=A0 I did not add a lot of wording about frequency of = calls from mobiles as suggested by James.=A0 I also did not delete the sect= ion on specific protocols phones must implement for location acquisition as= suggested by Patty.=A0 I'll bring up that issue at the meeting; basically,= I believe we must have a list that all phones must implement, and access n= etwork must choose one from that list.=A0 Otherwise, we will have no intero= perability.=A0 The list at present would be DHCP and the L7 protocol (HELD = or whatever).=A0 I think we want to have a discussion on whether LLDP-MED i= s on that list.

Until it appears in the archives, you can find it at:
http://www.brianrosen.net/internet-drafts/draft-rosen-ecrit-phonebcp-01.txt=
http://www.brianrosen.net/internet-drafts/draft-rosen-ecrit-phonebcp-01.htm= l

Brian

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

--=_alternative 00606C0185257199_=-- --===============1751751708== 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 --===============1751751708==-- From ecrit-bounces@ietf.org Mon Jun 26 13:41:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuv58-0006jJ-AU; Mon, 26 Jun 2006 13:41:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuv56-0006jA-6s for Ecrit@ietf.org; Mon, 26 Jun 2006 13:41:04 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuv55-0004WN-Sa for Ecrit@ietf.org; Mon, 26 Jun 2006 13:41:04 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5QHf3Rw024360; Mon, 26 Jun 2006 17:41:03 GMT Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 13:41:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft was submitted) Date: Mon, 26 Jun 2006 13:40:53 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft was submitted) Thread-Index: AcaZRpCEDpm5z98eQWWd+VIG387lWwAAFu0A From: "Rosen, Brian" To: X-OriginalArrivalTime: 26 Jun 2006 17:41:03.0483 (UTC) FILETIME=[B201D4B0:01C69947] X-Spam-Score: 0.5 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org You and I have discussed this, so you know what I'm going to say. Every phone has to implement every protocol on the list. The bar for a = protocol to be on the list should be very high. LLDP-MED is only = appropriate in a switched Ethernet environment, which is of course, very = common in enterprise. Wherever you could deploy LLDP-MED, it would be = reasonable to deploy the DHCP solution. The reverse is not true. = Claiming it's easier to deploy is interesting, but I don't think it gets = above the bar. Brian ________________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Monday, June 26, 2006 1:33 PM To: Rosen, Brian Cc: Ecrit@ietf.org Subject: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft was = submitted) Brian, list, =A0=20 > ... I think we want to have a discussion on whether LLDP-MED is on = that list.=20 As might be expected, I definitely support LLDP-MED as one on that list = of location methods. =A0Some key points in favour I believe are: =A0=20 o LLDP-MED works at Layer 2, which is where real location comes from. = =A0Closest to source is better. =A0=20 o Access network elements (L2 switches typically) need to be configured = anyway, and while the admin is touching them, location can be entered = readily. =A0=20 o Wire map associated with L2 access needs to be created and maintained = anyway. =A0(DHCP method would require it to be put in a different, = possibly unrelated dB.) =A0=20 o Simple and direct, no intermediate mechanisms needed. (Eg. no need to = turn on DHCP relay, insert DHCP relay agent sub-options, etc.) =A0Less = dependancies is better. =A0 =A0=20 o No need for any additional interfaces in LLDP-MED method -- all = interfaces are already defined. =A0In DHCP method (and presumably L7 = also ?) an interface to DHCP server, to interface to the wiremap dB, = would need to be defined to have a fully standards-based approach. =A0 = (In LLDP-MED, the wiremap dB interface is effectively done through SNMP = and the defined MIBs, and the data becomes distributed across the L2 = infrastructure.) =A0=20 o Can be made to work with wireless mobility as well. =A0Currently, = LLDP-MED can locate down to the Access Point only (since the wireless = environment does not yet have a standard way to do triangulation or = similar), however would be relatively straight-forward to extend to = higher accuracy. =A0(DHCP is completely inappropriate for wireless = mobility IMHO.) =A0=20 Personally, I think above points make best case to use LLDP-MED in a = managed enterprise environment. =A0That's a BIG market segment! =A0Other = methods may be more appropriate in different environments. =A0=20 BTW for those not familiar, among many other things, LLDP-MED provide an = L2 mechanism for location conveyance, 100% data compatible by design = with the DHCP methods (both geolocation and civic). =A0The spec, = (formally ANSI/TIA-1057), can be found at:=20 =A0 = http://www.tiaonline.org/standards/technology/voip/documents/ANSI-TIA-105= 7_final_for_publication.pdf=20 Cheers,=20 Peter Blatherwick=20 "Rosen, Brian" =20 26.06.06 10:13=20 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0[Ecrit] New phonebcp draft was = submitted I submitted an update to the phonebcp draft before the deadline.=A0 I = incorporated nearly all of the changes suggested on the list.=A0 I did = not add a lot of wording about frequency of calls from mobiles as = suggested by James.=A0 I also did not delete the section on specific = protocols phones must implement for location acquisition as suggested by = Patty.=A0 I'll bring up that issue at the meeting; basically, I believe = we must have a list that all phones must implement, and access network = must choose one from that list.=A0 Otherwise, we will have no = interoperability.=A0 The list at present would be DHCP and the L7 = protocol (HELD or whatever).=A0 I think we want to have a discussion on = whether LLDP-MED is on that list. Until it appears in the archives, you can find it at: http://www.brianrosen.net/internet-drafts/draft-rosen-ecrit-phonebcp-01.t= xt http://www.brianrosen.net/internet-drafts/draft-rosen-ecrit-phonebcp-01.h= tml Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 26 15:03:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwN1-0005HN-Um; Mon, 26 Jun 2006 15:03:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwN0-0005HG-TO for ecrit@ietf.org; Mon, 26 Jun 2006 15:03:39 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuwMz-0002IB-LA for ecrit@ietf.org; Mon, 26 Jun 2006 15:03:38 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k5QJ3aDg018075 for ; Mon, 26 Jun 2006 14:03:36 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 26 Jun 2006 20:03:35 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0134D1D2B@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: ecrit@ietf.org Date: Mon, 26 Jun 2006 20:03:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Ecrit] FW: Venue for CT1/ECRIT joint session on emergency calls X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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 have not seen anyone else post this yet. regards Keith -----Original Message----- From: 3GPP_TSG_CT_WG1 - Core Network and Terminals WG 1 [mailto:3GPP_TSG_CT_WG1@LIST.ETSI.ORG]On Behalf Of Stephen Hayes (TX/EUS) Sent: 21 June 2006 16:55 To: 3GPP_TSG_CT_WG1@LIST.ETSI.ORG Subject: Venue for CT1/ECRIT joint session on emergency calls The venue for the July 9, 2006 CT1/ECRIT session is: St. Charles room Delta Centre-Ville hotel 777 University Street Montreal, Quebec H3C 3Z7 (one of the IETF hotels) The meeting starts at 1pm. Could someone on the ECRIT list, please forward this information to that list. Regards, Stephen Hayes 3GPP TSG-SA Chair Ericsson Inc. Tel: +1 817-491-4015 Fax: +1 801 409 6319 Mobile: +1 469 360 8500 mailto:stephen.hayes@ericsson.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 26 15:09:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwSk-0000hA-EH; Mon, 26 Jun 2006 15:09:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwSj-0000h5-HB for Ecrit@ietf.org; Mon, 26 Jun 2006 15:09:33 -0400 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuwSh-0003D9-UL for Ecrit@ietf.org; Mon, 26 Jun 2006 15:09:33 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5QJ6JNB024422 for ; Mon, 26 Jun 2006 15:06:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) Date: Mon, 26 Jun 2006 22:09:28 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) Thread-Index: AcaZRpCEDpm5z98eQWWd+VIG387lWwAAFu0AAALsPcA= From: "Romascanu, Dan \(Dan\)" To: "Rosen, Brian" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.5 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 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, You are correct that LLDP-MED is well applicable in a bridged (switched) = Ethernet environment, although I would avoid saying 'only'. My question = is however - how many IP phones are connected to the Internet with an = Ethernet switched link being the first link? I believe that we had a discussion at the start of the ECRIT work about = whether enterprise environments have specific requirements that need to = be explicitly dealt. At that point in tome we did not find too many = obvious examples, but we said something like 'ECRIT will cover = enterprise environments, we do not know right now what would be = different in the enterprise, but when we'll find something that needs a = different solution we shall cove it with the appropriate applicability = statement attached'.=20 I think that the use of a sub-IP protocol like LLDP-MED is one of these = cases.=20 Dan =20 =20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 > Sent: Monday, June 26, 2006 8:41 PM > To: peter_blatherwick@mitel.com > Cc: Ecrit@ietf.org > Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp=20 > draft wassubmitted) >=20 > You and I have discussed this, so you know what I'm going to say. >=20 > Every phone has to implement every protocol on the list. The=20 > bar for a protocol to be on the list should be very high. =20 > LLDP-MED is only appropriate in a switched Ethernet=20 > environment, which is of course, very common in enterprise. =20 > Wherever you could deploy LLDP-MED, it would be reasonable to=20 > deploy the DHCP solution. The reverse is not true. Claiming=20 > it's easier to deploy is interesting, but I don't think it=20 > gets above the bar. >=20 > Brian >=20 > ________________________________________ > From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] > Sent: Monday, June 26, 2006 1:33 PM > To: Rosen, Brian > Cc: Ecrit@ietf.org > Subject: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp=20 > draft was submitted) >=20 >=20 > Brian, list, =A0=20 >=20 > > ... I think we want to have a discussion on whether=20 > LLDP-MED is on that list.=20 >=20 > As might be expected, I definitely support LLDP-MED as one on=20 > that list of location methods. =A0Some key points in favour I=20 > believe are: =A0=20 >=20 > o LLDP-MED works at Layer 2, which is where real location=20 > comes from. =A0Closest to source is better. =A0=20 >=20 > o Access network elements (L2 switches typically) need to be=20 > configured anyway, and while the admin is touching them,=20 > location can be entered readily. =A0=20 >=20 > o Wire map associated with L2 access needs to be created and=20 > maintained anyway. =A0(DHCP method would require it to be put=20 > in a different, possibly unrelated dB.) =A0=20 >=20 > o Simple and direct, no intermediate mechanisms needed. (Eg.=20 > no need to turn on DHCP relay, insert DHCP relay agent=20 > sub-options, etc.) =A0Less dependancies is better. =A0 =A0=20 >=20 > o No need for any additional interfaces in LLDP-MED method --=20 > all interfaces are already defined. =A0In DHCP method (and=20 > presumably L7 also ?) an interface to DHCP server, to=20 > interface to the wiremap dB, would need to be defined to have=20 > a fully standards-based approach. =A0 (In LLDP-MED, the wiremap=20 > dB interface is effectively done through SNMP and the defined=20 > MIBs, and the data becomes distributed across the L2=20 > infrastructure.) =A0=20 >=20 > o Can be made to work with wireless mobility as well. =A0 > Currently, LLDP-MED can locate down to the Access Point only=20 > (since the wireless environment does not yet have a standard=20 > way to do triangulation or similar), however would be=20 > relatively straight-forward to extend to higher accuracy. =A0 > (DHCP is completely inappropriate for wireless mobility IMHO.) =A0=20 >=20 > Personally, I think above points make best case to use=20 > LLDP-MED in a managed enterprise environment. =A0That's a BIG=20 > market segment! =A0Other methods may be more appropriate in=20 > different environments. =A0=20 >=20 > BTW for those not familiar, among many other things, LLDP-MED=20 > provide an L2 mechanism for location conveyance, 100% data=20 > compatible by design with the DHCP methods (both geolocation=20 > and civic). =A0The spec, (formally ANSI/TIA-1057), can be found at:=20 > =A0=20 > http://www.tiaonline.org/standards/technology/voip/documents/A NSI-TIA-1057_final_for_publication.pdf=20 Cheers,=20 Peter Blatherwick=20 "Rosen, Brian" =20 26.06.06 10:13=20 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0[Ecrit] New phonebcp draft was = submitted I submitted an update to the phonebcp draft before the deadline.=A0 I = incorporated nearly all of the changes suggested on the list.=A0 I did = not add a lot of wording about frequency of calls from mobiles as = suggested by James.=A0 I also did not delete the section on specific = protocols phones must implement for location acquisition as suggested by = Patty.=A0 I'll bring up that issue at the meeting; basically, I believe = we must have a list that all phones must implement, and access network = must choose one from that list.=A0 Otherwise, we will have no = interoperability.=A0 The list at present would be DHCP and the L7 = protocol (HELD or whatever).=A0 I think we want to have a discussion on = whether LLDP-MED is on that list. Until it appears in the archives, you can find it at: http://www.brianrosen.net/internet-drafts/draft-rosen-ecrit-phonebcp-01.t= xt http://www.brianrosen.net/internet-drafts/draft-rosen-ecrit-phonebcp-01.h= tml Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 26 16:17:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuxWa-0002hK-Mp; Mon, 26 Jun 2006 16:17:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuxWY-0002Z1-Lj for ecrit@ietf.org; Mon, 26 Jun 2006 16:17:34 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuxWX-0002kh-5z for ecrit@ietf.org; Mon, 26 Jun 2006 16:17:34 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k5QKC5X06374 for ; Mon, 26 Jun 2006 16:12:05 -0400 (EDT) Received: from [127.0.0.1] ([47.130.24.14] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 16:17:30 -0400 Message-ID: <44A040CE.5090101@nortel.com> Date: Mon, 26 Jun 2006 16:17:18 -0400 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jun 2006 20:17:30.0565 (UTC) FILETIME=[8D24DF50:01C6995D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Subject: [Ecrit] Changes in the ECRIT security draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I updated the ECRIT security draft to take account of comments Hannes and by Kamran Aquil. The following changes are reflected in draft-ietf-ecrit-security-threats-02.txt: 1. Abstract: eliminated reference to ECRIT and highlighted the two topics of the analysis by breaking them out into bullets. Added the word "identified" in front of "threats" in the last senttence (typo noted). 2. Changed the section headings to capitalized style. 3. Introduction second para: deleted the parenthetic reference to attempts to get free calling in the PSTN. Deleted the reference to the ECRIT WG further down, replacing "In view of the mandate of the ECRIT Working Group" with "While this can be a broad topic". 4. Next para: replaced "ECRIT" with "emergency calling". 5. Section 3 first para modified to eliminate references to ECRIT. Old: "The ECRIT Working Group has two work items relating to the routing of emergency calls to their proper destination. The first is to enable entities along the signalling path to recognize that a particular signalling message is associated with an emergency call. The ECRIT Working Group is defining content that can be added to the signalling messages, an emergency identifier, for this purpose. Signalling containing the emergency identifier may be given priority treatment, special processing, and/or special routing." New: "This memo deals with two topics relating to the routing of emergency calls to their proper destination. The first is the marking of call signalling to enable entities along the signalling path to recognize that a particular signalling message is associated with an emergency call. Signalling containing the emergency identifier may be given priority treatment, special processing, and/or special routing." 6. Next para: deleted a reference to ECRIT. 7. Section 4,third bullet of "attacks against the emergency response system": deleted reference to ECRIT and rephrased to make the meaning clearer. Old: "o to divert emergency responders to non-emergency sites. No attacks affecting the ECRIT Working Group's decisions on the emergency identifier and mapping protocol have been identified that achieve this objective" New: "o to divert emergency responders to non-emergency sites. This memo has not identified any attacks within its intended scope that achieve this objective, so it will not be mentioned further." 7. Section 5.1 bullet b. rewritten for more clarity: Old: "b. The call routing system assumes that the emergency caller's device addresses emergency calls using the result of mapping based on the caller's location." New: "b. The call routing system assumes that the emergency caller's device signals the correct PSAP URI for the caller's location." 8. Section 5.2.1 first para rewritten to take account of a point raised by Hannes: that the call may never get to a PSAP at all. Old: "This section considers attacks intended to reduce the effectiveness of the emergency response system for all callers in a given area. If the mapping operation is disabled, the immediate effect is to increase the probability that emergency calls are routed to the wrong PSAP. This has a double consequence: emergency response to the affected calls is delayed, and PSAP call taker resources outside the immediate area of the emergency are consumed due to the extra effort required to redirect the calls. Alternatively, attacks that cause the client to receive a URI that does not lead to a PSAP have the immediate effect of causing emergency calls to fail." New: "This section considers attacks intended to reduce the effectiveness of the emergency response system for all callers in a given area. If the mapping operation is disabled, then the emergency caller's device might not have the correct PSAP URI. As a consequence, the probability that emergency calls are routed to the wrong PSAP is increased. In the worst case the emergency caller's device might not be able to obtain a PSAP URI at all. Routing to the wrong PSAP has a double consequence: emergency response to the affected calls is delayed, and PSAP call taker resources outside the immediate area of the emergency are consumed due to the extra effort required to redirect the calls. Alternatively, attacks that cause the client to receive a URI that does not lead to a PSAP have the immediate effect of causing emergency calls to fail." 9. Section 5.2.1, para beginning "In an impersonation attack, ..." following the bullets, rewrote final sentence to make it clearer. Old: "However, the mapping protocol may help to protect against acceptance of responses from an impersonating entity." New: "However, the mapping protocol may allow impersonation to be detected, thereby preventing acceptance of responses from an impersonating entity and possibly triggering a more secure discovery procedure." 10. Section 5.2.3 first para: added the word "Alternatively" at the start of the sentence. 11. Added Kamran Aquil to the Acknowledgements section (typo noted, sorry). _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 26 16:32:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuxlD-0004uf-Py; Mon, 26 Jun 2006 16:32:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuxlC-0004tE-UX for ecrit@ietf.org; Mon, 26 Jun 2006 16:32:42 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuxlB-0003ks-Nu for ecrit@ietf.org; Mon, 26 Jun 2006 16:32:42 -0400 Received: from hydra.cs.columbia.edu (IDENT:eJPZVEq+yZZPoG3OFsFlESgx3gjXN3KG@hydra.cs.columbia.edu [128.59.16.129]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k5QKWDSr022270 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 26 Jun 2006 16:32:35 -0400 (EDT) Received: from webmail.cs.columbia.edu (IDENT:oQ8HNcqGxKkNTF5mvr14chM3DpYxUoxm@localhost [127.0.0.1]) by hydra.cs.columbia.edu (8.12.10/8.12.10) with SMTP id k5QKWCIL030695; Mon, 26 Jun 2006 16:32:12 -0400 Received: from 208.187.85.3 (SquirrelMail authenticated user hgs) by webmail.cs.columbia.edu with HTTP; Mon, 26 Jun 2006 16:32:13 -0400 (EDT) Message-ID: <56037.208.187.85.3.1151353933.squirrel@webmail.cs.columbia.edu> In-Reply-To: References: Date: Mon, 26 Jun 2006 16:32:13 -0400 (EDT) Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) From: hgs@cs.columbia.edu To: "Rosen, Brian" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-PerlMx-Spam: Gauge=X, Probability=10%, Report='PRIORITY_NO_NAME 0.716, NO_REAL_NAME 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_PRIORITY 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org In theory, yes. In practice, the DHCP server is often managed by different entities than the L2 infrastructure. (This seems to be fairly common on campuses.) In our local environment, your approach would be extremely difficult to implement, without a major network reorganization. > For the enterprise environment, I would think you would use the DHCP > relay option, which adds a circuit ID at the switch. That would be a > one step map (Circuit ID to location) at the DHCP server. It's a two > step configuration (have to assign the circuit ID on the switch, and > build the circuitId to location map), but still seems to be pretty close > to what you do with LLDP-MED. > > Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 26 17:04:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyFt-0005IF-9L; Mon, 26 Jun 2006 17:04:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyFs-0005I8-BE for Ecrit@ietf.org; Mon, 26 Jun 2006 17:04:24 -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 1FuxL7-0001vi-Vd for Ecrit@ietf.org; Mon, 26 Jun 2006 16:05:46 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FuxGr-0004Pm-AH for Ecrit@ietf.org; Mon, 26 Jun 2006 16:01:22 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5QJuxjw021075; Mon, 26 Jun 2006 19:56:59 GMT Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 15:56:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) Date: Mon, 26 Jun 2006 15:56:47 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) Thread-Index: AcaZVWfT9ATABoNRTQyoV4jS4Li6sQABLFxA From: "Rosen, Brian" To: "Henning Schulzrinne" , "Romascanu, Dan \(Dan\)" X-OriginalArrivalTime: 26 Jun 2006 19:56:58.0846 (UTC) FILETIME=[AEFB77E0:01C6995A] X-Spam-Score: -1.5 (-) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 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 For the enterprise environment, I would think you would use the DHCP relay option, which adds a circuit ID at the switch. That would be a one step map (Circuit ID to location) at the DHCP server. It's a two step configuration (have to assign the circuit ID on the switch, and build the circuitId to location map), but still seems to be pretty close to what you do with LLDP-MED. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Monday, June 26, 2006 3:19 PM To: Romascanu, Dan (Dan) Cc: Rosen, Brian; peter_blatherwick@mitel.com; Ecrit@ietf.org Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) I think this is also a matter of implementation complexity. In other =20 words, the threshold for an (imaginary) protocol that needs key =20 management, an SNMP MIB and an ASN.1 implementation is presumably =20 higher than for something like a DHCP option or a simple L2 frame. =20 For the case at hand, in many circumstances, configuring a switch =20 with basic location information will be easier than doing this =20 indirectly through DHCP, as the latter involves a fairly messy "trace =20 back" (get MAC address, find which switch port that MAC address =20 appears on via various bridge MIB walks, consult wire map database, =20 update DHCP database). Two crucial steps in that chain are not =20 currently standardized, making working in mixed-vendor environments a =20 pain. We've implemented both a well-known predecessor of LLDP-MED and the =20 DHCP option and the former is much easier to implement and more =20 reliable. Thus, I'm in favor of including LLDP-MED. Henning On Jun 26, 2006, at 3:09 PM, Romascanu, Dan ((Dan)) wrote: > Brian, > > You are correct that LLDP-MED is well applicable in a bridged =20 > (switched) Ethernet environment, although I would avoid saying =20 > 'only'. My question is however - how many IP phones are connected =20 > to the Internet with an Ethernet switched link being the first link? > > I believe that we had a discussion at the start of the ECRIT work =20 > about whether enterprise environments have specific requirements =20 > that need to be explicitly dealt. At that point in tome we did not =20 > find too many obvious examples, but we said something like 'ECRIT =20 > will cover enterprise environments, we do not know right now what =20 > would be different in the enterprise, but when we'll find something =20 > that needs a different solution we shall cove it with the =20 > appropriate applicability statement attached'. > > I think that the use of a sub-IP protocol like LLDP-MED is one of =20 > these cases. > > Dan > > > > > > > >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Monday, June 26, 2006 8:41 PM >> To: peter_blatherwick@mitel.com >> Cc: Ecrit@ietf.org >> Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp >> draft wassubmitted) >> >> You and I have discussed this, so you know what I'm going to say. >> >> Every phone has to implement every protocol on the list. The >> bar for a protocol to be on the list should be very high. >> LLDP-MED is only appropriate in a switched Ethernet >> environment, which is of course, very common in enterprise. >> Wherever you could deploy LLDP-MED, it would be reasonable to >> deploy the DHCP solution. The reverse is not true. Claiming >> it's easier to deploy is interesting, but I don't think it >> gets above the bar. >> >> Brian >> >> ________________________________________ >> From: peter_blatherwick@mitel.com =20 >> [mailto:peter_blatherwick@mitel.com] >> Sent: Monday, June 26, 2006 1:33 PM >> To: Rosen, Brian >> Cc: Ecrit@ietf.org >> Subject: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp >> draft was submitted) >> >> >> Brian, list, >> >>> ... I think we want to have a discussion on whether >> LLDP-MED is on that list. >> >> As might be expected, I definitely support LLDP-MED as one on >> that list of location methods. Some key points in favour I >> believe are: >> >> o LLDP-MED works at Layer 2, which is where real location >> comes from. Closest to source is better. >> >> o Access network elements (L2 switches typically) need to be >> configured anyway, and while the admin is touching them, >> location can be entered readily. >> >> o Wire map associated with L2 access needs to be created and >> maintained anyway. (DHCP method would require it to be put >> in a different, possibly unrelated dB.) >> >> o Simple and direct, no intermediate mechanisms needed. (Eg. >> no need to turn on DHCP relay, insert DHCP relay agent >> sub-options, etc.) Less dependancies is better. >> >> o No need for any additional interfaces in LLDP-MED method -- >> all interfaces are already defined. In DHCP method (and >> presumably L7 also ?) an interface to DHCP server, to >> interface to the wiremap dB, would need to be defined to have >> a fully standards-based approach. (In LLDP-MED, the wiremap >> dB interface is effectively done through SNMP and the defined >> MIBs, and the data becomes distributed across the L2 >> infrastructure.) >> >> o Can be made to work with wireless mobility as well. >> Currently, LLDP-MED can locate down to the Access Point only >> (since the wireless environment does not yet have a standard >> way to do triangulation or similar), however would be >> relatively straight-forward to extend to higher accuracy. >> (DHCP is completely inappropriate for wireless mobility IMHO.) >> >> Personally, I think above points make best case to use >> LLDP-MED in a managed enterprise environment. That's a BIG >> market segment! Other methods may be more appropriate in >> different environments. >> >> BTW for those not familiar, among many other things, LLDP-MED >> provide an L2 mechanism for location conveyance, 100% data >> compatible by design with the DHCP methods (both geolocation >> and civic). The spec, (formally ANSI/TIA-1057), can be found at: >> >> http://www.tiaonline.org/standards/technology/voip/documents/A > NSI-TIA-1057_final_for_publication.pdf > > Cheers, > Peter Blatherwick > > > > > "Rosen, Brian" > 26.06.06 10:13 > > To: > cc: > Subject: [Ecrit] New phonebcp draft was submitted > > > > I submitted an update to the phonebcp draft before the deadline. I =20 > incorporated nearly all of the changes suggested on the list. I =20 > did not add a lot of wording about frequency of calls from mobiles =20 > as suggested by James. I also did not delete the section on =20 > specific protocols phones must implement for location acquisition =20 > as suggested by Patty. I'll bring up that issue at the meeting; =20 > basically, I believe we must have a list that all phones must =20 > implement, and access network must choose one from that list. =20 > Otherwise, we will have no interoperability. The list at present =20 > would be DHCP and the L7 protocol (HELD or whatever). I think we =20 > want to have a discussion on whether LLDP-MED is on that list. > > Until it appears in the archives, you can find it at: > http://www.brianrosen.net/internet-drafts/draft-rosen-ecrit-=20 > phonebcp-01.txt > http://www.brianrosen.net/internet-drafts/draft-rosen-ecrit-=20 > phonebcp-01.html > > Brian > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > 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 Jun 26 17:35:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuyjr-0005cd-Jf; Mon, 26 Jun 2006 17:35:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuyjq-0005cV-Ds for ecrit@ietf.org; Mon, 26 Jun 2006 17:35:22 -0400 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuyjo-0000C8-VX for ecrit@ietf.org; Mon, 26 Jun 2006 17:35:22 -0400 Received: from MA0034AVEXU1.global.avaya.com (h135-35-75-7.avaya.com [135.35.75.7]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5QLV78u003403 for ; Mon, 26 Jun 2006 17:31:07 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) Date: Mon, 26 Jun 2006 17:35:20 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) Thread-Index: AcaZX67aI0Hfkg47RvWw9MB2L0WN4wABqpAw From: "Rodrig, Benny \(Benny\)" To: , "Rosen, Brian" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Also, solution robustness seems to be better with LLDP-MED compared to using DHCP with the DHCP relay, since LLDP-MED requires less "moving parts". That's because the layer-2 switch has to be involved anyway whether it's LLDP-MED or DHCP Relay needed to identify the individual switch-port, and then the DHCP solution is dependent also on the DHCP server. This could be less robust in emergency situations when parts of the network may be failing, etc. Benny=20 -----Original Message----- From: hgs@cs.columbia.edu [mailto:hgs@cs.columbia.edu]=20 Sent: Monday, June 26, 2006 4:32 PM To: Rosen, Brian Cc: ecrit@ietf.org Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) In theory, yes. In practice, the DHCP server is often managed by different entities than the L2 infrastructure. (This seems to be fairly common on campuses.) In our local environment, your approach would be extremely difficult to implement, without a major network reorganization. > For the enterprise environment, I would think you would use the DHCP=20 > relay option, which adds a circuit ID at the switch. That would be a=20 > one step map (Circuit ID to location) at the DHCP server. It's a two=20 > step configuration (have to assign the circuit ID on the switch, and=20 > build the circuitId to location map), but still seems to be pretty=20 > close to what you do with LLDP-MED. > > Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 26 17:38:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuymu-0007qs-Vg; Mon, 26 Jun 2006 17:38:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuymt-0007hv-5m for Ecrit@ietf.org; Mon, 26 Jun 2006 17:38:31 -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 1Fuwpv-00066n-0O for Ecrit@ietf.org; Mon, 26 Jun 2006 15:33:31 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fuwc0-0003TF-Cu for Ecrit@ietf.org; Mon, 26 Jun 2006 15:19:09 -0400 Received: from [192.168.100.113] (67-40-112-58.slkc.qwest.net [67.40.112.58]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k5QJIl2P001580 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 26 Jun 2006 15:18:52 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <68A39EAE-FC7B-4395-A95B-4047A0527A09@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) Date: Mon, 26 Jun 2006 15:18:47 -0400 To: "Romascanu, Dan \(Dan\)" X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: -0.3 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: "Rosen, Brian" , 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 this is also a matter of implementation complexity. In other words, the threshold for an (imaginary) protocol that needs key management, an SNMP MIB and an ASN.1 implementation is presumably higher than for something like a DHCP option or a simple L2 frame. For the case at hand, in many circumstances, configuring a switch with basic location information will be easier than doing this indirectly through DHCP, as the latter involves a fairly messy "trace back" (get MAC address, find which switch port that MAC address appears on via various bridge MIB walks, consult wire map database, update DHCP database). Two crucial steps in that chain are not currently standardized, making working in mixed-vendor environments a pain. We've implemented both a well-known predecessor of LLDP-MED and the DHCP option and the former is much easier to implement and more reliable. Thus, I'm in favor of including LLDP-MED. Henning On Jun 26, 2006, at 3:09 PM, Romascanu, Dan ((Dan)) wrote: > Brian, > > You are correct that LLDP-MED is well applicable in a bridged > (switched) Ethernet environment, although I would avoid saying > 'only'. My question is however - how many IP phones are connected > to the Internet with an Ethernet switched link being the first link? > > I believe that we had a discussion at the start of the ECRIT work > about whether enterprise environments have specific requirements > that need to be explicitly dealt. At that point in tome we did not > find too many obvious examples, but we said something like 'ECRIT > will cover enterprise environments, we do not know right now what > would be different in the enterprise, but when we'll find something > that needs a different solution we shall cove it with the > appropriate applicability statement attached'. > > I think that the use of a sub-IP protocol like LLDP-MED is one of > these cases. > > Dan > > > > > > > >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Monday, June 26, 2006 8:41 PM >> To: peter_blatherwick@mitel.com >> Cc: Ecrit@ietf.org >> Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp >> draft wassubmitted) >> >> You and I have discussed this, so you know what I'm going to say. >> >> Every phone has to implement every protocol on the list. The >> bar for a protocol to be on the list should be very high. >> LLDP-MED is only appropriate in a switched Ethernet >> environment, which is of course, very common in enterprise. >> Wherever you could deploy LLDP-MED, it would be reasonable to >> deploy the DHCP solution. The reverse is not true. Claiming >> it's easier to deploy is interesting, but I don't think it >> gets above the bar. >> >> Brian >> >> ________________________________________ >> From: peter_blatherwick@mitel.com >> [mailto:peter_blatherwick@mitel.com] >> Sent: Monday, June 26, 2006 1:33 PM >> To: Rosen, Brian >> Cc: Ecrit@ietf.org >> Subject: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp >> draft was submitted) >> >> >> Brian, list, >> >>> ... I think we want to have a discussion on whether >> LLDP-MED is on that list. >> >> As might be expected, I definitely support LLDP-MED as one on >> that list of location methods. Some key points in favour I >> believe are: >> >> o LLDP-MED works at Layer 2, which is where real location >> comes from. Closest to source is better. >> >> o Access network elements (L2 switches typically) need to be >> configured anyway, and while the admin is touching them, >> location can be entered readily. >> >> o Wire map associated with L2 access needs to be created and >> maintained anyway. (DHCP method would require it to be put >> in a different, possibly unrelated dB.) >> >> o Simple and direct, no intermediate mechanisms needed. (Eg. >> no need to turn on DHCP relay, insert DHCP relay agent >> sub-options, etc.) Less dependancies is better. >> >> o No need for any additional interfaces in LLDP-MED method -- >> all interfaces are already defined. In DHCP method (and >> presumably L7 also ?) an interface to DHCP server, to >> interface to the wiremap dB, would need to be defined to have >> a fully standards-based approach. (In LLDP-MED, the wiremap >> dB interface is effectively done through SNMP and the defined >> MIBs, and the data becomes distributed across the L2 >> infrastructure.) >> >> o Can be made to work with wireless mobility as well. >> Currently, LLDP-MED can locate down to the Access Point only >> (since the wireless environment does not yet have a standard >> way to do triangulation or similar), however would be >> relatively straight-forward to extend to higher accuracy. >> (DHCP is completely inappropriate for wireless mobility IMHO.) >> >> Personally, I think above points make best case to use >> LLDP-MED in a managed enterprise environment. That's a BIG >> market segment! Other methods may be more appropriate in >> different environments. >> >> BTW for those not familiar, among many other things, LLDP-MED >> provide an L2 mechanism for location conveyance, 100% data >> compatible by design with the DHCP methods (both geolocation >> and civic). The spec, (formally ANSI/TIA-1057), can be found at: >> >> http://www.tiaonline.org/standards/technology/voip/documents/A > NSI-TIA-1057_final_for_publication.pdf > > Cheers, > Peter Blatherwick > > > > > "Rosen, Brian" > 26.06.06 10:13 > > To: > cc: > Subject: [Ecrit] New phonebcp draft was submitted > > > > I submitted an update to the phonebcp draft before the deadline. I > incorporated nearly all of the changes suggested on the list. I > did not add a lot of wording about frequency of calls from mobiles > as suggested by James. I also did not delete the section on > specific protocols phones must implement for location acquisition > as suggested by Patty. I'll bring up that issue at the meeting; > basically, I believe we must have a list that all phones must > implement, and access network must choose one from that list. > Otherwise, we will have no interoperability. The list at present > would be DHCP and the L7 protocol (HELD or whatever). I think we > want to have a discussion on whether LLDP-MED is on that list. > > Until it appears in the archives, you can find it at: > http://www.brianrosen.net/internet-drafts/draft-rosen-ecrit- > phonebcp-01.txt > http://www.brianrosen.net/internet-drafts/draft-rosen-ecrit- > phonebcp-01.html > > Brian > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > 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 Jun 26 17:47:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyvR-0008GL-F3; Mon, 26 Jun 2006 17:47:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyvR-0008GB-1e for ecrit@ietf.org; Mon, 26 Jun 2006 17:47:21 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuyvP-0002Mj-Rk for ecrit@ietf.org; Mon, 26 Jun 2006 17:47:21 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 26 Jun 2006 17:47:21 -0400 X-IronPort-AV: i="4.06,178,1149480000"; d="scan'208"; a="91059424:sNHT28463192" Received: from [68.49.184.222] (rtp-vpn3-155.cisco.com [10.82.216.155]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5QLlIYL022918; Mon, 26 Jun 2006 17:47:19 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) Date: Mon, 26 Jun 2006 17:47:14 -0400 To: "Rodrig, Benny \(Benny\)" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: "Rosen, Brian" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org If the host cannot reach a DHCP server, and does not get an IP address usable on the subnet attached through the switch, it is not going to be able to do much. The "moving parts" that would concern me have to do with distributing location information to each switch about its ports. One advantage of letting host configuration handle this is that host get other centrally administered options this way already. John On Jun 26, 2006, at 5:35 PM, Rodrig, Benny ((Benny)) wrote: > Also, solution robustness seems to be better with LLDP-MED compared to > using DHCP with the DHCP relay, since LLDP-MED requires less "moving > parts". That's because the layer-2 switch has to be involved anyway > whether it's LLDP-MED or DHCP Relay needed to identify the individual > switch-port, and then the DHCP solution is dependent also on the DHCP > server. This could be less robust in emergency situations when parts of > the network may be failing, etc. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 26 18:00:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuz7w-0007x3-NU; Mon, 26 Jun 2006 18:00:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuz7u-0007wt-Ke for ecrit@ietf.org; Mon, 26 Jun 2006 18:00:14 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuz7t-0003lm-8i for ecrit@ietf.org; Mon, 26 Jun 2006 18:00:14 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id F1A9620035; Mon, 26 Jun 2006 18:00:12 -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 04142-06; Mon, 26 Jun 2006 18:00:12 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 66E6F2001C; Mon, 26 Jun 2006 18:00:12 -0400 (EDT) To: hgs@cs.columbia.edu Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: peter_blatherwick@mitel.com Date: Mon, 26 Jun 2006 18:00:11 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 06/26/2006 06:00:12 PM, Serialize complete at 06/26/2006 06:00:12 PM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.8 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: "Rosen, Brian" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2146633033==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============2146633033== Content-Type: multipart/alternative; boundary="=_alternative 0078DDD385257199_=" This is a multipart message in MIME format. --=_alternative 0078DDD385257199_= Content-Type: text/plain; charset="us-ascii" Thanks Henning. Yes, I also definitely believe implementation complexity, both in network admin and in server side, is a big difference. The admin simplicity part is especially significant here. Anything that adds extra coordination, extra dependancies, or opportunity for error of any kind, will very greatly reduce overall reliability of location delivery. And the traceback process seems likely to be fragile also, adding to the admin complexity. Plus add a yet-to-be-defined wiremap-to-DHCP dB interface as a variable ... I can definitely say that implementing LLDP-MED in the client side is quite low complexity. -- Peter hgs@cs.columbia.edu 26.06.06 16:32 To: "Rosen, Brian" cc: "Henning Schulzrinne" , "Romascanu, Dan \(Dan\)" , peter_blatherwick@mitel.com, ecrit@ietf.org Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) In theory, yes. In practice, the DHCP server is often managed by different entities than the L2 infrastructure. (This seems to be fairly common on campuses.) In our local environment, your approach would be extremely difficult to implement, without a major network reorganization. > For the enterprise environment, I would think you would use the DHCP > relay option, which adds a circuit ID at the switch. That would be a > one step map (Circuit ID to location) at the DHCP server. It's a two > step configuration (have to assign the circuit ID on the switch, and > build the circuitId to location map), but still seems to be pretty close > to what you do with LLDP-MED. > > Brian --=_alternative 0078DDD385257199_= Content-Type: text/html; charset="us-ascii"
Thanks Henning.  

Yes, I also definitely believe implementation complexity, both in network admin and in server side, is a big difference.  The admin simplicity part is especially significant here.  Anything that adds extra coordination, extra dependancies, or opportunity for error of any kind, will very greatly reduce overall reliability of location delivery.  And the traceback process seems likely to be fragile also, adding to the admin complexity.  Plus add a yet-to-be-defined wiremap-to-DHCP dB interface as a variable ...    

I can definitely say that implementing LLDP-MED in the client side is quite low complexity.  

-- Peter




hgs@cs.columbia.edu

26.06.06 16:32

       
        To:        "Rosen, Brian" <Brian.Rosen@neustar.biz>
        cc:        "Henning Schulzrinne" <hgs@cs.columbia.edu>, "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>, peter_blatherwick@mitel.com, ecrit@ietf.org
        Subject:        RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft      wassubmitted)



In theory, yes. In practice, the DHCP server is often managed by different
entities than the L2 infrastructure. (This seems to be fairly common on
campuses.)  In our local environment, your approach would be extremely
difficult to implement, without a major network reorganization.

> For the enterprise environment, I would think you would use the DHCP
> relay option, which adds a circuit ID at the switch.  That would be a
> one step map (Circuit ID to location) at the DHCP server.  It's a two
> step configuration (have to assign the circuit ID on the switch, and
> build the circuitId to location map), but still seems to be pretty close
> to what you do with LLDP-MED.
>
> Brian

--=_alternative 0078DDD385257199_=-- --===============2146633033== 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 --===============2146633033==-- From ecrit-bounces@ietf.org Mon Jun 26 18:24:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuzUv-00072E-Hz; Mon, 26 Jun 2006 18:24:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuzUt-00071z-IQ for ecrit@ietf.org; Mon, 26 Jun 2006 18:24:00 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuzUt-0005iW-5O for ecrit@ietf.org; Mon, 26 Jun 2006 18:23:59 -0400 Received: from dhcp89-089-104.bbn.com ([128.89.89.104] helo=rwatro-xp.bbn.com) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FuzUr-000535-6D; Mon, 26 Jun 2006 18:23:58 -0400 Message-Id: <6.1.0.6.2.20060626165438.02a17eb0@po2.bbn.com> X-Sender: rwatro@po2.bbn.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Mon, 26 Jun 2006 18:23:57 -0400 To: "Tom-PT Taylor" ,ecrit@ietf.org From: Ron Watro Subject: Re: [Ecrit] Changes in the ECRIT security draft In-Reply-To: <44A040CE.5090101@nortel.com> References: <44A040CE.5090101@nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: skent@bbn.com X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Tom, I posted a few comments on the threats document back in late May and Hannes posted some replies. I did not follow up at that time and you may not have noticed these comments. For example, in section 5.1, you say that signalling to obtain fraudulent service will most likely not include any location information. Are you assuming that there is some mechanism that prevents a caller from creating spoofed location information? If not, then those attempting to obtain fraudulent service would seem likely to include bogus location data, to make their calls appear more genuine without revealing their true location. In general, to make VoIP E911 work, one will need a deterrent to DoS attacks against a PSAP. If a VoIP user can make a large number of calls to a PSAP without fear of retribution, then we are in trouble. When a VoIP caller is getting free service to reach a PSAP, there will be no authentication of that caller by a VoIP service provider. If that caller is generating its own (bogus) location information to insert into the free call, then it seems that we have the potential for a DoS attack. ECRIT could help address this problem by designing a protocol where a location server or an ISP issues a cryptographic token to a phone for use in marking its emergency calls. This could provide some deterrent to launching a DoS attack. Steve Kent and I have had brief discussions about this possibility. We haven't worked out any details yet but we would be happy to have discussions with interested parties either on this list or in Montreal next month. Cheers Ron Watro At 04:17 PM 6/26/2006, Tom-PT Taylor wrote: >I updated the ECRIT security draft to take account of comments Hannes >and by Kamran Aquil. The following changes are reflected in >draft-ietf-ecrit-security-threats-02.txt: > >1. Abstract: eliminated reference to ECRIT and highlighted the two >topics of the analysis by breaking them out into bullets. Added the word >"identified" in front of "threats" in the last senttence (typo noted). > >2. Changed the section headings to capitalized style. > >3. Introduction second para: deleted the parenthetic reference to >attempts to get free calling in the PSTN. Deleted the reference to the >ECRIT WG further down, replacing > "In view of the mandate of the ECRIT Working Group" >with > "While this can be a broad topic". > >4. Next para: replaced "ECRIT" with "emergency calling". > >5. Section 3 first para modified to eliminate references to ECRIT. > >Old: > > "The ECRIT Working Group has two work items relating to the routing of > emergency calls to their proper destination. The first is to enable > entities along the signalling path to recognize that a particular > signalling message is associated with an emergency call. The ECRIT > Working Group is defining content that can be added to the signalling > messages, an emergency identifier, for this purpose. Signalling > containing the emergency identifier may be given priority treatment, > special processing, and/or special routing." > >New: > > "This memo deals with two topics relating to the routing of emergency > calls to their proper destination. The first is the marking of call > signalling to enable entities along the signalling path to recognize > that a particular signalling message is associated with an emergency > call. Signalling containing the emergency identifier may be given > priority treatment, special processing, and/or special routing." > >6. Next para: deleted a reference to ECRIT. > >7. Section 4,third bullet of "attacks against the emergency response >system": deleted reference to ECRIT and rephrased to make the meaning >clearer. > >Old: > > "o to divert emergency responders to non-emergency sites. No attacks > affecting the ECRIT Working Group's decisions on the emergency > identifier and mapping protocol have been identified that achieve > this objective" > >New: > > "o to divert emergency responders to non-emergency sites. This memo > has not identified any attacks within its intended scope that > achieve this objective, so it will not be mentioned further." > >7. Section 5.1 bullet b. rewritten for more clarity: > >Old: > > "b. The call routing system assumes that the emergency caller's > device addresses emergency calls using the result of mapping > based on the caller's location." > >New: > > "b. The call routing system assumes that the emergency caller's > device signals the correct PSAP URI for the caller's location." > >8. Section 5.2.1 first para rewritten to take account of a point raised >by Hannes: that the call may never get to a PSAP at all. > >Old: > > "This section considers attacks intended to reduce the effectiveness > of the emergency response system for all callers in a given area. If > the mapping operation is disabled, the immediate effect is to > increase the probability that emergency calls are routed to the wrong > PSAP. This has a double consequence: emergency response to the > affected calls is delayed, and PSAP call taker resources outside the > immediate area of the emergency are consumed due to the extra effort > required to redirect the calls. Alternatively, attacks that cause > the client to receive a URI that does not lead to a PSAP have the > immediate effect of causing emergency calls to fail." > >New: > > "This section considers attacks intended to reduce the effectiveness > of the emergency response system for all callers in a given area. If > the mapping operation is disabled, then the emergency caller's device > might not have the correct PSAP URI. As a consequence, the > probability that emergency calls are routed to the wrong PSAP is > increased. In the worst case the emergency caller's device might not > be able to obtain a PSAP URI at all. Routing to the wrong PSAP has a > double consequence: emergency response to the affected calls is > delayed, and PSAP call taker resources outside the immediate area of > the emergency are consumed due to the extra effort required to > redirect the calls. Alternatively, attacks that cause the client to > receive a URI that does not lead to a PSAP have the immediate effect > of causing emergency calls to fail." > >9. Section 5.2.1, para beginning "In an impersonation attack, ..." >following the bullets, rewrote final sentence to make it clearer. > >Old: > > "However, the mapping protocol may help to protect against > acceptance of responses from an impersonating entity." > >New: > > "However, the mapping protocol may allow impersonation to > be detected, thereby preventing acceptance of responses from an > impersonating entity and possibly triggering a more secure discovery > procedure." > >10. Section 5.2.3 first para: added the word "Alternatively" at the >start of the sentence. > >11. Added Kamran Aquil to the Acknowledgements section (typo noted, sorry). > > > > > > > > > > > > > >_______________________________________________ >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 Jun 26 20:38:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv1bL-0005qp-SW; Mon, 26 Jun 2006 20:38:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv1bK-0005pg-KS for ecrit@ietf.org; Mon, 26 Jun 2006 20:38:46 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv1bJ-0003bZ-6s for ecrit@ietf.org; Mon, 26 Jun 2006 20:38:46 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k5R0cfM29207; Mon, 26 Jun 2006 20:38:41 -0400 (EDT) Received: from [127.0.0.1] ([47.130.16.176] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 20:38:26 -0400 Message-ID: <44A07DFD.7030501@nortel.com> Date: Mon, 26 Jun 2006 17:38:21 -0700 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Ron Watro Subject: Re: [Ecrit] Changes in the ECRIT security draft References: <44A040CE.5090101@nortel.com> <6.1.0.6.2.20060626165438.02a17eb0@po2.bbn.com> In-Reply-To: <6.1.0.6.2.20060626165438.02a17eb0@po2.bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2006 00:38:26.0391 (UTC) FILETIME=[00BE5670:01C69982] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: skent@bbn.com, 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 apologize, Ron. I noted the discussion when it happened, but failed to file it where it would pop out when I got around to updating the draft. Hannes gave you a response. I think there are one or two points I want to address, so I will go back and give one of my own. I might as well start with the points you carried over in this E-mail, then go back for the others. Ron Watro wrote: > Tom, > > I posted a few comments on the threats document back in late May and > Hannes posted some replies. I did not follow up at that time and you > may not have noticed these comments. For example, in section 5.1, you > say that signalling to obtain fraudulent service will most likely not > include any location information. Are you assuming that there is some > mechanism that prevents a caller from creating spoofed location > information? If not, then those attempting to obtain fraudulent service > would seem likely to include bogus location data, to make their calls > appear more genuine without revealing their true location. [PTT] I was trying to state a case that would make the difficulties clear -- that it would not be a simple matter of the network checking the URI in the signalling against location also given in that signalling, because the attacker would not be so obliging as to include the necessary information. Your idea is even messier, but doesn't change the basic point that the URI has to be checked out on its own merits. I'll change the text to say: "... or there could be location information, but it is false." > > In general, to make VoIP E911 work, one will need a deterrent to DoS > attacks against a PSAP. If a VoIP user can make a large number of calls > to a PSAP without fear of retribution, then we are in trouble. When a > VoIP caller is getting free service to reach a PSAP, there will be no > authentication of that caller by a VoIP service provider. If that > caller is generating its own (bogus) location information to insert into > the free call, then it seems that we have the potential for a DoS > attack. ECRIT could help address this problem by designing a protocol > where a location server or an ISP issues a cryptographic token to a > phone for use in marking its emergency calls. This could provide some > deterrent to launching a DoS attack. Steve Kent and I have had brief > discussions about this possibility. We haven't worked out any details > yet but we would be happy to have discussions with interested parties > either on this list or in Montreal next month. [PTT] Leaving aside the solution, which must be the subject of a different I-D, the question is whether I have overlooked a requirement. DOS attacks on the PSAP are not in scope of the present document. Use of the emergency identifier or location mapping to generate such attacks is in scope, but that's not what you're talking about here. > > Cheers > > Ron Watro > ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 26 22:13:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv34r-0007N9-BT; Mon, 26 Jun 2006 22:13:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv34q-0007N4-QX for ecrit@ietf.org; Mon, 26 Jun 2006 22:13:20 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv34p-0003du-Jd for ecrit@ietf.org; Mon, 26 Jun 2006 22:13:20 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 21:13:17 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 26 Jun 2006 21:13:16 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 21:13:15 -0500 Message-ID: From: "Thomson, Martin" To: , Date: Mon, 26 Jun 2006 21:13:14 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 27 Jun 2006 02:13:15.0924 (UTC) FILETIME=[3FF82D40:01C6998F] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: U-NAPTR draft thread-index: AcaZjz8OQ+jPUWCsTp2LbHKuWwnL9g== X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Ecrit] U-NAPTR draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1446607983==" Errors-To: ecrit-bounces@ietf.org --===============1446607983== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message Rm9yIHRob3NlIG9mIHlvdSB0aGF0IGFyZSBpbnRlcmVzdGVkIGluIHNlcnZpY2UgZGlzY292ZXJ5 LCB0aGlzIGRyYWZ0IG91dGxpbmVzIGFuIFMtTkFQVFItbGlrZSBERERTIGFwcGxpY2F0aW9uIHRo YXQgaXMgYWJsZSB0byByZXR1cm4gVVJJczoNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtZGFpZ2xlLXVuYXB0ci0wMC50eHQNCg0KQ3Jvc3MtcG9zdGVkIGZvciBp dHMgcmVsZXZhbmNlIHRvIGJvdGggTG9TVCBhbmQgdGhlIEdFT1BSSVYgTDcgd29yay4NCg0KUmVn YXJkcywNCk1hcnRpbiANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBt YXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRl IGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4g IEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJd --===============1446607983== 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 --===============1446607983==-- From ecrit-bounces@ietf.org Tue Jun 27 04:22:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv8q9-0003Yg-WC; Tue, 27 Jun 2006 04:22:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv8q8-0003YY-Tr for ecrit@ietf.org; Tue, 27 Jun 2006 04:22:32 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fv8q6-0006Qj-Kz for ecrit@ietf.org; Tue, 27 Jun 2006 04:22:32 -0400 Received: (qmail invoked by alias); 27 Jun 2006 08:22:29 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp030) with SMTP; 27 Jun 2006 10:22:29 +0200 X-Authenticated: #29516787 Message-ID: <44A0EAC3.4010204@gmx.net> Date: Tue, 27 Jun 2006 10:22:27 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Ecrit] 3GPP CT1 - IETF ECRIT Joint Session on Emergency Calls X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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 scheduled a meeting with 3GPP folks to get a better understanding of the Emergency Service architecture and the ongoing work in the IETF ECRIT WG and the 3GPP CT1 about this subject. Please find the tentative agenda at: http://www.ietf-ecrit.org/3GPP-IETF-2006/Agenda.pdf Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 27 09:27:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvDbJ-00077u-E3; Tue, 27 Jun 2006 09:27:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvDbI-00074b-Di for ecrit@ietf.org; Tue, 27 Jun 2006 09:27:32 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvDbH-00078Z-3i for ecrit@ietf.org; Tue, 27 Jun 2006 09:27:32 -0400 Received: from dhcp89-089-104.bbn.com ([128.89.89.104] helo=rwatro-xp.bbn.com) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FvDbF-00012X-54; Tue, 27 Jun 2006 09:27:29 -0400 Message-Id: <6.1.0.6.2.20060627090049.02a8ea40@po2.bbn.com> X-Sender: rwatro@po2.bbn.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Tue, 27 Jun 2006 09:27:28 -0400 To: "Tom-PT Taylor" From: Ron Watro Subject: Re: [Ecrit] Changes in the ECRIT security draft In-Reply-To: <44A07DFD.7030501@nortel.com> References: <44A040CE.5090101@nortel.com> <6.1.0.6.2.20060626165438.02a17eb0@po2.bbn.com> <44A07DFD.7030501@nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: skent@bbn.com, 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 Tom, Thanks for the quick reply. I agree with your first point. Regarding the 2nd issue, I understand your logic, which (roughly put) is that the location/URI servers and protocols aren't the root source of the DOS on PSAP problem, so they don't need to deal with it; they just shouldn't make it any worse. Unfortunately though, *somebody* needs to deal with this problem somewhere in the VoIP E911 system, and the location servers and protocols are one obvious candidate. If ECRIT wants to pass on this issue, I think the security doc should at least point out that future modifications to the protocols may be needed to address these sorts of security problems. Ideally, we should have a system security analysis for VoIP E911, and this would drive what is in scope and out of scope for ECRIT. Cheers Ron At 08:38 PM 6/26/2006, Tom-PT Taylor wrote: >I apologize, Ron. I noted the discussion when it happened, but failed to >file it where it would pop out when I got around to updating the draft. > >Hannes gave you a response. I think there are one or two points I want to >address, so I will go back and give one of my own. I might as well start >with the points you carried over in this E-mail, then go back for the others. > >Ron Watro wrote: >>Tom, >>I posted a few comments on the threats document back in late May and >>Hannes posted some replies. I did not follow up at that time and you may >>not have noticed these comments. For example, in section 5.1, you say >>that signalling to obtain fraudulent service will most likely not include >>any location information. Are you assuming that there is some mechanism >>that prevents a caller from creating spoofed location information? If >>not, then those attempting to obtain fraudulent service would seem likely >>to include bogus location data, to make their calls appear more genuine >>without revealing their true location. > >[PTT] I was trying to state a case that would make the difficulties clear >-- that it would not be a simple matter of the network checking the URI in >the signalling against location also given in that signalling, because the >attacker would not be so obliging as to include the necessary information. >Your idea is even messier, but doesn't change the basic point that the URI >has to be checked out on its own merits. I'll change the text to say: "... >or there could be location information, but it is false." >>In general, to make VoIP E911 work, one will need a deterrent to DoS >>attacks against a PSAP. If a VoIP user can make a large number of calls >>to a PSAP without fear of retribution, then we are in trouble. When a >>VoIP caller is getting free service to reach a PSAP, there will be no >>authentication of that caller by a VoIP service provider. If that caller >>is generating its own (bogus) location information to insert into the >>free call, then it seems that we have the potential for a DoS >>attack. ECRIT could help address this problem by designing a protocol >>where a location server or an ISP issues a cryptographic token to a phone >>for use in marking its emergency calls. This could provide some >>deterrent to launching a DoS attack. Steve Kent and I have had brief >>discussions about this possibility. We haven't worked out any details >>yet but we would be happy to have discussions with interested parties >>either on this list or in Montreal next month. > >[PTT] Leaving aside the solution, which must be the subject of a different >I-D, the question is whether I have overlooked a requirement. DOS attacks >on the PSAP are not in scope of the present document. Use of the emergency >identifier or location mapping to generate such attacks is in scope, but >that's not what you're talking about here. >>Cheers >>Ron Watro >... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 27 17:15:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKuK-0006FK-I6; Tue, 27 Jun 2006 17:15:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKuJ-0006FA-Vb for ecrit@ietf.org; Tue, 27 Jun 2006 17:15:39 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvKuI-0004wj-LU for ecrit@ietf.org; Tue, 27 Jun 2006 17:15:39 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 27 Jun 2006 14:15:35 -0700 X-IronPort-AV: i="4.06,184,1149490800"; d="scan'208"; a="431402281:sNHT30164220" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k5RLFZvD006919 for ; Tue, 27 Jun 2006 14:15:35 -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 k5RLFZ9s001118 for ; Tue, 27 Jun 2006 14:15:35 -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.211); Tue, 27 Jun 2006 14:15:34 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Jun 2006 14:15:34 -0700 From: "Marc Linsner" To: Date: Tue, 27 Jun 2006 17:15:29 -0400 Message-ID: <01c001c69a2e$d1633230$240d0d0a@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.2869 Thread-Index: AcaaLtAhfrhjO/CxQWq846zzwVFneg== X-OriginalArrivalTime: 27 Jun 2006 21:15:34.0551 (UTC) FILETIME=[D42CB270:01C69A2E] DKIM-Signature: a=rsa-sha1; q=dns; l=94; t=1151442935; x=1152306935; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:Montreal=20ecrit=20agenda; X=v=3Dcisco.com=3B=20h=3DhXYxdAkQY0Uy+YIMg7rdq29wkBI=3D; b=qFErxU9hxTyD7lP25/+JwnPOtcuiaWh1neWmiczBKsxq7CbeX5qxhgTyo7/GjjghMFY4rJ+9 R0s+PiykhlESlTIZk2kjPrmh14+fEzqqt+62oWFx3licdHySVUUzxfkb; Authentication-Results: sj-dkim-1.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [Ecrit] Montreal 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 If you want time on the Montreal agenda for ecrit, let Hannes and I know. -Marc & Hannes- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 27 17:36:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvLEk-00010I-Pb; Tue, 27 Jun 2006 17:36:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvLEj-0000wR-3U for ecrit@ietf.org; Tue, 27 Jun 2006 17:36:45 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FvLEg-0006nf-M1 for ecrit@ietf.org; Tue, 27 Jun 2006 17:36:45 -0400 Received: (qmail invoked by alias); 27 Jun 2006 21:36:40 -0000 Received: from p54986463.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.100.99] by mail.gmx.net (mp035) with SMTP; 27 Jun 2006 23:36:40 +0200 X-Authenticated: #29516787 Message-ID: <44A1A4E5.9020804@gmx.net> Date: Tue, 27 Jun 2006 23:36:37 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Ecrit] Montreal ecrit agenda References: <01c001c69a2e$d1633230$240d0d0a@amer.cisco.com> In-Reply-To: <01c001c69a2e$d1633230$240d0d0a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 A small note: * I guess we don't want to speak about - the requirements draft - the security threats draft - the service URN draft * We do want to talk about the - LoST - Mapping Protocol Architecture - ECRIT framework draft - Phone BCP - James's other drafts; too many to list them in this mail :-) Anything else? Ciao Hannes PS: We might also want to summarize the 3GPP CT1 - IETF ECRIT Joint Session on Emergency Calls. Marc Linsner wrote: > If you want time on the Montreal agenda for ecrit, let Hannes and I know. > > -Marc & Hannes- > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 29 04:45:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvs9A-00058x-Vi; Thu, 29 Jun 2006 04:45:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvs99-000583-TF; Thu, 29 Jun 2006 04:45:11 -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 1FvqoE-0001fy-7y; Thu, 29 Jun 2006 03:19:30 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvqLi-0002I1-Hj; Thu, 29 Jun 2006 02:50:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5T6o29F017695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Jun 2006 06:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvqLi-00007l-4X; Thu, 29 Jun 2006 02: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: Thu, 29 Jun 2006 02:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-security-threats-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 : Security Threats and Requirements for Emergency Call Marking and Mapping Author(s) : T. Taylor, et al. Filename : draft-ietf-ecrit-security-threats-02.txt Pages : 18 Date : 2006-6-28 This document reviews the security threats associated with: o the marking of signalling messages to indicate that they are related to an emergency; and o the process of mapping from locations to Universal Resource Identifiers (URIs) pointing to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network. Based on the idnetified threats, this document establishes a set of security requirements for the the mapping protocol and for the handling of emergency-marked calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-security-threats-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-security-threats-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-security-threats-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-6-28214633.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-security-threats-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-security-threats-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-28214633.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 Jun 29 16:19:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw2yp-0001g8-Ds; Thu, 29 Jun 2006 16:19:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw2yo-0001fQ-5v for ecrit@ietf.org; Thu, 29 Jun 2006 16:19:14 -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 1Fw2ym-0005Hh-Qi for ecrit@ietf.org; Thu, 29 Jun 2006 16:19:14 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 29 Jun 2006 13:19:12 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5TKJCrf024390; Thu, 29 Jun 2006 13:19:12 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5TKJCke008904; Thu, 29 Jun 2006 13:19:12 -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.211); Thu, 29 Jun 2006 13:19:12 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.96.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Jun 2006 13:19:11 -0700 Message-Id: <4.3.2.7.2.20060629145440.036567f0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Jun 2006 15:19:10 -0500 To: "'ecrit@ietf.org'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 29 Jun 2006 20:19:11.0668 (UTC) FILETIME=[48A53740:01C69BB9] DKIM-Signature: a=rsa-sha1; q=dns; l=2499; t=1151612352; x=1152476352; c=relaxed/simple; s=sjdkim3001; 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:Several=20IDs=20recently=20submitted=20by=20me; X=v=3Dcisco.com=3B=20h=3Dt6rshECVRBKVeMLfWFPE+GEsCX8=3D; b=wHiRAeDMgU966i/wRnIgXhNQvUhCgfEmV9zsOiilX6QDXH6oUUv0SHOhC5dDl67qIhpgkfzL AxmszVtrzWjep2H7Td5gj55qPkotq/FPal6wqd6XHXmqgivSnUHC9Aud; Authentication-Results: sj-dkim-3.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [Ecrit] Several IDs recently submitted by me X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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 I've recently submitted several new IDs as individual submissions involving the scope near or of this WG. All proposed new DHCP Options involving emergency services are to be discussed on the ECRIT list now. This was worked out by both sets of WG chairs. http://www.ietf.org/internet-drafts/draft-polk-dhc-ecrit-lost-server-uri-00.txt defines a new DHCP Option for requesting and returning a LoST Server URI to a client. This indicates to a endsystem where to send its initial LoST query as the access provider (SP, SMB or Enterprise) sees it. Sometimes a Voice Service Provider (think Vonage) may want or need (perhaps by law or just strong guidance) to provide which LoST server(s) an endsystem sends its initial LoST query to. This is addressed in: http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost-server-uri-00.txt as part of an endsystem's SIP Registration transaction. Some here are have a position that LoST should be the only means to learn an emergency dialstring. As utopian an idea as I think this is, I do not believe this WG should be making implementation decisions for every infrastructure type or for every domain administration. There may be real reasons for using an existing protocol, with a small extension, to solve this dialstring-to-the-phone issue. http://www.ietf.org/internet-drafts/draft-polk-ecrit-dhc-emergency-dialstring-option-00.txt solves this using DHCP, and another ID: http://www.ietf.org/internet-drafts/draft-polk-ecrit-emergency-dialstring-00.txt solves this during SIP Registration. This latter transaction could yield both an emergency dialstring and a LoST URI in the same SIP 200 OK response message, making the messaging extremely efficient, and controllable by the application layer Voice SP - again, which may be forced on them by local laws or guidance. Since it is already highly advisable to use TLS during SIP Registration, confidentiality and integrity are covered without anything newly defined here. Finally, there may be infrastructures that want DHCP to provide a PSAP/ESRP URI in DHCP. These infrastuctures would/should be of a more contained type of infrastructure, like a smaller or single site enterprise network, and I have no issues with the Framework or phoneBCP stating this recommended limitation. But in such cases, I believe: http://www.ietf.org/internet-drafts/draft-polk-dhc-ecrit-uri-psap-esrp-00.txt addresses this solution space. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 29 17:11:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw3nZ-0001eB-Ey; Thu, 29 Jun 2006 17:11:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw2bw-0003nI-Kq for ecrit@ietf.org; Thu, 29 Jun 2006 15:55:37 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw2bs-00034v-VI for ecrit@ietf.org; Thu, 29 Jun 2006 15:55:34 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 29 Jun 2006 12:52:32 -0700 X-IronPort-AV: i="4.06,193,1149490800"; d="scan'208"; a="326449415:sNHT31493388" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5TJqVka010649 for ; Thu, 29 Jun 2006 12:52:31 -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 k5TJqVCU000302 for ; Thu, 29 Jun 2006 12:52:31 -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.211); Thu, 29 Jun 2006 12:52:31 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.96.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Jun 2006 12:52:30 -0700 Message-Id: <4.3.2.7.2.20060629145053.0281db70@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Jun 2006 14:52:30 -0500 To: "'ecrit@ietf.org'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 29 Jun 2006 19:52:30.0965 (UTC) FILETIME=[8E8D5250:01C69BB5] DKIM-Signature: a=rsa-sha1; q=dns; l=2160; t=1151610751; x=1152474751; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:SIP=20Location=20Conveyance=20-03=20submitted; X=v=3Dcisco.com=3B=20h=3D6h/pu6K51uDgq0u9cNl4mnfGp6w=3D; b=ORSKdeQ8m/WUFmRhMJeCr6VBiupZbx7aZw5tk+J26akGNVX2RVJxrmDcY7Amv5IP2vhT40rL CvydJ1m/i9sh7ORWOR8GIGASd2NxlAXi71lJqclRNrIYcbtl3LdUQVrS; Authentication-Results: sj-dkim-2.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Ecrit] SIP Location Conveyance -03 submitted X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org ECRIT WG here is the forwarded message I sent to the SIP WG list indicating a new version of the SIP Location Conveyance ID is now available for review and comments (on the SIP list please!) >Date: Thu, 29 Jun 2006 14:50:44 -0500 >To: sip@ietf.org >From: "James M. Polk" >Subject: SIP Location Conveyance -03 submitted > >I've submitted -03 of the SIP Location Conveyance ID for review and comments. > >http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-03.txt > > This is a list of the changes that have been made from the SIP WG > version -02 to this version -03: > > - general clean-up of some of the sections > > - removed the message examples from the UPDATE, MESSAGE and REGISTER > sections, as these seemed to be making the doc less readable, and > not more readable > > - removed the "unknown" option tag, as it was not needed with a > certain combination of the Supported and Location headers > > - clarified the location option tag usage in Supported, Require, > Unsupported, and that it shouldn't be used in Proxy-Require, and > why not. > > - Added a basic message flow to the basic operation section (Section > 4) to aid in understanding of this SIP extension. > > - Added a message routing flow, which is based on the location of > the requestor to show how a SIP server can make a routing decision > to a destination based on where the UAC is. > > - Articulated how a UAS concludes a UAC understands this extension, > yet does not know its location to provide to the UAS. This is > helpful in those times where an intermediary will act differently > based on whether or not a UAC understands this extension, and > whether or not the UAC includes its location in the request. > > - Corrected the erroneous text regarding an Unsupported header being > in a 424 response. It belongs in a 420 response. (Section 5.1) > > - Corrected the BNF (I hope) > > - Corrected some text in Section 5 that read like this document was > an update to RFC 3261. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 29 18:30:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw51n-000614-Cq; Thu, 29 Jun 2006 18:30:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw51l-0005h3-HD for Ecrit@ietf.org; Thu, 29 Jun 2006 18:30:25 -0400 Received: from py-out-1112.google.com ([64.233.166.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw51k-0005WU-1N for Ecrit@ietf.org; Thu, 29 Jun 2006 18:30:25 -0400 Received: by py-out-1112.google.com with SMTP id x31so9793pye for ; Thu, 29 Jun 2006 15:29:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=MlLLoxnOL1Zk7icV/HAdZ6oZdsjRXJiWW/wt+2Oh2KhPucuj//4J7MNl9dmzhLhkxDVd6oBkBRozZCOrVFqNafbnSBNN02NM3zexjiI15MM0vMvvQq1JilGHpdv5epj5sSesOgYbiB7ahIJ3hPBqJG4bz4ZMM/cHsQWE2x6GxnA= Received: by 10.35.88.18 with SMTP id q18mr2081916pyl; Thu, 29 Jun 2006 15:29:50 -0700 (PDT) Received: by 10.35.81.17 with HTTP; Thu, 29 Jun 2006 15:29:50 -0700 (PDT) Message-ID: <953beacc0606291529k4fc655adu3e8719ef3993bde9@mail.gmail.com> Date: Thu, 29 Jun 2006 15:29:50 -0700 From: "Rohan Mahy" To: "peter_blatherwick@mitel.com" Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft was submitted) In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.6 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: "Rosen, Brian" , Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1241729759==" Errors-To: ecrit-bounces@ietf.org --===============1241729759== Content-Type: multipart/alternative; boundary="----=_Part_17654_14373221.1151620190468" ------=_Part_17654_14373221.1151620190468 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Peter, Some comments inline. To be clear, I do not have a strong feeling about what does on Brian's list or not. I think LLDP-MED is a completely reasonable thing for a wired phone vendor to implement on enterprise class phones. On 6/26/06, peter_blatherwick@mitel.com wrote: > Brian, list, > > > ... I think we want to have a discussion on whether LLDP-MED is on that > list. > > As might be expected, I definitely support LLDP-MED as one on that list of > location methods. Some key points in favour I believe are: > > o LLDP-MED works at Layer 2, which is where real location comes from. > Closest to source is better. > ...As opposed to working at the application layer, where real application security comes from. Closer to the application is better? I don't want to have a debate about layer 2 vs. layer 7 location here, just point out that the answer you get depends on what you are willing to tradeoff. o Access network elements (L2 switches typically) need to be configured > anyway, and while the admin is touching them, location can be entered > readily. > > o Wire map associated with L2 access needs to be created and maintained > anyway. (DHCP method would require it to be put in a different, possibly > unrelated dB.) > I'll point out that in the wireless case, the location of the station is also often in an unrelated place to the the L2 access device. o Simple and direct, no intermediate mechanisms needed. (Eg. no need to turn > on DHCP relay, insert DHCP relay agent sub-options, etc.) Less dependancies > is better. > > o No need for any additional interfaces in LLDP-MED method -- all > interfaces are already defined. In DHCP method (and presumably L7 also ?) > an interface to DHCP server, to interface to the wiremap dB, would need to > be defined to have a fully standards-based approach. (In LLDP-MED, the > wiremap dB interface is effectively done through SNMP and the defined MIBs, > and the data becomes distributed across the L2 infrastructure.) > > o Can be made to work with wireless mobility as well. Currently, LLDP-MED > can locate down to the Access Point only (since the wireless environment > does not yet have a standard way to do triangulation or similar), however > would be relatively straight-forward to extend to higher accuracy. (DHCP is > completely inappropriate for wireless mobility IMHO.) > LLDP-MED does not work in an 802.11 wireless LAN environment. The assumptions made in LLDP-MED about link reliability, authentication, bandwidth availability, timing, and lack of mobility are grossly inappropriate in a WLAN environment. IEEE 802.11 Task Group V is working on a Layer 2 approach of their own, which is significantly better than LLDP-MED on these regards: ftp://ieee:wireless@ftp.802wirelessworld.com/11/06/11-06-0010-01-000v-location-presentation.ppt ftp://ieee:wireless@ftp.802wirelessworld.com/11/06/11-06-0009-03-000v-location-proposal.doc There were still some big issues in the posted version. I provided a bunch of comments to one of the authors after that version was published, at the last 802.11 interim. I would expect the draft will be updated shortly before the next 802.11 plenary in San Diego (the week after IETF 66). Personally, I think above points make best case to use LLDP-MED in a managed > enterprise environment. That's a BIG market segment! Other methods may be > more appropriate in different environments. > I am personally much more interested in location (emergency and otherwise) for wireless LAN devices than for wired devices. The user of a wireless LAN device is much less likely to know their own location than a user of a wired LAN devices. This is a fast growing market segment because people want mobility once the price is right and the quality is good enough. Yes, we need to solve wired location, but lets not forget the wireless communities. thanks, -rohan ------=_Part_17654_14373221.1151620190468 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Peter,

Some comments inline.  To be clear, I do not have a strong feeling about what does on Brian's list or not.  I think LLDP-MED is a completely reasonable thing for a wired phone vendor to implement on enterprise class phones.

On 6/26/06, peter_blatherwick@mitel.com <peter_blatherwick@mitel.com > wrote:
Brian, list,  

> ... I think we want to have a discussion on whether LLDP-MED is on that list.

As might be expected, I definitely support LLDP-MED as one on that list of location methods.  Some key points in favour I believe are:  

o LLDP-MED works at Layer 2, which is where real location comes from.  Closest to source is better. 

...As opposed to working at the application layer, where real application security comes from.  Closer to the application is better?   I don't want to have a debate about layer 2 vs. layer 7 location here, just point out that the answer you get depends on what you are willing to tradeoff.

o Access network elements (L2 switches typically) need to be configured anyway, and while the admin is touching them, location can be entered readily.  

o Wire map associated with L2 access needs to be created and maintained anyway.  (DHCP method would require it to be put in a different, possibly unrelated dB.)  

I'll point out that in the wireless case, the location of the station is also often in an unrelated place to the the L2 access device. 

o Simple and direct, no intermediate mechanisms needed. (Eg. no need to turn on DHCP relay, insert DHCP relay agent sub-options, etc.)  Less dependancies is better.    

o No need for any additional interfaces in LLDP-MED method -- all interfaces are already defined.  In DHCP method (and presumably L7 also ?) an interface to DHCP server, to interface to the wiremap dB, would need to be defined to have a fully standards-based approach.   (In LLDP-MED, the wiremap dB interface is effectively done through SNMP and the defined MIBs, and the data becomes distributed across the L2 infrastructure.)  

o Can be made to work with wireless mobility as well.  Currently, LLDP-MED can locate down to the Access Point only (since the wireless environment does not yet have a standard way to do triangulation or similar), however would be relatively straight-forward to extend to higher accuracy.  (DHCP is completely inappropriate for wireless mobility IMHO.)  

LLDP-MED does not work in an 802.11 wireless LAN environment.  The assumptions made in LLDP-MED about link reliability, authentication, bandwidth availability, timing, and lack of mobility are grossly inappropriate in a WLAN environment.

IEEE 802.11 Task Group V is working on a Layer 2 approach of their own, which is significantly better than LLDP-MED on these regards:

ftp://ieee:wireless@ftp.802wirelessworld.com/11/06/11-06-0010-01-000v-location-presentation.ppt
ftp://ieee:wireless@ftp.802wirelessworld.com/11/06/11-06-0009-03-000v-location-proposal.doc
 
There were still some big issues in the posted version.  I provided a bunch of comments to one of the authors after that version was published, at the last 802.11 interim.  I would expect the draft will be updated shortly before the next 802.11 plenary in San Diego (the week after IETF 66).

Personally, I think above points make best case to use LLDP-MED in a managed enterprise environment.  That's a BIG market segment!  Other methods may be more appropriate in different environments.  

I am personally much more interested in location (emergency and otherwise) for wireless LAN devices than for wired devices.  The user of a wireless LAN device is much less likely to know their own location than a user of a wired LAN devices.  This is a fast growing market segment because people want mobility once the price is right and the quality is good enough.  Yes, we need to solve wired location, but lets not forget the wireless communities.

thanks,
-rohan
 

------=_Part_17654_14373221.1151620190468-- --===============1241729759== 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 --===============1241729759==-- From ecrit-bounces@ietf.org Fri Jun 30 08:32:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwIAr-0007mb-Ne; Fri, 30 Jun 2006 08:32:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwIAp-0007mW-Dz for ecrit@ietf.org; Fri, 30 Jun 2006 08:32:39 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwIAm-0000W0-TJ for ecrit@ietf.org; Fri, 30 Jun 2006 08:32:39 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k5UCWZw5016555 for ; Fri, 30 Jun 2006 14:32:35 +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 k5UCWWOY012784 for ; Fri, 30 Jun 2006 14:32:35 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 14:32:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 Jun 2006 14:32:17 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECRIT Agenda thread-index: AcacQTlew7F2hktKRZiVT143EXjMdQ== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 30 Jun 2006 12:32:33.0175 (UTC) FILETIME=[42A7FA70:01C69C41] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [Ecrit] 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: , Content-Type: multipart/mixed; boundary="===============1070554214==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1070554214== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69C41.427D00B8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69C41.427D00B8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 we have uploaded a first agenda proposal. Please find it here: http://www3.ietf.org/proceedings/06jul/agenda/ecrit.txt We need feedback about the persons giving the presentations.=20 Is anything missing?=20 Ciao Hannes ------_=_NextPart_001_01C69C41.427D00B8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ECRIT Agenda

Hi all,

we have uploaded a first agenda = proposal. Please find it here:
http://www3.ietf.org/proceedings/06jul/agenda/ecrit.txt

We need feedback about the persons = giving the presentations.

Is anything missing?

Ciao
Hannes

------_=_NextPart_001_01C69C41.427D00B8-- --===============1070554214== 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 --===============1070554214==-- From ecrit-bounces@ietf.org Fri Jun 30 09:36:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwJAK-0000qo-Kd; Fri, 30 Jun 2006 09:36:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwJAJ-0000qj-5W for ecrit@ietf.org; Fri, 30 Jun 2006 09:36:11 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FwJAH-0006NX-NZ for ecrit@ietf.org; Fri, 30 Jun 2006 09:36:11 -0400 Received: (qmail invoked by alias); 30 Jun 2006 13:29:28 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp015) with SMTP; 30 Jun 2006 15:29:28 +0200 X-Authenticated: #29516787 Message-ID: <44A52735.2050108@gmx.net> Date: Fri, 30 Jun 2006 15:29:25 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ecrit] ECRIT WG Status X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, the following three documents are in good shape and passed the WGLC: - draft-ietf-ecrit-requirements-10.txt - draft-ietf-ecrit-service-urn-03.txt - draft-ietf-ecrit-security-threats-02.txt After Tom shipped another draft update to address the comments sent by Ron (see http://www1.ietf.org/mail-archive/web/ecrit/current/msg02231.html) we are going to forward them to Jon & Cullen/IESG. Comments? We have also submitted the rechartering proposal as discussed on the mailing list. You can find the submitted version here: http://www.ietf-ecrit.org/TEMP/ECRIT-Rechartering.txt Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 30 09:44:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwJHs-0002sh-OX; Fri, 30 Jun 2006 09:44:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwJHr-0002gy-0c for Ecrit@ietf.org; Fri, 30 Jun 2006 09:43:59 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwJHp-0007lP-KI for Ecrit@ietf.org; Fri, 30 Jun 2006 09:43:58 -0400 Received: from [10.0.1.105] ([::ffff:68.106.115.242]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 30 Jun 2006 09:44:16 -0400 id 01588120.44A52AB0.00007F27 In-Reply-To: <953beacc0606291529k4fc655adu3e8719ef3993bde9@mail.gmail.com> References: <953beacc0606291529k4fc655adu3e8719ef3993bde9@mail.gmail.com> Mime-Version: 1.0 Message-Id: From: Andrew Newton Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft was submitted) Date: Fri, 30 Jun 2006 09:43:53 -0400 To: "Rohan Mahy" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: "Rosen, Brian" , Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0853209030==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0853209030== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-32555-1151675057-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-32555-1151675057-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote: > To be clear, I do not have a strong feeling about what does on > Brian's list or not. I think LLDP-MED is a completely reasonable > thing for a wired phone vendor to implement on enterprise class > phones. Just throwing in my $0.0199997, I have not formed a strong opinion about this either. It does seem reasonable for enterprise class devices with ethernet jacks to implement LLPD-MED, or for devices of category Y to implement method X... as what must be implemented by the device will always be dictated by the network media it uses. Where this gets a little tricky is that if there is no one common method, then devices may end up implementing things that are not appropriate in an attempt to have devices that work in multiple network environments... and even then they may end up missing the mark. Therefore, one method that does work in all environments must be implemented. And that is likely to be the L7-LCP. -andy --=_zeke.ecotroph.net-32555-1151675057-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.0
On Jun 29, 2006, at 6:2= 9 PM, Rohan Mahy wrote:

To be clear, I do not have a s= trong feeling about what does on Brian's list or not.=A0 I think LLDP-MED= is a completely reasonable thing for a wired phone vendor to implement o= n enterprise class phones.=A0

Just throwing in my $0.0199997, I hav= e not formed a strong opinion about this either.=A0 It does seem reasonab= le for enterprise class devices with ethernet jacks to implement LLPD-MED= , or for devices of category Y to implement method X... as what must be i= mplemented by the device will always be dictated by the network media it = uses.

Where th= is gets a little tricky is that if there is no one common method, then de= vices may end up implementing things that are not appropriate in an attem= pt to have devices that work in multiple network environments... and even= then they may end up missing the mark.=A0 Therefore, one method that doe= s work in all environments must be implemented.=A0 =A0And that is likely = to be the L7-LCP.

<= DIV>-andy --=_zeke.ecotroph.net-32555-1151675057-0001-2-- --===============0853209030== 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 --===============0853209030==-- From ecrit-bounces@ietf.org Fri Jun 30 10:48:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwKIP-0007yK-Gj; Fri, 30 Jun 2006 10:48:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwKIO-0007y3-4s for Ecrit@ietf.org; Fri, 30 Jun 2006 10:48:36 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwKIM-0003VI-D0 for Ecrit@ietf.org; Fri, 30 Jun 2006 10:48:36 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 030C72004C; Fri, 30 Jun 2006 10:48:34 -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 14172-03; Fri, 30 Jun 2006 10:48:33 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 69D2B20026; Fri, 30 Jun 2006 10:48:33 -0400 (EDT) To: "Rohan Mahy" Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft was submitted) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: peter_blatherwick@mitel.com Date: Fri, 30 Jun 2006 10:48:31 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 06/30/2006 10:48:32 AM, Serialize complete at 06/30/2006 10:48:32 AM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.8 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: "Rosen, Brian" , Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0301641408==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============0301641408== Content-Type: multipart/alternative; boundary="=_alternative 005158948525719D_=" This is a multipart message in MIME format. --=_alternative 005158948525719D_= Content-Type: text/plain; charset="us-ascii" Hi Rohan, > LLDP-MED does not work in an 802.11 wireless LAN environment. The assumptions > made in LLDP-MED about link reliability, authentication, bandwidth availability, timing, > and lack of mobility are grossly inappropriate in a WLAN environment. Actually, LLDP-MED can be used in WLAN scenarios for location, with the constraint that it can only locate to the AP today. See LLDP-MED spec, Annex C for discussion of this. At this point in time, there is no solution in WLAN to resolve closer than the AP. To your points... If the wireless link becomes unreliable, then all methods are off. Auth is not really a strong requirement (IMHO) in this scenario, at least in enterprise. And, bw availability & timing are non-issues due to the very small size and periodic advertisements inherent in LLDP -- the other proposed methods use more bw and/or have difficulty getting updates on the fly. (Don't understand what you mean by "lack of mobility".) Yes, an imperfect solution, however reasonably practical at this time. > I am personally much more interested in location (emergency and otherwise) for wireless > LAN devices than for wired devices. The user of a wireless LAN device is much less > likely to know their own location than a user of a wired LAN devices. This is a fast > growing market segment because people want mobility once the price is right and the > quality is good enough. Yes, we need to solve wired location, but lets not forget the > wireless communities. I both agree and disagree here. Wired ethernet is by far the dominant case today in enterprise scenarios, therefore this is the biggest interest for me at this point in time. LLDP-MED is already being supported by several vendors in enterprise space, and is proving to be pretty easy to work with, so makes a good choice there IMHO. Of course I do very much agree we need to fully solve WLAN also, both enterprise and public, however it is lagging in large part due to lack of a well agreed / standardized method of doing the actual location (triangulation or otherwise). The work is ongoing, but will take time. Thanks for aiming at the IEEE work. I was aware, but have not been able to keep up with it in detail. If I understand correctly (may be dubious) it appears that yet a 4th location method might be required to support this. (I can hear Brian groaning as I type ;-) -- Peter "Rohan Mahy" 29.06.06 18:29 To: "peter_blatherwick@mitel.com" cc: "Rosen, Brian" , Ecrit@ietf.org Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft was submitted) Hi Peter, Some comments inline. To be clear, I do not have a strong feeling about what does on Brian's list or not. I think LLDP-MED is a completely reasonable thing for a wired phone vendor to implement on enterprise class phones. On 6/26/06, peter_blatherwick@mitel.com wrote: Brian, list, > ... I think we want to have a discussion on whether LLDP-MED is on that list. As might be expected, I definitely support LLDP-MED as one on that list of location methods. Some key points in favour I believe are: o LLDP-MED works at Layer 2, which is where real location comes from. Closest to source is better. ...As opposed to working at the application layer, where real application security comes from. Closer to the application is better? I don't want to have a debate about layer 2 vs. layer 7 location here, just point out that the answer you get depends on what you are willing to tradeoff. o Access network elements (L2 switches typically) need to be configured anyway, and while the admin is touching them, location can be entered readily. o Wire map associated with L2 access needs to be created and maintained anyway. (DHCP method would require it to be put in a different, possibly unrelated dB.) I'll point out that in the wireless case, the location of the station is also often in an unrelated place to the the L2 access device. o Simple and direct, no intermediate mechanisms needed. (Eg. no need to turn on DHCP relay, insert DHCP relay agent sub-options, etc.) Less dependancies is better. o No need for any additional interfaces in LLDP-MED method -- all interfaces are already defined. In DHCP method (and presumably L7 also ?) an interface to DHCP server, to interface to the wiremap dB, would need to be defined to have a fully standards-based approach. (In LLDP-MED, the wiremap dB interface is effectively done through SNMP and the defined MIBs, and the data becomes distributed across the L2 infrastructure.) o Can be made to work with wireless mobility as well. Currently, LLDP-MED can locate down to the Access Point only (since the wireless environment does not yet have a standard way to do triangulation or similar), however would be relatively straight-forward to extend to higher accuracy. (DHCP is completely inappropriate for wireless mobility IMHO.) LLDP-MED does not work in an 802.11 wireless LAN environment. The assumptions made in LLDP-MED about link reliability, authentication, bandwidth availability, timing, and lack of mobility are grossly inappropriate in a WLAN environment. IEEE 802.11 Task Group V is working on a Layer 2 approach of their own, which is significantly better than LLDP-MED on these regards: ftp://ieee:wireless@ftp.802wirelessworld.com/11/06/11-06-0010-01-000v-location-presentation.ppt ftp://ieee:wireless@ftp.802wirelessworld.com/11/06/11-06-0009-03-000v-location-proposal.doc There were still some big issues in the posted version. I provided a bunch of comments to one of the authors after that version was published, at the last 802.11 interim. I would expect the draft will be updated shortly before the next 802.11 plenary in San Diego (the week after IETF 66). Personally, I think above points make best case to use LLDP-MED in a managed enterprise environment. That's a BIG market segment! Other methods may be more appropriate in different environments. I am personally much more interested in location (emergency and otherwise) for wireless LAN devices than for wired devices. The user of a wireless LAN device is much less likely to know their own location than a user of a wired LAN devices. This is a fast growing market segment because people want mobility once the price is right and the quality is good enough. Yes, we need to solve wired location, but lets not forget the wireless communities. thanks, -rohan --=_alternative 005158948525719D_= Content-Type: text/html; charset="us-ascii"
Hi Rohan,

> LLDP-MED does not work in an 802.11 wireless LAN environment.  The assumptions
> made in LLDP-MED about link reliability, authentication, bandwidth availability, timing,
> and lack of mobility are grossly inappropriate in a WLAN environment.

Actually, LLDP-MED can be used in WLAN scenarios for location, with the constraint that it can only locate to the AP today.  See LLDP-MED spec, Annex C for discussion of this.  At this point in time, there is no solution in WLAN to resolve closer than the AP.  To your points... If the wireless link becomes unreliable, then all methods are off.  Auth is not really a strong requirement (IMHO) in this scenario, at least in enterprise.  And, bw availability & timing are non-issues due to the very small size and periodic advertisements inherent in LLDP -- the other proposed methods use more bw and/or have difficulty getting updates on the fly.  (Don't understand what you mean by "lack of mobility".)  Yes, an imperfect solution, however reasonably practical at this time.  

> I am personally much more interested in location (emergency and otherwise) for wireless
> LAN devices than for wired devices.  The user of a wireless LAN device is much less
> likely to know their own location than a user of a wired LAN devices.  This is a fast
> growing market segment because people want mobility once the price is right and the
> quality is good enough.  Yes, we need to solve wired location, but lets not forget the
> wireless communities.

I both agree and disagree here.  Wired ethernet is by far the dominant case today in enterprise scenarios, therefore this is the biggest interest for me at this point in time.  LLDP-MED is already being supported by several vendors in enterprise space, and is proving to be pretty easy to work with, so makes a good choice there IMHO.   Of course I do very much agree we need to fully solve WLAN also, both enterprise and public, however it is lagging in large part due to lack of a well agreed / standardized method of doing the actual location (triangulation or otherwise).  The work is ongoing, but will take time.  

Thanks for aiming at the IEEE work.  I was aware, but have not been able to keep up with it in detail.  If I understand correctly (may be dubious) it appears that yet a 4th location method might be required to support this.  (I can hear Brian groaning as I type ;-)

-- Peter




"Rohan Mahy" <rohan.mahy@gmail.com>

29.06.06 18:29

       
        To:        "peter_blatherwick@mitel.com" <peter_blatherwick@mitel.com>
        cc:        "Rosen, Brian" <Brian.Rosen@neustar.biz>, Ecrit@ietf.org
        Subject:        Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft was submitted)



Hi Peter,

Some comments inline.  To be clear, I do not have a strong feeling about what does on Brian's list or not.  I think LLDP-MED is a completely reasonable thing for a wired phone vendor to implement on enterprise class phones.

On 6/26/06, peter_blatherwick@mitel.com <peter_blatherwick@mitel.com > wrote:
Brian, list,  

> ... I think we want to have a discussion on whether LLDP-MED is on that list.

As might be expected, I definitely support LLDP-MED as one on that list of location methods.  Some key points in favour I believe are:  

o LLDP-MED works at Layer 2, which is where real location comes from.  Closest to source is better.  

...As opposed to working at the application layer, where real application security comes from.  Closer to the application is better?   I don't want to have a debate about layer 2 vs. layer 7 location here, just point out that the answer you get depends on what you are willing to tradeoff.

o Access network elements (L2 switches typically) need to be configured anyway, and while the admin is touching them, location can be entered readily.  

o Wire map associated with L2 access needs to be created and maintained anyway.  (DHCP method would require it to be put in a different, possibly unrelated dB.)  

I'll point out that in the wireless case, the location of the station is also often in an unrelated place to the the L2 access device.

o Simple and direct, no intermediate mechanisms needed. (Eg. no need to turn on DHCP relay, insert DHCP relay agent sub-options, etc.)  Less dependancies is better.    

o No need for any additional interfaces in LLDP-MED method -- all interfaces are already defined.  In DHCP method (and presumably L7 also ?) an interface to DHCP server, to interface to the wiremap dB, would need to be defined to have a fully standards-based approach.   (In LLDP-MED, the wiremap dB interface is effectively done through SNMP and the defined MIBs, and the data becomes distributed across the L2 infrastructure.)  

o Can be made to work with wireless mobility as well.  Currently, LLDP-MED can locate down to the Access Point only (since the wireless environment does not yet have a standard way to do triangulation or similar), however would be relatively straight-forward to extend to higher accuracy.  (DHCP is completely inappropriate for wireless mobility IMHO.)  

LLDP-MED does not work in an 802.11 wireless LAN environment.  The assumptions made in LLDP-MED about link reliability, authentication, bandwidth availability, timing, and lack of mobility are grossly inappropriate in a WLAN environment.

IEEE 802.11 Task Group V is working on a Layer 2 approach of their own, which is significantly better than LLDP-MED on these regards:

ftp://ieee:wireless@ftp.802wirelessworld.com/11/06/11-06-0010-01-000v-location-presentation.ppt
ftp://ieee:wireless@ftp.802wirelessworld.com/11/06/11-06-0009-03-000v-location-proposal.doc

There were still some big issues in the posted version.  I provided a bunch of comments to one of the authors after that version was published, at the last 802.11 interim.  I would expect the draft will be updated shortly before the next 802.11 plenary in San Diego (the week after IETF 66).
Personally, I think above points make best case to use LLDP-MED in a managed enterprise environment.  That's a BIG market segment!  Other methods may be more appropriate in different environments.  

I am personally much more interested in location (emergency and otherwise) for wireless LAN devices than for wired devices.  The user of a wireless LAN device is much less likely to know their own location than a user of a wired LAN devices.  This is a fast growing market segment because people want mobility once the price is right and the quality is good enough.  Yes, we need to solve wired location, but lets not forget the wireless communities.

thanks,
-rohan


--=_alternative 005158948525719D_=-- --===============0301641408== 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 --===============0301641408==--