Subject: [Ecrit] [issue7] Adding Additional Info to LoST Response

From: admin <[email-masked]>
Date: Thu, 13 Jul 2006 22:22:01 +0000

admin <[email-masked]> added the comment:

As discussed in the ECRIT IETF#66 working group session we are not going to add
this functionality to LoST.

----------
status: chatting -> done-cbb

__________________________________________________
LoST Issue Tracker <[email-masked]>
<http://www.tschofenig.priv.at:8080/lost/issue7>
__________________________________________________

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 13 Jul 2006 18:41:32 -0400

I don't remember this being discussed, but perhaps I missed it, or we aren't
talking about the same thing.

I would like to have an optional URI able to be returned in the response
which was "additional information" about the location.  For the LoST spec, I
would propose that no limitation on scheme, or resolution processes for this
URI be specified; it's just a URI.  In practice, this may be locally
defined.  That works because the PSAP serving the location is "local" to the
location.  Of course, authentication would have to be required to
dereference this information.

The intention is to have a place to deliver to a PSAP information like floor
plans, contact information, environmental information, etc. about this
location.  This is currently part of the NENA i3 spec.  Since the actual
PSAP that gets a call may change depending on congestion, failures, etc, the
information cannot be kept at the PSAP.

Brian

-----Original Message-----
From: admin [mailto:[email-masked]] 
Sent: Thursday, July 13, 2006 6:22 PM
To: [email-masked]; [email-masked]
Subject: [Ecrit] [issue7] Adding Additional Info to LoST Response

As discussed in the ECRIT IETF#66 working group session we are not going to
add
this functionality to LoST.

----------

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 13 Jul 2006 19:29:05 -0400

At least in my interpretation, Issue 7 is not quite what you  
describe, but rather about allowing to annotate services that get  
returned in some machine-readable format, which may well be service- 
dependent (distinguished by name spaces). For example, you could  
imagine returning some kind of service quality indication for non- 
PSAP services.

I''m a bit confused by the service you envision. I'm interpreting  
this as implying a pointer to some kind of WebDAV-like service where  
citizens can upload documents about themselves or about a particular  
location, such as a building.

Ted, Hannes and I discussed a slightly more general approach, namely  
that a response can return a list of distinct URLs.

A slight extension is to label the function of that URL, as in

<sap service="communications">sip:[email-masked]</>
<sap service="descriptions">http://upload.example.gov</>
<sap service="communications">mailto:[email-masked]</>

I don't know if 'communications' and 'description' are the only  
labels; I suspect there are others, such as "finding out more  
information about the service provider".

I'll also note that just specifying a URL without some fairly  
elaborate protocol mechanisms is probably of little value, unless  
this is simply a web page that has a web form and allows random  
citizens to upload documents for any location or person.