Skip to main content

An Extensible Format for Email Feedback Reports
RFC 5965

Yes

(Alexey Melnikov)

No Objection

Lars Eggert
(Adrian Farrel)
(Dan Romascanu)
(Gonzalo Camarillo)
(Jari Arkko)
(Ralph Droms)
(Ron Bonica)
(Stewart Bryant)

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

Lars Eggert No Objection

(Alexey Melnikov; former steering group member) Yes

Yes ()

                            

(Peter Saint-Andre; former steering group member) (was Discuss) Yes

Yes (2010-05-18)
Cleared.

(Adrian Farrel; former steering group member) No Objection

No Objection ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(David Harrington; former steering group member) (was Discuss, No Objection) No Objection

No Objection (2010-05-19)
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

No Objection ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection ()

                            

(Ralph Droms; former steering group member) No Objection

No Objection ()

                            

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection (2010-05-19)
  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

No Objection (2010-05-18)
I support Tim's DISCUSS positions.

(Stewart Bryant; former steering group member) No Objection

No Objection ()

                            

(Tim Polk; former steering group member) (was No Record, Discuss) No Objection

No Objection (2010-05-18)
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.