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

Marc Blanchet <marc.blanchet@viagenie.ca> Sun, 25 March 2012 13:07 UTC

Return-Path: <marc.blanchet@viagenie.ca>
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 E924E21F84B5 for <urn@ietfa.amsl.com>; Sun, 25 Mar 2012 06:07:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QowhFkAURvfO for <urn@ietfa.amsl.com>; Sun, 25 Mar 2012 06:07:33 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id D2E8521F84AF for <urn@ietf.org>; Sun, 25 Mar 2012 06:07:32 -0700 (PDT)
Received: from dhcp-51c6.meeting.ietf.org (dhcp-51c6.meeting.ietf.org [130.129.81.198]) by jazz.viagenie.ca (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 <marc.blanchet@viagenie.ca>
In-Reply-To: <4F6F1695.9090606@thinkingcat.com>
Date: Sun, 25 Mar 2012 15:07:30 +0200
Message-Id: <61D1B733-0575-4DDF-B2CB-CCEDC25BAC1F@viagenie.ca>
References: <201203122052.VAA22918@TR-Sys.de> <4F6F1695.9090606@thinkingcat.com>
To: Leslie Daigle <leslie@thinkingcat.com>
X-Mailer: Apple Mail (2.1257)
Cc: urn@ietf.org
Subject: Re: [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 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:
>>   <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?

- 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.

Marc.

> 
> 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:
>> <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
> 
> -- 
> 
> -------------------------------------------------------------------
> "Reality:
>     Yours to discover."
>                                -- ThinkingCat
> Leslie Daigle
> leslie@thinkingcat.com
> -------------------------------------------------------------------
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn