On 08/01/2017 10:17 PM, Leif Johansson wrote: > > On 2017-08-01 22:08, Jim Fenton wrote: >> >> I don't think I was suggesting anything involving Subject. There's >> already some of this in Section 5.3, and I'm not crazy about doing that >> either, especially since it's only a SHOULD (so the report recipient >> can't really depend on it being formatted that way). > On the contrary. A SHOULD basically means you follow the spec unless > you have a good reason not to do so.
In this case, you're depending on all of the domains that send TLS reports not to have a good reason not to do so. Maybe I'm just extra-careful, but I don't know what good reasons might come up (maybe some agent rewriting the Subject header field?) so I would be inclined to not depend on it. If this Subject header field formatting stands, is there some requirement that the requirement isn't a MUST (like the TLS-Report-* header fields)? Even so, recipients need to be able to handle any Subject header field that anyone throws at them, at least to discard those messages and not otherwise fail. For that reason, I think it's a good idea to minimize the number of things that require robust checking. Isn't this information in the payload of the report anyway? I'm not a fan of redundant information that can be inconsistent. -Jim _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
