Re: [Gen-art] Gen-ART Last Call review of draft-baeuerle-netnews-cancel-lock-05

[Paul Kyzivat <[e-mail]>]

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
>