|
|
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:hardie@xxxxxxxxxxxx]
Sent: Friday, May 19, 2006 2:49 PM
To: Hannes Tschofenig; ecrit@xxxxxxxx
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.
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).
>(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
>Ecrit@xxxxxxxx
>https://www1.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
|
|