draft-steidl-newsml-urn-rfc3085bis-00

Alfred Hönes <ah@TR-Sys.de> Thu, 24 September 2009 10:17 UTC

Return-Path: <A.Hoenes@TR-Sys.de>
X-Original-To: urn-nid@core3.amsl.com
Delivered-To: urn-nid@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C941C3A68DA for <urn-nid@core3.amsl.com>; Thu, 24 Sep 2009 03:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.189
X-Spam-Level: **
X-Spam-Status: No, score=2.189 tagged_above=-999 required=5 tests=[AWL=0.938, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E28d99nZ2ARf for <urn-nid@core3.amsl.com>; Thu, 24 Sep 2009 03:17:15 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 517BA3A6898 for <urn-nid@ietf.org>; Thu, 24 Sep 2009 03:17:14 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA112017463; Thu, 24 Sep 2009 12:17:43 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id MAA07540; Thu, 24 Sep 2009 12:17:38 +0200 (MESZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <200909241017.MAA07540@TR-Sys.de>
Subject: draft-steidl-newsml-urn-rfc3085bis-00
To: mdirector@iptc.org, Jayson.Lorenzen@businesswire.com
Date: Thu, 24 Sep 2009 12:17:37 +0200
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 8bit
Cc: urn-nid@ietf.org
X-BeenThere: urn-nid@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <urn-nid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn-nid>
List-Post: <mailto:urn-nid@ietf.org>
List-Help: <mailto:urn-nid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Sep 2009 10:17:16 -0000

Hello,
I apologize for the belated review, but hopefully the remarks
below still help further improving the draft.

These all address editorials and/or straighforward clarifications.


(1)  General -- citations

I suggest that you adopt the common style in IETF documents to
provide inline citations using the tags defined in the
References section(s), at least at the first occurrence of
a citation in the text, but even better at all 'important'
occurrences.

For instance, in the 1st para of Section 1:

   NewsML 1 and the G2-Standards specify XML formats for packaging
   multimedia news resources and items representing knowledge. [...]
---
   NewsML 1 [1] and the G2-Standards [2] specify XML formats for
   packaging multimedia news resources and items representing knowledge.
   [...]

More examples are included below without further explanation.

An Informative ref. entry for the RFC being obsoleted should be added;
I assume '[8]' being the outcome.  Then, in the 3rd para of Section 1:

|  This document obsoletes RFC 3085. The reasons for updating RFC 3085
   are:
---
|  This document obsoletes RFC 3085 [8].  The reasons for updating
   RFC 3085 are:


(2)  References

I suggest to make use of the recommended complete Reference entries
(including STD designations where appropriate) from rfc-ref.txt
(or the XML version thereof, if applicable to your drafting tools)
available from the RFC Editor web/ftp site.

Ref. [6] is outdated and should be replaced by a pointer to the
Full Standard version, RFC 5234.

In the prose, according to long-standing practice RFCs should always
be quoted with a single space between "RFC" and the RFC number.
So, if not using rfc-ref, please take care to manually
   s/RFC1035/RFC 1035/  in entry [7].


(3)  Section 1

In the last sentence of the 4th paragraph, I suggest to drop "RFC",
because the template is mainly for use by, and archival at, the IANA:

                              [...]. This includes meeting the formal
|  requirements of the new RFC template for URN registrations issued by
|  the IETF (RFC 3406).
---
                              [...].  This includes meeting the formal
|  requirements of the new template for URN registrations issued by the
|  IETF (RFC 3406 [5]).


(4)  Section 1 --> 2

I propose to move the final paragraph of Section 1 into Section 2,
where it gives an important (and unfortunately frequently omitted)
detail for the registration:

 2. Specification Template
|
|  This namespace specification is for a formal namespace.

The initial, 'identifying' clause in the template might be
simplified, dropping the unnecessary double-quotes and joining
the lines:

|  Namespace ID:
|
|     "newsml"
---
|  Namespace ID: newsml

(Doing so allows full text search operations with simple tools like
`grep` reveal more relevant key information from the memo at once.)


(5)  Section 2 -- ABNF related issues

The draft contains the ABNF line:

      month = ( 0 posdig ) / ( "1" ( "0" "1" "2" ) )

This would be equivalent to (by joining adjacent literal strings):

      month = ( 0 posdig ) / ( "1" ( "012" ) )

and hence

      month = ( 0 posdig ) / "1012"

... which certainly isn't what you want.  :-)

So please insert the alternation characters to make the line read

|     month = ( 0 posdig ) / ( "1" ( "0" / "1" / "2" ) )

Alternatively, and perhaps easier to comprehend for the human reader,
the alternatives could be spelled out fully (as for <day>), saving
lots of parentheses as well:

|     month = ( 0 posdig ) / "10" / "11" / "12"

To enhance the readability, I suggest to use columnar alignment
in the presentation of the ABNF.
For instance, incorporating the above change:

      NSS = ProviderId ":" DateId ":" NewsItemId
             [":" RevisionId][Update]
      ProviderId = string
      DateId = date
      NewsItemId = string
      RevisionId = posint
      Update = 0*1( "A" / "U" )
      date = century year month day
      century = ( "0" posdig ) / ( posdig DIGIT )
      year = 2DIGIT
      month = ( 0 posdig ) / ( "1" ( "0" "1" "2" ) )
      day = ( 0 posdig ) / ( ( "1" / "2" ) DIGIT ) / "30" / "31"
      string = 1*char
      char = ALPHA / DIGIT / symbol / escape
      symbol = "(" / ")" / "+" / "," / "-" / "." / "=" / "@" / ";" /
        "$" / "_" / "!" / "*" / "'"
      escape = "%" HEXDIG HEXDIG
      posint = posdig *DIGIT
      posdig = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
---
      NSS        = ProviderId ":" DateId ":" NewsItemId
                   [":" RevisionId] [Update]
      ProviderId = string
      DateId     = date
      NewsItemId = string
      RevisionId = posint
      Update     = 0*1( "A" / "U" )
      date       = century year month day
      century    = ( "0" posdig ) / ( posdig DIGIT )
      year       = 2DIGIT
      month      = ( 0 posdig ) / "10" / "11" / "12"
      day        = ( 0 posdig ) / ( ( "1" / "2" ) DIGIT ) / "30" / "31"
      string     = 1*char
      char       = ALPHA / DIGIT / symbol / escape
      symbol     = "(" / ")" / "+" / "," / "-" / "." / "=" / "@" / ";"
                 / "$" / "_" / "!" / "*" / "'"
      escape     = "%" HEXDIG HEXDIG
      posint     = posdig *DIGIT
      posdig     = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"

The ABNF RFCs, from the old RFC 2234 through the current
Full Standard revision, RFC 5234, recommend to disambiguate
(non-terminal) ABNF rule names when used in the prose by
enclosing them in angle brackets (as it was required in the
original BNF for the formal specification as well).
In particular, in a close vicinity to ABNF, is is confusing to
enclose some instances of rule names in qouble-quotes, which are
used to denote case-insensitive string literals in ABNF.

Thus the explanations in the draft below the ABNF should be modified
following the pattern shown below.  More instances to be addressed
appear in later clauses of the template.

(Note: After this kind of uniform 'markup' has been applied,
 as an additional step, it might be considered to downcase
 the rule names -- this is now performed below.)

|     ProviderId must be a registered Internet domain name [...]
---
|     <ProviderId> must be a registered Internet domain name [...]


|     DateId is a date in ISO 8601 Basic Format (CCYYMMDD), and must
         correspond to a date at which the organisation allocating the
         URN was the registered owner of the domain name specified in
|        the ProviderId.
---
|     <DateId> is a date in ISO 8601 Basic Format (CCYYMMDD), and must
         correspond to a date at which the organisation allocating the
         URN was the registered owner of the domain name specified in
|        the <ProviderId>.

...
...

|     Update: when associated with NewsML 1 news items, if the news item
|       contains one or more NewsML 1 "Update" elements, then Update
        must be set to "U".  If the news item consists only of a
|       replacement set of NewsML 1 NewsManagement data, then Update
        must be set to "A". If neither of these is the case, or if the
|       URN is not associated with a NewsML 1 news item, then Update
        must be omitted.
---
|     <Update>: when associated with NewsML 1 news items, if the news
        item contains one or more NewsML 1 "Update" elements, then
|       <Update> must be set to "U".  If the news item consists only of
|       a replacement set of NewsML 1 NewsManagement data, then <Update>
        must be set to "A".  If neither of these is the case, or if the
|       URN is not associated with a NewsML 1 news item, then <Update>
        must be omitted.

...
etc.
...


(6)  Section 3

The explanatory texts for all four examples are full sentences.
Thus, I recommend to add a trailing period (full-stop) to the end
of these sentences.


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| 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:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+