9 November 2006IETF 671 SEARCH-WITHIN No major changes Fix nits, references, formatting, non- ASCII characters, boilerplate WGLC Underway

9 November 2006IETF 672 CONVERT Reworded Abstract, Introduction, and other sections based on suggestions from Randy and Alexey BINARY on client no longer a MUST Fixed nits: boilerplate, references, non- ASCII, et al

9 November 2006IETF 673 Open CONVERT issues Returning multiple status codes for multiple conversions in a single FETCH METADATA entries/params for transcoding may be simplified (suggested by Randy I think)

9 November 2006IETF 674 VFOLDER Issues Multiple backing mailboxes Visible to legacy clients? Implementation complexity: new UIDs assigned to messages which go in/out of view. Expensive?

9 November 2006IETF 675 Notifications: Some Desirable Properties Server initiated (push) Support in-band and out-of-band transmission Can be tied to filter/narrow search criteria Notification filters may be named, discovered, and managed by clients Minimally support new message notifications Notification payload can contain enough info to determine which filter triggered the event Tolerant of delay and loss, Graceful degradation

9 November 2006IETF 676 Notifications Today: Many related drafts Lemonade Notifications, S2C & S2S CONTEXT IDLE VFOLDER MSG-EVENTS SIEVE NOTIFY, et al. (and related…SNAP, etc)

9 November 2006IETF 677 Desire: Simplicity and Unification Would be nice: –if in-band and out-of-band supported unified event model (msg-events) –In-band and out-of-band had unified filter criteria Or, if no single filter language, then at least feature parity –In-band and out-of-band channels coherent (don’t send notifications on one channel if already sent on other) –Notification (esp out-of-band) actually helps client sync more efficiently, saves bandwidth, etc –Is overall architecture general purpose and conforms to IAB goals of unified notification?

9 November 2006IETF 678 Notifications: Other Desires Out-of-band is secure and spoof proof Throttling notifications (client controlled?) Notification filtering/routing (send new message events via out-of-band, but not others) Out-of-band transport/network agnostic (IETF only describes payload and interface to notification server, not how to encode payload on SMS, UDP, etc) Scales well for IMAP server.

9 November 2006IETF 679 Notifications: Where we are View Filters –CONTEXT (IMAP search syntax) –VFOLDER (IMAP search syntax) –SIEVE (on deposit?) Event/Notification Filters –SIEVE (on NF side) –CONTEXT NOTIFY –P-IMAP simple “prefs” model (using METADATA)

9 November 2006IETF 6710 Notifications: Where We Are Event Model (msg-events) Server-2-Server (notifications-protocol) Payload (xemn, xmpp message?)

9 November 2006IETF 6711 Notifications: Other Issues Addressing –Does the IMAP server generate a notification payload and address it to a device OR –Do devices setup named notification/event “filters” and devices can then “subscribe” to them? –Latter case, IMAP server doesn’t need to know how to address device directly, just publish payload to named channel –Former case, IMAP server may need to specify “device id” to in payload/s2s protocol.

9 November 2006IETF 6712 Notifications: Issues Provisioning –Client may need to discover address of notification gateway (e.g. jabber server) Security –IAB and Lemonade goals strongly desire support for end-to-end security –But some operator networks rely on “secure/trusted” nature of carrier itself –Lots of work/problems for specifying how gateways to do this, e.g. with SMS.