Subject: Re: [lemonade] COMPRESS=mumble

From: Alexey Melnikov <[email-masked]>
Date: Fri, 01 Sep 2006 14:16:13 +0100

Tony Finch wrote:

>On Fri, 25 Aug 2006, Ted Hardie wrote:
>  
>
>>There might be, of course, conditions later where no TLS is present and
>>compression is desired using some later non-TLS-friendly compression
>>algorithm.  But if I understand things correctly, that would be a change
>>in design goals, which seem to be at the moment "compression should
>>be tls-friendly" trending into "should be done in TLS" in the future.
>>    
>>
>
>"Later"? What about security layers negotiated with SASL? Are we expecting
>them to provide their own compression, or should they leave it to
>application level compression?
>  
>
In theory a SASL security layer can provide compression as well. Once 
upon a time I was toying with an idea to add compression to DIGEST-MD5.
But after COMPRESS=, I don't see much point. So I don't think we should 
worry about this.

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

---

From: Eric Burger <[email-masked]>
Date: Fri, 08 Sep 2006 16:55:05 -0400

Speaking as a long-time data base hacker (and the Professor in the title is
from when I taught Data Base Theory at GMU and GWU), and not strictly as
chair:

I can (happily) live with a separate compression table with two attributes.
One attribute is the compression method name (with some naming rules) and
the other is the reference for the compression method (like an RFC).  This
is 3NF at its best.  No dependencies, and updates in one place don't break
the relationships in another.

Anyone strongly object to a new IANA registry?

---

From: Randall Gellens <[email-masked]>
Date: Mon, 11 Sep 2006 14:43:23 -0700

>  Anyone strongly object to a new IANA registry?

So the proposal is for a new IANA registry for compression mechanisms 
for use in IMAP and (I assume) message submission?  This new registry 
to be totally independent of the existing IANA registry for 
compression mechanisms used in TLS?

What is the alternative?  Is it trying to fit the IMAP and message 
submission compression mechanisms into the TLS registry?  Or is it 
not using an IANA registry for IMAP or message submission?

As I've said before, I don't see any need for, nor benefit to having, 
an IANA registry for compression mechanisms in IMAP and message 
submission.  Could you or someone who is in favor of it please state 
the advantage?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Look out!  Behind you!

---

From: Tony Hansen <[email-masked]>
Date: Mon, 11 Sep 2006 22:30:50 -0400

I was on the side of creating a registry for the list of compression
mechanisms. However, given where we've circled around since then, I'm
going to come out on the other side. In support of that, I'm also
offering this IANA Considerations section for consideration:

	IANA Considerations

	[ This section may be removed at RFC publication time. ]

	Note to IANA: This RFC does *not* specify the creation of
	a registry for compression mechanisms. The current feeling of
	the IMAP community is that is is unlikely that another
	compression algorithm will be added in the future. However, if
	this RFC is extended in the future by another RFC, and another
	compression is added at that time, it would then be appropriate
	to create a registry.

This side steps the issue, and explains to both the IESG and IANA *why*
we're not going down that route at this time.

	Tony Hansen
	[email-masked]

Randall Gellens wrote:
>> I can (happily) live with a separate compression table with two 
>> attributes. One attribute is the compression method name (with some
>> naming rules) and the other is the reference for the compression
>> method (like an RFC). This is 3NF at its best. No dependencies, and
>> updates in one place don't break the relationships in another.
>>
> for use in IMAP and (I assume) message submission?  This new registry to
> be totally independent of the existing IANA registry for compression
> mechanisms used in TLS?
> 
> submission compression mechanisms into the TLS registry?  Or is it not
> using an IANA registry for IMAP or message submission?
> 
> As I've said before, I don't see any need for, nor benefit to having, an
> IANA registry for compression mechanisms in IMAP and message
> submission.  Could you or someone who is in favor of it please state the
> advantage?

---

From: Eric Burger <[email-masked]>
Date: Wed, 13 Sep 2006 07:12:25 -0400

I can buy the argument, "Do not write code that will not be used."

While it looks like we do not see a different algorithm being used, I can
already see the press releases in five years saying, "Lemonade is deficient
because it uses the old deflate algorithm.  We need to create a work group
to create a new / proprietary / different mail system."

Yes, weirder things have happened.

I would offer we just say that we have an extensible protocol mechanism that
may create a registry in the future.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 13 Sep 2006 21:41:12 +0200

(I've read the later messages, too.)

Tony Hansen writes:
>         Note to IANA: This RFC does *not* specify the creation of a 
>         registry for compression mechanisms. The current feeling of 
>         compression algorithm will be added in the future. However, 
>         if this RFC is extended in the future by another RFC, and 
>         another compression is added at that time, it would then be 
>         appropriate to create a registry.

I'll use something like that. I'll actually say that we expect that at 
some point, TLS compression will be used. Personally, I don't expect 
that to happen soon, but I do expect it to happen. Five years, maybe.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 15 Sep 2006 13:57:08 +0200

> I can buy the argument, "Do not write code that will not be used."

Particularly when people disagree what code to write and there's no 
concrete benefit to writing it today ;)

> While it looks like we do not see a different algorithm being used, I 
> can already see the press releases in five years saying, "Lemonade is 
> deficient because it uses the old deflate algorithm. We need to 
> create a work group to create a new / proprietary / different mail 
> system."
>
> I would offer we just say that we have an extensible protocol 
> mechanism that may create a registry in the future.

-04 does that: Creates no registry now and does not get in the way of 
creating a registry later. In particular the syntax is open enough.

If TLS compression is widely available with good enough APIs if/when 
another algorithm becomes desirable, I dare say we'll switch to using 
TLS compression.

I've just now sent -04 to the i-d editor. Thanks for being patient. The 
changes since -03: Some textual changes and minor clarifications as 
requested/recommended by various people. In particular there's a 
sentence to keep people from making a very easy mistake while 
implementing, and end up with RFC1950 data instead of RFC1952. And the 
big change: Creating an IANA registry is deferred to another document, 
and the reason is given (using text by Tony).

Arnt