ABNF nits (was: I-D Action:draft-ietf-usefor-usepro-11.txt)

["Frank Ellermann" <[e-mail]>]

> Filename        : draft-ietf-usefor-usepro-11.txt
[...]
> Comments are solicited and should be addressed to
> the Usenet Format Working Group at [e-mail].

New tools trick, you can extract the ABNF as seen by 
http://tools.ietf.org/abnf/draft-ietf-usefor-usepro-11

Skipping two lines which are no ABNF I copied the
output and pasted it "as is" in Bill's ABNF parser.

| 11: moderation-flag     = SP "(" %4D.6F.64.65.72.61.74.65.64 ")"
|                                  ^
| 11:30: error: Illegal character '%' - skipping to end of line

ITYM %x, I manually fixed the input to check the effect.

| 17: control-command     =/ Newgroup-command
| 18: Newgroup-command    = "newgroup" Newgroup-arguments
|   ^
| 18:0: error: Rule control-command does not yet exist; treating /= as =

I manually added an "import" rule at the top like this:

: control-command  = <see [USEFOR] section 3.2.3>

After that it was at "no errors" listimg all undefined
and unused terms.  Bill's "canonical format" is a matter
of taste, but always intersting to see:

| ; CRLF UNDEFINED
| ; SP UNDEFINED
| ; newsgroup-name UNDEFINED

That's IMO no okay.  Please import it:

: newsgroup-name        = <see [USEFOR] section 3.1.4>

| ; HTAB UNDEFINED
| ; newsgroup-description UNDEFINED

That's an artefact of the ABNF extraction tool, I copied
the missing term manually to the ABNF input form field:

: newsgroup-description
:                     = eightbit-utext *( *WSP eightbit-utext )

| ; WSP UNDEFINED
| ; utext UNDEFINED

That's a real issue in the draft.  ITYM that it MUST be
<UTF8-non-ascii> as specified in RFC 3977, but servers
MUST in practice accept any octet.  How about this:

- eightbit-utext      = utext / %d127-255
+ eightbit-utext      = UTF8-non-ascii / %d128-255
+ UTF8-non-ascii      = <see RFC3977 section 9.8>
+
+ Note that <eightbit-utext> MUST be <UTF8-non-ascii>,
+ but for backwards compatibility servers MUST other
+ non-ASCII octets.

Technical detail, I omitted %d127 (DEL), because it is
not obviously needed.  Please spice it with a RFC 5198
reference to get NFC.  The EAI drafts do this, it is no
new untested idea.  BTW, they also use <UTF8-non-ascii>.

Back to the ABNF parser output:

| ; DIGIT UNDEFINED
| ; msg-id UNDEFINED

That is critical, various different definitions exist.
Please import the (here) relevant <msg-id> definition:

: msg-id                = <see [USEFOR] section 3.1.3>

Not RFC 3977 without "@", not RFC 2822 with NO-WS-CTL,
not RFC 2822upd allowing ">" (IIRC), and not RFC 1036.

It is a zoo, and for this round I hope to arrive at a
consistent story.  To align this with 2822upd I think
that a later RFC.ietf-usefor-usefor update would cover
all cages in the NetNews department of this zoo (down
to the news: URIs).

| ; path-identity UNDEFINED

: path-identity          = <see [USEFOR] section 3.1.5>

| ; control-command defined but not used
| ; groupinfo-body defined but not used
| ; checkgroups-body defined but not used
| ; sendme-body defined but not used

That's as it should be.  When you add the imported terms
you could also import the used STD 68 terms, as we did
it in RFC.ietf-usefor-usefor

Subtle point, instead of "[USEFOR]" please use "RFCnnnn"
in ABNF prose definitions, and add an RFC-editor note to
replace "yyyy" by the RFC number.

The very popular "rfcmarkup" tool can identify "RFCnnnn
section X.Y" as link to a section X.Y in RFCnnnn.  We're
not supposed to cuddle simple-minded tools in RFCs, but
in that case I think it is worth it, rfcmarkup-format is
used in RFC links by almost all MediaWiki installations.

You use a few ABNG terms like <verb> in the prose.  When
you add an "ABNF import interface" in chapter 1 please
import also those terms while you are at it.  IMHO this
helps to read (and maybe understand) non-trivial memos.

--------------------------------------------------------
Related nits:  Please upgrade RFC 4234 to 5234 (STD 68).
The USEAGE reference should get a proper URL.  I found
a trick to bypass the xml2rfc "work in progress" blurb:

<reference
  anchor='USEAGE'
  target='http://tools.ietf.org/html/draft-ietf-usefor-useage-01'>
  <front>
    <title>Usenet Best Practice</title>
    <author initials='C.' surname='Lindsey'
            fullname='Charles H. Lindsey'>
      <organization>University of Manchester</organization>
    </author>
    <date month='March' year='2005' />
  </front>
  <seriesInfo name='Internet' value='draft-ietf-usefor-useage-01' />
  <format type='TXT'
    target='http://tools.ietf.org/id/draft-ietf-usefor-useage-01' />
</reference>

The trick in this reference is <seriesInfo name="Internet" ...
(Tested in the news: URI RFC for the historical Gilman draft.)

Maybe add an RFC editor note that "2822" instead of "2822upd"
is as it should be for reasons they don't need to care about
unless they are willing to read the complete USEFOR archive
as prerequisite for real explanations.

I'm surprised that you got away without a s-o-1036 reference,
but I'm not going to investigate how you pulled that stunt.

If it was only the lack of a ready made xml2rfc <reference>
check out the news: URI I-D xml source under .../home/test

------------------------------------------------------------
IANA business

Last sentence in the intro of chapter 4, please add an exact
reference to [RFC2046] section 5.2.1.  After EAI introduced
a new message/global these details matter.   Not being exact
could require an essay in the security considerations, but
we have no time for this potential fun.

Please post review requests for application/news-checkgroups,
application/news-transmission, and application/news-groupinfo
on the types review list.

If you already did that years ago I missed it, but I guess
we simply forgot to do this.  It is mostly "pro forma", but
sometimes the experts ask good questions resulting in fixed
registration templates.

Clearly I should post the review requests, because I think
they are required.  But I could not answer questions about
many application/news-* details.  AFAICT Harald is also in
the "required" camp.

For message/news I think you *could* add a new registration
template, because you modify not only the status, but also
the semantics ("use message/rfc822"), and the owner (IETF).

But maybe that is irrelevant and/or too late now.  If not:

: MIME type name:           message
: MIME subtype name:        news
: Required parameters:      none
: Optional parameters:      charset, compare message/rfc822
: Disposition:              by default, inline
: Encoding considerations:  compare message/rfc822 (RFC 2046)
: Security considerations:  OBSOLETE, use message/rfc822.
: Interoperability considerations:
:                           Rarely used; and therefore often
:                           handled as application/octet-stream
: Published specification:  son-of-1036, RFCXXXX
: Applications that use this media type:
:                           Some old mail and news user agents
: Intended usage:           OBSOLETE
: Author:                   Henry Spencer 
: Change controller:        IETF

Looking in RFC 4288 I found that you did not use some fields
in the other templates.  I can't tell if that is okay, e.g.,
IMO "change controller: IETF" is implied by standards track.

That's the point where you might need a proper [son-of-1036]
reference, grab it from one of the XML sources.  I think you
should not say "this specification" in any IANA template, 
they are supposed to store these templates on their server.

(What they do in practice is a diferent question, I did not
 find the old original message/news template spontaneously).

You can use the magic &rfc.number; in xml2rfc sources for
this purpose.  It expands to RFCXXXX in drafts, and to the
RFC number in AUTH48.  (Hopefully, I can't test this theory
before RFC.ietf-usefor-usefor RFC got its number.)

BTW, where did you find "Disposition" in RFC 4288 ?  It is
a good idea, but maybe it belongs to the "Interoperability".

 Frank