headers
Stephan Bosch | 3 Aug 2010 10:34
Picon

Re: Question about draft-ietf-sieve-external-lists-02

  Op 31-7-2010 19:09, Ned Freed schreef:
>> However, the
>> document does not describe how this new match type interacts with a
>> specified comparator.
>
> Yes, and I'm of two minds as to how to fix it. The simplest thing to 
> do is to
> simply declare that comparators have no effect on :list. (We can make 
> them a
> no-op or an error to even specify.) The alternative is to allow 
> comparators to
> be an input, but for the use of that input to be implementation and
> list-specific. (Again, whether or not it would be an error to specify a
> comparator on a :list that doesn't consume it would need to be 
> determined.)

I think it is always a good idea to make sure the user gets to know that 
the combination of match-type and comparator isn't valid. If it is 
obvious at compile time, a compile error would be appropriate. At 
runtime I am not sure. A fatal error seems harsh. But, simply ignoring a 
specified comparator is in my opinion not a good idea either.

The base spec already specifies something that is somewhat analogous to 
the :list situation:

Section 2.7.3 Comparators:

Some comparators may not be usable with substring matches; that is,
they may only work with ":is".  It is an error to try to use a
comparator with ":matches" or ":contains" that is not compatible with
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeffrey Hutzelman | 3 Aug 2010 18:56
Picon
Favicon

Re: Question about draft-ietf-sieve-external-lists-02

--On Tuesday, August 03, 2010 10:34:46 AM +0200 Stephan Bosch 
<stephan <at> rename-it.nl> wrote:

>> There's also the possibility of doing something akin to how the
>> current regex
>> draft uses comparators - as a means of identifying a canonicalization
>> and what
>> constitutes a unit of comparison. Do we want to allow that sort of use
>> with
>> :list?
>
> Hmm, well.... why not? I suggest we make it an error only when the list
> has no explicit use for it, meaning that implementors MAY accept
> comparators for an external list, but MUST trigger an error when the list
> does not use the specified comparator or the comparator is incompatible
> somehow.
>
> I guess the main question is: what would be the disadvantage of providing
> more flexibility to the implementor for the interaction of :list with
> comparators?

This sounds like an interoperability nightmare.  You describe a situation 
where a SIEVE implementation has the option to accept comparators or not, 
but if not, then providing them is an error, and there is no way for the 
producer of the sieve script to know in advance what will happen.

This is _not_ analogous to comparators that work with :is but not with 
:matches or :contains, because you can know from the specifications which 
combinations are acceptable and which will produce errors.
(Continue reading)

Permalink | Reply | 14 comments |
headers
Stephan Bosch | 3 Aug 2010 19:11
Picon

Re: Question about draft-ietf-sieve-external-lists-02

  Op 3-8-2010 18:56, Jeffrey Hutzelman schreef:
> --On Tuesday, August 03, 2010 10:34:46 AM +0200 Stephan Bosch 
> <stephan <at> rename-it.nl> wrote:
>> Hmm, well.... why not? I suggest we make it an error only when the list
>> has no explicit use for it, meaning that implementors MAY accept
>> comparators for an external list, but MUST trigger an error when the 
>> list
>> does not use the specified comparator or the comparator is incompatible
>> somehow.
>>
>> I guess the main question is: what would be the disadvantage of 
>> providing
>> more flexibility to the implementor for the interaction of :list with
>> comparators?
>
> This sounds like an interoperability nightmare.  You describe a 
> situation where a SIEVE implementation has the option to accept 
> comparators or not, but if not, then providing them is an error, and 
> there is no way for the producer of the sieve script to know in 
> advance what will happen.

Hmm. Good point. My version would require each and every list type to be 
specified, at least in terms of their comparator behavior... 
undesirable. Well, with that in mind, providing a warning is the best an 
implementation can do I guess.

> This is _not_ analogous to comparators that work with :is but not with 
> :matches or :contains, because you can know from the specifications 
> which combinations are acceptable and which will produce errors.
(Continue reading)

Permalink | Reply | 12 comments |
headers
Alexey Melnikov | 4 Aug 2010 11:34
Favicon

Comments on Sieve include (draft-ietf-sieve-include-04.txt)

As discussed in Maastricht, the document should contain some text about 
use of include with ManageSieve.

3.1.  General Considerations

   Sieve implementations must track the use of actions in included

s/must/MUST ?

   scripts so that implicit "keep" behavior can be properly determined
   based on whether any actions have executed in any script.

   Sieve implementations MUST ensure that recursive includes are not
   possible.  For example, if script "A" includes script "B", and script
   "B" includes script "A" an error MUST be generated either when the
   script is uploaded to the Sieve repository,

I wonder if this is too strong and if this should be replaced with
"activated". I am thinking about a script A that includes B is being
uploaded, while the older version of B already includes A.

   or when the script is
   executed.  If such an error is detected whilst processing a Sieve
   script, an implicit "keep" action MUST be executed to prevent loss of
   any messages.

3.2.  Control Structure include

   Personal script "spam_tests"
(Continue reading)

Permalink | Reply | 2 comments |
headers
Alexey Melnikov | 4 Aug 2010 11:42
Favicon

Sieve reject and Disposition-Notification-To header field

I got a private question about whether Disposition-Notification-To 
header field should be honoured when generating MDNs with "reject". 
Should it be ignored?

_______________________________________________
sieve mailing list
sieve <at> ietf.org
https://www.ietf.org/mailman/listinfo/sieve
Permalink | Reply | 5 comments |
headers
Alexey Melnikov | 4 Aug 2010 11:45
Favicon

Re: Question about draft-ietf-sieve-external-lists-02

Jeffrey Hutzelman wrote:
> --On Tuesday, August 03, 2010 10:34:46 AM +0200 Stephan Bosch 
> <stephan <at> rename-it.nl> wrote:
>>> There's also the possibility of doing something akin to how the
>>> current regex
>>> draft uses comparators - as a means of identifying a canonicalization
>>> and what
>>> constitutes a unit of comparison. Do we want to allow that sort of use
>>> with
>>> :list?
>> Hmm, well.... why not? I suggest we make it an error only when the list
>> has no explicit use for it, meaning that implementors MAY accept
>> comparators for an external list, but MUST trigger an error when the 
>> list
>> does not use the specified comparator or the comparator is incompatible
>> somehow.
>>
>> I guess the main question is: what would be the disadvantage of 
>> providing
>> more flexibility to the implementor for the interaction of :list with
>> comparators?
> This sounds like an interoperability nightmare.  You describe a 
> situation where a SIEVE implementation has the option to accept 
> comparators or not, but if not, then providing them is an error, and 
> there is no way for the producer of the sieve script to know in 
> advance what will happen.
>
> This is _not_ analogous to comparators that work with :is but not with 
> :matches or :contains, because you can know from the specifications 
> which combinations are acceptable and which will produce errors.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 4 Aug 2010 11:53
Favicon

Re: Question about draft-ietf-sieve-external-lists-02

Stephan Bosch wrote:
>  Op 3-8-2010 18:56, Jeffrey Hutzelman schreef:
>> --On Tuesday, August 03, 2010 10:34:46 AM +0200 Stephan Bosch 
>> <stephan <at> rename-it.nl> wrote:
>>> Hmm, well.... why not? I suggest we make it an error only when the list
>>> has no explicit use for it, meaning that implementors MAY accept
>>> comparators for an external list, but MUST trigger an error when the 
>>> list
>>> does not use the specified comparator or the comparator is incompatible
>>> somehow.
>>>
>>> I guess the main question is: what would be the disadvantage of 
>>> providing
>>> more flexibility to the implementor for the interaction of :list with
>>> comparators?
>> This sounds like an interoperability nightmare.  You describe a 
>> situation where a SIEVE implementation has the option to accept 
>> comparators or not, but if not, then providing them is an error, and 
>> there is no way for the producer of the sieve script to know in 
>> advance what will happen.
> Hmm. Good point. My version would require each and every list type to 
> be specified, at least in terms of their comparator behavior... 
> undesirable. Well, with that in mind, providing a warning is the best 
> an implementation can do I guess.
>> This is _not_ analogous to comparators that work with :is but not 
>> with :matches or :contains, because you can know from the 
>> specifications which combinations are acceptable and which will 
>> produce errors.
> Agreed.
>
(Continue reading)

Permalink | Reply | 11 comments |
headers
Stephan Bosch | 4 Aug 2010 15:09
Picon

Re: Comments on Sieve include (draft-ietf-sieve-include-04.txt)

On 08/04/2010 11:34 AM, Alexey Melnikov wrote:
> As discussed in Maastricht, the document should contain some text 
> about use of include with ManageSieve.

It does describe some parts of the interaction with ManageSieve already 
actually, but I see what you mean.

>   Sieve implementations MUST ensure that recursive includes are not
>   possible.  For example, if script "A" includes script "B", and script
>   "B" includes script "A" an error MUST be generated either when the
>   script is uploaded to the Sieve repository,
>
> I wonder if this is too strong and if this should be replaced with
> "activated". I am thinking about a script A that includes B is being
> uploaded, while the older version of B already includes A.
>

I guess this is related to the ManageSieve upload problem discussed at 
the meeting. A quick recap:

In the current ManageSieve specification the script is verified 
(compiled) upon upload. When include is involved, verification of each 
individual script after it is uploaded can cause trouble in multiple 
ways. Including the above, the examples we've thought of thus far are:

- Race condition of the script interpreter using a mix of new and 
outdated scripts while ManageSieve is in the process of uploading. Older 
versions of not-yet-uploaded scripts can malfunction with 
included/including scripts that are already uploaded.
(Continue reading)

Permalink | Reply | 0 comments |
headers
NED+mta-filters | 4 Aug 2010 17:05

Re: Sieve reject and Disposition-Notification-To header field

> I got a private question about whether Disposition-Notification-To
> header field should be honoured when generating MDNs with "reject".
> Should it be ignored?

We honor it in this case. It would be trivial to switch it off, but is there a
resson why we shouldn't be honoring it for these MDNs?

				Ned
_______________________________________________
sieve mailing list
sieve <at> ietf.org
https://www.ietf.org/mailman/listinfo/sieve
Permalink | Reply | 4 comments |
headers
NED+mta-filters | 5 Aug 2010 01:00

Re: Question about draft-ietf-sieve-external-lists-02

> I personally think that comparators should be allowed with :list, but I
> don't have a strong opinion.

Given the points that have been raised, I'm starting to think this is the right
answer. In the rare cases where a compprator does make sense to use with an
external list, it can be encoded into the list name.

> I also think that making Sieve scripts fail because an implementation
> decides that a particular comparator can't be used with :list would be a
> bad idea. If we want to go this route, then we need to define how a
> particular comparator works for a particular external list URI type.

Yeah, but the problem there is what to do about tag: URLs. I don't know what
other implementations have planned, but we're not exactly keen on letting users
specify arbitrary LDAP URLs or anything similar. Instead, the mail admin sets
up whatever tag: URLs (incuding families of them) they want, and these are then
mapped to LDAP, database queries, code callouts, whatever.

As it happens we have no exiting or planned external list mechanisms where a
comparator makes sense, so right now we can simply reject the combination
outright. But suppose this were to change. Given the mapping involved we'd
basically be counting on the admin to specify the handling of comparators, and
this means the admin is going to be responsible for setting it up so an unused
comparator results in an error. Of course we can arrange the defaults so that
the "right" think happens most of the time, but even so this doesn't sound
like all that great of an idea...

				Ned
_______________________________________________
sieve mailing list
(Continue reading)

Permalink | Reply | 10 comments |

Gmane