Hi Viktor, many thanks to you for the deep review and thanks to authors for the update.
> > We uploaded a new version of the TLSRPT a few moments ago. The majority of > > the changes are meant to > address comments submitted by Viktor Dukhovni (https://www.ietf.org/mail- > archive/web/uta/current/msg02388.html). A rough list of changes: > > > > - Update to mime type > > - Add dnssec-required > > - TLSA record change > > - Change scale phrasing > > - Make source-of-truth language more clear > > - Change label vs labels > > - Add IP to report > > > > Please let us know if you have any further comments. Thank you. > > Thanks. Progress on most of the issues, but some nits remain or were > introduced (especially the MIME changes are not right yet): > > Section 4.4, page 11: example policy string: > > o "policy-string": A string representation of the policy, whether > TLSA record ([RFC6698] section 2.3) or MTA-STS policy. Examples: > TLSA: ""_25._tcp.mx.example.com. 3 0 1 \ 1F850A337E6DB9C609C522D13 > 6A475638CC43E1ED424F8EEC8513D747D1D085D)"" MTA-STS: ""version: > STSv1\nmode: report\nmx: mx1.example.com\nmx: \ > mx2.example.com\nmx: mx.backup-example.com\nmax_age: 12345678"" > > This was incompletely updated and the TLSA example is rather mangled. > This element lacks a proper grammar. The intention seems to be a string > of newline separated elements (I'd prefer a JSON array of strings). > Please provide a better example, and ideally some text describing the > syntax in a bit more detail. We are on the late stage of document processing, so, please provide a concrete wording that you are happy with. > Section 5.1, page 13: file format recommendation: > > This section provides an ABNF grammar for an element of the report > that is merely a convenience for when reports arrive in mailbox > read by a human postmaster who saves the attached reports manually. > > Such a specific prescription is unnecessary. Better text would just > indicate that each report's filename should ideally identify the > origin of the report and the policy domain plus a unique report id. Again, your suggestion? Remove the ABNF? Or just change RECOMMENDED to MAY (or to plain "may")? Please, be more specific. > The section ends with: > > For example, this > is a possible filename for the gzip file of a report to the Policy > Domain "example.net" from the Sending MTA "mail.sender.example.com": > > "mail.sender.example.com!example.net!1470013207!1470186007!001.json" > > But, if the file is indeed compressed, a more friendly file extension > would be ".json.gz" not ".json". I tend to agree with you here. What authors think? > The new version then confuses the MIME contexts of HTTPS and Email. > It is in HTTPS where "Content-Encoding" is supported, and so no > separate MIME type or MIME type parameter is needed to signal > compression. While Email has no support for "Content-Encoding" > and so it is there a "conversions = gzip" parameter could be > added to the Content-Type. > > In either case, there'd be no need for the "application/tlsrpt+gzip" > media type defined in Section 6.4. > > Bottom line it looks like the MIME changes were made in haste, and > are incomplete. Please take a closer look at these and decide whether > there's to be a single media type with compression signalled separately, > via Content-Encoding for HTTPS and a new "conversions" parameter (clearly > defined with the proper context) for email. Again, please provide the text. Otherwise the iterations update-review may last forever. Regards, Valery. > Please be less prescriptive about the email filename, it is not essential > to interoperability. If the draft is much less prescriptive about the > format of the message subject or attachment filename, there's probably > no need for section 5.6, as there is then no possibility to specify > conflicting metadata in what are essentially free-form courtesy fields > for human consumption. > > -- > Viktor. > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
