Internet Message Store Events
RFC 5423

Received changes through RFC Editor sync (changed abstract to 'One of the missing features in the existing Internet mail and messaging standards is a facility for server-to-server and server-to- client event notifications related to message store events. As the scope of Internet mail expands to support more diverse media (such as voice mail) and devices (such as cell phones) and to provide rich interactions with other services (such as web portals and legal compliance systems), the need for an interoperable notification system increases. This document attempts to enumerate the types of events that interest real-world consumers of such a system.

This document describes events and event parameters that are useful for several cases, including notification to administrative systems and end users. This is not intended as a replacement for a message access facility such as IMAP. [STANDARDS-TRACK]')

[Ballot comment]
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.

[Ballot discuss]
In general, a well-written document; however, there are couple
of places that would benefit from some clarification:

The level of detail in the parameter descriptions (Section 5) varies a
lot -- some specify an exact character/octet string encoding, others
just the information on general level. Section 5 should probably
explicitly say which of these are intended to be precise
specifications, and for which parameters, the exact encoding is left
to future documents (specifying the notification system protocols).
(Also noted in Richard Barnes's SecDir review)

Section 4.4: the terms "subscribe" and "subscription" are used with
many different meanings in email contexts (e.g. mailing list
subscription, IMAP subscribe, event subscription); the text should
explicitly say which of these is meant for MailboxSubscribe etc.
(this is probably obvious to the authors, but not to me :)

Section 5, "timestamp": is this when the notification was generated,
or when the event described by the notification occured? (presumably,
in some systems these might be separated by quite a bit)

Section 5, "user": what about when SASL is not used? ("user"
would also make sense for e.g. HTTP access.)

[Ballot comment]
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)

[Ballot discuss]
DISCUSS-DISCUSS: I'd like to understand why this document is going for
  PS rather than, say, Informational. I see little in here that is
  actually implementable; much of it is very high-level. The document
  itself says "As a first step towards building a notification system,
  this document attempts to enumerate the core events that real-world
  customers demand." That doesn't sound much like what I'd expect a PS
  in this space to say. Another example: "This document does not
  indicate which event parameters are mandatory or optional.  That is
  done in documents which specify specific message formats or bindings
  to a notification system."

IANA Last Call comments:

Action 1:

Upon approval of this document, the IANA will create a registry
called "Internet Message Store Events" at
http://www.iana.org/assignments/TBD

Using IANA Considerations [RFC2434] terminology, entries which do
not start with "vnd." are allocated by IETF Consensus, while those
starting with "vnd." are allocated First Come First Served.


Action 2:

Upon approval of this document, the IANA will create a sub-registry
called "Event Names" in the "Internet Message Store Events" registry
at http://www.iana.org/assignments/TBD

Initial contents of this sub-registry will be:

Event Name Reference
--------------- -----------
FlagsClear [RFC-lemonade-msgevent-05]
FlagsSet [RFC-lemonade-msgevent-05]
Login [RFC-lemonade-msgevent-05]
Logout [RFC-lemonade-msgevent-05]
MailboxCreate [RFC-lemonade-msgevent-05]
MailboxDelete [RFC-lemonade-msgevent-05]
MailboxRename [RFC-lemonade-msgevent-05]
MailboxSubscribe [RFC-lemonade-msgevent-05]
MailboxUnSubscribe [RFC-lemonade-msgevent-05]
MessageAppend [RFC-lemonade-msgevent-05]
MessageExpire [RFC-lemonade-msgevent-05]
MessageExpunge [RFC-lemonade-msgevent-05]
MessageNew [RFC-lemonade-msgevent-05]
MessageRead [RFC-lemonade-msgevent-05]
MessageTrash [RFC-lemonade-msgevent-05]
QuotaChange [RFC-lemonade-msgevent-05]
QuotaExceeded [RFC-lemonade-msgevent-05]
QuotaWithin [RFC-lemonade-msgevent-05]


Action 3:

Upon approval of this document, the IANA will create a sub-registry
called "Event Parameters" in the "Internet Message Store Events"
registry at http://www.iana.org/assignments/TBD

Initial contents of this sub-registry will be:

Parameter Reference
--------------- -----------
admin [RFC-lemonade-msgevent-05]
bodyStructure [RFC-lemonade-msgevent-05]
clientIP [RFC-lemonade-msgevent-05]
clientPort [RFC-lemonade-msgevent-05]
diskQuota [RFC-lemonade-msgevent-05]
diskUsed [RFC-lemonade-msgevent-05]
envelope [RFC-lemonade-msgevent-05]
flagNames [RFC-lemonade-msgevent-05]
mailboxID [RFC-lemonade-msgevent-05]
maxMessages [RFC-lemonade-msgevent-05]
messageContent [RFC-lemonade-msgevent-05]
messageSize [RFC-lemonade-msgevent-05]
messages [RFC-lemonade-msgevent-05]
modseq [RFC-lemonade-msgevent-05]
oldMailboxID [RFC-lemonade-msgevent-05]
pid [RFC-lemonade-msgevent-05]
process [RFC-lemonade-msgevent-05]
serverFQDN [RFC-lemonade-msgevent-05]
service [RFC-lemonade-msgevent-05]
tags [RFC-lemonade-msgevent-05]
timestamp [RFC-lemonade-msgevent-05]
uidnext [RFC-lemonade-msgevent-05]
uidset [RFC-lemonade-msgevent-05]
uri [RFC-lemonade-msgevent-05]
user [RFC-lemonade-msgevent-05]


We understand the above to be the only IANA Actions for this
document.