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.


Uta mailing list

Reply via email to