Subject: Re: [urn] URNs for media types and other protocol constants relevant to interoperability

From: Martin J. Dürst <[email-masked]>
Date: Fri, 5 Feb 2016 19:46:15 +0900

Hello Carsten,

I think the issue below has come up repeatedly in different groups, but 
probably never got enough traction. Unfortunately, I can't remember any 
details, but you should probably find something if you dig deeper, 
either for using URNs or for using URLs.

Sorry for not being of more help.

Regards,   Martin.

On 2016/01/27 23:10, Carsten Bormann wrote:
> In W3C WoT IG, we are looking at employing RDF to represent information
> that is today often held in Web links (RFC 6690, RFC 5988).
> That includes media types, but also maybe link relation types and other
> registry content.
> It would be great to have a canonical mapping to URIs for all these.
> Has there been any attempt in the past to define, say, URNs for media types?
> Any other advice on how to obtain stable URIs for protocol constants?
> (I don't think we want to use the URL to the IANA registry page.)
>
> Grüße, Carsten
>
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn
>

---

From: Ted Hardie <[email-masked]>
Date: Fri, 5 Feb 2016 09:54:06 -0800

I've added Graham Klyne, because he worked on RDF representations of IETF
media types during the content negotiation work many years ago.

Theory states that you could register these are protocol parameters under
the registry set up in RFC 3553 (
http://www.iana.org/assignments/params/params.xhtml#params-1), but I think
you would find that you'd basically have to create the mappings rather than
rely on a set already in place.

regards,

Ted Hardie

On Fri, Feb 5, 2016 at 2:46 AM, Martin J. Dürst <[email-masked]>
wrote:

> details, but you should probably find something if you dig deeper, either
> for using URNs or for using URLs.
>

---

From: Sean Leonard <[email-masked]>
Date: Fri, 19 Feb 2016 04:31:16 -0800

Yes, rely on mappings...

There is another issue, namely that media types define parameters, some 
of which may be required for interoperability. For example, "text/plain; 
charset=UTF-8" will be interpreted differently (in a way that matters a 
lot) than "text/plain" or "text/plain; charset=iso-8859-15".

It would be a straightforward mapping to say 
<urn:ietf:params:mt:text/plain>, but the parameters present a 
significant challenge. I would suggest defining the protocol slot to be 
"media type" in the first place, in which case you can tack on the 
parameters after the ; delimiter like normal. If you are trying to stuff 
a different, or validated, media type compared to the resource that the 
URI is pointing to, you can use ni: (RFC 6920) or data: (RFC 2397), or 
you can invent your own URI scheme.

Sean

On 2/5/2016 9:54 AM, Ted Hardie wrote:
> I've added Graham Klyne, because he worked on RDF representations of 
> IETF media types during the content negotiation work many years ago.
>
> Theory states that you could register these are protocol parameters 
> under the registry set up in RFC 3553 
> (http://www.iana.org/assignments/params/params.xhtml#params-1), but I 
> think you would find that you'd basically have to create the mappings 
> rather than rely on a set already in place.
>
> regards,
>
> Ted Hardie
>
> On Fri, Feb 5, 2016 at 2:46 AM, Martin J. Dürst 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hello Carsten,
>
>     I think the issue below has come up repeatedly in different
>     groups, but probably never got enough traction. Unfortunately, I
>     can't remember any details, but you should probably find something
>     if you dig deeper, either for using URNs or for using URLs.
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: John C Klensin <[email-masked]>
Date: Fri, 19 Feb 2016 09:56:30 -0500

Hi.

Partially because this WG is years overdue on its primary task,
when I read through the comments below, what I mostly hear is a
difficult and controversial task and area trying to suck us into
a huge rat hole, and to drag everything else we are doing (like
2141bis) into the hole with it.

So I'd like to see (and recommend) if this can simply be ruled
out of scope, at least until the three current documents are
complete and finished with IETF Last Call.

In addition to the comments that have been made already, it may
be useful to remember the following:

(i) Even though this thread started in a W3C discussion, there
remain a number of leaders in the W3C community who are
unalterably opposed to URNs and the URN concept.  It appears to
me that opposition has become sufficiently much of a religious
issue that, even if we were to define a model for handling media
types as URNs, they would be unlikely to willingly adopt them,
perhaps pushing instead for a media-type-specific URI scheme.

(ii) We've been pushed several times by people in IETF circles
to define the limits of URNs (possibly even at what 2141
permits) and encourage the development of other URI schemes,
even if they are name-like rather than locator-like, for
situations that don't fit.

I think those two comments are consistent with Sean's remarks
but, for me right now, I just hope we can keep this discussion
out of the critical path of this WG.

People who have read so far are reminded that 2141bis-15 was
posted about two weeks ago and we have not seen a single
substantive comment on the list since.  Does that imply that we
are ready for WG Last Call on it (or on a slightly revised
version to correct a few minor editorial errors)?

     john

--On Friday, February 19, 2016 04:31 -0800 Sean Leonard
<[email-masked]> wrote:

> Yes, rely on mappings...
> 
> There is another issue, namely that media types define
> parameters, some of which may be required for
> interoperability. For example, "text/plain; charset=UTF-8"
> will be interpreted differently (in a way that matters a lot)
> than "text/plain" or "text/plain; charset=iso-8859-15".
> 
> significant challenge. I would suggest defining the protocol
> slot to be "media type" in the first place, in which case you
> can tack on the parameters after the ; delimiter like normal.
> If you are trying to stuff a different, or validated, media
> type compared to the resource that the URI is pointing to, you
> can use ni: (RFC 6920) or data: (RFC 2397), or you can invent
> your own URI scheme.
> 
> Sean
> 
>> I've added Graham Klyne, because he worked on RDF
>> representations of  IETF media types during the content
>> negotiation work many years ago.
>> 
>> Theory states that you could register these are protocol
>> parameters  under the registry set up in RFC 3553 
>> (http://www.iana.org/assignments/params/params.xhtml#params-1
>> ), but I  think you would find that you'd basically have to
>> create the mappings  rather than rely on a set already in
>> place.
>> 
>> regards,
>> 
>> Ted Hardie
>> 
>>     I think the issue below has come up repeatedly in
>>     different groups, but probably never got enough traction.
>>     Unfortunately, I can't remember any details, but you
>>     should probably find something if you dig deeper, either
>>         that is today often held in Web links (RFC 6690, RFC
>>         5988). That includes media types, but also maybe link
>>         relation types and other
>>         registry content.

---

From: Barry Leiba <[email-masked]>
Date: Sun, 21 Feb 2016 09:05:52 -0800

The thing here is that URNs are meant to name things, not to provide
all the information necessary to fully dereference and render the
things that are named.  I'll note that http URIs don't generally have
the kind of information in them that you're talking about -- rather,
when a client asks for a resource, the server tells the client what
the media type and associated parameters are.

Further, I would say that the intent of URNs, as well as the actual
need in the field, is to having different URNs for different versions
of things.  For example, the RFC Editor will be making RFCs available
in plain text, HTML, XML, PDF, and possibly other formats (some form
of markdown and so forth).  Those are all meant to be substantively
the same, but they won't be exactly the same, and they'll have
different URNs -- not one URN with some sort of parameters.

I do think the scope of the work we're doing now is to revise the URN
specs to meet up with current usage and needs, and to apply things
we've learned since the originals were written.  I think it'd be a bad
idea, particularly considering how long this needed work has dragged
on, to add new features that we're not sure we'll actually need or
want when the rubber hits the road.

Barry

On Fri, Feb 19, 2016 at 4:31 AM, Sean Leonard <[email-masked]> wrote:
> Yes, rely on mappings...
>
> There is another issue, namely that media types define parameters, some of
> which may be required for interoperability. For example, "text/plain;
> charset=UTF-8" will be interpreted differently (in a way that matters a lot)
> <urn:ietf:params:mt:text/plain>, but the parameters present a significant
> challenge. I would suggest defining the protocol slot to be "media type" in
> the first place, in which case you can tack on the parameters after the ;
> delimiter like normal. If you are trying to stuff a different, or validated,
> media type compared to the resource that the URI is pointing to, you can use
> ni: (RFC 6920) or data: (RFC 2397), or you can invent your own URI scheme.
>
> Sean
>
>
> the registry set up in RFC 3553
> (http://www.iana.org/assignments/params/params.xhtml#params-1), but I think

---

From: John C Klensin <[email-masked]>
Date: Sun, 21 Feb 2016 12:36:33 -0500

--On Sunday, February 21, 2016 9:05 AM -0800 Barry Leiba
<[email-masked]> wrote:

> The thing here is that URNs are meant to name things, not to
> provide all the information necessary to fully dereference and
> render the things that are named.  I'll note that http URIs
> don't generally have the kind of information in them that
> you're talking about -- rather, when a client asks for a
> resource, the server tells the client what the media type and
> associated parameters are.
> 
> Further, I would say that the intent of URNs, as well as the
> actual need in the field, is to having different URNs for
> different versions of things.  For example, the RFC Editor
> will be making RFCs available in plain text, HTML, XML, PDF,
> and possibly other formats (some form of markdown and so
> forth).  Those are all meant to be substantively the same, but
> they won't be exactly the same, and they'll have different
> URNs -- not one URN with some sort of parameters.

Barry,

While I agree with everything else in your note, the above
example is less clear to me and less clear because the
"substantively the same" part.  So, just as I can imagine 
    http://www.rfc-editor.org/info/rfc2141?format=PDF
as a plausible alternate to 
    https://www.rfc-editor.org/rfc/pdfrfc/rfc2141.txt.pdf
in some brave new world, I can imagine
    urn:ietf:rfc:2141?=format=PDF
As a URN whose intent is to name RFC 2141 (everything up to the
"?") and to "resolve to" any of the locations at which the PDF
form of that RFC can be located.

I think this sort of thing has to be a per-namesspace decision,
lest it make us all crazy.  If that decision has been made and
document for the "IETF" NID, or even for the nid:"rfc"
sub-namespace (whatever those are), I don't think I've seen the
document.

> I do think the scope of the work we're doing now is to revise
> the URN specs to meet up with current usage and needs, and to
> apply things we've learned since the originals were written.
> I think it'd be a bad idea, particularly considering how long
> this needed work has dragged on, to add new features that
> we're not sure we'll actually need or want when the rubber
> hits the road.

+Many

    john

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 22 Feb 2016 14:33:09 +0900

> sub-namespace (whatever those are), I don't think I've seen the

I agree mostly with John here. Even more, there shouldn't be anything in 
the specs against just using
    urn:ietf:rfc:2141
because in many circumstances, I'd not worry too much about which 
version I'd get (I'd assume HTML if I'm in a browser,..., but that's a 
separate issue).

Regards,   Martin.

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 22 Feb 2016 14:43:01 +0900

Hello John, others,

> 2141bis) into the hole with it.

I think you're hearing wrong. What I heard was a request for information 
from somebody who figured out that if anybody, then somebody on this 
very list might know.

That was responded to by comments of the nature of "I think you might 
find something if you dig deeper", "here's a person you might want to 
contact", and "here's an aspect of your question you might want to make 
sure you cover". At no point in time was there any suggestion of a 
direct connection to our current work items.

> complete and finished with IETF Last Call.

I agree it's out of scope for the three current documents. Nobody 
suggested otherwise. But even in cases where a WG is very focused on its 
current work, there is the chance that there is some inquiry on the WG 
list about related work that is best made on that WG list.

> perhaps pushing instead for a media-type-specific URI scheme.

I have definitely known people at W3C who don't recommend URNs, but none 
of the suggested a new URI scheme instead.

> situations that don't fit.

I'm not sure you are suggesting to use URNs for media types or not, but 
at least assuming the former, a "has anybody ever attempted to do 
something like this with URNs" would definitely fit on this list.

> out of the critical path of this WG.

I very much agree here.

Regards,    Martin.

---

From: John C Klensin <[email-masked]>
Date: Mon, 22 Feb 2016 03:32:58 -0500

--On Monday, February 22, 2016 14:43 +0900 "Martin J. Dürst"
<[email-masked]> wrote:

>> unalterably opposed to URNs and the URN concept.  It appears
>> to me that opposition has become sufficiently much of a
>> religious issue that, even if we were to define a model for
>> handling media types as URNs, they would be unlikely to
>> willingly adopt them, perhaps pushing instead for a
>> media-type-specific URI scheme.
> 
> I have definitely known people at W3C who don't recommend
> URNs, but none of the suggested a new URI scheme instead.

Sorry, wrote too quickly and was insufficiently clear:

The WG has had three sets of loud opponents with regard to the
fundamentals of its work, i.e., to updating 2141 and associated
documents to add additional syntax and capabilities:

(1) THose who are concerned about destabilizing (e.g., reducing
the permanence of) 2141-style URNs and who therefore recommend
freezing it and creating a new name-type (as distinct from
location-type) URI and attaching the new syntax and capabilities
to it.  A subset of that group has proposed not defining the new
scheme as a URI at all, thereby escaping the syntax and
semantics of RFC 3986 entirely (along with arguments about them).

(2) Those who believe that there is no such thing as a real set
of things called URNs with properties of persistence that anyone
can really define operationally and that therefore they are just
confusing syntax added to what should be scheme-per-namespace
URIs.  They believe that all instances of urn:foo:some-NSS
should be replaced by foo:something-related-to-NSS, with direct
3986-style queries and fragments.

(3) THose who believe that URNs are conceptually wrong and
should be replaced by either http[s] URLs or some sort of
Semantic Web objects.  I include in this group those who think
the "resolver" discussion, e.g., what we now see as 
    urn:Example-NID:example-nss?+resolverID some-string?=foo=bar
should be turned into:
    http://resolver-ID/some-string?foo=bar

A subset of the third group have clear W3C affiliations, to the
point that some of them are generally assumed (including by
themselves) to be speaking for W3C.  A (smaller) subset of the
second group are periodically assumed to be speaking for the web
community and some of them seem to encourage that perception.

I don't think naming names would have any value but am willing
to do so offlist if you think I'm making this up.

> I'm not sure you are suggesting to use URNs for media types or
> not, but at least assuming the former, a "has anybody ever
> attempted to do something like this with URNs" would
> definitely fit on this list.

No I wasn't thinking of media types.  I was thinking more about
some of the discussions I tried to summarize in (1) above.  But
I agree with your comment as well.  It is another topic I hope
we can keep out of the critical path, but I believe that, if we
were doing a document similar to RFC 1737 today, some of its
statements, criteria, and requirements would be quite different
with the addition of requirements for what we now call
q-components and/or r-components as a small part of that.

>> out of the critical path of this WG.

Thanks.

    john