An Extensible Format for Email Feedback Reports
RFC 5965
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
Lars Eggert No Objection
(Alexey Melnikov; former steering group member) Yes
(Peter Saint-Andre; former steering group member) (was Discuss) Yes
Cleared.
(Adrian Farrel; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(David Harrington; former steering group member) (was Discuss, No Objection) No Objection
I support Tim's DISCUSS. in sectio 3.2, last paragraph, the historic field should also be accepted - why, if it is historic are we continuing its support here? what happens if a Recived-Date and an Arrival-Date bith exist, and are different?
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
The introduction says: > > This memo seeks to define a standard extensible format by creating > the "message/feedback-report" [MIME] type for these reports. > Two points. First, this specification defines the message/feedback- report. Please drop "seeks to". Second, the new MIME type is one part in the overall email feedback report, but talking about this one piece before talking about multipart/report in the introduction lead me to a different expectation. That incorrect expectation is corrected in the subsequent paragraph. A top-down ordering here would have helped me. Section 3.1 says: > > o "Version" indicates the version of specification that the report > generator is using to generate the report. The version number in > this specification is set to "0.1". [NOTE TO RFC EDITOR: This > should be changed to "1" at time of publication.] > Note that "0.1" is not valid under the Version ABNF definition.
(Sean Turner; former steering group member) No Objection
I support Tim's DISCUSS positions.
(Stewart Bryant; former steering group member) No Objection
(Tim Polk; former steering group member) (was No Record, Discuss) No Objection
It would be helpful (IMHO, anyway) if section 3 included a forward pointer to section 5 (extensibility). The content of section 3 does not indicate that a marf processor should expect to see unknown fields.