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

[Alfred Hönes <[e-mail]>]

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