DRAFT    DRAFT    DRAFT    DRAFT
30 November 2006 Edition



LEMONADE WG
IETF 67
7 and 9 November 2006


Chair Decisions:
Publish Server-Side Reconnect after Profile bis.

Group Decisions (pending list discussion):
Interim (depends on progress made on Thursday 9 November).

Other:
Looking for streaming media editor


Discussions of Note (see Jabber log for details)
http://www3.ietf.org/meetings/ietf-logs/lemonade/2006-11-07.html

BURL, IDLE
Discuss search filters.
Long discussion on IMAP URL's being underspecified.
Quick SUBMIT


We reviewed document status, listing completed documents (RFCs, in RFC editor queue, in/finished IETF last call), ready-to-go documents (in/finished/ready for working-group last call), and docments that need to be discussed.  Then Eric gave a brief report of the October interoperability testing in London.  Many things worked well, and the test highlighted some clarifications that are needed in some of the specifications.   IMAP Notify extension: will give the IMAP client the choice of what types of events to be notified about; allows search critera (notifications only on matching documents) and mailbox patterns (monitoring multiple mailboxes); allows the client to define fetch options to be automatically returned with the notification (saves an extra explicit request by the client).  There was some discussion that a client could ask for too much, and there needs to be advice to make sure the implementers know what they're asking for.  Servers should also be allowed to limit what they're willing to give (maximum number of mailboxes, for instance).

IMAP URL update: There was much discussion of the meanings of certain relative URLs, and the interaction between certain characters in mailbox names and the URLs.  We seem to be reaching consensus on limitations on relative URLs for the next draft.

"Profile-bis" vs "Profile-ter": There was discussion about whether it makes sense to have another ("ter") iteration on the profile, and whether that will confuse things in the OMA.  Dorothy Gellert, who's working with OMA, says it will.  Getting the notifications specs in there is key for the OMA.

Contents of Profile-bis: Alexey Melnikov proposed adding four items to Profile-bis, and we discussed those at length, particularly SMTP compression (again) and SMTP checkpoint/restart.  Consensus not to add either of those, but to add SASL-IR and in-band notifications.  The chair suggested we wait to see what a SMTP compression document would look like before proceeding.  There's also the question of whether we should remove binary MIME, and that question will go to the mailing list.

There was discussion on reviving Tony Finch's SMTP quick-start draft.  Randy will work with Tony and produce an updated draft.


Suggesting to bypass convert to allow Alexey and Ray to do an offline document pass, then bring it to the list

bash agenda: 
    interop
    notifications
    search-within, filtered views, profile bis, convert

Interop Results, Notifications, named Searches, and URLs  http://www3.ietf.org/proceedings/06nov/slides/lemonade-2.ppt

  alexey: issues discovered during interop
  alexey: urlauth:
  a couple bugs -- suggestions for doc
  Dave Cridland: That's EXPIRE= validation during GENURLAUTH, not during URLFETCH (where everyone did, AFAIK)
  Dave Cridland: Also, if clients have clocks set in the past, GENURLAUTH works but BURL fails.
  (blank stares on question of 'does anyone care about urlmech issues'
  Dave Cridland: Might be a possibility of using a shared-key URLMECH sometime, avoid the GENURLAUTH round-trip.
  pguenther: that was kind of the original design, yes
  cromwellian: anyone see this?
  chris: urlmech response code is really there for methods other than internal; 
  pguenther: cromwellian: yes
  chris: add note to base?
SUMMARY: add note to base : if server only implements internal, response code will not convey any info and should be optional in that case

  barry: question on idle issues
  alexey: not really idle issues

  alexy: condstore issues
need note about CONDSTORE on CONDSTORE + UIDPLUS combination
  (need untagged OK to convey notification sequence)
  additional note: how  HIGHESTMODSEQ can be returned and additional text for client on what to do if  it doesn't get it
  alexey: constore: "STORE UNCHANGEDSINCE 0"
  phill: pick option 2; client can already find which flags exist
  alexey: prefer option 1
  pete: use BAD for 0?
  alexey: some servers also set flags, which was wrong
  so should have said NO
SUMMARY: STORE UNCHANGEDSINCE 0 for any system/user defined flags MUST return NO

  lisa: BAD for system flags, NO for user flags?

  alexey: STORE UNCHANGEDSINCE 0 for any system/user defined flags MUST return NO.
  alexey: QRESYNC
  merge with EXPUNGED draft?
  why? QRESYNC is optimization on condstore, as is EXPUNGED
  probably used together, too many extensions, so merge?
  new draft: "client reconnect"
SUMMARY: merge them
  cyrus: call this an update to condstore?
  alexey: no, not needed, but feel free to suggest text
  alexeymelnikov: Cyrus promised to provide some text about QRESYNC updating CONDSTORE

  resnick: Not at the mic, since I haven't thought this out: If EXPUNGED would be useful without CONDSTORE *and* folks would be willing to implement EXPUNGED *without* implementing CONDSTORE, then I'd rather it be a separate extension.
  sorry:

Status of drafts, Notification Discussion 
http://www3.ietf.org/proceedings/06nov/slides/lemonade-3.ppt

 slide 5
 Lisa: Pete: It's certainly a tradeoff.  Why not ask the question who would implement EXPUNGED without CONDSTORE?
 randy: Pete: by 'folks' do you mean clients, servers, either, or both?
 resnick: Randy: Servers.
 Lisa: (And isn't it actually draft-ietf-lemonade-reconnect that it would be combined with?)
 randy: Pete: it might be better to ask if its useful for clients to have only one
  (ray cromwell describing slide 5 ....)
 resnick: Lisa/Randy: Understood. That's why I didn't get up to the mic. I'm not sure if EXPUNGED would be independently interesting to clients and has a higher likelihood of implementation on servers. Still cogitating.
 randy: I have doubts that EXPUNGED alone would be useful to clients, but I'm not sure
 resnick: Neither am I.
 Lisa: Mark Crispin asked the same thing Randy just asked.
  discuss on list: whether notification payload >>needs<< to carry info to determine which filter triggered the event
 resnick: On this notifications stuff: I take it folks understand that we need a charter update, eh?
  ... discussion of use cases ...
 Glenn Parsons: Pete:  what do you think is out of scope?
  ... unexplored in some ways, could use trial, design payload format so that extra stuff can be added later ...
 resnick: Glenn: This sure sounds like server->client notifications.
 Glenn Parsons: There are several parts:  architecture, content, out of band & inband
  ... is notification a hint that client needs to go digging for update, or include sufficient info in and of itself ...
 fanf: what about notifications that aren't intended to prod an IMAP client?
 randy: fanf: what are those notifications intended for?
  ... client opaque data returned by server  ...
  ... not filter name but client provided user data item ...
 fanf: e.g. for a "you have new mail" indicator
 arnt: that's an indirect way to prod an imap client
 Glenn Parsons: I think our view on notifications has changed significantly since we started.
  ... are filters client specific? hardware specific? ...
 resnick: Glenn: Absolutely. But the charter doesn't reflect that.
  ... "tolerant of delay and loss" sounds like flow control? throttling?
 randy: My comment was about the intent of notifications: if they are merely small wake-ups that let the client know it needs to go fetch data to resync, and perhaps also include enough info to help the client decide to fetch data now or later, then the delay/loss and security requirements are very different.
 Glenn Parsons: The charter does not have the specifics, but it has the spirit
 randy: On the other hand, if the notifications contain enough data to resync, then the delay/loss and security requirements are significantly different
 randy: I
 resnick: Quite the opposite. That charter was designed to specifically not allow notifications from server to client.
 randy: I've heard both discussed here and i think we need to decide which path we want to go down
  ... is this replacement for inband sync?
 Glenn Parsons: The charter included the note that the IAB was going to rule on that issue.
  ... partial sync for sms's ... not job to create imap sync over X ...
 resnick: I think the thoughts in this area have probably matured enough to make it reasonable for us to work on, but I think the rest of the community should be told that we're working on it.
 randy: Throttling is very different from delay/loss
 randy: Without throttling, notifications can be much more expensive (to operator and user) than polling
 randy: Issue of where throttling is done: on event-generating server (IMAP server) or on separate notification server (perhaps in carrier network)
  ... last time discussion of throttling, may client could set up rules on server, but too complicated ...
... throttling would be left up to vendor implementation, client should be able to say "i've had enough" ...
 Lisa: Some notification transports have their own throttling mechanisms.
  ... question of two filters triggering same event ...
  ... discuss further issues with notifications on list ...
 arnt: who's speaking - ray?

  slide 6: ray 
 Glenn Parsons: And the result of the IAB ruling fed into our architecture discussion and document.
  (notifications today: many related drafts)
 Glenn Parsons: On the recharter, we had discussed before
 Glenn Parsons: the current rough consensus is that it would be nice , but not needed
  ray: need to unify things -- make them more coherent

  slide 7: Desire: simplicity and unification
  resnick: AFAIK, the IAB never gave an answer ("ruling") on this issue, and I have no memory of any consensus on rechartering. Can you point me to any messages?
  Lisa: I think I'm the one with the goals for unified notification, actually
  Glenn Parsons: Pete:  we reviewed the IAB note last year sometime ...
  arnt: I'm connected to my imap server form my desktop all the time, even when I'm not in the office. I want out-of-band when not in the office.
  Glenn Parsons: and the rechartering discsussions have been mostly at IETF sessions...
SUMMARY: need to associate filters with sessions; session needs some idea of device being connected
  fanf: this device identifier sounds like an XMPP resource
  (agreement on channeled comment)
  (user device knows what it wants; server can't guess)
  fanf: one problem with the client explicitly asking the server to suppress notifications is what happens when the client's imap connection is abruptly lost. do notifications remain suppressed?
  (fanf: do you want that comment channelled?)
  hardie: Wouldn't it be useful on shared mailbox--telling someone that an item has been expunged helps indicate it's not in the queue?
 
  ray: slide 8: Notifications: Other Desires
  eric: what is goal wrt DoS attacks?
  ... discussion ...

  slide 9: Notifications: Where we are
  ... view filters - different constraints, may be able to eliminate one of CONTEXT or VFOLDER
  ... alexey: add IDLE notify ...
  (to event/notification filters list)
  ray would welcome proposals for notifications draft

  slide 10: notifcations: where we are
  ... msg-events done ...
  ... s2s needs work, payload needs work ...
  eric: will there be a s2s need in the wild: between vendor A and vendor B
  ray: mega-notification boxes?
  chris: good to be able to hook up s2s between servers, but not critical path. postpone to after profile-bis?
  eric: part of charter
  lisa: least part of our goals
  ray: leave out of profile, make supplementary in future? but don't drop
SUMMARY: eric: keep on docket but move milestone

  slide 11: notifications: other issues
  chris: it's critical that servers not know device ids?
  ... must have on imap server, a way for client to say  that there's a class of events it can make use of
  Lisa: +1 to all Chris said.
  ... subscription managed by client, generation mananged by server, need throttling on both sides
SUMMARY: desire is that devices subscribe to appropriate filters for their circumstance
  ... imap servers will not be device aware

  slide 12: notifications: issues
  provisioning...
  security...
  ... need integrity checks, but not necessarily e2e encryption (e.g.)
  harald: doesn't a notification (potentially) contain a message sender and a subject line?
  ...don't want to drain batter life, DoS
  ... ray: integrty is SHOULD, e2e secrutiy is desirable, 
  arnt: it potentially does that. stress on the word potentially.
  arnt: read the two dozen drafts ;)
  chris: notification model needs security issues section ... specify considerations of notificiation section
  Glenn Parsons: we have a notifications architecture document -- this is not the model Chris is looking for?
  arnt: no, there are _lots_. perhaps not two dozen, but _lots_. many partly competing, partly complementary proposals.
  ... draft-ietf-lemonade-notifications
  ray: too many drafts, need to be combined
  lisa: two models: not systems that support subscribe, another for sms you just push out to?
  ray: word subscribe being used 2 different ways
  harald: -notifications-03 section 8.1 contains a "should" for encryption that IMHO should be SHOULD (for notifications with subject, sender and so on)
  eric: if notif mech is SIP, SIP has subscription semantics and protocols
  ... discussion on subscribe ...
  chris: 2 diff pieces: 1) event generation filters, partly controlled on server and partly policy
  2) subscriptions, function of notif method
  ray: except SMS
  could address by: event generation filters are good enough, or generation trigger
  Lisa: For the notes, what I was saying at the MIC was that there could be two completely different ways of authorizing and setting up event flows:  one way for delivery over systems that already have a Subscription model (SIP and XMPP), and one for delivery over systems that do not have subscriptions (email and SMS). 
  ray: do notif server need bidirectional capability?
  Lisa: In the first case, the IMAP server as the notification source only needs to have authorization setup.   In the second case, the notification source needs to have event streams initiated with filters etc and a way to stop them again.
  eric: sip clarification
  eric: asks if xmpp is similar
  lisa: clarifies xmpp
  ray: boil down: 
  1) what do we do with mechanis that don't have subscription method? does imap need way to do that?
  2) is there reason why imap server needs to now if people have unsubscribed at the gateway?
  phil: affects on url?
  phil: reasonable to have aggregator tell imap to stop/restart event streams
  pguenther: note quite: use URLAUTH with imap: SEARCH urls for authorizing access to notifications
  lisa essentially concurs
  ray: need to coalesce, unify and finish up
  alexey: need jabber interims?
  arnt: use the mike?
  (discussing what to discuss next)
  resnick: This is kibitzing about which slides will appear.

  back to slide 4: vfolder issues
  alexey: volder and context need to be discussed together
  SEARCH WITHIN is LC

  slide 3: open convert issues
  ray: simplify discovery mechanism?

  Interop Results, Notifications, named Searches, and URLs slide 11: lemonade profile bis
  randy: My message to the lemonade list sent May 31 8:38 AM contained suggestions for how to simplify discovery mechanisms

  slide 13
  phil: is anything in profile bis saying: clients should not do dorky things with vfolders
  slides added to http://www3.ietf.org/proceedings/06nov/slides/lemonade-4.pdf on Contexts
  do we need interim or jabber sessions enough?
  Glenn Parsons: ack  -- you didn't talk to me ...
  lisa: do we need notificaiton interim?
  alexey: notif and filtering?
  lisa: workshop?
  (ietf process governs difference)
  pguenther: dave crocker suggested an interim bof
  Glenn Parsons: what was Lisa talking about?   A new non-LEMONADE notifications event?
  resnick: Glenn: Yes.
  Glenn Parsons: 12th of what?
  resnick: December.
  Lisa: Glenn, I really want to discuss this more with some people like Ted first, and some people outside of Apps who are working on very similar notification problems.  But I was thinking of a pre-BoF: call it a workshop or whatever, but I finally see how one might write a scoped charter for a finite-time WG in this area.
  Glenn Parsons: Lisa for the LEMONADE problem space we do not want a general boil the notification ocean solution.
  Lisa: Yes.  "I finally see how one might write a scoped charter for a finite-time WG".
SUMMARY:  ... when to have jabber interim ..., december 12, 7am PST
 hardie: midnight in new zealand

  topic: context, vfolders, and such

  milestones (slide 27 of chair's slides)
  imap url Dec?
  yes
  profile, filtered views, notifications payload format should be on time
  barry: imap sieve
SUMMARY:  barry: will have update to imap sieve and corresponding sieve environment draft by end of year
  Glenn Parsons: IMAP SIEVE Christmas present...
  alexey: ned was also talking about sieve environment, so ned and barry need to talk
  pete: do folks want catenate go around after profile bis is done?

  chris: needs to delete a clause from burl

  dorothy: lemonade bis by june?
  yes