Re: [Gen-art] draft-baeuerle-netnews-cancel-lock-06 and RFCs 5536 & 5322

[Paul Kyzivat <[e-mail]>]

On 9/19/17 2:41 PM, Pete Resnick wrote:
> On 19 Sep 2017, at 9:23, Alexey Melnikov wrote:
> 
>             optional-field =/ *( approved /
>             archive /
>             control /
>             distribution /
>             expires /
>             followup-to /
>             injection-date /
>             injection-info /
>             lines /
>             newsgroups /
>             organization /
>             path /
>             summary /
>             supersedes /
>             user-agent /
>             xref )
> 
>         I see one issue with the above. <optional-field> appears *twice*
>         in the
>         definition of <fields> in 5322. I don't understand what the
>         intent was
>         there - whether it was a mistake or was trying to express
>         something that
>         I am missing.
> 
>     I believe it was entirely intentional. The first instance allows to add
>     new trace header fields (which should be kept together in groups), the
>     second allows adding other types of header fields.
> 
> Correct, that was the intention. In 5322, optional-field is a catchall 
> for any new header field, so you need one for new trace fields and one 
> for other fields. Otherwise, there's no way to put a new field between 
> two trace fields. This was a fix in 5322 from 2822.
> 
>         This really needs some further discussion. (E.g., should
>         the valid values for <optional-field> as used with trace be distinct
>         from those in its later appearance?
> 
>     Yes. It would have been better to have 2 separate productions, like
>     trace-optional-field and other-optional-field, but what Pete did seems
>     to be Ok.

This probably wasn't *too* bad as long as <optional-field> was simply 
defined as:

    optional-field  =   field-name ":" unstructured CRLF

Even then, ideally there should have been some words to indicate that 
the <field-name>s used as extensions for trace be disjoint from those 
used as non-trace extension headers.

It gets more ugly when we start to extends <optional-field> 
syntactically via =/. Now, when the syntax is evaluated the new header 
fields we are defining show up as explicitly syntactically valid in both 
places. :-(

> Yes, that might have been nice, but putting extensibility syntax 
> throughout the grammar starts to get ugly. (Imagine 
> resent-optional-field, originator-optional-field, etc.) I think just one 
> is fine.

Since there is an IANA registry, another possibility would be to not 
attempt to revise the syntax from 5322 at all. Instead, simply rely on 
the the extensibility already there via <optional-field> and register 
all the new header fields in the IANA registry. (Use ABNF to define the 
syntax of the individual new headers but not their linkage into the 
message.)

Then use text to specify conditions about where they may appear in a 
message.

	Thanks,
	Paul

>         This needs to be thrashed out with
>         mail experts before this fix is finalized. I don't know what
>         forum is
>         appropriate for that.
> 
>     I am not sure. Pete?
> 
> Probably ietf-822, but (a) I personally haven't read the list in a very 
> long time, and (b) I don't think there's anything terribly controversial 
> about the change.
> 
>         Ignoring that, I agree this change to 5536 would achieve the goal
>         without requiring a change in 5322, which is progress. However I
>         think a
>         tweak to the above would be be a bit cleaner:
> 
>         optional-field =/ approved /
>         archive /
>         control /
>         distribution /
>         expires /
>         followup-to /
>         injection-date /
>         injection-info /
>         lines /
>         newsgroups /
>         organization /
>         path /
>         summary /
>         supersedes /
>         user-agent /
>         xref
> 
>         This is definitely a better fix than I was suggesting. (Thank
>         you Pete!)
> 
>     Good.
> 
> You're very welcome. I am equally fine with Alexey and Julien's version:
> 
> |optional-field = <see RFC 5322 Section 3.6.8> news-fields = approved / 
> archive / control / distribution / expires / followup-to / 
> injection-date / injection-info / lines / newsgroups / organization / 
> path / summary / supersedes / user-agent / xref optional-field /= 
> newsfields |
> 
> pr
> -- 
> Pete Resnick http://www.qualcomm.com/~presnick/ 
> <http://www.qualcomm.com/%7Epresnick/>
> Qualcomm Technologies, Inc. - [phone]
>