On 8/9/17 6:33 AM, Alexey Melnikov wrote: > Hi, > > (As a participant) > > > On 09/08/2017 14:07, Brotman, Alexander wrote: >> Jim, >> >> To be clear, you'd like to remove the headers (5.3) and filename >> (5.1) sections, and have all the filtering based solely on the >> subject that is specified in 5.3? > I don't think Jim made a convincing argument for removing new header > fields. From my personal experience writing IMAP based applications > that search for this information (e.g. to search and process "all > reports from a particular domain") is easier with new header fields > than doing a search on a Subject which has complicated structure. This > has nothing to do with whether the same mailbox receives multiple > types of email messages, this is still a useful functionality if a > particular mailbox receives only TLSRPT reports. > > As per my followup discussion with Jim libraries for generating > messages need to be able to add new header fields anyway. If people > have real world experience about whether this is problematic, I would > like to hear it. > > > Regarding filenames - I am ambivalent. If you need this information > somewhere, you will need to define new header fields as well.
I'll leave it up to the rough consensus of the WG. But my expectation is that the vast majority of TLSRPT mail will be directed to addresses only used for that purpose, and then piped directly into an agent that does something with them -- probably stuff the data into a database, which is then used to generate composite reports for the domain. IMAP won't be involved at all, and filtering will be done only by database lookups. If the same information from the body of the report is also contained in new header fields, message subject, or attachment filename, the specification needs to be clear about what happens when they don't agree: does the recipient discard reports that are inconsistent, and if not, which values are used? IMO, it's more straightforward to keep this simple and have the information in only one place. > >> And relating to "draft-ietf-dnsop-attrleaf", could you clarify >> that a bit? Are you asking me to request an alteration of the >> attrleaf document after TLSRPT has been created? > (As Area Director) > Yes. Depending on which documents gets to IESG first, the last one > should include the information. +1. Or if attrleaf goes first, TLSRPT requests an entry in the registry that attrleaf created. -Jim _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
