Subject: [Ecrit] [issue4] Service URN in Response Message

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 06 Aug 2006 21:06:39 +0000

Hannes Tschofenig <[email-masked]> added the comment:

Henning suggested that if the specific service is not available for a  
particular location then the server MAY return an alternate service. If  it 
does so, it MUST indicate the actual service returned (i.e., its  service URN). 
There is no restriction on the new service offered.  Thus, it is possible that 
a query for

urn:service:sos.ambulance

returns

urn:service:undertaker

A server MAY instead return an error response indicating that the  service is 
not available.

The Phone BCP draft needs to provide a discussion about the local policy aspect 
that the deployment of a LoST server implies. The length of the discussion on 
the mailing list is an indication that this issue is important and seems to be 
difficult to understand. 

Here is an example: Imagine there is a region that only 
understands 'urn:service:sos' but 
not 'urn:service:sos.fire', 'urn:service:sos.ambulance', 
and 'urn:service:sos.police'.

If a LoST client asks for 'urn:service:sos.fire' then it could get:
* 'urn:service:sos' or
* 'urn:service:sos.fire' with the values of 'urn:service:sos' being populated 
to 'urn:service:sos.fire' 

The implication for LoST is to provide an optional <service> element to the 
response message.

So far, Martin and Brian supported the proposal by Henning.

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

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