Subject: RE: [lemonade] Call the Question - Compression: TLSor Application-layer

From: "Stephane H. Maes" <[email-masked]>
Date: Thu, 7 Oct 2004 11:28:26 -0700

I am getting more and more convinced that the differences of opinion are at the level of the use cases and assumptions on what the technical solution is. We have different views on how the mobile issues can be addressed and the work of carefully crafting the use cases and requirements in a technology agnostic manner may have to be revisited.

I am not advocating and I agree that it would be ridiculous to duplicate encryption, compression or any other technology if already provided in ways that fulfill the requirements. That's not the goal. However, I do believe that there are use cases that we can't support today and need to find ways to address.

We should discuss this more in details in Vancouver.

More in line below marked as <SM> .... </SM>.

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 Lyndon Nerenberg
Sent: Tuesday, October 05, 2004 11:43 PM
To: Stephane H. Maes; [email-masked]
Subject: RE: [lemonade] Call the Question - Compression: TLSor Application-layer

--On 2004-10-5 10:37 PM -0700 "Stephane H. Maes" 
<[email-masked]> wrote:

> I think that I have answered your other requests for clarifications in 
> answers to previous e-mails. Let me know if something requires more 
> details.

Well I've read through the whole discussion a couple of times now, and 
I still can't see a non-hypothetical reason why we would need to add 
compression and encryption to IMAP.

>From an engineering standpoint, adding these to the application
protocol -- when both are already provided for in the protocol -- makes 
no sense at all. 
<SM> Agreed BUT I do believe (and that's where we differ) that there are cases where we may not be able to rely on the same transport mechanisms and may not be able to use STARTTLS or it is not sufficient and I think that they are in scope of our work. And so I believe that more needs to be done to support these cases and vendors will do that investments if they want to support such cases i.e. if there is a market demand for it.</SM>
 
You're making the argument that a client and a server, 
each of which chooses to *not* implement STARTTLS (as is *mandated* by 
RFC3501) are going to implement an optional extension. 

<SM> Not exactly. I am stating that a client may not be implementing RFC3501 but whatever will be the lemonade profile. Hence STARTTLS may not apply or as re-explained below may not be sufficient. I am a bit confused BTW on the view that client and server WILL implement RFC3501. We are talking of a lemonade client talking to a lemonade server.... In my view, they may present variations with respevct to RFC3501 even if compatibility / interwworking with RFC3501 is to be addressed...</SM>

Some specific questions I have about this are:

1) Why would a vendor, who can't expend the effort to implement 
something *required* by the standard, implement something that isn't? 
Especially when by not implementing STARTTLS they are seriously 
restricting their customer base? 

<SM> Because they would want to support use cases / deployment patterns where STARTTLS can't be used (e.g. firewall with restricted opened ports) or does not address all aspects (e.g. end to end encryption when using a lemonade proxy. </SM>

2) Why would a vendor who *does* properly implement the standard want 
to expend developer resources to code up and support a completely 
redundant way of doing what STARTTLS was designed to do (and already 
does)?

<SM> I am not agreeing that profiles or extensions of a protocol are still the protocol... So may be we are miscommunicating. So for the sake of discussion, Lemonade profile may not mandate STARTTLS or transport that support STARTTLS... When the vendor selects not to use (e.g. to support other relevant use cases), there would not be any redundancy...</SM>

3) What would this extension provide that STARTTLS does not? I want to 
see a specific, real world example. You're going to be hard pressed to 
convince anyone of the need for this unless you can show a 
non-hypothetical case where STARTTLS does not work, and can not be made 
to work.

<SM> As one example: a Service Provider (operator) deploys a Lemonade proxy that communicates to lemonade clients and e-mail servers in enterprise domain. Encryption of the content of the messages is required to avoid messages in the clear in the SP proxy. The extension would allow to request such encryption.</SM>

--lyndon

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

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