Subject: Re: [Ecrit] Summary of Recent Discussion

From: "Stastny Richard" <[email-masked]>
Date: Sat, 20 May 2006 00:05:24 +0200

Ted, 
 
>This is also where I can't tell whether I agree with Richard or not.

I also do not know if I agree with you ;-)
 
>From an IETF point of view I agree with you that only a globally unique
definition makes sense
 
OTOH, having been nearly for two weeks in Geneva, where
every second sentence ends with: this is a national matter ....
 
regards
Richard

________________________________

Von: Ted Hardie [mailto:[email-masked]]
Gesendet: Fr 19.05.2006 23:15
An: Stastny Richard; Brian Rosen; Hannes Tschofenig; [email-masked]
Betreff: Re: [Ecrit] Summary of Recent Discussion

Continuing the top posting meme, the LoST protocol mechanism appears to be:

"Return the urn for which this is a mapping, so the client knows if it is changed".

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.   That means you don't have to do
a server configuration mapping step  to say "return sos.police to sos queries".
Still, I agree that returning the service URN that is associated with the responder
may be appropriate, as there may be cases where that will cause the caller to
make some decision (e.g. drop the call if they were calling in a police brutality
sighting).  I think that should not be a protocol error, in other words, but I think
we should be strongly pushing for a BCP of urn:service:sos being a populated
item in the LoST emergency server; it really does help interoperability here to
have a default.

This is also where I can't tell whether I agree with Richard or not.  The local LoST
server should return to you the contact URI of the URN associated with your
query.  What that URN means should be globally known, not purely based on
local custom, or roaming folks are going to be overly surprised. If it isn't sufficiently
well described to distinguish between a "my parents make me do chores" counselling
service  and an emergency child-slave rescue service, then something is wrong.
In a local context, it is, of course, possible that the same folks respond to both,
because they have been trained to do so.  But the services are distinct.

If Richard is talking about what the mapping should be in the absence of a
service listing, that  may be local (should the child slave talk to a counsellor trained
to talk to kids, or a policeman trained in dealing with lawbreakers like child slavers?)
If he's saying that the local folks should decide that urn:service:help:child should
be whatever the local folks say it should mean, that's not globally appropriate.
urn:service:help:child.counselling and urn:service:sos:child.rescue should be
distinguishable.
                        regards,       
                                Ted

At 10:26 PM +0200 5/19/06, Stastny Richard wrote:
>I support this. It is a local decision if child.help is a counselling service or an emergency service
>you may even have both.
>
>- A conselling service for giving children advice in case they have problems with their parents
>or teachers (this may also anonymous)
>- and an emergency service for children brought by slave-traders into
>another country (here a location is very useful, because the child
>may have no idea where it is and may also may not talk the language)
>
>This was basically the service CHI requested
>
>Richard
>
>
>________________________________
>
>Von: Brian Rosen [mailto:[email-masked]]
>Gesendet: Fr 19.05.2006 21:01
>An: 'Ted Hardie'; 'Hannes Tschofenig'; [email-masked]
>Betreff: RE: [Ecrit] Summary of Recent Discussion
>
>
>
>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.
>
>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
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/ecrit
>
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ecrit
>
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ecrit

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