Subject: [urn] Comments on WG Items

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 23 Dec 2010 11:23:15 +0200

Hello all,

I have reviewed the WG items (URN Syntax, URN Registration Procedures
and ISBN URN Namespace) and can provide some fedback.

==URN Syntax draft==
1. Abstaract
I think it should be more brief. I propose the following:
"This document specifies generic syntax for Unifirm Resource Names
(URNs), which stand as persistant, location-independent resource
identifiers. It obsoletes RFC 2141"
You may add additional info in Introduction. Proposed abstarcat
reflects what the documents is about clearly and briefly. What do you
think about this?
2. Introduction Section.
-I propose to replace the paragraph sequence so that it is: para2,
para3, para1. The most significant ones should go first, but now they
don't.
-Rename the Section 1.1 to 'Historical Overview of URNs'. And remove
paragraphs 1, 9, 10. We can put the ABNF convention into section 1.4.
Putting info about used BNF in previous specifications is odd, I
think.
-Remove paragraphs 2, 3, 5 in section 1.3. The, IMO, also give odd information.
-Rename section 1.4 to Convention and add there ABNF convention.
3. Syntax itself
-Remove ABNF convention from para 1 of section 2 (put in 1.4).
-ABNF nit: <NID> and <NSS> are capitalized, but only core rules are capitalized.
-Generic URI syntax - shouldn't we mention that only one segment is
allowed? we do not use nore than 1 segment in URNs.
-Why do we allow only 32 cahrs in NID? Do not we need more? (that is
question for discuss).
-As for form fo NID - I consider that to be OK (letters, digits and
hyphens only). If URNs are 'human-friendly' identifiers, the need to
be simple.
-Should we put @ in the allowed chars. Some software would interpret
that as e-mail address.
-If we restrict %00, we should put it into 'excluded' rule. Moreover,
let's put MUST requirement for 'excluded' rule as 'MUST not be used in
URNs'
4. Minor questions.
-Should we discuss the document at uri_review and [email-masked] mailing lists?
-If we reserve 'urn' NS, we should provide the template for it. (See below)
-Do we really need Appendix A?

==URN Registration procedures==
1. Abstract
It is really *too* long. I propose to remove paras 1 and 2.
2. Text of document
-Why we do not use ABNF on this document? It will allow to specify the
syntax of different types of URNs clearly.
-We should replace the sequence of paras 3.1, 3.2 and 3.3 (and the
same in s4) in the folowing way:
3.3, 3.2, 3.1. That is significance order.
-Shouldn't we create the subregistry for 'Historic' URN namespaces?
-Shouldn't we provide the possibility to withdarw the informal URN NS
registration?

==ISBN URN NS - will write later==

Finally, I think we should make a draft describing the 'urn' and
'exmple' UR NSs, to provide UANA clear registration guidelines for it.
What about it?

I hope my comments will be useful. Mostly these is qeustion to
discuss, so there will be some questions, exactly.You may feel free to
contact me at [email-masked] for further info.

All the best,
Mykyta Yevstifeyev

---

From: Alfred Hönes <[email-masked]>
Date: Thu, 23 Dec 2010 15:27:15 +0100 (MEZ)

Mykyta,
thanks for taking time and your comments.

> ...

I split my initial answers to allow separate threads for the different
drafts to emerge, which will make it easier to follow (and later:
evaluate) the discusion on a particular draft.

Here are a few general remarks that should be considered by all WG
participants:

a)  We hope and expect various interested people to join the WG
    who do not have much background on the IETF, how it works,
    and on the history of current documents.

    In particular as a service to these these participants,
    but also to inform those that will have to evaluate the WG
    output once RFC publication is being requested, the current
    drafts include a lot of background information, which in a
    synopsis might be regarded as redundant.

    The intention clearly is to revisit this information before we
    proceed to WG last call.  However, to provide the above service
    to late newcomers for a while, I hesitate to heavily cut it
    down _now_.

    For example, Appendix A could eventually be removed from
    rfc2141bis unless the WG decides it is particularly useful
    for prospective writers of URN Namespace registration documents,
    which -- as experience has shown in the past -- frequently also
    are newcomers to the IETF and might find it valuable to have this
    information co-located with the specification they need to use
    as a base for their work.

b)  I'm -- to some degree -- also a newcomer to the matter.
    In particular, I haven't participated in the long-lasting,
    partly very controversial discussions that eventually lead to
    the RFCs we are now working from.
    However, there _are_ enough IETF participants, and in particular
    participants with a very strong standing in the community, who
    are very concerned and do not want that we revisit specific
    discussions and decisions that have been made in the past --
    if not for other reasons, at least for the sake of efficient
    progess in the WG.  This has become part of our WG charter,
    and we are well advised to follow this guidance.

    As a first corollary, this means that in the current drafts,
    as much text as possible has been carried over literally from
    the predecessor RFCs; changes have been made where the perspective
    has changed during a decade, where practice has evolved in a
    manner slightly diverging from the written green-table word,
    under the "silent consensus" of the community, or where new needs
    or requirements have emerged.
    (This includes changes in document structure, formatting, and
    style required or recommended by the RFC Style Guide and current
    RPC (RFC Production Center) practice, because I prefer to apply
    such changes in an early stage, so that late chages in the
    publication process are reduced to a minimum.)

    Therefore, If you propose changes to old text, please first check
    the necessity and compatibility.  There must be demonstrably good
    arguments for dropping or changing legacy text that has been the
    outcome of an onerous process in the past, sometimes with heated
    controversies.

c)  We always need to keep in mind the persitency properties of URNs.
    Therefore, we need to carefully evaluate that changes are made
    in a backwards compatible manner.  Two corollaries to this basic
    property:

    - any URN actually assigned under the rules of previous RFCs
      MUST remain valid under the updated specifications;

    - no URN namespace that once has been registered -- even it it's
      "only" an informal namespace -- can be removed unless it can be
      demonstrated that it never has been used or the entities once
      identified by such URNs have disappeared *and* there's no more
      need to identify these entities, _now and forever_.

Kind regards
  Alfred.

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 23 Dec 2010 17:53:21 +0200

Alfred, all,

Thank you for advices. So let me systematize my comments.

Firstly, IMO abstract gives too many information. What I am talking about?

> Uniform Resource Names (URNs) are intended to serve as persistent,
>     location-independent, resource identifiers.  This document serves as
>     the foundation of the 'urn' URI Scheme according toRFC 3986  <http://tools.ietf.org/html/rfc3986>  and sets
>     forward the canonical syntax for URNs, which subdivides URNs into
>     "namespaces".  A discussion of both existing legacy and new
>     namespaces and requirements for URN presentation and transmission are
>     presented.  Finally, there is a discussion of URN equivalence and how
>     to determine it.  This document supersedesRFC 2141  <http://tools.ietf.org/html/rfc2141>.
>
>     The requirements and procedures for URN Namespace registration
>     documents are currently set forth inRFC 3406  <http://tools.ietf.org/html/rfc3406>, which is also being
>     updated by a companion, revised specification dubbed RFC 3406bis.
The last paragraph does not concern the document text. Abstract should 
tell only about this document, but not others. Moreover, Why do we begin 
with the overview of designation of URNs. And why the sentence about 
'urn' URI scheme stands first here, after 'sets forward the canonical 
syntax for URNs'? Its title is 'URN Syntax', but not 'The urn URI 
scheme'. Finally, why not use 'obsoletes' instead 'supersedes'? It is 
current practice in RFCs, I think.

What is more, the same is with Introduction. We should put the most 
significant paragraphs first, so I proposed to put the in the following 
order: 2, 3, 1.

Next, why do we put ABNF convention into 'Historical Overview'? We 
should put such note into section 1.4, that may be renamed to 
'Conventions'. But even now, the note about ABNF is in section 2 too - 
appears twice. Such information, I think, should appear only once.

As for syntax. I wonder why do we allow only 32 chars in NID? Isn't that 
little amount? What is more, I also wonder why do we put "@" into 
allowed chars? For instance, we have URN urn:x-abc:foo:[email-masked]
It is synthetically correct. But look, it is recognized as e-mail 
address (tested in Thunderbird 3.1.7). Shouldn't we move "@" to 'excluded'?

Moreover, IMO there will be no harm if "&" and "~" will be allowed. Why 
do we think that while others are allowed, these should be restricted. 
As I know, they are not used to separate URI parts (maybe occasionally 
in query, but that is part of query), so can be allowed in URNs.

And as for 'excluded' rule, there must be put the %00 NUL octet as not 
used in URNs, if we restrict its using.  Moreover, IMO there should be 
put the MUST requirement there as 'MUST NOT be used in URN NSSs'. 
Another minor comment is that only core rules, according to RFC 5234 are 
capitalized while we have rules named 'NID' and 'NSS'.

Lastly, I consider that to be useful to discuss the draft (maybe not in 
early stages, but later) at [email-masked] mailing list (and even 
occasionally at [email-masked]).

All the best,
Mykyta Yevstifeyev

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 23 Dec 2010 18:12:09 +0200

Hello all,

Let me describe my suggestion more clearly.

Is there a sense in such long abstract. There are mostly what is to be 
put into Introduction. I propose the following one:

>     This document serves as a guidleline for authors of URN Namespace
>     definition and registration documents.  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.  Further, this RFC describes the process to
>     be followed to get a URN Namespace registered with IANA.
>
>     It obsoletesRFC 3406  <http://tools.ietf.org/html/rfc3406>.

i. e. only two last paragraphs. Maybe it would be better to use the term 
'URN Namespace Identifier Name', as namespace itself is not what is 
specified.

I also wonder why ABNF is not used in this document. For instance, the 
experimental NID could be described as:

experiment_nid   = "X-" 1*URN-char
URN-char             =<defined in ......>

or smth like this. That will provide clear guidelines to registrants, IMO.

What is more, I propose to create a 'Reserved NID Names' sub-registry 
for that NID Names that are not to be used at all. There could be put 
'urn', 'uri', 'iri', etc. (see my previous messages). I do not consider 
the sentence 'IANA is asked to add a note to [IANA-URN] that 'urn' is a 
permanently reserved formal namespace identifier string that cannot be 
registered, in order to avoid confusion with the 'urn' URI scheme.' to 
be appropriate. If there is defined procedure for registering URN NIDs, 
we should follow it or create separate one for reserved names (as a 
propose).

As minor comments, that seems to be a grammar mistake:
> the author of which *are*
And also I wonder why while describing types of URN NIDs, we put firstly 
Experimental, than Informal and lastly Formal (sections 3 and 4). Not 
vice versa?

However these are *not all* comments for this document. I'll try to 
review it more carefully and make some other comments ASAP. You may feel 
free to contact me for further info.

All the best,
Mykyta Yevstifeyev

23.12.2010 11:23, Mykyta Yevstifeyev wrote:
> [......]
> [......]