Subject: Re: [Ecrit] Summary of Recent Discussion

From: "Stastny Richard" <[email-masked]>
Date: Fri, 19 May 2006 22:26:11 +0200

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

---

From: Ted Hardie <[email-masked]>
Date: Fri, 19 May 2006 14:15:51 -0700

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 20 May 2006 22:23:49 +0200

Hi Ted,

Ted Hardie wrote:
> as a direct, effective way of handling that. 

Sounds like a good idea to me.

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

   That means you don't have to do
> a server configuration mapping step  to say "return sos.police to sos queries".

I agree.

> item in the LoST emergency server; it really does help interoperability here to

I am confused with this suggestion.

Ciao
Hannes

---

From: Ted Hardie <[email-masked]>
Date: Mon, 22 May 2006 12:56:14 -0700

A
>I am confused with this suggestion.

Sorry for the confusion.  I am suggesting that it should not be a protocol error
for the server to return the contact URI + the service URN when that service
URN differed from the one that was requested.  I think the base reason for this
is the one we identified a long time ago:  I ask for sos.fire, but only sos is supported;
I return the contact URI, and let the client know that the contact URI is for
sos.   We need that to be possible.

Returning the contact URI and the service URN for sos.police when there is no sos
looks like the same protocol mechanism to me.  So I think we shouldn't try
to rule it out at the protocol level, but advocate instead that people accomplish
the same thing by populating the sos service URN with the same data as is
present at sos.police.  (Given that this is not a protocol mechanism, this would
be Best Practice at most).

I also acknowledge that there will be corner cases where getting a service
URN different than the one requested may cause the caller to do something
other than continue the call.  I don't thing we ought to be too concerned about that,
but given the protocol mechanism is there, we should note it may be useful
in that case as well.

I hope that's clearer,
			regards,
				Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 22 May 2006 16:28:59 -0400

There seem to be two approaches to this problem: client-based and 
server-based.

In a client-based approach, the server returns an error when a 
particular service is unavailable. The client then retries with the more 
general service (sos.police -> sos).

Ted seems to advocate the server-based approach where the server 
"guesses" (quoted, since this might be a fairly predictable algorithm) 
what the user would want in the absence of its first choice.

I don't think there's a right answer here. The client-based approach has 
the advantage of not returning information that the client already had 
("Thanks, I already know about service:sos since I just asked for it, 
but I wanted to know whether there are sub-services.") and being 
slightly simpler.

The server-based approach has the advantage that the server may have a 
better idea what's available, avoiding having to client to try a bunch 
of things. (The discovery mechanism addresses that problem to some extent.)

The problem with the server-based approach is that it starts to get 
messy if the alternative, second-best answer is a list, not a single 
answer. Suddenly, the protocol has to support providing a possibly 
lengthy list of services that are all potential substitutes.

My gut feeling is that modular protocols are easier to get correct, 
where each request does something simple and the client makes decisions. 
For this case, the behavior would be something like

(1) client asks for sos-related services and obtains a list of services 
(some subset of the sub-services in the sos.* list)

(2) client obtains the sub-service information (URLs, description, etc.) 
it cares about

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 22 May 2006 17:15:52 -0400

I don't understand how your suggested solution handles the case of child
help, where in one jurisdiction, there is an emergency, and in another there
is only an NGO non-emergency.  Do you propose to have two entries in the
tree, and populate one or both and have the client know the difference? 

I also don't understand the protocol difference between "return a list of
sos.*" and "the second-best answer is a list".  Both involve the protocol
returning one or more items in a list.

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Monday, May 22, 2006 4:29 PM
> To: Ted Hardie
> Cc: [email-masked]
> Subject: Re: [Ecrit] Related services (was: Summary of recent discussion)
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 22 May 2006 17:18:46 -0400

I am confused by
> be Best Practice at most).

If it looks like the same mechanism, maybe it should be the same mechanism
and we don't need another mechanism.  Why are you advocating an alternative
to returning sos.police for an sos query if you are okay returning sos for
an sos.police query?

Brian

> Sent: Monday, May 22, 2006 3:56 PM
> To: Hannes Tschofenig
> Cc: Stastny Richard; Brian Rosen; [email-masked]

---

From: Andrew Newton <[email-masked]>
Date: Mon, 22 May 2006 17:54:29 -0400

> of things. (The discovery mechanism addresses that problem to some extent.)

The server based approach is more time and network efficient.  I hope 
those are important attributes for emergency use cases.

> lengthy list of services that are all potential substitutes.

What is suppose to happen with a list of services on the user end?  I 
want sos.fire and I get back a list of sos.utility, sos.scuba-accidents, 
and sos.crazy-persons?  What am I suppose to do with those?

-andy

---

From: Ted Hardie <[email-masked]>
Date: Mon, 22 May 2006 15:03:02 -0700

At 4:28 PM -0400 5/22/06, Henning Schulzrinne wrote:
>There seem to be two approaches to this problem: client-based and server-based.
>
>In a client-based approach, the server returns an error when a particular service is unavailable. The client then retries with the more general service (sos.police -> sos).
>
>Ted seems to advocate the server-based approach where the server "guesses" (quoted, since this might be a fairly predictable algorithm) what the user would want in the absence of its first choice.

I actually don't think that's what I'm advocating.   I believe there are cases
where queries will come in for service URNs that are not supported in the local
area.  If a local administration decides that those do not need to get any
service, then a normal "no data" message is returned.  I believe, though,
that there are cases where they will wish to use one of the emergency
service responders as a "backup" service for unknown sos services.  Brian
indicates that this is commonly police, and I've used that in my examples.

I believe the best way to handle that is for the local administration to provision
the unsupported emergency service URNs with the same data as is present
for the "backup" service (that, is put the sos.police data at sos.foo if sos.foo
is not supported).  Nobody has to guess at that point; it is a straightforward
result.

Based on Brian's message, though, I believe there will be cases where the
local authorities may not want to provision those service URNs, but will want
instead for the LoST server to return what is, essentially, a compound message
"There is no service available for your query; the backup service is sos.police,
and here is its contact URI".   This may be to manage the client expectation or
to avoid caching of data that is not, strictly speaking correct.  The example
I can imagine most clearly here is for a sos.poison.  If the jurisdiction doesn't
have a poison service or a top-level sos service, the client's query for sos.poison
being redirected to sos.police may be far enough off that a client would
prefer to try to make a non-emergency call to a known hospital number
instead.  Other clients might decide to continue the call and ask for police
help with finding a poison center.  Whichever choice is made, though,
the metadata about the redirection to other responders may be valuable.

Note that none of this is service "guessing"; it's the jurisdiction covering
the location saying what it wants returned--I think that will be easy if
they do it by providing contact URIs for the services, but also do-able if
they want to provide both a contact URI and the metadata of which
service will be really handling the call.

Let's put this in jurisdictional terms for a second.  If Happyland has services for
fire, police, ambulance, and coast guard services, the Happylanders likely know
those relevant telephone numbers and will call them in the appropriate moments.
When Happyland adopts LoST, they will populate their LoST servers with contact URIs for
sos.fire, sos.police, sos.ambulance, and sos.marine.  In the telephone system, they
may well have only the specific numbers, with no general telephone number at
all.

If I roam into Happyland, I may be doing so from someplace that uses a single
response number for all those services.  When I try to look up the contact URI for
emergency services, in other words, I'm going to query for sos alone.   There is
no such service in Happyland.

What happens next?

If the LoST server returns only that there is no data for sos, the device
must at least spend time re-querying, which is a loss of time.  If the device
knows about sos.fire, sos.police, sos.ambulance, and sos.marine, etc. it will
presumably need only a few round trips to find something that works,
but any UI input needed will take attention as well as time--which is not
great.  In the proxy case, there is no chance that the proxy will know which
more specific URN to try; it will have to work off some sort of priority table. 
The device or proxy may also not know of some URNs in use in Happyland.
I'm particularly worried about that in cases where a user input like
a dialed 911 or 112 is triggering this input.

I think we should acknowledge that a client may have to go through this,
but push as much as we can to avoid it.  That means treating it as "best practice"
to create an entry for the covering sos service *even if there is no corresponding
telephone number*.  Failing that, allowing the LoST server to indicate in metadata
that the contact URI is for a service that *will respond* but is not the one for
which the query is made is a second line of defense.  I'd like to see the client/proxy
picking a URN from its known set as the last line of defense.

				regards,
					Ted Hardie

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 22 May 2006 18:17:41 -0400

> those are important attributes for emergency use cases.

Since the query is done well ahead of the emergency, this is probably of 
  only modest concern. I suspect that the difference is essentially one 
round-trip time, at most.

> and sos.crazy-persons?  What am I suppose to do with those?

Ignore the ones you don't care about, but an implementation might, as 
discussed separately, add them to the user's address book since the user 
might actually care about scuba accidents, even if the phone wasn't 
programmed for divers or this new service was added after the phone was 
built.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 22 May 2006 18:30:19 -0400

> tree, and populate one or both and have the client know the difference? 

I'm probably misunderstanding you, but this seems to be a labeling (URN) 
issue, not a lookup issue. child-help would be in one place, either as 
urn:service:sos.child-help or as urn:service:counseling.child-help. We 
would pick one, knowing that the boundaries between these are not 
perfectly well defined, but it doesn't much matter as long as users (and 
their address books) know where to find them. After all, users would 
never dial urn:service.anything; they'd follow a textual or iconic 
description in their pre-populated address book on their cell phone or a 
link on a web page.

As discussed previously, the properties of the call to such services, 
such as whether location is desired or mandatory, would be stored in the 
LoST record for that service and jurisdiction. This makes it easy to 
have different policies in different countries, reflecting national laws 
and customs. This is true across services. (For example, the poison 
control emergency service in the US does not, as far as I know, have a 
legal right to my location or identity information and there might be 
good reasons to keep it that way, if the poison happens to be derived 
from cold pills or is a white powder.)

> returning one or more items in a list.

Except in the second case, it is a separate operation which is useful by 
itself. I'm trying to keep things modular and simple, without recreating 
very similar functionality in different places.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Mon, 22 May 2006 18:30:59 -0400

> programmed for divers or this new service was added after the phone was 

Yeah, but who do I call when there is a fire?

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 22 May 2006 18:38:21 -0400

I suspect you're trying to say something deep that I'm missing, but it 
is either

- 911 or 112 if that's what I'm trained to do (which is auto-configured 
by LoST to reach urn:service.sos and the appropriate URL)

- the PSAP URL that the local jurisdiction has assigned to the 
urn:service.sos.fire service in the LoST record (which might well be the 
same as that for urn:service.sos or urn.service.sos.police or maybe even 
urn.service.sos.animal-control, but that's of no concern to the caller)

- if there is none, the generic (next-layer-up) service, i.e., 
urn:service:sos and the PSAP URL that goes with that.

Henning

Andrew Newton wrote:
>> discussed separately, add them to the user's address book since the 
>> user might actually care about scuba accidents, even if the phone 
>> wasn't programmed for divers or this new service was added after the 
>> phone was built.
>

---

From: Andrew Newton <[email-masked]>
Date: Mon, 22 May 2006 20:45:57 -0400

On May 22, 2006, at 6:38 PM, Henning Schulzrinne wrote:

> I suspect you're trying to say something deep that I'm missing, but  
> it is either
>
> - 911 or 112 if that's what I'm trained to do (which is auto- 
> configured by LoST to reach urn:service.sos and the appropriate URL)
>
> urn:service.sos.fire service in the LoST record (which might well  
> be the same as that for urn:service.sos or urn.service.sos.police  
> or maybe even urn.service.sos.animal-control, but that's of no  
> concern to the caller)
>

I'm not trying to say anything deep, I'm just trying to figure out  
how you imagine this will work (perhaps that does require a lot of  
deep thinking).

My alarm panel, which uses VoIP, has three buttons (actually 6, 2  
rows of three that require both buttons in each row to be pressed).   
One is labeled "Police", one is labeled "Ambulance" and one is  
labeled "Fire".  If I press fire, urn:service.sos.fire is sent to the  
LoST server.  The lost server then responds with  
urn:service.sos.scuba-accidents, urn:service.sos.crazy-persons, and  
urn:service.sos.duck-patrol.  Why is it not proper for the LoST  
server simply to respond with "you want urn:service.sos" and here is  
the URI for that PSAP."  Why must the client have to requery by  
knocking of a label?

BTW:  I thought there was no tree structure for these URNs, so what  
does "next-layer-up" mean?

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 22 May 2006 21:27:01 -0400

> rows of three that require both buttons in each row to be  
> pressed).  One is labeled "Police", one is labeled "Ambulance" and  
> one is labeled "Fire".  If I press fire, urn:service.sos.fire is  
> sent to the LoST server.  The lost server then responds with  
> server simply to

I'm not suggesting that the server respond with scuba-accidents or  
the like; I'm not sure where I gave you this impression.

> respond with "you want urn:service.sos" and here is the URI for  
> that PSAP."  Why must the client have to requery by knocking of a  
> label?

Why not just provide the PSAP URL in that case, even if it's the same  
answer that urn:service:sos would return? After all, this PSAP is, by  
definition, able to provide access to fire department services. That  
it is not an organizationally separate entity seems to be of no  
interest to the caller.

> does "next-layer-up" mean?

There is no tree structure, but I thought earlier discussion had  
agreed that the top-level service (urn:service.x) is always valid if  
there are any sub-services?

---

From: Andrew Newton <[email-masked]>
Date: Mon, 22 May 2006 21:59:33 -0400

On May 22, 2006, at 9:27 PM, Henning Schulzrinne wrote:
> Why not just provide the PSAP URL in that case, even if it's the  
> same answer that urn:service:sos would return? After all, this PSAP  
> is, by definition, able to provide access to fire department  
> services. That it is not an organizationally separate entity seems  
> to be of no interest to the caller.

I think we are saying the same thing, then.

>>
>> BTW:  I thought there was no tree structure for these URNs, so  
>> what does "next-layer-up" mean?
>
> agreed that the top-level service (urn:service.x) is always valid  
> if there are any sub-services?

I must have missed that, but I'm fine with this idea.

-andy

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 23 May 2006 17:15:07 -0500

I think that what Ted is saying/assuming is that sos is a generalization of sos.police, and it is therefore logical that sos be used in the absence of sos.police.  The same cannot be said for the reverse, sos.police is probably not a reasonable generalization of sos.  Therefore, if you only have sos.police, and that is the entity that you intend to have serve sos, then you duplicate that data in the sos record, rather than "redirecting" sos queries to sos.police.

Best Practice would therefore dictate that you would always have data for sos.  What happens after that, for the "sub-services" is entirely up to local policy.

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Tuesday, 23 May 2006 7:19 AM
> To: 'Ted Hardie'; 'Hannes Tschofenig'
> Cc: 'Stastny Richard'; [email-masked]
> Subject: RE: [Ecrit] Summary of Recent Discussion
> 
> I am confused by
> > Returning the contact URI and the service URN for sos.police when there
> is
> > no sos
> > present at sos.police.  (Given that this is not a protocol mechanism,
> this
> > would
> > >>make some decision (e.g. drop the call if they were calling in a
> police
> > brutality
> > >>item in the LoST emergency server; it really does help
> interoperability
> > here to
> > >>have a default.
> > >
> > Sorry for the confusion.  I am suggesting that it should not be a
> protocol
> > error
> > URN differed from the one that was requested.  I think the base reason
> for
> > this
> > I return the contact URI, and let the client know that the contact URI
> is
> > for
> > Returning the contact URI and the service URN for sos.police when there
> is
> > no sos
> > present at sos.police.  (Given that this is not a protocol mechanism,
> this
> > would
> > other than continue the call.  I don't thing we ought to be too
> concerned
> > about that,

------------------------------------------------------------------------------------------------
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]