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
- [urn] New Version Notification for draft-ietf-urn… Alfred Hönes
- [urn] IANA repository Re: New Version Notificatio… Leslie Daigle
- Re: [urn] IANA repository Re: New Version Notific… Marc Blanchet
- Re: [urn] IANA repository ... draft-ietf-urnbis-r… Alfred Hönes
- Re: [urn] IANA repository ... draft-ietf-urnbis-r… Alfred Hönes
- Re: [urn] IANA repository Re: New Version Notific… Peter Saint-Andre
- Re: [urn] IANA repository ... draft-ietf-urnbis-r… Peter Saint-Andre