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

Reply via email to