Subject: [lemonade] WGLC draft-ietf-lemonade-compress-02.txt

From: "Burger, Eric" <[email-masked]>
Date: Thu, 20 Jul 2006 15:17:57 -0400

The Work Group Last Call for draft-ietf-lemonade-compress-02.txt will
close 5 August 2006.  Please prepend the string "WGLC compress-02" to
the subject line of your comments.

Thank you.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-compress-02.txt

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

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 21 Jul 2006 00:56:40 +0100

>http://www.ietf.org/internet-drafts/draft-ietf-lemonade-compress-02.txt
I think the document is in a good shape, but at least one more revision 
is needed.
(Also, Dave has a real implementation issue with this extension, but I 
let him report it.)

 >2.  Introduction and Overview
[...]
 >    The goal of COMPRESS=DEFLATE is to reduce the bandwidth usage of
 >    IMAP.  On regular IMAP connections, the PPP or MNP compression used
 >    with many low-bandwidth links compresses IMAP well. However, when
 >    TLS is used, PPP/MNP compression is ineffective. TLS too may provide
 >    compression, but a careful IMAP implementation can do much better.

I don't like the last sentence. It doesn't provide any explanation on 
why TLS compression is worse.

 >    In order to increase interoperation, it is desirable to have as few
 >    different compression algorithms as possible, so this document
 >    specifies only one.  The DEFLATE algorithm is standard, widely
 >    available, unencumbered by patents and fairly efficient.  Hopefully
 >    it will not be necessary to define additional algorithms.

I think a reference to the DEFLATE algorithm description is needed the 
first time it is mentioned.

 >3.  The COMPRESS Command
[...]
 >    If both [STARTTLS] and COMPRESS are in use, the data should be

SASL is not listed here, but listed below. I suggest to change the 
beginning of the first sentence to read:

 >    If both [STARTTLS]/SASL security layer [SASL][IMAP] and COMPRESS 
are in use, the data should be

 >    compressed before it is encrypted (and decrypted before it is
 >    decompressed), independent of the order in which the client issues
 >    COMPRESS, AUTHENTICATE and STARTTLS.

Section 3 doesn't describe when exactly compression starts in both 
directions. Suggested text:

      Compression takes effect immediately following the
      CRLF that concludes the COMPRESS command for the client,
      and the CRLF of the tagged OK response for the server.

 >4.  Compression Efficiency

This is not a big deal, but I would recommend moving this into 
Informative Appendix.

 >5.  Formal Syntax
[...]
 >        command-any =/ compress
 >
 >        compress    = "COMPRESS" SP algorithm
 >
 >        algorithm   = "DEFLATE"

Does this mean that sending DEFLATE as quoted string (or literal) is not 
allowed?

I would rather see the following:

        algorithm   = astring
                            ;; Only "DEFLATE" is registered by this document

Or if you really want to use atom:

        algorithm   = atom
                            ;; Only "DEFLATE" is registered by this document

BTW, be prepared to answer IESG why you don't want an IANA registry.

 >6.  Security Considerations
 >
 >    As for [TLSCOMP] RFC 3749.

That is probably Ok, but wouldn't it be better to cut&paster Security 
Considerations from RFC 3749 and do explicit acknowledgment of the 
copied text?

 >9.1. Normative References
 >
 >    [IMAP]     Crispin, "Internet Message Access Protocol - Version
 >               4rev1", RFC 3501, University of Washington, June 2003.

[...]

 >    [STARTTLS] Newman, C. "Using TLS with IMAP, POP3 and ACAP", RFC
 >               2595, June 1999.

This reference got replaced by RFC 3501, drop it.
*
*

---

From: Dave Cridland <[email-masked]>
Date: Fri, 21 Jul 2006 11:47:03 +0100

> BTW, be prepared to answer IESG why you don't want an IANA registry.

I asked Arnt about this in private mail a while back, and Arnt's 
response was that currently, there was little need for the complexity 
when we have effectively a single unencumbered candidate. (In fact, 
LZW is now out of patent, if memory serves, but implementations are 
fewer). We would, in any case, have to mandate DEFLATE support for 
interoperability purposes.

I actually think that a better way forward would be to define a 
distinct document which created the IANA registry and populated it 
with DEFLATE as the MTI, and then subsequently this document would 
then reference it. Subsequent documents providing an ESMTP analogue 
of this document would do the same.

However, the latter path is going to take longer and delay this 
document.

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: Dave Cridland <[email-masked]>
Date: Fri, 21 Jul 2006 11:47:12 +0100

On Fri Jul 21 10:45:38 2006, Alexey Melnikov wrote:
> Dave Cridland wrote:
> 
>> 3) In section 3 (The COMPRESS Command), it would be useful if the 
>> example showed a DIGEST-MD5 or GSSAPI layer negotiating a security 
>> layer in SASL. Whilst the combination of TLS and a SASL security 
>> layer is unlikely, the contrived example would clearly show where 
>> the compression layer takes effect.
> 
> I was thinking about this, but saying that COMPRESS happens [when 
> sending] before SASL and TLS is sufficient, as the order of SASL 
> and TLS encryption is detailed in other specs.
> Oh wait, RFC 3501 is silent on relative order of TLS and SASL 
> security layer encryption, because it was written to conform to RFC 
> 2222, but this issue was identified later in RFC 4422.
> 
> 
I still think the example would be more useful if it showed the 
complex case. In particular, the current example doesn't show the 
layer insertion that's somewhat unique to this specification.

Essentially, we're looking at the layers changing from:

IMAP/TCP =STARTTLS=> IMAP/TLS/TCP =COMPRESS=> IMAP/COMPRESS/TLS/TCP 
=AUTHENTICATE=> IMAP/COMPRESS/SASL/TLS/TCP

Of course, when you show the IMAP layer, the layer insertion looks 
rather mundane.

>> 4) I'm not clear if a security considerations section which merely 
>> points to an informative reference is a good idea or not. Maybe 
>> that reference needs to be normative?
> 
> Yes, this relates to my comment about cut&pasting the text.
> 
> 
I'm actually okay with a normative reference, thinking about it, as 
it hopefully means that a new TLS compression RFC would be examined 
for new Security Considerations. Perhaps, though, key considerations 
could be cut and pasted as well.

Dave.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 21 Jul 2006 11:57:57 +0100

Dave Cridland wrote:

> then reference it.

After writing draft on comparators Arnt should be an expert on IANA 
registrations ;-).

> Subsequent documents providing an ESMTP analogue of this document 
> would do the same.

Sure. Can we just reuse an existing registry?

> However, the latter path is going to take longer and delay this document.

Yes.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 21 Jul 2006 10:45:38 +0100

Dave Cridland wrote:

> layer in SASL. Whilst the combination of TLS and a SASL security layer 
> is unlikely, the contrived example would clearly show where the 
> compression layer takes effect.

I was thinking about this, but saying that COMPRESS happens [when 
sending] before SASL and TLS is sufficient, as the order of SASL and TLS 
encryption is detailed in other specs.
Oh wait, RFC 3501 is silent on relative order of TLS and SASL security 
layer encryption, because it was written to conform to RFC 2222, but 
this issue was identified later in RFC 4422.

> points to an informative reference is a good idea or not. Maybe that 
> reference needs to be normative?

---

From: Tony Hansen <[email-masked]>
Date: Fri, 21 Jul 2006 10:02:30 -0400

The complexity of adding a single section to the IANA Considerations
seems pretty minimal to me. (I've written a few and didn't find them
onerous at all.)

	Tony Hansen
	[email-masked]

Dave Cridland wrote:
> when we have effectively a single unencumbered candidate. (In fact, LZW
> is now out of patent, if memory serves, but implementations are fewer).
> We would, in any case, have to mandate DEFLATE support for
> I actually think that a better way forward would be to define a distinct
> document which created the IANA registry and populated it with DEFLATE
> as the MTI, and then subsequently this document would then reference it.
> Subsequent documents providing an ESMTP analogue of this document would
> do the same.
>

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 22 Jul 2006 19:49:48 +0100

Mark Crispin wrote:

> On Fri, 21 Jul 2006, Alexey Melnikov wrote:
>
> However, RFC 3501 does say that STARTTLS must happen before 
> AUTHENTICATE. That pretty much defines the order unambiguously.

And the order is ...?
Most of the new protocols say that TLS is always below SASL security 
layer, no matter in which order they were negotiated (e.g. LDAP allow 
STARTTLS after SASL). The main argument here is that TLS is frequently 
provided by OS.

---

From: Mark Crispin <[email-masked]>
Date: Sat, 22 Jul 2006 20:56:59 -0800

On Sat, 22 Jul 2006, Alexey Melnikov wrote:
>>> layer encryption, because it was written to conform to RFC 2222, but this 
>>> issue was identified later in RFC 4422.
>> However, RFC 3501 does say that STARTTLS must happen before AUTHENTICATE. 
>> That pretty much defines the order unambiguously.
> And the order is ...?
> Most of the new protocols say that TLS is always below SASL security layer, 
> no matter in which order they were negotiated (e.g. LDAP allow STARTTLS after 
> SASL). The main argument here is that TLS is frequently provided by OS.

I'm surprised that LDAP allows STARTTLS after SASL.  What's the point of 
allowing that?

As far as I'm concerned, it only makes sense to have TLS below the SASL 
security layer.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: Mark Crispin <[email-masked]>
Date: Fri, 21 Jul 2006 09:05:59 -0800

On Fri, 21 Jul 2006, Alexey Melnikov wrote:
> Oh wait, RFC 3501 is silent on relative order of TLS and SASL security layer 
> encryption, because it was written to conform to RFC 2222, but this issue was 
> identified later in RFC 4422.

-- Mark --

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 24 Jul 2006 12:35:45 +0100

Mark Crispin wrote:

> As far as I'm concerned, it only makes sense to have TLS below the 
> SASL security layer.

I agree with that, but can this be clarified in 3501 errata in order to 
avoid all doubts?

---

From: Randall Gellens <[email-masked]>
Date: Fri, 28 Jul 2006 15:29:30 -0700

At 3:17 PM -0400 7/20/06, Eric Burger wrote:

>  Please prepend the string "WGLC compress-02" to

Oops -- sorry, I forgot to do that.  [Comments in previous message.]
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The Macintosh may only have 10% of the market, but it is clearly
the top 10%.
       --Douglas Adams, 1996 WWDC.

---

From: Randall Gellens <[email-masked]>
Date: Fri, 28 Jul 2006 15:33:03 -0700

At 12:51 AM +0100 7/21/06, Dave Cridland wrote:

>  1) The abstract is confusing, implying as it does that TLS prevents 
> compression. This is only so for the types of link-level 
> compression later referred to in the draft, but I'm not aware of 
> high deployment of these outside traditional POTS modems.

Yes, this text can be improved.

>  6) Section 4 (Compression Efficiency) should, I think, be an 
> appendix. It's providing useful implementation notes, but is not 
> essential.

It is useful, it is advice, and it does not contain normative terms. 
But I think it's fine as a section.  I don't see a benefit in 
demoting it to a mere appendix.

-------------- Randomly-selected tag: ---------------
Few ideas are really bad.  Most are either pre- or post-mature.
                                                   --Jon Postel

---

From: Randall Gellens <[email-masked]>
Date: Fri, 28 Jul 2006 15:39:26 -0700

At 12:56 AM +0100 7/21/06, Alexey Melnikov wrote:

>   >    If both [STARTTLS]/SASL security layer [SASL][IMAP] and 
> COMPRESS are in use, the data should be
>

I think "both" becomes confusing when the first half includes two 
protocols.  Perhaps:

	If a security layer such as [STARTTLS] or [SASL] is used with COMPRESS,
	the data should be compressed before....

>  BTW, be prepared to answer IESG why you don't want an IANA registry.

May as well say clearly in the document that "deflate is the only 
currently defined mechanism.  Additional mechanisms are not expected 
to be required, but if so can be created by future RFCs which extend 
this document."
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Television is simply automated day-dreaming.
       --Lee Lovinger, _Quote_, July 30, 1967

---

From: Philip Guenther <[email-masked]>
Date: Fri, 28 Jul 2006 16:02:41 -0700

> At 12:56 AM +0100 7/21/06, Alexey Melnikov wrote:
...
> May as well say clearly in the document that "deflate is the only currently 
> defined mechanism.  Additional mechanisms are not expected to be required, 
> but if so can be created by future RFCs which extend this document."

For consistency, I suggest copying the text that the SORT/THREAD doc, 
draft-ietf-imapext-sort-17.txt, uses to describe the extensions and the 
registries.  To quote parts of that doc's Introduction and IANA 
Considerations sections:
     A server which supports the THREAD extension indicates this with one
     or more capability names consisting of "THREAD=" followed by a
     supported threading algorithm name as described in this document.
     This provides for future upwards-compatible extensions.
...
     This document creates a new [IMAP] threading algorithms registry, which
     registers threading algorithms by publishing a standards track or IESG
     approved experimental RFC.  This document constitutes registration of
     the ORDEREDSUBJECT and REFERENCES algorithms in that registry.

Philip Guenther

---

From: Randall Gellens <[email-masked]>
Date: Fri, 28 Jul 2006 17:20:36 -0700

At 4:02 PM -0700 7/28/06, Philip Guenther wrote:

>> currently defined mechanism.  Additional mechanisms are not 
>> expected to be required, but if so can be created by future RFCs 
>> which extend this document."
>
>  For consistency, I suggest copying the text that the SORT/THREAD 
> doc, draft-ietf-imapext-sort-17.txt, uses to describe the 
> extensions and the registries.  To quote parts of that doc's 
> Introduction and IANA Considerations sections:

Sorry for not being clear: I don't think we need an IANA registry, 
because we don't expect to define future mechanisms.  If we find that 
we do need other mechanisms, we can define those in new RFCs that 
extend this one.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
He had occasional flashes of silence that made his conversation
perfectly delightful.                            --Sydney Smith

---

From: Philip Guenther <[email-masked]>
Date: Fri, 28 Jul 2006 20:01:44 -0700

> Sorry for not being clear: I don't think we need an IANA registry, because we 
> don't expect to define future mechanisms.  If we find that we do need other 
> mechanisms, we can define those in new RFCs that extend this one.

I don't think we expect to see future THREAD mechanisms either, but it's 
apparently simpler and less contentious to create a registry than it is to 
_not_ do so.  As author/editor/review time is the most precious commodity 
in the IETF, creating the registry and copying text to do so that people 
have already nodded their heads at seem like the most efficient choice.

Philip Guenther

---

From: Mark Crispin <[email-masked]>
Date: Fri, 28 Jul 2006 20:15:09 -0700

On Fri, 28 Jul 2006, Philip Guenther wrote:
> _not_ do so.  As author/editor/review time is the most precious commodity in 
> the IETF, creating the registry and copying text to do so that people have 
> already nodded their heads at seem like the most efficient choice.

Excellent point.

It's also important to note that creating a registry is a great way to 
prevent bad ideas from getting into a protocol.  If you don't have a 
registry, then everybody who thinks that he has a Very Important Idea will 
fillibuster the specification until the bad idea is added to the 
specification.  With a registry, the people with VIIs have an outlet, but 
then have to make the VII stand on its own (which few VIIs will actually 
accomplish).

-- Mark --

---

From: Tony Hansen <[email-masked]>
Date: Mon, 31 Jul 2006 10:05:31 -0400

+1

Philip Guenther wrote:
> apparently simpler and less contentious to create a registry than it is
> to _not_ do so.  As author/editor/review time is the most precious
> commodity in the IETF, creating the registry and copying text to do so
> that people have already nodded their heads at seem like the most
> efficient choice.