Subject: RE: [Ecrit] Related services (was: Summary of recent discussion)

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 23 May 2006 10:07:08 -0400

There are a number of good ideas about how to provision such a system.
I am wondering if this is intended to be part of the protocol document
itself or a separate BCP, given that there are several interpretations
of how the protocol is to be used?

Mike

> -----Original Message-----
> From: Ted Hardie [mailto:[email-masked]] 
> Sent: Monday, May 22, 2006 6:03 PM
> To: Henning Schulzrinne
> Cc: [email-masked]
> Subject: Re: [Ecrit] Related services (was: Summary of recent 
> discussion)
> 
> At 4:28 PM -0400 5/22/06, Henning Schulzrinne wrote:
> >There seem to be two approaches to this problem: 
> client-based and server-based.
> >
> >In a client-based approach, the server returns an error when 
> a particular service is unavailable. The client then retries 
> with the more general service (sos.police -> sos).
> >
> >Ted seems to advocate the server-based approach where the 
> server "guesses" (quoted, since this might be a fairly 
> predictable algorithm) what the user would want in the 
> absence of its first choice.
> 
> I actually don't think that's what I'm advocating.   I 
> believe there are cases
> where queries will come in for service URNs that are not 
> supported in the local area.  If a local administration 
> decides that those do not need to get any service, then a 
> normal "no data" message is returned.  I believe, though, 
> that there are cases where they will wish to use one of the 
> emergency service responders as a "backup" service for 
> unknown sos services.  Brian indicates that this is commonly 
> police, and I've used that in my examples.
> 
> I believe the best way to handle that is for the local 
> administration to provision the unsupported emergency service 
> URNs with the same data as is present for the "backup" 
> service (that, is put the sos.police data at sos.foo if 
> sos.foo is not supported).  Nobody has to guess at that 
> point; it is a straightforward result.
> 
> Based on Brian's message, though, I believe there will be 
> cases where the local authorities may not want to provision 
> those service URNs, but will want instead for the LoST server 
> to return what is, essentially, a compound message "There is 
> no service available for your query; the backup service is sos.police,
> and here is its contact URI".   This may be to manage the 
> client expectation or
> to avoid caching of data that is not, strictly speaking 
> correct.  The example I can imagine most clearly here is for 
> a sos.poison.  If the jurisdiction doesn't have a poison 
> service or a top-level sos service, the client's query for 
> sos.poison being redirected to sos.police may be far enough 
> off that a client would prefer to try to make a non-emergency 
> call to a known hospital number instead.  Other clients might 
> decide to continue the call and ask for police help with 
> finding a poison center.  Whichever choice is made, though, 
> the metadata about the redirection to other responders may be 
> valuable.
> 
> Note that none of this is service "guessing"; it's the 
> jurisdiction covering the location saying what it wants 
> returned--I think that will be easy if they do it by 
> providing contact URIs for the services, but also do-able if 
> they want to provide both a contact URI and the metadata of 
> which service will be really handling the call.
> 
> Let's put this in jurisdictional terms for a second.  If 
> Happyland has services for fire, police, ambulance, and coast 
> guard services, the Happylanders likely know those relevant 
> telephone numbers and will call them in the appropriate moments.
> When Happyland adopts LoST, they will populate their LoST 
> servers with contact URIs for sos.fire, sos.police, 
> sos.ambulance, and sos.marine.  In the telephone system, they 
> may well have only the specific numbers, with no general 
> telephone number at all.
> 
> If I roam into Happyland, I may be doing so from someplace 
> that uses a single response number for all those services.  
> When I try to look up the contact URI for
> emergency services, in other words, I'm going to query for 
> sos alone.   There is
> no such service in Happyland.
> 
> What happens next?
> 
> If the LoST server returns only that there is no data for 
> sos, the device must at least spend time re-querying, which 
> is a loss of time.  If the device knows about sos.fire, 
> sos.police, sos.ambulance, and sos.marine, etc. it will 
> presumably need only a few round trips to find something that 
> works, but any UI input needed will take attention as well as 
> time--which is not great.  In the proxy case, there is no 
> chance that the proxy will know which more specific URN to 
> try; it will have to work off some sort of priority table. 
> The device or proxy may also not know of some URNs in use in 
> Happyland.
> I'm particularly worried about that in cases where a user 
> input like a dialed 911 or 112 is triggering this input.
> 
> I think we should acknowledge that a client may have to go 
> through this, but push as much as we can to avoid it.  That 
> means treating it as "best practice"
> to create an entry for the covering sos service *even if 
> there is no corresponding telephone number*.  Failing that, 
> allowing the LoST server to indicate in metadata that the 
> contact URI is for a service that *will respond* but is not 
> the one for which the query is made is a second line of 
> defense.  I'd like to see the client/proxy picking a URN from 
> its known set as the last line of defense.
> 
> 				regards,
> 					Ted Hardie
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
> 

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 23 May 2006 10:17:25 -0400

I hadn't thought through the "compound reply", but I like the idea.  I think
I can agree with all of this.

Brian