Subject: [lemonade] Draft Minutes, Both Days

From: "Burger, Eric" <[email-masked]>
Date: Thu, 1 Jun 2006 22:20:51 -0400

[Corrections applied from list]

Draft Minutes, lemonade Interim Meeting 65,5
31 May 2006 - 01 July 2006
Ottawa, ON, Canada

Chairs:
Eric Burger
Glenn Parsons

Attendees:
Alexey Melnikov
Arnt Gulbrandsen
Ray Cromwell
Dave Cridland
Greg Vaudreuil
Mike Parsel
Ken Murchison
Jerry Shih
Stephane Maes
Randy Gellens

Jabber Logs
31 May 2006:
http://www3.ietf.org/meetings/ietf-logs/lemonade/2006-05-31.html
01 June 2006:
http://www3.ietf.org/meetings/ietf-logs/lemonade/2006-06-01.html

Meeting Goal: Get updates to documents by 19 June 2006 in time for WGLC
before or at IETF 66 in Montreal.

Draft Discussions
=================

RECONNECT
---------
Issue: Do we need to mandate a minimum number of outstanding sessions a
server must support?
Discussion: Could make clients easier to implement if they knew that a
server would have at least so many sessions available.
Rejoinder: No matter what, another client can consume sessions, so the
client must have code to deal with exhaustion of session resources.
Thus there is no benefit of having a preset minimum number of sessions
available for reconnect.
Result: Be silent on a minimum number of sessions.

Issue: Do we need server-side RECONNECT?
Discussion:  RECONNECT authors realized the tokens being passed to let
the server know which session was being reconnected was identical to the
state the server needed to know to re-establish state.  Thus it is
possible for the server to be stateless.
This follows IETF practice of avoiding fate sharing.  The client holds
the state, and if the client fails, it doesn't care the state is lost,
as it lost the state anyway.  The proposal does not add any burden on
clients, as the client needed to store the same information with the
server-driven scheme.
Rejoinder: Server-driven document is already written; do we want to
delay?
Result: Create new document centered around client-driven RECONNECT.  It
will be a work group document: draft-ietf-lemonade-reconnect-client; we
are confident in its status as only about 2 paragraphs change.  After
the new draft is issued and the old draft is updated (there are some
ABNF issues, etc. that need to be addressed), we will preferably chose
one document and kill the other.  Alternately, we will chose one,
reference it in Profile-bis, and release the other as Experimental.
Worst-case is both documents progress.

IMAP URL (2192-bis)
-------------------
Issue: Alexey needs Mark's input to decide what goes into 2192-bis
versus URLAUTH.
Resolution: Alexey will e-mail Mark directly.

Issue: Alexey needs some help with sections talking about listing
content of a server and mailbox naming scope. 
Resolution: We volunteer Dave to help.

Issue: Should 2192-bis include examples of extensions from BINARY,
URLFETCH, imap-search-ret?
Resolution: If those drafts are stable, then yes, otherwise, no.  Alexey
will send note to list if he doesn't get a response, then he will assume
the drafts are not stable.

CONVERT
-------
Issue: ISO-8859-n has 16 values for n.  Which one(s) do we mandate?
Resolution: All of them (?).  Clearly at least ISO-8859-1 (trivially
easy) and ISO-8859-5 (in honor of Alexey) will be mandatory to
implement.

Issue: The original draft had a bunch of conversions that are now not
mandatory.
Resolution: Leave the text, but change RFC 2119 language from
MUST/SHOULD to MAY.  Note that OMA will impose relevant
mandatory-to-implement conversions.  We will ensure the protocol can
handle them, but will not mandate any particular conversions outside of
ISO-8859-n to UTF-8.

COMPRESS
--------
Note: There are some very interesting results discussed in the Jabber
log <http://www3.ietf.org/meetings/ietf-logs/lemonade/2006-05-31.html>,
around the 12:20 time mark, about compression experiment results for TLS
and compress=deflate.  The short of it is that traffic with a moderate
amount of attachments gets 70% compression using TLS; traffic with lots
of attachments gets better compression with compress=deflate.

Issue: How to disambiguate Content-Transfer-Encoding from Content-Type?
Discussion: VPIM experience is the C-T-E is not well supported.  One
proposal is to use magic MIME types.
Rejoinder: Only a C-T-E knowledgeable client will request compression
from a C-T-E knowledgeable server.  Moreover, using C-T-E is a correct
protocol thing to do, as in "say what we mean."
Reminder: The server is in the best position to decide whether or not to
compress (if compression accepted by the client).  The client-driven use
case, where the client wants to save CPU at the expense of radio power,
does not match the physics of the situation. 
Discussion: Propose compress=deflate (draft-arnt-imap-deflate-02).
Unquestionable desire to NOT have the mechanism be on a
request-per-body-part basis.  However, there is also a desire to have
the mechanism be controllable (on or off) at client-requested point in
the session.
Discussion: Although deflate is the compression algorithm of gzip, and
the proposed lemonade mechanism was called gzip, we are NOT discussing
using gzip anymore.  This means that the stream will not include the
actual MIME type or file name (as would happen if we used the entire
gzip structure).
Discussion: Clear win for downstream (server->client) compression.
However, compression could be a cost for upstream messages, as the
protocol messages are often smaller than the PDU of the compressed
block.
Discussion: What, if in the middle of a transaction, the client says,
"stop compressing"?  That isn't a problem, because the IMAP transaction
model says the current transaction completes.
Resolution: Move compress out of convert document.  Use
compress=deflate.  Ensure the method is controllable.  Ensure the method
can be asymmetric (compress one way and not the other).
Arnt is to be lead author.
Special note: we will re-use the name draft-ietf-lemonade-compress-04,
but the contents will be entirely deleted and the new content will
substantially come from draft-arnt-imap-deflate-02.

ENCRYPT
-------
Issue: Still not clear what the business / use case is for this feature.
Needs to be clear and distinct.
Discussion: Classic industry problem: if we don't do it, someone less
knowledgeable will do it.
Resolution: new draft coming.

WITHIN
------
Issue: Second recalculation is way too much of a server burden.
Discussion: We are not trying to replicate instant messaging.  Daily is
enough.  Hourly is OK.
Discussion: We came up with a bunch of use cases which do need finer
grain than hourly, e.g., transportation (your flight has been diverted)
and military (invade Iraq if I don't hear from you for 15 minutes).
Discussion: Can we let the client request whatever it wants (in minutes)
and have the server reply with what it set it to?  I.e., if a server
does hourly, and I request 39 minutes, the server responds that it will
do updates hourly; if a server does quarter-hourly, and I request 39
minutes, the server responds with 30 minutes or 45 minutes (up to the
server to decide).
Resolution: By minutes; need to think about letting the server do the
granularity (need text).

Issue: Should we give guidance on recomputing views?
Resolution: Yes, put in an informative section into the document.

VFOLDER
-------
Issue: Anonymous users creating VFOLDERs can be a DoS attack.
Resolution: Anonymous users cannot create a VFOLDER, but they can read
them.

Issue: Legacy clients might duplicate messages since they don't know the
messages are virtual.
Reminder: In Dallas (and on the list) we said that only lemonade clients
could use VFOLDERs.
Discussion: Would be very useful for legacy clients to see VFOLDERs.
Resolution: Allow VFOLDER only for lemonade clients for now.

Issue: What happens if one renames a folder a VFOLDER depends on?
Discussion: Original proposal is to delete the VFOLDER.
Rejoinder: That would be a customer service nightmare, "All of my
folders disappeared?!?!"
Resolution: VFOLDER calculations get updated when one renames an
underlying mailbox.

Issue: What happens if one deletes a folder a VFOLDER depends on?
Discussion: Choice is to immediately delete the dependent VFOLDERs, keep
the VFOLDERs around until the next status/select/examine, or make the
VFOLDER real.  Arnt's implementation today immediately deletes the
dependent VFOLDERs.

Issue: What about Append/Copy support for VFOLDER?  The current draft
says "maybe".  
Discussion: Alexey proposed saying "yes" unless not possible.  Arnt said
that some clients expect a message to be there if they put it in the
folder.  If it isn't there, the client may retry.  If it is the View
that keeps the message away, the repost will always fail (causing the
client to loop).
Rejoinder: The scenario of a message never getting posted can happen
today.  One client can post a message while another expunges it.  Answer
to that is that while it could happen, it is not likely to occur
repetitively.

Issue: The server should be able to reject expensive or complex VFOLDER
calculations.
Discussion: This could cause a user interface problem if the creation of
the VFOLDER is hard-coded in the client.  That is, the user does not
know they are requesting the creation of a VFOLDER.  Thus they get a
surprise when they get an error messaging saying the VFOLDER they didn't
know they were creating failed to be created.
Rejoinder: In a sense, this is a client implementation failure, and the
user will sensibly force the provider to fix the client.
Discussion: The impetus for the question is that it is thought that some
servers may not implement dynamic attributes for VFOLDER.  Further
discussion indicated that if you do VFOLDER and CONDSTORE, you pretty
much have already done dynamic attributes.
Resolution: Consensus is that if one does VFOLDER, one must do Dynamic
Attrributes.

Issue: There are two use cases for VFOLDER.  One is as a notification
mechanism (setup a VFOLDER to filter messages of interest and then
report on the state of that VFOLDER).  The other is as a mailbox
management mechanism (I get thousands of messages per day or I have a
ton of messages in my folder, and I want to have only a small subset on
my client).  Should we have two mechanisms?
Discussion: It is true that the former use case demands dynamic
attributes while the second may be able to get by with static
attributes.  However, the use cases are too close together, and the user
interface would be too complicated, to split the functionality.
Resolution: We just have VFOLDER, and it requires support of dynamic
attributes.

Issue: Can we have a VFOLDER that is the set of messages that are not
selected by any other VFOLDER?
Resolution: Submit text.

Issue: When does a VFOLDER recomputed its contents?
Discussion: Clearly when a new message arrives.  What about on any IMAP
command? on IMAP commands the mutate state? only on SELECT? by time
interval?
Resolution: "In a timely manner" [I'd like to see text]

NOTIFICATIONS
-------------
Note: Ray extended EMN for lemonade needs; will fold back in to official
EMN definition in OMA.

Issue: MSGEVENTS draft expired
Discussion: It is critically important for the set of events to be
reviewed for completeness.
Resolution: Chris to resubmit; WG to review.  NEED VOLUNTEERS TO REVIEW.

Issue: MSGEVENTS are not extendable
Discussion: We cannot anticipate future extensions to IMAP, nor can we
be sure we have covered everything today.  Also, there is a legitimate
business need for proprietary extensions for use in proprietary
environments.
Resolution: Ray will investigate creating an extensible mechanism for
notification events.
Special Note: We will make clear that this mechanism for proprietary
extensions MUST make it explicit what kind of notifications are
acceptable to go over the wire with this mechanism.  In particular, we
are talking about stuff we don't care if it gets lost or where a
duplicate delivery doesn't harm anything.  I think that like the Pork
example in the Torah, we should explicitly call out LOCKDOWN as a
message that is wholly inappropriate for this mechanism and MUST NOT be
sent as an extension message.  LOCKDOWN, purge all messages, purge your
cache, et al. are all messages that fall into the category of "do not
use notifications."

Issue: We had two mechanisms, out-of-band (oob) and in-band (ib) for
notifications.  However, it can be very difficult to decide if a user is
actually connected.
Discussion: Don't want to have multiple code paths, especially if the
choice to go ib can turn out to be wrong.  On the other hand, the
technology of ib (use TCP) and oob (use, e.g., SMS), can have very
different cost profiles.
Discussion: Independent of message state, it can be useful to have both
mechanisms.
Resolution: We will split NOTIFICATIONS into two drafts, on ib and one
oob.  Alexey will write the ib draft.  New draft must be done by June
19.

Issue: Server-to-Server (S2S) text in draft does not bind the messages
to a transport protocol.  Is this OK?
Discussion: Might not want to make a binding, so the server can natively
interface with SIMPLE Server, XMPP Server, SMSC, MMSC, etc.
Rejoinder: Some folks do not care about mobile notifications and even if
they do they do not want to have to implement a bunch of notification
server protocols.
Resolution: We will choose a single transport binding.  Stephane will
provide text in next revision of NOTIFICATIONS draft, due June 19.

Issue: Should lemonade S2S document be explicitly limited to lemonade /
messaging environments?
Discussion: Do not want to boil the ocean - generic notifications are a
BIG computer science problem.  Moreover, the whole reason for having a
lemonade S2S document is for the purposes of having a baseline,
easy-to-implement protocol for lemonade servers to use.
Resolution: Randy and Stephane will provide appropriate text, by June
19.

DEPLOYMENTS
-----------
Issue: Dave was going to supply figures for reconnection costs.
Resolution: Dave WILL supply figures for reconnection costs.

Issue: Current draft references Profile-bis and NOTIFICATIONS
Discussion: They will hold up publication.
Discussion: What about TCP-Challenged Environments?
Resolution: Drop NOTIFICATIONS, don't reference TCP-Challenged, and
reference Profile.  Put them back when we do DEPLOYMENTS-bis.  Update by
June 9.  The document will be ready for WGLC at that point.

Reminder: We are publishing this as a BCP.

TCP-CHALLENGED ENVIRONMENTS
---------------------------
Issue: So we are not circumventing firewall policy, HTTP PDUs will have
a header to indicate the payload is really a mobile message.  Current
draft uses X-HTTP-Binding.
Resolution: Use something descriptive, like HTTP-Mobile-Email and do not
use X-.

Issue: The draft enumerates five different approaches to making lemonade
work in environments without TCP.  Should we choose one?
Discussion: While HTTP tunneling provides 100% of the lemonade
functionality, HTTP tunneling will not work in all TCP-challenged
environments.  REST will work in all TCP-challenged environments, but
will not provide 100% of lemonade functionality.
Resolution: Mandate REST.  Not providing 100% of lemonade functionality
is a feature, not a bug.  Using REST allows lemonade to work in all
environments, including high-value environments like satellite e-mail.
In addition, not providing 100% of lemonade functionality gives
operators that are TCP-challenged an incentive to properly implement
their network.
Note: We will keep the text for the other methods, to explain why we are
not using them.
Note: Ray to review how XMPP specifies operation over TCP and fall-back
to HTTP.  [References to this are in the Jabber logs (pardon the
irony).]

Chair's note: Ensure there is NO normative language in any of the text
for the other methods, and move them to appendices.  Make it clear that
REST is the only approved (and specified) method available.

STREAMING
---------
Issue: How to do VCR controls (fast-forward, rewind, speed-up,
slow-down, pause)?
Discussion: MSCML and MSML have the bulk of the market.  This problem is
being examined informally by the mediactrl interest group (see
<http://flyingfox.cantata.com/i-d/mediactrl>).  RAI (TSV, historically)
didn't have pressure to examine this work.  MSCML is on RFC Editor
Queue.
Resolution: We will press RAI to solve this issue for us, as it is a SIP
control thing.  Our document will not reference VCR controls.

Issue: Server location is important.
Discussion: Neil is working on a proposal.
Resolution: Neil's text will go into Profile-bis.

PROFILE-BIS
-----------
Editorial: Need to update bis to reflect decisions on compression,
encryption, and reconnect.

Issue: What about streaming? Is it mandatory to implement?
Discussion: Streaming is purely a client issue.  Server only needs to
support URLAUTH and URLFETCH.
Resolution: Remove streaming appendix from bis and reference streaming
draft.

OMA LIAISON
===========

Document Progress
-----------------
We will tell OMA about our progress by enumerating RFC's published and
documents in or about to be in WGLC or IETF LC.  LC documents include
FUTUREDELIVERY, CONVERT, WITHIN, METADATA (ANNOTATEMORE), ESEARCH, and
deployment issues.

We will not include RECONNECT, as we need to nail down server-side
versus client-side state storage first.

Interoperability Testing
------------------------
Reasons for Interop:
 Marketing
 Moving to IETF Draft standard
 Compliance
 Input to OMA IOP

We will focus on #2 and help on #4.  Plan is to have the following
interoperability events:

A Private Interop Event (under NDA).
Participants: Developers (only)
Venue Requirements: Close to the most developers / travel constrained
developers; excellent Internet connectivity, as some developers will
participate remotely or their servers may be remote
Location: UK
Dates: October 23-27 [tentative]
Goal: Get working implementations of lemonade suite.  Prove accuracy /
viability of IETF I-D's before RFC publication and moving to IETF Draft
Standard from Proposed standard. Results will NOT be published, to
encourage folks with alpha code and prototypes.

A Market-Focused Interop Event, Highlighting Lemonade Interoperability.
Participants: Field Folks
Venue Requirements:  High visibility venue that will generate customer
and press buzz.
Location: Telecom 2006, Hong Kong
Dates: December (first week?)

A Market-Focused Interop Event, Highlighting Mobile Messaging
Paricipants: Field Folks
Venue Requirements:  High visibility venue that is mobile-oriented that
will generate customer and press buzz.
Location: 3GSM, Barcelona
Dates: February 12 - 17, 2007 (?)

To make the marketing events happen, we need outside coordinator.
Stephane volunteered EIMG group.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Randall Gellens <[email-masked]>
Date: Thu, 8 Jun 2006 16:06:09 -0700

>  Resolution: Randy and Stephane will provide appropriate text, by June

My notes indicate that there are to be two notification drafts: one 
for the format (payload), and one for the mandatory-to-implement 
protocol.  (I agreed to co-author the second.)  Did I misunderstand, 
and there is supposed to be only one draft covering both?

>  DEPLOYMENTS

I haven't seen text from Dave yet, and I sent in a revision which can 
go to WGLC.  If Dave has figures at hand they can be added during 
WGLC, otherwise they can go into deployments-bis.

>  June 9.  The document will be ready for WGLC at that point.

Actually, the then-current draft did not reference notifications, but 
did reference profile-bis.  The resolution was to reference profile 
instead of profile-bis, and to not add notifications or 
tcp-challenged until deployments-bis.

I sent in an updated draft that is ready for WGLC.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
People demand freedom of speech to make up for the freedom of thought
which they avoid.                                       --Kierkegaard

---

From: Dave Cridland <[email-masked]>
Date: Fri, 09 Jun 2006 09:36:07 +0100

On Fri Jun 09 00:06:09 2006, Randall Gellens wrote:
> I haven't seen text from Dave yet, and I sent in a revision which 
> can go to WGLC.  If Dave has figures at hand they can be added 
> during WGLC, otherwise they can go into deployments-bis.
> 
> 
I have one feature I need to ensure works properly - specifically, 
TLS session resumption stuff - then I need to settle down with 
ethereal and Polymer's debug mode and count octets, carefully 
disabling any extension not in Profile.

I'll do this before Monday.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 09 Jun 2006 12:34:57 +0100

> At 10:20 PM -0400 6/1/06, Eric Burger wrote:
[...]

> and there is supposed to be only one draft covering both?

I would prefer to have 2 documents.