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. - +1 (858)651-4478
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
