Re: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-02

Peter Saint-Andre <> Tue, 03 July 2012 19:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 985E611E81EC for <>; Tue, 3 Jul 2012 12:39:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.503
X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NXD6h-k3QH0j for <>; Tue, 3 Jul 2012 12:39:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8E91511E81EA for <>; Tue, 3 Jul 2012 12:39:35 -0700 (PDT)
Received: from [] (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id 6A86D4005A; Tue, 3 Jul 2012 13:58:00 -0600 (MDT)
Message-ID: <>
Date: Tue, 03 Jul 2012 13:39:42 -0600
From: Peter Saint-Andre <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: SM <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-02
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Revisions to URN RFCs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Jul 2012 19:39:36 -0000

On 6/27/12 5:17 PM, SM wrote:

> In Section 1.1:
>   "Since this RFC will be of particular interest for groups and
>    individuals that are interested in persistent identifiers in general
>    and not in continuous contact with the IETF and the RFC series, this
>    section gives a brief outline of the evolution of the matter over
>    time.  Appendix E gives hints on how to obtain RFCs and related
>    information."
> This is unnecessary.  if a person cannot find RFC XXXX, it's unlikely
> that the person would find this document.
>   "Registration procedures for URI Schemes originally had been laid down
>    in RFC 2717 [RFC2717] and guidelines for the related specification
>    documents were given in RFC 2718 [RFC2718].  These documents have
>    been obsoleted and consolidated into BCP 35, RFC 4395 [RFC4395], which
>    is based on, and aligned with, RFC 3986."
> The history of the registration procedures is not as important.  I
> suggest moving it into an appendix if the author wants to keep that
> information.  I found the text informative but most readers won't share
> that view.

At the least, I agree that moving this information to an appendix would
be better. I question whether it really belongs in this document at all.

> In Section 1.2:
>   "This section aims at quoting requirements as identified in the past;
>    it does not attempt to revise or redefine these requirements, but it
>    gives some hints where more than a decade of experience with URNs has
>    shed a different light on past views.  The citations below are given
>    here to make this document self-contained and avoid normative down-
>    references to old work."
> Such information might only be informative for a small subset of IETF
> participants.  People reading a document about URN syntax might find it
> confusing.  This this is a stylistic nit.  I suggest targeting the
> average reader.  Describe the properties of URNs and move the historical
> information to an appendix if the author would like to keep that.

I think Section 1.2 is positively misleading. Just say "High level
requirements for URNs can be found in RFC 1738."

> In Section 1.3:
>   "RFC 2141 does not seamlessly match current Internet Standards.  The
>    primary objective of this document is the alignment with the URI
>    standard [RFC3986] and URI Scheme guidelines [RFC4395], the ABNF
>    standard [RFC5234] and the current IANA Guidelines [RFC5226] in
>    general.
> The objective should be in the Introduction Section.  Move the
> Historical information to the section about history.
>   "For advancing the URN specification on the Internet Standards-Track,
>    it needs to be based on documents of comparable maturity.  Therefore,
>    to further advancements of the formal maturity level of this RFC, it
>    deliberately makes normative references only to documents at Full
>    Standard or Best Current Practice level."
> This above is not that useful in the context of this document.


I think all of Section 1 can be condensed into a few paragraphs instead
of multiple pages, and that (as SM noted) the entire document could
benefit from significant editing to remove unnecessary text.


Peter Saint-Andre