Subject: [Sipping] 'service' URN

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 12 Jul 2005 18:08:17 -0400

http://www.ietf.org/internet-drafts/draft-schulzrinne-sipping-service-00.txt 
(or prettier at 
http://www.cs.columbia.edu/sip/draft/service/draft-schulzrinne-sipping-service-00.html) 
is an initial attempt to solve an identification problem, namely how to 
identify services that have different instantiations depending on the 
location of the entity requesting the service. Emergency calling is the 
best-known instance of this problem or service, but there are many more, 
from "311" (general government services in large cities) to the AAA 
SuperNumber for towing services.

Comments as to the general approach are particularly appreciated.

Henning

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Andrew Newton <[email-masked]>
Date: Tue, 12 Jul 2005 19:06:35 -0400

> Comments as to the general approach are particularly appreciated.

Well, a few questions rather than comments.

Why a URN registry?  What does that offer that a list of well-known  
service identifiers does not?

What am I expecting to get if I plug in urn:service:sos.fire into my  
URN resolver?  Should it be a URLs pointing to a web page about the  
"sos.fire" identifier?  Or is it URLs to all the mapping services of  
the world that service "sos.fire"?

Is this approach meant to make countries with unique emergency  
identifiers register those identifiers in a global registry?  If not,  
then are you expecting "adhoc URNs" in the service NID?

I know you put TBD for the namespace registrant, but who did you have  
in mind that would run this NID?  Is it the ITU?  And what rules are  
they willing to use to insure that identifiers with duplicate meaning  
are not registered?  Such as a particularly stubborn government  
wishing to register their national languages equivalent to "police".

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 12 Jul 2005 22:04:26 -0400

> Well, a few questions rather than comments.

Thanks for taking the time to read the document. Let me try some answers.

> service identifiers does not?

Primarily, the ability to use these identifiers where URLs or URNs are 
required or useful, such as SIP request URIs, web pages or the responses 
from multi-stage mapping protocols, such as those we are discussing in 
this WG.

> the world that service "sos.fire"?

There are several possible models, depending on the number of such 
mapping protocols. There are several cases, depending on whether one can 
rely on the fact that all services for a particular URN are available in 
all mapping protocols (this might be a condition for registration) or 
not. If they are, a client can simply choose whatever protocol it 
supports. If not, things get messier. My preference would be a very 
small number of such protocols, just as most other URN schemes have 
somewhere close to one resolution mechanisms (well, zero in some cases).

I didn't want to specify this right now, as that gets into tangential 
arguments, which also depend on the resolution of the mapping protocol 
discussion within ECRIT.

> then are you expecting "adhoc URNs" in the service NID?

I'm not sure what you mean by "unique emergency identifiers". Are you 
talking about dial strings like 911 or, say, a new type of emergency, 
such as my Italian sos.fashion example?

For the latter, I would indeed expect them to register such services, in 
the same fashion that they would register such service identifiers in 
your mapping proposal.

> are not registered?  Such as a particularly stubborn government  wishing 
> to register their national languages equivalent to "police".

The rules would be similar to the rules that would need to be imposed 
for service identifiers that appear "naked" in the ECRIT mapping 
protocol. The usual set of IANA policies, from FCFS to standards 
document, may apply.

Thanks for your questions; they help to flesh out the proposal.