Subject: [urn] A comment on draft-ietf-urnbis-rfc2141bis-urn-02

From: Bengt Neiss <[email-masked]>
Date: Wed, 14 Mar 2012 08:36:12 +0000

Hi all,

Just a comment on the text of the new text (RFC2141bis-urn-02)

I am concerned about the phrase "special meaning" in the text in the section "2.3.2. The percent character, percent encoding" as follows

"Namespaces MAY designate one or more characters from the URN
character repertoire as having special meaning for that namespace.
If the namespace also uses that character in a literal sense as well,
the character used in a literal sense MUST be encoded with "%"
followed by the hexadecimal representation of that octet.  Further, a
character MUST NOT be percent-encoded if the character is not a
reserved character."

Does "special meaning" mean "reserved character (should be treated as a reserved character within that namespace)" and thus MUST be percent encoded if it is used in a literal sense within the NSS?

In section "4.4 Additional considerations" in RFC3188bis-nbn-urn-03 the following text can be found:

"Hyphen MUST be used as the delimiting character between the prefix

 and the NBN string.  Within the NBN string, hyphen MAY be used for

 separating different sections of the identifier from one another."

My interpretation of this text is that URN's can look like "urn:nbn:se:kb-1234-5678"
Is hyphen in this text a character with a "special meaning"?

Depending on how the text about "special meaning" is interpreted the text about the use of hyphen in the NBN namespace might violate the section in RFC2141bis.

I think the phrase "special meaning" needs some clarification.

Regards,

//Bengt

---------------------------------------------------------
Bengt Neiss
Kungl. Biblioteket / National Library of Sweden
Phone: +46 (0)10 709 35 41

---

From: Alfred Hönes <[email-masked]>
Date: Wed, 14 Mar 2012 15:32:53 +0100 (MEZ)

> Just a comment on the text of the new text (RFC2141bis-urn-02)

Bengt,
thanks for taking the time to look into the drafts and commenting.

[[ speaking as the author/editor of the quoted I-Ds ]]

> I am concerned about the phrase "special meaning" in the text in the
> section "2.3.2. The percent character, percent encoding" as follows
>
>
> Does "special meaning" mean "reserved character (should be treated as
> a reserved character within that namespace)" and thus MUST be percent
> encoded if it is used in a literal sense within the NSS?

The quoted paragraph is carried over from RFC 2141 *top of page 4)
into the current draft almost unchanged -- the only changes are
- to avoid messing up with well established character set terminology,
  "character repertoire" is used in place of "character set";
- "%-encoding" is uniformly spelled out as "percent-encoding"
  throughout the draft.

The important point here, IMO is the conjunction -- the character
must both have special (semantical and/or syntactical) meaning
within the existing namespace, AND it is desired to make use of it
in the assigned strings of that namespace in the literal form, i.e.
without that special meaning.

> In section "4.4 Additional considerations" in
> RFC3188bis-nbn-urn-03 the following text can be found:
>
> Depending on how the text about "special meaning" is interpreted
> the text about the use of hyphen in the NBN namespace might
> violate the section in RFC2141bis.

NBN is not a single pre-existing namespace.
For the construction of the URN:NBN namespace, the nationally
assigned NBN strings are prefixed -- as in your example -- with the
URI scheme (urn), the URN NID (nbn), and the NBN prefix (se:kb).
The rfc3188bis draft is intended to make it clear that it does
not regard the hyphen character as a character of the type
referred to in the above quote from RFC 2141[bis], by giving only
the leftmost instance of hyphen in the NSS a special meaning --
and this hyphen is outside the assigned NBN string.

To this end, the "Declaration of syntactic structure of NSS part"
clause in the filled-out Namespace registration template in
Section 5 of draft-ietf-urnbis-rfc3188bis-urn-nbn-03 states,
first ...

|  The namespace-specific string (NSS) will consist of three parts:
|
|    a prefix, consisting of an ISO 3166-1 alpha-2 country code and
|    optional sub-namespace code(s) separated by colon(s),
|
|    a hyphen (-) as the delimiting character, and
|
|    an NBN string assigned by the national library or sub-delegated
|    authority.

... and, below the ABNF formalizing that the prefix cannot contain
a hyphen, but assigned NBN strings can, the prose states ...

|     Hyphen MUST be used as the delimiting character between the prefix
|     and the NBN string.  Within the NBN string, hyphen MAY be used for
|     separating different sections of the identifier from one another.

The final sentence reflects existing usage of hyphen in assigned
NBN strings.  Should a National library want to also use hyphens
within one of more of the different sections of such identifiers,
it would need to be escaped; but such practice is deemed very
confusing, has not been observed in practice, and hence is not
being sanctioned by the rfc3188bis draft.  This way, in my and
Juha's opinion, the second precondition from RFC 21410bis) is not
fulfilled here.

Therefore, I do not believe that we have a problem here.

> I think the phrase "special meaning" needs some clarification.

If you have an idea of how to further clarify the above quoted
paragraph from the rfc2141bis draft (or any text in the rfc3188bis
draft), please suggest suitable replacement text (together with clear
enough editing instructions to allow us to correctly place it to
reflect your intent).

Note that any new text must be compatible with the original one
from RFC 2141 to avoid any doubt that rfc2141bis could break
URN Namespaces registered based on RFC 2141 (and RFC 3406).

> //Bengt

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+