Subject: [Ecrit] LoST #4: service URN in response message

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 13 Jul 2006 15:49:36 -0400

Proposed resolution: If the specific service is not available for a  
particular location, 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.

Henning

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 14 Jul 2006 07:30:20 -0500

Do we have any additional guidance that would be helpful, or is that the
extent of your proposed guidance?

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, 14 July 2006 5:50 AM
> To: ECRIT
> Subject: [Ecrit] LoST #4: service URN in response message
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 14 Jul 2006 09:20:19 -0400

What kind of guidance do you have in mind?

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 14 Jul 2006 08:39:44 -0500

We talked about the different directions in the "tree" that the server
could "climb" before this.  Your response threw all of that out - I just
wanted to make sure that this was intentional.

One piece of guidance that is useful is to say that "urn:service:sos"
always has a result available for it.

Another piece, which is probably the tricky part, describes which way
the server can automatically climb.  Upwards, sideways, or wherever are
the three options.  If you don't have at least a little guidance, then
it becomes harder to make an automated decision at the UA when it
receives this information.  In other words - some text here helps both
the server implementers/administrators (they can make informed decisions
about what they will do) but it also informs resolver implementers, who
sometimes have to make an automated decision when urn:service:undertaker
comes back.

Not having any additional guidance means that it's harder to achieve
consistency between implementations, which, I think, would be
advantageous.

Sorry, but I don't have the answers on this one, yet.

Martin

> Sent: Friday, 14 July 2006 11:20 PM
> To: Thomson, Martin
> Cc: ECRIT
> Subject: Re: [Ecrit] LoST #4: service URN in response message
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 14 Jul 2006 09:45:13 -0400

> wanted to make sure that this was intentional.

Yes, since I interpreted this to be the consensus in the WG meeting  
(please see the minutes).

> always has a result available for it.

I believe that such operational advice is best encapsulated in the  
phone-bcp document. LoST is not limited to service:sos

> sometimes have to make an automated decision when  

There is no climbing, up, down or otherwise. The server decides for  
each service either to offer a "real" service, if available, or to  
offer a substitution service. This is a matter of local policy; I  
don't see how you can usefully automate that. Again, during the WG  
session, a number of examples were offered where blindly going "up"  
the service tree would not be desirable.

> consistency between implementations, which, I think, would be

I don't think such guidance is necessary for protocol interoperability.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 14 Jul 2006 09:49:50 -0400

Hi Martin,

with Hennings proposal we have a lot of freedom for the party that 
operates the LoST server. In some sense this is good since they know the 
    services best.

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'

Another example:

Imagine there is a region that only understands 'urn:service:sos.fire', 
'urn:service:sos.ambulance', and 'urn:service:sos.police' but it does 
not understand 'urn:service:sos'.

If a LoST client asks for 'urn:service:sos' what would it get?

We probably need to state what it means if the LoST client receives a 
response that indicates 'I couldn't provide a response to your request 
based on urn:service:sos.ambulance but I have something else for you.'

I am not sure what the LoST client can usefully do in this case.

Ciao
Hannes

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 17 Jul 2006 18:04:53 -0500

I think that I am happy with Henning's response on all of these.  The guidance for urn:service:sos now just needs to be captured in the phone BCP.

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Friday, 14 July 2006 11:50 PM
> To: Thomson, Martin
> Cc: Henning Schulzrinne; ECRIT

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 18 Jul 2006 08:38:15 -0400

I think most of this goes in the LoST document, but the bcp should clearly
say that the client has to be prepared for the substitution.  It's not
really clear it cares a lot, except for, perhaps, the user interface it
presents, where the user, if she are paying attention, would probably want
to know what is happening to her call.

Brian

-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: Monday, July 17, 2006 7:05 PM
To: Hannes Tschofenig
Cc: ECRIT
Subject: RE: [Ecrit] LoST #4: service URN in response message

I think that I am happy with Henning's response on all of these.  The
guidance for urn:service:sos now just needs to be captured in the phone BCP.

> >>service is not available.

----------------------------------------------------------------------------
--------------------
----------------------------------------------------------------------------
--------------------
[mf2]