Subject: [urn] Allowing "/" in the NSS (was Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt)

From: "Svensson, Lars" <[email-masked]>
Date: Sun, 18 Aug 2013 02:27:20 +0000

> Today begins a two-week working group last call of draft-ietf-urnbis-
> rfc2141bis-urn-06.txt. This last call will end Tuesday, 27 August 2013.
> 
> The document can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/
> 
> Please review and comment on the draft, even if it is only to say on the
> record "I have reviewed this document thoroughly and it looks good."  We
> would like to have no fewer than five people report that they have taken a
> look at the whole document and reported their findings.

This is a late question the range of reserved/forbidden characters to which I haven't found any discussion on the list (if it has been discussed, could someone please point me to the relevant discussion?).

One of the changes between 2141 and 2141bis is that in 2141bis the characters "~" and "&" characters are allowed in an NSS. Has there been any discussion on allowing "/" in the NSS as well. There are use cases where this can make sense (e. g. embedding DOIs in URNs). Is there a strong reason not to allow that?

Thanks,

Lars

---

From: Keith Moore <[email-masked]>
Date: Sat, 17 Aug 2013 22:31:11 -0400

> One of the changes between 2141 and 2141bis is that in 2141bis the characters "~" and "&" characters are allowed in an NSS. Has there been any discussion on allowing "/" in the NSS as well. There a…
The best reason I know of is that it's about the only reserved character 
left which could be used to extend URN syntax, say, to communicate 
requests to resolution services.   Offhand I think this is more 
important than the ability to embed DOIs in URNs without %-encoding, 
though I admit to some bias here.   DOIs are, after all, an attempt to 
end-run around IETF standardization.

Keith

---

From: John C Klensin <[email-masked]>
Date: Sun, 18 Aug 2013 11:27:35 -0400

--On Saturday, 17 August, 2013 22:31 -0400 Keith Moore
<[email-masked]> wrote:

>...
> DOIs are, after all, an attempt to end-run around IETF
> standardization.

Only if you believe that every identifier type that might be
used on the Internet is either owned by the IETF or an end run
around it.  Absent firm beliefs that the IETF is in charge of
the Internet _and_  that there are no relevant non-Internet uses
for digital objects or identifiers, it is at least as sensible
to argue that URNs are an attempted end-run around DOIs and
their predecessors.

And, yes, I know the history.  But not only are there multiple
versions of it, but it just isn't relevant at this point.

    john

p.s. That doesn't stop me from agreeing that keeping "/" out of
NSSs is a good idea (and, indeed, from wondering whether we are
really sure that allowing "~" and "&" is necessary.

---

From: Keith Moore <[email-masked]>
Date: Sun, 18 Aug 2013 11:31:30 -0400

> versions of it, but it just isn't relevant at this point.

I certainly don't pretend that the history can be summarized in one 
sentence; I'm just trying to be honest about the nature of my bias.

> really sure that allowing "~" and "&" is necessary.
I also wonder whether allowing tilde and ampersand are good ideas. To me 
that looks like an incompatible change that could potentially harm 
interoperability for existing URNs.

Keith

---

From: John C Klensin <[email-masked]>
Date: Sun, 18 Aug 2013 13:34:09 -0400

--On Sunday, 18 August, 2013 11:31 -0400 Keith Moore
<[email-masked]> wrote:

>...
>> p.s. That doesn't stop me from agreeing that keeping "/" out
>> of NSSs is a good idea (and, indeed, from wondering whether
>> we are really sure that allowing "~" and "&" is necessary.
> I also wonder whether allowing tilde and ampersand are good
> ideas. To me that looks like an incompatible change that could
> potentially harm interoperability for existing URNs.

In general, relaxing a previous restriction has no serious ill
effects, at least if those restrictions were followed.  But I'd
like to see, at least, a little more motivation for relaxing it
included in the document.

However, to expose one of my biases, the whole "some characters
are reserved, others are reserved for special purposes except
when they are not, and still others aren't reserved unless
someone says so, all on a URI scheme type basis" model of
character use in URIs has struck me as a bad idea since the
beginning and I see this particular set of choices as just a
symptom.

    john

---

From: Keith Moore <[email-masked]>
Date: Sun, 18 Aug 2013 14:02:58 -0400

On 08/18/2013 01:34 PM, John C Klensin wrote:
> effects, at least if those restrictions were followed.

The principle danger that I see is if there are existing systems that 
convert some other kind of identifiers to URNs, and they currently 
percent-encode tildes and ampersands, either for the purpose of coining 
new URNs or resolving existing identifiers as URNs.   If those 
converters change their behavior to stop encoding tildes and ampersands, 
lookups of old URNs that were converted with an old converter will 
fail.   If some of those converters change their behavior and others 
don't, behavior will be inconsistent between different implementations.

So I think we need strong justification to remove existing restrictions 
on characters permitted in URN syntax.  And in light of the scenarios 
described above, a desire to be able to convert existing identifiers to 
URNs without percent-encoding some of the characters in those 
identifiers might actually be a good reason to not change those 
restrictions.

Keith

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 19 Aug 2013 15:42:01 -0600

> identifiers might actually be a good reason to not change those

With my editor hat on, I see no particular rationale for allowing tilde
and ampersand in the updated syntax. As I recall, doing so was a
consequence of simplifying the syntax (i.e., borrowing the pchar rule
from the URI specification), and that might have been done without full
consideration for the consequences.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Juha Hakala <[email-masked]>
Date: Wed, 28 Aug 2013 13:54:13 +0300

Hello,

There are two persistent identifiers (Handle and DOI) which always 
require "/" in the identifier string.

Many identifier systems do in theory allow the use of slash, tilde or 
ampersand. In practice, they seem to be seldom used. For instance, I 
have never seen an NBN which would have contained anything else but just 
ASCII characters.

Nobody has required that it should be possible to use "~" and "&" 
without percent encoding. The change to the RFC 2141 NSS charset was 
done mainly to simplify the specification and because we saw no problem 
in doing that. Now that a good argument against allowing their use 
un-encoded has emerged, we can return to the original policy, and 
require percent encoding of these characters. This should not be a 
problem, since there does not seem to be a strong use case for allowing 
them.

If there were plans to register a URN namespace to Handle and DOI, we 
should analyze the pros and cons of allowing "/". Since the Handle / DOI 
community is not planning to rely on URN resolution we can, for the time 
being, stick to the current policy as regards "/".

All the best,

Juha

On 18.8.2013 21:02, Keith Moore wrote:
> percent-encode tildes and ampersands, either for the purpose of 
> coining new URNs or resolving existing identifiers as URNs.   If those 
> converters change their behavior to stop encoding tildes and 
> ampersands, lookups of old URNs that were converted with an old 
> converter will fail.   If some of those converters change their 
> behavior and others don't, behavior will be inconsistent between 
> different implementations.
>
> So I think we need strong justification to remove existing 
> restrictions on characters permitted in URN syntax.  And in light of 
> the scenarios described above, a desire to be able to convert existing 
> identifiers to URNs without percent-encoding some of the characters in 
> those identifiers might actually be a good reason to not change those 
> restrictions.
>
> Keith
>
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn