Subject: [urn] draft-ietf-urnbis-rfc2141bis-urn vs draft-ietf-appsawg-uri-scheme-reg and RFC1737

From: Larry Masinter <[email-masked]>
Date: Fri, 27 Mar 2015 16:34:53 +0000

draft-ietf-appsawg-uri-scheme-reg revises RFC 4395, including
the requirements for permanent URI schemes. Expect a new version
very soon, based on IETF last call comments, IANA review, etc.

It is currently scheduled for IESG telechat April 8.
https://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/

If approved, the requirements for permanent URI schemes will
apply to the “urn:” scheme, and draft-ietf-urnbis-rfc2141bis-urn.

I do not think draft-ietf-urnbis-rfc2141bis-urn meets the requirements
for permanent URI scheme registrations. If the URNBIS working group
thinks the requirements are incorrect, or that this is a special
case where SHOULD requirements do not apply, then please
either justify amendments to uri-scheme-reg or provide adequate
justification for those exceptions.

The requirements I have in mind include the use of “/“ in
a URI scheme that was “not intended for use with relative URIs”,
the handling of Unicode characters, the definition of the
use of fragment identifiers, and section 3.3 Well-Defined
in the requirement of being clear about how the “urn:” scheme
is expected to function. This requirement is stronger than
the RFC 2026 requirement.

RFC 1737 Functional Requirements

RFC 1737 was the original URN working group consensus
on requirements for URNs. While RFC 2141 was not constrained
by RFC 1737, it does provide some justification for the features
of URNs that, in my opinion, rfc2141bis-urn weakens. If there
is some agreement that RFC 1737 requirements are relevant,
I’ll review of “urn:” as defined in rfc2141 vs. rfc2141bis-urn to
ensure that the original URN requirements have not been 
inadvertently missed in the effort to satisfy other more
current requirements.

Larry
—
http://larry.masinter.net

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 27 Mar 2015 10:58:05 -0600

> https://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/

I'm happy to see that work finishing up.

> for permanent URI scheme registrations.

Because I at least haven't been tracking the 4395bis work, I haven't put 
effort into ensuring that 2141bis meets 4395bis requirements.

> If the URNBIS working group

Until I have a chance to review 4395bis (it's been a long time since I 
looked at it), I won't have further comments. However, your summary 
below is helpful as a pointer to issues that might need attention.

> inadvertently missed in the effort to satisfy other more

That to me seems like a separate issue from the 4395bis conformance.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Larry Masinter <[email-masked]>
Date: Sat, 28 Mar 2015 05:20:08 +0000

>below is helpful as a pointer to issues that might need attention.

https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-05
 was just posted, so now I can quote it.

I have three issues which I think are solvable and I’ve proposed solutions
for them all:

============

1. Use of “/“

https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-05#section-3.2

> Schemes that are not intended for use with relative URIs SHOULD avoid
> use of the forward slash "/" character, in order to avoid unintended
> processing such as resolution of "." and ".." (dot-segments).

rfc2141 defined the urn: scheme as "not intended for use with relative
URIs", and 2141bis does not change this intention;
https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-10#section-5

says explicitly "URNs are not hierarchical”. a SHOULD
requires “valid reasons” to be given, but I can find none
in 2141bis.

Resolution: I think this can be solved simply by supplying
at least one compelling use case where the advantage of using “/“
instead of some other punctuation (like : or @ or !) outweighs
the risks, and ensuring all URN namespaces that allow / also
don’t allow ‘.’ or ‘..’.  

============
2. Use of “#”

https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-05#section-3

also says (now more explicitly):

> For
> example, this means that fragment identifiers cannot be re-used
> outside the generic syntax restrictions, and fragment identifiers are
> not scheme-specific.A scheme definition must specify the scheme
> name and the syntax of the scheme-specific part, which is clarified
> as follows:
> URI = scheme ":" scheme-specific-part [ "#" fragment ]
> scheme-specific-part = hier-part [ "?" query ]

But 2141bis attempts to define fragment identifiers for the “urn:” scheme
specifically in Section 5 where it says
“… f-component need not be semantically equivalent to the URI … 
fragment component” which sounds like it is trying to make fragment

identifiers for urn URIs scheme specific.

I’m not sure how to resolve this, but here are two possible paths:

I imagined earlier inventing some kind of 
virtual media type for each URN namespace that wanted
special handling for f-components, but it’s a lot of trouble
and a substantial departure from  RFC 2141 which is not well-motivated
since no use cases are supplied. 

An alternative would be to change uri-scheme-reg (as well as 3986)
to ALLOW scheme-specific fragments. I find this more attractive,
because there ARE some use cases for scheme-specific fragments,
e.g., temporal fragments of realtime URIs.

==============
3. Update of formal namespaces with ‘Expert Review’

2141bis relaxes the registration policy for formal namespaces from "IETF
       Review" to "Expert Review”. In particular

https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-10#section-8.1

says
> A formal namespace registration can be revised by updating the
> registration template, following the same steps outlined above for
> new registrations.

This seems to allow existing namespace definitions which
went through IETF approval and are defined by Informational
RFCs to be updated by Expert Review.

But uri-scheme-reg retains the requirement in section 7

> Registrations can be updated in the registry by the same mechanism as
> required for an initial registration.  In cases where the original
> definition of the scheme is contained in an IESG-approved document,
> update of the specification also requires IESG approval

I think in the case of urn:, the definition of urn URIs has

been delegated to namespace definitions, but the “original”
definition of the scheme overall is currently in a set of
IESG-approved documents. I suppose the IESG, by approving
2141bis, would be approving the change. 

However, the problem is that it leaves a raft
of previously IESG-approved RFCs in the RFC series
marked as Informational when they should be Historic.

Resolution: change 2141bis section 7 to
note that in the case of updating the registry for a namespace
that was previously defined by an Informational RFC,
the IESG should be asked first for approval to mark the
previous definition RFC as historic.

Larry
—

---

From: Keith Moore <[email-masked]>
Date: Sat, 28 Mar 2015 03:20:34 -0400

> I have three issues which I think are solvable and I’ve proposed solutions

A use case would help, but that still doesn't address the problems that 
result with use of URNs and relative URIs in documents that change over 
time, so that those combinations of URNs and relative URIs become 
invalid, inaccessible, meaningless, or change meanings.

Part of the problem may be that we're used to thinking of the result of 
a base URL and a relative URI as being another URL.   But if a base URN 
is combined with a relative URI, the result looks like a URN but (absent 
some guarantees that aren't supplied in 2141bis) doesn't necessarily 
have the persistence properties of a URN.   But even if this can somehow 
be finessed, I think the use of relative URIs with base URNs (when the 
latter refer to resources whose contents change over time) still creates 
a strong incentive to change the meanings of existing URNs.

Good catch.   I don't think this can be fixed without updating 3986.

I'm personally sympathetic to the idea that fragments should be defined 
differently for URNs than for URLs.   But this still begs the question 
of how to interpret fragments for URNs that resolve to URLs.   If urn:X 
resolves to http:Y, should urn:X#z resolve to http:Y#z or what?   I'm 
really uncomfortable with the notion that using a URN to name a resource 
that also has a URL means that you can't address a fragment of that 
resource, or that there are potentially different names for the same 
fragments of that resource.

Keith

---

From: John C Klensin <[email-masked]>
Date: Sun, 29 Mar 2015 14:40:50 -0400

--On Saturday, March 28, 2015 03:20 -0400 Keith Moore
<[email-masked]> wrote:

>> An alternative would be to change uri-scheme-reg (as well as
>> 3986) to ALLOW scheme-specific fragments. I find this more
>> attractive, because there ARE some use cases for
>> scheme-specific fragments, e.g., temporal fragments of
>> realtime URIs.
> 

Well...   Variations on this have been raised and discussed,
although with little response on the list.  I hope you folks
have been reading it and am disappointed this didn't come up
earlier.

First, the "syntax only" decision makes the binding that 3986
specifies between fragments and media types inapplicable to URNs
and hence allows URN-scheme-specific fragments and fragment
interpretation.  I hope we don't need to revisit that issue.  I
agree that there is a more general issue and that it needs to be
addressed in a revision or update of 3986, but that isn't a
URNBIS WG problem.  That leads to...

> I'm personally sympathetic to the idea that fragments should
> be defined differently for URNs than for URLs.   But this
> still begs the question of how to interpret fragments for URNs
> that resolve to URLs.   If urn:X resolves to http:Y, should
> urn:X#z resolve to http:Y#z or what?   I'm really
> uncomfortable with the notion that using a URN to name a
> resource that also has a URL means that you can't address a
> fragment of that resource, or that there are potentially
> different names for the same fragments of that resource.

This is part of a more general problem that concerns me (and
that, again, has been raised earlier).

Let's examine URNs that resolve to one or more URLs and ignore
other types of URNs for a moment.  Can one plausibly assume that
all of those URLs (or whatever resolves or executes them) will
consider the same set of, e.g., queries or fragments to be
plausible?  If not, do we care and, in particular, does that
violate whatever we think we mean by persistence?

Note that "persistence" gets tricky in this case.  If one
assumes that the URN identifies a document, like the content of
an RFC, that will [soon] be available in multiple forms and with
multiple online locations/copies of each form, the URLs to which
the URN might lead are not only not all equal but different
members of the set point to those different instantiations of
something the RFC Editor is required to believe are the same
content and therefore the rest of us are too.   It may be that
invalidates the urn:ietf:rfc sub-namespace as insufficiently
persistent the moment the alternate forms start being published
but, if so, I see that as a problem for the RFC Editor and not
this WG.

If it does not invalidate the namespace completely, one
interesting question (which has come up in the WG before) then
becomes whether it would be legitimate to have a URN with a
query component that looked essentially like:

   urn:ietf:rfc:9999?format=pdf

(I note that is _not_ possible without a redefinition and
registration of the "ietf" namespace and its "rfc" sub-namespace
(or whatever one calls those) because 2141bis is quite specific
that, if a registration doesn't explicitly legitimize
q-components for a particular namespace, they are not permitted.)

The important characteristic of the above is the "?format=pdf"
really is qualifying information for the base URN, telling the
URN "resolver" which  URLs from the collection that would be
possible without it to to return, and not a query to be applied
to one or more of those URLs.

Contrast it with 

   urn:ietf:rfc:9999#Section3.1
or, if you prefer
   urn:ietf:rfc:9999?Section=3.1

Where the f- and q-components are almost certainly intended to
be passed through to the URLs as fragments or queries.

>From at least one perspective, distinctions between the object
associated with an identifier and assorted metadata associated
with either the object or the identifier are just special cases
of the "instructions to the URN resolver" case.

We don't have any lexical or other namespace-independent way to
distinguish between the "instructions to the URN resolver" and
"instructions to be passed through to the URL" cases.  We've
raised it on the list, with proposals to 

	* Reserve q-components for local instructions and
	f-components for pass-through and vice versa
	
	* Create some special, scheme-wide (i.e., applying to
	all URN namespaces that allow the relevant components)
	syntax or keywords to separate the two cases.

I don't believe that either of those notions, or anything else
that has been proposed, has gotten nearly enough traction in the
WG to justify a specification that would apply across the
collection of namespaces.  So we are left with a per-namespace
situation that leaves notions of generic resolvers, even for the
narrow range of cases in which URNs are known to resolve to URLs
(or a selection from a family of URLs) in even more trouble.  

I, at least, would welcome suggestions.  Lamenting the state we
find ourselves in seems less helpful.

best,
    john

---

From: Keith Moore <[email-masked]>
Date: Tue, 31 Mar 2015 17:52:30 -0400

On 03/29/2015 02:40 PM, John C Klensin wrote:
> interpretation.  I hope we don't need to revisit that issue.

I suspect that we do, for reasons cited elsewhere, i.e. because this 
forces clients to have specific knowledge about every URN scheme in 
order to resolve URNs in a generic fashion.

>   I

I don't know that we can plausibly assume that.  But I don't think it 
inherently violates persistence for a URN to resolve to more than one 
form of the same content, which might yet vary among one another in 
their interpretation of fragments or queries. [1]   For instance 
urn:ietf:rfc:3986 might reasonably resolve to a text, an HTML, and a PDF 
version of the same document, but it might be the case that only the 
HTML document supports fragments, or that the fragment names in the HTML 
version don't match those in the PDF version.

What I do think is reasonable is to declare that if a URN resolves to 
multiple forms of the same content that vary in fragment or query 
interpretation, that use of an f-component or q-component with such a 
URN is undefined.   Or alternatively, if a URN resolves to multiple 
forms of the same content that vary in fragment or query interpretation, 
the effect of interpreting fragment or query information that are 
supplied with the URN (whatever the syntax) in terms of the actual 
resource is undefined, unless perhaps also supplied with the URN is some 
directive that constrains the choice of which form of the content to 
resolve to.   (is that complicated enough?)

(Note that this can happen even when not using URNs at all, since HTTP 
itself supports various forms of content negotiation.   Even though 
TimBL once vigorously insisted to me that fragments and queries had to 
be invariant across content negotiation, that's clearly not likely to 
work across multiple content-types that have different notions of 
fragments, and/or require different access protocols that impose 
different constraints on queries.    Anyway, if HTTP can't make 
fragments or queries invariant across content-negotiation, it's probably 
not reasonable to expect URNs or URN resolution to do so.)

[1] What might violate persistence is for a URN that contains an 
f-component or q-component to resolve to different revision of the same 
resource at different times, such that the meaning of the base URN when 
combined with the f-component or q-component changed over time.   This 
is why I want rfc2141bis to define whether each of f-, p-, and 
q-components affect persistence of the resulting identifier.   Note that 
I think it's going to be very confusing to people to understand that for 
a string like "urn:foo:bar/zot?xyzzy#mumble" that the whole string isn't 
persistent but, say, the "urn:foo:bar/zot" portion (or maybe just the 
"urn:foo:bar" portion) is persistent.    And I think it endangers the 
valuable property that exists with 2141-conforming URNs that an 
identifier beginning with "urn:" can be assumed to be persistent - since 
especially if URNs use rfc3986 syntax, people will consider the entire 
identifier as part of the URN -  just like they're used to parsing HTTP 
URLs.    But I also recognize that there's tremendous pressure to 
combine fragments and queries and path components with URNs, so I'm just 
asking that 2141bis define which portions of such URNs are supposed to 
be persistent.

> but, if so, I see that as a problem for the RFC Editor and not

Right, but I don't think the URN concept of "persistence" was ever 
intended to apply to variations in content rendition of the same 
revision of a resource.   It was certainly intended  apply to variations 
between different versions of the resource, and to forbid reusing the 
same URN to apply to a "different" resource at a later time.

> find ourselves in seems less helpful.

Basically I don't think the document meets 2026 criteria for Proposed 
Standard without resolving these issues, that IESG should not approve it 
unless/until such issues are resolved, and that we're doing harm to URNs 
(and thus acting against what I assume all of us care about) if we don't 
resolve these issues.

But to fix it, I think we "just" have to

(a) define which of the f-, p-, and/or q-components of a URN are 
required to be persistent along with the base URN
(Even if the answer is "none of the above", I think we still need to say 
that.   And I think each of these components needs to be considered 
separately, as the answer might well be different for different 
components, particularly given the desire to support relative URIs in 
conjunction with base URNs), and

(b) define some standard and namespace-independent means of indicating 
how to pass fragment and query to the resource for those cases in which 
the resource accepts them.  It might be that we just need to reserve 
some subset of fragment names and query parameter names (say, all names 
beginning with "~") for fragments or queries to be evaluated in the 
context of the resource (after removing the "~").    And of course 
2141bis needs to be fixed so that it doesn't preclude a general-purpose 
resolution protocol by permitting each new namespace to have different 
behavior for f-, p-, and q-components.

An alternative to (b) might be to define a standardized general-purpose 
resolution protocol, so that there would be a standard way to determine 
the mapping of urn:foo:bar?x#y onto one or more URLs that mapped x 
and/or y to the URL when appropriate.   But that solution has the 
possibly unfortunate side-effect of requiring resolution just in order 
to find out how to evaluate x in y in the context of a copy of the 
resource.   In other words, it's not sufficient to have a copy of 
urn:foo:bar or urn:foo:bar?x already cached in order to find fragment y, 
you actually have to know what the mapping is too.

Keith