On Mon, Jul 7, 2008 at 11:45 PM, Aaron Stone <aaron(_at_)serendipity(_dot_)cx>
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(_at_)serendipity(_dot_)cx> wrote:
Wait, top-post here says, "is there a point to the discussion going on
here?"
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.
thanks
Are you suggesting that we not bring managesieve to publication as an
RFC?
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
complicates implementation).
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.
BAD input
----------------
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.
"newlines"
----------------
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
meant).
Are you suggested what we can do for a next-generation sieve management
system?
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.
+1
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.
- robert