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

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 05 Jun 2006 14:58:21 +0000

New submission from Hannes Tschofenig <[email-masked]>:

In the current LoST draft we return a service URN in the response message. 
The current text says: 

"
   If a more specific service is requested but does not exist,
   information for the more generic service SHOULD be returned.  For
   example, a request for urn:service:sos.fire might return
   urn:service:sos in the United States since citizens in that country
   reach the fire department through the common emergency service.
"

In the response message the service URN attribute/element then contains the 
URN that was used in the matching process. 
 
Two questions:

* Is this "error" handling mechanism useful?
* Do we want to include a query-type attribute with the values 'strict match' 
and 'loose match' in the query message to indicate what type of behavior is 
desired?

----------
assignedto: hannes
messages: 6
nosy: ecrit, hannes
priority: critical
status: unread
title: Service URN in Response Message

__________________________________________________
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:18:01 -0400

I think this is related to the issue of the other thread, regarding 
defaults.

I don't think the querier actually cares whether the PSAP for sos.fire 
and sos.police happens to be the same.

Thus, I think this is purely a server configuration issue where the 
server database is set up to return a default value for unknown 
emergency services. This seems to be the case in practice today: even in 
places where there are separate numbers for various services, if you 
don't know whom to call for a "non-standard" emergency, you'd probably 
call the police.

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 5 Jun 2006 16:28:56 -0400

Yes, I think it's necessary.  You requested one thing, you got another.  You
should be told what you got.

No, I don't think we need to provide options for strict/loose match.

Brian

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Monday, June 05, 2006 10:58 AM
To: [email-masked]
Subject: [Ecrit] [issue4] Service URN in Response Message

"

Two questions:

* Is this "error" handling mechanism useful?
* Do we want to include a query-type attribute with the values 'strict
match' 
and 'loose match' in the query message to indicate what type of behavior is 
desired?

----------
assignedto: hannes
messages: 6
nosy: ecrit, hannes
priority: critical
status: unread

---

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

Hi Henning,

> I think this is related to the issue of the other thread, regarding 

It is similar but there is a difference:

* 'Default' means that the LoST client does not provide a service URN 
and the LoST server just assumes that there is a default value for it.

* The 'service URN' in the response message addresses the error handling 
where the requested service is not available but the LoST server can use 
another service instead (e.g., sos instead of sos.fire).

> don't know whom to call for a "non-standard" emergency, you'd probably 

With your description it would not make sense to return the service URN 
in the response message if we assume that the querier does not care 
about this aspect. Would this be OK for you?

Ciao
Hannes

>> In the current LoST draft we return a service URN in the response 
>> message. The current text says:
>> "
>> In the response message the service URN attribute/element then 
>> contains the URN that was used in the matching process.  
>> Two questions:
>>
>> match' and 'loose match' in the query message to indicate what type of 
>> behavior is desired?
>>
>> ----------
>> assignedto: hannes
>> messages: 6
>> nosy: ecrit, hannes
>> priority: critical
>> status: unread

---

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

Hi Brian,

> should be told what you got.

Hmmm. Minor disagreement with Henning.

> No, I don't think we need to provide options for strict/loose match.
OK.

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 05 Jun 2006 17:23:20 -0400

>> should be told what you got.

I'm not sure that's really the case. It would be the case if you 
requested urn:service:pizza-delivery and somehow got an answer for 
urn:service:weightloss, but, here, we seem to be talking about the case 
that a single PSAP handles multiple types of emergencies and that 
there's no separate PSAP record for the type of emergency you requested.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 05 Jun 2006 17:25:28 -0400

I'd like to better understand the model that people have in mind, where 
this condition would actually occur and where this information would 
actually be useful to the querier. (I don't think the querier needs to 
know which emergency services happen to all land on the same PSAP in a 
particular area.)

>> emergency services. This seems to be the case in practice today: even 
>> in places where there are separate numbers for various services, if 
>> you don't know whom to call for a "non-standard" emergency, you'd 
>> probably call the police.
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 5 Jun 2006 19:31:26 -0500

I agree, we need to be clearer about what the LoST server is doing.

I propose that it be possible to request for "urn:service:x.y.z" and get a result for either "urn:service:x.y" or "urn:service:x".  That is what the original text said.  I think we can be clearer and say that you should never get "urn:service:x" unless your request started with "urn:service:x" and you can never get "urn:service:x.y" if you asked for "urn:service:x".  That is, the server can go up the tree, but never sideways or down.

(The fact that "urn:service:x" == "urn:service:x.y" is something I don't care about; that's jurisdictional specific and can be solved with server configuration.  This shouldn't be confused with the fallback option.)

On parameters, Brian had it right.  If this fallback occurs, make sure the client knows.  A "strict" parameter isn't necessary, providing this behaviour is clear.

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, 6 June 2006 7:25 AM
> To: Hannes Tschofenig
> Cc: [email-masked]
> Subject: Re: [Ecrit] [issue4] 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: Hannes Tschofenig <[email-masked]>
Date: Tue, 06 Jun 2006 22:05:02 +0200

Hi Martin,

thanks for your input.

I think the important issue here is that future services are defined in 
such a way that the "urn:service:x" == "urn:service:x.y" equation 
produces something reasonable. I suspect that this will at the end be 
the quintessence of the problem.

Since this is difficult to solve (in general) we can do the following.
Assume that the query is for "urn:service:x.y".

* If the semantic of the service supports the "urn:service:x" == 
"urn:service:x.y" semantic then we apply Ted's approach.

* If the semantic of the service supports the "urn:service:x" == 
"urn:service:x.y" semantic then an error message is returned "service 
not available".

Ted's approach:

Populate "urn:service:x"'s LoST data with the same data as "urn:service:x.y"

Does this sound like a reasonable compromise?

Ciao
Hannes

---

From: Brian Rosen <[email-masked]>
Date: Wed, 7 Jun 2006 01:20:45 -0400

This is reasonable only if you also include urn:service.x in the reply, 
so that when you ask for x.y you are told you got the URIs for x.