Internet Message Store Events
draft-ietf-lemonade-msgevent-07
Yes
(Lisa Dusseault)
No Objection
(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Magnus Westerlund)
(Pasi Eronen)
(Ross Callon)
(Tim Polk)
Recuse
(Chris Newman)
Note: This ballot was opened for revision 07 and is now closed.
Lisa Dusseault Former IESG member
Yes
Yes
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2008-08-14)
Unknown
Given that the defined attributes do not contain interesting fields such as Subject or From, does it mean that this facility is only useful if you (a) intend to fetch every new message anyway or (b) always supply message content? I'd like to understand why the design is like this.
Lars Eggert Former IESG member
(was Discuss)
No Objection
No Objection
(2008-08-11)
Unknown
The LEMONADE charter says "The IAB is currently working on the specification of general guidelines and requirements for notification services. Once complete this work will be used as input to item 4 above." (Work item 4 is on notifications.) Has this IAB document materialized? The document doesn't refer to it at least, and the tracker has no shepherd writeup where I could find out about this. Section 4.2., paragraph 7: > The flagNames MUST not include \Recent. Using lowercase 'not' together with uppercase 'MUST' is not an accepted usage according to RFC 2119. Please use 'MUST NOT' (if that is what you mean). Section 5., paragraph 10: > The IP address of the message store access client which performed > the action which triggered the notification. Changing "the IP address" to "the IPv4 or IPv6 address" would make it clearer that both are allowed. Section 9.1., paragraph 3: > [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an > IANA Considerations Section in RFCs", BCP 26, RFC 2434, > October 1998. Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
()
Unknown
Chris Newman Former IESG member
Recuse
Recuse
()
Unknown