Subject: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline

From: "Stastny Richard" <[email-masked]>
Date: Sat, 13 May 2006 23:02:11 +0200

Henning,

> I can remember that in on older version was also a sos.child
> (as I proposed because we have such a help-line under our
> emergency services in Austria)
>

I checked; while this might have been discussed at some point, it 
wasn't in the earlier versions or in sipping-sos.

> This has now vanished in the latest definitions in section 4.3
> sos service types

I'm happy to include it, but given the recent discussion about 
limiting sos.* to emergency, immediate-help situations, I want to 
make sure that there is consensus that this is appropriate.

[Richard] Thanks for checking, I could just remeber that I once posted
all of our 9 (NINE) emergency services ;-)

For example, in the US, this seems to be a counseling service for run-
aways (http://1800runaway.org/), which could be considered an 
emergency, but also seems to be a general counseling service.

I'm starting to wonder if it wouldn't make more sense to group all of 
these counseling services (mental health, run-away, drug and alcohol 
abuse, suicide prevention, etc.) into a new top category, such as 
"advice".

[Richard] As you see from the request from Child Helpline International
and also from the draft circular questionary, it is also unclear to them and to SG2 if
this should be an emergency service or a counseling service using toll free numbers.
 
[Richard] Our problem is that we cannot decide in IETF what of these
services is an emergency service, because this is a national matter.
Also what is an conselling service and what
other services might be there: e.g services for public interest, but not toll free,
e.g. car break down services. Directory services with additional charges
services where location information MUST be provided, services where
location information is only by user push, and services where location
information and identity must be withheld, etc. etc
 
[Richard] IMHO we should try to define these types of services,
but leave it to the national implementations to define in what box
they put specific services.
 
regards Richard

One practical reason is that these services have somewhat different 
privacy and location needs compared to traditional fire/police/
ambulance emergency services. For example,  I don't think it would 
make sense to mandate location and identity disclosure for these 
counseling services. Indeed, many of these services offer anonymity 
to encourage calls, even though 800 numbers in the US obviously allow 
the agency to see the calling number, even with CLID restrictions.

The UA requirements draft will presumably mandate inclusion of 
location information in all sos.* calls; this does not seem 
appropriate for these crisis counseling services.

Henning

>
> I bring this to your attention because at the SG2 Meeting this
> week in Geneva a request for numbering resources was brought
> forward to Q1 by Child Helpline International. For your information
> I copy the relevant text of the Q1 Report below.
>
> As you see from the text, a draft circular was created
> to request information by ITU TSB from member states on
> this issue and also on a emergency numbers in general.
>
> Since this is also for interest for ECRIT, I copy also
> the draft circular below. You should keep in mind that
> this is only a draft and will be modified by TSB before
> sent out officially.
>
> The results of this survey will also prove useful for
> the further work of ECRIT.
>
> best regards
>
> Richard Stastny
>

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 13 May 2006 17:33:17 -0400

Note to ECRIT participants: This issue raises a larger point, so even  
if you don't care about child helplines, take a look at the proposal  
at the bottom.

> this should be an emergency service or a counseling service using  

There seem to be at least three dimensions for such services, all of  
which are somewhat beyond the scope:

- whether to allow non-registered and expired subscribers to use  
these services (true for 800# on payphones, but not from private  
residences, for example)

- whether to mandate inclusion of location information

- whether to use a regular number (800#, say) or a short three/four  
digit number, i.e., the dial string

> they put specific services.

While we don't have to decide on dial strings and issues of network  
access (this can be done on a local basis or can be contained in LoST  
records), the inclusion of location information needs to be  
universal, not national UNLESS we also include this information in  
the LoST record, along with the dial string.

My inclination would be to focus on the universally-agreed upon  
immediate-response-with-location-needed services in sos for now, but  
also define an attribute in the LoST schema that indicates location  
inclusion.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 14 May 2006 01:33:51 +0200

Hi Henning,

it was foreseeable that the grouping would be difficult.

I, however, agree with your proposal to focus on the 
immediate-response-with-location-needed services in the Service URN 
draft as part of the SOS branch.

Some other services do not seem to that (a) very urgent or (b) may 
impose different authentication, authorization, location and charging 
requirements. It might be interesting to state in the IANA consideration 
section that the definition of new services need to investigate these 
aspects.

Regarding the additional attribute in LoST to indicate the need to 
include location information:

For the SOS services the inclusion of location info does not need to be 
explicit. It is obvious from the definition in the document. For other 
services it might be reasonable to argue that in some countries location 
info is required and in other countries it isn't. Hence, LoST could 
provide this info.

Ciao
Hannes

Henning Schulzrinne wrote:
> if you don't care about child helplines, take a look at the proposal  at 
> the bottom.
> 
> 
> - whether to allow non-registered and expired subscribers to use  these 
> services (true for 800# on payphones, but not from private  residences, 
> for example)
> 
> records), the inclusion of location information needs to be  universal, 
> not national UNLESS we also include this information in  the LoST 
> record, along with the dial string.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 13 May 2006 20:00:19 -0400

>
> For the SOS services the inclusion of location info does not need  
> to be explicit. It is obvious from the definition in the document.  
> For other services it might be reasonable to argue that in some  
> countries location info is required and in other countries it  
> isn't. Hence, LoST could provide this info.

Well, according to recent messages, this doesn't even seem  
universally true for emergency calls (see the Japan example). Even  
within emergency services, this is, strictly speaking, not true. For  
example, in the US, poison control (1-800-222-2222) clearly doesn't  
expect location information and probably has no legal basis for  
demanding it.

Henning

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 14 May 2006 02:14:11 +0200

Hi Henning,

Henning Schulzrinne wrote:
>>
>> For the SOS services the inclusion of location info does not need  to 
>> be explicit. It is obvious from the definition in the document.  For 
>> other services it might be reasonable to argue that in some  countries 
>> location info is required and in other countries it  isn't. Hence, 
>> LoST could provide this info.
> 
> 
> Well, according to recent messages, this doesn't even seem  universally 
> true for emergency calls (see the Japan example).

I guess you refer to Keith's message. He referred to identity privacy 
(if I understood him correctly).

> Even  within emergency 
> services, this is, strictly speaking, not true. For  example, in the US, 
> poison control (1-800-222-2222) clearly doesn't  expect location 
> information and probably has no legal basis for  demanding it.
This makes the classification not necessarily easier.

It, however, demands an attribute that indicates to express whether 
location info is needed for a specific service identifier.

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 13 May 2006 20:21:55 -0400

On May 13, 2006, at 8:14 PM, Hannes Tschofenig wrote:

>>> For the SOS services the inclusion of location info does not  
>>> need  to be explicit. It is obvious from the definition in the  
>>> document.  For other services it might be reasonable to argue  
>>> that in some  countries location info is required and in other  
>>> countries it  isn't. Hence, LoST could provide this info.
>> universally true for emergency calls (see the Japan example).
>
> I guess you refer to Keith's message. He referred to identity  
> privacy (if I understood him correctly).

Right, but those seem essentially the same, at least for fixed-line  
services. After all, getting the location from the phone number and  
vice versa is often fairly easy, particularly for a government  
agency. (See recent US headline news...)

>
>
>> Even  within emergency services, this is, strictly speaking, not  
>> true. For  example, in the US, poison control (1-800-222-2222)  
>> clearly doesn't  expect location information and probably has no  
>> legal basis for  demanding it.

One pretty simple solution is to have a four-valued attribute:

- required --> no service without it; you're legally obligated to  
provide it for this service
- helpful  --> the receiver would like to have this information, but  
isn't going to refuse the call and you're not legally obligated; if  
you route the call yourself, you don't need to include it in signaling
- routing  --> the receiver doesn't need it, but it's used to route  
the call
- ignored  --> the receiver will just ignore the location information  
and there's no location-based routing

I suspect this can be split into two dimensions (routing and end  
system).

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 14 May 2006 17:28:17 +0200

Hi Henning,

Henning Schulzrinne wrote:
> vice versa is often fairly easy, particularly for a government  agency. 
> (See recent US headline news...)

As a general statement it is, however, not true.

> isn't going to refuse the call and you're not legally obligated; if  you 
> route the call yourself, you don't need to include it in signaling
> - routing  --> the receiver doesn't need it, but it's used to route  the 
> call
> I suspect this can be split into two dimensions (routing and end  system).
> 
Does not sound like a bad idea.
This assumes that these properties do not change on a regular basis or 
depend on parameters that cannot be provided by LoST (e.g., user 
specific properties).

What do other people think?

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 16 May 2006 09:02:14 -0400

>> - helpful  --> the receiver would like to have this information,  
>> but  isn't going to refuse the call and you're not legally  
>> obligated; if  you route the call yourself, you don't need to  
>> include it in signaling
>> - routing  --> the receiver doesn't need it, but it's used to  
>> route  the call
>> - ignored  --> the receiver will just ignore the location  
>> information  and there's no location-based routing
> This assumes that these properties do not change on a regular basis  
> or depend on parameters that cannot be provided by LoST (e.g., user  
> specific properties).
>

I suspect that these attributes would be governed by national or  
state laws and regulations, which presumably change slowly and with  
advance notice, well outside the anticipated caching intervals for  
LoST records.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 16 May 2006 09:09:34 -0400

Let's back off a moment and consider what this is for. The purpose of 
the service URN, as far as ECRIT is concerned, is to provide an 
unambiguous indication that the call should be routed to a PSAP. It's 
all very well to have attributes whose treatment is defined by local 
policy, but what about the proxy half-way around the world that has to 
recognize an emergency call?

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 16 May 2006 09:25:32 -0400

Service URNs indeed serve as identification, both in the end system  
and in points along the way to the destination. My goal is to hard- 
code as little as possible, so that we can adjust the system over  
time, without changing end systems and new protocol specs.

The basic idea is that all entities along the way can look up  
identifiers and determine

- what users should dial if they have a twelve-button phone
- where to route the call (based on the identifier and location)
- whether the call should contain location information
- whether the location information should be (or can be) end-to-end  
encrypted

Not all calls may end up in a PSAP (see poison control).

On May 16, 2006, at 9:09 AM, Tom-PT Taylor wrote:

> Let's back off a moment and consider what this is for. The purpose  
> of the service URN, as far as ECRIT is concerned, is to provide an  
> unambiguous indication that the call should be routed to a PSAP.  
> It's all very well to have attributes whose treatment is defined by  
> local policy, but what about the proxy half-way around the world  
> that has to recognize an emergency call?

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 16 May 2006 09:35:33 -0400

I would say that the service URN defines what service location based routing
is needed for.  I don't think it should be up to ecrit to define which
services location based routing is needed.  We're defining a mechanism: put
in location and service type (URN) and get out URIs.  That's enough for
ecrit.

We can try to make the organization of the service URN tree structure
reflect some sort of common reality, but we are highly unlikely to be always
right all of the time.  I think it would be a mistake to try to infer any
kind of policy decision by the shape of the "urn:service." tree.

I don't think that matters.  It can be a local policy (or maybe a policy
that is associated with the dialstring that is mapped to the service URN)
whether this is an "emergency", whether location is forwarded, etc at the
location the call originates from.

Brian

---

From: Andrew Newton <[email-masked]>
Date: Tue, 16 May 2006 09:40:21 -0400

> kind of policy decision by the shape of the "urn:service." tree.

If that is true, then there is likely never a point-in-time when the 
tree will match reality.  And since we are shooting for global 
interoperability here, perhaps we should just stop with sos.

-andy

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 16 May 2006 09:42:15 -0400

My starting point is ECRIT's requirement, I thought. Originally that was 
for some way to mark a call to indicate that it was an emergency call. I 
just finished reading the first part of section 6 of the requirements 
document and can hardly recognize it.

I can't quite understand the current intention. Is it:

(a) that the client passes the identifier in the mapping request and 
gets back a URI appropriate to that identifier, so that the mapping 
database becomes more general-purpose than just to locate PSAPs; or

(b) that the mapping response includes an identifier to be appended to 
the call; or

(c) something else?

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 16 May 2006 10:47:58 -0400

> kind of policy decision by the shape of the "urn:service." tree.

I think we're at least talking past each other. The whole point of my 
suggestion was to avoid "inferring any kind of policy decision by the 
shape of the ... tree". Rather, each party should be able to look up 
what the local provider of the service needs or wants (or feels legally 
entitled to), so that the client can make a choice whether and how to 
use the service. Consider this to be the policy equivalent of 
auto-configuration, rather than hard-configuring choices forever and 
everywhere.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 16 May 2006 10:57:55 -0400

Certainly (a).

In addition, the SIP (or other protocol) request is marked with the 
identifier. How this is done obviously depends on the protocol, so the 
URN document is silent on this aspect. The idea is to use the 
Request-URI for the URN and Route headers for the PSAP. The URN would be 
inserted either by the UA or by the outbound proxy if the dial string is 
recognized by that outbound proxy.

This would presumably also work with various B2BUAs.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 16 May 2006 11:04:58 -0400

Actually, I thought I was agreeing with you:
> The basic idea is that all entities along the way can look up identifiers
and determine

I thought that meant the LoST operation that did dialstring to service URN
for a location returned policy for that service at that location.

I was asserting that trying to get policy out of where in the service tree
you were was not a good idea, because Child Help may be an emergency (sos)
in some parts of the world and human services, not an emergency in others.
Whether it goes in service.sos or service.human shouldn't infer whether it's
an emergency or not.

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Tuesday, May 16, 2006 10:48 AM
To: Brian Rosen
Cc: [email-masked]
Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 16 May 2006 13:27:45 -0400

>> The basic idea is that all entities along the way can look up identifiers

Glad to hear that; sorry I misunderstood.

> for a location returned policy for that service at that location.

Indeed. The LoST operation would presumably return policy either when 
looking up the dial string or when determining the destination. In 
almost all cases, these will be the same scopes and lifetimes, but one 
could theoretically imagine that they have separate scope ("By Vermont 
state law, you don't have to provide location information when dialing 
911". Obviously made up).

> Whether it goes in service.sos or service.human shouldn't infer whether it's

We're indeed in full agreement on this point.

Henning

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 16 May 2006 13:47:00 -0400

I obviously haven't been paying attention. LoST is taking dial strings 
as arguments??

Brian Rosen wrote:
...
> for a location returned policy for that service at that location.
...
> Brian
...

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 17 May 2006 16:50:19 -0500

Having looked at this yesterday, "dialstring" is part of the LoST RESPONSE 
example in the current LoST draft, not part of the request, so I think we 
are confused here (which may be as simple as the LoST draft being out of 
phase with what people think, or may be something else)...

Please check my math in draft-hardie-ecrit-lost-00.txt.

Comments? It's "location *to* service translation", right? :-)

Thanks,

Spencer

>I obviously haven't been paying attention. LoST is taking dial strings as 
>arguments??
>
> Brian Rosen wrote:
> ...
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 17 May 2006 17:56:14 -0400

LoST maps location and service URN to a set of answers. Thus, you have

query to LoST: "I'm in Tokyo, Japan and interested in the fire brigade"

response: "Your dialstring is XYZ and the PSAP URL is 
[email-masked]"

Spencer Dawkins wrote:
> Having looked at this yesterday, "dialstring" is part of the LoST 
> RESPONSE example in the current LoST draft, not part of the request, so 
> I think we are confused here (which may be as simple as the LoST draft 
> being out of phase with what people think, or may be something else)...
>