Subject: [lemonade] Draft Interim Minutes

From: Eric Burger <[email-masked]>
Date: Wed, 20 Oct 2004 23:53:16 -0400

MANY THANKS TO GREG

Attendees
 - Stephan Maes    	[email-masked]
 - mark Crispin    	[email-masked]
 - randy Gellens   	[email-masked]
 - Ted Hardie	 	[email-masked]
 - Lyndon Nerenberg	[email-masked]
 - corby wilson    	[email-masked]
 - Jerry Weingarten  	[email-masked]
 - Aranaud Meylan	   	[email-masked]
 - Glenn Parsons	  	[email-masked]
 - Eric Burger	  	[email-masked]
 - Jean Sini	  	[email-masked]  

By Phone
 - Pete Resenick	  	presnick@qualcomm

Agenda was bashed.

Liaison statements
  - Lemonade received liaison response from T2.  No further response needed
  - OMA liaison previously sent has not received response, Follow-up to be
done
  - Additional OMA response notifying of working group last call for MMS
mapping to be sent via Dean Willis

Working Group Last Calls 
  Completed
  - Glenn to write IESG summary to send to Ted  (Server to Server
Notifications Reqs)
  - MMS Mapping - After Randy makes some last-minute changes
  To be sent
  - Goals document needs WG Last Call for tomorrow.
  - Future Delivery - draft-ietf-lemonade-00   Needs WG Last Call tomorrow

Pull document Review
  - BURL document ready for last call? 
	- Private comments sent to Chris..need to be folded into new
document.
 	- WGLC to be sent, pick up final comments in that review
	- Alexey explicitly named to review document.
  - CATENATE
	- Not ready yet... 
	- How to edit message drafts save on server?  Apparent consensus not
to optimize at this time.
      - Desire is to have appropriate examples in the catenate document.  
	- Describe how to use and choice of simplicity in the profile
document
  - URLAUTH
	- Some editorial messages from Randy to be incorporated before or
after WGLC
	- Add some note text talking about revocation of tokens... if
administrator wants to use
		 stronger algorithm, Randy to contribute text.

Target for pull documents is last call after revised drafts posted before
the close of ID posting interval, with close of the WGLC at the Lemonade WG
meeting in Washington.

Channel
  - Current channel proposal is security challenged
  - GV restated model presented earlier in email as a starting place for
discussion

Open discussion resulted in the following new insights.  The problem space
was split into two

  A) Download of file types using existing IMAP connections.  Add request
for server-side 
	transcoding to the IMAP protocol somehow.
  B) Use URLAUTH to retrieve content from a streaming server using RTSP.
Negotiation is part of RTSP.  
	Some hand waving/work require needed to determine how to use the
URLAUTH in RTSP.

Substantial discussion was conducted to determine if the problem space
triggered any OPES considerations.  The consensus was that this work met the
requirements for explicit request and authorization of content stored in the
subscribers own mailbox.  Also, it was expected that the unmodified content
would remain in the mailbox for access by alternate clients or later times
when better connectivity is available.  A statement to the effect that the
server should never convert without a request from the client was seen as a
good idea.

WG also discussed the charter and convinced ourselves that charter item #1
implied a requirement to provide a mechanism for transcoding requests.

Requirements
  Client controls conversion
  No default conversion on server
  Message contents not changed on server after conversion
  Assumption is Conneg mechanism for IMAP download option.  Streaming
protocols have mechanism based on SDP?
  Go-fish content request mechanisms are bad...  try to reduce trips.
     - maybe client requests ordered list of formats

Discussion of IMAP compression

Presentation made by Aranaud Meylan  (available on VPIM web-site).
Discussion, interpolation, and guessing suggested that compression may be a
red-herring.  Compression of IMAP commands and responses appears to save few
if any packets and no round-trips.  Most text-messages seem short enough
that compression, while effective, does not save packets or round-trips, the
main costs.  Larger contents such as pictures, audio, and video are already
highly compressed.  

Compression tests were most valuable at winning back the base-64 encoding of
large attachments, to which the WG reached consensus that it would be better
to require use binary Fetch.

Various folks will work with Aranaud to better test these hypothesis with
additional testing and/or modeling.  

Rough consensus also achieved that if compression is needed, StartTLS with a
null cypher and compression seems to be the best approach. This also
leverages use of TLS for encryption which is expected to become commonly
available in handset OS's in the target timeframe.

There are some low-handing fruits that may be exploited to minimize IMAP
chattiness, but the working group decided not to complicate or delay
Lemonade 1.0 profile to figure how to exploit these opportunities.

Also some thought that if compression of specific media types such as
text/plain is desired, the conversion could be requested from the server
using the media conversion extensions.

Encryption at a basic "must implement" level appears to be necessary for
enterprise use.

Discussion of notification and Restart

The Lemonade profile will address the requirement for inband "instant"
notification of arrival of new 
messages.   The working group split the problem statement, agreeing that TCP
should survive the underlying networking coming and going.  In that case,
IMAP IDLE provides a good mechanism for notification of new messages.
However, given the widespread lack of support for good TCP behavior, the WG
will acknowledge the need for out-of-band notification that may stimulate a
sleeping client to efficiently reconnect and fetch messages.  

The group discussed a number of concepts but did not have any specific
proposals to review.  There was general interest in improving IMAP
synchronization rather than an explicit session token.  The interest is
motivated by the desire to have fast starts when using server pools and
connection after mid-to-long term disconnection.

Marketing and PR

The WG is enthusiastic, and after a review of charter milestones discussed
the need to engage a marketing-oriented group for PR and promotion of the
Lemonade profile.  Greg Vaudreuil was invited to present the work of the
Lemonade group to the TMIA, meeting in Vancouver in conjunction with the
Lemonade WG meeting :-).  The TMIA may be a reasonable choice to sponsor or
promote interoperability events and PR as and if necessary.

ACTION ITEMS:

Eric Burger will invent (with help) a lightweight mechanism for starting a
RTSP session based on a URLAUTH.  Due after November IETF meeting, but Eric
is expected to do some thinking in time for the WG meeting.

Lyndon Nerenberg will take a first stab, published in an ID before the
November IETF, for a capabilities declaration and transcoding request
mechanism within IMAP. 

Greg is supposed to capture the pictures of options A and B in ASCII art as
part of these minutes.

Randy to post a new version of the MMS mapping document addressing editorial
comments received.

Pete Resnik to post a new version of Catenate including some relevant
examples

Aranaud to iterate on the analysis of the benefits of compression.

Corby and Alexey will continue their collaboration on restart.

Respectfully submitted for WG review by Greg Vaudreuil

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

---

From: [email-masked]
Date: Fri, 22 Oct 2004 08:20:53 -0500

> Discussion of IMAP compression
...
> Encryption at a basic "must implement" level appears to be 

Is there a little more detail about what this means? At face value this would seem obvious, but the question is how?

Mike

---

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Fri, 22 Oct 2004 09:42:32 -0500

The observation was that all enterprises the assembled group is familiar with either use an encrypted VPN tunnel or SSL encryption of IMAP traffic.  VPN's were seen as impractical for limited resource devices and a major impediment to the use of IMAP in that target market.  Based on that, and the desire to support that market, it seems that a minimum must-implement encryption support makes sense in the base profile.    It was postulated that all mobile handsets will support SSL encryption in the Lemonade timeframe, likely in the OS, in support of various other functions such as secure web and e-commerce applications.    Details to be determined later.

Does this help?  Other comments?

Greg V.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 22, 2004 9:21 AM
To: [email-masked]; [email-masked]
Subject: RE: [lemonade] Draft Interim Minutes

...

Mike

---

From: [email-masked]
Date: Fri, 22 Oct 2004 09:51:28 -0500

Yes, this is helpful, and as expected. Thank You.

Mike

> From: ext Vaudreuil, Greg M (Greg) [mailto:[email-masked]]
> Sent: Friday, October 22, 2004 10:43 AM
> To: Wener Michael (Nokia-ES/Pittsburgh); [email-masked];
> [email-masked]
> The observation was that all enterprises the assembled group 
> is familiar with either use an encrypted VPN tunnel or SSL 
> encryption of IMAP traffic.  VPN's were seen as impractical 
> for limited resource devices and a major impediment to the 
> use of IMAP in that target market.  Based on that, and the 
> desire to support that market, it seems that a minimum 
> must-implement encryption support makes sense in the base 
> profile.    It was postulated that all mobile handsets will 
> support SSL encryption in the Lemonade timeframe, likely in 
> the OS, in support of various other functions such as secure 
> web and e-commerce applications.    Details to be determined later.
> 
> Is there a little more detail about what this means? At face 
> value this would seem obvious, but the question is how?
> 
> Mike
>

---

From: "Stephane H. Maes" <[email-masked]>
Date: Fri, 22 Oct 2004 08:07:49 -0700

Greg,

You should also mention the fact that if proxys are used outsid the enterprise domain, the messages should not be in the clear atteh proxy.

Stephane

_____
Stephane H. Maes, PhD,
Director of Architecture - Mobile, Oracle Corporation.
Ph: +1-203-300-7786 (mobile/SMS); Fax: +1-650-506-7222; Office UM: +1-650-607-6296.
e-mail: [email-masked]
IM: shmaes (AIM) or [email-masked] (MSN Messenger)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Vaudreuil, Greg M (Greg)
Sent: Friday, October 22, 2004 7:43 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [lemonade] Draft Interim Minutes

Greg V.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 22, 2004 9:21 AM
To: [email-masked]; [email-masked]
Subject: RE: [lemonade] Draft Interim Minutes

...

Mike

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

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

---

From: [email-masked]
Date: Fri, 22 Oct 2004 11:51:05 -0500

Was this split deployment discussed? 

What I mean by split is where two servers, one proxying for the other and both IMAP protocol aware, are split between two organizations that do not trust each other.

Mike

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of ext Stephane H. Maes
> Sent: Friday, October 22, 2004 11:08 AM
> To: [email-masked]
> You should also mention the fact that if proxys are used 
> outsid the enterprise domain, the messages should not be in 
> the clear atteh proxy.
> 
> Stephane
> 
> _____
> Stephane H. Maes, PhD,
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Vaudreuil, 
> Greg M (Greg)

---

From: "Stephane H. Maes" <[email-masked]>
Date: Fri, 22 Oct 2004 10:03:56 -0700

Yes as a use case that de facto exists today in mobile e-mail deployments.
Stephane
_____
Stephane H. Maes, PhD,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, October 22, 2004 9:51 AM
To: [email-masked]; [email-masked]
Subject: RE: [lemonade] Draft Interim Minutes

Mike

> > Encryption at a basic "must implement" level appears to be necessary 
> > for enterprise use.
>