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

[Sean Leonard <[e-mail]>]

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