An Extensible Format for Email Feedback Reports
RFC 5965

Note: This ballot was opened for revision 06 and is now closed.

Alexey Melnikov Yes

(Peter Saint-Andre) (was Discuss) Yes

Comment (2010-05-18 for -)
No email
send info
Cleared.

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Lars Eggert) No Objection

(Adrian Farrel) No Objection

(David Harrington) (was Discuss, No Objection) No Objection

Comment (2010-05-19 for -)
No email
send info
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?

(Russ Housley) No Objection

Comment (2010-05-19 for -)
No email
send info
  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.

(Tim Polk) (was No Record, Discuss) No Objection

Comment (2010-05-18)
No email
send info
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.

(Dan Romascanu) No Objection

(Sean Turner) No Objection

Comment (2010-05-18 for -)
No email
send info
I support Tim's DISCUSS positions.