Re: [urn] A comment on draft-ietf-urnbis-rfc2141bis-urn-02
Alfred Hönes <ah@TR-Sys.de> Wed, 14 March 2012 14:34 UTC
Return-Path: <A.Hoenes@TR-Sys.de>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19E021F854E for <urn@ietfa.amsl.com>; Wed, 14 Mar 2012 07:34:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.295
X-Spam-Level:
X-Spam-Status: No, score=-98.295 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqcNouPmIZkl for <urn@ietfa.amsl.com>; Wed, 14 Mar 2012 07:34:06 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id B999721F8512 for <urn@ietf.org>; Wed, 14 Mar 2012 07:34:04 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA181345575; Wed, 14 Mar 2012 15:32:55 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id PAA07222; Wed, 14 Mar 2012 15:32:53 +0100 (MEZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <201203141432.PAA07222@TR-Sys.de>
To: bengt.neiss@kb.se
Date: Wed, 14 Mar 2012 15:32:53 +0100
In-Reply-To: <F52230A186DA59469E8E21CF80FE6D4D0F24911E@SRVVM305.kb.local> from Bengt Neiss at Mar "14, " 2012 "08:36:12" am
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 7bit
Cc: urn@ietf.org
Subject: Re: [urn] A comment on draft-ietf-urnbis-rfc2141bis-urn-02
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Mar 2012 14:34:07 -0000
On 2012-03-14, Bengt Neiss wrote: > Hi all, > > 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 > > > "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? 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: > > "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. 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). > Regards, > > //Bengt > > --------------------------------------------------------- > Bengt Neiss > Kungl. Biblioteket / National Library of Sweden > Phone: +46 (0)10 709 35 41 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: ah@TR-Sys.de | +------------------------+--------------------------------------------+
- [urn] A comment on draft-ietf-urnbis-rfc2141bis-u… Bengt Neiss
- Re: [urn] A comment on draft-ietf-urnbis-rfc2141b… Alfred Hönes