[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Treat as a WGLC: draft-martin-managesieve-10.txt
On Mon, Jul 7, 2008 at 11:45 PM, Aaron Stone <aaron@xxxxxxxxxxxxxx> wrote:
> On Jul 7, 2008, at 3:29 PM, Robert Burrell Donkin wrote:
>> On Mon, Jul 7, 2008 at 10:54 PM, Aaron Stone <aaron@xxxxxxxxxxxxxx> wrote:
>>> Wait, top-post here says, "is there a point to the discussion going on
>> i'm confused: which top post? this top post you're posting now? (or
>> another that gmail has helpfully hidden)
> My top post, i.e. this sub-thread.
>>> Are you suggesting that we not bring managesieve to publication as an
>> if the aim is codification of existing practice then since i am not an
>> existing practioner of this particular protocol, how can i object?
>> it's been made quite clear to me that this is the priority of this RFC
>> is not quality but compatibility
> Ok, cool.
in future, i'll save my criticisms for other forums and i'll try to
refrain from replying to flames
i did turn up some specific points when i looked through the draft.
FWIW here are some of them
> 1.2 Syntax
> The BYE response may be used if the server wishes to close the
> connection. A server may wish to do this because the client was idle
> for too long or there were too many failed authentication attempts.
> This response can be issued at any time and should be immediately
> followed by a server hang-up of the connection. If a server has a
> inactivity timeout resulting in client autologout it MUST be no less
> than 30 minutes.
1. too verbose: the justification in secnd paragraph is not needed;
2. unclear: using 'MAY' makes the intent of the protocol unclear.
changing this to SHOULD would allow the client to infer abnormal
shutdown from it's absence.
3. the autologout timeout requirement is evil. this requirement gains
little from a client perspective (client needs to be able to cope
robustly with connection failures) at a high cost from the server
perspective (holding connections on the server limits scalability and
client agent identity and capabilities
the draft lacks a mechanism which allows a client libraries to
identify themselves or their capabilities. if it were possible for
servers to identify clients then workarounds could be applied just for
particular clients with known bugs. as this draft stands, servers are
forced to apply workarounds for all clients. this (in turn) means the
de juru standard tends to drift from the de facto one.
the draft does not indicate the right way to deal with input that
cannot be parsed. perhaps server SHOULD deal with malformed input by
issuing a BYE followed by an appropriate response code.
the specification mentions "newlines" in a couple of places. it would
be clearer to specify what's meant by this eg CRLF (if that's what's
>>> Are you suggested what we can do for a next-generation sieve management
>> Alexey Melnikov's comments about a next generation protocol
>> compatiable with IMAP make a lot more sense to me. it seems to me that
>> an independent protocol would be much more widely useful if it did not
>> adopt the IMAP style.
> Yeah, I think so, too. Unless we exposed the protocol through IMAP somehow,
> which I'm still a fan of doing, if possible.
i'm interested in this
> Thanks for clearing up the angle you're approaching this from.
i plan to use RESTful HTTP. i believe that approach has many
advantages over this draft and may encourage easier interoperability
amongst the general development community.