Subject: [urn] IETF does protocol design, not philosophy

From: Larry Masinter <[email-masked]>
Date: Tue, 17 Jun 2014 14:07:54 +0000

We're protocol designers, not philosophers. We should be talking about the URI/URN/URL protocols.

In this protocol, two parties Alice (A)  and B (B), are communicating. Embedded in their communication

A ------- UR* --->  B

Alice, speaking with Bob, utters a URI/URL/URN. Bob, receiving this UR* from Alice, interprets it.
The UR* is an element of an overall communication protocol, and we are designing the UR*
protocol element so that it's useful in lots of contexts, whether they're HTML, HTTP, XMPP,
DNS or whatever.

We've had a design where URNs of the form urn:<authority>:<string>  fit into the overall
space of URI things of the form <scheme>:<scheme-stuff> by using "urn" as the scheme.

While it's true that if Alice tells Bob "urn:ietf:rfc:2517" in some context rather than
"http://tools.ietf.org/html/rfc2517" that Bob will not be able to process that URI
in the same way, and whether that's as useful to Bob depends on the protocol
context; if it's in a hyperlink in a HTML document, probably not, unless someone 
set up some system for turning the former into the latter and informed Bob about
that out of band (e.g., changing the registration of the urn:ietf URN namespace
to make that system authoritative).

In many contexts, the intention of a communication of a UR* is through several
layers of indirection.

UR*s are just strings composed by encoding parts and concatenating them
with punctuation. 

"urn:isbn:978-394-30185-7-8" at its shallowest means "whatever the authority
for the isbn URN namespace is 978-394-30185-7-8",  with the hope that the
isbn authority will tell Bob the same thing it told Alice when Alice looked
it up, while "http://nbn-resolving.de/urn:nbn:de:101:1-2013022715846"
at its shallowest could be "use HTTP to the host nbn-resolving.de with
path /urn:nbn:De:101:1-2013022715846".

Everything else -- whether Alice meant to tell Bob about a book or a person or
an edition of a book or the book's metadata and not the book itself -- is
not specified. If you need to be more specific in the protocol you're designing --
if you need more information than is present in a URI/URN/URL -- then 
you need to supply it some other way.  Links can have link types, other
metadata supplied in protocol parts, fields, attributes or whatever
other than the UR*. 

Sorry, you can't fix your protocol by packing more info into the UR*
than is already there. 

Larry
--
http://larry.masinter.net

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Jun 2014 18:15:28 -0400

Larry,

Perhaps your note illustrates another part of the disconnect we
are having in the URN space.  Some of the intended/desired uses
are precisely not in an [Internet] protocol context.  Even of
those that are, many do not follow your "A ------- UR* --->  B"
model because the URNs are used as indicators, not retrieval
indicators of some sort (most, but not all, uses with "HTML,
HTTP, XMPP, DNS or whatever" are for retrieval elements, but
some, including ones that Peter has identified for XMPP and
several recent I-Ds, are not).   In particular, Alice may want
to inquire whether a URN with a particular NID and NSS exists in
some data structure or transaction and then take an action on
that basis that is indicated by the URN but that has nothing to
do with communicating the URN to Bob or otherwise executing or
resolving it.

In retrospect, perhaps we would have been better off had we
avoided the generic URI idea entirely, preferring a wide variety
of URLs -- all intended for use in contexts that fit your model
-- and then invented a Universal Digital Indicator or Universal
Digital Flag that would have entirely different properties.  But
we didn't go in that direction and it looks to me, right now, as
if there is no practical way to get back there without even more
damage.

One of Martin's recent notes in another thread seems to me to be
another aspect of the same problem.  For URLs, the "HTTP GET"
and "HTTP HEAD" requests -- same object with different verbs --
is a useful distinction and no further distinctions are needed
among the URL that locates (or describes) the object.  From a
variation on that perspective, the URN issue is that, at a
slightly higher level of abstraction ("name" versus "location"),
there is a desire to be able to incorporate that distinction
into the identifying string itself, not somehow know that
anything that can be the target of a URL can be fully retrieved
with GET or have some specific metadata retrieved with HEAD.
>From my point of view, we haven't been completely consistent
about that distinction even with URLs: we say
    GET <url>
in HTTP to fetch the whole object
    HEAD <url>
to fetch a certain type of metadata, but, if we want only a
section or material after a starting point, we say 
    GET <url>
and then apply a fragment identifier to the result.  That
operation could have been defined differently, e.g., by saying 
   GET <uri>  frag=<fragmentID>
or, for improved backwards compatibility and error messages,
   GETPARTIAL <uri>  frag=<fragmentID>
to push the extraction job onto the server/ resolution mechanism.

As with URLs versus a hypothetical UDI or UDF, one can argue
endlessly about whether a model in which pure indicators (or
information that designates different types of action loci and
instructions for them are necessary).  I imagine we will never
agree about that.  

But that, and part of Dale's recent note (to while I'll respond
separately), ultimately comes down to the issue I was trying to
get at in my recent proposed text.  There is a significant
community who believe that the distinctions are relevant and
that additional syntax and flexibility are needed.  It is, IMO,
largely irrelevant whether they are, in some abstract
philosophical sense, or even from a protocol design sense based
on a particular perspective, "correct".  The main thing that is
relevant is that if we decline to accommodate their perceived
needs, they will either fork the standard or head off in a
different way entirely.  Our trying to say "no, you are wrong",
even if we had consensus on that  (and I don't believe we do)
would be extremely unlikely to change anyone's mind. 

IMO, given that entirely pragmatic situation, the right things
for us to do are:

(1) Stop this debate, suck it up as needed, try to elicit (real
or perceived) requirements, and design/modify the URN specs
accordingly.

(2) To the degree to which some people think this is the wrong
way to proceed (or that the communities who think they have
other requirements are wrong-headed), I would hope that they
would start on an I-D that would explain the One True Path as
clearly and lucidly as possible, with the intent of publishing
that discussion as an informational that reflects their view of
the present and future RFC.  Whether such a document should be a
WG product or an individual or independent submission is
probably less important than it be written... at least if this
debate about philosophy or perspective is actually important
rather than a delaying or obstructionist action.

best,
   john

--On Tuesday, June 17, 2014 14:07 +0000 Larry Masinter
<[email-masked]> wrote:

> In this protocol, two parties Alice (A)  and B (B), are
> communicating. Embedded in their communication
> 
> 
> A ------- UR* --->  B
> 
> Alice, speaking with Bob, utters a URI/URL/URN. Bob, receiving
> this UR* from Alice, interprets it. The UR* is an element of
> an overall communication protocol, and we are designing the UR*
> protocol element so that it's useful in lots of contexts,
> whether they're HTML, HTTP, XMPP, DNS or whatever.
> 
> We've had a design where URNs of the form
> urn:<authority>:<string>  fit into the overall space of URI
> things of the form <scheme>:<scheme-stuff> by using "urn" as
> the scheme.
> 
> While it's true that if Alice tells Bob "urn:ietf:rfc:2517" in
> some context rather than "http://tools.ietf.org/html/rfc2517"
> that Bob will not be able to process that URI in the same way,
> and whether that's as useful to Bob depends on the protocol
> context; if it's in a hyperlink in a HTML document, probably
> not, unless someone  set up some system for turning the former
> into the latter and informed Bob about that out of band (e.g.,
> changing the registration of the urn:ietf URN namespace to
> make that system authoritative).
> 
> In many contexts, the intention of a communication of a UR* is
> through several layers of indirection.
> 
> UR*s are just strings composed by encoding parts and
> concatenating them with punctuation. 
> 
> "urn:isbn:978-394-30185-7-8" at its shallowest means "whatever
> the authority for the isbn URN namespace is
> 978-394-30185-7-8",  with the hope that the isbn authority
> will tell Bob the same thing it told Alice when Alice looked
> it up, while
> "http://nbn-resolving.de/urn:nbn:de:101:1-2013022715846" at
> its shallowest could be "use HTTP to the host nbn-resolving.de
> with path /urn:nbn:De:101:1-2013022715846".
> 
> Everything else -- whether Alice meant to tell Bob about a
> book or a person or an edition of a book or the book's
> metadata and not the book itself -- is not specified. If you
> need to be more specific in the protocol you're designing --
> if you need more information than is present in a URI/URN/URL
> -- then  you need to supply it some other way.  Links can have
> link types, other metadata supplied in protocol parts, fields,
> attributes or whatever other than the UR*. 
> 
> Sorry, you can't fix your protocol by packing more info into
> the UR* than is already there. 
> 
> Larry
> --

---

From: Larry Masinter <[email-masked]>
Date: Thu, 19 Jun 2014 08:37:56 +0000

> are having in the URN space.  

I meant it too.

> Some of the intended/desired uses
> are precisely not in an [Internet] protocol context.  

I meant "protocol" in the broad sense. I can't think of
any use cases that do not involve protocols. UR*'s
are strings to be used in protocols, and any use
that doesn't involve a communication is out of scope:
for discussion of UR* uses, for this working group, for
the IETF. 

> Even of
HTTP, XMPP, DNS or whatever" are for retrieval elements, but
some, including ones that Peter has identified for XMPP and
several recent I-Ds, are not).   

I think the 'indicator' vs. 'for retrieval' distinction is not
about the UR* but about the context of use, not the UR*
itself.  This is a key point: you can use a 'http:' URI both
'as indicator' and 'for retrieval', and also you can use
a 'urn:' URI for both. However, as a matter of implementation,
Using 'urn:' URIs for retrieval doesn't work so well.
========================================
Let me try to explain in words what I meant by
A -- UR* --> B.

Alice and Bob are communicating. Somehow. All communication
involves a communication protocol. Protocols are simple or complex,
are layered and modularized. HTTP is a protocol, but English is
a protocol, "the web" is a protocol. Speaking broadly.

In the English email protocol which I am using now, English
words and punctuation and UR*s are used as protocol
elements.

As part of Alice communicating with Bob, Alice might include
a UR*, embedded in "English email" or HTML or XMPP or XML,
and you want to ask about the meaning of that UR*.
Does it indicate, is it intended for retrieval, does Alice want
Bob to try to retrieve whatever 'fetch'ing the UR* and understand
something because of whatever Bob gets?

My point is that the answer is the same whether the context
is English email or HTML or any other protocol: no one can
know for certain what Alice intended by the UR*, the
ambiguity is intrinsic, no amount of words in RFCs will
change that. If there is to be any disambiguation, it has
to be carried out of band or elsewhere in the protocol.
==========================

> In particular, Alice may want

I don't understand. How did Alice get the URN? And how
did the creator of the data structure or transaction
get the URN?  

I'd say that if there is no communication path that passes
the UR* as an opaque string, then you don't have a URI or
URL or URN, you just have a string that looks like one and
we have nothing to say because it doesn't matter what
we say.

> and then invented a Universal Digital Indicator or Universal
> Digital Flag that would have entirely different properties.

Disagree. To repeat: the nature of the context of use
(such as indicate vs. for retrieval) is orthogonal the
nature of the UR* scheme (http: or uuid:) or scheme type
(urn or UDI Or UDF).   

>  But

Mumble about 'back there' (were we ever there) and 'damage' 
(implies harm).

> is a useful distinction

If a protocol uses a method along with a URL that's fine,
but most schemes other than http:/https: don't have much 
To say about HEAD. 

>  and no further distinctions are needed
> among the URL that locates (or describes) the object. 

The IANA registry of link types is proof that many
feel more distinctions are needed. 

>  From a
> into the identifying string itself,

Desire is too weak a design rationale; you can't always
get what you want. Because the distinction applies to the 
context of use, incorporating the distinction in the
identifying string itself isn't possible.

>  not somehow know that

"somehow know" = by context.

> to push the extraction job onto the server/ resolution mechanism.

Fragment identifiers are much more complicated.
http://www.w3.org/2001/tag/doc/mimeTypesAndFragids
and ultimately have very little to do with fragments
as chunks or components (you're thinking range retrieval)
and are more like "highlight" or "view".

> instructions for them are necessary).  I imagine we will never

Barking up the wrong tree, endlessly.  

> But that, and part of Dale's recent note 

> or perceived) requirements, and design/modify the URN specs

Only according to real requirements, not unsubstantiated
ones, please.

> other requirements are wrong-headed), 

We should avoid examining heads. 

Real requirements can come from anywhere. 

 > I would hope that they
> the present and future RFC.

Sounds like make-work. If there are real requirements,
follow step (1).

> rather than a delaying or obstructionist action.

I'm trying to help here. 

RFC5988 establishes a link type registry.
http://www.iana.org/assignments/link-relations/link-relations.xhtml

which seems like a great vehicle for those designing
applications that need additional link categorizations.
Is there a use case where that won't do?