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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Sat, 13 May 2006 22:31:16 +0100

In the UK the equivalent is run by a charity, which has in the past made play that it is independent of any authority in promoting itself to its clients. 

So from a UK perspective, I would have no difficulty in seeing it grouped with other counselling services.

If classed as an emergency service, I suspect that in the absence of a local provider, the routeing to a default PSAP that may well be the police would cause distress to some callers.

regards

Keith

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: 13 May 2006 17:21
> To: Stastny Richard
> Cc: [email-masked]
> Subject: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline
> 
> 
> > 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.
> 
> 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".
> 
> 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
> 

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

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Sat, 13 May 2006 22:36:01 +0100

By the way, in Henning's original mail, I note that he implied that emergency calls never have privacy.

I understand Japan does require any privacy expressed by the caller in making the call to be honoured when delivered to the PSAP.

Therefore calling identity privacy cannot be regarded as a distinguishing factor between these groupings of service.

regards

Keith

> From: Drage, Keith (Keith) 
> Sent: 13 May 2006 22:31
> To: 'Henning Schulzrinne'; Stastny Richard
> Cc: [email-masked]
> Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child
> helpline
> 
> 
> In the UK the equivalent is run by a charity, which has in 
> the past made play that it is independent of any authority in 
> promoting itself to its clients. 
> 
> So from a UK perspective, I would have no difficulty in 
> seeing it grouped with other counselling services.
> 
> If classed as an emergency service, I suspect that in the 
> absence of a local provider, the routeing to a default PSAP 
> that may well be the police would cause distress to some callers.
> 
> regards
> 
> Keith
>

---

From: "Stastny Richard" <[email-masked]>
Date: Sun, 14 May 2006 00:20:40 +0200

Keith;

>In the UK the equivalent is run by a charity, which has in the past made play that it is independent of any authority in >promoting itself to its clients.

>If classed as an emergency service, I suspect that in the absence of a local provider, the routeing to a default PSAP that >may well be the police would cause distress to some callers.

As I said, the issue is (currently) a national matter, in Austria it is treated by ordinance as an
emeregncy service.
 
OTOH, the issue has been taken now to a global (ie. political) level, originally at the

"World Summit on Information Society (Tunis, 14-20 November 2005): Article 92 states "We encourage countries, including all other interested parties, to make available child helplines, taking into account the need for mobilization of appropriate resources. For this purpose, easy-to-remember numbers, accessible from all phones and free of charge, should be made available."

This statement caused the input from Chile Helpline International, a global network of helplines
for children and young in 103 countries to ITU-T. There was strong support by the member states
for this, causing now the circular sent to all meber states.

As you also see, the milestones are defined in such a way to get some feedback already
before the plenipot meeting in November in Antalya, where I suspect that this issue
will get some attention.

And one also may assume that some decisions will be made to announce some 
success i-e commitment (I am now citing again from the input document to ITU-T SG2:)

May 17th is World Telecoms Day.  The theme for 2007 is children and youth.  This day celebrates children as key players in the information society.  It would therefore be an ideal opportunity to announce the telecoms sector's commitment to a toll free, easy to remember, 3-4 digit number for all children, so that every child in need of care and protection knows that help is just a phone call away!

It would be nice if IETF could also contribute something to this commitment of
the telecoms sector in 2007

This seems to be  a very political issue.

regards
Richard

---

From: "Roger Marshall" <[email-masked]>
Date: Wed, 17 May 2006 16:40:09 -0700

PSAP_preference_info is likely to be more static than dynamic in nature.
Not so much that this PSAP is 'dark' due to an outage, (though maybe we
want think about this in terms beyond a single fallback PSAP), but more
descriptive of how this PSAP differs from the next PSAP, for example:

A classic case may be to differentiate between a user's predetermined
desire to only invoke an emergency response from the Capital Police vs.
the District police when in D.C., or a parent's want to avoid the Disney
Security and instead get Orange County Police on the scene after a
tragedy, etc.  In cases like these, jurisdictional boundaries often
blur.

-roger.

>From: Brian Rosen [mailto:[email-masked]] 
>Sent: Wednesday, May 17, 2006 4:18 PM
>To: 'Ted Hardie'; Roger Marshall; 'Henning Schulzrinne'; 
>'Spencer Dawkins'
>Cc: [email-masked]
>Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 
>Child helpline
>
>I hadn't thought about it before, but it does make sense to 
>return a list of all the service identifiers that LoST could 
>return a URI for.
>
>I'm not so sure about PSAP preference info.  Normally, I would 
>expect to get that in the INVITE response.  Is there something 
>outside of that you think would be interesting?  What? How is 
>it represented?
>
>Brian
>
>From: Ted Hardie [mailto:[email-masked]]
>Sent: Wednesday, May 17, 2006 7:00 PM
>To: Roger Marshall; Henning Schulzrinne; Spencer Dawkins
>Cc: [email-masked]
>Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 
>Child helpline
>
>At 3:49 PM -0700 5/17/06, Roger Marshall wrote:
>>As used for emergency services, I assume LoST produces the following
>>outputs:
>>
>>A. ) given location as input, LoST returns service identifier (e.g.
>>urn:service:sos)
>
>I don't think I understand this.  You want the LoST server to 
>return the supported service identifiers in response to a 
>query containing only location?
>
>
>
>>B. ) given location + service identifier as input, LoST returns PSAP 
>>URI C. ) given location + service identifier as input, LoST returns 
>>PSAP URI
>>+ dial string
>>D. ) given location + service identifier as input, LoST returns PSAP 
>>URI
>>+ dial string + PSAP_preference_info
>
>Is PSAP_preference_info the same as a fallback PSAP, or something else?
>
>
>>Are there more cases?
>>
>>Roger Marshall
>>
>>>Sent: Wednesday, May 17, 2006 2:56 PM
>>>To: Spencer Dawkins
>>>Cc: [email-masked]
>>>Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child 
>>>helpline
>>>
>>>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)...
>>>>
>>>> Please check my math in draft-hardie-ecrit-lost-00.txt.
>>>>
>>>> Comments? It's "location *to* service translation", right? :-)
>>>

---

From: "Roger Marshall" <[email-masked]>
Date: Wed, 17 May 2006 16:52:54 -0700

Right after the the end device is deployed, but right before the LoST
server is deployed - that's one case...

Agree that the universal case poses few problems, but what happens when
the device crosses into a jurisdiction which handles service types
differently?  For example, a user invokes a setup routine, based on
location (plus maybe something additional, like the string "fire"), LoST
could return urn:service:sos.fire while visiting Japan, whereas returns
urn:service:sos when back in the U.S. 

Roger Marshall

>From: Thomson, Martin [mailto:[email-masked]] 
>Sent: Wednesday, May 17, 2006 4:24 PM
>To: Roger Marshall; Ted Hardie; Henning Schulzrinne; Spencer Dawkins
>Cc: [email-masked]
>When do you think that a LoST client will not know about 
>urn:service:sos?
>
>I'd recommend against this.  A decision was made in DNS not to 
>provide a way to query for indexes.  This is similar.  Given 
>an arbitrarily large number of possible services you end up 
>with arbitrarily large responses.
>
>> From: Roger Marshall [mailto:[email-masked]]
>> Sent: Thursday, 18 May 2006 9:11 AM
>> To: Ted Hardie; Henning Schulzrinne; Spencer Dawkins
>> Cc: [email-masked]
>> Ted:
>> Please see my responses inline.
>> 
>> >Sent: Wednesday, May 17, 2006 4:00 PM
>> >I don't think I understand this.  You want the LoST server 
>to return 
>> >the supported service identifiers in response to a query containing 
>> >only location?
>> >
>> 
>> Yes.  If location is all you've got, then why not?  At the 
>very least, 
>> LoST could return the universal emergency service identifier, 
>> "urn:service:sos".
>> 
>> >
>> >
>> I'm loosely referring to what has been discussed on the list 
>recently, 
>> wrt the idea that some UAS' 
>will_require/won't_require/won't_accept a 
>> location object to be provided with the call, for example.
>> 
>> -roger.
>> 
>---------------------------------------------------------------
>---------------------------------
>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]
>

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 18 May 2006 15:09:18 +0200

I like this approach
some questions
 
In A.)  it is service identifier(s)

should not PSAP preference returned always?
 
The dial string should be a specific query
 
Richard

________________________________

Von: Roger Marshall [mailto:[email-masked]]
Gesendet: Do 18.05.2006 00:49
An: Henning Schulzrinne; Spencer Dawkins
Cc: [email-masked]
Betreff: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline

A. ) given location as input, LoST returns service identifier (e.g.
urn:service:sos)
B. ) given location + service identifier as input, LoST returns PSAP URI
C. ) given location + service identifier as input, LoST returns PSAP URI
+ dial string
D. ) given location + service identifier as input, LoST returns PSAP URI
+ dial string + PSAP_preference_info

Are there more cases?

Roger Marshall

>Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03
>Child helpline
>
>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 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

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 18 May 2006 14:20:45 -0400

Ummm...  I don't boot my cell phone every time I cross an SP or
jurisdictional boundary.

There seems to be a potential danger here of too much success.  What if
a query without URN results in a phone book size list of service URNs?
Much more than I might have configured memory for?

Better maybe to have urn:service:sos as the default or let the first
query be urn:service:top or * to fetch the next level below service.

I also didn't understand the need for two RTT.  If you tell me there is
urn:service:sos why not also provide the PSAP URI at the same time?

That is, options A-D collapse to one:

Input: location + URN (default to urn:service:sos)
Ouput: URN + [PSAP] URI/dialstring + preference info 

If just intending to browse the tree:

Input: location + "urn:service:*"
Ouput: list of next level:
       URN + URI/dialstring + preference info 

Mike

> Sent: Wednesday, May 17, 2006 8:33 PM
> To: Ted Hardie
> Cc: [email-masked]; Thomson, Martin
> > If this functionality is desired at all, I feel strongly 
> that it not 
> > be the result of sending a simple "location/no service" query.  If 
> > someone sent a location with
> >
> 
> Definitely - this should be a separate query. I don't believe 
> in "let me guess what you meant and good luck figuring out 
> what to do with the response" protocols.
> 
> > no urn, I would far rather that be sent the response for 
> > urn:service:sos, with the service urn populated in the 
> response.  To 
> > me, that's the "default response"
> > for an emergency service lookup.
> >
> > Even that is broken--we should ensure that LoST clients 
> know at least 
> > urn:service:sos, but it is the right "be liberal in what 
> you accept" 
> > response to brokenness.  At best, the returning of a list causes a 
> > round trip before the client selects a service to request, 
> and I don't 
> > want additional round trips when my car is on fire.
> 
> Any "list services" queries would be done on boot (when 
> configuring dial strings and such), not when routing a call.
> 
> 
> >
> > Assuming that it is not the default response, but is a 
> query for "what 
> > URNs do you support", I would agree that having it as a protocol 
> > mechanism might be useful.  But I would not in deployment, I would 
> > suggest that it be one of the first things turned off 
> during a DoS or 
> > other attack indicator.  And I wouldn't be upset at finding some 
> > service providers never turning it on.
> >
> > 				regards,
> > 					Ted Hardie
> 
>