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

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

Ted:
Please see my responses inline. 

>-----Original Message-----
>From: Ted Hardie [mailto:[email-masked]] 
>Sent: Wednesday, May 17, 2006 4: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?
>

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".

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

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.

>
>
>>Are there more cases?
>>
>>Roger Marshall
>>
>>>-----Original Message-----
>>>From: Henning Schulzrinne [mailto:[email-masked]]
>>>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? :-)
>>>
>>>_______________________________________________
>>>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: "Thomson, Martin" <[email-masked]>
Date: Wed, 17 May 2006 18:23:30 -0500

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]
> Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline
> 
> Ted:
------------------------------------------------------------------------------------------------
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: Henning Schulzrinne <[email-masked]>
Date: Wed, 17 May 2006 19:51:29 -0400

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

And since LoST can be used beyond just urn:service:sos, the list of  
services could indeed be fairly large, depending on how the  
urn:service: hierarchy evolves. However, unlike DNS, the restrictions  
on query size aren't as relevant. It might be possible to have a more  
restricted listing, such as listing sub-services for a particular  
service, so that a client can automatically determine whether there  
are separate dial strings for fire and police, say. The alternative  
is that the client polls for every possible emergency service it  
knows about, which seems much worse and also makes adding services  
later very hard.

Henning

---

From: Ted Hardie <[email-masked]>
Date: Wed, 17 May 2006 17:04:48 -0700

At 7:51 PM -0400 5/17/06, Henning Schulzrinne wrote:
>And since LoST can be used beyond just urn:service:sos, the list of services could indeed be fairly large, depending on how the urn:service: hierarchy evolves. However, unlike DNS, the restrictions on query size aren't as relevant. It might be possible to have a more restricted listing, such as listing sub-services for a particular service, so that a client can automatically determine whether there are separate dial strings for fire and police, say. The alternative is that the client polls for every possible emergency service it knows about, which seems much worse and also makes adding services later very hard.
>
>Henning

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

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 17 May 2006 19:05:19 -0500

I don't have a problem with asking for sub-services.  For instance, I know about urn:service:massage, but I might like to know that urn:service:massage.swedish exists.  That's valuable.

Of course, the advantage with what we have currently is that this feature can be added later.  If it isn't necessary, then we can leave it until we don't have more pressing problems to address.

Q: If I try to resolve urn:service:sos.fire and it doesn't exist, can the LoST server unilaterally return the result for urn:service:sos?

> Sent: Thursday, 18 May 2006 9:51 AM
> To: Thomson, Martin
> Cc: Roger Marshall; Ted Hardie; Spencer Dawkins; [email-masked]
> Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline
> 
> >

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 17 May 2006 20:12:01 -0400

On May 17, 2006, at 8:05 PM, Thomson, Martin wrote:

> I don't have a problem with asking for sub-services.  For instance,  
> I know about urn:service:massage, but I might like to know that  
> urn:service:massage.swedish exists.  That's valuable.
>
> Of course, the advantage with what we have currently is that this  
> feature can be added later.  If it isn't necessary, then we can  
> leave it until we don't have more pressing problems to address.

Indeed - that's a separate query.

>
> Q: If I try to resolve urn:service:sos.fire and it doesn't exist,  
> can the LoST server unilaterally return the result for  
> urn:service:sos?

I suppose, as a hint, although I'm a bit worried about the complexity  
once you generalize this. Imagine that we have more than two levels  
of service descriptions (urn:service:sos.fire.cats_in_trees). Should  
the result include the whole tree above the (non-existing) service?

I think a better approach is to have the client do the "list  
subservices" query, and then query for those subservices. Less  
guesswork and special cases.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 17 May 2006 20:33:02 -0400

> sending a simple "location/no service" query.  If someone sent a  

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.

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

---

From: Andrew Newton <[email-masked]>
Date: Fri, 19 May 2006 12:23:55 -0400

I'm a little fuzzy as to what a phone is suppose to do with services it 
did not previously know about.  Just what is it to do, present the user 
with a cryptic URN when they are in the throes of making an emergency 
phone call?

So, is this optimization for the following reason:

   Phone has 3 sos services it knows about.  The LoST service knows 
about 10 sos services.  The phone wants to pre-populate its cache with 
the sip addresses of the 3 sos services it is configured to support. 
The other 7 will not be queried.

Just to be clear, we aren't talking about the phone trying to understand 
services its software has never seen before, right?

-andy

Henning Schulzrinne wrote:
>> I don't have a problem with asking for sub-services.  For instance, I 
>> know about urn:service:massage, but I might like to know that 
>> feature can be added later.  If it isn't necessary, then we can leave 
>> it until we don't have more pressing problems to address.
> 
>> Q: If I try to resolve urn:service:sos.fire and it doesn't exist, can 
>> the LoST server unilaterally return the result for urn:service:sos?
> 
> once you generalize this. Imagine that we have more than two levels of 
> service descriptions (urn:service:sos.fire.cats_in_trees). Should the 
> result include the whole tree above the (non-existing) service?
> 
> subservices" query, and then query for those subservices. Less guesswork 
> and special cases.
> 
> Henning
> 
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 19 May 2006 12:41:24 -0400

While I can see some really smart phones trying to make sense out of the
list, in my mind the purpose here is to develop a COMPLETE list of dial
strings that need to be recognized and translated into service URNs.

Brian

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Friday, May 19, 2006 12:24 PM
To: Henning Schulzrinne
Cc: [email-masked]; Thomson, Martin
Subject: List services use case (was Re: [Ecrit] Re:
CommmentsI.D-ecrit-service-urn-03 Child helpline)

-andy

---

From: Andrew Newton <[email-masked]>
Date: Fri, 19 May 2006 12:46:20 -0400

> strings that need to be recognized and translated into service URNs.

Exactly what "smart" thing would they do?

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 19 May 2006 12:51:18 -0400

I would imagine that there would be, somewhere, some kind of a "pretty
print" description of what these services are.  The phone would access this
along with the list of service urns available at their location and offer an
interesting GUI for what it finds.

Brian

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Friday, May 19, 2006 12:46 PM
To: Brian Rosen
Cc: 'Henning Schulzrinne'; [email-masked]; 'Thomson, Martin'
Subject: Re: List services use case (was Re: [Ecrit] Re:

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 May 2006 12:59:07 -0400

I agree with Brian.

It seems quite common for GSM phones to show a text message indicating 
"welcome to Teluristan; you can get concierge services at *311 and can 
talk to our sales rep at *411." when roaming into a new country or 
service area. The problem with these messages is that they are not 
structured, so there is no easy way for them to be integrated into the 
phone's address book, for example. With the service listing proposed, 
this would be fairly straightforward. Given the generic URN service 
names, it would also make it easy to have symbols or visitor-language 
descriptions on the phone. Thus, tourists could always easily access the 
local version of the poison control center, for example, even if they 
have no clue that they'd dial 1-800-222-1222 in the US for that.

Henning

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 20 May 2006 08:07:22 +0200

First of all I always think a phone have some priming information in  
it. It is configured for "normal" use. For example how to use it  
where it normally is.

Given this information, the phone only need to know where it is, send  
a query to the "home listing service" and get temporary reprogramming  
of whatever features should work differently where the phone is now.

Personally I am quite irritated on the sms messages I get when I roam  
into a new providers network. Specifically when the foreign network  
change N times the first M hours where neither N or M is large.  
Including roaming into the same network a few times the first day.

Much better to allow "my home provider" to have this as a service, or  
create the ability for "google's" all over the world to sell listing  
services to the users.

"I am at the moment in Istanbul" is a pretty simple message I can  
even give to my phone manually (so that timezone is changed, 112/911,  
listing, best restaurant etc all are changed).

I already do this on my phone, to set the timezone, so why can this  
operation not automatically set other things as well?

    Patrik

On 19 maj 2006, at 18.59, Henning Schulzrinne wrote:

> I agree with Brian.
>
> It seems quite common for GSM phones to show a text message  
> indicating "welcome to Teluristan; you can get concierge services  
> at *311 and can talk to our sales rep at *411." when roaming into a  
> new country or service area. The problem with these messages is  
> that they are not structured, so there is no easy way for them to  
> be integrated into the phone's address book, for example. With the  
> service listing proposed, this would be fairly straightforward.  
> Given the generic URN service names, it would also make it easy to  
> have symbols or visitor-language descriptions on the phone. Thus,  
> tourists could always easily access the local version of the poison  
> control center, for example, even if they have no clue that they'd  
> dial 1-800-222-1222 in the US for that.
>
> Henning
>
> Brian Rosen wrote:
>> From: Andrew Newton [mailto:[email-masked]] Sent: Friday, May 19,  
>> 2006 12:46 PM
>> To: Brian Rosen

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 20 May 2006 09:07:23 -0400

Patrik,

I'm not quite sure if you're agreeing or disagreeing with the general  
gist of my statement. In any event, I think I'm agreeing with you  
that having a way to localize services based on my current location  
is a good thing and SMS (or other human-readable) messages are not  
really a good approximation of such automatic localization. They  
simply indicate that there's a need for such information and that  
service provider have an incentive to provide pointers to such  
localized services. I'd like to make them work better for both sides.

While this is outside the scope of ECRIT, LoST is general enough to  
manage pointers to other local services, such as the restaurant  
finder you mention. My current thinking is that this would be  
something like urn:service:info.*  (As described in the current  
service URN draft, each top-level service can have its own LoST  
server hierarchy, so the provider of LoST mapping for emergency  
services doesn't have to worry about informational services and vice  
versa.)

Henning

On May 20, 2006, at 2:07 AM, Patrik Fältström wrote:

> First of all I always think a phone have some priming information  
> in it. It is configured for "normal" use. For example how to use it  
> where it normally is.
>
> Given this information, the phone only need to know where it is,  
> send a query to the "home listing service" and get temporary  
> reprogramming of whatever features should work differently where  
> the phone is now.
>
> Personally I am quite irritated on the sms messages I get when I  
> roam into a new providers network. Specifically when the foreign  
> network change N times the first M hours where neither N or M is  
> large. Including roaming into the same network a few times the  
> first day.
>
> Much better to allow "my home provider" to have this as a service,  
> or create the ability for "google's" all over the world to sell  
> listing services to the users.
>
> even give to my phone manually (so that timezone is changed,  
> 112/911, listing, best restaurant etc all are changed).
>
>> at *311 and can talk to our sales rep at *411." when roaming into  
>> a new country or service area. The problem with these messages is  
>> tourists could always easily access the local version of the  
>> poison control center, for example, even if they have no clue that  
>> they'd dial 1-800-222-1222 in the US for that.
>>
>> Henning
>>
>> Brian Rosen wrote:

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 20 May 2006 15:28:20 +0200

On 20 maj 2006, at 15.07, Henning Schulzrinne wrote:

> Patrik,
>
> I'm not quite sure if you're agreeing or disagreeing with the  
> general gist of my statement.

Neither. I just try to point out that some event can be triggered  
manually, and the rest can follow automatically. We don't have to be  
able to do everything automatically.

And, at the same time we have to (like you seems to have already)  
understand and accept there will be competition between the location  
services just like we have competition between Yahoo and Google.

Last thing is that I personally think it is better if the end user  
can choose what service they use (subscribe to) and always use it  
than having one tied to the local network they roam to.

This also fits with for example the view the Swedish IT Minister  
Ulrica Messing has. One should be able to reach the services one want  
to use whenever, from wherever and with whatever device.

I do though understand different views exist on this last bullet. The  
technology probably have to support both.

    Patrik

> In any event, I think I'm agreeing with you that having a way to  
> localize services based on my current location is a good thing and  
> SMS (or other human-readable) messages are not really a good  
> approximation of such automatic localization. They simply indicate  
> that there's a need for such information and that service provider  
> have an incentive to provide pointers to such localized services.  
> I'd like to make them work better for both sides.
>
> services doesn't have to worry about informational services and  
> vice versa.)
>
> Henning
>
>> in it. It is configured for "normal" use. For example how to use  
>> it where it normally is.
>>
>> I already do this on my phone, to set the timezone, so why can  
>> this operation not automatically set other things as well?
>>
>>    Patrik
>>
>>> be integrated into the phone's address book, for example. With  
>>> the service listing proposed, this would be fairly  
>>> straightforward. Given the generic URN service names, it would  
>>> also make it easy to have symbols or visitor-language  
>>> descriptions on the phone. Thus, tourists could always easily  
>>> access the local version of the poison control center, for  
>>> example, even if they have no clue that they'd dial  
>>> 1-800-222-1222 in the US for that.
>>>
>>> Henning
>>>
>>> Brian Rosen wrote: