On 3/6/25 05:53, Murray S. Kucherawy wrote: > I think this is just a warning from the tool that can be safely ignored. > > No, I think it's right, you need RFC 7405 if you want to use the case > sensitivity extension to ABNF. > > You can either introduce the reference where you start using the "%s" > extension, or you could do a brief Section 1.1.2 that says something like: > > Formal language specifications in this document use ABNF [RFC 5234] as > augmented for case sensitivity by [RFC 7405]. We already have that in the Github version, but not in any released version of the draft: | ### Notation | | Certain properties of email messages described in this | document are referenced using notation found in [@?RFC5598] | (e.g., "RFC5322.From"). | | This specification uses the Augmented Backus-Naur Form | (ABNF) notation of [@!RFC5234] and [@!RFC7405]. Anyway, I think you're overestimating the smartness of the tool, as it only consider the ABNF pasted into the textarea. I just tried it again, and got the same complaints as before, without even parsing the document first. Reading the source code, this warning comes when it is invoked without the rfc7405 option set and a "%s" is encountered. https://github.com/ietf-tools/bap/blob/bd3d29d7e968af9b70b1b4d61fc4f3a526350d2d/parser.y#L427-L431 However, looking more closely at the output, what at first glance seemed like a repetition of the input, actually has useful information in it. ; dot-atom-text UNDEFINED ; domain UNDEFINED These references RFC5322 in a comment ; DIGIT UNDEFINED ; ALPHA UNDEFINED These are implicit Core Rules, and taking a cue from RFC5322, we could add: | The following primitive tokens that are used but | otherwise unspecified are taken from the "Core Rules" | of [@!RFC5234]: DIGIT, ALPHA. ; FWS UNDEFINED This is also from RFC5322, but not noted as such where we use it. ; domain-name UNDEFINED The draft text says: | The first domain-name indicates the DNS domain name about | which the report was generated. The second domain-name | indicates the DNS domain name representing the Mail | Receiver generating the report. It's clear what domain-name is supposed to be, but it being syntactically undefined is problematic. I suggest we add this to resolve it: domain-name = dot-atom-text ; from RFC5322 ; filename defined but not used ; dmarc-subject defined but not used These are the 'results' referred to in the text when defining how to construct a filename and the subject header, respectively. Daniel K. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
