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

[Alexey Melnikov <[e-mail]>]

Hi Paul,

> On 19 Sep 2017, at 21:02, Paul Kyzivat <[e-mail]> wrote:
> 
>> 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.

On my memory most of new header fields are defined without extending "optional-field" production. So people are already doing what you propose.

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

Right.

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