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

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

On Mon, Jul 7, 2008 at 10:06 PM, Aaron Stone <aaron@xxxxxxxxxxxxxx> wrote:
>
> On Jul 7, 2008, at 1:40 PM, Robert Burrell Donkin wrote:
>
>>
>> On Mon, Jul 7, 2008 at 9:23 PM, Jeffrey Hutzelman <jhutz@xxxxxxx> wrote:
>>>
>>> --On Monday, July 07, 2008 08:27:59 PM +0100 Robert Burrell Donkin
>>> <robertburrelldonkin@xxxxxxxxx> wrote:
>>
>> <snip>
>>
>>>> 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.
>>>
>>> That makes the assumption that sieve scripts live only in IMAP servers,
>>> which I don't think we want to do.
>>
>> not at all :-)
>>
>> the function contained in this protocol is really very trivial. i
>> doubt that any implementator using a storage mechanism other than IMAP
>> would bother creating an implementation rather than just reusing their
>> preferred protocol at the application level. for example, HTTP is a
>> well known protocol whose secruity characterics are know well
>> understood. sieve maintainance using RESTful HTTP would be much
>> simpler than creating an implementations of this novel protocol.
>
> There are at least a dozen client and server implementations of this
> protocol that exist and interoperate and have been doing so for several
> years, so on that issue your point is negated by fact.

how many implementations are not IMAP servers?

> Further, HTTP is dramatically more complicated than this protocol, and I
> challenge the notion that its security is actually well understood enough to
> be applied to other applications without some seriously thorough and careful
> thinking. The only thing HTTP really buys you is the ability to re-use
> existing HTTP server frameworks. This is generally not a benefit to authors
> of email software, since most of us have already written our own server
> frameworks for IMAP and SMTP and the like.

yes but the point was predicated on the apparent requirement that this
protocol should be usable beyond the community of email server
creators. yes, anyone who's spent time writing email servers will be
comfortable but that community is small. other users are likely to
find it much easier to reuse an existing protocol.

- robert