Subject: [Ecrit] List Hum on service URN

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 7 Nov 2005 18:35:52 -0500

In the meeting today, Henning presented his draft on sos@ URI and the
service: URN.  There were some people who did not understand why we may
need to implement both for a while, as Henning suggests.

Could I ask if there is anyone who does not agree that the service URN
is a good permanent solution, requiring a number of elements to change
in order to completely deploy?  If we have agreement that the service
URN is the long term target, we can start work on that at least.  There
was a suggestion, for example, to more widely circulate the proposal
outside of ecrit to gather comments.

Brian

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Nov 2005 14:08:23 -0500

Well, you asked if anyone DOESNT agree that the service URN is the right 
direction speak up. I think it is the right direction, but I'll speak up 
anyway ;)

Architecturally speaking, I think the service URN is really the right 
thing here because the very problem we are trying to solve is how to 
identify a particular resource by its name, in a way quite distinct from 
its actual location. In that way, the various mapping protocols can be 
viewed as a name to address mapping service. Using the sos URI is 
actually an attempt to represent a name with an address by stealing a 
value out of the namespace for every single domain in existence, and 
declaring any address with that user part to actually represent a name. 
This introduces the practical problem Henning has pointed out, about 
entities outside of that domain needing to recognize the name anyway.

The main drawback that has been raised on the URN is that it requires 
endpoint and proxy changes in order to be deployable. I'd argue that, 
for these environments, we already have a transition mechanism which are 
the localized emergency URI (i.e., sip:[email-masked]). It doesn't 
make sense to me to insert an intermediate solution rather than going 
right to the destination. Thus, I would propose we abandon the sos URI 
draft entirely.

So, the logic would be that an endpoint would try to call the service 
URN, and if that fails, it would use a emergency URI of the form above.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 08 Nov 2005 18:01:09 -0500

On the transition issue, I agree that this is probably hard to get right 
  for the cases that matter and it may not matter enough to try. There 
are probably three cases of interest:

- corporate SIP hard phones: the sip:[email-masked];user=phone is 
likely to work well enough. The difficulty is then how the proxy would 
act on such requests; ideally, it would replace the To/Request-URI with 
urn:service:sos so that downstream entities can recognize the nature of 
the call independent of the location of the caller. Request-URI is 
obviously easy, but for the 'To' header, this goes back to the 
discussion taking place in today's SIP meeting. Refering a user to the 
urn:service wouldn't work.

The problem is that there are lots of emergency identifiers and they 
should not leave the local environment. For example, both 9-911 and 911 
(and local emergency numbers) work.

- service-provider soft phones: presumably can be upgraded easily;

- service-provider hard phones/ATAs: may be harder, but roughly similar 
to the first problem.

I don't think there are enough cases of interest where the outbound 
proxy is operated by a party other than the service provider or 
enterprise to spend much effort on this.

Thus, if we can solve the re-labeling problem, I'm happy to focus on the 
service URN.

Henning

---

From: Ted Hardie <[email-masked]>
Date: Tue, 8 Nov 2005 15:42:31 -0800

By the way, there is already a service URI scheme, which is associated
with RFC2165 (according to http://www.iana.org/assignments/uri-schemes).
While it is up to the urn-nid list to decide whether having a urn:service
NID and a service scheme is too confusing, we may wish to avoid the
heartburn by picking a different NID.
			regards,
				Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 08 Nov 2005 18:52:28 -0500

2165 seems to be rather rarely used these days, so I'm not convinced 
that we need to steer clear of this.