[Uri-review] draft-larmouth-oid-iri-01 editorials

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

Hello,
I have followed up to the long expected update to your OID URI scheme
draft, draft-larmouth-oid-iri-01, and have a bunch of editorial
remarks.

(1)  Abstract -- spurious word duplication?

I did not really understand the second sentence, but my final
conclusion (based on the observation of more text duplication
in the draft) is that the last 3 words should simply be deleted:

   This internet draft defines the IRI/URI scheme for International
   Object Identifiers.  The syntax and semantics of the IRI is specified
   below using the International Object Identifier tree specified in
|  ITU-T X.660 International Object Identifiers.
---
   This internet draft defines the IRI/URI scheme for International
   Object Identifiers.  The syntax and semantics of the IRI is specified
   below using the International Object Identifier tree specified in
|  ITU-T X.660.


(2)  Section 1

(2a)  1st para

The draft says:

   The International Object Identifier tree [ITU-T X.660] provides a
|  hierarchically based identification scheme for objects/resources,
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   using almost all Unicode/ISO 10646 characters to identify arcs in the
   tree.  [...]

The use of "based" in this context without designating the base does
not make proper sense to me.
Thus, again I suggest to simplify the language:

   The International Object Identifier tree [ITU-T X.660] provides a
|  hierarchical identification scheme for objects/resources, using
              ^^
   almost all Unicode/ISO 10646 characters to identify arcs in the tree.
   [...]

(2b)  3rd para

For improved readability, I suggest to add a comma as indicated
below; also, I'd insert a hyphen in "% encoding" (or spell it out:
"percent-encoding") :

   [...]
   For ITU-T purposes, it is essential to be able to use names in any
|  language as well as numbers, without resort to any %-encoding or
                                v                      ^
|  restriction to numeric values, where an IRI can be used.  [...]

(2c)  6th para

I suggest to enhance the readability by swapping detailed references.
The first instance is in this paragraph:

      ... [RFC3987], Section 3.1 ...
---
      ... Section 3.1 of [RFC3987] ...

A Similar change should be applied in the last para of section 2.1.

(2d)  7th and 8th para -- duplicate text

These two paragraphs are (up to the additional paragraph break)
a literal repetition of the 3rd para:

|  There has been in existence for some time a URN scheme of "urn:oid",
|  but this is based entirely on numeric identification of each arc.
|
|  For ITU-T purposes, it is essential to be able to use names in any
|  [...]
|  A separate new 'oid' IRI scheme was considered far preferable.

Please strike out both paragraphs!


(3)  Section 2.1

(3a)  1st para -- typo in citation (spurious spacing)

The ref tag for the ABNF RFC contains a spurious blank
[ proof of non-use of xml2rfc!  :-) ].
Please correct:   s/[RFC 5234]/[RFC5234]/

(3b)  1st para -- missref

The internal pointer has not been adjusted during the restructuring
of the memo.  Please correct:     s/2.5/2.2/

(3c)  ABNF spec

According to RFC 5234, the  '<...>'  notation for ABNF non-termoinals
should be used in the prose and avoided in the formal ABNF.
Therefore, I suggest to remove the angle braces, including the
clerical error introduced in the course of their introduction.
Furthermore, columnar alignment and some more indentation for the
ABNF 'code' would perhaps improve the readability and make that
 important part more outstanding.

|  <oidiri> = "oid:/" <firstarcid> <subsequentarcid>
|  <firstarcid> = <unicodelabel>
|  <subsequentarcid> = 0*("/" <unicodelabel&gt);
|  <unicodelabel> = 1*(<iunreserved>)
---
|     oidiri          = "oid:/" firstarcid subsequentarcid
|     firstarcid      = unicodelabel
|     subsequentarcid = 0*("/" unicodelabel);
|     unicodelabel    = 1*(iunreserved)

(3d)  last para

See (2c) and (3a) above:

     ... [RFC 3987], Section 3.1 ...
---
     ... Section 3.1 of [RFC3987] ...


(4)  Section 2.4

Please supply the missing trailing period at the end of the last para.


(5)  Section 4.1

(5a)  1st para

I suggest be be more explicit regarding the expected IANA action:

|  (The IANA Registration Template is in 4.2)
---
|  IANA is asked to register the IRI/URI scheme 'oid' on behalf of this
|  document, using the IANA Registration Template [RFC4395] presented in
|  Section 4.2.

(5b)  3rd para

As in (3a) above:    s/[RFC 2434]/[RFC2434]/


(6)  Section 4.2

I suggest to enhance the readability by use of indentation of the
continuation lines (for "Applications ..." and "Contact:".


(7)  Section 6

It looks like ref. [ORS] is not publicly available -- at least
it is (currently) not listed on
 <http://standards.ISO.ORG/ittf/PubliclyAvailableStandards/index.html>.

This might be an obstacle for wide-spread adoption, and will
definitely exclude its use as a Normative Reference.
However, it looks like this ref. can be demoted to Informative
without negatively affecting the specification of the URI scheme.
Yet, it would be interesting to learn how the indicated use of the
DNS for [ORS] is managed.


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+