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

From: Alfred Hönes <[email-masked]>
Date: Mon, 12 Mar 2012 21:52:20 +0100 (MEZ)

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 [email-masked] -----

> From: [email-masked]
> To: [email-masked]
> Message-Id: <[email-masked]>
> 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 [email-masked] -----

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

---

From: Leslie Daigle <[email-masked]>
Date: Sun, 25 Mar 2012 08:59:01 -0400

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:
>> Message-Id:<[email-masked]>
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 25 Mar 2012 15:07:30 +0200

Le 2012-03-25 à 14:59, Leslie Daigle a écrit :

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

---

From: Alfred Hönes <[email-masked]>
Date: Sun, 25 Mar 2012 23:16:14 +0200 (MESZ)

Leslie,
thanks again for your feedback; see my remarks inline below.

> Is this point in the document:

Note to other readers:  This is in Section 6, IANA Considerations.

> just *this* reference to *an* IANA registry?

this Note is more or less the result of some frustration over
- first having useful conversation with IANA and seeing things (of
  admittedly more general impact) improved -- at least for the
  URN Namespace IANA registry,
- but several months later finding the improvements have been lost
  again.

Having it somehow back in the draft again, I wanted to hand the I-D
to IANA for a quick pre-evaluation (once some more issues in the
I-D have been resolved), and this way an independent inquiry to IANA
wrt the loss could be avoided.

I agree that the topic is general.
Personally having followed the consensus building regarding a few
IANA registries during the last couple of years, I thought that the
principle of a simple, media-neutral stable URI for IANA registries
that resolves to the most versatile presentation form of the registry
(i.e. [X]HTML) -- and from which the TXT and possible XML forms are
linked -- was consensual between IANA and IETF leadership.
Seeing the recent loss of the [X]HTML form of various registries and
.txt forms only being available via FTP now might indeed be an
indication that you are right that this should perhaps become
a topic for IAB/IESG to discuss with IANA.

> ... [snip]

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Alfred Hönes <[email-masked]>
Date: Sun, 25 Mar 2012 23:32:29 +0200 (MESZ)

Marc Blanchet wrote:

>   + each XML registry has in the note: "This registry is also
>     available in plain text."  and the .txt is available by http.

Marc,
the first statement may be correct, but I've seen examples of the
second being definitely not holding any more.

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

I do not agree.  This is not universally true.
For these registries, all I see in my browser is an offer to save
the .xml as a file, and hence I don't get a chance to click on
a link to an alternate format.
At least some of the supported .txt URIs seem to be non-intuitive;
e.g. you don't get the .txt form by appending ".txt" to the generic URI.

  Alfred.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Mar 2012 01:34:57 +0200

On 3/25/12 3:07 PM, Marc Blanchet wrote:
>>>   where the .txt version (currently only available at ftp.IANA.ORG
>>> <http://ftp.IANA.ORG>)
>  +  each XML registry has in the note: "This registry is also available
> in plain text
> <http://www.iana.org/assignments/urn-namespaces/urn-namespaces.txt>."
>  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.

Yes, this text is quite out of place in the document and needs to be
removed.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Mar 2012 01:37:01 +0200

> - but several months later finding the improvements have been lost

Venting your frustration in the IANA considerations of an I-D about URNs
is not the right approach.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/