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

From: Keith Moore <[email-masked]>
Date: Tue, 03 Sep 2013 10:18:05 -0400

I recommend that "/" be reserved to communicate options to resolution
services, so that "?" and "#" do not get overloaded for this purpose.

Keith

On 08/28/2013 06:54 AM, Juha Hakala wrote:
> 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:
>> On 08/18/2013 01:34 PM, John C Klensin wrote:
>>>
>>> --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.
>>
>> 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
>>
>> _______________________________________________
>> urn mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/urn
>
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn