Subject: Re: [lemonade] COMPRESS: last call comments

From: Randall Gellens <[email-masked]>
Date: Thu, 11 Jan 2007 18:47:58 -0800

At 2:35 PM -0800 12/18/06, Lyndon Nerenberg wrote:

>  Page 2:
>
>      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 (defined in [RFC1951]) is
>      standard, widely available, unencumbered by patents and fairly
>      efficient, so it is the only algorithm defined by this document.
>
>  More word-smithing :-)
>
>  	To ensure interoperability, every IMAP client and server
>  	supporting COMPRESS MUST support the DEFLATE [RFC1951]
>  	compression mechanism.
>
>  We could add some rationale, but I prefer keeping it simple.  We don't
>  need to make excuses for the choice, although it might be worth adding
>  something to discourage adoption of other mechanisms, citing the
>  pending deployment of TLS compression.

I like the explanation and justification.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The significant problems that we face today cannot be solved at the
same level of thinking that created them.         --Albert Einstein

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

---

From: Lyndon Nerenberg <[email-masked]>
Date: Thu, 11 Jan 2007 20:47:48 -0800

>>  	supporting COMPRESS MUST support the DEFLATE [RFC1951]

The pedant strikes again :-)  s/client and server/client or server/

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 17 Jan 2007 16:33:00 +0100

Lyndon Nerenberg writes:
> My problem is with this:
>
>     If the server issues an OK response, the server MUST compress
>     starting with the first response after the CRLF ending the OK
>     response.
>
> and in particular '... with the first response'.  If that was changed 
> to '... with the octet immediately following the CRLF terminating the 
> OK response.' that eliminates any ambiguity.

I am outvoted.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 17 Jan 2007 16:33:00 +0100

I am outvoted.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 17 Jan 2007 16:33:00 +0100

Lyndon Nerenberg writes:
> More last call comments on compress.  This are almost all editorial.

I did most of them. I did not split the TLS/COMPRESS list in two. Below 
I quote and comment only where where comments seem necessary.

> PPP and MNP should have informative references.

PPP is easy, RFC 1962. MNP... that took some time, but I found two 
references which should inform those who wish to be informed of such 
things (0-471-00852-4 and the ITU v42bis recommendation, now available 
on the web in PDF format).

> -------------------------------------------------------
> Page 2:
>
> need to make excuses for the choice, although it might be worth 
> adding something to discourage adoption of other mechanisms, citing 
> the pending deployment of TLS compression.

I can see the logic, but I don't want to make the change. Too many 
people didn't see anything wrong about the existing wording, and it's 
late.

> And could we move the examples into a separate, informative, section?

Are you really sure? The first often-quoted RFC I looked at contained 
dozens of examples in normative sections, so it's hardly unusual to 
have examples in normative sections.

Again, since so many people didn't see anything wrong and it's late, I 
don't want to make the change.

(I'll wait six hours, then submit -07.)

> -------------------------------------------------------
> Section 4:
>
>     This section is informative, not normative.
>
> And that sentence is redundant :-)  s/,.*$/./

So it is, and it's not the only redundancy in the draft. For example: 
«This syntax augments the grammar specified in [RFC3501]. [...] Except 
as noted otherwise, all alphabetic characters are case-insensitive.  
The use of upper or lower case characters to define token strings is 
for editorial clarity only.  Implementations MUST accept these strings 
in a case-insensitive fashion.»

Arnt

e.com>,
	Lyndon Nerenberg <[email-masked]>
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Lyndon Nerenberg writes:
> More last call comments on compress.  This are almost all editorial.

I did most of them. I did not split the TLS/COMPRESS list in two. Below 
I quote and comment only where where comments seem necessary.

> PPP and MNP should have informative references.

PPP is easy, RFC 1962. MNP... that took some time, but I found two 
references which should inform those who wish to be informed of such 
things (0-471-00852-4 and the ITU v42bis recommendation, now available 
on the web in PDF format).

> -------------------------------------------------------
> Page 2:
>
> need to make excuses for the choice, although it might be worth 
> adding something to discourage adoption of other mechanisms, citing 
> the pending deployment of TLS compression.

I can see the logic, but I don't want to make the change. Too many 
people didn't see anything wrong about the existing wording, and it's 
late.

> And could we move the examples into a separate, informative, section?

Are you really sure? The first often-quoted RFC I looked at contained 
dozens of examples in normative sections, so it's hardly unusual to 
have examples in normative sections.

Again, since so many people didn't see anything wrong and it's late, I 
don't want to make the change.

(I'll wait six hours, then submit -07.)

> -------------------------------------------------------
> Section 4:
>
>     This section is informative, not normative.
>
> And that sentence is redundant :-)  s/,.*$/./

So it is, and it's not the only redundancy in the draft. For example: 
«This syntax augments the grammar specified in [RFC3501]. [...] Except 
as noted otherwise, all alphabetic characters are case-insensitive.  
The use of upper or lower case characters to define token strings is 
for editorial clarity only.  Implementations MUST accept these strings 
in a case-insensitive fashion.»

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 17 Jan 2007 16:36:17 +0100

Alexey Melnikov writes:
> So I suggest changing this to:
>
>            NO The server doesn't support the requested mechanism, or
>               the compression mechanism is already active via another 
>               layer (e.g. TLS),
>
>>            BAD Command unknown, invalid argument, or COMPRESS already
>>                active.

I started by changing it as you suggest, but ended up with slightly 
different wording. (I used BAD for the case where the client sends an 
unadvertised mechanism.)

Arnt

---

From: Lyndon Nerenberg <[email-masked]>
Date: Wed, 17 Jan 2007 10:41:21 -0800 (PST)

> have examples in normative sections.

Remember AUTH=LOGIN?  Can you absolutely guarantee there is no conflict 
between the examples and the specification?

--lyndon

   The two most common elements in the universe are Hydrogen and stupidity.
   			-- Harlan Ellison

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 17 Jan 2007 20:36:51 +0100

Lyndon Nerenberg writes:
> Remember AUTH=LOGIN?  Can you absolutely guarantee there is no 
> conflict between the examples and the specification?

No, I can't guarantee that. But at this late stage, I want strong 
justification for each change (mostly so I won't accidentally add a bug 
after so many people have reviewed and blessed the text).

Arnt

---

From: Lyndon Nerenberg <[email-masked]>
Date: Wed, 17 Jan 2007 11:39:06 -0800 (PST)

> justification for each change (mostly so I won't accidentally add a bug after 
> so many people have reviewed and blessed the text).

Fair enough.

--lyndon

   I love to sing, and I love to drink scotch. Most people would rather
   hear me drink scotch.
   			-- George Burns