Hi Stephan,
I am responding to the rest of your comments:
Stephan Bosch wrote:
2.1:
[...]
Why SCRAM?
I am glad that somebody has noticed :-).
I might be too ambitious in this case: I would like to require a SASL
mechanism that doesn't pass password to the server (like SASL PLAIN) and
can be used without TLS. DIGEST-MD5 mechanism would have been my
preferred mechanism a couple of years ago. But the current SASL WG
thinking is that it has too many interop issues and is too hard to
implement. That is why I have SCRAM in the document.
So I think now is good time for having a discussion about which
mandatory-to-implement SASL mechanism we should have in ManageSieve. For
short term and medium term (3 years).
[...]
2.11.3:
- NOOP: why expect a NO response from older servers? It is advertised
as a capability; if it is not advertised, don't issue the NOOP command.
Right.
I've removed the following sentence:
Older servers may not understand the NOOP command and robust clients
SHOULD be prepared to receive a NO response.
[...]
General:
- The described protocol is both referred to as "ManageSieve" and
"Manage Sieve" (e.g. IANA Considerations)
Ok, I've changed "Manage Sieve" to "ManageSieve" everywhere in the document.
I hope this review is useful. I'll try to update my implementation to
match the most recent changes in the coming week or so.