DRAFT DRAFT DRAFT DRAFT

IETF 68 - Prague, Czech Republic

Monday, 19 March 2007

Administrivia
Agenda bashing:
- Arnt's talk moved to Thursday, since he takes notes on
  Monday. Expectation level for the notes raised to compensate.
- SMTP restart, IMAP sieve moved to today, streaming too perhaps
- Big picture stays today
- Rohan speaks Monday

Document status:
- Glenn waiting for AUTH48 for fururedelivery
- Four drafts getting htere

Drafts in our control:
- lemonade-convert: editors cannot work on it, needs work, Alexey
  volunteers himself this time. (Later: IANA considerations needed, a
  bunch of nits and a last call note.)
- anotatemore: considered ready for IESG by various WG members
- msgevent: Chris suggests WGLC. Fits one implementation, more would
  be better, but the best is the enemy of the good. Lisa can be AD.
Views:
- vfolder expired, to be discussed Thursday
- context: not expired, to be discussed Thursday
Object level encryption:
- object-level encryption is expired, not in the profile, needs a new
  editor.
- REST-based access: a HTTP-based tunnel, halfway in profile, expired,
  XMPP WG working on tunneling protocols over HTTP. General hopes that
  they'll deal with the problem and we can duck it.
A digression regarding status of an RFC.

Monday commences as in the bashed agenda.

Alexey: Quick reconnect
- various trivial nits
- ready

Alexey: IMAP URL
- believed ready by Alexey, ever the optimist
- changes since last revision summed up
- WGLC

Barry: imap-sieve
- describing draft -02
- major open issue: how to tie event to script. first thought:
  managesieve. now favoured: metadata. needs discussion.
- real examples needed that just use the base spec (all the good ones
  barry has thought of use extensions)
- "discard" can be considered to be rather different from what discard
  means when injecting new message. barry will explain why.
- call for volunteers
- comments that this is a major change to sieve, needs careful
  consideration. randy talks himself into volunteering. aaron ditto.
- on Thursday we'll discuss whether this goes into profile-bis

Notifications:
- several proposals

Rohan Mahy talks about SIP notifications
- description of a typical connection using the example from 3842
- SIP PUBLISH vs. SIP NOTIFY: PUBLISH is for occasionally-present
  clients to publish to permanently-present servers. Notify expects
  the receiver to be there all the time.
- proposed extensions to 3842 for sieve: draft-many-sieve-notify-sip
- example shown
- some concern over the size of initial connection, when informnation
  about all messages is sent
- Dave Cridland asks why not keep an IMAP connection open? Some
  unconclusive back-and-forth.
- Chris Newman asks about who guarantees event arrival - sender or
  some buffering hub, or some code which regenerates?
- Ted Hardie points out that it's fine and useful to get more information
  across the connection you already have
- Ted Hardie points out that if you have several IMAP servers, SIP or
  XMPP PUBSUB can monitor all of them
- Much very fast communication, no conclusion, five people around the
  microphone.
- Chris Newman suggests that using SIP for notiications sounds is it
  may not meet Lemonade's time limits.
- Security questions. Rohan suggests that SIP over TLS is the
  question, and clarifies as TCP+TLS.
- More words without any form of conclusion. It is pointed out that
  modern boxes have timesharing and can wait for TCP packets without
  spending resources while waiting.
- Greg pointed up that the notification archtiecture places the
  per-user customization of notification rules in the message
  store. Real-world is that this per-device rules tend to be
  implemented in teh notification server.  such server does not see
  the sieve scripts.

OMA MEM Liaison
- Notifications from OMA; Glenn answers, draft to the list first,
  likely discussion on Thursday.