Re: ABNF nits

[Russ Allbery <[e-mail]>]

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

> | 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.

Thanks, fixed.

> | ; CRLF UNDEFINED
> | ; SP UNDEFINED
> | ; newsgroup-name UNDEFINED
>
> That's IMO no okay.  Please import it:

The ABNF in USEPRO is additive to the ABNF in USEFOR and the Core Rules
defined in RFC5234 as noted in 1.4.

> : 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.

No, I mean what the text says.

   While a charset parameter is defined for this media type, most
   existing software does not understand MIME header fields or correctly
   handle descriptions in a variety of charsets.  Using a charset of US-
   ASCII where possible is therefore RECOMMENDED; if not possible, UTF-8
   [RFC3629] SHOULD be used.  Regardless of the charset used, the
   constraints of the above grammar MUST be met and the <newsgroup-name>
   MUST be represented in that charset using the same octets as would be
   used with a charset of US-ASCII.

> 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.

You'll have to convince the chairs to reopen this topic if you want to
make a change to the specification in this area, since that's not the
policy that we previously reached consensus on for how to handle Unicode.

> 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>.

Likewise here.  I don't care one way or the other about DEL, but making
substantive changes at this phase is just asking for trouble.  I'm willing
to drop it if there's clear consensus and the chair okays making that
change, but not otherwise, since we're trying to finish.

> 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>

I don't think it's necessary to note everywhere that we reference msg-id
that we mean the version defined in USEFOR.  I think the introduction to
the document covers that adequately.

> 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.

I don't think this is useful.  [USEFOR] is a much simpler search string to
use to find all instances that need to be corrected once the other draft
has been published.

> 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.

I don't, at present, intend to add an import interface.

> Related nits:  Please upgrade RFC 4234 to 5234 (STD 68).

Done.

> The USEAGE reference should get a proper URL.

Done, thanks.

> I found a trick to bypass the xml2rfc "work in progress" blurb:

They should have a work in progress blurb.  They're Internet-Drafts.  I
missed the <seriesInfo> tag here and for USEFOR; fixed.

The status of USEAGE needs to be resolved before publishing the document.
If it's not going to be published, we need to strip all references to
USEAGE in this document.  So having the work in progress tag is useful to
be sure that we do that.

> 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 didn't think that 2822upd breaks anything that wasn't already broken.
What are you worried about having break here?

> Last sentence in the intro of chapter 4, please add an exact
> reference to [RFC2046] section 5.2.1.

Done.

> 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.

I don't have time to do this at present and can make no promises as to
when I will have time to do so.

> 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.

I'm inclined not to bother with this unless people feel it would be
worthwhile.  It makes the draft longer and I don't think anyone's going to
care.

> 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.

Yeah, I don't know if this is okay or not either.  I can do whatever the
right thing to do here is.  Should I add all of the other template
attributes there?

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

I didn't; I just didn't change it.  This has been in the draft for quite a
while.  Should I remove it?  I don't see Disposition anywhere in the media
type registration either.

> 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.)

Thank you.  Charles had this right and I broke it; I'm now using
&rfc.number;, which seems like a good solution.

-- 
Russ Allbery ([e-mail])             <http://www.eyrie.org/~eagle/>