Subject: RE: [Ecrit] [issue1] Do we need a default service URN for the LoS Tquery?

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 6 Jun 2006 13:14:52 +0100

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:[email-masked]]
> Sent: 05 June 2006 23:56
> To: Henning Schulzrinne
> Cc: [email-masked]
> 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
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ecrit
> >
> >
> 
> 
> _______________________________________________
> 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: Shida Schubert <[email-masked]>
Date: Tue, 06 Jun 2006 13:06:40 -0700

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 6 Jun 2006 10:03:07 -0400

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.