Subject: [Ecrit] FW: New Version Notification for draft-rosen-ecrit-completed-location-00

From: Brian Rosen <[email-masked]>
Date: Mon, 01 Mar 2010 18:02:56 -0500

In NENA, we really want to be able to send a complete PIDF-LO (every element
we have) back to a LoST requester to sends us a PIDF that is valid (meaning,
it's complete enough to dispatch responders), but doesn't have all the
fields that the LoST server does.

A good example is when you send a postal address.  We have the actual
municipal address.  We would like to return that (the A3 element).

Another example is when you send "North Main", without a "Street" suffix.
If there are no other North Mains, then it's unique, and therefore valid,
but we would like to get that "Street" suffix back.

Currently, you can't get a PIDF back on a LoST response.  This document adds
an attribute for <findService> (requestCompletedLocation) that requests that
a PIDF be sent in the response.  It adds a PIDF in a
<responseCompletedLocation> element.

Brian
------ Forwarded Message
From: IETF I-D Submission Tool <[email-masked]>
Date: Mon,  1 Mar 2010 09:03:48 -0800 (PST)
To: Brian Rosen <[email-masked]>
Cc: Henning Schulzrinne <[email-masked]>
Subject: New Version Notification for
draft-rosen-ecrit-completed-location-00

A new version of I-D, draft-rosen-ecrit-completed-location-00.txt has been
successfuly submitted by Brian Rosen and posted to the IETF repository.

Filename:  draft-rosen-ecrit-completed-location
Revision:  00
Title:   Completing the Request Location
Creation_date:  2010-03-01
WG ID:   Independent Submission
Number_of_pages: 14

Abstract:
This document defines an extension to LoST (RFC5222) that allows a
request to specify that a PIDF be returned in the response if the
location was valid, but there were some missing elements.  For
example, an civic location that did not include a postal code, but
was otherwise a complete, and unambiguous location, would receive a
complete PIDF in the response that included the postal code.

The IETF Secretariat.

------ End of Forwarded Message

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 01 Mar 2010 18:20:44 -0600

well - I guess including a PIDF-LO in a LoST response isn't such a 
foreign idea anymore...  (re: 
draft-polk-ecrit-lost-transformations-urn-00 in Stockholm - where 
several spoke at the mic that this wasn't the purpose of LoST (to 
return a PIDF-LO), but only a URI for that service).

If a LoST response can include a corrected LO, then it certainly can 
include a transformed LO (from one location format to another), as 
the transformations ID proposes.

Comment about draft-rosen-ecrit-completed-location-00 specifically - 
what do you have in mind to ensure a location isn't inadvertently 
completed when it shouldn't have been?

For example, 2 adjacent cities, both with a "North Main", but where 
one is "st" the other is "Ave".  If somehow the wrong info is sent 
back to an endpoint, this could be included in subsequent 
transmissions of location - and not using LoST anymore.

This may be a too small a corner case, but this would make one error 
a lot worse (by adding more bad information in what will be used by 
other applications).

If this is too small a concern to really worry about, I guess this 
could be addressed in the Security Considerations section - and be 
done with it.

I think this ID has value - as long as it doesn't compound errors by 
making them worse.

James

At 05:02 PM 3/1/2010, Brian Rosen wrote:
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit

---

From: Brian Rosen <[email-masked]>
Date: Mon, 01 Mar 2010 19:28:53 -0500

There is a difference between returning some fields that the input
neglected, and transforming the output: we're getting the mapping, and
everything else in the same transaction, and we want that.

I think the other effort on geocoding is likely a better approach than using
LoST.

You can always make a mistake and not know that you have made a mistake.  If
you meant 100 North Main, Anytown, but sent 100 North Main, Thistown, and
there is a 100 North Main in both, it validates, and no one knows a mistake
is made.

In our case, you have to have a valid location, but no one is expecting
EVERY field to be supplied to determine that: if you give us enough fields
that we have exactly ONE place on our map where you could be, then we
declare it valid.  That is true with or without this extension.

Brian

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 2 Mar 2010 09:01:43 +0800

I think that there is a mistake here in talking about PIDF-LO.  Since the LoST server wont be given any identification information, any PIDF-LO it creates would not include any useful identity.

It seems that all you need to include in the response is the corrected _location information_.

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Rosen
> Sent: Tuesday, 2 March 2010 10:03 AM
> To: [email-masked]
> Subject: [Ecrit] FW: New Version Notification for draft-rosen-ecrit-
> completed-location-00
>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 01 Mar 2010 19:09:29 -0600

At 07:01 PM 3/1/2010, Thomson, Martin wrote:
>I think that there is a mistake here in talking about 
>PIDF-LO.  Since the LoST server wont be given any identification 
>information, any PIDF-LO it creates would not include any useful identity.

won't the LoST server have the identity from the PIDF-LO that was in 
the LoST request (i.e., to be copied from request to response)?

>corrected _location information_.

Are we trying to save a few bytes here?  What's the harm in including 
a complete 1 packet PIDF-LO response?

James

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 2 Mar 2010 10:25:59 +0800

Unless I am seriously mistaken a LoST server doesn't get a PIDF-LO today, it gets a location. There was considerable objection to including a PIDF-LO in the original LoST query protocol on the grounds that it included identity information EVEN if the identity was an unlinked pseudonym. These were similar grounds as to why a location URI was not deemed an acceptable input to a LoST server.

I would like to understand why these issues are suddenly a non-argument.

Cheers
James

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> James M. Polk
> Sent: Tuesday, 2 March 2010 12:09 PM
> To: Thomson, Martin; Brian Rosen; [email-masked]
> Subject: Re: [Ecrit] FW: New Version Notification for draft-rosen-ecrit-
> completed-location-00
> 
> > > Currently, you can't get a PIDF back on a LoST response.  This
> document
> > > adds
> > > an attribute for <findService> (requestCompletedLocation) that
> requests
> > > that

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 01 Mar 2010 20:38:32 -0600

you're right

I fixated on the idea of location -- and didn't pull my head above 
what I was buried with enough to think more about this before replying.

I apologize

James

At 08:25 PM 3/1/2010, Winterbottom, James wrote:
>Unless I am seriously mistaken a LoST server doesn't get a PIDF-LO 
>today, it gets a location. There was considerable objection to 
>including a PIDF-LO in the original LoST query protocol on the 
>grounds that it included identity information EVEN if the identity 
>was an unlinked pseudonym. These were similar grounds as to why a 
>location URI was not deemed an acceptable input to a LoST server.
>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 02 Mar 2010 08:10:10 -0500

You are correct.  I will edit the text accordingly.

Brian

On 3/1/10 9:25 PM, "James Winterbottom" <[email-masked]>
wrote:

> Unless I am seriously mistaken a LoST server doesn't get a PIDF-LO today, it
> gets a location. There was considerable objection to including a PIDF-LO in
> the original LoST query protocol on the grounds that it included identity
> information EVEN if the identity was an unlinked pseudonym. These were similar
> grounds as to why a location URI was not deemed an acceptable input to a LoST
> server.
>