Subject: [urn] I-D Action: draft-ietf-urnbis-semantics-clarif-04.txt

From: [email-masked]
Date: Wed, 08 Jun 2016 07:03:03 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Uniform Resource Names, Revised of the IETF.

        Title           : URN Semantics Clarification
        Author          : John C Klensin
	Filename        : draft-ietf-urnbis-semantics-clarif-04.txt
	Pages           : 14
	Date            : 2016-06-08

Abstract:
   Experience has shown that identifiers associated with persistent
   names have properties and requirements that may be somewhat different
   from identifiers associated with the locations of objects.  This is
   especially true when such names are expected to be stable for a very
   long time or when they identify large and complex entities.  In order
   to allow Uniform Resource Names (URNs) to evolve to meet the needs of
   the Library, Museum, Publisher, and Information Science communities
   and other users, this specification separates URNs from the semantic
   constraints that many people believe are part of the specification
   for Uniform Resource Identifiers (URIs) in RFC 3986, updating that
   document accordingly.  The syntax of URNs is still constrained to
   that of RFC 3986, so generic URI parsers are unaffected by this
   change.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-urnbis-semantics-clarif/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-urnbis-semantics-clarif-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-semantics-clarif-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Sean Leonard <[email-masked]>
Date: Tue, 28 Jun 2016 23:22:44 -0700

Comments were requested, so:

Really only two things.

Section 2. Pragmatic Goals uses the term "abstractly correct" instead of 
"correct in the abstract":

    2.  Provide a path to avoid getting bogged down in declarative
        statements about definitions and debates about what is and is not
        correct in the abstract.
        *abstractly correct.*

I think I know enough US-English by now; I am not sure what "abstractly 
correct" really means. I think it means "abstractly correct". But nobody 
says that. Everybody says (and writes) "correct in the abstract". Google 
agrees:

http://www.googlebattle.com/?domain=abstractly+correct&domain2=correct+in+the+abstract&submit=Go%21

A Google search for the exact terms yields "correct in the abstract" has 
532,000 results; "abstractly correct" yields 7,580 results. (Don't even 
get me started on who is known to have used the latter, according to 
Google!)

Stick with "correct in the abstract".

The second comment addresses the whole draft.

It looks like this draft "really went there" in terms of actually 
updating 3986. It really does—or, at least, it tries to within this URN 
scope.

Please, don't do that. As much as I have invested into this URN thing, 
really, nobody cares (commercially) about URN URIs like people care 
(commercially) about HTTP(S), LDAP, DATA, MAILTO, WEBSOCKET, MAGNET, etc.

I thought the chairs/ADs already said that updating 3986 is out-of-scope 
a long time ago. This strikes me as a poor way to get what we want. 
Rather than dialing it back, this draft-04 is getting more aggressive.

Bend the URN draft(s) in whatever ways you want to make it work with 
what RFC 3986 says about URIs. Remember that RFC 3986 "resources" that 
URIs point to are abstract: they can be anything you want, or don't 
want, or whatever. The whole enterprise (of trying to change 3986 when 
we all know that ship has sailed and honestly it's just totally not 
worth it anyway) is making me feel very tired.

That is my feedback. Thanks,

Sean

On 6/8/2016 7:03 AM, [email-masked] wrote:
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 29 Jun 2016 18:29:37 +0900

Hello everybody,

> That is my feedback. Thanks,

I agree. I started to read this draft, but I only got up to the 
following (partial) sentence in the abstract:

 >>                   this specification separates URNs from the semantic
 >>  for Uniform Resource Identifiers (URIs) in RFC 3986

In particular, the word 'believe' stuck out. Since when is the IETF 
dealing with religion or similar stuff? Believes, one way or another, 
just don't belong in an IETF document.

The 'problem' with RFC 3986 may be that it uses some specific terms. But 
then, any spec has to use some specific terms. The IP spec probably uses 
the term 'packet', but there's probably nothing in that spec that says 
that a packet doesn't have to be a physical 🎁 [packet/present emoji]. 
In a very similar way, about every IETF spec uses some terms that 
heretofore or still currently have other meanings in other contexts.

RFC 3986 is absolutely no exception here. Maybe somebody has to write an 
RFC that would explaining something like the following: If you come from 
another field (that may not only be library science, but maybe biology, 
or mechanical engineering, or what not, or even just from apps for ops 
and vice versa), don't assume the terms used in the spec mean exactly 
what they mean in the field you are coming from. Instead understand (and 
if necessary, translate for yourself) these terms with the meanings that 
they are (explicitly or implicitly) given in the document. Understand 
that lots of meaning in any language or jargon is derived from use in 
that language or jargon.

It's true that RFC 3986 is easier to read for somebody familiar with 
HTTP than for somebody familiar with URNs, but actually happens to make 
sense because there are (at least currently) many more HTTP URIs than 
URNs. But there's nothing in there that precludes identifiers "to be 
stable for a very long time"
or to
"identify large and complex entities",
quite to the contrary. It's the URN spec that the necessary constraints 
for this on top of the (extremely low, even for syntax) constraints in 
RFC 3986.

Well, maybe this is just me who has been doing a lot of spec reviews and 
gotten used to the fact that different specs use different vocabulary, 
and sometimes the same word with different meanings. But I don't think 
I'm alone here; this is pretty much common sense for any kind of subject 
field.

Regards,    Martin.

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 Jun 2016 12:00:15 -0400

Sean, Martin,

One pre-call observation (at this point, I'm not sure I'll
manage to make the call)...

While we can debate how to fix semantics-clarif at length
(including nit-picking about "abstractly correct", which I will
happily change just to avoid spending time debating it), 

semantics-clarif _does not_ change, or try to change, 3986.
What it attempts to do is to establish some local context,
relationships, and terminology for URNs that conflict with some
people's reading of 3986.  If that is still not clear to a
significant fraction of the WG, it is clear that a new editor is
needed because I can't stand looking at it any more.

But the bottom line seems to me to be the comment in another
note that we should just make 2141bis conform to whatever 3986
says about URIs.  I believe that the WG has already concluded
that is impossible (at least as many participants in the WG
under 3986) and that we need to move past it.  If that
discussion is going to be reopened, let's do it explicitly,
rather than trying to do it by debating the fine points of
either of these URNBIS documents.

   john