NED+mta-filters | 1 Feb 04:54

Re: Sieve include: interactions with MIME loops

> Posting this now.

Looks good to me.

				Ned

> On Mon, Jan 23, 2012 at 5:00 PM, Ned Freed <ned.freed <at> mrochek.com> wrote:
> >> 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
(Continue reading)

Cyrus Daboo | 16 Feb 20:29

notify-sip-message and convert actions

Hi folks,
Regarding the recent IETF last calls on the notify-sip-message and convert 
drafts in relation to the late IPR disclosures. The WG chairs have 
determined to proceed as follows based on feedback from the last call and 
discussions with the AD. This decision was reached on the basis of a 
process violation by one of the document editors of the documents, by 
failing to disclose IPR as required by BCP 79 (RFC 3979), and as per RFC 
2418 Section 6.1, the WG Chairs have the authority to take appropriate 
action.

We will request the RFC Editor to move ahead with publication of these two 
drafts. However, we have decided that Qian Sun will no longer be a document 
editor for those two drafts and we will have the RFC Editor remove his name 
from the author/editor list at the top of the documents and the Authors' 
Addresses sections at the end. We will require them to add Qian Sun to the 
Acknowledgements section of both drafts to identify that he did contribute 
text to the drafts.

If anyone objects to this course of action please reply.

AD Pete Resnick will communicate this decision to the IETF as whole, and 
then we will proceed with the instructions to the RFC Editor.

--

-- 
Cyrus Daboo

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

rfc-editor | 29 Feb 19:58
Favicon

RFC 6468 on Sieve Notification Mechanism: SIP MESSAGE


A new Request for Comments is now available in online RFC libraries.

        
        RFC 6468

        Title:      Sieve Notification Mechanism: SIP MESSAGE 
        Author:     A. Melnikov, B. Leiba, K. Li
        Status:     Standards Track
        Stream:     IETF
        Date:       February 2012
        Mailbox:    Alexey.Melnikov <at> isode.com, 
                    barryleiba <at> computer.org, 
                    likepeng <at> huawei.com
        Pages:      10
        Characters: 21331
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-sieve-notify-sip-message-08.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6468.txt

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

This document is a product of the Sieve Mail Filtering Language Working Group of the IETF.

This is now a Proposed Standard Protocol.

(Continue reading)


Gmane