Subject: New URN scheme proposal: urn:service

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 20 Nov 2005 13:23:41 -0500

draft-schulzrinne-sipping-service-01 (also in HTML at 
http://www.cs.columbia.edu/sip/draft/service/draft-schulzrinne-sipping-service-01.html) 
is summarized as:

"The content of many communication services depend on the context, such 
as the user's location. We describe a 'service' URN that allows to 
register such context-dependent services that can be resolved in a 
distributed manner."

In a nutshell, a SIP user agent or other communications device (such as 
an XMPP client) would issue a request for "well-known" services such as 
like urn:service:sos or urn:service:repair and then have the request be 
routed (by a SIP proxy, say) to an appropriate destination, based on the 
user's context, such as his or her current service provider, geographic 
location or time-of-day. The assumption is that a relatively small 
number of widely-used services names would be registered with IANA. This 
is not a replacement for personal names, for example.

Similar features exist today on many traditional phone systems, either 
through 'hot buttons' or well-known phone N11 numbers such as 311 (gov't 
services), 911 (emergency services), 411 (directory assistance) or 611 
(repair). The latter are, unfortunately, only defined within particular 
geographic regions and thus not useful for devices that are likely to be 
mobile.

The draft has been discussed in the IETF ECRIT and SIPPING working 
groups. The problem is part of the charter of the ECRIT (emergency 
calling) working group. Both working groups expressed interest in this 
concept, but advised me to get feedback first from the URN NID mailing list.

Feedback is appreciated.

Henning

---

From: Leslie Daigle <[email-masked]>
Date: Tue, 10 Jan 2006 12:55:23 -0500

As noted by the list moderator, a number of messages
were held up in the moderation queue until January 6, 2006 --
so we did not see your message until then.

An editorial comment:  this document needs to include a
"Community Considerations" section, as well as a "Namespace
Considerations" section -- see RFC3406.

WRT the identifier uniqueness issue -- I believe you need to
make it clearer how this proposed namespace is conceptually
aligned with the uniqueness requirements of URNs; otherwise,
you're looking for a persistent identifier, not a name, it seems.

Best regards,
Leslie.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 13 Jan 2006 11:02:40 -0500

Leslie,

Thanks for your comments. I'll add the missing sections in the next 
version. A question inline below:

> you're looking for a persistent identifier, not a name, it seems.

I'm not quite sure I understand the comment. The uniqueness is given in 
that each resource identified by such a URN is a unique, well-defined 
service. Just like other URNs, it might resolve to zero or more URLs, 
depending on external circumstances. It is not meant as a persistent 
identifier for a specific person or group (such as a SIP URL might be).

Unlike URNs that I'm familiar with, I don't anticipate that a service 
URN would resolve to a document-like resource, but rather to a resource 
accessible by interactive communications, e.g., a mailto:, im:, sip: or 
h323: URL.

Henning

---

From: Leslie Daigle <[email-masked]>
Date: Tue, 17 Jan 2006 16:50:51 -0500

Howdy,

To quote the text (in -01):

> Identifier uniqueness considerations:
> 'service' URNs identify one logical service, recognized by human users
> as such. The service does not have to be provided by the same
> organization or to the same standards over time and space. Unlike for
> other URNs, the content of the service is by nature dynamic. While
> undesirable in many cases, two users making the same request for a
> service from the same place may not necessarily be directed to the same
> resource.

The canonical example is a URN for "Today's weather in Washington".
The URN would be expected to resolve to different things on different
days, and conceptually it would uniquely identify one thing.

Your text above says a lot about things that will *differ* between
resolutions, without being clear about what will remain the same
(even conceptually).

It's the latter that I believe needs clarification.

Thanks,
Leslie.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Jan 2006 17:18:26 -0500

I'm trying to think how to make this more precise, but can't get much 
beyond "offers the same basic service characteristics". I'm thinking of 
this as the equivalent of a yellow page heading or entry in the 
alphabetical listing of services in a hotel (without suggesting that 
service URNs are appropriate for either). The characteristic is that the 
user does not care (or does not get to make a choice), in detail, who 
delivers the service and that all service delivery mechanisms are 
considered to provide a functionally equivalent service, although 
obviously the quality of service can differ.

Suggestions on wording would be most welcome.

Benja Fallenstein wrote:
> Hi Leslie,
> 
> (I'm sorry, I previously sent this to you only instead of the mailing
> list. My bad.)
> 
> On 1/17/06, Leslie Daigle <[email-masked]> wrote:
> (Just to be clear, I'm not the 'you' addressed here.)
> 
> The beginning of the text you quoted seemed pretty clear to me:
> 
>>> as such.
> This made immediate sense to me; it's not uncommon for people to talk
> about "9-1-1" or equivalent, for example, as one entity -- "in this
> situation, call 9-1-1" -- even though the call center that the call
> gets routed to will depend on the caller's location. To the 'user,'
> this appears irrelevant to the identity of the service (9-1-1 is
> 9-1-1, you don't talk about "calling your local 9-1-1").
> 
> I understand that you want it to be expanded on, but it wasn't clear
> to me what issues, specifically, you would like the author of the ID
> to address (if any).
> 
> All the best,
> - Benja

---

From: Benja Fallenstein <[email-masked]>
Date: Wed, 18 Jan 2006 00:04:40 +0200

Hi Leslie,

All the best,
- Benja

---

From: Leslie Daigle <[email-masked]>
Date: Fri, 27 Jan 2006 18:29:00 -0500

Okay, a week and several re-reads later, let me try
again :-)

Benja Fallenstein wrote:
 >> This made immediate sense to me;

So, the problem is, it is almost useless in a specification.
"What's a service?  Don't know, but I'll recognize it when I see it."
I'm thinking that I got (and I suspect others might) distracted
by the additional context that is not critical to the definition.

Maybe:

OLD:

NEW:
Identifier uniqueness considerations:
'service' URNs identify one service instance for the particular service 
at the time of resolution. The service must conform to any requirements 
set out by the service registration (see IANA Considerations), but it 
does not have to be provided by the same organization or to the same 
standards over time and space.

And stop there.  Generalizations about other URNs are distracting.

Two other (small!) nits:

> Declaration of syntactic structure:
> The URN consists of a hierarchical service identifier, with a sequence
> of labels separated by periods. The left-most label is the most
> significant one and is called 'top-level service', while names to the
> right are called 'sub-services'. The set of allowable characters is the
> same as that used for domain names. Any string of service labels can be

I think you need to give a clear reference for "same as that used for
domain names" -- for ease of the reader, and because you probably mean
"host name" conventions, not "domain names" (which, actually, can take
8 bit data, but let's not discuss that).

> used to request services that are either more generic or more specific.
> In other words, if a service 'x.y.z' exists, the URNs 'x' and 'x.y' are
> also valid service URNs. [?]

Is that [?] a missing reference or flagging that there are unresolved
issues in the sentence?

Leslie.

---

From: Benja Fallenstein <[email-masked]>
Date: Sat, 28 Jan 2006 01:55:35 +0200

Hi Leslie, Henning,

> "What's a service?  Don't know, but I'll recognize it when I see it."

Right.

> Maybe:
[...]
> standards over time and space.

Actually, if the specification says that they define an *instance* of
the service, and this instance depends on the context when the URN is
resolved, then it says that what the URN identifies depends on the
context!

This is a practical consideration for some uses. In RDF (Resource
Description Framework), URIs are used to identify things that
statements are made about; many RDF users, including me, want to be
able to go to the specifications of a URI scheme (and in the case of
URNs, to the namespace registration) and see what exactly a particular
URI identifies. So, even if the expected use of service URNs is to
contact a service, the specification should make clear what the URN
identifies, too: in this case, the service.

So how about,

Identifier uniqueness considerations:
A service URN identifies a logical service, specified in the service
registration (see IANA considerations). Resolution of the URN, if
successful, will return a particular provider of the service, and this
provider may be different even for two users making the same request
in the same place at the same time; the logical service identified by
the URN, however, is persistent and unique.

- Benja

---

From: Leslie Daigle <[email-masked]>
Date: Fri, 27 Jan 2006 19:00:49 -0500

Howdy,

> the URN, however, is persistent and unique.

OK, if that's in close enough alignment with what Henning et al
believe they meant, I believe this makes sense to me.  This is clearly
consistent with all URNs; it's the whole point of separating
name & location!

(Not entirely sure about "return a particular provider"; seems
a little clumsy but I don't have better to suggest).

Leslie.

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Jan 2006 23:54:41 -0500

> a little clumsy but I don't have better to suggest).

"particular instance".  please don't bring the notion of competing 
providers into this - it's certain to be misconstrued.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 28 Jan 2006 14:31:17 -0500

> 8 bit data, but let's not discuss that).

Is it acceptable in the days of I18N to limit this to RFC 1034 set  
([A-Z0-9-])? That would be my preference as these are more akin to  
protocol constants than user-visible identifiers.

> Is that [?] a missing reference or flagging that there are unresolved

The latter. I wasn't quite sure if I wanted to make this assertion,  
but have since convinced myself that this is probably needed, so the  
[?] will disappear.

Thanks for the close reading!

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 28 Jan 2006 14:33:07 -0500

Thanks for the wording suggestion, which I'll incorporate.

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Sat, 28 Jan 2006 16:06:16 -0500

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Saturday, January 28, 2006 2:31 PM
> To: Leslie Daigle
> Cc: [email-masked]
> Subject: Re: New URN scheme proposal: urn:service
> 
> >
> 
> Picking up the nits:
> 
> > Two other (small!) nits:
> >
> >> The URN consists of a hierarchical service identifier, with a 
> >> sequence of labels separated by periods. The left-most 
> label is the 
> >> most significant one and is called 'top-level service', 
> while names 
> >> to the right are called 'sub-services'. The set of allowable 
> >> characters is the same as that used for domain names. Any 
> string of 
> >> service labels can be
> >
> Is it acceptable in the days of I18N to limit this to RFC 
> 1034 set ([A-Z0-9-])? That would be my preference as these 
> are more akin to protocol constants than user-visible identifiers.

Be carteful about citing RFC 1034 as a reference for domain label syntax.
The ABNF in that document doesn't allow labels to begin with a digit.

-Scott-

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 Jan 2006 21:59:30 -0500

Thanks again for the comments. I have tried to incorporate all of  
these into

http://www.cs.columbia.edu/sip/draft/service/draft-schulzrinne- 
sipping-service-02.html

I'll submit this draft sometime during the week, but please let me  
know if I missed anything.

Henning

---

From: Martin Duerst <[email-masked]>
Date: Mon, 30 Jan 2006 18:46:47 +0900

>protocol constants than user-visible identifiers.

I think that a better solution would be to syntactically allow
a wider range of characters (via UTF-8 and %-encoding), but to
clearly say that because of the nature of the identifier, you don't
expect that to be used too much.

There is always the chance that non-ASCII characters come in very
handy for education, local governement needs, and so on.

Regards,    Martin.