Subject: [lemonade] Re: Last Call: draft-gulbrandsen-imap-enable (The IMAP ENABLE Extension) to Proposed Standard

From: Alexey Melnikov <[email-masked]>
Date: Tue, 15 Jan 2008 19:12:16 +0000

The IESG wrote:

>The IESG has received a request from an individual submitter to consider
>the following document:
>
>- 'The IMAP ENABLE Extension '
>   <draft-gulbrandsen-imap-enable-05.txt> as a Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send substantive comments to the
>[email-masked] mailing lists by 2008-01-16. Exceptionally, 
>comments may be sent to [email-masked] instead. In either case, please 
>retain the beginning of the Subject line to allow automated sorting.
>
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-gulbrandsen-imap-enable-05.txt
>  
>
So far I've only seen one minor comment from a Gen-Art reviewer who 
spotted that RFC 2177 is no longer referenced.
If you have more substantial comments, please send them before tomorrow.

One possible change to ENABLE was suggested by Cyrus on the mailing list 
when discussing CONVERT capability discovery, see
<http://www1.ietf.org/mail-archive/web/lemonade/current/msg04269.html>

A possible solution for this would be to change the ENABLE command to 
allow arbitrary parameters to capabilities enclosed in (), e.g.

tag1 ENABLE CONVERT (("TEXT" "HTML") ("TEXT" "PLAIN" "FORMAT" ("FLOWED" 
"FIXED")) ("TEXT" "*" "CHARSET" ("UTF-8" "US-ASCII")) ("IMAGE" ("JPEG" 
"PNG" "GIF") "PIX-X" "240" "PIX-Y" "320"))

Servers would be required to ignore parameters for capabilities they 
don't understand.

My personal opinion about this change: While I don't feel strongly 
against this change I am not convinced that it is needed. Besides, the 
way ENABLE is defined, we can get away without it. Multiple ENABLE 
commands are additive. A client can send each capability with parameters 
in a separate ENABLE command, as shown above. A server that doesn't 
recognize this would reject such ENABLE with BAD.

Thoughts?

Alexey

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 15 Jan 2008 21:37:29 +0100

Alexey Melnikov writes:
> One possible change to ENABLE was suggested by Cyrus on the mailing 
> list when discussing CONVERT capability discovery, see
> tag1 ENABLE CONVERT (("TEXT" "HTML") ("TEXT" "PLAIN" "FORMAT" 
> ("FLOWED" "FIXED")) ("TEXT" "*" "CHARSET" ("UTF-8" "US-ASCII")) 
> ("IMAGE" ("JPEG" "PNG" "GIF") "PIX-X" "240" "PIX-Y" "320"))
>

ENABLE so far has been about enabling server-side behaviour by explicit 
command instead of as a side effect of another command.

This change would add a general parameter facility for IMAP extensions. 
Instead of just being on/off, IMAP extensions would now have complex 
paramaters.

I have two comments on that.

1. Most importantly, adding something that big one day before the end of 
IETF LC is really bad. I might even raise an appeal to prevent that, to 
make sure we get proper discussion and a new last call. It's unfair on 
reviewers to more than double the complexity of an extension one day 
before the end of IETF LC.

2. Less importantly, I'm not sure it's called for. We have only one use 
case, and it's not even an awfully strong use case. (Should I make an 
alternative suggestion for CONVERT? Not in this thread.)

Arnt

---

From: Dave Cridland <[email-masked]>
Date: Tue, 15 Jan 2008 20:49:24 +0000

On Tue Jan 15 20:40:06 2008, Mark Crispin wrote:
> +1
I'm in broad agreement.

> On Tue, 15 Jan 2008, Arnt Gulbrandsen wrote:
>> Alexey Melnikov writes:
>>> One possible change to ENABLE was suggested by Cyrus on the  
>>> mailing list when discussing CONVERT capability discovery, see
>>> A possible solution for this would be to change the ENABLE  
>>> command to allow arbitrary parameters to capabilities enclosed in  
>>> (), e.g.
>>> 
>>> Servers would be required to ignore parameters for capabilities  
>>> they don't understand.
>> 
>> ENABLE so far has been about enabling server-side behaviour by  
>> explicit command instead of as a side effect of another command.
>> 
>> This change would add a general parameter facility for IMAP  
>> extensions. Instead of just being on/off, IMAP extensions would  
>> now have complex paramaters.
>> 
>> 1. Most importantly, adding something that big one day before the  
>> end of IETF LC is really bad. I might even raise an appeal to  
>> prevent that, to make sure we get proper discussion and a new last  
>> call. It's unfair on reviewers to more than double the complexity  
>> of an extension one day before the end of IETF LC.
>> 
>> 
+1 on this argument, and I think this argument is sufficient.

>> 2. Less importantly, I'm not sure it's called for. We have only  
>> one use case, and it's not even an awfully strong use case.  
>> (Should I make an alternative suggestion for CONVERT? Not in this  
>> thread.)

I'm not convinced that a generic mechanism is called for.  
Architecting such a mechanism is not going to be trivial, especially  
with only one sketched out use-case.

Especially when I've got my own concerns with whether my own proposal  
satisfies the requirements of client developers as well as it should.

FWIW, I'm happy with ENABLE as-is.

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: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 15 Jan 2008 21:55:40 +0100

Huh. On rereading, the tone of that missive is a leeetle stronger than I 
intended. Sorry about that.

---

From: Mark Crispin <[email-masked]>
Date: Tue, 15 Jan 2008 12:40:06 -0800 (PST)

+1

On Tue, 15 Jan 2008, Arnt Gulbrandsen wrote:
>> A possible solution for this would be to change the ENABLE command to allow 
>> arbitrary parameters to capabilities enclosed in (), e.g.
>> 
>> Servers would be required to ignore parameters for capabilities they don't 
>> understand.
>
> 1. Most importantly, adding something that big one day before the end of IETF 
> LC is really bad. I might even raise an appeal to prevent that, to make sure 
> we get proper discussion and a new last call. It's unfair on reviewers to 
> more than double the complexity of an extension one day before the end of 
> IETF LC.
>
> 2. Less importantly, I'm not sure it's called for. We have only one use case, 
> and it's not even an awfully strong use case. (Should I make an alternative 
> suggestion for CONVERT? Not in this thread.)
>
> Arnt
>
>

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.