On 7/10/17 3:31 PM, Julien ÉLIE wrote:
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?
The problem is that if you are going to extend the definition of
news-fields (news-fields =/ ...), then you need some way to reference
the base definition that you are extending. If that is only in an
erratum then I don't know how you can reference it.
Perhaps you can find some way to make the two independent, but nothing
comes immediately to my mind.
Thanks,
Paul
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
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art