Subject: [salud] Expert opinions on the Salud URN namespace

From: Dale R Worley <[email-masked]>
Date: Tue, 2 Oct 2012 11:10:09 -0400 (EDT)

[as an individual]

This is a summary of feedback I received from experts regarding the
Salud URN scheme at IETF-84.

People I talked to regarding Salud URNs at IETF-84:

Andrew Newton, urnbis co-chair (Alfred Hoenes is the other co-chair)
Barry Leiba, applications area AD, who supervises the urnbis WG
Mark Nottingham, liaison between IETF and W3C regarding URI issues
John Klensin, who has been around the IETF for years

The first point that was made clear to me is that Alfred Hoenes'
criticisms are quite mainstream; there is a strong principle that URNs
should have meanings that are fixed over the long term, and that this
will be enforced by the IESG.

One suggestion that was raised by the experts is that we might recast
the URNs as a new scheme of URIs, changing them from "resource names"
to "resource identifiers".  The requirements on "identifiers" are far
less strict, although creating a new schema of them is considered a
larger action.

Unfortunately, other experts pointed out that a new URI scheme is
unlikely to be approved either.  The main reason is that our URNs do
not identify a specific object in the sense that people desire for
"resources".  In particular, there is a sense that a URI identifies a
"resource" only if there are multiple actions that can be done to that
resource, but the only thing that can be done with Salud URNs is to
render them as an alerting signal.  Salud URNs can not be used by a
process to obtain further information via any sort of resolution
process (unlike, say, HTTP and SIP URIs).

All of this suggests that the current design approach of encoding all
of the alerting information into a URN namespace will not be approved
by the IESG.

I can list a number of alternatives that have been suggested.  (In
most cases, I can't remember who suggested which alternative, so I
can't give people proper credit.)

* Alfred H. suggested the possibility of qualifying private names with
   a date/time, to provide a unique mapping from the private name to
   the
   responsible organization.  (I fear that this might not pass IESG
   vetting, though, because there still is no registration or
   resolution
   process for private names.)

* Move the alerting specification into an entirely new header whose
   value is a string, rather than a series of URNs.

* Move the alerting specifications into one or more header parameters
   of the Alert-Info header, whose values are strings.

* Leave the standardized alerting URNs as they are, but move the
   private name subcomponents into a header parameter on the URN.  And
   change any URNs for "private subtrees" into a fixed URN with a
   header parameter carrying the private components.

The last three approaches would make it possible to move all the
standardized URNs into the urn:ietf:params subtree, although I am not
sure whether we would want to do so.

There are certainly additional approaches worth looking at.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Oct 2012 11:44:04 -0400

> process (unlike, say, HTTP and SIP URIs).

I am confused by this.

The examples you list of things that can be resolved are not URNs.

URI - identifier
URL - locator
URN - name

Contrast with the service URN. What can you do with that?
It names a service. You can give it to somebody that knows where to find 
such a service.

Contrast to ISBN URN. It names a book. Not a particular instance of a 
book, just a class of books that are all in terms of content and form. 
What can you do with it? Use it as a key to look up stuff about the book.

So what can you do with an alert urn? You can identify an alert you 
would like to have rendered by someone you are calling. You can identify 
an alert you would like to have rendered by someone who is calling you. 
You can identify an alert as part of specifying a policy for handling 
calls. You can use it as a key to look up (in IANA) the description of 
the semantics of the alert.

So I don't understand why this cannot be a URN.

	Thanks,
	Paul

---

From: Laura Liess <[email-masked]>
Date: Wed, 3 Oct 2012 08:19:54 +0200

Dale,

Thank you for doing this work.

An additional proposal:

My understanding is that their main concern is not so much the new URN
NID itself ( Alfred's high level concern) but the <private-name> part,
which seems now also to me to be in contradiction with the  URN
Definition in RFC 2141:  "Uniform Resource Names (URNs) are intended
to serve as persistent, location-independent, resource identifiers..."
I came across http://tools.ietf.org/html/rfc4198  "A Uniform Resource
Name (URN) Namespace for Federated Content".  My proposal is to
to spliting the draft in:
    - a standard-track draft which defines standard Alert-Info URNs:
going ahead with the original draft but without
private names, if the urnbis people agree to it and
     - a second draft, maybe informational,which defines "federated
Alert-Info URNs" based on RFC 4198, of the
form urn:fdc:example.com:2002:alert:private-alert-identifier
where <private-alert-identifier> has the same ABNF-syntax as
<alert-identifier> in the first draft but the namespace is managed by
an organization.

We already have an algorithm on how to handle combinations of URNs, so
we can combine standard and private Alert-Info URNs.

Examples:
- Instead of Alert-Info: urn:alert:service:com.example.2012:foo:bar (or
Alert-Info:urn:alert:service:[email-masked]:bar as discussed on
the ML yesterday)   we could have
       Alert-Info:urn:fdc:example.com.2012:alert:service:foo:bar

- Instead of Alert-Info:urn:alert:service:recall:transfer:com.example.2012:foo
we could have
      Alert-Info:urn:alert:service:recall:transfer,
             urn:fdc:example.com.2012:alert:service:recall:transfer:foo

The examples are quick shots, maybe wrong, but mayybe we can use RFC
4198 or at least their model.

Thanks a lot
Laura

2012/10/2 Dale R Worley <[email-masked]>:
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud

---

From: Laura Liess <[email-masked]>
Date: Wed, 3 Oct 2012 09:18:06 +0200

Dale,

My main concern with some of the approaches, e.g. swiching to URIs or
moving all the
standardized URNs into the urn:ietf:params subtree is the backward
compatibility issue.
At least urn:alert:service:call-waiting has been added to the 3GPP IMS
specification
some years ago and is now up and running in many systems, mainly customer
end devices. Software in customers end devices is difficult or
impossible  to change, because
people block software updates for their end devices.

Otherwise any approach which is compatibile with
urn:alert:service:call-waiting
works for me.

Thank you
Laura

---

From: Dale R Worley <[email-masked]>
Date: Wed, 3 Oct 2012 11:36:20 -0400 (EDT)

> From: Paul Kyzivat <[email-masked]>
> 

Well, the argument isn't that clear to me, either.  Certainly the
urn:ietf:params subtree of URNs do not denote *things* and there is no
sort of resolution that can be done with them.  But the general
implication from what I heard is that creating a new URI scheme for
alerts is unlikely to be approved -- this complaint that a "resource"
is not identified came up only in the context of a new URI scheme.

Dale

---

From: Dale R Worley <[email-masked]>
Date: Wed, 3 Oct 2012 12:15:39 -0400 (EDT)

> From: Laura Liess <[email-masked]>
> 
> My main concern with some of the approaches [...]
> is the backward compatibility issue.  At least
> urn:alert:service:call-waiting has been added to the 3GPP IMS
> specification some years ago and is now up and running in many
> systems, mainly customer end devices. [...]

And urn:alert:service:normal appears in
draft-ietf-bliss-shared-appearances.

I would prefer that we can keep something very close to the current
design.  But it seems to me that moving the "private name" information
out of the URNs would be backward compatible.

Dale

---

From: Laura Liess <[email-masked]>
Date: Thu, 4 Oct 2012 14:15:00 +0200

> draft-ietf-bliss-shared-appearances.

This is correct. I just lost sight of it.
> out of the URNs would be backward compatible.

I am not aware about any implementation or even specification based on
the "private name" mechanism.

Laura