Subject: [urn] Thread about urnbis-semantics-clarif-03 in the context of updating 3986

From: Sean Leonard <[email-masked]>
Date: Tue, 31 May 2016 07:32:36 -0700

This is a thread about urnbis-semantics-clarif-03 in the context of 
updating RFC 3986, as requested.

draft-ietf-urnbis-semantics-clarif-03 originally started out as (John's) 
polemic against using the URI framework ("syntax and high-level 
semantics of URLs" -- see draft-ietf-urnbis-urns-are-not-uris-00 Section 
1) for URNs. That draft has a Section 3, which states:

This specification removes URNs from the scope ofRFC 3896 <https://tools.ietf.org/html/rfc3896>.  It makes
no changes for URI types that remain within that scope.

**

That verbal formulation (including the typo...) has survived through the 
drafts into Section 4 of draft-ietf-urnbis-semantics-clarif-03.

Other stuff that purports to get updated: stuff about queries; stuff 
about fragments; and...that's about it. Oh, it also says stuff about how 
RFC 3401 and RFC 2483 apply but don't apply and we aren't talking about 
them.

******

Overall, the problems that need to be addressed are:

draft-ietf-urnbis-semantics-clarif-03 doesn't actually *do anything*. I 
view it as a lot of hot air...either that hot air gets into 2141bis, or 
blow it away. I see nothing implementable here in Internet software or 
protocols.

clarif-03 purports to "update 3986" but it doesn't really update 3986. 
Actually what it's doing is it's passive-aggressively declaring that 
URNs (i.e., 2141bis) are adopting some of RFC 3986 but not the whole 
thing, without really understanding what RFC 3986 actually says. That is 
an update to 2141bis, not to RFC 3986. If this WG really wants to say 
that, then 2141bis should simply say "a generic URI processor can parse 
URNs syntactically as urn: URI schemes".

Specific paragraph in clarif-03:

    This document updatesRFC 3986 <https://tools.ietf.org/html/rfc3986>  to make the distinction between syntax
    and semantics clear for URNs and to isolate URNs from presumed URI
    semantic requiremnts.  It is important to note that some readers of
    RFC 3986 <https://tools.ietf.org/html/rfc3986>  are convinced that the separation is clear in that
    specification and therefore that no changes to that document are
    needed.  For them, this specification is only a confirming
    clarification.

(again, a typo)

The two key issues are that clarif-03 doesn't do either of the critical 
things that it purports to do:

"This document updates RFC 3986 to make the distinction between syntax 
and semantics clear for URNs"

...actually it doesn't really clarify any distinction between syntax and 
semantics.

"isolate URNs from presumed URI semantic requirements"

The keyword here is "presumed". If you read RFC 3986, you basically see 
that there are very few presumed semantic requirements. Those 
requirements should not be presumed--they need to be spelled out, if 
you're going to change them.

Julian just re-posted his April 27 message, with quotations from the 
specs. As pointed out, URIs don't have semantic requirements in the ways 
that clarif-03 worries about. This is focusing on the query and fragment 
productions. Specifically, RFC 3986 says:

"If no such representation [a content, including a media type] exists, 
then the semantics of the fragment are considered unknown and are 
effectively unconstrained. Fragment identifier semantics are independent 
of the URI scheme and thus cannot be redefined by scheme specifications."

Okay...that is true...but obviously the absolute-URI (excluding the 
fragment) defines what the fragment is doing, because the absolute-URI 
defines the primary resource and directly influences the retrievable 
representations. If I say:
http://foo.com/bar#baz
ldap://foo.com/bar#baz
data:text/plain,bar#baz

Obviously, #baz means something really different in these cases because 
http, ldap, and data are going to return very different primary 
representations (if they are even capable of returning anything at all). 
There are very large classes of URIs that are not intended for 
retrieving Internet content (data with a media type and parameters). The 
absolute-URI (including the scheme and path) DEFINES (not "redefines") 
the primary resource, the primary resource defines the scope and quality 
of representations, and therefore, secondary resources.

So...when 2141bis says something about fragment, /including saying 
nothing at all/, it is not in conflict with RFC 3986.

Sean

---

From: John C Klensin <[email-masked]>
Date: Tue, 31 May 2016 13:11:09 -0400

Just one reminder on this subject...

The WG has always (or more or less always) considered
urnbis-semantics-clarif as primarily a working document for its
own convenience in developing 2141bis and anything else
relevant.  We've agreed (I think several times) to defer the
question of whether to actually publish it as an RFC until we
were winding up our work (that might be now -- now my call).  If
the WG concludes that it is no longer needed (or, in retrospect,
never was), I'd be the first one to applaud and take it out of
my queue.

That "maybe we will publish and maybe we won't" approach has
almost certainly resulted in a more casual attitude toward
precise text than would have been the case for a draft that was
clearly going to be standards-track or RFC-publication-track.
The assumption, perhaps unrealistic or wrong in retrospect, has
been that, if the WG decided to publish it or its offspring as
an RFC, we would go over it and clean details up at that point.
The approach also dictated at least two other sets of decisions
that have been raised (again) recently:

(1) The reference to it from 2141bis is Informative, not
Normative.  If 2141bis is not constructed well enough to justify
that distinction, it is a problem with it (2141bis) and
suggestions about text are welcome.

(2) There is some, perhaps a good deal, of text in
urnbis-semantics-clarif that is intended to convey the general
sense that the WG isn't sure (and doesn't have clear consensus)
whether there is are issues between 2141bis (etc.?) and 3986 or
not; if there are conflicts, read this document and 2141bis as
authoritative for URNs and not 3986; if there are not, you can
ignore this document.  Section 2, which, as Sean points out, was
carried forward largely unchanged from the "URNs are not URIs"
document (see below), attempts to cover that point.  In
rereading it, it occurs to me that an entirely different
approach could be taken, which would be to say just that, i.e.,
to start from "Some people in the community think there is a
conflict between these URN specs and 3986.  Others disagree.  If
readers find apparent conflicts, especially in the
scheme-specific syntax for URNs, then 2141bis should be treated
as authoritative for URNs independent of what they believe 3986
says."   Such a statement, I'd hope with better wording, could
easily be incorporated into 2141bis and this whole "semantics
versus syntax" discussion and all of the baggage associated with
it discarded.  Or, if someone thinks a separate document is
needed, replacing urnbis-semantics-clarif, as far as I'm
concerned, please have at it.

Finally, not because I'm particularly attached to either
document, but because it might be important, one clarification:
the "URNs are not URIs" proposal came about after some fairly
extensive discussions within the WG about both the apparent
substantive issues involved and about how to change the WG
discussion focus back to URNs and away from
seemingly-interminable discussions about the relationship
between URNs and whatever people thought 3986 said, a set of
discussions that also included examination of places where 3986
appeared to change or constrain 2141 and/or 3406 without
explicitly discussing or updating those documents, leaving all
three in an ambiguous state.    I no longer remember how much of
those discussions were on the mailing list, in formal meetings,
and in sequences of small group conversations, but note that
draft-ietf-urnbis-urns-are-not-uris really was a WG document for
which I drew the short straw to assemble and edit -- fwiw, the
original idea was not mine although I think the syntax split one
might have been.  At a subsequent meeting, the WG decided on the
narrower approach that draft-ietf-urnbis-semantics-clarif
attempts to capture.  I drew that short straw too and, being
lazy (and, IIR, on instructions from that meeting), reused as
much text as I thought feasible.   I hope that the "URNs are not
URIs" approach is part of our past and we can concentrate on
moving forward, but it was a WG document, did have some level of
consensus (although obviously not enough) and I don't think
dismissing it as "John's polemic" is at all helpful.  

That earlier approach could become relevant again in one
particular situation that I hope won't arise.  The in-meeting
conclusion and subsequent list discussion that discarded "URNs
are not URIs" in favor of the syntax-semantics separation was, I
believe, ultimately tentative and experimental wrt the question
of whether the latter separation could be made to work.   If the
WG were to conclude that a distinction is needed and the
syntax-semantics separation is not feasible in practice, unless
we simply decided to abandon URNs, the result would presumably
be a return to the "URNs are not URIs" approach.  That approach
would require updating 3896 as well, but only to the extent of
removing the example at the end of Section 1.1.2, modifying the
example in Section 3, and modifying the discussion in 1.1.3 to
remove the discussion of URNs and maybe non-locator names.  One
of the attractions of that updating relationship was that there
was never any question of its documentary effect on 3986 (unlike
the current discussion about the much finer distinction of the
"semantics-clarif" approach).

  best,
     john

---

From: Andrew Newton <[email-masked]>
Date: Tue, 31 May 2016 20:02:04 +0200

On Tue, May 31, 2016 at 4:32 PM, Sean Leonard <[email-masked]> wrote:
> This is a thread about urnbis-semantics-clarif-03 in the context of updating
> RFC 3986, as requested.
>
> polemic against using the URI framework ("syntax and high-level semantics of
> URLs" -- see draft-ietf-urnbis-urns-are-not-uris-00 Section 1) for URNs.
> That draft has a Section 3, which states:

The definition of "polemic" is: a strong verbal or written attack on
someone or something.
The key words being "strong" and "attack" which connote discourse not
becoming of the IETF. I believe this is a mischaracterization of both
John and his work. Let's try to avoid such words in the future.

> Other stuff that purports to get updated: stuff about queries; stuff about
> fragments; and...that's about it. Oh, it also says stuff about how RFC 3401
> and RFC 2483 apply but don't apply and we aren't talking about them.

The references to 2483 and 3401 are in regard to scope of the changes
and seem completely appropriate.

> draft-ietf-urnbis-semantics-clarif-03 doesn't actually *do anything*. I view
> it as a lot of hot air...either that hot air gets into 2141bis, or blow it
> away. I see nothing implementable here in Internet software or protocols.

"hot air"... again, let's dial it down.

> Julian just re-posted his April 27 message, with quotations from the specs.
> As pointed out, URIs don't have semantic requirements in the ways that
> clarif-03 worries about. This is focusing on the query and fragment
> "If no such representation [a content, including a media type] exists, then
> the semantics of the fragment are considered unknown and are effectively
> unconstrained. Fragment identifier semantics are independent of the URI
> scheme and thus cannot be redefined by scheme specifications."

The entirety of that paragraph is:

   The semantics of a fragment identifier are defined by the set of
   representations that might result from a retrieval action on the
   primary resource.  The fragment's format and resolution is therefore
   dependent on the media type [RFC2046] of a potentially retrieved
   representation, even though such a retrieval is only performed if the
   URI is dereferenced.  If no such representation exists, then the
   semantics of the fragment are considered unknown and are effectively
   unconstrained.  Fragment identifier semantics are independent of the
   URI scheme and thus cannot be redefined by scheme specifications.

As I recall, the issue was that fragments could not be defined by a
URN namespace thus causing the basis for separation of syntax from
semantics.

-andy

---

From: Sean Leonard <[email-masked]>
Date: Tue, 31 May 2016 12:20:52 -0700

> John and his work. Let's try to avoid such words in the future.

John has been doing good work and the work is appreciated.

When I wrote the term "polemic", it is because "Names are Not Locators 
and URNs are Not URIs" (the title, and the document, see, e.g., section 
1, draft-ietf-urnbis-urns-are-not-uris-00) *are* strong written attacks 
on something: namely, on the seemingly antagonistic relationship between 
URNs and URIs (specifically URN is attacking URI because it wants to 
secede from the URI country and set up its own republic of URN). There 
is nothing wrong in John's writing or in the characterization of it. Far 
from it--we need more strong opinions so we can clearly say "okay, we're 
going to go this way", or "no, we discussed it, we have decided we are 
not going to go that way".

> "hot air"... again, let's dial it down.

There is genuine frustration among implementers that this URN work has 
taken too long and is far too nebulous. Polemics etc. are fine for 
generating and stirring debate (the original urns-are-not-uris). But we 
seem to be continuing to have debates without resolutions...

What matters is that people write software that interoperates with other 
software. There is no grand theory of URIs or what have you, apart from 
the fact that two people write software a particular way that uses some 
sequence of characters to do similar things. Whether urn:isbn:1234 
identifies a book, pages in a book, some stream of bits, or abstract 
notions of fair play and substantial justice, *does not matter*, as long 
as we agree on them. URIs can do anything, or nothing, that we want them 
to as software engineers. Ditto for URNs.

Maybe this is a process issue. It's hard for me (and not to raise 
others' hands, but I think Julian is raising this point too) to see how 
RFC 3986 is getting updated, when RFC 3986 is not really getting 
updated, you're just creating a urn: string that only "partially" adopts 
RFC 3986 things. Maybe it's just better in rfc2141bis to say that URNs 
are syntactically URIs (whatever verbal formulation you want), and where 
they differ, to point out *in rfc2141bis* those specific differences. No 
"Updates: RFC3986" necessary in the header. And hopefully, the need for 
the clarif document will be obviated.

Regards,

Sean

---

From: John C Klensin <[email-masked]>
Date: Tue, 31 May 2016 15:22:45 -0400

Andy,

Thanks.  Let me try to shed some additional light on part of
this by posting some of the analysis I've been resisting...

--On Tuesday, May 31, 2016 20:02 +0200 Andrew Newton
<[email-masked]> wrote:

Julian's quote from 3986...
>> "If no such representation [a content, including a media
>> type] exists, then the semantics of the fragment are
>> considered unknown and are effectively unconstrained.
>> Fragment identifier semantics are independent of the URI

>    The semantics of a fragment identifier are defined by the
> set of    representations that might result from a retrieval
> action on the    primary resource.  The fragment's format and
> resolution is therefore    dependent on the media type
> [RFC2046] of a potentially retrieved    representation, even
> though such a retrieval is only performed if the    URI is
> dereferenced.  If no such representation exists, then the
> semantics of the fragment are considered unknown and are
> effectively    unconstrained.  Fragment identifier semantics
> are independent of the    URI scheme and thus cannot be
> redefined by scheme specifications.

The first problem with the above is that, unless somehow knows
which sentences are relevant and which ones are not, it can be
read as self-contradictory, at least for things that are not
classical URLs or similar to them.  Sentence 2 ("The fragment's
format...") says that the format and resolution of the fragment
are dependent on the media type, even though..."  If the
paragraph stopped there, a reasonable person might conclude that
fragments are invalid unless a retrieval is performed and the
URI dereferenced (not even clear what that combination allows or
prohibits, but let's skip that).   Fortunately, the text then
goes on to say "...unknown and effectively unconstrained", which
is fine, except that, if "such representation" refers to the
"retrieved representation" obtained when a URI is
"dereferenced".  That term is used in 1.2.2 as part of the
definition of "URI 'resolution'" and then defined as the use of
an access mechanism that is determined as part of "resolution".

Skipping over that bit of circularity, we have more or less the
"3986 does not constrain URN fragments at all, so anything
2141bis says would be true or not-true" (not quite a fair
characterization, but bear with me).  However, then one gets to
the next sentence, which has been quoted to the WG several times
(and, IIR, had a large influence on the present state of
2141bis).  It says that fragment semantics are
scheme-independent and schemes cannot redefine them.  That would
seem to contradict "unknown and ... effectively unconstrained".  

Now the good news is that, as Julian has pointed out, the web
community knows what that means and (at least for URLs) has a
consistent understanding of it, consistent enough to ignore the
issues that some of us who are relative outsiders consider
convoluted and possibly self-referential or recursively
referential.  The bad news is that, for non-locator URIs, the
WG's choices were to simply ignore 3986 language that seemed
unclear or inappropriate, to devise a trick that would permit
work on URNs to go forward without having to try to completely
analyze and fix 3968, or to try to do that analysis and repair
job.   The latter was clearly out of scope for the WG (and, for
the WG, impossible in practice).  Early discussions made it
clear that the WG would not be allowed to get away with the
former.   That left us with the second option, which we've tried
to apply in a couple of different ways and which, as I suggested
earlier, if far more about separating the URN discussions from
debates about what 3986 means for non-locators than it is about
fixing or updating 3986.  If the IETF had a significantly
broader vocabulary than "updates", we might well use it, but it
doesn't.

> As I recall, the issue was that fragments could not be defined
> by a URN namespace thus causing the basis for separation of
> syntax from semantics.

Yes, but I would have said "it wasn't clear whether fragments
could be defined by a URN namespace or not and we needed to
avoid spending further time on that debate" rather than your
more definitive "could not be defined".  The latter would be
false if one ignored the last sentence quoted above and focused
on "unknown and ... effectively unconstrained".  The other
qualification is that fragments were not believed to be the only
case -- we were concerned about issues with queries (with or
without their division into q- and r-components) and the
possibility of issues that no one had yet identified with, e.g.,
statements about resolution and resources, that might come back
and bite us later.  

Taking a really narrow view rather than the over-broad "syntax,
no semantics" and trying to identify and make exceptions to the
specific language that was problematic to URNs would have
required an extensive search and analysis for which I believe
there was general WG agreement was unneeded, undesirable, and
ultimately out of scope.    I hope we can avoid being dragged
backwards into the analysis we explicitly decided to avoid and
had hoped we could avoid the partial analysis of fragments,
resolution, access methods, and dereferencing above.

best,
   john