Hi Paul, > On 19 Sep 2017, at 21:02, Paul Kyzivat <pkyzi...@alum.mit.edu> 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. - +1 (858)651-4478 > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
