Subject: AD review of draft-ietf-sieve-3028bis-12

From: Chris Newman <[email-masked]>
Date: Thu, 29 Mar 2007 18:34:03 +0530

I have reviewed draft-ietf-sieve-3028bis-12.txt and that draft has sufficient 
quality that I will vote "yes" for it to become proposed standard.

However, I have found enough issues during review that the improvement in a 
draft 13 based on the non-controversial comments I've made would be worth the 
delay, IMHO.

One particular issue, marked with "***" below is a cross-WG compatibility issue 
-- the sort of issue it is my job as area director to catch.

As AD I do not wish to impose engineering decisions on WGs except in egregious 
cases, so I do not require the WG to fix any of the issues listed below.  The 
WG is free to say "-12" is good enough.  In that case consider these comments 
fodder for 3028ter.

                - Chris Newman
                Applications Co-Area Director

-----
Section 1, 4th paragraph

   the Mail Transfer Agent (MTA) does final delivery, such as
   traditional Unix mail, it is reasonable to sort when the MTA deposits
   mail into the user's mailbox.              ^^^^

Q: Should that be "filter"?

>    Implementations MUST support integer values in the inclusive range
>    zero to 2,147,483,647 (2^31 - 1), but MAY support larger values.

Q: Is there a Sieve capability to indicate support for larger numbers?

section 2.4.2.1. String Lists

>  Conversely, in any case where a list of strings is appropriate, a

Awkward wording.

Q: Perhaps this text should mention empty lists are forbidden to align with the
   ABNF?

Section 2.5

>   actions.  In this document, tests are given to if/elsif/else to

Q: Are tests "given" to else?

Section 2.6.2

>   To simplify this specification, tagged arguments SHOULD NOT take
>   tagged arguments as arguments.

Q: How does what future standards choose to do with tagged arguments make this 
specification simpler?  Perhaps just remove "To simplify this specification, "?

Section 2.6.3

>   different orderings on UTF-8 [UTF-8] characters.

The ordering and equality rules of a comparator apply to strings, not 
characters.  So this could be made more precise.

>   There are three match types describing the matching used in this
>   specification: ":is", ":contains", and ":matches".  Match type
>   arguments are supplied to those commands which allow them to specify
>   what kind of match is to be performed.

Awkward wording.

Section 2.7.1

>   in use.  In contrast, the comparator "i;basic;uca=3.1.1;uv=3.2"
>   defines a character to be any UTF-8 octet sequence encoding one

Perhaps just say "a Unicode-based comparator would define ..." since the basic 
comparator got split out of the base spec and could change dramatically.

Section 2.10.4

>   Site policy MAY limit numbers of actions taken and MAY impose
 numbers -> the number

Section 2.10.5

>   Implementations MUST NOT execute at all any script which requires an

Perhaps drop the "at all"

>         Experience with PostScript suggests that mechanisms that allow
>         a script to work around missing extensions are not used in
>         practice.

This statement would argue that the proposed "ihave" action needs to go 
experimental until utility is demonstrated at which point this text would be 
misleading.

>   Extensions which define actions MUST state how they interact with
>   actions discussed in the base specification.

Q: Isn't this redundant with the last paragraph of section 2.10.1?

> 2.10.7. Limits on Execution

Q: There is no mention of limits on script size, string size, or list size. 
Should there be?

Section 4.2

>   The message is send back out with the address from the redirect
  send->sent

Section 5.1 ***

There's some tricky interaction with IDN and EAI here.  It could be clarified 
with text like: A Sieve implementation for use with Internet email MUST support 
the use of IDN-encoded domain names [IDN] in the key-list.  A Sieve 
implementation MAY support use of UTF-8 for domain names in the key-list (a 
subsequent Sieve extension could add a capability name to require that 
behavior).

Section 5.4

>   command.  The null reverse-path is matched against as the empty
>   string, regardless of the ADDRESS-PART argument specified.

Awkward wording.

Personally, I would have preferred unknown envelope parts were ignored.  In the 
case of EAI, I'd include "alt-address" in most tests but wouldn't care if the 
implementation supports it.  I could always add a require "alt-address" to the 
script if I really needed it to work.  With the "unknown envelope parse SHOULD 
result in an error", one has to use the ihave extension to support the "don't 
care if it works" case.

Section 5.9

>   Note that for a message that is exactly 4,000 octets, the message is
>   neither ":over" 4000 octets or ":under" 4000 octets.
                                ^^
                                nor

>   As the range of mail systems that this document is intended to apply
>   to is quite varied, a method of advertising which capabilities an
>   implementation supports is difficult due to the wide range of
>   possible implementations.

I suggest removing all text up to and including the "," to simplify this 
sentence.

Section 8.1

>   multiline-dotstuff = "." 1*octet-not-crlf CRLF

This name is misleading because it covers all lines starting with a dot, 
whether or not they are dot-stuffed.  Perhaps it should be "multiline-dotstart".

Section 10

>   Implementations SHOULD take measures to prevent scripts from looping.

Q: Isn't this trivially true because Sieve scripts have no loop command? 
Perhaps you meant to say "creating mail loops" instead of "looping".

Section 13

>   [COLLATION] Newman, C., Duerst, M., and A. Gulbrandsen "Internet
>                    Application Protocol Collation Registry" draft-
>                    newman-i18n-comparator-07.txt (work in progress),
>                    March 2006.

Now RFC 4790...Thanks Arnt!

Section 15

This is missing some important changes.

10. Added encoded-character capability and deprecated (but did not remove)
    use of arbitrary binary in Sieve scripts.
11. Updated IANA registration template, and permit capability prefix
    registrations.  Prefix registrations outside "vnd." require IESG approval.
12. Added .sieve as a valid extension for sieve scripts.

                - Chris

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 29 Mar 2007 18:15:07 +0100

Chris Newman wrote:

> I have reviewed draft-ietf-sieve-3028bis-12.txt and that draft has 
> sufficient quality that I will vote "yes" for it to become proposed 
> standard.

Thanks :-)

> However, I have found enough issues during review that the improvement 
> in a draft 13 based on the non-controversial comments I've made would 
> be worth the delay, IMHO.
>
> One particular issue, marked with "***" below is a cross-WG 
> compatibility issue -- the sort of issue it is my job as area director 
> to catch.
>
> As AD I do not wish to impose engineering decisions on WGs except in 
> egregious cases, so I do not require the WG to fix any of the issues 
> listed below.  The WG is free to say "-12" is good enough.  In that 
> case consider these comments fodder for 3028ter.

After discussing this with Cyrus: chairs would like to publish -12 + 
RFC-editor's notes.

Below I am replying to your comments. I've split them into 2 categories: 
the ones that should be just applied and the ones that should be either 
deferred till 3028ter or at least discussed.

With my contributor's hat on, I think the following changes should be 

> Q: Should that be "filter"?

(I don't care either way, but I think filter is probably better)
 [...]

> Q: Are tests "given" to else?

Your are right. Remove "else" here.

> Q: How does what future standards choose to do with tagged arguments 
> make this specification simpler?  Perhaps just remove "To simplify 
> this specification, "?

Agreed.
 [...]

> Perhaps just say "a Unicode-based comparator would define ..." since 
> the basic comparator got split out of the base spec and could change 
> dramatically.

Agreed.

>>   Site policy MAY limit numbers of actions taken and MAY impose

Ok.
 [...]

>>   The message is send back out with the address from the redirect

Yes.
 [...]

>>   neither ":over" 4000 octets or ":under" 4000 octets.

Yes.

> I suggest removing all text up to and including the "," to simplify 
> this sentence.

That would be fine with me.

> This name is misleading because it covers all lines starting with a 
> dot, whether or not they are dot-stuffed.  Perhaps it should be 
> "multiline-dotstart".

Sure.
 [...]

> Now RFC 4790...Thanks Arnt!

Yes. But note that RFC editor will fix this automatically.

> 12. Added .sieve as a valid extension for sieve scripts.

Yes!

*======================
*Below are the changes that needs to be discussed/deferred till 3028ter 

> Q: Is there a Sieve capability to indicate support for larger numbers?

No, there isn't any.
 [...]

> Q: Perhaps this text should mention empty lists are forbidden to align 

That would be fine with me, even though I don't think this is necessary.
 [...]

> characters.  So this could be made more precise.

The change seems fine to me.

>>   what kind of match is to be performed.

How about the following:

  Match type arguments control what kind of match is to be performed by 
commands.

(The "which allow the to specify" is not important, as commands that 
don't allow for match types obviously don't care about them.)
However, is the updated sentence adds any value to the spec?

 [...]

> Perhaps drop the "at all"

The text is trying to prevent people to do partial script execution. Any 
suggestions how to improve the text?

> This statement would argue that the proposed "ihave" action needs to 
> go experimental

I think this is what Ned was planning to do anyway.

> until utility is demonstrated at which point this text would be 
> misleading.

Should this sentence just be dropped?

> * *

It is, but I don't think it hurts to repeat this.

> Q: There is no mention of limits on script size, string size, or list 
> size. Should there be?

Hmm. We do have limits on size of variables. Opinions?

> Section 5.1 ***
>
> There's some tricky interaction with IDN and EAI here.  It could be 
> clarified with text like: A Sieve implementation for use with Internet 
> email MUST support the use of IDN-encoded domain names [IDN] in the 
> key-list.

Isn't this implied? I mean any ACE-encoded IDN domain name is a valid 
ASCII domain name.

>   A Sieve implementation MAY support use of UTF-8 for domain names in 
> the key-list (a subsequent Sieve extension could add a capability name 
> to require that behavior).

Addition of this text is fine with me.

> Personally, I would have preferred unknown envelope parts were ignored.

If I remember correctly, the WG discussed this and the existing text is 
based on WG consensus.

> In the case of EAI, I'd include "alt-address" in most tests but 
> wouldn't care if the implementation supports it.  I could always add a 
> require "alt-address" to the script if I really needed it to work.  
> With the "unknown envelope parse

-12 says "parts", not "parse".
(So I don't know if the rest of your argument is valid)

> SHOULD result in an error", one has to use the ihave extension to 
> support the "don't care if it works" case.

 [...]

> Q: Isn't this trivially true because Sieve scripts have no loop 
> command? Perhaps you meant to say "creating mail loops" instead of 
> "looping".

I think you are right.

---

From: Chris Newman <[email-masked]>
Date: Fri, 30 Mar 2007 10:00:52 +0530

> After discussing this with Cyrus: chairs would like to publish -12 +

That's fine.  Send me RFC-editor notes I can paste into the ballot and I'll 
push the draft forward.

> suggestions how to improve the text?

Perhaps:
 Implementations MUST NOT execute any Sieve script test or command
 subsequent to "require" if one of the required extensions is unavailable.

> Isn't this implied? I mean any ACE-encoded IDN domain name is a valid ASCII
> domain name.

This is implied only as long as the SMTP infrastructure is 7-bit.  But the 
present Sieve spec is written in such a way that it could be applied to an 
8-bit infrastructure (such as XMPP or future UTF8SMTP which EAI will produce). 
So the question is do we want the ability to move a Sieve script from a 7-bit 
infrastructure to a UTF-8 infrastructure and have it continue to function in 
the same way?

My technical preference is that user Sieve scripts should keep working when the 
infrastructure is upgraded as I don't like disrupting users.

                - Chris

---

From: Philip Guenther <[email-masked]>
Date: Thu, 29 Mar 2007 23:19:34 -0700

> Alexey Melnikov wrote on 3/29/07 18:15 +0100:
...
> subsequent to "require" if one of the required extensions is unavailable.

I like that.

> 8-bit infrastructure (such as XMPP or future UTF8SMTP which EAI will 
> produce). So the question is do we want the ability to move a Sieve script 
> from a 7-bit infrastructure to a UTF-8 infrastructure and have it continue to 
> function in the same way?

Ah, I had read your original message as implying the opposite direction 
(UTF-8 domain arguments as matching IDN-encoded header/envelope), which 
would be a new requirement.  Simply saying "MUST support use of 
IDN-encoded..." is insufficient, IMHO, as "use" does not clearly imply 
matching between encodings.

The direction you're suggesting makes sense to me...but I suspect we're 
going to need a "sieve in an EAI world" RFC anyway to cover everything 
that comes up from the EAI work.  E.g., should 'envelope "from"' match 
against both the UTF8SMTP address and an ALTADDRESS, if any?  How do you 
'redirect' to an address w/ALTADDRESS (just loosen the syntax in 
2.4.2.3?)?

Note that some of those may be in new extensions, but some may simply be 
new requirements on implementations.  3028/3028bis describe the 
requirements on sieve implementations that operate on top of 2821/2822. 
Implementations that operate in other environments have other 
requirements, described in other docs, such as already seen in 
draft-ietf-lemonade-imap-sieve.  An implementation in a UTF8SMTP/EAI 
environment can have additional requirements placed on it by a separate 
RFC.  Of course, those requirements should be designed to ease script 
portability, as your suggestion does.

> My technical preference is that user Sieve scripts should keep working when 
> the infrastructure is upgraded as I don't like disrupting users.

Agreed, I'm just not sure we have enough knowledge right now to guarantee 
that.

Philip Guenther

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 30 Mar 2007 10:56:25 -0400

Hi Philip,

--On March 29, 2007 11:19:34 PM -0700 Philip Guenther 
<[email-masked]> wrote:

>> This is implied only as long as the SMTP infrastructure is 7-bit.  But
>> the  present Sieve spec is written in such a way that it could be
>> applied to an  8-bit infrastructure (such as XMPP or future UTF8SMTP
>> which EAI will  produce). So the question is do we want the ability to
>> move a Sieve script  from a 7-bit infrastructure to a UTF-8
>> infrastructure and have it continue to  function in the same way?
>
>> My technical preference is that user Sieve scripts should keep working
>> when  the infrastructure is upgraded as I don't like disrupting users.
>

Yes - I always assumed that there would be a SIEVE for EAI extension to 
allow SIEVE to work in an EAI environment. Shouldn't that be part of the 
EAI WG since it is looking at SMTP/IMAP/POP etc in an EAI environment? I 
would be somewhat reluctant to undertake that work here, but it seems to me 
it should be done in parallel with the SMTP/IMAP/POP work so it can be 
deployed and used alongside those when they get upgraded.

-- 
Cyrus Daboo

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 30 Mar 2007 16:42:45 +0100

> Hi Philip,

Hi Cyrus,

> Yes - I always assumed that there would be a SIEVE for EAI extension 
> to allow SIEVE to work in an EAI environment. Shouldn't that be part 
> of the EAI WG since it is looking at SMTP/IMAP/POP etc in an EAI 
> environment? I would be somewhat reluctant to undertake that work 
> here, but it seems to me it should be done in parallel with the 
> SMTP/IMAP/POP work so it can be deployed and used alongside those when 
> they get upgraded.

Chris has the final say on this, but here is my personal opinion:
I got impression from Harald that EAI WG is not going to take on any 
extra work until its current milestones are done. EAI might recharter to 
take on more work.
I think whichever WG can finish its milestones first can recharter to do 
this work.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 30 Mar 2007 22:10:56 +0100

Chris Newman wrote:

> That's fine.  Send me RFC-editor notes I can paste into the ballot and 
> I'll push the draft forward.

Ok, here is the list of changes I would like to propose (Can please 
someone else sanity check this!).
I will keep the rest of your comments till 3028ter.
========================
Section 1, 3rd paragraph:

OLD:
   Scripts written in Sieve are executed during final delivery, when the
   message is moved to the user-accessible mailbox.  In systems where
   the Mail Transfer Agent (MTA) does final delivery, such as
   traditional Unix mail, it is reasonable to sort when the MTA deposits
                                              ^^^^
   mail into the user's mailbox.
NEW:
   Scripts written in Sieve are executed during final delivery, when the
   message is moved to the user-accessible mailbox.  In systems where
   the Mail Transfer Agent (MTA) does final delivery, such as
   traditional Unix mail, it is reasonable to filter when the MTA deposits
                                               ^^^
   mail into the user's mailbox.

In section 2.5:

OLD:
   Tests are given as arguments to commands in order to control their
   actions.  In this document, tests are given to if/elsif/else to
                                                          ^^^^^
   decide which block of code is run.

NEW:
   Tests are given as arguments to commands in order to control their
   actions.  In this document, tests are given to if/elsif to
                                                          ^
   decide which block of code is run.

(i.e. delete "/else")

In section 2.6.2, last paragraph:

OLD:
   To simplify this specification, tagged arguments SHOULD NOT take
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   tagged arguments as arguments.

NEW:
   Tagged arguments SHOULD NOT take tagged arguments as arguments.

(i.e. delete the beginning of the sentence till the comma).

In section 2.6.3, last paragraph:

OLD:
   One particularly noteworthy case is the ":comparator" argument, which
   allows the user to specify which comparator [COLLATION] will be used
   to compare two strings, since different languages may impose
   different orderings on UTF-8 [UTF-8] characters.
                                        ^^^^^^^^^^
NEW:
   One particularly noteworthy case is the ":comparator" argument, which
   allows the user to specify which comparator [COLLATION] will be used
   to compare two strings, since different languages may impose
   different orderings on UTF-8 [UTF-8] strings.
                                        ^^^^^^^

In section 2.7.1, 1st paragraph, replace the 2nd sentence:

OLD:
   Match type arguments are supplied to those commands which allow them 
to specify
   what kind of match is to be performed.
NEW:
  Match type arguments control what kind of match is to be performed by 
commands.

In section 2.7.1, 5th paragraph:

OLD:
   In contrast, the comparator "i;basic;uca=3.1.1;uv=3.2"
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   defines a character to be any UTF-8 octet sequence encoding one
   ^^^^^^^
   Unicode character and thus "?" may match more than one octet.

NEW:
   In contrast, a Unicode-based comparator would define
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   a character to be any UTF-8 octet sequence encoding one
   Unicode character and thus "?" may match more than one octet.

In section 2.10.4, 1st paragraph:

OLD:
   Site policy MAY limit numbers of actions taken and MAY impose
                         ^^^^^^^
NEW:
   Site policy MAY limit the number of actions taken and MAY impose
                          ^^^^^^^^

In section 2.10.5, replace the 3rd paragraph:

OLD:
   unknown capability name.

NEW:

In section 2.10.5, remove the 5th paragraph (part of the Note):
REMOVE:
         Experience with PostScript suggests that mechanisms that allow
         a script to work around missing extensions are not used in
         practice.

In section 4.2, 3rd paragraph:

OLD:
   The message is send back out with the address from the redirect
                  ^^^^
NEW:
   The message is sent back out with the address from the redirect
                  ^^^^

Section 5.9, last paragraph:

OLD:

NEW:
   Note that for a message that is exactly 4,000 octets, the message is
   neither ":over" 4000 octets nor ":under" 4000 octets.
                               ^^^

In section 6.3:

OLD:
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   ^^^^^^^^^^^^^^^^^^

NEW:
   A method of advertising which capabilities an
   implementation supports is difficult due to the wide range of
   possible implementations.

(i.e. delete everything before the comma).

In section 8.1:

OLD:
   multi-line         = "text:" *(SP / HTAB) (hash-comment / CRLF)
                        *(multiline-literal / multiline-dotstuff)
                                              ^^^^^^^^^^^^^^^^^^
                        "." CRLF
NEW:
   multi-line         = "text:" *(SP / HTAB) (hash-comment / CRLF)
                        *(multiline-literal / multiline-dotstart)
                                              ^^^^^^^^^^^^^^^^^^
                        "." CRLF

And also:

OLD:
   multiline-dotstuff = "." 1*octet-not-crlf CRLF
   ^^^^^^^^^^^^^^^^^^
                          ; A line containing only "." ends the
                          ; multi-line.  Remove a leading '.' if
                          ; followed by another '.'.
NEW:
   multiline-dotstart = "." 1*octet-not-crlf CRLF
   ^^^^^^^^^^^^^^^^^^
                          ; A line containing only "." ends the
                          ; multi-line.  Remove a leading '.' if
                          ; followed by another '.'.

In section 13:

Please update the [COLLATION] reference to point to RFC 4790.

In section 15:

Add to the end:

10. Added encoded-character capability and deprecated (but did not remove)
   use of arbitrary binary octets in Sieve scripts.
11. Updated IANA registration template, and permit capability prefix
   registrations.  Prefix registrations outside "vnd." require IESG 
approval.
12. Added .sieve as a valid extension for sieve scripts.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 30 Mar 2007 22:15:39 +0100

> command? Perhaps you meant to say "creating mail loops" instead of 

Actually, there is separate text about mail loops:

   The "redirect" command has considerations regarding loop prevention;
   see the command description for recommendations.

I can't remember now why this text is here. Maybe it is just alerting 
about buggy implementations that might loop due to buffer overflows, etc.?

---

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 30 Mar 2007 17:40:42 -0400

I had submitted the following comment for -09:

    > 10.     Security Considerations

    >    Implementations SHOULD take measures to prevent languages from
    >    looping.

    I think it means "messages" not "languages"

"languages" was changed to "scripts" which seems no better.  I dunno,
maybe the original intent was "scripts" but I still don't see why that
would be there.  The reminder about message loops seems appropriate to me
for this section.

A couple of the other changes look familiar too :)

mm

---

From: "Aaron Stone" <[email-masked]>
Date: Fri, 30 Mar 2007 22:20:04 -0000

Everything looks good. A few more wordsmithing comments below.

> someone else sanity check this!).

[snip]

>   Match type arguments control what kind of match is to be performed by 

The whole thing is pretty awkward. Here's the whole paragraph in -12:

   These are used as optional arguments to tests that perform string
   comparison.

Suggest:

   Commands which perform string comparisons may have an optional match
   type argument. The three match types in this specification are ":is",
   ":contains", and ":matches". 

I don't think we need to define the word argument "argument". We only need
to explain what "match type arguments" are.

A bit later in the section, I suggest dropping the highlighted clause:

2.7.3. Comparators

   In order to allow for language-independent, case-independent matches,
   the match type may be coupled with a comparator name.  The Internet
   Application Protocol Collation Registry [COLLATION] provides the
   framework for describing and naming comparators as used by this
   specification.                                  ^^^^^^^^^^^^^^^
   ^^^^^^^^^^^^^^

The purpose of the registry is not to document what Sieve does. Rather,
Sieve is just using the registry.

[snip]

> 12. Added .sieve as a valid extension for sieve scripts.

Suggest:

    11. Updated IANA registration template, and added IANA considerations
        to permit capability prefix registrations.

We don't need to repeat the "vnd." requirement, we just have to point the
reader to that section of the document.

Aaron

Date: Fri, 30 Mar 2007 22:20:04 -0000
To: "Alexey Melnikov" <[email-masked]>, "Chris Newman" <[email-masked]>
Subject: Re: AD review of draft-ietf-sieve-3028bis-12
From: "Aaron Stone" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Everything looks good. A few more wordsmithing comments below.

> someone else sanity check this!).

[snip]

>   Match type arguments control what kind of match is to be performed by 

The whole thing is pretty awkward. Here's the whole paragraph in -12:

   These are used as optional arguments to tests that perform string
   comparison.

Suggest:

   Commands which perform string comparisons may have an optional match
   type argument. The three match types in this specification are ":is",
   ":contains", and ":matches". 

I don't think we need to define the word argument "argument". We only need
to explain what "match type arguments" are.

A bit later in the section, I suggest dropping the highlighted clause:

2.7.3. Comparators

   In order to allow for language-independent, case-independent matches,
   the match type may be coupled with a comparator name.  The Internet
   Application Protocol Collation Registry [COLLATION] provides the
   framework for describing and naming comparators as used by this
   specification.                                  ^^^^^^^^^^^^^^^
   ^^^^^^^^^^^^^^

The purpose of the registry is not to document what Sieve does. Rather,
Sieve is just using the registry.

[snip]

> 12. Added .sieve as a valid extension for sieve scripts.

Suggest:

    11. Updated IANA registration template, and added IANA considerations
        to permit capability prefix registrations.

We don't need to repeat the "vnd." requirement, we just have to point the
reader to that section of the document.

Aaron

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 30 Mar 2007 17:40:42 -0400
To: Alexey Melnikov <[email-masked]>
Cc: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: AD review of draft-ietf-sieve-3028bis-12
Sender: [email-masked]

mm

Date: Fri, 30 Mar 2007 22:15:39 +0100
From: Alexey Melnikov <[email-masked]>
To: Chris Newman <[email-masked]>
CC: [email-masked]
Subject: Re: AD review of draft-ietf-sieve-3028bis-12
Sender: [email-masked]

Date: Fri, 30 Mar 2007 22:10:56 +0100
From: Alexey Melnikov <[email-masked]>
To: Chris Newman <[email-masked]>
CC: [email-masked]
Subject: Re: AD review of draft-ietf-sieve-3028bis-12
Sender: [email-masked]

OLD:

In section 2.5:

OLD:

NEW:

(i.e. delete "/else")

OLD:

NEW:

OLD:

OLD:

OLD:

NEW:

OLD:

OLD:

NEW:

OLD:

OLD:

NEW:

In section 6.3:

OLD:

NEW:

In section 8.1:

OLD:

And also:

OLD:

In section 13:

In section 15:

Add to the end:

Date: Fri, 30 Mar 2007 16:42:45 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: Philip Guenther <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Subject: Re: AD review of draft-ietf-sieve-3028bis-12
Sender: [email-masked]

Hi Cyrus,

Date: Fri, 30 Mar 2007 10:56:25 -0400
From: Cyrus Daboo <[email-masked]>
To: Philip Guenther <[email-masked]>, Chris Newman <[email-masked]>
cc: [email-masked]
Subject: Re: AD review of draft-ietf-sieve-3028bis-12
Sender: [email-masked]

Hi Philip,

-- 
Cyrus Daboo

Date: Thu, 29 Mar 2007 23:19:34 -0700
From: Philip Guenther <[email-masked]>
To: Chris Newman <[email-masked]>
cc: [email-masked]
Subject: Re: AD review of draft-ietf-sieve-3028bis-12
Sender: [email-masked]

...

I like that.

Philip Guenther

Date: Fri, 30 Mar 2007 10:00:52 +0530
From: Chris Newman <[email-masked]>
Subject: Re: AD review of draft-ietf-sieve-3028bis-12
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Perhaps:

                - Chris

Date: Thu, 29 Mar 2007 18:15:07 +0100
From: Alexey Melnikov <[email-masked]>
To: Chris Newman <[email-masked]>
CC: [email-masked]
Subject: Re: AD review of draft-ietf-sieve-3028bis-12
Sender: [email-masked]

Thanks :-)

Agreed.
 [...]

Agreed.

Ok.
 [...]

Yes.
 [...]

Yes.

Sure.
 [...]

Yes!

*======================

No, there isn't any.
 [...]

How about the following:

 [...]

 [...]

I think you are right.

Date: Thu, 29 Mar 2007 18:34:03 +0530
From: Chris Newman <[email-masked]>
Subject: AD review of draft-ietf-sieve-3028bis-12
To: [email-masked]
Sender: [email-masked]

                - Chris Newman

-----
Section 1, 4th paragraph

Awkward wording.

Section 2.5

Section 2.6.2

Section 2.6.3

Awkward wording.

Section 2.7.1

Section 2.10.4

 numbers -> the number

Section 2.10.5

Section 4.2

  send->sent

Section 5.1 ***

Section 5.4

Awkward wording.

Section 5.9

                                ^^
                                nor

Section 8.1

Section 10

Section 13

Section 15

                - Chris

Date: Wed, 28 Mar 2007 18:06:19 -0000
To: "Alexey Melnikov" <[email-masked]>, "Barry Leiba" <[email-masked]>
Subject: Re: Comments on draft-ietf-lemonade-imap-sieve-02.txt
From: "Aaron Stone" <[email-masked]>
Cc: "Lemonade WG" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On Wed, Mar 28, 2007, Alexey Melnikov <[email-masked]> said:

[snip everything else]

> Other comments:
> 
> I suggest you add the following requirement: 'IMAP Sieve interpreters 
> SHOULD support Sieve "environment" test"'. And I would be Ok with it 
> being a MUST.

+1. I think that IMAP Sieve should probably require a fairly good profile
of Sieve extensions, particularly those which allow the script to be smart
about the context it is running in.

Aaron

Date: Wed, 28 Mar 2007 15:43:28 +0100
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: Lemonade WG <[email-masked]>, [email-masked]
Subject: Comments on draft-ietf-lemonade-imap-sieve-02.txt
Sender: [email-masked]

Hi Barry,
The document is in a much better shape now. Thank you.

Some comments below:

> 3.1.  The Implicit Keep
>
>    For all cases that fall under IMAPSieve, the implicit keep means that
>    the message is treated as it would have been if no Sieve script were
>    run.  For APPEND, MULTIAPPEND and COPY, the message is stored into
>    the target mailbox normally.  For flag or annotation changes, the
>    message is left in the mailbox.

And would the implicit keep mean for EXPUNGEs?

> 3.6.  The Discard Action
>
>    The discard action is applicable in all cases that fall under
>    IMAPSieve.  For APPEND, MULTIAPPEND, and COPY, the message is first
>    stored into the target mailbox.  If a keep action, implicit or
>    explicit, is also in effect, the discard action now does nothing.

'Discard' cancels the implicit keep, so it can't "do nothing".

>    Otherwise, the original message is then marked with the \Deleted flag
>    (and a flag-change Sieve script is NOT invoked).

We've discussed this briefly in Lemonade: this text doesn't agree with 
the definition of "discard" in the base Sieve document - it is just an 
action that cancels the implicit keep. After the discussion I think your 
interpretation of discard in IMAP Sieve is fine with me, but you need to 
add more text to describe the motivation.

> 3.8.  The Addheader and Deleteheader Actions
>
>    Even if the [EditHeader] extension is available, since messages in
>    IMAP mailboxes are immutable these actions are NOT applicable.  Using
>    them for flag or annotation changes to existing messages would cause
>    the message to be changed.  Using them for APPEND, MULTIAPPEND, and
>    COPY would cause unexpected differences in the stored copy as
>    compared to what the client expected, and would make the client's
>    message cache invalid unexpectedly.

As far as I can see the last two sentences are describing a "what if" 
situation, but I think the text as worded is not entirely clear on that.

>    Use of these MUST result in an
>    error condition that will terminate the Sieve script.
>
> 3.9.  The Setflag, Deleteflag, and Removeflag Actions
>
>    If the [IMAP4Flags] extension is available, the actions associated
>    with it are all applicable to any case that falls under IMAPSieve.
>    It is worth noting also that the "hasflag" test that is defined in
>    the IMAP4Flags extension might be particularly useful in scripts
>    triggered by flag changes.

I think you need to clarify that "hasflag" will test the current set of 
flags
that is set for the current message, as visible in IMAP.

>    The flag changes behave as though a
>    client had made the change.

  [...]

> 4.  Open Issues With This Document

  [...]

>    2.  All of the extensions that we describe how to work with: are they
>        normative, or non-normative references?

I think most of them are normative, except for the ones which are 
explicitly disallowed (such as addheader). For example you update the 
behavior of redirect and fileinto actions.

> 5.  Examples
>
>    Example 1:
>    If a new message is added to the "ActionItems" mailbox, a copy is
>    sent to the address "[email-masked]".
>
>      require ["copy", "variables"];

Replace "variables" with "environment" here.

>    Example 2:
>    If the script is called for any message with the \Flagged flag set
>    (tested through the [IMAP4Flags] extension), a notification is sent
>    using the [Notify] extension.  No notification will be sent, though,
>    if we're called with an existing message that already had that flag
>    set.
>
>      require ["nofity", "imap4flags", "variables"];

Replace "variables" with "environment" here.

>
>      if allof (hasflag "\\Flagged",
>                not environment :contains "changedflags" "\\Flagged") {
>          notify :message "Important message in ${IMAPSieve.mailbox}";

The example needs to be fixed, because ${IMAPSieve.mailbox} is not 
defined anymore.

>      }
>
>
> 7.1.  Registration of imapsieve extension
>
>    The following template specifies the IANA registration of the Sieve
>    extension specified in this document:
>
>    To: [email-masked]
>    Subject: Registration of new Sieve extension
>    Capability name: imapsieve
>    Capability keyword: imapsieve
>    Capability arguments: N/A

The template in 3028bis has changed, so your registration needs to be 
updated.

Other comments:

I suggest you add the following requirement: 'IMAP Sieve interpreters 
SHOULD support Sieve "environment" test"'. And I would be Ok with it 
being a MUST.

Subject: Re: Sieve notify options and escaping
From: Aaron Stone <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Date: Tue, 27 Mar 2007 07:14:14 -0700
Sender: [email-masked]

On Tue, 2007-03-27 at 14:03 +0200, Kjetil Torgrim Homme wrote:
> On Mon, 2007-03-26 at 17:53 +0000, Aaron Stone wrote:
> > Do we have the option for "lazy evaluation" of variable expansion? If the
> > expansion takes place inside the action, we have no trouble. If it takes
> > place prior to calling the action, we need escaping.
> 
> [variables] says:
> 
> 3.  Interpretation of strings
>    [...]
>    Tests or actions in future extensions may need to access the
>    unexpanded version of the string argument and, e.g., do the expansion
>    after setting variables in its namespace.  The design of the
>    implementation should allow this.
> 
> so the door is kept open, but the extension needs to be explicit about
> it.  notice that a separate namespace should be used for such "dynamic"
> or "internal" variables, in other words it should be ${notify.summary},
> not just ${summary}.  for normal variables without a namespace, the
> behaviour is:
> 
>    The expanded string MUST use the variable values which are current
>    when control reaches the statement the string is part of.

So a user can supply a variable that expands into valid options or url
syntax. I do think we have to prevent this.

Aaron

Subject: Re: Sieve notify options and escaping
From: Kjetil Torgrim Homme <[email-masked]>
To: Aaron Stone <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Date: Tue, 27 Mar 2007 14:03:24 +0200
Sender: [email-masked]

On Mon, 2007-03-26 at 17:53 +0000, Aaron Stone wrote:
> Do we have the option for "lazy evaluation" of variable expansion? If the
> expansion takes place inside the action, we have no trouble. If it takes
> place prior to calling the action, we need escaping.

[variables] says:

3.  Interpretation of strings
   [...]
   Tests or actions in future extensions may need to access the
   unexpanded version of the string argument and, e.g., do the expansion
   after setting variables in its namespace.  The design of the
   implementation should allow this.

so the door is kept open, but the extension needs to be explicit about
it.  notice that a separate namespace should be used for such "dynamic"
or "internal" variables, in other words it should be ${notify.summary},
not just ${summary}.  for normal variables without a namespace, the
behaviour is:

   The expanded string MUST use the variable values which are current
   when control reaches the statement the string is part of.

-- 
Kjetil T.

Date: Mon, 26 Mar 2007 17:53:48 -0000
To: "Alexey Melnikov" <[email-masked]>
Subject: Re: Sieve notify options and escaping
From: "Aaron Stone" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Mon, Mar 26, 2007, Alexey Melnikov <[email-masked]> said:

> Aaron, Dave has forwarded me your message:

Ok, moving back on list since we're more than one side-comment out.

> Dave Cridland wrote:
> 
>> Dave,
>>
>>Barry and I discussed the need for some text to say what this means:
>>
>>    notify :options "body=${summary}" "mailto:foo@bar" 
>>
>>Because when you expand ${summary} is pretty important wrt escaping.
>>Barry said that he'd add some text to handle this. I forgot to mention
>>it in the jabber room for the official notes.
>>  
>>
> Is this specific to Mailto notification method? Note that there is no 
> text in notify base saying that options are to be converted to URI 
> parameters.

Same issues arise from this:  mailto "mailto:foo@bar?body=${summary}"

What if ${summary} expands to "safebody&evil=evilbody"? We'll need some
text to handle this situation I think. The issue applies to all
mechanisms, I'm sure we could just as easily have additional xmpp url
arguments or options.

Do we have the option for "lazy evaluation" of variable expansion? If the
expansion takes place inside the action, we have no trouble. If it takes
place prior to calling the action, we need escaping.

> Also, do we actually want to register the "body" option?

Sure, I don't see why not...

Aaron 

Date: Sun, 25 Mar 2007 22:37:33 +0100
From: Alexey Melnikov <[email-masked]>
To: Aaron Stone <[email-masked]>
CC: [email-masked]
Subject: Re: Support for encoded-character
Sender: [email-masked]

Aaron Stone wrote:

>After the Sieve interop yesterday evening sort of crumbled over
>encoded-char, I implemented the hex side of things for libSieve.
>
>I also noticed that in 2038bis-12, 2.4.2.4, the sentence:
>
>   In the following script, message A is discarded, since the specified
>   test string is equivalent to "$$$".
>
>...should refer to 'message B'.
>  
>
Indeed. I've sent Lisa/Chris a note saying that this needs to be fixed 
before publication.

Date: Fri, 23 Mar 2007 18:19:31 +0000
From: Alexey Melnikov <[email-masked]>
To: Tony Hansen <[email-masked]>
CC: IETF MTA Filters List <[email-masked]>
Subject: Re: SIEVE mime loops
Sender: [email-masked]

Tony Hansen wrote:

> Two issues in section 6 are controversial and are denoted with "NB:". 

>6.  Action Enclose
>
>   Usage:  enclose <:subject string> <:headers string-list> string
>
>   A new SIEVE action command is defined to allow an entire message to
>   be enclosed as an attachment to a new message.  NB: The following
>   statement may be controversial:
>
It is.

>This enclose action takes precedence
>   over all other message modifications, such as "replace".
>  
>
First of all, I am not sure what "take precedence" means. If one 
replaces a part and then enclose the whole message, wouldn't you want to 
enclose the modified message? Or are you trying to say that this would 
be too difficult to implement and thus is not worth it?

>   ...
>   The Subject: header is specified by the :subject argument.  Any
>   headers specified by :headers are copied from the old message into
>   the new message.  NB: The following statement may be controversial:
>   If not specified by :headers, Date: and From: headers should be
>   synthesized to reflect the current date and the user running the
>   SIEVE action.
>  
>
(speaking as an individual contributor)
As I mentioned during the Sieve WG meeting in Prague, I think the 
synthesized message should use the current date. This would allow people 
to trace Sieve anomalies, as the date of the original message would be 
still inside the enclose container.
I am not so sure about the From, but the proposal seems reasonable.

Date: Fri, 23 Mar 2007 23:03:07 +0000
From: Alexey Melnikov <[email-masked]>
To: Tony Hansen <[email-masked]>
CC: Kjetil Torgrim Homme <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: SIEVE mime loops
Sender: [email-masked]

Kjetil Torgrim Homme wrote:

>>   Example:
>>
>>   require ["mime", "for_every_part", "fileinto"];
>>
>>   for_every_part
>>   {
>>       if header :mime :param "filename" :comparator
>>          "Content-Disposition" "important"
>>       {
>>           fileinto "INBOX.important";
>>           break;
>>       }
>>   }
>>    
>>
>the comparator is missing in the above example.
>  
>
Yes. I think :comparator should be deleted to use the default one.

>>7.  SIEVE Capability Strings
>>    
>>
>perhaps you could add the list of capability strings to the
>introduction?  I also think it would be useful if each section
>describing an extension named the capability string needed to enable it.
>  
>
I agree.

Some additional comments:

IANA registration for different Sieve extensions is missing.

One example uses "application/exe". I can't check IANA registry at the 
moment, but I think this is invalid.

Alexey

P.S. Apart from the issues mentioned above and open issues in the 
document, I think the document is ready for WGLC.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-mime-loop-02.txt 
Date: Thu, 22 Mar 2007 10:50:02 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: SIEVE Email Filtering:  MIME part Tests, Iteration, Replacement and Enclosure
	Author(s)	: T. Hansen, C. Daboo
	Filename	: draft-ietf-sieve-mime-loop-02.txt
	Pages		: 13
	Date		: 2007-3-22
	
The SIEVE email filtering language has no way to examine individual
   MIME parts or any way to manipulate those individual parts.  However,
   being able to filter based on MIME content is important.  This
   document defines extensions for these needs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-mime-loop-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-sieve-mime-loop-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-mime-loop-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-mime-loop-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-mime-loop-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Subject: Support for encoded-character
From: Aaron Stone <[email-masked]>
To: [email-masked]
Date: Tue, 20 Mar 2007 19:32:51 -0700
Sender: [email-masked]

After the Sieve interop yesterday evening sort of crumbled over
encoded-char, I implemented the hex side of things for libSieve.

I also noticed that in 2038bis-12, 2.4.2.4, the sentence:

   In the following script, message A is discarded, since the specified
   test string is equivalent to "$$$".

...should refer to 'message B'.

It's about 50 lines, quick-and-dirty, so when I do Unicode I'll write a
better little state machine loop that should be half as long as able to
do both hex and unicode. It should port nearly verbatim to Cyrus IMAPd.

I do ignore hex 00, however, as I'm not 100% 8-bit clean (and Cyrus is
_really_ not 8-bit clean). I assume this needs to be resolved before we
have a 'working implementation' for standards track purposes?

Aaron

X-Mail-Sent-By-AEGEE.org-Account: Dilyan Palauzov
From: "Dilyan Palauzov" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>, "Ned Freed" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Interaction between "editheader" and "redirect"
Date: Mon, 19 Mar 2007 19:38:56 +0100
Sender: [email-masked]

Hello,

> Can we rephrase the text to say that if an implementation allows deletion 
> of the Received headers, it MUST implement some other kind of  loop 
> control?

Suppose a message goes over hostA and hostB. hostA sends it to hostB, and 
hostB sends it to hostA. HostB deletes the Received: added by hostA, and 
hostA removes the headers added by hostB.

What kind of loop control can be here applied?

    Със здраве,
        Дилян 

Subject: Re: Interaction between "editheader" and "redirect"
From: Aaron Stone <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Tony Hansen <[email-masked]>, [email-masked]
Date: Mon, 19 Mar 2007 11:30:08 -0700
Sender: [email-masked]

On Mon, 2007-03-19 at 17:47 +0000, Alexey Melnikov wrote:
> Tony Hansen wrote:
> 
> >Alexey Melnikov wrote:
> >  
> >
> >>Ned Freed wrote:
> >>    
> >>
> >>>I see three ways to implement this:
> >>>
> >>>(1) Don't allow editheader actions on Received: fields, period.
> >>>(2) Silently ignore any deletions made to Recieved: fields when redirect
> >>>   is used.
> >>>(3) Add in enough dummy Received: field to keep the count from going
> >>>down.
> >>>
> >>>I'm going with option (2), but I have to question whether we really
> >>> want to allow (3). It sure sounds like a bad idea to me.
> >>>      
> >>>
> >>I agree that we don't want to encourage (3).
> >>Can we rephrase the text to say that if an implementation allows
> >>deletion of the Received headers, it MUST implement some other kind of
> >>loop control?
> >>    
> >>
> >I'd rather specify (1) but can live with (2).
> >
> >Note, there is a 4th option, which I'll call (1a).
> >
> >  (1a) Always silently ignore any deletions made to Received fields.
> >  
> >
> I think you meant 2a, i.e. it is a modification of 2, rather than 1.

+2. That is, +1 I like option 2a, and +1 Tony indeed meant 2a not 1a ;-)

Aaron

Date: Mon, 19 Mar 2007 17:47:38 +0000
From: Alexey Melnikov <[email-masked]>
To: Tony Hansen <[email-masked]>
CC: [email-masked]
Subject: Re: Interaction between "editheader" and "redirect"
Sender: [email-masked]

Tony Hansen wrote:

>Alexey Melnikov wrote:
>  
>
>>Ned Freed wrote:
>>    
>>
>>>I see three ways to implement this:
>>>
>>>(1) Don't allow editheader actions on Received: fields, period.
>>>(2) Silently ignore any deletions made to Recieved: fields when redirect
>>>   is used.
>>>(3) Add in enough dummy Received: field to keep the count from going
>>>down.
>>>
>>>I'm going with option (2), but I have to question whether we really
>>> want to allow (3). It sure sounds like a bad idea to me.
>>>      
>>>
>>I agree that we don't want to encourage (3).
>>Can we rephrase the text to say that if an implementation allows
>>deletion of the Received headers, it MUST implement some other kind of
>>loop control?
>>    
>>
>I'd rather specify (1) but can live with (2).
>
>Note, there is a 4th option, which I'll call (1a).
>
>  (1a) Always silently ignore any deletions made to Received fields.
>  
>
I think you meant 2a, i.e. it is a modification of 2, rather than 1.

Date: Mon, 19 Mar 2007 10:47:17 -0400
From: Barry Leiba <[email-masked]>
To: [email-masked]
CC: Dilyan Palauzov <[email-masked]>
Subject: Re: environment / Re: Revised drafts posted
Sender: [email-masked]

Kinda late reply here, sorry...

>>    I have a small question for the environment test: wouldn't it be
>> simpler to immitate the behaviour with variables:
> 
> I think doing this with variables and includes is actually quite a bit more
> complex and almost certainlyt less portable.

Even further than that, the suggestion assumes that the environment is 
static.  The default environment items are, but future extension items 
might not be.  In particular, I'm adding four environment items in 
draft-ietf-lemonade-imap-sieve-02: the type of event that triggered the 
script, the mailbox that the message is in or will be stored in, and so 
on.  That's not static info that can be "included".

Barry

--
Barry Leiba, STSM, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

Subject: Re: SIEVE mime loops
From: Kjetil Torgrim Homme <[email-masked]>
To: Tony Hansen <[email-masked]>
Cc: IETF MTA Filters List <[email-masked]>
Date: Mon, 19 Mar 2007 12:28:18 +0100
Sender: [email-masked]

On Sun, 2007-03-18 at 20:27 -0400, Tony Hansen wrote:
> 4.1.  Test "header"
> 
>    The "header" test is extended with the addition of a new ":mime"
>    tagged argument, which takes a number of other arguments.
> 
>    Usage:  header [:mime] [:anychild] [MIMEOPTS]
>       [COMPARATOR] [MATCH-TYPE]
>       <header-names: string-list> <key-list: string-list>
> 
>    Usage:  The definition of [MIMEOPTS] is:
> 
>       Syntax: ":type" / ":subtype" / ":contenttype" /
>       ":param" <param-list: string-list>

this extension would be useful for "string" in variables, too, in
particular the :param bit which allows us to (ab)use a variable as a
hash.

myvar["key"] = "value" could be written:

    set "myvar" "${myvar}; key=value";

to extract it, use

    if string :mime :param "key" :matches "myvar" "*" ...

not sure how to specify this extension conveniently, though.

>    When the ":mime" tagged argument is present in the "header" test, it
>    will parse the MIME header lines in a message so that tests can be
>    performed on specific elements.
> 
>    If the ":anychild" tagged argument is NOT specified:
> 
>    o  If used within the context of a "for_every_part" iterator, the
>       "header" test will examine the headers associated with the current
>       MIME part context from the loop.
> 
>    o  If used outside the context of a "for_every_part" iterator, the
>       "header" test will examine only the outer, top-level, headers of
>       the message.

I feel it is unnecessary to change the semantics of "header" when there
is no :mime.  if you don't have access to variables, it can be
inconvenient to write rules which both rely on top-level headers and
MIME properties.  my suggestion is that you need to write :mime to
inspect the inner parts.

>    Example:
> 
>    require ["mime", "for_every_part", "fileinto"];
> 
>    for_every_part
>    {
>        if header :mime :param "filename" :comparator
>           "Content-Disposition" "important"
>        {
>            fileinto "INBOX.important";
>            break;
>        }
>    }

the comparator is missing in the above example.

> 7.  SIEVE Capability Strings

perhaps you could add the list of capability strings to the
introduction?  I also think it would be useful if each section
describing an extension named the capability string needed to enable it.

looks good to me!

-- 
Kjetil T.

Date: Mon, 19 Mar 2007 08:55:37 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Slides for the Sieve WG meeting uploaded
Sender: [email-masked]

Check 
<https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68>

Date: Mon, 19 Mar 2007 04:41:34 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: Interaction between "editheader" and "redirect"
Sender: [email-masked]

Alexey Melnikov wrote:
> 
> Ned Freed wrote:
>> I see three ways to implement this:
>>
>> (1) Don't allow editheader actions on Received: fields, period.
>> (2) Silently ignore any deletions made to Recieved: fields when redirect
>>    is used.
>> (3) Add in enough dummy Received: field to keep the count from going
>> down.
>>
>> I'm going with option (2), but I have to question whether we really
>>  want to allow (3). It sure sounds like a bad idea to me.
> 
> I agree that we don't want to encourage (3).
> Can we rephrase the text to say that if an implementation allows
> deletion of the Received headers, it MUST implement some other kind of
> loop control?

I'd rather specify (1) but can live with (2).

Note, there is a 4th option, which I'll call (1a).

  (1a) Always silently ignore any deletions made to Received fields.

	Tony Hansen
	[email-masked]

Date: Sun, 18 Mar 2007 20:21:38 +0000
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
CC: [email-masked]
Subject: Re: Interaction between "editheader" and "redirect"
Sender: [email-masked]

Ned Freed wrote:

>> Folks,
>> Philip recently posted draft-ietf-sieve-editheader-08.txt. Below is the
>> summary of changes done to address interaction between "editheader" and
>> "redirect". I would like to quickly confirm that the changes are fine
>> with everyone.
>
>> ==============
>> Additional text in section 4 (Action deleteheader):
>
>>    If an script uses the deleteheader action to remove "Received"
>>    header fields and then performs a "redirect" action, the
>>    implementation SHOULD NOT send the outgoing message with fewer
>>    Received header fields than the original message.  If the
>>    implementation does not permit that for the involved script, it
>>    is implementation defined what Received header fields are present
>>    in such an outgoing message.  The above overrides the requirement
>>    on Received header fields in RFC-ietf-sieve-3028bis-12 section
>>    4.2.
>
> I see three ways to implement this:
>
> (1) Don't allow editheader actions on Received: fields, period.
> (2) Silently ignore any deletions made to Recieved: fields when redirect
>    is used.
> (3) Add in enough dummy Received: field to keep the count from going 
> down.
>
> I'm going with option (2), but I have to question whether we really 
> want to
> allow (3). It sure sounds like a bad idea to me.

I agree that we don't want to encourage (3).
Can we rephrase the text to say that if an implementation allows 
deletion of the Received headers, it MUST implement some other kind of 
loop control?

>> The following paragraph in section 5 (Interaction with Other Sieve
>> Extensions):
>
>>    All other actions that store or send the message MUST do so with
>>    the current set of header fields.
>
>> was replaced with:
>
>>    With the exception of the special handling of "redirect" and
>>    "Received" header fields described above, all other actions that
>>    store or send the message MUST do so with the current set of
>>    header fields.
>
> What about actions that result in a DSN or MDN that returns content? I 
> don't
> think it is a good idea to use the modified message in such cases.

I agree that "reject" should be excluded from this rule as well.

> I can interpret "send" as including or excluding such operations so I 
> think
> this could be a bit clearer.

Date: Sun, 18 Mar 2007 20:27:34 -0400
From: Tony Hansen <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
Subject: Re: SIEVE mime loops
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------010807020908070606010100
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Alexey Melnikov wrote:
> Guys, can you please do a new revision before the meeting, so that we
> can discuss it.
> Sending it to the mailing list would be fine.

So, better late than never, draft-ietf-sieve-loops-02 is enclosed.

12.  Change History (to be removed prior to publication as an RFC)
12.1.  draft-ietf-sieve-mime-02

   minor syntax glitches in examples

   Add clarification on "replace" affecting subsequent for_every_part
   loops?

   Add IANA considerations for Original-Subject: and Original-From:.

   Add note on "enclose" creating From: and Date: headers.

Two issues in section 6 are controversial and are denoted with "NB:".

6.  Action Enclose

   Usage:  enclose <:subject string> <:headers string-list> string

   A new SIEVE action command is defined to allow an entire message to
   be enclosed as an attachment to a new message.  NB: The following
   statement may be controversial: This enclose action takes precedence
   over all other message modifications, such as "replace".
   ...
   The Subject: header is specified by the :subject argument.  Any
   headers specified by :headers are copied from the old message into
   the new message.  NB: The following statement may be controversial:
   If not specified by :headers, Date: and From: headers should be
   synthesized to reflect the current date and the user running the
   SIEVE action.

	Tony Hansen
	[email-masked]

--------------010807020908070606010100
Content-Type: text/plain;
 name="draft-ietf-sieve-mime-loop-02.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
 filename="draft-ietf-sieve-mime-loop-02.txt"

Internet Engineering Task Force                                T. Hansen
Internet-Draft                                         AT&T Laboratories
Intended status: Standards Track                                C. Daboo
Expires: September 19, 2007                               Apple Computer
                                                          March 18, 2007

  SIEVE Email Filtering:  MIME part Tests, Iteration, Replacement and
                               Enclosure
                   draft-ietf-sieve-mime-loop-02.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 19, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   The SIEVE email filtering language has no way to examine individual
   MIME parts or any way to manipulate those individual parts.  However,
   being able to filter based on MIME content is important.  This
   document defines extensions for these needs.

Hansen & Daboo         Expires September 19, 2007               [Page 1]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007

Note

   This document is being discussed on the MTA-FILTERS mailing list,
   [email-masked].

1.  Introduction

   SIEVE scripts are used to make decisions about the disposition of an
   email message.  The base SIEVE specification,
   [I-D.ietf-sieve-3028bis], defines operators for looking at the
   message headers, such as addresses and the subject.  Other extensions
   provide access to the body of the message ([I-D.ietf-sieve-body]), or
   allow you to manipulate the header of the message
   ([I-D.ietf-sieve-editheader]).  But none of these extensions take
   into account that MIME messages ([RFC2045]) are often complex
   objects, consisting of many parts and sub-parts.  This extension
   defines mechanisms for performing tests on MIME body parts, looping
   through the MIME body parts, changing the contents of a MIME body
   part, and enclosing the message with a wrapper.

2.  Conventions Used in This Document

   Conventions for notations are as in [I-D.ietf-sieve-3028bis] section
   1.1.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  SIEVE Loops

   The base SIEVE language has no looping mechanism.  Given that
   messages may contain multiple parts, in order to support filters that
   apply to any and all parts, we introduce a new control command:
   "for_every_part", which is an iterator that walks though every MIME
   part of a message, including nested parts, and applies the commands
   in the specified block to each of them.  The iterator will start with
   the first MIME part (as its current context) and will execute a
   command block (SIEVE commands enclosed by { ...}).  Upon completion
   of this command block, the iterator advances to the next MIME part
   (as its current context) and executes the same command block again.

   The iterator can be terminated prematurely by a new SIEVE command,
   "break".

Hansen & Daboo         Expires September 19, 2007               [Page 2]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007

   Usage:  for_every_part block

   Usage:  break;

   "for_every_part" commands can be nested inside other "for_every_part"
   commands.  When this occurs, the nested "for_every_part" iterates
   over the MIME parts contained within the MIME part current being
   targeted by the nearest enclosing "for_every_part" command.  If that
   MIME part is a terminal MIME part (i.e. does not contain other MIME
   parts) then the nested "for_every_loop" is simply ignored.

   SIEVE implementations MAY limit the number of nested loops that occur
   within one another, however they MUST support at least one nested
   loop inside another loop.

4.  Changes to SIEVE tests

   This specification extends the base SIEVE "header", "address" and
   "exists" tests to support targeting those tests at a specific MIME
   part or at all MIME parts in the enclosing scope.

4.1.  Test "header"

   The "header" test is extended with the addition of a new ":mime"
   tagged argument, which takes a number of other arguments.

   Usage:  header [:mime] [:anychild] [MIMEOPTS]
      [COMPARATOR] [MATCH-TYPE]
      <header-names: string-list> <key-list: string-list>

   Usage:  The definition of [MIMEOPTS] is:

      Syntax: ":type" / ":subtype" / ":contenttype" /
      ":param" <param-list: string-list>

   When the ":mime" tagged argument is present in the "header" test, it
   will parse the MIME header lines in a message so that tests can be
   performed on specific elements.

   If the ":anychild" tagged argument is NOT specified:

   o  If used within the context of a "for_every_part" iterator, the
      "header" test will examine the headers associated with the current
      MIME part context from the loop.

   o  If used outside the context of a "for_every_part" iterator, the
      "header" test will examine only the outer, top-level, headers of

Hansen & Daboo         Expires September 19, 2007               [Page 3]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007

      the message.

   If the ":anychild" tagged argument IS specified, the "header" test
   will examine all MIME body parts and return true if any of them
   satisfies the test.

   The "header" test with the ":mime" tagged argument can test various
   aspects of certain structed MIME headers.  These options are
   available:

   :type  parses the header assuming it has the format of a "Content-
      Type:" MIME header field, and tests the value of the MIME type
      specified in the header.

   :subtype  parses the header assuming it has the format of a "Content-
      Type:" MIME header field, and tests the value of the MIME subtype
      specified in the header.

   :contenttype  parses the header assuming it has the format of a
      "Content-Type:" MIME header field, and tests the combined value of
      the MIME type and subtype specified in the header.

   :param  parses the header looking for MIME parameters in the header.
      The supplied string-list lists the names of any parameters to be
      tested.  If any one named parameter value matches the test string
      value, the test will return true.

   Example:

   require ["mime", "fileinto"];

   if header :mime :type "Content-Type" "image"
   {
       fileinto "INBOX.images";
   }

   In this example, any message that contains a MIME image type part at
   the top-level is saved to the mailbox "INBOX.images".

   Example:

   require ["mime", "fileinto"];

   if header :mime :anychild :contenttype :comparator
             "Content-Type" "text/html"
   {
       fileinto "INBOX.html";
   }

Hansen & Daboo         Expires September 19, 2007               [Page 4]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007

   In this example, any message that contains any MIME part with a
   content-type of "text/html" is saved to the mailbox "INBOX.html".

   Example:

   require ["mime", "for_every_part", "fileinto"];

   for_every_part
   {
       if header :mime :param "filename" :comparator
          "Content-Disposition" "important"
       {
           fileinto "INBOX.important";
           break;
       }
   }

   In this example, any message that contains any MIME part with a
   content-disposition with a filename parameter containing the text
   "important" is saved to the mailbox "INBOX.important".

4.2.  Test "address"

   The "address" test is extended with the addition of a new ":mime"
   tagged argument, which takes a number of other arguments.

   Usage:  address [:mime] [:anychild] [COMPARATOR]
      [ADDRESS-PART] [MATCH-TYPE]
      <header-list: string-list> <key-list: string-list>

   When the ":mime" tagged argument is present in the "address" test, it
   will parse the MIME header lines as if they were standard address
   header lines in a message so that tests can be performed on specific
   elements.

   The behavior of the ":anychild" tagged argument and the interaction
   with the "for_every_part" iterator is the same as for the extended
   "header" test Section 4.1.

   Example:

   require ["mime", "fileinto"];

   if address :mime :is :all "content-from" "[email-masked]"
   {
       fileinto "INBOX.part-from-tim";
   }

Hansen & Daboo         Expires September 19, 2007               [Page 5]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007

   In this example, any message that contains a MIME Content-From header
   at the top-level matching the text "[email-masked]" is saved to the
   mailbox "INBOX.part-from-time".

4.3.  Test "exists"

   The "exists" test is extended with the addition of a new ":mime"
   tagged argument, which takes one other argument.

   Usage:  exists [:mime] [:anychild] <header-names: string-list>

   When the ":mime" tagged argument is present in the "exists" test, the
   test is extended to check for the existence of MIME headers in MIME
   parts.

   The behavior of the ":anychild" tagged argument and the interaction
   with the "for_every_part" iterator is the same as for the extended
   "header" test Section 4.1.

   Example:

   require ["mime", "fileinto"];

   if exists :mime :anychild "content-md5"
   {
       fileinto "INBOX.md5";
   }

   In this example, any message that contains a MIME Content-MD5 header
   in any MIME part is saved to the mailbox "INBOX.md5".

5.  Action Replace

   Usage:  replace [:mime] [:subject string] [:from string]
      <replacement: string>

   The "replace" command is defined to allow a MIME part to be replaced
   with the text supplied in the command.

   When used in the context of a "for_every_part" iterator, the MIME
   part to be replaced is the "current" MIME part.  If the current MIME
   context is a multipart MIME part, the entire multipart MIME part is
   replaced, which would alter the MIME structure of the message by
   eliminating all of the children of the multipart part.  (Replacing a
   non-multipart MIME part within a "for_every_part" loop context does
   not alter the overall message structure.)  If the MIME structure is
   altered, the change takes effect immediately: the "for_every_part"

Hansen & Daboo         Expires September 19, 2007               [Page 6]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007

   iterator that is executing does not go into the no-longer existing
   body parts, and subsequent "for_every_part" iterators would use the
   new message structure.

   When used outside the context of a "for_every_part" loop, the MIME
   part to be replaced is the entire message.

   If the :mime parameter is not specified, the replacement string is a
   text/plain part.

   If the :mime parameter is specified, then the replacement string is,
   in fact, a MIME entity as defined in [RFC2045] section 2.4, including
   both MIME headers and content.  If the optional :mime parameter is
   not supplied, the reason string is considered to be a UTF-8 string.

   If the entire message is being replaced, a ":subject" parameter
   specifies a subject line to attach to the message that is generated.
   UTF-8 characters can be used in the string argument; implementations
   MUST convert the string to [RFC2047] encoded words if and only if
   non-ASCII characters are present.  Implementations MUST preserve the
   previous Subject header as an Original-Subject header.

   If the entire message is being replaced, a ":from" parameter may be
   used to specify an alternate address to use in the From field of the
   message that is generated.  The string must specify a valid [RFC2822]
   mailbox-list.  Implementations SHOULD check the syntax and generate
   an error when a syntactically invalid ":from" parameter is specified.
   Implementations MAY also impose restrictions on what addresses can be
   specified in a ":from" parameter; it is suggested that values that
   fail such a validity check simply be ignored rather than causing the
   replace action to fail.  Implementations MUST preserve the previous
   From header as an Original-From header.

6.  Action Enclose

   Usage:  enclose <:subject string> <:headers string-list> string

   A new SIEVE action command is defined to allow an entire message to
   be enclosed as an attachment to a new message.  NB: The following
   statement may be controversial: This enclose action takes precedence
   over all other message modifications, such as "replace".  If multiple
   "enclose" actions are executed by a script, only the text specified
   on the last one is used when creating the enclosed message.  This
   action does not affect messages that are forwarded via a "redirect"
   action.

   Specifically, the original message becomes a multipart/mixed message

Hansen & Daboo         Expires September 19, 2007               [Page 7]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007

   with two parts: a text/plain portion with the string argument as its
   body, and a message/rfc822 portion with the original message
   enclosed.  The Content-Type: header field becomes multipart/mixed.
   The Subject: header is specified by the :subject argument.  Any
   headers specified by :headers are copied from the old message into
   the new message.  NB: The following statement may be controversial:
   If not specified by :headers, Date: and From: headers should be
   synthesized to reflect the current date and the user running the
   SIEVE action.

7.  SIEVE Capability Strings

   A SIEVE implementation that defines the "for_every_part" and "break"
   actions will advertise the capability string "for_every_part".

   A SIEVE implementation that defines the ":mime" tagged arguments to
   the "header", "address" and "exists" commands will advertise the
   capability string "mime".

   A SIEVE implementation that defines the "replace" action will
   advertise the capability string "replace".

   A SIEVE implementation that defines the "enclose" action will
   advertise the capability string "enclose".

8.  Examples

8.1.  Example 1

   A SIEVE script to replace all the Windows executable attachments in a
   message would be:

require [ "for_every_part", "mime", "replace" ];
for_every_part
{
  if ( anyof (
         header :mime :contenttype :is "Content-Type" "application/exe",
         header :mime :param "filename"
           ["Content-Type", "Content-Disposition"] :matches "*.com" )
  {
    replace "Executable attachment removed by user filter";
  }
}

Hansen & Daboo         Expires September 19, 2007               [Page 8]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007

8.2.  Example 2

   A SIEVE script to warn the user about executable attachment types
   would be:

   require [ "for_every_part", "mime", "enclose" ];

   for_every_part
   {
     if header :mime :param "filename"
        ["Content-Type", "Content-Disposition"] :matches
          ["*.com", "*.exe", "*.vbs", "*.scr",
           "*.pif", "*.hta", "*.bat", "*.zip" ]
     {
       # these attachment types are executable
       enclose :subject "Warning" "
   WARNING! The enclosed message contains executable attachments.
   These attachments types may contain a computer virus program
   that can infect your computer and potentently damage your data

   Before clicking on these message attachments, you should verify
   with the sender that this message was sent by them and not a
   computer virus.
   ";
       break;
     }
   }

9.  Acknowledgements

   Comments from members of the MTA Filters Working Group, in particular
   Ned Freed, Nigel Swinson and Mark Mallett, are gratefully
   acknowledged.

   To be provided

11.  IANA Considerations

   The Original-Subject: and Original-From: headers are to be registered
   in the Permanent Message Header Fields table.

Hansen & Daboo         Expires September 19, 2007               [Page 9]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007

12.  Change History (to be removed prior to publication as an RFC)

12.1.  draft-ietf-sieve-mime-02

   minor syntax glitches in examples

   Add clarification on "replace" affecting subsequent for_every_part
   loops?

   Add IANA considerations for Original-Subject: and Original-From:.

   Add note on "enclose" creating From: and Date: headers.

12.2.  draft-ietf-sieve-mime-01

   what happens when nested for_every_loop's

   a "mime" shorthand for testing the type/subtype, without requiring

   interactions with variables
   notifications
   notifications to calendar service
   address tests, exists tests
   mimeheader, mimeparameter tests

12.3.  draft-ietf-sieve-mime-00

   Changed title and text to emphasize MIME Tests.

   Changed for.every.part to for_every_part.

   Added :anychild to mime test.  Default is to use the current context
   or outer envelope; specifying :anychild will look at all children.

   Added clarifications to replacing parts affecting the structure.

   Added :mime option to replace, ala draft-ietf-sieve-vacation-06.

   Various other minor nit fixes.

12.4.  draft-hansen-sieve-loop-01

   Merged with draft-daboo-sieve-mime-00.txt.

12.5.  draft-hansen-sieve-loop-02

Hansen & Daboo         Expires September 19, 2007              [Page 10]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007

      Update to 3028bis reference.

      Added 2119 conventions section.

      Terminology/title tweaks.

      Added informative references to body and editheader extensions.

      Added description of nested loops.

      Replaced mime test by extensions to header, address and exists
      tests.

13.  References

13.1.  Normative References

   [I-D.ietf-sieve-3028bis]
              Showalter, T. and P. Guenther, "Sieve: An Email Filtering
              Language", draft-ietf-sieve-3028bis-12 (work in progress),
              February 2007.

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
              Part Three: Message Header Extensions for Non-ASCII Text",
              RFC 2047, November 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
              April 2001.

13.2.  Informative References

   [I-D.ietf-sieve-body]
              Guenther, P. and J. Degener, "Sieve Email Filtering: Body
              Extension", draft-ietf-sieve-body-06 (work in progress),
              February 2007.

   [I-D.ietf-sieve-editheader]
              Guenther, P. and J. Degener, "Sieve Email Filtering:
              Editheader Extension", draft-ietf-sieve-editheader-08
              (work in progress), March 2007.

Hansen & Daboo         Expires September 19, 2007              [Page 11]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007

Authors' Addresses

   Tony Hansen
   AT&T Laboratories
   200 Laurel Ave.
   Middletown, NJ  07748
   USA

   Email: [email-masked]

   Cyrus Daboo
   Apple Computer, Inc.
   1 Infinite Loop
   Cupertino, CA  95014
   USA

   Email: [email-masked]
   URI:   http://www.apple.com/

Hansen & Daboo         Expires September 19, 2007              [Page 12]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Hansen & Daboo         Expires September 19, 2007              [Page 13]
=0C

--------------010807020908070606010100--

From: "=?windows-1251?B?zeXw5eLl7fzq7iDe8Ojp?=" <[email-masked]>
Subject: =?windows-1251?B?zu/r4PLgIPLw8+TgIC0g4eXx7+vg8u3g/yDv8O7j8ODs7OAgICAgKGFpdXNuYSk=?=
Date: Tue, 13 Mar 2007 15:45:33 -0700
To: undisclosed-recipients:;
Sender: [email-masked]

	"������ ����� �� "�" �� "�". ���������� ������� ���������������, ����������� � ����������� ������ �����, ������������� � ��������� �������� ���������." 

/������ ������� ����, ������������ �������� ��������������� ��������, �������������� ������������, ���������� � ��������� ������������./ 

>   ��������� � ������ ����� � 1 ������ 2007 ���� ������������� ��������� ����� �����������. ���� ����� ������ "���������" ������ ����� ��! ����������� ��� "��������� �����" ���������� ����, �� ������� �� ����� ��������. 

                           1 6   � � � � �  2007 �. 
                         8-(0-4-4) 5..6..0..1..6..5..5 

>����� ��������� ��������� � ���������������� � �����:
���������� ����� ������ ���� � 2007 ����; ������� ����������� � ������������ ������ � 2007 ����; ������ ������� � ���� ��������� �� ���������� ���������;  ���������� ������� ����� �������� �� ��������; ����� ���������� ��� ������� ������������ ���������; ��������� � ������� ���������� ��������� ������; ����� � ������� ���������� �������� �������;   ����������� ���������� �������������� ����� �������� ������� � ������� ������� ������;  ����� � ������� ���������� ������ ����������; ��������� � ������� ��������� ��������� ������ ��-����������; ������� ������� �� ����� �� ����� ���������;  ��������������� ���� ����������� �� ���������������� ������ ��� �������� ���������; ����� �� ������� �������� �������� ���� �� ��������� ����� ������;  ������ ������������ ���������� ������ �� �������� �����, ������������� �� ����������� � ������� �� ����� �� ��������; ���������� ���������� ������� � ��������� �� 1 ������� 2007 �.; ��������������� ������ ������ �� ����� ��������� �����; �������
  �������������� ��������� ����� �

>����� �� ������ ������:
����������� ���������� ��������� ���������� �����, � �.�. �� �����;  ��������������� ������������ ������; ������������� ������ � ���� �������������� ���� (������ �����, �������, ������, �������������� ����� � �.�.) ��� ���������� ���������� ��������; ����������� ��������������� ���� ������ ��������, ����������� � ������� ����������; ����������� ��������������� �������� ����� �������������� � ��; ��������������� ���� ����������� �� ������������� ��������� ���������, �������� �����;  ��������������� ������ �� �������� �����������; ������� ������ ������ ��� ������� ���������� � ��.
>������ � ���������� �����:
����������� ���� �������, ������������ �� ������� �������� ������ ������� ������������ ��������; ������� �������, �� ����������� � ��������, � ������������ ��������; ���������� ���������� �������� ��� ���������� ������������ ��������;���������� ������� ��� ��������, ������������ �� ��������� ��������;����������� ���������� ������� ��� �������� ��������� ���������� ��� �� ���������� �����;����������� ������� �� ��������� ��� �������� � ���������� � ��.���������� � ����������� ����� ��������� (���������������, ����������, ���������������-������������� �������� �������, �����������, ���������� ����, ������������ ���������� ������� ����).��������� �������� �� ������ ����� �� ������� �������. 

>������� ����������� ������ ����� �� �����������:
���������� ��������� �� ������ ����� � �������� ����������;���������� �������������� ������������� ���� �������� � �����������;������� ������ � ������ ������� (� ������ �����, �����������, � �������� ��������� � �.�.);
��������� �� �������� ���������� (���������� �����, ������, ��������);������� ������� ������� �������� (����������, ������������, ���������);����� ������� ���������� ��������;������� � ����������� �� ����������-�������� ���������;�������������� � ������������;��������������� �� ��������� ��������� ���������������� � ��������� � ��������������� ��������. ������ �� ������� ����������. 

>������ � ������������: 
�e�c����e����� ��e�� ���A� � Co��a a����opo� ��pa���, a����op� c ��o�o�e���� c�a�e�, c�e��a��c�� � o��ac�� �a�o�o�o�o ��a��po�a���, a��op� ������a��� �o �o�poca� �a�o�oo��o�e��� �e����x �e�o��x � ��x�a��epc��x C��, �o�c����a��� �o �o����k�a� c op�a�a�� ��A�. 

5  6  0  .  0  0    �   p  �  . 

� 9-30 �� 17-00, � ���������� �� ����-����� � ����. 

*-������ �� ������� ��������� � �� (��.5, �.5.2.1. ������ "� ��������������� �������") 

����� ����������: �.����, ���������-��� ����� "Sankt-Peterburg", ������� �.��������,4 (�."��������"). 

���������� ���� ����������! ������� ������������������ �������, ���.8.0.4.4-5~6~0-1~6-5~5 

> ����� �� ������� ���������� ��������� �������� ����  � ������� ���������� ���������� ��������!

=====
gpzjb700417727636674190

Date: Fri, 09 Mar 2007 15:53:34 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Working Group Last Call on draft-ietf-sieve-notify-mailto-02.txt
Sender: [email-masked]

We would like to draw your attention to the following draft:

<http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-mailto-02.txt>

A three week working group last call of this document starts today on 
March 9th 2007 and ends on March 30th 2007 at 6 pm EST.

Please review this document and send issues to the list or direct to the 
author(s). In the latter case please CC both WG chairs, so that we can 
track issues.

NB If you do review this document, but have no issues or comments, 
please send both co-chairs (or the list) an email to indicate you have 
looked at it. This will allow the chairs to gauge the scope of reviews 
of this document to aid in our determination on whether to send it to 
the IESG. Thanks.

--
Cyrus Daboo and Alexey Melnikov
SIEVE WG chairs

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-notify-mailto-02.txt 
Date: Thu, 08 Mar 2007 15:50:04 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Notification Mechanism: mailto
	Author(s)	: B. Leiba, M. Haardt
	Filename	: draft-ietf-sieve-notify-mailto-02.txt
	Pages		: 13
	Date		: 2007-3-8
	
This document describes a profile of the Sieve extension for
   notifications, to allow notifications to be sent by electronic mail.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-mailto-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-sieve-notify-mailto-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-notify-mailto-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-notify-mailto-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-notify-mailto-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Subject: Re: Interaction between "editheader" and "redirect"
From: Aaron Stone <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Date: Wed, 07 Mar 2007 11:39:37 -0800
Sender: [email-masked]

On Wed, 2007-03-07 at 10:12 +0000, Alexey Melnikov wrote:

[snip]
>    With the exception of the special handling of "redirect" and
>    "Received" header fields described above, all other actions that
>    store or send the message MUST do so with the current set of
>    header fields.

I figure that 'current' is defined as 'the set of headers as modified by
the editheader commands at this point in the script' but I had to think
about it for a moment. Could we dumb it down a notch to make the meaning
of 'current' more explicit?

> Additional paragraph in section 7 (Security Considerations):
> 
>    While this specification overrides the requirement that redirected
>    messages have more Received header fields than the message as
                        ^       ^ add double quotes to be consistent?
>    received, doing so removes an important mechanisms for detecting
                                                      ^ zap the 's'
>    loops and therefore should not be permitted by implementations
>    without due consideration, such as requiring administrative
                              ^ end the sentence here?
>    action to enable it.

Aaron

Subject: Re: Interaction between "editheader" and "redirect"
From: Aaron Stone <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Date: Wed, 07 Mar 2007 11:39:37 -0800
Sender: [email-masked]

On Wed, 2007-03-07 at 10:12 +0000, Alexey Melnikov wrote:

[snip]
>    With the exception of the special handling of "redirect" and
>    "Received" header fields described above, all other actions that
>    store or send the message MUST do so with the current set of
>    header fields.

I figure that 'current' is defined as 'the set of headers as modified by
the editheader commands at this point in the script' but I had to think
about it for a moment. Could we dumb it down a notch to make the meaning
of 'current' more explicit?

> Additional paragraph in section 7 (Security Considerations):
> 
>    While this specification overrides the requirement that redirected
>    messages have more Received header fields than the message as
                        ^       ^ add double quotes to be consistent?
>    received, doing so removes an important mechanisms for detecting
                                                      ^ zap the 's'
>    loops and therefore should not be permitted by implementations
>    without due consideration, such as requiring administrative
                              ^ end the sentence here?
>    action to enable it.

Aaron

Date: Wed, 7 Mar 2007 17:17:03 -0700
From: Philip Guenther <[email-masked]>
To: Dilyan Palauzov <[email-masked]>
cc: [email-masked]
Subject: Re: editheader (and redirect)
Sender: [email-masked]

On Thu, 8 Mar 2007, Dilyan Palauzov wrote:
...
> And  about editheader:
>
>  3. Action addheader:
>
>  The addheader action adds a header field to the existing message
>  header.  If the field-name is not a valid 7-bit US-ASCII header
>  field name as described by the [IMAIL] "field-name" nonterminal
>  syntax element, the implementation MUST flag an error.  The
>  addheader action does not affect Sieve's implicit keep.
>
> I am against this 7bit ASCII restriction. Once draft-ietf-eai-utf8headers 
> gets a rfc number, it will be normal to add UTF8 headers, apart the ASCII 7 
> bits one.

The restriction is on the field *name*, not on the value.  The EAI draft 
you mention does not currently permit non-ASCII characters in the field 
name and suggestions to permit them have been consistently rejected.

...
>  If an script uses the deleteheader action ...
>  -> If a script uses the deleteheader action ...

Fixed.

> In
>  5 Interaction with Other Sieve Extensions
>
>  shouldn|t it be canceLLed instead of canceLed? I am not an expert, but 
> consider canceLLed is better.

American english usage, which is what the RFC series tends to follow, 
prefers "canceled" over "cancelled".

Philip Guenther

Date: Thu, 08 Mar 2007 00:44:41 +0100
From: Dilyan Palauzov <[email-masked]>
To: [email-masked]
Subject: editheader (and redirect)
Sender: [email-masked]

Hello,

Concerning the discussion with redirect I am in favour of Ned's 2nd  
suggestion:

(2) Silently ignore any deletions made to Recieved: fields when  
redirect is used.

And пдие about editheader:

    3. Action addheader:

    The addheader action adds a header field to the existing message
    header.  If the field-name is not a valid 7-bit US-ASCII header
    field name as described by the [IMAIL] "field-name" nonterminal
    syntax element, the implementation MUST flag an error.  The
    addheader action does not affect Sieve's implicit keep.

I am against this 7bit ASCII restriction. Once  
draft-ietf-eai-utf8headers gets a rfc number, it will be normal to add  
UTF8 headers, apart the ASCII 7 bits one. And because we don't want  
then to release a new editheader, I suggest to allow UTF8 headers  
without generating an error (or leave it up to the implementation).

The same story with:
    4. Delete header

    If the field-name is not a valid 7-bit header field name ...
    [...]
    If an script uses the deleteheader action ...
    -> If a script uses the deleteheader action ...

In
    5 Interaction with Other Sieve Extensions

    shouldn|t it be canceLLed instead of canceLed? I am not an expert,  
but consider canceLLed is better.

   Със здраве,
     Дилян

Cc: [email-masked]
Date: Wed, 07 Mar 2007 10:56:58 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Interaction between "editheader" and "redirect"
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

> Folks,
> Philip recently posted draft-ietf-sieve-editheader-08.txt. Below is the
> summary of changes done to address interaction between "editheader" and
> "redirect". I would like to quickly confirm that the changes are fine
> with everyone.

> ==============
> Additional text in section 4 (Action deleteheader):

>    If an script uses the deleteheader action to remove "Received"
>    header fields and then performs a "redirect" action, the
>    implementation SHOULD NOT send the outgoing message with fewer
>    Received header fields than the original message.  If the
>    implementation does not permit that for the involved script, it
>    is implementation defined what Received header fields are present
>    in such an outgoing message.  The above overrides the requirement
>    on Received header fields in RFC-ietf-sieve-3028bis-12 section
>    4.2.

I see three ways to implement this:

(1) Don't allow editheader actions on Received: fields, period.
(2) Silently ignore any deletions made to Recieved: fields when redirect
    is used.
(3) Add in enough dummy Received: field to keep the count from going down.

I'm going with option (2), but I have to question whether we really want to
allow (3). It sure sounds like a bad idea to me.

> The following paragraph in section 5 (Interaction with Other Sieve
> Extensions):

>    All other actions that store or send the message MUST do so with
>    the current set of header fields.

> was replaced with:

>    With the exception of the special handling of "redirect" and
>    "Received" header fields described above, all other actions that
>    store or send the message MUST do so with the current set of
>    header fields.

What about actions that result in a DSN or MDN that returns content? I don't
think it is a good idea to use the modified message in such cases.

I can interpret "send" as including or excluding such operations so I think
this could be a bit clearer.

> Additional paragraph in section 7 (Security Considerations):

>    While this specification overrides the requirement that redirected
>    messages have more Received header fields than the message as
>    received, doing so removes an important mechanisms for detecting
>    loops and therefore should not be permitted by implementations
>    without due consideration, such as requiring administrative
>    action to enable it.

This looks fine to me.

				Ned

Date: Wed, 07 Mar 2007 10:12:49 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Interaction between "editheader" and "redirect"
Sender: [email-masked]

Folks,
Philip recently posted draft-ietf-sieve-editheader-08.txt. Below is the 
summary of changes done to address interaction between "editheader" and 
"redirect". I would like to quickly confirm that the changes are fine 
with everyone.

==============
Additional text in section 4 (Action deleteheader):

   If an script uses the deleteheader action to remove "Received"
   header fields and then performs a "redirect" action, the
   implementation SHOULD NOT send the outgoing message with fewer
   Received header fields than the original message.  If the
   implementation does not permit that for the involved script, it
   is implementation defined what Received header fields are present
   in such an outgoing message.  The above overrides the requirement
   on Received header fields in RFC-ietf-sieve-3028bis-12 section
   4.2.

The following paragraph in section 5 (Interaction with Other Sieve 
Extensions):

   All other actions that store or send the message MUST do so with
   the current set of header fields.

was replaced with:

   With the exception of the special handling of "redirect" and
   "Received" header fields described above, all other actions that
   store or send the message MUST do so with the current set of
   header fields.

Additional paragraph in section 7 (Security Considerations):

   While this specification overrides the requirement that redirected
   messages have more Received header fields than the message as
   received, doing so removes an important mechanisms for detecting
   loops and therefore should not be permitted by implementations
   without due consideration, such as requiring administrative
   action to enable it.

Cc: [email-masked]
Date: Wed, 07 Mar 2007 07:05:05 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: about draft-freed-sieve-date-index-04
To: Dilyan Palauzov <[email-masked]>
Sender: [email-masked]

> Hello,
> Some notes on date-index:

> *1. Introduction:
> *
> *   Some header fields containing date/time information, e.g.  Received:,
> *   naturally occur more than one in a single header.
> For me it sounds better "occur more than once"

> * 4. Date test:
> *
> *   Implementations MAY support extraction of date-time information
> *   that appears in other positions in the header field content.

> What shall a sieve interpreter do, if a header contains at two places
> a date - in the middle, and at the end?

AFAIK no such header has ever been defined, but hey, it avoids a tiny bit of
ambiguity so I have no problem with saying use the last value is the one to
use. After all, who knows what wierdness is floating around in a Received:
field somewhere?

> I would suggest, that implementations interpret always the last
> mentioned date in the header, or include means to access the not-last
> mentioned date.

> 4.2. Date-part argument,

> *     "minute"    => the current hour, "00" .. "59".
> shall be
>        "minute"    => the current minute, "00" .. "59".

Cut and paste error of course. Will be fixed in the next version.

				Ned

Cc: [email-masked]
Date: Wed, 07 Mar 2007 06:38:01 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: vacation 5.4 From:
To: Dilyan Palauzov <[email-masked]>
Sender: [email-masked]

> Hello,
> draft-ietf-sieve-vacation-07 sais:

This draft was approved as proposed standard many months back. It is now
much too late to consider such a change. Maybe in the next version.

> * 5.4. From
> *
> *   Unless explicitly overridden with a :from parameter, the From field
> *   SHOULD be set to the address of the owner of the Sieve script.

> I would suggest here another approach: the From is by default the
> (first) address, where the mail was sent. E.g. mails to
> [email-masked], [email-masked], and [email-masked] go all
> to the same mailbox, have the same sieve script (not on a duplica of
> the script, but opearate on the same script). However when one writes
> a mail To: you, her, CC: [email-masked], then the autoreply shall be
> Fron: [email-masked] (instead From: [email-masked]). In
> a similar way, when one writes To: him, them, CC: [email-masked], the
> autoreply shall come From: [email-masked], even if the same script is
> executed.

> I suggest we use in 5.4 From something like

> *   Unless explicitly overridden with a :from parameter, the From field
> *   SHOULD be set to the address of recipient's first mentioned address,
> *   whose Sieve script is executes.

> Moreover, it shall be stated, that the script is executed once per
> incoming mail and mailbox (if it is not clear from somewhereelse): if
> a mail is To: [email-masked], [email-masked] , then there shall be one
> autoreply generatated, not two (as this is the same mailbox). But I
> have no idea how the user will be informed about both addresses.

First of all, while it would be good to have some advice in there saying it
probably makes sense to use an address the recipient knows is yours, I don't
think this rises to anything close to a SHOULD. Site policy may mandate using
specific addresses in all replies, for example.

The concept of "first-mentioned" also seems a bit ill-defined (e.g,  does
resent-to come before or after to?) and actually somewhat wrongmineded. The
obvious address to use in replies is the envelope recipient address - as long
as it's the one that satisfied the header match criteria, and regardless of
what header field it matched or where it appeared in that field. If that's not
the address that matched something in the header things get a bit tricky.
Suppose the match was to one of the :addresses values. What then? This may be
the best address for the originator, but in forwarding situations there may be
authorization issues (think DKIM or SPF) with one site emitting mail with an
address belonging to some other forwarding site.

If memory serves, our implementation uses the envelope recipient address unless
overridden by a :from - we don't attempt anything tricky with using :addresses
values.

In any case, I don't have a problem with saying something along the lines of:

   Unless explicitly overridden with a :from parameter, the From field
   should be set to an address the person sending the original message
   is likely to recognize. One possibility is to use the orivinal message's
   envelope recipient address if it is available. If it is not available
   the recipient's address that satisfied the header matching criteria
   could be used, although caution should be exercised in using addresses
   specified in a :addresses construct that belong to other sites.

But as i say, too late for this version.

				Ned

Date: Wed, 07 Mar 2007 13:48:33 +0100
From: Dilyan Palauzov <[email-masked]>
To: [email-masked]
Subject: about draft-freed-sieve-date-index-04
Sender: [email-masked]

Hello,
Some notes on date-index:

*1. Introduction:
*
*   Some header fields containing date/time information, e.g.  Received:,
*   naturally occur more than one in a single header.
For me it sounds better "occur more than once"

* 4. Date test:
*
*   Implementations MAY support extraction of date-time information
*   that appears in other positions in the header field content.

What shall a sieve interpreter do, if a header contains at two places
a date - in the middle, and at the end?

I would suggest, that implementations interpret always the last
mentioned date in the header, or include means to access the not-last
mentioned date.

4.2. Date-part argument,

*     "minute"    => the current hour, "00" .. "59".
shall be
       "minute"    => the current minute, "00" .. "59".

    Greetings,
      Dilian

Date: Wed, 07 Mar 2007 13:47:42 +0100
From: Dilyan Palauzov <[email-masked]>
To: [email-masked]
Subject: vacation 5.4 From:
Sender: [email-masked]

Hello,
draft-ietf-sieve-vacation-07 sais:

* 5.4. From
*
*   Unless explicitly overridden with a :from parameter, the From field
*   SHOULD be set to the address of the owner of the Sieve script.

I would suggest here another approach: the From is by default the
(first) address, where the mail was sent. E.g. mails to
[email-masked], [email-masked], and [email-masked] go all
to the same mailbox, have the same sieve script (not on a duplica of
the script, but opearate on the same script). However when one writes
a mail To: you, her, CC: [email-masked], then the autoreply shall be
Fron: [email-masked] (instead From: [email-masked]). In
a similar way, when one writes To: him, them, CC: [email-masked], the
autoreply shall come From: [email-masked], even if the same script is
executed.

I suggest we use in 5.4 From something like

*   Unless explicitly overridden with a :from parameter, the From field
*   SHOULD be set to the address of recipient's first mentioned address,
*   whose Sieve script is executes.

Moreover, it shall be stated, that the script is executed once per
incoming mail and mailbox (if it is not clear from somewhereelse): if
a mail is To: [email-masked], [email-masked] , then there shall be one
autoreply generatated, not two (as this is the same mailbox). But I
have no idea how the user will be informed about both addresses.

    Greetings,
      Дилян

Cc: Ned Freed <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Date: Tue, 06 Mar 2007 15:39:03 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Informal Working Group Last Call on draft-freed-sieve-date-index-04.txt
To: Dave Cridland <[email-masked]>
Sender: [email-masked]

> > I'll consider adding some, but I'm more interested in getting this
> > done than in
> > adding examples at this point.

> I'll take that as a public call for useful examples, which'd also be
> a useful way of validating the draft.

Yes, that would be great.

> >> 5) Do you think anyone will figure out that, if using
> >> i;ascii-numeric, "2007-03-06" will be considered equal to
> >> "2007-01-01"? It might be a good idea to make a paragraph or two
> >> noting which comparators are suitable for which operations.
> >> (i;octet
> >> works for all of them, I think, except "julian", for which you need
> >> "i;ascii-numeric").
> >
> > How about you suggest some text for this?

> Not all comparators are suitable with all date-part arguments. In
> general, the date-parts can be compared and tested for equality with
> either "i;ascii-casemap" (the default) or "i;octet", but there are
> two exceptions:

> "julian" - The Modified Julian Day is an integer, and may or may not
> have leading zeros. As such, it needs to be used with
> "i;ascii-numeric".

> "std11" - This is case-insensitive, and therefore "i;ascii-casemap"
> needs to be used.

> "year", "month", "day", "date", "hour", "minute", "second" and
> "weekday" all use fixed-width string representations of integers, and
> can therefore be compared with "i;octet", "i;ascii-casemap", and
> "i;ascii-numeric" with equivalent results.

> (And yes, avoiding any RFC2119 language there was intentional -
> script authors *can* compare iso8601 values using "i;ascii-numeric"
> if they want.)

Nice. I've added it more or less verbatim. Thanks!

				Ned

Subject: Re: Informal Working Group Last Call on draft-freed-sieve-date-index-04.txt
Date: Tue, 06 Mar 2007 22:02:21 +0000
From: Dave Cridland <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On Tue Mar  6 18:19:09 2007, Ned Freed wrote:
>> On Tue Mar  6 12:58:48 2007, Alexey Melnikov wrote:
>> >
>> > We would like to draw your attention to the following draft:
>> >
>> > 
>> <http://www.ietf.org/internet-drafts/draft-freed-sieve-date-index-04.txt>
> 
>> Some comments based on a fairly rapid first-time read-through from 
>> a
>> script author's perspective:
> 
>> 1) In the abstract, concerning index, I note it refers to "specific
>> instances of header fields" - but it's presumably also capable of
>> limiting to specific addresses.
> 
> No, that's not the intent at all. :index counts multiple occurances 
> of header
> fields, not whatever is in those fields.
> 
> Of course you could define a parameter that selects a particular 
> address out of
> an address list for testing, but :index isn't it. I also have to 
> say that I see
> no reason to have such a capability, whereas the abiltiy to specify 
> the header
> field you're testing is clearly useful even for address tests 
> (again, think
> about possible situations involving multiple blocks of resent- 
> fields in the
> header).
> 
> 
Right - I was beginning to think so from Arnt's comment about 
Resent-*.

I think there's lots of utility in being able to run several tests on 
a particular address in a header field, too, but if that's not what 
this specification is trying to do, that's fine. I just read 
"address" and ":index", and thought it probably was.

>> 2) Section 4 uses the phrase "[...] as modified by the comparator 
>> and
>> match keywords." - this doesn't ring true with my understanding of
>> comparators, perhaps a better way of phrasing this would be, "[...]
>> according to the comparator and match keywords.".
> 
> I agree the wording isn't great, but I also think according is 
> actually worse
> wording than what's there now. How about "as controlled by"?
> 
> 
Yes, much better.

>> 3) Section 4 implies that it only operates on structured header
>> fields. I suspect it might be useful to allow it to be used on an
>> unstructured header field that happens to contain a string which
>> forms a date. The last paragraph appears to imply that, but the use
>> of the phrase "structured headers" contradicts.
> 
> Such a field is then by definition not unstructured. I don't see 
> much point in
> calling this out, but there's also little point in referring to 
> this test
> operating on structured fields. I'll simply remove the word 
> "structured" from
> the sentence.
> 
> 
I have to admit I read "structured" as implying one formally defined 
to hold a date somewhere. Whereas I'd expect that, in principle, 
"X-Foo-Date: ..." wouldn't be structured per se. Removal of 
"structured" would confuse me less.

>> 4) The draft utterly lacks any examples. How can I possibly 
>> implement
>> it unless I have badly written examples to perpetuate errors from? 
>> ;-)
> 
> I'll consider adding some, but I'm more interested in getting this 
> done than in
> adding examples at this point.
> 
> 
I'll take that as a public call for useful examples, which'd also be 
a useful way of validating the draft.

>> 5) Do you think anyone will figure out that, if using
>> i;ascii-numeric, "2007-03-06" will be considered equal to
>> "2007-01-01"? It might be a good idea to make a paragraph or two
>> noting which comparators are suitable for which operations. 
>> (i;octet
>> works for all of them, I think, except "julian", for which you need
>> "i;ascii-numeric").
> 
> How about you suggest some text for this?

Not all comparators are suitable with all date-part arguments. In 
general, the date-parts can be compared and tested for equality with 
either "i;ascii-casemap" (the default) or "i;octet", but there are 
two exceptions:

"julian" - The Modified Julian Day is an integer, and may or may not 
have leading zeros. As such, it needs to be used with 
"i;ascii-numeric".

"std11" - This is case-insensitive, and therefore "i;ascii-casemap" 
needs to be used.

"year", "month", "day", "date", "hour", "minute", "second" and 
"weekday" all use fixed-width string representations of integers, and 
can therefore be compared with "i;octet", "i;ascii-casemap", and 
"i;ascii-numeric" with equivalent results.

(And yes, avoiding any RFC2119 language there was intentional - 
script authors *can* compare iso8601 values using "i;ascii-numeric" 
if they want.)

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Cc: Alexey Melnikov <[email-masked]>, Ned Freed <[email-masked]>, [email-masked]
Date: Tue, 06 Mar 2007 10:19:09 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Informal Working Group Last Call on draft-freed-sieve-date-index-04.txt
To: Dave Cridland <[email-masked]>
Sender: [email-masked]

> On Tue Mar  6 12:58:48 2007, Alexey Melnikov wrote:
> >
> > We would like to draw your attention to the following draft:
> >
> > <http://www.ietf.org/internet-drafts/draft-freed-sieve-date-index-04.txt>

> Some comments based on a fairly rapid first-time read-through from a
> script author's perspective:

> 1) In the abstract, concerning index, I note it refers to "specific
> instances of header fields" - but it's presumably also capable of
> limiting to specific addresses.

No, that's not the intent at all. :index counts multiple occurances of header
fields, not whatever is in those fields.

Of course you could define a parameter that selects a particular address out of
an address list for testing, but :index isn't it. I also have to say that I see
no reason to have such a capability, whereas the abiltiy to specify the header
field you're testing is clearly useful even for address tests (again, think
about possible situations involving multiple blocks of resent- fields in the
header).

> Similarly, section 6 also implies that the address test operates on a
> header field rather than on an address, which seems odd. I believe
> that the address header fields - To, CC, BCC - are only allowed once
> in a message header.

Um, not exactly. While it is true that RFC 2822 says you should only have one
of each of these fields, there are plenty of other standard fields that can
contain addresses, such as resent-to, that can appear multiple times. (And this
doesn't even consider nonstandard fields containing addresses.) I will also
point out that just because RFC 2822 says this doesn't mean the rule isn't
violated routinely (RFC 822 contains no such prohibition, BTW), and sieve needs
to be able to process the stuff people actually do, not just what the standards
say is OK to do.

> I'd expect:
> 	address :index 2 :domain ["to"] ["mrocheck.com"]

> to match for this message, for example.

Again, that's not the intent. I'll add a paragraph that makes this clear.

> 2) Section 4 uses the phrase "[...] as modified by the comparator and
> match keywords." - this doesn't ring true with my understanding of
> comparators, perhaps a better way of phrasing this would be, "[...]
> according to the comparator and match keywords.".

I agree the wording isn't great, but I also think according is actually worse
wording than what's there now. How about "as controlled by"?

> 3) Section 4 implies that it only operates on structured header
> fields. I suspect it might be useful to allow it to be used on an
> unstructured header field that happens to contain a string which
> forms a date. The last paragraph appears to imply that, but the use
> of the phrase "structured headers" contradicts.

Such a field is then by definition not unstructured. I don't see much point in
calling this out, but there's also little point in referring to this test
operating on structured fields. I'll simply remove the word "structured" from
the sentence.

> 4) The draft utterly lacks any examples. How can I possibly implement
> it unless I have badly written examples to perpetuate errors from? ;-)

I'll consider adding some, but I'm more interested in getting this done than in
adding examples at this point.

> 5) Do you think anyone will figure out that, if using
> i;ascii-numeric, "2007-03-06" will be considered equal to
> "2007-01-01"? It might be a good idea to make a paragraph or two
> noting which comparators are suitable for which operations. (i;octet
> works for all of them, I think, except "julian", for which you need
> "i;ascii-numeric").

How about you suggest some text for this?

				Ned

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-editheader-08.txt 
Date: Tue, 06 Mar 2007 15:50:02 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Email Filtering: Editheader Extension
	Author(s)	: P. Guenther, J. Degener
	Filename	: draft-ietf-sieve-editheader-08.txt
	Pages		: 10
	Date		: 2007-3-6
	
This document defines two new actions for the "Sieve" email
   filtering language that add and delete email header fields.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-editheader-08.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-sieve-editheader-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-editheader-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-editheader-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-editheader-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-notify-xmpp-04.txt 
Date: Tue, 06 Mar 2007 15:50:02 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Notification Mechanism: xmpp
	Author(s)	: P. Saint-Andre, A. Melnikov
	Filename	: draft-ietf-sieve-notify-xmpp-04.txt
	Pages		: 9
	Date		: 2007-3-6
	
This document describes a profile of the Sieve extension for
   notifications, to allow notifications to be sent over the Extensible
   Messaging and Presence Protocol (XMPP), also known as Jabber.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-xmpp-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-sieve-notify-xmpp-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-notify-xmpp-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-notify-xmpp-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-notify-xmpp-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 6 Mar 2007 15:16:40 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Informal Working Group Last Call on draft-freed-sieve-date-index-04.txt
Cc: Alexey Melnikov <[email-masked]>, Ned Freed <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Dave Cridland writes:
> Similarly, section 6 also implies that the address test operates on a 
> header field rather than on an address, which seems odd. I believe 
> that the address header fields - To, CC, BCC - are only allowed once 
> in a message header.

Resent-To and its friends may occur any number of times. (Its friends 
are not my friends.)

Arnt

Subject: Re: Informal Working Group Last Call on draft-freed-sieve-date-index-04.txt
Date: Tue, 06 Mar 2007 13:58:43 +0000
From: Dave Cridland <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Ned Freed <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Tue Mar  6 12:58:48 2007, Alexey Melnikov wrote:
> 
> We would like to draw your attention to the following draft:
> 
> <http://www.ietf.org/internet-drafts/draft-freed-sieve-date-index-04.txt>

Some comments based on a fairly rapid first-time read-through from a 
script author's perspective:

1) In the abstract, concerning index, I note it refers to "specific 
instances of header fields" - but it's presumably also capable of 
limiting to specific addresses.

Similarly, section 6 also implies that the address test operates on a 
header field rather than on an address, which seems odd. I believe 
that the address header fields - To, CC, BCC - are only allowed once 
in a message header.

I'd expect:
	address :index 2 :domain ["to"] ["mrocheck.com"]

to match for this message, for example.

2) Section 4 uses the phrase "[...] as modified by the comparator and 
match keywords." - this doesn't ring true with my understanding of 
comparators, perhaps a better way of phrasing this would be, "[...] 
according to the comparator and match keywords.".

3) Section 4 implies that it only operates on structured header 
fields. I suspect it might be useful to allow it to be used on an 
unstructured header field that happens to contain a string which 
forms a date. The last paragraph appears to imply that, but the use 
of the phrase "structured headers" contradicts.

4) The draft utterly lacks any examples. How can I possibly implement 
it unless I have badly written examples to perpetuate errors from? ;-)

5) Do you think anyone will figure out that, if using 
i;ascii-numeric, "2007-03-06" will be considered equal to 
"2007-01-01"? It might be a good idea to make a paragraph or two 
noting which comparators are suitable for which operations. (i;octet 
works for all of them, I think, except "julian", for which you need 
"i;ascii-numeric").

Feel free to correct my comments if I've merely missed things on a 
read-through.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Date: Tue, 06 Mar 2007 12:58:48 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Informal Working Group Last Call on draft-freed-sieve-date-index-04.txt
Sender: [email-masked]

We would like to draw your attention to the following draft:

<http://www.ietf.org/internet-drafts/draft-freed-sieve-date-index-04.txt>

A three week informal last call of this document starts today on March 
6th 2007 and ends on March 27th 2007 at 6 pm EST.

Please review this document and send issues to the list or directly to 
the author. In the latter case please CC both WG chairs, so that we can 
track issues.

NB If you do review this document, but have no issues or comments, 
please send both co-chairs (or the list) an email to indicate you have 
looked at it. This will allow the chairs to gauge the scope of reviews 
of this document to aid in our determination on whether to send it to 
the IESG. Thanks.

--
Cyrus Daboo and Alexey Melnikov
SIEVE WG chairs

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-vacation-07.txt 
Date: Mon, 05 Mar 2007 15:50:03 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Email Filtering:  Vacation Extension
	Author(s)	: T. Showalter, N. Freed
	Filename	: draft-ietf-sieve-vacation-07.txt
	Pages		: 16
	Date		: 2007-3-5
	
This document describes an extension to the Sieve email filtering
   language for an autoresponder similar to that of the Unix "vacation"
   command for replying to messages.  Various safety features are
   included to prevent problems such as message loops.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-vacation-07.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-sieve-vacation-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-vacation-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-vacation-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-vacation-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 05 Mar 2007 12:04:10 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: WGLC ended for: draft-ietf-sieve-notify-07.txt
Sender: [email-masked]

Alexey Melnikov wrote:

> Barry and I recently submitted -07. We believe this version addresses 
> all issues brought up during WGLC.
>
> I would like to issue an additional 1 week WGLC on this version of the 
> document.
>
> In particular, I would like to bring people's attention to the 
> following 3 changes:
>
> 1). New notify_method_capability test.
>
> 2). One major editorial change is the removal of extract_text test, as 
> per WG discussion. The replacement test or action is more likely to 
> move to the MIME loops document, but this decision is not final.
>
> 3). Regarding describing interaction of the notify action parameters 
> with URI parameters in the method parameter: Looking through comments 
> received during WGLC, I found no single agreeable solution. Pretty 
> much everybody wanted different behavior. So sieve-notify was updated 
> to list available choices, but not prescribe any specific behavior, 
> which is left up to specifications describing notification methods. 
> Once the new Sieve notify is deployed and we get some implementation 
> experience with different notification methods, some consensus might 
> emerge. At which point sieve-notify-bis can prescribe a specific behavior.

Nobody has commented on the updated -07, so I (as an editor) assume that 
it is good to be submitted to IESG. As such I will recommend Cyrus to 
send it to IESG shortly.

Cc: Ned Freed <[email-masked]>, [email-masked]
Date: Sat, 03 Mar 2007 14:51:35 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: environment / Re: Revised drafts posted
To: Dilyan Palauzov <[email-masked]>
Sender: [email-masked]

>    Hallo,

>    I have a small question for the environment test: wouldn't it be
> simpler to immitate the behaviour with variables:

>    If the users want to check for envirnoment property, they include a
> well-known file (e.g. system), which imports the relevant information,
> which is the same the current environment, and then the sieve-scripts
> use it as they want.

Short answer: No.

Longer answer: You're talking about at a minumum supporting some kind of
include mechanism, not to mention the variables extension itself. Include
processing is quite complex and difficult to get right; we have to even agree
on a model for it, and even if we do manage to do that eventually there are
likely to be a variety of naming issues that will make portability an issue.

The main point of environment is to be able to write more portable scripts.
Conflating such checks with an extnesion that by its nature is likely to have
portability issues is a seriously losing proposition.

And as a purely operational matter, even if we implement an include mechanism
(can't say for sure if we would or not - it will depend on the semantics), our
customers are unlikely to enable it given their preference for standalone
scripts stored in LDAP. (This is not my personal preference at all , BTW - I
actually dislike this use of LDAP.)

>    The advantage of this simpler approach would be, that the
> implementations need not be changed, script-generating utilities
> neither, and the sieve language is in fact not extended, but is more
> powerful.

>    Opinions?

I think doing this with variables and includes is actually quite a bit more
complex and almost certainlyt less portable.

				Ned

Date: Sat, 03 Mar 2007 23:33:58 +0100
From: Dilyan Palauzov <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: [email-masked]
Subject: environment / Re: Revised drafts posted
Sender: [email-masked]

   Hallo,

   I have a small question for the environment test: wouldn't it be  
simpler to immitate the behaviour with variables:

   If the users want to check for envirnoment property, they include a  
well-known file (e.g. system), which imports the relevant information,  
which is the same the current environment, and then the sieve-scripts  
use it as they want.

   The advantage of this simpler approach would be, that the  
implementations need not be changed, script-generating utilities  
neither, and the sieve language is in fact not extended, but is more  
powerful.

   Opinions?
   Greetings,
     Дилян

----- Message from [email-masked] ---------
     Date: Sat, 03 Mar 2007 12:47:39 -0800 (PST)
     From: Ned Freed <[email-masked]>
Reply-To: Ned Freed <[email-masked]>
  Subject: Revised drafts posted
       To: [email-masked]

>
> I have revised the vacation, date, environment, and ihave drafts. They
> are available here:
>
>  ftp://mail.apps.ietf.org/sievedate.{txt,html,xml}
>  ftp://mail.apps.ietf.org/sieveenvironment.{txt,html,xml}
>  ftp://mail.apps.ietf.org/sieveihave.{txt,html,xml}
>  ftp://mail.apps.ietf.org/sievevacation.{txt,html,xml}
>
> IMO the sieve date draft is ready for last call.
>
> I split environment and ihave into separate documents so they can   
> proceed with
> different statuses should the need arise. I also added a new notify extension
> to the environment document - it does the obvious with SMTP NOTIFY
> parameters.
>
> Vacation is a done deal but I wanted to update the references and the IANA
> registration template.
>
> I submitted the revisions of date and vacation to the drafts repository.
> Splitting environment and ihave reset them to -00 so they cannot be submitted
> right now. I will do so once the gate for new drafts reopens.
>
> 				Ned

----- End message from [email-masked] -----

Date: Sat, 03 Mar 2007 12:47:39 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Revised drafts posted
To: [email-masked]
Sender: [email-masked]

I have revised the vacation, date, environment, and ihave drafts. They
are available here:

  ftp://mail.apps.ietf.org/sievedate.{txt,html,xml}
  ftp://mail.apps.ietf.org/sieveenvironment.{txt,html,xml}
  ftp://mail.apps.ietf.org/sieveihave.{txt,html,xml}
  ftp://mail.apps.ietf.org/sievevacation.{txt,html,xml}

IMO the sieve date draft is ready for last call.

I split environment and ihave into separate documents so they can proceed with
different statuses should the need arise. I also added a new notify extension
to the environment document - it does the obvious with SMTP NOTIFY  parameters.

Vacation is a done deal but I wanted to update the references and the IANA
registration template.

I submitted the revisions of date and vacation to the drafts repository.
Splitting environment and ihave reset them to -00 so they cannot be submitted
right now. I will do so once the gate for new drafts reopens.

				Ned

Date: Fri, 02 Mar 2007 15:59:59 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: Request for agenda items for the Sieve WG meeting in Prague
Sender: [email-masked]

Alexey Melnikov wrote:

> Please send your requests directly to me or just reply to this message.
>
> Also, I would like to ask people to let me know who is planning to 
> come to the Sieve WG meeting in Prague. (Ignore this, if you've 
> already told me).

As nobody has sent me any proposals, here is my suggestion:

Document status review (5 min)
Sieve Notify WGLC issues (15 min)
Sieve Notify Mailto issues  (30 min)
Sieve MIME Loops (30 min)
Other documents:
- Mailbox metadata access (20 min)
- Externally stored lists* (10 min)
- Environment, date-time, ... (10 min)

* - I have not submitted this one yet, but I can describe the proposal I
was discussing with Alexandros Vellis.

If there is any spare time left at the end of the meeting we can also 
talk about draft-gulbrandsen-collation-basic-XX.txt. Even though it is 
not a WG document, the  Sieve WG is probably the best place to discuss it.