Subject: WGLC on draft-ietf-sieve-managesieve-01.txt

From: Alexey Melnikov <[email-masked]>
Date: Sat, 01 Nov 2008 18:47:55 +0000

Hi folks,

draft-martin-managesieve already had an informal WG-like last call 
(before the Sieve WG rechartered). I've just posted 
draft-ietf-sieve-managesieve-01.txt that I believe addressed all major 
outstanding issues. Because the list of changes to the document is long, 
as one of the authors I think it is worth to have another WGLC to verify 
that they are Ok with the WG.

Now, with my co-chair hat on:

This message officially starts the Sieve Working Group Last Call for the 
following document:
A Protocol for Remotely Managing Sieve Scripts
<http://www.ietf.org/internet-drafts/draft-ietf-sieve-managesieve-01.txt>

The Working Group Last Call for this document starts on November 3rd and 
will end on November 21st (so it is almost 3 weeks, so that the IETF 
meeting in Dublin is covered).

Please send any comments to the Sieve mailing list or directly to me. If 
you chose to do the latter, please CC Cyrus Daboo <[email-masked]>.
Reviews that found no issues are also welcomed, so if you review the 
document and find it acceptable, please let the mailing 
list/authors+chairs know as well.

Thank you,
Alexey, Sieve WG co-chairs

---

From: Stephan Bosch <[email-masked]>
Date: Thu, 06 Nov 2008 12:10:52 +0100

Hello,

> list/authors+chairs know as well.
Since this is the last call, I decided to do a full review of the 
document. Thus far I have not implemented any of the recent 
changes/additions to the document, so I may find other issues when I do 
(hopefully before the 21st of November).

My review is structured in a per-section manner. Comments include typos, 
but also requests for clarification:

1.3:

- Use of example with 'the QUOTA/MAXSCRIPTS response' code is confusing. 
MAXSCRIPTS is not part of the standard, but the example does not mention 
that explicitly. Also, I can imagine that such detailed response can 
have some merit. So, why is it not included in the standard along with 
something like MAXSIZE?

- Typos in explanation of NONEXISTENT and ALREADYEXISTS : 
s/references/referenced.

1.7:

- Example at the end of this section lists STARTTLS after 
authentication, which is strange considering that STARTTLS is only valid 
in a non-authenticated state.

- Explain the purpose of the OWNER capability. Common question would be: 
clients already know their identity, so why advertise it as a 
capability? Also, in my mind, listing status information in a capability 
response seems hardly appropriate.

2.1:

- From text: "When both [TLS] and SASL security layers are in effect, 
the TLS encoding MUST be applied (when sending data) after the SASL 
encoding, regardless of the order in which the layers were negotiated." 
Isn't this order fixed correctly already by the fact that the STARTTLS 
command is only valid before authentication(== SASL and any security 
layer it may install). I mean that I do not see how the layers can be 
negotiated in a different order.

- From text: "To ensure interoperability, client and server 
implementations of this extension MUST implement the [SCRAM] SASL 
mechanism." This sentence seems out of place. What extension? Why SCRAM?

2.2.1:

- Item 1, first sentence: s/than/then

2.6:

- Clarify what is meant by syntax checking. In the strictest sense it 
could mean that any script that complies with the basic grammar of the 
Sieve language would pass. Command syntax, i.e. which arguments are 
required/allowed, would then be ignored. Also, wouldn't it be 
helpful/useful/desirable to include contextual checks here as well? E.g. 
unknown/invalid comparators etc. I first encountered this distinction 
when discussing the ihave extension to the Sieve language. I implicitly 
interpreted this requirement as a full script check (i.e. as would be 
done for full compilation), which seems overly restrictive when reading 
this standard more carefully.

2.11:

- Naming of CHECKSCRIPT extension is not consistent with RENAME 
extension. To be consistent CHECK would be a better choice. (Yes, I am 
nitpicking, sorry)

2.11.2:

- For clarity, mention that the CHECKSCRIPT command is in effect 
identical to the PUTSCRIPT command when in ANONYMOUS Sieve script 
verification mode.

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.

2.11.4:

- Explain the use and merit of the UNAUTHENTICATE command. The only 
merit I can think of is that reconnecting can cause some extra overhead 
for setting up the connection and re-negotiating security/TLS layers. 
But is this time optimization worth complicating the protocol? 
Discussion item: who would be willing to implement this? I personally 
have no real problems with the addition of this command, but I cannot 
imagine that I will ever want to implement it. Perhaps I am overlooking 
something?
	
General:
- The described protocol is both referred to as "ManageSieve" and 
"Manage Sieve" (e.g. IANA Considerations)

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.

Kind regards,

--
Stephan Bosch
[email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 06 Nov 2008 16:04:17 +0000

Hi Stephan,
Thank you for your review.

I am quickly answering easy comments/questions and will followup on the 
rest later on.

Stephan Bosch wrote:

> Hello,
>
> Alexey Melnikov wrote:
>
>> The Working Group Last Call for this document starts on November 3rd 
>> and will end on November 21st (so it is almost 3 weeks, so that the 
>> IETF meeting in Dublin is covered).
>>
>> Please send any comments to the Sieve mailing list or directly to me. 
>> If you chose to do the latter, please CC Cyrus Daboo <[email-masked]>.
> changes/additions to the document, so I may find other issues when I 
> do (hopefully before the 21st of November).
>
> My review is structured in a per-section manner. Comments include 
> typos, but also requests for clarification:
>
> 1.3:

 [...]

> - Typos in explanation of NONEXISTENT and ALREADYEXISTS : 

Fixed.

> authentication, which is strange considering that STARTTLS is only 
> valid in a non-authenticated state.

Right. I can add a text that listing STARTTLS capability after 
successful STARTTLS is a SHOULD NOT.
Unless people prefer MUST NOT?

> - Explain the purpose of the OWNER capability. Common question would 
> be: clients already know their identity, so why advertise it as a 
> capability?

I will reply to this in a separate message.

> Also, in my mind, listing status information in a capability response 
> seems hardly appropriate.

The list of currently available SASL mechanisms is also status 
information (it might depend on whether TLS is on or not), so I think 
your argument is not entirely valid.

> encoding, regardless of the order in which the layers were 
> negotiated." Isn't this order fixed correctly already by the fact that 
> the STARTTLS command is only valid before authentication (== SASL and 
> any security layer it may install). I mean that I do not see how the 
> layers can be negotiated in a different order.

Good point. This was cut&paste from another document.
I've deleted part of the sentence that starts with "regardless".

> mechanism." This sentence seems out of place. What extension?

This should have been "To ensure interoperability, client and server 
implementations of the ManageSieve protocol ..."

> Why SCRAM?

I will reply to this separately.

> - Item 1, first sentence: s/than/then

Fixed.

> helpful/useful/desirable to include contextual checks here as well? 
> E.g. unknown/invalid comparators etc.

IMHO, invalid/unknown comparator would be covered by syntactic checks.

> I first encountered this distinction when discussing the ihave 
> extension to the Sieve language. I implicitly interpreted this 
> requirement as a full script check (i.e. as would be done for full 
> compilation), which seems overly restrictive when reading this 
> standard more carefully.

You need to suggest specific text, especially if you want the document 
to describe interaction with ihave in more details.
 [...]

> identical to the PUTSCRIPT command when in ANONYMOUS Sieve script 

I am not sure that would add much clarity.
I am almost tempted to add a reference in the other direction. The only 
thing stopping me is the fact that CHECKSCRIPT is an extension.
 [...]

> merit I can think of is that reconnecting can cause some extra 
> overhead for setting up the connection and re-negotiating security/TLS 
> layers. 

Yes.

> But is this time optimization worth complicating the protocol? 

I think the answer is yes. For a management client that tries to update 
Sieve scripts for several users the speed of reestablishing a 
ManageSieve connection might be non trivial.

UNAUTHENTICATE command came out of discussion regarding SASL 
reauthentication in Dublin. Here is the message that motivated the whole 
discussion: <http://www.imc.org/ietf-mta-filters/mail-archive/msg04061.html>

> Discussion item: who would be willing to implement this?

I am willing to implement this in Isode's server.

> I personally have no real problems with the addition of this command, 
> but I cannot imagine that I will ever want to implement it. Perhaps I 
> am overlooking something?

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 08 Nov 2008 16:07:40 +0000

Hi Stephan,
Thanks again for your detailed review.
I think message I will reply to your question about the new OWNER 
capability:

Stephan Bosch wrote:

> capability? Also, in my mind, listing status information in a 
> capability response seems hardly appropriate.

I wanted to post a message on this change, but you were quicker than me.
Chris Newman suggested in his original ManageSieve review 3 changes 
related to Sieve URIs:

> * IMAP URLs made the mistake of confusing the identity used to 
> authenticate with the identity that owns the script.  This makes IMAP 
> URLs cumbersome. I would strongly encourage a naming model that 
> separates the two and keeps the script owner explicit.  For example:
>
>   sieveurl-script = "sieve://" [ authority ] "/" owner "/" scriptname 

As per mailing list discussions a modified version of this syntax was 
adopted by the draft, so I've decided to address one of the 2 remaining 
issues:

> Then two other changes would make this particularly useful:
> 1. Allow a script name (at least in putscript) to be either a Sieve URI
> or a local name.  This allows, for example, a secretary to set the
> script for her boss.
> 2. Add a capability that advertises the owner name that applies to a 
> given managesieve session (this would be derived from the 
> authentication id).

[I think Chris meant "authorization identity" above.]

So, OWNER corresponds to 2). When using SASL authentication a client can 
authenticate as one person ("authentication identity"), but be allowed 
to act as another ("authorization identity"). OWNER is returning the latter.

I have a weak preference for having the OWNER capability. So far I found 
a couple of reasons for it:

Imagine you have a ManageSieve client that need to process several Sieve 
URIs (e.g. to update several scripts).
The client would be able to compare the "owner" part of an URI against 
the value returned in the OWNER capability in order to decide if it 
needs to authenticate as another user before processing another script 
identified by a URI.

I also think that the OWNER capability can be useful for debugging (i.e. 
for analyzing protocol trace logs). Of course this only helps if the 
client requests capabilities after authentication.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 08 Nov 2008 16:05:19 +0000

So far I am aware of 2 open issues (not counting Stephan Bosch's 
comments) that need some discussion:

1). Should RENAME, NOOP and CHECKSCRIPT capabilities be merged into a 
single capability. (Personally I dislike capability proliferation).
2). Chris Newman has suggested to allow use of URIs in commands like 
PUTSCRIPT. Should this be done? If yes, should this be an extension?

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 08 Nov 2008 17:34:07 +0000

Hi Stephan,
I am responding to the rest of your comments:

 [...]

> 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.

 [...]

> "Manage Sieve" (e.g. IANA Considerations)

Ok, I've changed "Manage Sieve" to "ManageSieve" everywhere in the document.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 08 Nov 2008 18:25:28 +0000

Hi Stephan,

Stephan Bosch wrote:

> 1.3:
>
> - Use of example with 'the QUOTA/MAXSCRIPTS response' code is 
> confusing. MAXSCRIPTS is not part of the standard, but the example 
> does not mention that explicitly. Also, I can imagine that such 
> detailed response can have some merit. So, why is it not included in 
> the standard along with something like MAXSIZE? 

I've missed that comment somehow.

Yes, I agree that it would be worth adding QUOTA/MAXSCRIPTS (the maximum 
number of per-user scripts) and QUOTA/MAXSIZE (maximum script size), so 
I will add them to the document.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 09 Nov 2008 14:42:00 -0500

> short term and medium term (3 years).

I think perhaps the right answer, for ManageSieve and for many other 
protocols, is to require

- clients MUST implement both PLAIN and FOO
- servers MUST implement at least one of PLAIN or FOO

where FOO is some mechanism with the properties you describe.

The problem is that there are a wide variety of underlying authentication 
services that people might want to deploy which can work with PLAIN but not 
with any of the mechanisms that are candidates for FOO.  Examples include 
Kerberos password validation (used where the client has no Kerberos 
support), RSA SecurID, and OTP mechanisms such as that described in RFC2289.

-- Jeff

---

From: Stephan Bosch <[email-masked]>
Date: Tue, 18 Nov 2008 10:42:48 +0100

> to describe interaction with ihave in more details.
I was not saying that the interaction with ihave needs to be described 
better, I was merely saying that during the discussion of the ihave 
extension I noticed that the current formulation of the syntactic 
validation requirement is very much open for interpretation. IMHO, this 
is usually a bad thing in a document that is intended to establish a 
standard.

I am not very good at writing such texts myself, but I can provide a 
textual representation of how I interpret the sentence 'The server MUST 
check the submitted script for syntactic validity, which includes 
checking that all Sieve extensions mentioned in Sieve script "require" 
statement(s) are supported by the Sieve interpreter.' (somewhere on page 
20):

'The server MUST check the submitted script for validity, which includes 
checking that the script complies with the Sieve grammar [SIEVE], that 
all Sieve extensions mentioned in script's "require" statement(s) are 
supported by the Sieve interpreter, that all used commands are known 
(i.e. either part of the main Sieve language or an extension mentioned 
in the "require" lines), that commands are used in the correct context 
and that the supplied command arguments are valid for each command. 
Essentially, the performed validation should be equal to what is 
performed when compiling the script for execution. Implementations that 
use a binary representation to store compiled scripts can extend the 
validation to a full compile, in order to avoid validating uploaded 
scripts multiple times.'

Does this interpretation match your intention of that sentence? I am 
also wondering what others think of this. I can imagine that the ihave 
authors have some amendments, but I think the text that follows the 
aforementioned sentence in the draft should cover most potential issues.

Regards,

--
Stephan Bosch
[email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 25 Nov 2008 20:54:17 +0000

Alexey Melnikov wrote:

 [...]

>> or a local name.  This allows, for example, a secretary to set the
We've discussed this in more details in Minneapolis and the room 
agreement was that ManageSieve commands should accept URIs in addition 
to script names.
However, I am having second thoughts on this.

1). It looks like at least the following commands would need to be updated:
 HAVESPACE, PUTSCRIPT, GETSCRIPT, DELETESCRIPT

But LISTSCRIPTS returns script names. Should it be changed to return 
URIs? I think this would break all existing clients, so I don't think 
that an unextended version of LISTSCRIPTS should do that.

Also, should it list *all* scripts accessible by the current user, or 
just personal scripts? The former seems like an extension that Dilian 
was talking about.

2). Considering that Sieve script names are in Unicode it would also 
make sense to specify IRI version of Sieve URIs. I frankly don't have 
experience specifying IRIs.

So my current thinking is that these changes might have undesired 
effects on existing clients and they also seem to require quite a bit of 
work.
But I really want to get this document done (for Lemonade/OMA MEM among 
other things). So can we postpone this change till an extension?

> So, OWNER corresponds to 2). When using SASL authentication a client 
> can authenticate as one person ("authentication identity"), but be 
> allowed to act as another ("authorization identity"). OWNER is 
> returning the latter.
>
> I have a weak preference for having the OWNER capability. So far I 
> found a couple of reasons for it:
>
> Imagine you have a ManageSieve client that need to process several 
> Sieve URIs (e.g. to update several scripts).
> I also think that the OWNER capability can be useful for debugging 
> (i.e. for analyzing protocol trace logs). Of course this only helps if 
> the client requests capabilities after authentication.

I've missed another obvious use case: constructing URIs to give them to 
third parties.

---

From: Aaron Stone <[email-masked]>
Date: Tue, 25 Nov 2008 13:28:24 -0800

> other things). So can we postpone this change till an extension?

+51% wait to work on an extension. Now that we've enumerated some more
of the issues URI's raise, I think it's likely we'll get really stuck on
working out the details.

Is there another way that we can achieve the goal of one user modifying
another user's Sieve scripts that's not too ugly and can easily become
URI in a future revision?

Is there a path we might agree on for merging Sieve management into IMAP
protocol, and cease work on ManageSieve at some reasonable level of
functionality?

> I've missed another obvious use case: constructing URIs to give them to 

It would be a shame if the Sieve URI's ended up being like email message
ID's -- they look like something that you could use to uniquely identify
and retrieve a message from somewhere in the universe, but not really.

Aaron

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 26 Nov 2008 04:40:52 +0000

>of the issues URI's raise, I think it's likely we'll get really stuck on
Agreed.

>URI in a future revision?
We already have UNAUTHENTICATE.
But using URIs would be quite elegant.

>protocol, and cease work on ManageSieve at some reasonable level of
You already know my personal answer to this question ;-).

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 30 Nov 2008 15:17:58 +0000

Hi Stephan,

Stephan Bosch wrote:

>> I am quickly answering easy comments/questions and will followup on 
>> the rest later on.
>
>>> 2.6:
>>>
>>> - Clarify what is meant by syntax checking. In the strictest sense 
>>> it could mean that any script that complies with the basic grammar 
>>> of the Sieve language would pass. Command syntax, i.e. which 
>>> arguments are required/allowed, would then be ignored. Also, 
>>> wouldn't it be helpful/useful/desirable to include contextual checks 
>>> here as well? E.g. unknown/invalid comparators etc.
>>
>> You need to suggest specific text, especially if you want the 
>> document to describe interaction with ihave in more details.
>
> validation requirement is very much open for interpretation. IMHO, 
> this is usually a bad thing in a document that is intended to 
> establish a standard.
>
> textual representation of how I interpret the sentence 'The server 
> MUST check the submitted script for syntactic validity, which includes 
> statement(s) are supported by the Sieve interpreter.' (somewhere on 
> page 20):
>
> 'The server MUST check the submitted script for validity, which 
> includes checking that the script complies with the Sieve grammar 
> [SIEVE], that all Sieve extensions mentioned in script's "require" 
> statement(s) are supported by the Sieve interpreter,

Good so far.

> that all used commands are known (i.e. either part of the main Sieve 
> language or an extension mentioned in the "require" lines),

I think this text is not going to be good in presence of ihave 
extension. So I would rather omit or reword this part.

> that commands are used in the correct context

I am not sure what you mean here.

> and that the supplied command arguments are valid for each command.

IMHO, this part is good.

> performed when compiling the script for execution. Implementations 
> that use a binary representation to store compiled scripts can extend 
> the validation to a full compile, in order to avoid validating 
> uploaded scripts multiple times.'

This text is good and might be helpful.

> aforementioned sentence in the draft should cover most potential issues.

While I generally agree with the intent of your new text, I think it 
demonstrates cases when saying less is actually better than saying more: 
a very specific text might unintentionally exclude some valid checks.