Subject: [Ecrit] Summary of Recent Discussion

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 19 May 2006 16:44:02 +0200

Hi all,

here is a short summary of the recent discussions:

* LoST always requires a service identifier and location information as 
parameters of a query.  A dialstring is not an input parameter for a 
LoST query.

* Extensibility mechanism for LoST. Is a "capability discovery" for LoST 
in the form of a "Please return what services URIs you understand." 
useful? (Btw, we similar mechanisms with the policy work in Geopriv.) 
The degree of complexity introduced by the different proposals needs to 
be analysed. (This aspect does not need to be captured in the 
requirements document and is subject for discussion related to LoST.)

* Various failure cases in LoST need to be carefully analysed. E.g., A 
person asks for "urn:service:sos.fire" but only ""urn:service:sos" is 
available. What would happen? This item and the last one are related to 
each other.

* Henning suggested to extend LoST to return additional information 
regarding the service (e.g., location information needed). This 
discussion is relevant for LoST. I can see that there was support for 
his proposal. This aspect does not need to be captured in the 
requirements draft.

* Child helpline
Henning has already captured the child helpline service identifier after 
a discussion on the mailing list: 
http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service-urn-03.txt).
(see urn:service:counseling.children)

* Requirements draft
Roger mentioned a few open issues with the document where he would 
appreciate input. A final review would help to finish the document.

Ciao
Hannes

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

---

From: Ted Hardie <[email-masked]>
Date: Fri, 19 May 2006 11:48:41 -0700

At 4:44 PM +0200 5/19/06, Hannes Tschofenig wrote:
>Various failure cases in LoST need to be carefully analysed. E.g., A person asks for "urn:service:sos.fire" but only ""urn:service:sos" is available. What would happen? This item and the last one are related to each other.

The LoST server should return the contact URI for urn:service:sos along with
the URN it used for the mapping.  The phone will get a useful contact, and
it will know that the location actually derived from a "default" emergency
service urn, rather than the specific.

Note:  I don't think this should work like tree walking.  There should be a single
default (urn:service:sos for emergency services).  If the LoST server does not
have the sos.$var you asked for, it *always* goes back to the default.  I think
this reinforces the idea that you separate emergency services from counselling
services or non-emergency public support; they may have a different default,
but they certainly should not be sent to the emergency default.

				Ted

>* Henning suggested to extend LoST to return additional information regarding the service (e.g., location information needed). This discussion is relevant for LoST. I can see that there was support for his proposal. This aspect does not need to be captured in the requirements draft.
>
>* Child helpline
>Henning has already captured the child helpline service identifier after a discussion on the mailing list: http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service-urn-03.txt).
>Roger mentioned a few open issues with the document where he would appreciate input. A final review would help to finish the document.
>
>Ciao
>Hannes
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 19 May 2006 15:01:10 -0400

Nope, that won't work.

In some countries, there is no sos single service.  In other countries, if
there is no fire number, there is ONLY the top level sos (with respect to
fire).

The database has to know this (but that's okay, because it's all local data,
as is all the data in the database).  If you query with sos, and there is no
sos, there will be a local decision of what to return.  In most cases, I'd
expect they would decide to return sos.police.  If you query sos.police in
North America, you will definitely get back the sos URI (and presumably the
sos URN).  It could be that you get back an error (in this jurisdiction,
there is no such service, and we want you to do it over).

This lets it be a local decision if humanServices.child gets you sos.police.

Brian

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Friday, May 19, 2006 2:49 PM
To: Hannes Tschofenig; [email-masked]
Subject: Re: [Ecrit] Summary of Recent Discussion

At 4:44 PM +0200 5/19/06, Hannes Tschofenig wrote:
>Various failure cases in LoST need to be carefully analysed. E.g., A person
asks for "urn:service:sos.fire" but only ""urn:service:sos" is available.
What would happen? This item and the last one are related to each other.

Note:  I don't think this should work like tree walking.  There should be a
single
default (urn:service:sos for emergency services).  If the LoST server does
not
have the sos.$var you asked for, it *always* goes back to the default.  I
think
this reinforces the idea that you separate emergency services from
counselling
services or non-emergency public support; they may have a different default,
but they certainly should not be sent to the emergency default.

				Ted

>* Henning suggested to extend LoST to return additional information
regarding the service (e.g., location information needed). This discussion
is relevant for LoST. I can see that there was support for his proposal.
This aspect does not need to be captured in the requirements draft.
>
>* Child helpline
>Henning has already captured the child helpline service identifier after a
discussion on the mailing list:
http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service-urn-03
.txt).