Re: ABNF nits

["Frank Ellermann" <nobody@xxxxxxxxxxxxxxxxx>]

Russ Allbery wrote:

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

Tools like the ABNF extractor don't know this, I think it's a
good idea to have an "import interface" also for human users.

The <control-command> continuation based on a start in USEFOR
is not obvious for folks not familiar with the details.  As
in say "IESG members, GenArt reviewers, or RFC-editor staff",
who might all try to check the ABNF "as is".  

I did *not* check what happens if the USEFOR + USEPRO syntax
is simply aggregated, maybe that is good enough.

 [utext]
> No, I mean what the text says.
[...]

I looked only at the ABNF, references, and stuff related to
the IANA templates.  SHOULD ASCII and otherwise SHOULD UTF-8
makes sense.  Checking the <utext> again I think you are not
talking about some "Unicode text", but about "unstructured
text" <utext> in RFC 2822 imported via RFC.ietf-usefor-usefor:

| utext   =       NO-WS-CTL /     ; Non white space controls
|                  %d33-126 /     ; The rest of US-ASCII
|                 obs-utext

Or actually about the non-obsolete part of RFC 2822 <utext>.

>From my POV that's not intuitive, especially because 2822upd
has no <utext> at all.  I propose to spell out what you want
here, in essence any MIME-compatible octet, that is not NUL,
and lots of fine print for CR LF.  You could simply write:

:  eightbit-utext = %d1-9 / %d11-12 / %d14-255

The name "eightbit-utext" is arguably confusing, at least it
managed to confuse me.  Please use <eightbit-mime> for this,
it would also reflect the "NOTE" at the begin of chapter 2.

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

I don't understand the last part "using the same octets as
would be used with a charset of US-ASCII".  What does this
mean ?  

Let's say the newsgroup-name is example.öko with an umlauted
o.  There are many ways to limit this to ASCII, oe, &ouml;,
percent-encoded UTF-8, numeric character references (NCRs,
i.e. Unicode points), IDNA punycode (but that won't fly for
some non-LDH ASCII group characters), RFC 2047, and more.  

>> Technical detail, I omitted %d127 (DEL), because it is not
>> obviously needed.  Please spice it with a RFC 5198
>> reference
[...]
 
> 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.

FWIW all but one %d127 uses in 2821bis drafts were removed.
We are quibbling about a non-issue, I didn't understand what
<utext> is.  See above for a better name and clearer syntax.

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

Agreed, I also don't think that it is necessary to note this
fact *everywhere*.  I proposed to note this *once* in syntax,
in an "import interface".  In prose you have it already, but
I didn't look at your prose for my ABNF validation.

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

I thought that you intend to keep [USEFOR] and [USEAGE] in the
prose.  If that's not the case forget my idea - it makes only
sense when you'd update [USEFOR] or rather RFCnnnn only in the
syntax, keeping [USEFOR] elsewhere as is.

Just in case, the drafts will be published simultaneously, they
have bidirectional normative references.

  [<verb> e.a.]
>> 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.

I recently added an import interface to a draft that needs no
syntax at all.  After that I finally began to understand what
this draft is about (= the other "u", not as in <utext>, but
as in U-label).

> The status of USEAGE needs to be resolved before publishing
> the document.

The WG will be terminated, and the USEAGE reference is only
informative...  

> If it's not going to be published, we need to strip all 
> references to USEAGE in this document.

...not required, and USEAGE won't be published anytime soon.

IMO nothing is wrong with an informative reference to prior
related work.  But saying that it's "work in progress" when
that's not the case (at the moment) could be bad.  The folks
at rfc-editor.org could decide to treat USEAGE as MISSREF...

[Actually I think they can't simply decide this, and that's
 the core idea of "normative" vs. "informative" references.]

> I didn't think that 2822upd breaks anything that wasn't 
> already broken. What are you worried about having break
> here?

The <utext> detail is interesting.  NO-WS-CTL was firmly
moved to "obs-cene".  IIRC no more <dcontent> (that was a
nit in 2821bis, no nit in usepro).  Various minor fixes
related to old 822 #-lists (all "obs" => irrelevant here).

 [review requests]
> 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.

Okay, sometimes the WG Chairs or the responsible AD do this
for WG drafts.  But doing it too late is sub-optimal, after
all a review request *could* trigger a no-nonsense review.

 [message/news template]
> 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.

Clearly I think it is worthwhile, because IANA cannot do much
to "obsolete" message/news without a template.  All they can
do without template is update their 1036 reference to USEPRO.

But it might be possible to submit the template individually,
should I try this ?  In that case I'd be at least confident 
about posting a review request "on behalf of the USEFOR WG",
e.g. I'd know that I can't say "on behalf of".

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

You could add an "Interoperability considerations" field, and
put the "default disposition inline" into this field.  Maybe
Charles still knows where he found this ?  (= not in RFC 4288)

For "message/news" I'd remove it as not more relevant if we
pick the "make it so" out-sourced IANA registration approach.

 Frank