On 3/2/18 4:06 AM, Valery Smyslov wrote: > Hi Jim, > > just one comment: > >> Section 5.3 paragraph 3: "MUST match the value found in the filename" >> but the value in the filename is only a recommendation (section 5.1). I >> continue to lean toward not depending on values in other than the >> message body (single source of truth). > I believe that this section describes how the "TLS-Report-Submitter" is > filled in > by sender, not how it is checked by the receiver. Section 5.6. already states > that the report body is the only authoritative source for receiver. > I agree that the current wording is a confusing and can be improved. For > example: > > When constructed the "TLS-Report-Submitter" value MUST match the value in > the > filename (if it is present there) and the [RFC5321] domain from the > "contact-info" from the > report body. These message headers MUST be included and should allow > for easy searching for all reports submitted by a report domain or a > particular submitter, for example in IMAP [RFC3501]:
My opinion is that since section 5.6 effectively says the filename (and therefore the TLS-Report-Submitter) doesn't matter because only the body is authoritative, the MUST requirements are excessive. I do see the value of the TLS-Report-Submitter header field as a convenience feature for the IMAP search usage that was mentioned, so I would say that it SHOULD match the body. I agree with Viktor's comment that the filename should be treated as an opaque string. Setting specific requirements for it only makes the protocol more brittle, and as he points out, how and whether the filename is used is implementation-dependent anyway. -Jim _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta