Re: Treat as a WGLC: draft-martin-managesieve-10.txt

["Robert Burrell Donkin" <robertburrelldonkin@xxxxxxxxx>]

On Mon, Jul 7, 2008 at 1:18 PM, Alexey Melnikov
<alexey.melnikov@xxxxxxxxx> wrote:
> Robert Burrell Donkin wrote:
>
>> On Mon, Jul 7, 2008 at 9:21 AM, Stephan Bosch <stephan@xxxxxxxxxxxx>
>> wrote:
>>
>> <snip>
>>
>>>
>>> Ok, I did some preliminary implementation of the new commands. Regarding
>>> the
>>> NOOP command I have only one (nitpicking) remark. The managesieve
>>> specification explicitly lists which commands are valid before
>>> authentication. However, by introducing extensions this becomes a little
>>> more sketchy. The RENAMESCRIPT command is clearly not useful before
>>> authentication. However, implementors with IMAP experience might think of
>>> allowing NOOP before authentication, because in IMAP the NOOP command
>>>  may
>>> be issued before authentication.
>>>
>>
>> failing to allow NOOP as may be expected violates the principle of
>> least surprise.
>>
>> is there any reason for this?
>>
>> in general, this protocol seems more than a little peculiar. it's
>> close in syntax to IMAP but has enough differences for IMAP
>> implementors to be surprised and confused by the differences.
>>
>> is there any reason for this choice?
>>
>
> The protocol is trying to stay backward compatible with CMU implementation
> (and there are many other client and server implementations that mimic it).
> If I were to design a new protocol from scratch, I would have made it as
> similar to IMAP as possible. But due to existing deployments, I don't think
> this would be a good option.

i can see that's a tough choice: codification of existing (possibly
dubious but at least well understood) practice verses the creation of
a better protocol

it seems unfortunate that this means that a separate port is required
for sieve management. a compatible extension to IMAP would allow sieve
management using the same URI.

- robert