Sieve Notification Mechanism: mailto
RFC 5436
Yes
No Objection
Note: This ballot was opened for revision 10 and is now closed.
Lars Eggert (was Discuss) No Objection
idnits complains about two instances of "MAY NOT", which isn't a valid RFC2119 term. I believe both can be replaced by MUST NOT.
(Chris Newman; former steering group member) Yes
Two fixes I believe would improve this document: 1. It "Updates: RFC 3834" because it changes the extension rules from IETF consensus to Specification Required. 2. The term "URI Header" is not defined anywhere. I assume it means "Header field name and value extracted from the mailto URI," but it might be a good idea to include that (or a similar) definition in this specification. Lisa: Who are you recommending as the expert reviewer for the new auto-submitted extension registry this creates?
(Lisa Dusseault; former steering group member) Yes
(Cullen Jennings; former steering group member) (was Discuss) No Objection
(Dan Romascanu; former steering group member) No Objection
The current IESG Write-up is replicating the whole PROTO shepherd write-up.
(David Ward; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Pasi Eronen; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Tim Polk; former steering group member) No Objection
The message composition guidelines in section 2.7 are very weak. As far as I can tell, the only field that is required to be included is the "Auto-Submitted: auto-notified" header field. Everything else is a SHOULD. Is that really the wg's intention?