Re: [urn] IANA repository Re: New Version Notification for draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt (fwd)

Marc Blanchet <> Sun, 25 March 2012 13:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E924E21F84B5 for <>; Sun, 25 Mar 2012 06:07:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QowhFkAURvfO for <>; Sun, 25 Mar 2012 06:07:33 -0700 (PDT)
Received: from (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by (Postfix) with ESMTP id D2E8521F84AF for <>; Sun, 25 Mar 2012 06:07:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id B6AB2400DF; Sun, 25 Mar 2012 09:07:31 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_2F28597F-BA4A-4D4A-B369-B37F8CC07505"
From: Marc Blanchet <>
In-Reply-To: <>
Date: Sun, 25 Mar 2012 15:07:30 +0200
Message-Id: <>
References: <> <>
To: Leslie Daigle <>
X-Mailer: Apple Mail (2.1257)
Subject: Re: [urn] IANA repository Re: New Version Notification for draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt (fwd)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Revisions to URN RFCs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 25 Mar 2012 13:07:35 -0000

Le 2012-03-25 à 14:59, Leslie Daigle a écrit :

> Hi,
> Is this point in the document:
>>  [[ NOTE: It would be preferable to restore the generic, most
>>   universally supported (HTML) form of the registry be identified by an
>>   implementation-neutral URL, as previously supported by IANA:
>>   <>.  Yet, currently
>>   this URI and similar forms all resolve to an XML version.
>>   The content there should link to alternate forms (.xml, .txt), and
>>   those alternate versions should indicate the *other* versions; i.e.,
>>   where the .txt version (currently only available at ftp.IANA.ORG)
>>   also says, "This registry is also available in XML and plain text
>>   formats.", it should better say: "This registry is also available in
>>   HTML and XML formats."  Similarly, the XML form should point to the
>>   HTML and plain text forms. ]]
> actually a question for the URN document, or rather something for the IESG/IAB to explain or take up with IANA?  I.e., it seems to me that this is a broader question of references to IANA registries, and not just *this* reference to *an* IANA registry?

- actually, the note above (the extract from the document) is wrong.
 +  each XML registry has in the note: "This registry is also available in plain text."  and the .txt is available by http.
 + the html version is redundant. the xml version has xsl statement for browsers to render it in html on the fly. so no need to have a separate html page.


> Leslie.
> On 3/12/12 4:52 PM, Alfred � wrote:
>> URNbis colleagues,
>> [ speaking again as the document editor ]
>> I have just (in time) completed and uploaded an update to the
>> RFC 3406bis draft, one of our basic work items.
>> As usual, all related information, starting with the HTML-ized
>> version of the draft, and including diffs to the previous version
>> are available at:
>> <>
>> Please review the draft (and the changes) and focus your comments
>> on the remaining issues.  For your convenience, the change and
>> issue summaries contained in the draft are attached inline below,
>> after the forwarded draft announcement.
>> Unfortunately, list discussion has been interesting in the past,
>> but largely not very focussed on the draft text.
>> This has been summed up by Peter Saint-Andre his message
>> sent on "Wed, 11 Jan 2012 15:52:10 -0700" and archived at
>> <>,
>> which concluded with the question:
>>> In any case, what is the practical output of this discussion
>>> in terms of specification text?
>> I have to admit: not very much.    :-(
>> So please help the editor by giving focussed review comments and
>> proposed alternative text or text deltas for where you think
>> it is needed.
>> Kind regards
>>   Alfred.
>> ----- Forwarded message from -----
>>> From:
>>> To:
>>> Message-Id:<>
>>> Date: Mon, 12 Mar 2012 13:20:35 -0700
>>> Subject: New Version Notification for
>>>    draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt
>> A new version of I-D, draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt
>> has been successfully submitted by Alfred Hoenes and posted to the
>> IETF repository.
>> Filename:        draft-ietf-urnbis-rfc3406bis-urn-ns-reg
>> Revision:        02
>> Title:           Uniform Resource Name (URN) Namespace Definition Mechanisms
>> Creation date:   2012-03-12
>> WG ID:           urnbis
>> Number of pages: 30
>> Abstract:
>>    Uniform Resource Names (URNs) are intended to serve as persistent,
>>    location-independent, resource identifiers.  To structure and
>>    organize their usage, the URN syntax (RFC 2141bis) specifies a
>>    hierarchy that divides the set of possible URNs into "URN Namespaces"
>>    that can be individually defined and managed.  URN Namespaces in
>>    particular serve to map existing identifier systems into the URN
>>    system and thereby make available generic, network-based resolution
>>    services for the identified documents, artifacts, and other objects
>>    (and metadata related to them).
>>    To achive these goals, URN Namespaces need to be specified in a
>>    comparable manner, and their Namespace Identifiers (NIDs) need to be
>>    registered with IANA, so that naming conflicts are avoided and
>>    implementers of services can follow a structured approach in support
>>    of various namespaces, guided by the registry to the related
>>    documents and the particularities of specific namespaces, as
>>    described in these Namespace registration documents.
>>    This RFC serves as a guideline for authors of URN Namespace
>>    definition and registration documents and the process to be followed
>>    to register a URN Namespace with IANA.  It describes the essential
>>    content of such documents and how they shall be structured to allow
>>    readers familar with the scheme to quickly assess the properties of a
>>    specific URN Namespace.
>>    This document is a companion document to the revised URN Syntax
>>    specification, RFC 2141bis; it supersedes and replaces RFC 3406.
>> The IETF Secretariat
>> ----- End of forwarded message from -----
>> --------  begin of excerpt from draft --------
>> C.4.  Changes from URNbis WG I-D -01 to -02
>>    General text edits based on evaluation of meeting and on-list
>>    comments.
>>    Updated and tightened the organizatorial requirements for Formal
>>    Namespace requests.
>>    Restored additional IANA Considerations -- due to observed defects.
>>    Reserved NID strings "example.*" for documentation (as suggested by
>>    Larry Masinter, Peter Saint-Andre, and Julian Reschke).
>>    Added text on possible "higher level" methods to establish lexical
>>    equivalence of URNs, with the caveats that such things are rather
>>    unlikely to get traction in general-purpose client software.
>>    Removed historical Appendix B.1 (Example Template).
>>    Various editorial enhancements and fixes.
>>    Updated and expanded "Issues" Appendix (below) in preparation of
>>    usage of the IETF Issue Tracker.
>> Appendix D.  Issues in this Draft
>>    [ Appendix to be replaced by use of IETF Tools issue tracker. ]
>>    For more details on the issues below, please also see the Editorial
>>    Notes interspersed in the body of this draft.
>>    Discuss consequences of RFC 2141bis (once consensus is achieved); if
>>    proposal for fragment part is adopted, details need to be described
>>    per Namespace that wants to adopt these possibilities, and maybe the
>>    registration template needs a new clause where this will be specified
>>    -- or the information has to be assigned to existing clauses.
>>    Do registration documents need more guidance and be caused to be more
>>    precise in their elaboration on the applicability of Services?  Since
>>    RFC 2483 is considered outdated, but RFC 2483bis not yet alife (nor a
>>    URNbis work item), we might need a registry for URN Services
>>    (initially populated from RFC 2483) that can be referred to in
>>    Namespace registration documents, thus avoiding normative
>>    dependencies on a future RFC 2483bis.
>>    Do we actually need Experimental Namespaces?
>>    [Regarded as CLOSED affirmatively at IETF 80.]
>>    There are concerns regarding usage of "X-" NIDs, which is reported to
>>    having proven impractical in practice.  This draft version contains
>>    tentative text to address these concerns; "X-" is now demoted to
>>    "SHOULD" level.
>>    The syntax of the NID strings for the various NID types is given in
>>    an informal manner (as has been done in RFC 3406); is it worth the
>>    effort to introduce ABNF for this purpose?
>>    [The request for ABNF has been voiced only once; the document Editor
>>    regards this issue as CLOSED.]
>>    Increase review/timeout periods for urn-nid list and IANA experts
>>    from 2 to 4 (or more) weeks?  This draft version tentatively
>>    specifies 4 weeks.
>>    Juha Hakala has argued that the assessment of the responsible
>>    organizations needed to assure their ability to properly operate the
>>    Namespace could never be performed within the present 2 weeks time
>>    span; 8 weeks might be an even better choice for the future upper
>>    limit for the review period.  It has been pointed out that even 8
>>    weeks are miniscule with regard to the expected lifetime of the to-
>>    be-registered Namespace and hence should not matter.  In practice,
>>    the subsequent IESG evaluation of URN Namespace registration
>>    documents has typically needed much longer time.
>>    Clarification of the desired content of the "Namespace
>>    Considerations" and "Community Considerations" sections in
>>    registration documents.  Shall we admit a combined section for both
>>    topics? (so far supported by 2 postings) Cf. the NOTEs in Sections
>>    4.4.1 and 4.4.2 for more details.
>>    [No feedback on the list since -01, so the draft text seems to have
>>    silent consensus and the issue is regarded as CLOSED.]
>>    Shall other strings beyond "urn" also be 'reserved' in the NID
>>    registry? (e.g. "uri", "url", "urc", ...)  There have been voices in
>>    favor of leaving the decision of what is acceptable and reasonable in
>>    practice to the common sense of prospective registrants and the
>>    designated IANA experts.  This draft version reserves NID strings
>>    matching the RE "^example.*" for documentation.
>>    Appendix A: Once RFC 2483 gets updated and an IANA registry for URN
>>    resolution services gets established, the "Process for identifier
>>    resolution" clause in the registration template should call out for
>>    enumerating the registered services that are applicable for the newly
>>    defined URN Namespace.
>>    How far can we go in this respect without an update to RFC 2483 at
>>    hands?
>>    Do we really still need Appendix B.1 ?  (There are lots of real-life
>>    examples now!)
>>    [ Old B.1 removed, old B.2 became Appendix B; ==>  CLOSED ]
>> --------  end of excerpt from draft  --------
>> _______________________________________________
>> urn mailing list
> -- 
> -------------------------------------------------------------------
> "Reality:
>     Yours to discover."
>                                -- ThinkingCat
> Leslie Daigle
> -------------------------------------------------------------------
> _______________________________________________
> urn mailing list