Subject: RE: List services use case (was Re: [Ecrit] Re:CommmentsI.D-ecrit-service-urn-03 Child helpline)

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 19 May 2006 13:05:34 -0400

If I were French would I miss the difference between poison and poisson?

There was a statement earlier that the urn's were protocol elements not
visible to the end-user.  
Is that true or not? 

Mike

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Friday, May 19, 2006 12:59 PM
> To: Brian Rosen
> Cc: [email-masked]; 'Thomson, Martin'
> Subject: Re: List services use case (was Re: [Ecrit] 
> Re:CommmentsI.D-ecrit-service-urn-03 Child helpline)
> 
> 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:
> > 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:
> > CommmentsI.D-ecrit-service-urn-03 Child helpline)
> > 
> > Brian Rosen wrote:
> >> 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.
> > 
> > Exactly what "smart" thing would they do?
> > 
> > -andy
> 
> _______________________________________________
> 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: Andrew Newton <[email-masked]>
Date: Fri, 19 May 2006 13:23:03 -0400

> There was a statement earlier that the urn's were protocol elements not

I agree with Mike on this.  URNs are protocol elements and should not be 
shown to the user.  And there can be no pretty form for localization if 
the phone as never encountered the URN before.

I'm also a little dubious of any use case that has end users scrolling 
through a list of emergency services before they make an emergency call.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 19 May 2006 13:26:39 -0400

Yes, that's why we don't really care about the "shape" of the tree.
The URNs are protocol elements; the "name" is not designed to be shown to a
user.  That's why I think there is a database somewhere which has
(localized) information on what these URNs mean.

The LoST mechanism merely gives you the list of services available at the
current location, which may be much smaller than the list of all possible
service URNs.

Brian

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Friday, May 19, 2006 1:06 PM
To: Henning Schulzrinne; Brian Rosen
Cc: [email-masked]; Thomson, Martin
Subject: RE: List services use case (was Re: [Ecrit]

Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 May 2006 13:29:02 -0400

> There was a statement earlier that the urn's were protocol elements not

Yes, that's certainly true. The idea is as follows:

The smart address book in your phone contains an entry for all the usual 
services, but not all of which will be available in the countries that 
you're visiting. Maybe the poison control service will have the 
requisite skull symbol on your phone or the appropriate label in your UI 
language of choice.

When you are in a new area, the mobile device queries for the (say) 
urn:service:sos services. It fills in the services that are supported 
locally, rather than individually querying for all the services that may 
or may not be. (Say, mountain rescue in Holland or marine rescue in 
Switzerland.)

The LoST response would include the dial string and, possibly, a service 
description, using, if possible, the language indicated in the LoST 
query or whatever languages the local service provider has chosen. Maybe 
in France the provider description would indicate "does not provide 
information on selecting fish in restaurants and does not deal with 
Piranhas."

In addition, there might be local services that your phone does not know 
about. In those cases, depending on the device preferences, these 
services might be added, with the best-possible locally-provided 
description.

 From a protocol perspective, this is all pretty trivial.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 19 May 2006 13:37:36 -0400

I assure you that "ViPr" (the video telephone I worked on a while ago),
could give you a VERY nice UI for this kind of thing, and it indeed would
likely first present a very short list of true emergency choices plus a
"more" choice.  It would be localized, and it would not depend on any prior
history.

Somehow I think you are missing the big picture I'm describing.
I'm thinking someone puts a database together with some kind of xml
structure that has things a short name and a brief description, with maybe
some flags or categorization, in a variety of languages, and makes it
available to a phone that can use that structure, plus the list, to render a
useful GUI.

Brian

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

-andy

---

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

I understand how software localization works.  But software cannot 
localize well known values it has no knowledge of (think 2 year old 
firmware and an ever increasing IANA registry).

Additionally, the "more choices" menu idea is fine while surfing the web 
casually, but it is a horrible idea for emergency calls.  How do we 
determine precedence order for which emergency service is on the first 
screen?  How do we avoid "Fire" being on screen 4?

-andy

ps. actually, the "more choices" on every cell phone I've ever used is 
infuriating... and I can only imagine the additional frustration while 
attempting to do so while my house is on fire.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 May 2006 14:01:02 -0400

You are positing, I believe, a false choice. Nobody is suggesting 
replacing dialing 911 or 112 with scrolling through a list of emergency 
services, as long as "dialing" is still the predominant user interface 
metaphor. (For Brian's Vipr, I suspect that it is not.)

I chose the poison control example for a reason - almost everyone will 
have to consult their phone book to find the number and there's 
essentially no hope for me to find that number when I'm visiting a 
foreign country.

---

From: Andrew Newton <[email-masked]>
Date: Fri, 19 May 2006 14:25:47 -0400

So this needs to be in the phone BCP.  And for UAs that do not use 
dialing as their predominant user interface, they should try to use some 
standard or well-known, easy to use mechanism that is equivalent to 
urn:service:sos.

Does that make sense?

-andy

Henning Schulzrinne wrote:
>> Additionally, the "more choices" menu idea is fine while surfing the 
>> web casually, but it is a horrible idea for emergency calls.  How do 
>> we determine precedence order for which emergency service is on the 
>> first screen?  How do we avoid "Fire" being on screen 4?
>>
>> -andy
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 May 2006 14:46:31 -0400

Indeed. In some cases, particularly where there is no easily accessible 
dial pad in the UI, this may involve a user-confirmed UI interaction (as 
opposed to just the mis-dial prone "big red emergency button").