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

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 05 Jun 2006 18:56:55 +0000

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

I went through the mailing list about this issue again. 
The mailing discussion started around 
http://www1.ietf.org/mail-archive/web/ecrit/current/msg01964.html

Martin, Mike, Henning, Brian, Andy, Ted, Hannes and Henning participated in the 
discussion. 

I am actually confused and I am not quite sure what the outcome of the 
discussion is.

Here are a few discussion snippets:

Henning Schulzrinne wrote:

>
> On May 17, 2006, at 8:05 PM, Thomson, Martin wrote:
>
>> I don't have a problem with asking for sub-services.  For instance, I know 
about urn:service:massage, but I might like to know that 
urn:service:massage.swedish exists.  That's valuable.
>>
>> Of course, the advantage with what we have currently is that this feature 
can be added later.  If it isn't necessary, then we can leave it until we don't 
have more pressing problems to address.
>
>
> Indeed - that's a separate query.
>
>>
>> Q: If I try to resolve urn:service:sos.fire and it doesn't exist, can the 
LoST server unilaterally return the result for urn:service:sos?
>
>
> I suppose, as a hint, although I'm a bit worried about the complexity once 
you generalize this. Imagine that we have more than two levels of service 
descriptions (urn:service:sos.fire.cats_in_trees). Should the result include 
the whole tree above the (non-existing) service?
>
> I think a better approach is to have the client do the "list subservices" 
query, and then query for those subservices. Less guesswork and special cases.
> Henning 

Ted argued: 

"
I think the rest of Brian's cases are, in essence, default mappings, where one
service (e.g. sos.police) is doing double duty as something else (e.g sos).  I
would also argue that it would be better in that case to populate the
default URN (sos)'s LoST data with the same data as (sos.police)
as a direct, effective way of handling that.
"

Hannes responded: 
"
Doing this you wouldn't even need to return the service urn with the LoST 
response since it would match the query. 
"

----------
status: unread -> chatting

__________________________________________________
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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 05 Jun 2006 16:00:05 -0400

If we assume that there's a "list services" method, would we still need 
this?

Maybe it would help to define a usage scenario, as participants in this 
discussion may have different ideas.

One additional item of discussion that we seemed to agree on was that 
the server could provide PSAP information for a more specialized service 
even if it was the same as the more general service. For example, in the 
US, the PSAP information for sos.fire would always return the same 
information as sos.police (and as just plain sos) as long as all these 
emergency requests get routed to a single PSAP, regardless of the nature 
of the emergency. (This isn't quite true for all sos services even in 
the US, as poison-control gets routed elsewhere.)

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 05 Jun 2006 22:29:23 +0200

Hi Henning,

> If we assume that there's a "list services" method, would we still need 

I wasn't quite sure whether there is an agreement for such a 'list 
services' functionality. Have you seen enough interest in this 
funcationality?

 >> as a direct, effective way of handling that.

Ciao
Hannes

> the US, as poison-control gets routed elsewhere.)
Does this directly relate to Ted's proposal where he wants to respond to 
a query to sos.fire even if there is only the generic service sos by 
linking the sos data items to sos.fire?

Ciao
Hannes

>> I went through the mailing list about this issue again. The mailing 
>> discussion started around 
>> can be added later.  If it isn't necessary, then we can leave it until 
>> we don't have more pressing problems to address.
>>
>>>
>> you generalize this. Imagine that we have more than two levels of 
>> service descriptions (urn:service:sos.fire.cats_in_trees). Should the 
>> result include the whole tree above the (non-existing) service?
>>
>> Hannes responded: "
>> Doing this you wouldn't even need to return the service urn with the 
>> LoST response since it would match the query. "
>>
>> ----------