Re: ABNF nits

[Russ Allbery <rra@xxxxxxxxxxxx>]

"Frank Ellermann" <nobody@xxxxxxxxxxxxxxxxx> writes:
> 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.

I'm sympathetic that this might be interesting in general for the IETF,
but in the absence of a general IETF policy or some standard about how
this is supposed to be done, I think this is just about the worst possible
working group to be innovating in how we present ABNF.  What we're doing
right now seems to be pretty much in line with what other RFCs are doing,
although I may have missed recent changes.

Is there something like that available, such as documentation of the
import syntax that you're using, in an RFC or a guideline for ABNF usage
somewhere?

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

I'm sorry to be uninformative here, but the points you are raising are
points previously discussed in the working group on an issue that was
closed.  In the interests of trying to shut this down, I'm going to
decline to discuss this issue unless the chairs determine that it should
be reopened.

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

Ah, yes, the [USEFOR] string will definitely change.  [USEAGE] is, from my
perspective, rather up in the air.

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

There are only two references to USEAGE in the document (3.8 and 3.9).
Personally, I think they're expendible.  If USEAGE isn't going to be
published, I think the best resolution is to just remove them.  I'd rather
not cite an I-D in a published RFC, and I suspect the RFC Editor would
have similar qualms.

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

I think it's definitely a good thing to do.  I just won't be able to do it
soon.  I might be able to do it towards the end of September; failing
that, I won't have a free block of time until November.  Unless there's
likely to be no discussion other than just the message, which of course is
simple, but usually that's not true of public IETF review.

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

That's a good point.

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

I'm very happy to either support that.  I can also include the template in
the document easily enough if the working group thinks that's the right
thing to do.  Does anyone else have an opinion?

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

Charles, do you remember?

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

I think it's worthwhile to explicitly deprecate it in the text of a
published RFC, personally, but maybe I'm too anal about that.

-- 
Russ Allbery (rra@xxxxxxxxxxxx)             <http://www.eyrie.org/~eagle/>