Hi Paul,
Julien Élie has proposed a new syntax definition.
I was copied on his mail proposing a change to RFC5536, and that is
tentative. *This* document would of course require a similar change. Or
else it could extend that change, via something like
news-fields =/ cancel-lock / cancel-key
But that can only be done if there is actually a draft that revises 5536
that can then be referenced. Bottom line is that it seems there needs to
be some coordination of that fix with this draft.
Is a draft really needed?
In RFC 5536, I for instance read wording about taking into accounts errata:
2.3. MIME Conformance
User agents MUST meet the definition of MIME conformance in [RFC2049]
and MUST also support [RFC2231]. This level of MIME conformance
provides support for internationalization and multimedia in message
bodies [RFC2045], [RFC2046], and [RFC2231], and support for
internationalization of header fields [RFC2047] and [RFC2231]. Note
that [Errata] currently exist for [RFC2045], [RFC2046], [RFC2047] and
[RFC2231].
[Errata] "RFC Editor Errata",
<http://www.rfc-editor.org/errata.php>.
Maybe *this* document could have similar wording, like "it extends
news-fields defined in Section 3 of [RFC5536] amended with verified
erratum xxx".
Also note that, when referencing RFCs, the current RFC Editor's practice
is to link to <http://www.rfc-editor.org/info/rfc5536> (that provides a
link to the errata page).
Last but not least, for *this* document, if extending the ABNF grammar
of another RFC gives too much bargain, then why just *not* extend
anything and just define <cancel-lock> and <cancel-key> as-is?
Definition of Jabber-ID or DKIM-Signature header fields for instance do
not extend anything from RFC 5322 (mail):
https://tools.ietf.org/html/rfc7259
https://tools.ietf.org/html/rfc6376
--
Julien ÉLIE
« – Chef ! On vient !
– On se met en carré ?
– Non ! En bosquet ! » (Astérix)
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
