http://blog.gmane.org/gmane.ietf.mta-filters hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.mta-filters/5210 <pre>Hi Barry, On 14/03/2012 15:50, Barry Leiba wrote: [...] I think Stephan's issues were addressed. I think you already did (by making support for ManageSieve a MUST). I think you should update the definition of the "imapsieve" IMAP capability to be "imapsieve=&lt;sieveurl-server&gt;", where sieveurl-server is defined in Section 3 of RFC 5804. Also update IMAP examples accordingly. Is this still needed? And did you mean IMAP Sieve script activation for a mailbox? Some suggestions for the first issue are above. I need a bit more information on the second issue. Also here are some other related changes: 2.3.1. Interaction with Metadata This specifies the mechanism for "activating" a script for a given mailbox (or for all mailboxes), but does not specify a mechanism for creating, storing, or validating the script. Implementations MUST support ManageSieve [RFC5804], and can use the PUTSCRIPT command to store the script without using the SETACTIVE command to activate it. In any case, the script name that is specified in the /IMAPSieve/ Script metadata entry is in a form that depends upon how the server handles the storing of Sieve scripts. Script names used here MUST match script names used by METADATA. I do find the last 2 sentences confusing. How about this instead: Script names used in "/IMAPSieve/Script" metadata entries are the script names used on the corresponding ManageSieve server. If a "/IMAPSieve/Script" metadata entry contains a script name that doesn't exist in the ManageSieve server, then no Sieve script will be invoked for IMAP Sieve events. _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> Alexey Melnikov 2012-03-20T11:11:08 http://permalink.gmane.org/gmane.ietf.mta-filters/5209 <pre>Ping... Still soliciting final reviews. Ned 'em. Last document, here -- let's finish it up! Also: we have a suggestion that the target status of this document be changed from Standards Track to Experimental. I support that change, as do the chairs. Comments from other reviewers on this are &lt;strike&gt;welcome&lt;/strike&gt; encouraged. Barry On Tue, Mar 6, 2012 at 12:15 PM, Barry Leiba &lt;barryleiba&lt; at &gt;computer.org&gt; wrote: _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> Barry Leiba 2012-03-14T15:50:40 http://permalink.gmane.org/gmane.ietf.mta-filters/5207 <pre> This is nearly it! We're down to one final document now, draft-ietf-sieve-imap-sieve Let's get that finished up and wrap things up! Barry _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> Barry Leiba 2012-03-07T23:25:04 http://permalink.gmane.org/gmane.ietf.mta-filters/5206 <pre>The IESG has approved the following document: - 'Sieve Email Filtering: Include Extension' (draft-ietf-sieve-include-15.txt) as a Proposed Standard This document is the product of the Sieve Mail Filtering Language Working Group. The IESG contact persons are Pete Resnick and Peter Saint-Andre. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sieve-include/ Technical Summary 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. Working Group Summary This was a popular extension within the working group. It was under active development for about a year and a half, during which time a number of suggestions were discussed, and issues were ironed out. It then went dormant for a year because the editors (also the two chairs) were very busy, and the working group as a whole was very quiet. Once revived, it was finished up with final editing. There are no controversies at this point, and there were no major controversies during the document's development. Document Quality The issues that were worked out during document development were mostly dealing with how to specify the included scripts, how multiple included scripts interact, and how to resolve conflicts among the different scripts. The working group expects that this isn't the final version, and that it will be updated after more experience in practical use -- that is, what's here is appropriate for Proposed Standard. There are at least two implementations of draft versions, and at least two other implementors plan to implement the final version. Personnel Barry Leiba &lt;barryleiba&lt; at &gt;computer.org&gt; is the Document Shepherd. Pete Resnick &lt;presnick&lt; at &gt;qualcomm.com&gt; is the Responsible AD. RFC Editor Note Section 3.5, end of second paragraph (typo "foreverpart"): OLD A "stop" in an included script, even within a "foreverpart" loop, still halts all script execution NEW A "stop" in an included script, even within a "foreverypart" loop, still halts all script execution _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> The IESG 2012-03-07T04:14:01 http://permalink.gmane.org/gmane.ietf.mta-filters/5205 <pre>... And another is: http://tools.ietf.org/html/draft-ietf-sieve-imap-sieve (Hi, Alexey!) This version should be close to ready: I've incorporated all comments so far except what I note below, and thanks to Stephan for his last review (quite some time ago now; sorry), which resulted in some significant improvements. (I do have two minor updates in my working copy, one of which replaces the obsolete reference to RFC 4409 with 6409.) I have added a section, 1.4, noting what's left; please review that. In that section I have three responses to Stephan (which I think should be final, and we should be OK), and two remaining action items that I'd like to ask Alexey to help with. The two items are as follows: To Do: "Interaction with Metadata": Add text requiring ManageSieve, and giving ManageSieve URI in IMAP capability. To Do: "Interaction with Metadata": Add ManageSieve action to set metadata item. Alexey, you're much more familiar with ManageSieve than I am. Can you come up with text to put into the "Interaction with Metadata" section (2.3.1) that will resolve these two items? If we can get text for that soon (hey, maybe even by the end of the week, so I can re-post before the Monday deadline?), we can actually do a WGLC on this version, and be ready to send it to the IESG after Paris. Barry _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> Barry Leiba 2012-03-06T17:15:38 http://permalink.gmane.org/gmane.ietf.mta-filters/5203 <pre>PING! Aaron: please post a -16 version with the typo fixed, and I will tell Pete to go ahead with this. Barry, shepherd _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> Barry Leiba 2012-03-06T02:47:20 http://permalink.gmane.org/gmane.ietf.mta-filters/5202 <pre> 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&lt; at &gt;isode.com, barryleiba&lt; at &gt;computer.org, likepeng&lt; at &gt;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. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor&lt; at &gt;rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> rfc-editor< at >rfc-editor.org 2012-02-29T18:58:32 http://permalink.gmane.org/gmane.ietf.mta-filters/5199 <pre>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. </pre> Cyrus Daboo 2012-02-16T19:29:12 http://permalink.gmane.org/gmane.ietf.mta-filters/5198 <pre> Looks good to me. Ned _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> NED+mta-filters< at >mauve.mrochek.com 2012-02-01T03:54:05 http://permalink.gmane.org/gmane.ietf.mta-filters/5197 <pre>Oof :( Thanks for reviewing the changes! On Tue, Jan 31, 2012 at 1:07 PM, Barry Leiba &lt;barryleiba&lt; at &gt;computer.org&gt; wrote: _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> Aaron Stone 2012-01-31T21:59:02 http://permalink.gmane.org/gmane.ietf.mta-filters/5196 <pre> That looks like what we want (the -15 version). Now just put out a -16 to fix the "foreverpart" typo you just introduced, and we'll move it along. Indeed. Barry, shepherding _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> Barry Leiba 2012-01-31T21:07:47 http://permalink.gmane.org/gmane.ietf.mta-filters/5195 <pre> 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-15.txt Pages : 17 Date : 2012-01-31 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-15.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-15.txt _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> internet-drafts< at >ietf.org 2012-01-31T18:08:50 http://permalink.gmane.org/gmane.ietf.mta-filters/5194 <pre>Posting this now. On Mon, Jan 23, 2012 at 5:00 PM, Ned Freed &lt;ned.freed&lt; at &gt;mrochek.com&gt; wrote: _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> Aaron Stone 2012-01-31T17:41:19 http://permalink.gmane.org/gmane.ietf.mta-filters/5193 <pre>Cyrus, for us at least, the issue is mostly moot because we have little interest in either of these extensions. (And I speak as someone who has implemented the vast majority of Sieve extensions so far.) In the case of convert, we've been providing on-the-fly conversion capabilities in our software ever since the early 90s. We've gone through multiple iterations of this idea, including system-level facilities, user-level facilities, and even schemes that allowed for hierarchical control of what's done. To be blunt, essentally none of it has proved to be worth the time spent coding it. Yes, there has been occasional usage, but the biggest use by far has been to do stuff the facilities weren't really intended for, like fixing up various sorts of brokenness - something that could have been accomodated better by a less general and more targetted mechanism. About the only conversion that has ever seen significant use is charset conversion, and that's invariably best done as a system-level thing since users rarely understand how to configure it. (And at this point it's all built in anyhow; no need for Sieve to control it.) The problem appears to be fundamental - people simply do not know how to codify their conversion needs in advance. I will also point out that complex per-user conversions at the MTA level have some serious performance implications in a high performance environment such as ours. I have always regarded this extension as mostly intended for MUA-side actions where such costs are essentially irrelevant. As for SIP notifications, it's not that we don't use notifications - we use them extensively - but other sorts seem to have us covered. Now, if a specific customer application arose for SIP notifications, the fact that we are aware of patents in the aware would immediately result in the corpordate legallie-beagallies getting pulled in. I honestly haven't a clue what the response from them would be. Ned _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> NED+mta-filters< at >mauve.mrochek.com 2012-01-27T17:17:26 http://permalink.gmane.org/gmane.ietf.mta-filters/5192 <pre> xml2rfc put that into MY documents without asking me or even pointing it out to me. I only discovered it because I carefully read the boilerplate, then chased the symlinks, then read a lot of unrelated prose in the two RFCs (not) specified. If I'd been a reasonable human rather than a horrible pedant I'd never have done that. Arnt _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> Arnt Gulbrandsen 2012-01-27T08:04:34 http://permalink.gmane.org/gmane.ietf.mta-filters/5191 <pre> Barry also said that company procedures have been improved to prevent this particular type of failure in the future. Speaking as Sieve WG member and sieve developer, I'm in favour of treating this as a mishap (albeit a bad one), not an attempt at deception. Arnt _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> Arnt Gulbrandsen 2012-01-27T08:01:25 http://permalink.gmane.org/gmane.ietf.mta-filters/5190 <pre>Hi Cyrus, At 13:42 26-01-2012, Cyrus Daboo wrote: That's the "do nothing" alternative. Peter mentioned that it is a bad idea. At 13:44 26-01-2012, Cyrus Daboo wrote: Thanks. Regards, -sm _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> SM 2012-01-26T22:37:23 http://permalink.gmane.org/gmane.ietf.mta-filters/5184 <pre>Hi folks, As I am sure you are aware IETF last calls on the sip-message and convert documents were re-issued in order to get IETF-wide feedback on the IPR issues. Much debate on this is going on on the IETF list and I have been approving messages to the SIEVE list coming from non-subscribers who are cross-posting, to make sure SIEVE WG can see some of that debate. I think we really need SIEVE implementors to speak up on this issue at least in regard to whether these specifications can still be used as-is in products, or whether the current IPR terms would preclude that. I realize that probably means getting a formal legal review done, but chances are that is going to be needed regardless. Knowledge of this would help simplify the debate in terms of whether the current documents should be published at all, irrespective of any additional action on the part of the IETF on the actual failure in the IPR process. So please, if possible, reply to the current thread on the second last call, and please make sure the IETF list is cc'd. Thanks. </pre> Cyrus Daboo 2012-01-26T16:42:20 http://permalink.gmane.org/gmane.ietf.mta-filters/5183 <pre>As I've mentioned to others, since I'm one of the people who will have to judge the consensus on this question, my comments will remain strictly based on the facts of the events as I know them and on the relevant IETF procedures. It is up to the IETF community to decide on what the appropriate course of action shall be. That said, I have some comments and questions: On 1/26/12 3:31 AM, John C Klensin wrote: We were told by the other company employees who facilitated the disclosures, at the time of the disclosures, that this was strictly an individual's failure to comply with the IETF IPR Policy, that the author in question claims not to have understood the IETF IPR Policy, and that the company proceeded to make these disclosures as soon as it discovered that this IPR existed. I have no information to contradict that claim. Are you asking that the IPR statements be updated with the name, department, and title of the "Director of Licensing", or that of the author of the documents and patents in question? It seems to me that the former is a procedural question that is separate from the disposition of these particular documents, and seems like a reasonable requirement for any IPR disclosure. If you're asking for the latter, are you asking that the sanction against the author be a new obligation on the author? Section 6 of RFC 3979 clearly says, "A participant's obligation to make a disclosure is also considered satisfied if the IPR owner or the participant's employer or sponsor makes an appropriate disclosure in place of the participant doing so." The IETF Chair has in the past sent messages to companies to inquire about their handling of IPR disclosures, so I imagine such a message could be sent if the IETF community desires it. I'll ask to bring this topic up with the IETF attorney. I am pretty sure we can *ask* that they do this as a show of good faith. I am also pretty certain that we can't negotiate the terms of a license agreement. Of course, removal of individual document editors is well within the rights and responsibilities of the chairs, so if this is the consensus of the IETF, I am sure it can be done. I would like you to elaborate on the issue of the authors who are employees of the company but *not* the author of the patent in question. Are you saying that their names should be removed because, as co-workers of the author in question, they ought to have known (or been more diligent in confirming) that the IPR existed and therefore should be sanctioned for failing to comply with the IPR rules, or are you saying that this is a sanction that should be levied against the company and therefore its employees? I will note that RFC 3979 does not put a responsibility on individual participants to go discover IPR that may exist, nor does it make any overt requirements of companies since it applies only to the individual participants in the IETF (caveat the recognitions in sections 6.6 and 7). I believe this last one is outside of the scope of the decisions the IETF has to take regarding the disposition of the particular documents. It may indeed be reasonable for every IETF participant to review the policies and actions of their own employer as they relate to IETF participation and make a conscientious decision whether they can continue to participate in the IETF, whatever their role, given those policies and procedures. pr </pre> Pete Resnick 2012-01-26T16:08:28 http://permalink.gmane.org/gmane.ietf.mta-filters/5168 <pre>+1 On 1/25/12 2:50 PM, Adrian Farrel wrote: _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> Peter Saint-Andre 2012-01-25T22:04:09 http://permalink.gmane.org/gmane.ietf.mta-filters/5165 <pre> 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' &lt;draft-ietf-sieve-convert-06.txt&gt; 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&lt; at &gt;ietf.org mailing lists by 2012-02-08. Exceptionally, comments may be sent to iesg&lt; at &gt;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/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sieve-convert/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1657/ _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> The IESG 2012-01-25T20:19:02 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.mta-filters