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
> When constructed the "TLS-Report-Submitter" value MUST match the value in
> 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.
Uta mailing list