headers
Aaron Stone | 5 Jan 2012 15:32
Gravatar

Re: [Gen-art] Gen-ART Last Call Review of draft-ietf-sieve-include-13

On Mon, Dec 19, 2011 at 12:46 PM, Ben Campbell <ben <at> nostrum.com> wrote:
> Thanks for the response! Further comments inline, with sections that appear
> to need no further comment removed:
>
> On Dec 19, 2011, at 1:13 PM, Aaron Stone wrote:
>
>
>
> On Tue, Dec 13, 2011 at 2:13 PM, Ben Campbell <ben <at> nostrum.com> wrote:
>>
>>
>
> […]
>
>> Minor issues:
>>
>> -- section 3.1, paragraph 4: "Implementations MUST NOT generate errors for
>> recursive inclusions at upload time, as this would force an upload ordering
>> requirement upon script authors / generators.  However, if an active script
>> is replaced with a faulty script and would remain the active script, an
>> error MUST be generated and the upload MUST fail."
>>
>> These two statements seem contradictory on a quick reading.  In
>> particular, how can the latter assertion avoid an upload ordering
>> requirement? Or do you mean faulty in some way other than being recursive?
>
>
> If you're replacing an active script, it has to be correct all the time, and
> uploads are atomic only on a per-script basis. There's a risk that if you're
> uploading a set of scripts that include one another, at some intermediate
(Continue reading)

Permalink | Reply | 2 comments |
headers
internet-drafts | 5 Jan 2012 16:01
Picon
Favicon

I-D Action: draft-ietf-sieve-include-14.txt


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: Include Extension
	Author(s)       : Cyrus Daboo
                          Aaron Stone
	Filename        : draft-ietf-sieve-include-14.txt
	Pages           : 16
	Date            : 2012-01-05

   The Sieve Email Filtering "include" extension permits users to
   include one Sieve script inside another.  This can make managing
   large scripts or multiple sets of scripts much easier, and allows a
   site and its users to build up libraries of scripts.  Users are able
   to include their own personal scripts or site-wide scripts.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-sieve-include-14.txt

_______________________________________________
sieve mailing list
sieve <at> ietf.org
https://www.ietf.org/mailman/listinfo/sieve
(Continue reading)

Permalink | Reply | 0 comments |
headers
RFC Errata System | 5 Jan 2012 16:14
Favicon

[Editorial Errata Reported] RFC5233 (3079)


The following errata report has been submitted for RFC5233,
"Sieve Email Filtering: Subaddress Extension".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5233&eid=3079

--------------------------------------
Type: Editorial
Reported by: Aaron Stone <aaron <at> serendipity.cx>

Section: 4

Original Text
-------------
   A diagram showing the ADDRESS-PARTs of an email address where the
   detail information follows a separator character sequence of "+" is
   shown below:

          :user "+" :detail  " <at> " :domain
         \-----------------/
             :local-part

   A diagram showing the ADDRESS-PARTs of a email address where the
   detail information precedes a separator character sequence of "--" is
   shown below:

          :detail "--" :user  " <at> " :domain
         \------------------/
(Continue reading)

Permalink | Reply | 2 comments |
headers
NED+mta-filters | 5 Jan 2012 19:06

Re: [Editorial Errata Reported] RFC5233 (3079)

The correction seems fine, but as long as you're correcting this section
might as well change the "a email address" to "an email address" in the second
paragraph.

				Ned

> The following errata report has been submitted for RFC5233,
> "Sieve Email Filtering: Subaddress Extension".

> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5233&eid=3079

> --------------------------------------
> Type: Editorial
> Reported by: Aaron Stone <aaron <at> serendipity.cx>

> Section: 4

> Original Text
> -------------
>    A diagram showing the ADDRESS-PARTs of an email address where the
>    detail information follows a separator character sequence of "+" is
>    shown below:

>           :user "+" :detail  " <at> " :domain
>          \-----------------/
>              :local-part

>    A diagram showing the ADDRESS-PARTs of a email address where the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Aaron Stone | 5 Jan 2012 19:21
Gravatar

Re: [Editorial Errata Reported] RFC5233 (3079)

Just happened to read back on the rejected erratum, and realized that
he'd caught the right error in the wrong place (local-part vs.
:localpart). Theoretically, :local-part is a technical error, but I
marked it editorial because it's in an example rather than a normative
section.

I could add the typo, but that's way on the editorial side :)

Cheers,
Aaron

On Thu, Jan 5, 2012 at 10:06 AM, Ned Freed <ned.freed <at> mrochek.com> wrote:
> The correction seems fine, but as long as you're correcting this section
> might as well change the "a email address" to "an email address" in the second
> paragraph.
>
>                                Ned
>
>> The following errata report has been submitted for RFC5233,
>> "Sieve Email Filtering: Subaddress Extension".
>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=5233&eid=3079
>
>> --------------------------------------
>> Type: Editorial
>> Reported by: Aaron Stone <aaron <at> serendipity.cx>
>
>> Section: 4
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 21 Jan 2012 14:31
Favicon

Sieve include: interactions with MIME loops

I am looking at the new text in draft-ietf-sieve-include-14.txt:

3.5.  Interaction with Other Extensions

         When "include" is used with the Editheader extension [RFC5293], 
any
         changes made to headers in a script MUST be propagated both to and
         from included scripts.  By way of example, if a script deletes one
         header and add another, then includes a second script, the 
included
         script MUST NOT see the removed header, and MUST see the added
         header.  Likewise, if the included script adds or removes a 
header,
         upon returning to the including script, subsequent actions MUST 
see
         the added headers and MUST NOT see the removed headers.

         When "include" is used with the MIME extension [RFC5703]
         "foreverypart" control structure, the included script MUST be
         presented with the current MIME part as though it were the entire
         message.  A script SHALL NOT have any special control over the
         control structure it was included from.  In the MIME example once
         again, a "stop" or "return" in an included script cannot directly
         terminate or continue flow of a "foreverypart" block.  In such a
         case, the included script should set a global variable that the
         including script can test.

This makes me think that it is not clear what effect the "reject" action 
would have if called in an included script within a "foreverypart" 
block. What does it mean to "reject" a particular body part of a message?
(Continue reading)

Permalink | Reply | 7 comments |
headers
Aaron Stone | 24 Jan 2012 01:25
Gravatar

Re: Sieve include: interactions with MIME loops

On Sat, Jan 21, 2012 at 5:31 AM, Alexey Melnikov
<alexey.melnikov <at> isode.com> wrote:
> I am looking at the new text in draft-ietf-sieve-include-14.txt:
>
> 3.5.  Interaction with Other Extensions
>
>        When "include" is used with the Editheader extension [RFC5293], any
>        changes made to headers in a script MUST be propagated both to and
>        from included scripts.  By way of example, if a script deletes one
>        header and add another, then includes a second script, the included
>        script MUST NOT see the removed header, and MUST see the added
>        header.  Likewise, if the included script adds or removes a header,
>        upon returning to the including script, subsequent actions MUST see
>        the added headers and MUST NOT see the removed headers.
>
>        When "include" is used with the MIME extension [RFC5703]
>        "foreverypart" control structure, the included script MUST be
>        presented with the current MIME part as though it were the entire
>        message.  A script SHALL NOT have any special control over the
>        control structure it was included from.  In the MIME example once
>        again, a "stop" or "return" in an included script cannot directly
>        terminate or continue flow of a "foreverypart" block.  In such a
>        case, the included script should set a global variable that the
>        including script can test.
>
> This makes me think that it is not clear what effect the "reject" action
> would have if called in an included script within a "foreverypart" block.
> What does it mean to "reject" a particular body part of a message?

I think it should immediately halt the script chain and reject the
(Continue reading)

Permalink | Reply | 6 comments |
headers
NED+mta-filters | 24 Jan 2012 02:00

Re: Sieve include: interactions with MIME loops

> On Sat, Jan 21, 2012 at 5:31 AM, Alexey Melnikov
> <alexey.melnikov <at> isode.com> wrote:
> > I am looking at the new text in draft-ietf-sieve-include-14.txt:
> >
> > 3.5.  Interaction with Other Extensions
> >
> >        When "include" is used with the Editheader extension [RFC5293], any
> >        changes made to headers in a script MUST be propagated both to and
> >        from included scripts.  By way of example, if a script deletes one
> >        header and add another, then includes a second script, the included
> >        script MUST NOT see the removed header, and MUST see the added
> >        header.  Likewise, if the included script adds or removes a header,
> >        upon returning to the including script, subsequent actions MUST see
> >        the added headers and MUST NOT see the removed headers.
> >
> >        When "include" is used with the MIME extension [RFC5703]
> >        "foreverypart" control structure, the included script MUST be
> >        presented with the current MIME part as though it were the entire
> >        message.  A script SHALL NOT have any special control over the
> >        control structure it was included from.  In the MIME example once
> >        again, a "stop" or "return" in an included script cannot directly
> >        terminate or continue flow of a "foreverypart" block.  In such a
> >        case, the included script should set a global variable that the
> >        including script can test.
> >
> > This makes me think that it is not clear what effect the "reject" action
> > would have if called in an included script within a "foreverypart" block.
> > What does it mean to "reject" a particular body part of a message?

> I think it should immediately halt the script chain and reject the
(Continue reading)

Permalink | Reply | 5 comments |
headers
The IESG | 25 Jan 2012 21:17
Picon
Favicon

Second Last Call: <draft-ietf-sieve-notify-sip-message-08.txt> (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard


The IESG has received a request from the Sieve Mail Filtering Language WG
(sieve) to consider the following document:
- 'Sieve Notification Mechanism: SIP MESSAGE'
  <draft-ietf-sieve-notify-sip-message-08.txt> as a Proposed Standard

Last calls were earlier issued on version -05 of this document and this
document was approved by the IESG on 2011-10-06. Subsequently,
an IPR disclosure statement for this draft was submitted.
This Second Last Call is intended to determine whether the community
is still comfortable with publication of this document in light of the IPR statement.
The relevant IPR statement is available at:

https://datatracker.ietf.org/ipr/1658/

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2012-02-08. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document describes a profile of the Sieve extension for
   notifications, to allow notifications to be sent over SIP MESSAGE.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/

IESG discussion can be tracked via
(Continue reading)

Permalink | Reply | 57 comments |
headers
The IESG | 25 Jan 2012 21:19
Picon
Favicon

Second Last Call: <draft-ietf-sieve-convert-06.txt> (Sieve Extension for Converting Messages Before Delivery) to Proposed Standard


The IESG has received a request from the Sieve Mail Filtering Language WG
(sieve) to consider the following document:
- 'Sieve Extension for Converting Messages Before Delivery'
  <draft-ietf-sieve-convert-06.txt> as a Proposed Standard

Last calls were earlier issued on version -05 of this document and this
document was approved by the IESG on 2011-12-01. Subsequently,
an IPR disclosure statement for this draft was submitted.
This Second Last Call is intended to determine whether the community
is still comfortable with publication of this document in light of the IPR statement.
The relevant IPR statement is available at:

https://datatracker.ietf.org/ipr/1657/

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2012-02-08. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document describes how the "CONVERT" IMAP extension can be used
   within the Sieve mail filtering language to transform messages before
   final delivery.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-sieve-convert/
(Continue reading)

Permalink | Reply | 0 comments |

Gmane