RE: IANA URN registration enquiry - Rules for Lexical Equivalence of NSS

"DTG Registration" <registration@dtg.org.uk> Thu, 21 April 2011 15:48 UTC

Return-Path: <registration@dtg.org.uk>
X-Original-To: urn-nid@ietfc.amsl.com
Delivered-To: urn-nid@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 89448E07ED for <urn-nid@ietfc.amsl.com>; Thu, 21 Apr 2011 08:48:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNs66Jj5+MQG for <urn-nid@ietfc.amsl.com>; Thu, 21 Apr 2011 08:48:58 -0700 (PDT)
Received: from dtg.org.uk (mail1.dtg.org.uk [217.20.28.2]) by ietfc.amsl.com (Postfix) with ESMTP id 40D2DE065C for <urn-nid@apps.ietf.org>; Thu, 21 Apr 2011 08:48:57 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Subject: RE: IANA URN registration enquiry - Rules for Lexical Equivalence of NSS
Date: Thu, 21 Apr 2011 16:48:56 +0100
Message-ID: <A81C894800C709429D1973719CF7D336024B85FA@sbs.dtg.org.uk>
In-Reply-To: <4DAE5458.70309@stpeter.im>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: IANA URN registration enquiry - Rules for Lexical Equivalence of NSS
Thread-Index: AcwAO59YRp74WxXpSEmtOSQbipd+Mw==
References: <A81C894800C709429D1973719CF7D336024B8319@sbs.dtg.org.uk> <4DAE5458.70309@stpeter.im>
From: DTG Registration <registration@dtg.org.uk>
To: Peter Saint-Andre <stpeter@stpeter.im>, DTG Registration <registration@dtg.org.uk>
Cc: Dave Walton <dave.walton@echostar.com>, urn-nid@apps.ietf.org
X-BeenThere: urn-nid@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <urn-nid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn-nid>
List-Post: <mailto:urn-nid@ietf.org>
List-Help: <mailto:urn-nid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 15:48:59 -0000

Dear Peter,

Thank you for your answer, the information provided does still not make clear why NSS lexical equivalence rules are required, if the NSS is not registered with IANA. The text in RFC 3406 implies that NSS lexical equivalence rules are required as part of the NID registration, see extract below.

Rules for Lexical Equivalence of NSS part:

      [[ Editorial Note: This clause moved into vicinity of "syntax". ]]

      [[ Editorial Note: In the past, there has been iterated trouble in
      tentative registration documents with regard to what rules can be
      imposed for lexical equivalence.  Since the "urn:" prefix and the
      NID part both are invariably case-insensitive per RFC 3986 and RFC
      2141[bis], in order to avoid repeated confusion, this version of
      the template tentatively restricts this clause to only the NSS
      part of the new URN namespace definition documents. ]]

      {
      If there are particular algorithms for determining equivalence
      between two identifiers in the underlying namespace (and hence, in
      the URN string itself), rules can be provided here.

      Some examples include:
      -  equivalence between hyphenated and non-hyphenated groupings in
         the identifier string;
      -  equivalence between single-quotes and double-quotes;
      -  namespace-defined equivalences between specific characters,
         such as "character X with or without diacritic marks".

      Note that these are not normative statements for any kind of best
      practice for handling equivalences between characters; they are
      statements limited to reflecting the namespace's own rules.
      }

Perhaps I am unclear on the process after the urn has been successfully registered. Are NSS lexical equivalence rules stored and publicised by IANA, so that people wishing to make use of dtg defined resources know how to correctly address them?

Best regards,

Will Godfrey




-----Original Message-----
From: Peter Saint-Andre [mailto:stpeter@stpeter.im] 
Sent: 20 April 2011 04:35
To: DTG Registration
Cc: Benja Fallenstein; Ted Hardie; Dave Walton; urn-nid@apps.ietf.org
Subject: Re: IANA URN registration enquiry - Rules for Lexical Equivalence of NSS part - Email found in subject

On 4/19/11 3:25 AM, DTG Registration wrote:
> Hello,
> 
> When declaring rules for lexical equivalence of NSS part, is this
> section valid if only the URN NID is being registered with IANA?

I assume you're referring to Appendix A of RFC 3406. Because the entire
text of that document is about the registration of a namespace
identifier with IANA (or, to be precise, "the processes by which a
collection of identifiers satisfying certain constraints can become a
bona fide URN namespace by obtaining a NID"), it's not clear to me what
you mean by your question "is this section valid if only the URN NID is
being registered with IANA?" Only the NID is ever registered with IANA
because specific URNs under that NID are issued by the administrative
entity that registers the NID in the first place. However, part of the
process of registering a NID is specifying the rules for lexical
equivalence. As with the other requirements of RFC 3406, defining the
rules for lexical equivalence will help the administrative entity to
clarify its processes and procedures regarding URN issuance, and also
will help developers of software for handling the issued URNs to
implement consistent parsing algorithms.

Did I misunderstand your question?

Peter

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



The information in this email and any attachments is confidential, may be subject to copyright and is intended solely for the addressee (s). Access to this email by anyone else is unauthorised. If you are not the intended recipient, please notify the sender and delete this e-mail.  In this case, please note that copying, disseminating or taking any action in relation to the contents of this e-mail is strictly prohibited. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Digital TV Group. Digital TV Group cannot ensure that emails are virus-free and therefore accepts no liability for viruses that might be transferred by this email or any attachment.