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

Leslie Daigle <leslie@thinkingcat.com> Sun, 25 March 2012 12:59 UTC

Return-Path: <leslie@thinkingcat.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8F0CA21F84A0 for <urn@ietfa.amsl.com>; Sun, 25 Mar 2012 05:59:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 0UsGNpyR10c4 for <urn@ietfa.amsl.com>; Sun, 25 Mar 2012 05:59:27 -0700 (PDT)
Received: from zeke.ecotroph.net (zeke.ecotroph.net []) by ietfa.amsl.com (Postfix) with ESMTP id A45EB21F8483 for <urn@ietf.org>; Sun, 25 Mar 2012 05:59:25 -0700 (PDT)
Received: from dhcp-4553.meeting.ietf.org ([::ffff:]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Sun, 25 Mar 2012 08:59:04 -0400 id 015B40D8.4F6F1698.00006F0A
Message-ID: <4F6F1695.9090606@thinkingcat.com>
Date: Sun, 25 Mar 2012 08:59:01 -0400
From: Leslie Daigle <leslie@thinkingcat.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: urn@ietf.org
References: <201203122052.VAA22918@TR-Sys.de>
In-Reply-To: <201203122052.VAA22918@TR-Sys.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: [urn] IANA repository Re: New Version Notification for draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt (fwd)
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: Sun, 25 Mar 2012 12:59:28 -0000


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:
>    <http://www.iana.org/assignments/urn-namespaces>.  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?


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:
> <http://tools.ietf.org/html/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02>
> 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
> <http://www.ietf.org/mail-archive/web/urn/current/msg01672.html>,
> 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 internet-drafts@ietf.org -----
>> From: internet-drafts@ietf.org
>> To: ah@TR-Sys.de
>> Message-Id:<20120312202035.21803.80702.idtracker@ietfa.amsl.com>
>> 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 internet-drafts@ietf.org -----
> --------  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
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn


      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle