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

[Leslie Daigle <[e-mail]>]

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?

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 [e-mail] -----
>
>> From: [e-mail]
>> To: [e-mail]
>> Message-Id:<[e-mail]>
>> 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 [e-mail] -----
>
>
>
> --------  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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/urn

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[e-mail]
-------------------------------------------------------------------