From aaron@serendipity.cx Thu Jan 5 06:33:24 2012 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9DC21F86CD; Thu, 5 Jan 2012 06:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.146 X-Spam-Level: X-Spam-Status: No, score=-101.146 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYJ1jlszlkw1; Thu, 5 Jan 2012 06:33:23 -0800 (PST) Received: from slice.serendipity.cx (slice.serendipity.cx [67.23.2.90]) by ietfa.amsl.com (Postfix) with ESMTP id 59D3421F85BD; Thu, 5 Jan 2012 06:33:23 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by slice.serendipity.cx (Postfix) with ESMTPSA id E6D91110077; Thu, 5 Jan 2012 06:30:55 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so478264vcb.31 for ; Thu, 05 Jan 2012 06:33:19 -0800 (PST) Received: by 10.220.149.135 with SMTP id t7mr1174966vcv.34.1325773999217; Thu, 05 Jan 2012 06:33:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.112.70 with HTTP; Thu, 5 Jan 2012 06:32:58 -0800 (PST) In-Reply-To: <2FF53820-1728-4FDE-843A-19E61CBB795D@nostrum.com> References: <2FF53820-1728-4FDE-843A-19E61CBB795D@nostrum.com> From: Aaron Stone Date: Thu, 5 Jan 2012 06:32:58 -0800 Message-ID: To: Ben Campbell Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "gen-art@ietf.org Review Team" , Sieve mailing list Subject: Re: [sieve] [Gen-art] Gen-ART Last Call Review of draft-ietf-sieve-include-13 X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 14:33:24 -0000 On Mon, Dec 19, 2011 at 12:46 PM, Ben Campbell wrote: > Thanks for the response! Further comments inline, with sections that appe= ar > 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 wrote: >> >> > > [=85] > >> Minor issues: >> >> -- section 3.1, paragraph 4: "Implementations MUST NOT generate errors f= or >> recursive inclusions at upload time, as this would force an upload order= ing >> requirement upon script authors / generators. =A0However, if an active s= cript >> 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. =A0In >> particular, how can the latter assertion avoid an upload ordering >> requirement? Or do you mean faulty in some way other than being recursiv= e? > > > 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 > stage while some scripts are uploaded but not others, they are in an inva= lid > state. The managesieve spec says that scripts must be validated at upload > time. The language above is trying to say that you can upload all of the > scripts that may include one another in any order without generating erro= rs > immediately, however, if you're replacing an active script or a script > included by the active script, then you DO have to upload a correct scrip= t > right from the get-go. > > > Is this just a question of whether the script(s) are replacing active > scripts? That is, the license to create a transient invalid state is > suspended if if you are replacing an active script? If so, how would one = go > about updating a set of linked scripts when one or more of them replace > active scripts? Should one somehow deactivate the old ones, load all the > scripts, then activate them? Having written this out, I don't recall how an implementation would handle this. I haven't had luck tracking down maling list discussion on the topic. I'll have to chase up on this. >> >> -- section 3.4.1, paragraph 5: "If a "global" command is given the name = of >> a variable that has previously been defined in the immediate script with >> "set", an error MUST be generated either when the script is uploaded or = at >> execution time." >> >> Does this conflict with the previous statement that it is okay for a >> global and a private variable to have the same name? > > > It doesn't conflict, because those variables live in separate namespaces. > The effect of the global command is to bind the two names. An error is > generated rather than specifying if the local overwrites the global value= , > or the global overwrites the local value. > > > I take this to mean you can have a global and a local variable with the s= ame > name, but not if they are in the same script, right? If so, then it would > help to add that qualification to the 2nd paragraph in 3.4. As it is, it > says implementation MUST allow a global and non-global variable to have t= he > same name with no interaction, and doesn't exclude it from happening in t= he > same script. Ok. > >> >> -- section 3.4.2: >> >> Why do you need two ways to accomplish the same thing? > > > I might be making this up, but I think the original question was whether = the > variables spec would have namespaces. > > > I think I need more context to understand that response--but _my_ origina= l > question was more along the lines of "if we have the global name space, w= hy > do we need the command, and vice-versa?" It seems like either one > accomplishes the goal (I actually like the NS as it seems like it would > obviate the previous question about globals and locals with the same name= ) > But more practically, why make an implementation implement them both? It > seems like twice as much work, and twice as much opportunity to introduce > bugs. Background on my reply: there was a question early-on in the variables document about whether namespaces would be supported, at the same time as early drafts of include. I checked, and these were contemporary issues in 2003. Ultimately, Sieve Variables provides namespaces, and this document added support for namespaces without dropping the command-form global. >> >> Does the global namespace have the same "requires" requirement as the >> global command? > > > Yes, but this isn't explicitly stated. > > > Thanks--I think it would help to state it explicitly. I've added some text that quotes from Sieve Variables, where this "require" requirement is stated. > >> >> -- section 4.2, paragraph 2: >> >> Can you elaborate on what permissions are proper? Is it different for an >> included script than for any other script? >> >> -- section 4.2, paragraph 3: >> >> Can you elaborate on what you mean by "safe for a storage system"? >> > > There are both somewhat vague warnings, basically, "Don't allow 'include > "./../..//etc/passwd"' and don't allow 'include "foo$(`rm star`)"'. > > > Including those (or some other) examples would help. > > [=85] Done. > >> >> -- section 3.4.2, paragraph 3: "Variables declared global and variables >> accessed via the global namespace MUST be one and the same." >> >> Plurality mismatch. I suggest something like "a variable declared as >> global and a variable accesses with the global namespace, otherwise havi= ng >> the same name=85" > > > I might insert the word "each" after MUST to account for the plurality > without rewriting the sentence. > > > > That works, too. > > [=85] Done. From internet-drafts@ietf.org Thu Jan 5 07:01:32 2012 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9906D21F873C; Thu, 5 Jan 2012 07:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmNA3PLcrDdX; Thu, 5 Jan 2012 07:01:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF4621F8541; Thu, 5 Jan 2012 07:01:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120105150132.22804.72245.idtracker@ietfa.amsl.com> Date: Thu, 05 Jan 2012 07:01:32 -0800 Cc: sieve@ietf.org Subject: [sieve] I-D Action: draft-ietf-sieve-include-14.txt X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 15:01:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. 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 From wwwrun@rfc-editor.org Thu Jan 5 07:16:50 2012 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CEC21F8750 for ; Thu, 5 Jan 2012 07:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAf3aMZMFjUe for ; Thu, 5 Jan 2012 07:16:50 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2040521F8598 for ; Thu, 5 Jan 2012 07:16:50 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id EF0B1B1E002; Thu, 5 Jan 2012 07:14:32 -0800 (PST) To: murch@andrew.cmu.edu, presnick@qualcomm.com, stpeter@stpeter.im, cyrus@daboo.name, aaron@serendipity.cx From: RFC Errata System Message-Id: <20120105151432.EF0B1B1E002@rfc-editor.org> Date: Thu, 5 Jan 2012 07:14:32 -0800 (PST) Cc: sieve@ietf.org, rfc-editor@rfc-editor.org Subject: [sieve] [Editorial Errata Reported] RFC5233 (3079) X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 15:16:51 -0000 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 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 "@" :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 "@" :domain \------------------/ :local-part Corrected 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 "@" :domain \-----------------/ :localpart 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 "@" :domain \------------------/ :localpart Notes ----- Throughout the document, the prose phrase "local-part" is hyphenated, while the syntactic word ":localpart" is not hyphenated. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5233 (draft-ietf-sieve-rfc3598bis-05) -------------------------------------- Title : Sieve Email Filtering: Subaddress Extension Publication Date : January 2008 Author(s) : K. Murchison Category : PROPOSED STANDARD Source : Sieve Mail Filtering Language Area : Applications Stream : IETF Verifying Party : IESG From NED+mta-filters@mauve.mrochek.com Thu Jan 5 10:08:35 2012 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2F021F87CF for ; Thu, 5 Jan 2012 10:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opFCK1b6j6hn for ; Thu, 5 Jan 2012 10:08:34 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 931F621F85D8 for ; Thu, 5 Jan 2012 10:08:34 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OAFALM22FK00VVH0@mauve.mrochek.com> for sieve@ietf.org; Thu, 5 Jan 2012 10:08:31 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OADP8G3BY8000HW1@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Thu, 5 Jan 2012 10:08:24 -0800 (PST) From: NED+mta-filters@mauve.mrochek.com Message-id: <01OAFALIPSKQ000HW1@mauve.mrochek.com> Date: Thu, 05 Jan 2012 10:06:03 -0800 (PST) In-reply-to: "Your message dated Thu, 05 Jan 2012 07:14:32 -0800 (PST)" <20120105151432.EF0B1B1E002@rfc-editor.org> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120105151432.EF0B1B1E002@rfc-editor.org> To: RFC Errata System Cc: sieve@ietf.org, presnick@qualcomm.com, rfc-editor@rfc-editor.org Subject: Re: [sieve] [Editorial Errata Reported] RFC5233 (3079) X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 18:08:35 -0000 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 > 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 "@" :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 "@" :domain > \------------------/ > :local-part > Corrected 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 "@" :domain > \-----------------/ > :localpart > 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 "@" :domain > \------------------/ > :localpart > Notes > ----- > Throughout the document, the prose phrase "local-part" is hyphenated, while the syntactic word ":localpart" is not hyphenated. > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > -------------------------------------- > RFC5233 (draft-ietf-sieve-rfc3598bis-05) > -------------------------------------- > Title : Sieve Email Filtering: Subaddress Extension > Publication Date : January 2008 > Author(s) : K. Murchison > Category : PROPOSED STANDARD > Source : Sieve Mail Filtering Language > Area : Applications > Stream : IETF > Verifying Party : IESG > _______________________________________________ > sieve mailing list > sieve@ietf.org > https://www.ietf.org/mailman/listinfo/sieve From aaron@serendipity.cx Thu Jan 5 10:21:42 2012 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184F321F8767 for ; Thu, 5 Jan 2012 10:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.229 X-Spam-Level: X-Spam-Status: No, score=-101.229 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3iIn3EZOvpC for ; Thu, 5 Jan 2012 10:21:41 -0800 (PST) Received: from slice.serendipity.cx (slice.serendipity.cx [67.23.2.90]) by ietfa.amsl.com (Postfix) with ESMTP id 3961921F87D6 for ; Thu, 5 Jan 2012 10:21:39 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by slice.serendipity.cx (Postfix) with ESMTPSA id 0FC3D11007C for ; Thu, 5 Jan 2012 10:19:06 -0800 (PST) Received: by vbbfo1 with SMTP id fo1so673210vbb.31 for ; Thu, 05 Jan 2012 10:21:29 -0800 (PST) Received: by 10.52.178.70 with SMTP id cw6mr1469493vdc.6.1325787689256; Thu, 05 Jan 2012 10:21:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.112.70 with HTTP; Thu, 5 Jan 2012 10:21:08 -0800 (PST) In-Reply-To: <01OAFALIPSKQ000HW1@mauve.mrochek.com> References: <20120105151432.EF0B1B1E002@rfc-editor.org> <01OAFALIPSKQ000HW1@mauve.mrochek.com> From: Aaron Stone Date: Thu, 5 Jan 2012 10:21:08 -0800 Message-ID: To: Ned Freed Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sieve@ietf.org, presnick@qualcomm.com, RFC Errata System Subject: Re: [sieve] [Editorial Errata Reported] RFC5233 (3079) X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 18:21:42 -0000 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 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 s= econd > paragraph. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ned > >> 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=3D5233&eid=3D3079 > >> -------------------------------------- >> Type: Editorial >> Reported by: Aaron Stone > >> Section: 4 > >> Original Text >> ------------- >> =A0 =A0A diagram showing the ADDRESS-PARTs of an email address where the >> =A0 =A0detail information follows a separator character sequence of "+" = is >> =A0 =A0shown below: > >> =A0 =A0 =A0 =A0 =A0 :user "+" :detail =A0"@" :domain >> =A0 =A0 =A0 =A0 =A0\-----------------/ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0:local-part > >> =A0 =A0A diagram showing the ADDRESS-PARTs of a email address where the >> =A0 =A0detail information precedes a separator character sequence of "--= " is >> =A0 =A0shown below: > >> =A0 =A0 =A0 =A0 =A0 :detail "--" :user =A0"@" :domain >> =A0 =A0 =A0 =A0 =A0\------------------/ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0:local-part > >> Corrected Text >> -------------- >> =A0 =A0A diagram showing the ADDRESS-PARTs of an email address where the >> =A0 =A0detail information follows a separator character sequence of "+" = is >> =A0 =A0shown below: > >> =A0 =A0 =A0 =A0 =A0 :user "+" :detail =A0"@" :domain >> =A0 =A0 =A0 =A0 =A0\-----------------/ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0:localpart > >> =A0 =A0A diagram showing the ADDRESS-PARTs of a email address where the >> =A0 =A0detail information precedes a separator character sequence of "--= " is >> =A0 =A0shown below: > >> =A0 =A0 =A0 =A0 =A0 :detail "--" :user =A0"@" :domain >> =A0 =A0 =A0 =A0 =A0\------------------/ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0:localpart > >> Notes >> ----- >> Throughout the document, the prose phrase "local-part" is hyphenated, wh= ile the syntactic word ":localpart" is not hyphenated. > >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. > >> -------------------------------------- >> RFC5233 (draft-ietf-sieve-rfc3598bis-05) >> -------------------------------------- >> Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Sieve Email Filtering: Subaddress Ex= tension >> Publication Date =A0 =A0: January 2008 >> Author(s) =A0 =A0 =A0 =A0 =A0 : K. Murchison >> Category =A0 =A0 =A0 =A0 =A0 =A0: PROPOSED STANDARD >> Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Sieve Mail Filtering Language >> Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Applications >> Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF >> Verifying Party =A0 =A0 : IESG >> _______________________________________________ >> sieve mailing list >> sieve@ietf.org >> https://www.ietf.org/mailman/listinfo/sieve From barryleiba.mailing.lists@gmail.com Fri Jan 13 07:13:56 2012 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0505C21F84CD; Fri, 13 Jan 2012 07:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.721 X-Spam-Level: X-Spam-Status: No, score=-102.721 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sXtoMO3mISn; Fri, 13 Jan 2012 07:13:55 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5A021F845F; Fri, 13 Jan 2012 07:13:55 -0800 (PST) Received: by yenr11 with SMTP id r11so308458yen.31 for ; Fri, 13 Jan 2012 07:13:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kCQwa5isQj/RaVT7dmuintVTJEeJRMRSWg4n9MEp+p8=; b=g7nSc5vCgJMfKRnK6V45ALKPWuSSasl9+ok6WzyDSMJdE+vRAyJhBvec/Ut5jo7yUh nxESo/NgqZF+Iz6wPJS649CjoSnDf3kNIetP2PAZG6p3djeYVIK5iFD8txzm+rCoWs7D yEtaQAnTU6tRcp8UJa8p3HH/yUzvrJmL+rH4I= MIME-Version: 1.0 Received: by 10.236.152.35 with SMTP id c23mr2020878yhk.58.1326467634850; Fri, 13 Jan 2012 07:13:54 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.114.13 with HTTP; Fri, 13 Jan 2012 07:13:49 -0800 (PST) In-Reply-To: References: <2FF53820-1728-4FDE-843A-19E61CBB795D@nostrum.com> Date: Fri, 13 Jan 2012 10:13:49 -0500 X-Google-Sender-Auth: VMYjuaVuR_GATWOWG6bl3jAQgYc Message-ID: From: Barry Leiba To: Aaron Stone Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ben Campbell , "gen-art@ietf.org Review Team" , Sieve mailing list Subject: Re: [sieve] [Gen-art] Gen-ART Last Call Review of draft-ietf-sieve-include-13 X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 15:13:56 -0000 >>> -- section 3.1, paragraph 4: "Implementations MUST NOT generate errors = for >>> recursive inclusions at upload time, as this would force an upload orde= ring >>> requirement upon script authors / generators. =A0However, 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. =A0In >>> particular, how can the latter assertion avoid an upload ordering >>> requirement? Or do you mean faulty in some way other than being recursi= ve? >> >> 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 yo= u're >> uploading a set of scripts that include one another, at some intermediat= e >> stage while some scripts are uploaded but not others, they are in an inv= alid >> state. The managesieve spec says that scripts must be validated at uploa= d >> time. The language above is trying to say that you can upload all of the >> scripts that may include one another in any order without generating err= ors >> immediately, however, if you're replacing an active script or a script >> included by the active script, then you DO have to upload a correct scri= pt >> right from the get-go. >> >> Is this just a question of whether the script(s) are replacing active >> scripts? That is, the license to create a transient invalid state is >> suspended if if you are replacing an active script? If so, how would one= go >> about updating a set of linked scripts when one or more of them replace >> active scripts? Should one somehow deactivate the old ones, load all the >> scripts, then activate them? > > Having written this out, I don't recall how an implementation would > handle this. I haven't had luck tracking down maling list discussion > on the topic. I'll have to chase up on this. I don't think this is a real problem; the text just needs a little tweaking. Errors should still be generated at upload time for any detectable script errors OTHER THAN recursion. What this is meant to deal with is a situation where, say, we have this: main includes sub-a sub-a includes sub-b sub-b includes sub-c ...and we want to rewrite things and change the structure thus: main includes sub-a main includes sub-c sub-c includes sub-b [sub-b no longer includes sub-c] This would require that we update sub-b *before* we update sub-c, or else we'd get an error at upload time. The text is meant to block the recursion error, so we can update the scripts in any order. However, if the script gets run in the middle of the updates and we hit a recursion situation, we WILL get a runtime error. That's all that text is meant to do. That said, it would be wise for implementations to provide a way to do an atomic update of a set of scripts, because, clearly, multiple scrips in some indeterminate intermediate upload state could do very weird (and perhaps bad) things, even if no errors are generated during their execution. I think this isn't a protocol requirement, but a quality-of-implementation issue. But I do think the document could have a paragraph discussing this, and warning of the consequences. Barry, document shepherd From alexey.melnikov@isode.com Sat Jan 21 06:17:28 2012 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4D421F853B for ; Sat, 21 Jan 2012 06:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.285 X-Spam-Level: X-Spam-Status: No, score=-102.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttXSM7RVGbph for ; Sat, 21 Jan 2012 06:17:28 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id D38F221F8534 for ; Sat, 21 Jan 2012 06:17:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1327155444; d=isode.com; s=selector; i=@isode.com; bh=CHouZRwkulaI9SbC8JGg92735Max11ZAUp+CR0aOPhk=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Qd/L7Yb/a9DVczSI9gvadTdqlNkbW0WxnryLwVlQTRLmCRX1MbFdrkLmRXgQixIJIlHhcw TO42AAZ/W68LWxcfbU+h1KmnTvMJmU/2hnhSnN+we+CfjageNgihJNsSHPJLenPgROPW8V zdr6jYfLWBemOcNXcGnIB/9S/VBSedE=; Received: from [188.28.224.161] (188.28.224.161.threembb.co.uk [188.28.224.161]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 21 Jan 2012 14:17:23 +0000 Message-ID: <4F1ABE14.5020601@isode.com> Date: Sat, 21 Jan 2012 13:31:00 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: Sieve mailing list MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sieve] Sieve include: interactions with MIME loops X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 14:17:28 -0000 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? From aaron@serendipity.cx Mon Jan 23 16:26:12 2012 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9131B21F85C4 for ; Mon, 23 Jan 2012 16:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.332 X-Spam-Level: X-Spam-Status: No, score=-101.332 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPsdz7fG8ZA1 for ; Mon, 23 Jan 2012 16:26:12 -0800 (PST) Received: from slice.serendipity.cx (slice.serendipity.cx [67.23.2.90]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA2021F85C3 for ; Mon, 23 Jan 2012 16:26:12 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by slice.serendipity.cx (Postfix) with ESMTPSA id CAB6C11005E for ; Mon, 23 Jan 2012 16:23:22 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so2564448vcb.31 for ; Mon, 23 Jan 2012 16:26:05 -0800 (PST) Received: by 10.220.149.212 with SMTP id u20mr5882672vcv.7.1327364765222; Mon, 23 Jan 2012 16:26:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.112.70 with HTTP; Mon, 23 Jan 2012 16:25:44 -0800 (PST) In-Reply-To: <4F1ABE14.5020601@isode.com> References: <4F1ABE14.5020601@isode.com> From: Aaron Stone Date: Mon, 23 Jan 2012 16:25:44 -0800 Message-ID: To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Sieve mailing list Subject: Re: [sieve] Sieve include: interactions with MIME loops X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 00:26:12 -0000 On Sat, Jan 21, 2012 at 5:31 AM, Alexey Melnikov wrote: > I am looking at the new text in draft-ietf-sieve-include-14.txt: > > 3.5. =A0Interaction with Other Extensions > > =A0 =A0 =A0 =A0When "include" is used with the Editheader extension [RFC5= 293], any > =A0 =A0 =A0 =A0changes made to headers in a script MUST be propagated bot= h to and > =A0 =A0 =A0 =A0from included scripts. =A0By way of example, if a script d= eletes one > =A0 =A0 =A0 =A0header and add another, then includes a second script, the= included > =A0 =A0 =A0 =A0script MUST NOT see the removed header, and MUST see the a= dded > =A0 =A0 =A0 =A0header. =A0Likewise, if the included script adds or remove= s a header, > =A0 =A0 =A0 =A0upon returning to the including script, subsequent actions= MUST see > =A0 =A0 =A0 =A0the added headers and MUST NOT see the removed headers. > > =A0 =A0 =A0 =A0When "include" is used with the MIME extension [RFC5703] > =A0 =A0 =A0 =A0"foreverypart" control structure, the included script MUST= be > =A0 =A0 =A0 =A0presented with the current MIME part as though it were the= entire > =A0 =A0 =A0 =A0message. =A0A script SHALL NOT have any special control ov= er the > =A0 =A0 =A0 =A0control structure it was included from. =A0In the MIME exa= mple once > =A0 =A0 =A0 =A0again, a "stop" or "return" in an included script cannot d= irectly > =A0 =A0 =A0 =A0terminate or continue flow of a "foreverypart" block. =A0I= n such a > =A0 =A0 =A0 =A0case, the included script should set a global variable tha= t the > =A0 =A0 =A0 =A0including 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 entire message. I think stop does the same, except with the implicit keep as the default. Some text in an additional "interactions with other extensions" subsection should state this. Oh man, here goes another rev. Thanks, Aaron From NED+mta-filters@mauve.mrochek.com Mon Jan 23 17:03:15 2012 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88CB421F85C3 for ; Mon, 23 Jan 2012 17:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goczsoCOmoyX for ; Mon, 23 Jan 2012 17:03:15 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 04D6121F85BD for ; Mon, 23 Jan 2012 17:03:15 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OB4UBU1HR4006QMA@mauve.mrochek.com> for sieve@ietf.org; Mon, 23 Jan 2012 17:03:08 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OB4EQF85J400ZUIL@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Mon, 23 Jan 2012 17:03:00 -0800 (PST) From: NED+mta-filters@mauve.mrochek.com Message-id: <01OB4UBRD5QU00ZUIL@mauve.mrochek.com> Date: Mon, 23 Jan 2012 17:00:17 -0800 (PST) In-reply-to: "Your message dated Mon, 23 Jan 2012 16:25:44 -0800" References: <4F1ABE14.5020601@isode.com> To: Aaron Stone Cc: Sieve mailing list Subject: Re: [sieve] Sieve include: interactions with MIME loops X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 01:03:15 -0000 > On Sat, Jan 21, 2012 at 5:31 AM, Alexey Melnikov > 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 > entire message. I don't agree; I think it should simply set reject as the script result and continue. It's possible that some other action that's compatible with reject (e.g., notify) would be done later. If you want it to halt you can put stop after the reject. > I think stop does the same, except with the implicit > keep as the default. Right, but stop should be the only thing that terminates execution. > Some text in an additional "interactions with other extensions" > subsection should state this. > Oh man, here goes another rev. Good thing they're cheap. Ned From iesg-secretary@ietf.org Wed Jan 25 12:17:28 2012 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143A121F8508; Wed, 25 Jan 2012 12:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49MfkpVBQO7D; Wed, 25 Jan 2012 12:17:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2011221F8449; Wed, 25 Jan 2012 12:17:14 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> Date: Wed, 25 Jan 2012 12:17:14 -0800 Cc: sieve@ietf.org Subject: [sieve] Second Last Call: (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 20:17:28 -0000 The IESG has received a request from the Sieve Mail Filtering Language WG (sieve) to consider the following document: - 'Sieve Notification Mechanism: SIP MESSAGE' 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@ietf.org mailing lists by 2012-02-08. Exceptionally, comments may be sent to iesg@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 http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1658/ From iesg-secretary@ietf.org Wed Jan 25 12:19:03 2012 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B5F11E80BE; Wed, 25 Jan 2012 12:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOrv7fr46xsq; Wed, 25 Jan 2012 12:19:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97EA11E808F; Wed, 25 Jan 2012 12:19:02 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120125201902.5110.73400.idtracker@ietfa.amsl.com> Date: Wed, 25 Jan 2012 12:19:02 -0800 Cc: sieve@ietf.org Subject: [sieve] Second Last Call: (Sieve Extension for Converting Messages Before Delivery) to Proposed Standard X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 20:19:03 -0000 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' 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@ietf.org mailing lists by 2012-02-08. Exceptionally, comments may be sent to iesg@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/ From stpeter@stpeter.im Wed Jan 25 14:04:11 2012 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D7011E8098; Wed, 25 Jan 2012 14:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.717 X-Spam-Level: X-Spam-Status: No, score=-102.717 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIlawElRT7qr; Wed, 25 Jan 2012 14:04:11 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E6A0F11E807A; Wed, 25 Jan 2012 14:04:10 -0800 (PST) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4257F40058; Wed, 25 Jan 2012 15:13:56 -0700 (MST) Message-ID: <4F207C59.6070705@stpeter.im> Date: Wed, 25 Jan 2012 15:04:09 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk> In-Reply-To: <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Sieve mailing list , 'Adam Roach' , ietf@ietf.org, IESG IESG Subject: Re: [sieve] Second Last Call: (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 22:04:12 -0000 +1 On 1/25/12 2:50 PM, Adrian Farrel wrote: > Please also see US patent 20090204681 visible at > http://ip.com/patapp/US20090204681 > > > > In my opinion, this second last call should be suspended until this > significant breach of the IETF's IPR policy set out in BCP79 has been > resolved. > > > > While it is important to find out what the IETF community's view of this > situation is, there are two questions: > > > > 1. What does the WG think about the I-D being IPR encumbered and do they > want to develop an alternate solution that is not encumbered? > > > > 2. How will the IETF handle the breach of IPR policy? > > > > I believe the document should be returned to the working group who are > the main victims of the disruptive behaviour by the author. > > > > Thanks, > > Adrian > > > > *From:*ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] *On Behalf > Of *Adam Roach > *Sent:* 25 January 2012 21:36 > *To:* ietf@ietf.org > *Cc:* sieve@ietf.org; The IESG; IETF-Announce > *Subject:* Re: Second Last Call: > (Sieve Notification > Mechanism: SIP MESSAGE) to Proposed Standard > > > > Just to make sure I understand the sequence of events: > > 1. August 21, 2007: Huawei files a patent (CN 200710076523.4) on using > SIP for SIEVE notifications. The inventor is listed as a single > Huawei employee. > 2. August 30, 2007: That same Huawei employee and two additional > authors publish an IETF draft ( > draft-melnikov-sieve-notify-sip-message-00) on using SIP for SIEVE > notifications. > 3. September 2007 - September 2011: The SIEVE working group discusses > and improves the IETF draft. > 4. October 6, 2011: The IESG approves the IETF draft for publication as > an RFC. > 5. December 14th, 2011: Huawei files an IPR disclosure with the IETF > informing it of patent CN 200710076523.4 > > > Is that correct? Am I leaving anything out? > > /a > > > On 1/25/12 2:17 PM, The IESG wrote: > > > > The IESG has received a request from the Sieve Mail Filtering Language WG > > (sieve) to consider the following document: > > - 'Sieve Notification Mechanism: SIP MESSAGE' > > 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@ietf.org mailing lists by 2012-02-08. Exceptionally, comments may be > > sent to iesg@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 > > http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/ > > > > > > The following IPR Declarations may be related to this I-D: > > > > http://datatracker.ietf.org/ipr/1658/ > > > > > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce > > > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From presnick@qualcomm.com Wed Jan 25 15:06:37 2012 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573EB21F8631; Wed, 25 Jan 2012 15:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8iWctoAFkL5; Wed, 25 Jan 2012 15:06:36 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id A0C7321F862D; Wed, 25 Jan 2012 15:06:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1327532796; x=1359068796; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F208AEF.5060406@qualcomm.com>|Date:=20We d,=2025=20Jan=202012=2017:06:23=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20"Worley,=20Dale=20R=20(Dale)" =20|CC:=20"adrian@olddog.co.uk"=20,=20'Adam=20Roach'=0D=0A=09,=20"ietf@ietf.org"=20,=20"sieve@ietf .org"=0D=0A=09|Subject:=20Re:=20Second=20 Last=20Call:=09=0D=0A=20(Sieve=09Notification=20Mechanism:=20SIP=20MES SAGE)=20to=20Proposed=20Standard|References:=20<201201252 01714.3903.82295.idtracker@ietfa.amsl.com>=09<4F2075BE.50 70201@nostrum.com>,=09<033901ccdbab$6bae0900$430a1b00$@ol ddog.co.uk>=20|In-Reply-To:=20|Content-Type:=20text/plain=3B=20charset=3D"ISO-8859 -1"=3B=20format=3Dflowed|Content-Transfer-Encoding:=207bi t|X-Originating-IP:=20[172.30.48.1]; bh=B7wQBDpCDOcWYdzJwmVfcIHKAdxG7PRCOqPq5kMrdiQ=; b=CB3G6v9ItjJQFHm2s79U9PDszpGpgUkqv8S1nehtumYCIMUW3L/u36e+ Mmt135aoq7MnD7An/QvvqdT6ez4b14nmii+hdn0J+Q1e4XSYNCZMq2oRg B3+Maaw56vPCQw9nhpPs0HJZzNtMjlHS3beLb00Jer2NktnwTlpHoBoPU M=; X-IronPort-AV: E=McAfee;i="5400,1158,6600"; a="155623226" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 25 Jan 2012 15:06:36 -0800 X-IronPort-AV: E=Sophos;i="4.71,568,1320652800"; d="scan'208";a="157173473" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 25 Jan 2012 15:06:34 -0800 Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 25 Jan 2012 15:06:25 -0800 Message-ID: <4F208AEF.5060406@qualcomm.com> Date: Wed, 25 Jan 2012 17:06:23 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com>, <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: "sieve@ietf.org" , "adrian@olddog.co.uk" , 'Adam Roach' , "ietf@ietf.org" Subject: Re: [sieve] Second Last Call: (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 23:06:37 -0000 On 1/25/12 4:39 PM, Worley, Dale R (Dale) wrote: >> From: Adrian Farrel [adrian@olddog.co.uk] >> >> In my opinion, this second last call should be suspended until this >> significant breach of the IETF's IPR policy set out in BCP79 has been >> resolved. >> [...] >> I believe the document should be returned to the working group who are >> the main victims of the disruptive behaviour by the author. >> > If the facts are as outlined by Adam Roach, this is the only thing to do. > I apologize for not making this clear in the Last Call text: Before posting this Last Call (and the similar one for draft-ietf-sieve-convert), the documents *were* returned to the SIEVE WG to review the situation. With minimal complaint from the WG and no indication that the WG wished to change their decision on the documents, the chairs asked that I simply put it to the entire community as a Last Call. So I believe anything other than "go ahead with publication as is" will be done only if that is the consensus of the IETF community as a whole. The SIEVE chairs and I will be monitoring the discussion. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From presnick@qualcomm.com Wed Jan 25 17:41:06 2012 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E65211E80CD; Wed, 25 Jan 2012 17:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoOR2qT441Gy; Wed, 25 Jan 2012 17:41:05 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 177CC11E80AC; Wed, 25 Jan 2012 17:41:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1327542065; x=1359078065; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: x-originating-ip; z=Message-ID:=20<4F20AF20.40103@qualcomm.com>|Date:=20Wed, =2025=20Jan=202012=2019:40:48=20-0600|From:=20Pete=20Resn ick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Adam=20Roach=20|CC:=20,=20,=20The=20IE SG=20,=0D=0A=09IETF-Announce=20< ietf-announce@ietf.org>|Subject:=20Re:=20Second=20Last=20 Call:=20=0D =0A=20(Sieve=20Notification=20Mechanism:=20SIP=20MESSAGE) =20to=20Proposed=20Standard|References:=20<20120125201714 .3903.82295.idtracker@ietfa.amsl.com>=20<4F2075BE.5070201 @nostrum.com>|In-Reply-To:=20<4F2075BE.5070201@nostrum.co m>|Content-Type:=20multipart/alternative=3B=0D=0A=09bound ary=3D"------------010602010108090808070707" |X-Originating-IP:=20[172.30.39.5]; bh=WfQM7uxvTaHp6jHW8qf00HwyQ2sGHONE0aybSgMjoqU=; b=g/MY8HQtkYjHv+ygmR3JxpH6xb+c0aMcqYanArW0Z8VQp9Veh4AYKTuQ rMQhtdeL+cShLSYUrdCxOwck/Dk4GHBJwL4ZhCPt//4qfiRBHFvFQGXCM nSlRYENzHVgSmVCfG+/l34ShuVYs5nXqPO30ibitCpdty5aID1lRGhcC7 E=; X-IronPort-AV: E=McAfee;i="5400,1158,6600"; a="155653546" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine02.qualcomm.com with ESMTP; 25 Jan 2012 17:40:51 -0800 X-IronPort-AV: E=Sophos;i="4.71,568,1320652800"; d="scan'208,217";a="119012305" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 25 Jan 2012 17:40:51 -0800 Received: from Macintosh-4.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 25 Jan 2012 17:40:51 -0800 Message-ID: <4F20AF20.40103@qualcomm.com> Date: Wed, 25 Jan 2012 19:40:48 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Adam Roach References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> In-Reply-To: <4F2075BE.5070201@nostrum.com> Content-Type: multipart/alternative; boundary="------------010602010108090808070707" X-Originating-IP: [172.30.39.5] Cc: The IESG , sieve@ietf.org, ietf@ietf.org, IETF-Announce Subject: Re: [sieve] Second Last Call: (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 01:41:06 -0000 --------------010602010108090808070707 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 1/25/12 3:35 PM, Adam Roach wrote: > Just to make sure I understand the sequence of events: > > 1. August 21, 2007: Huawei files a patent (CN 200710076523.4) on > using SIP for SIEVE notifications. The inventor is listed as a > single Huawei employee. > > 2. August 30, 2007: That same Huawei employee and two additional > authors publish an IETF draft ( > draft-melnikov-sieve-notify-sip-message-00) on using SIP for > SIEVE notifications. > Correct, except let's call it an "Internet Draft" for precision's sake. > 3. September 2007 - September 2011: The SIEVE working group > discusses and improves the IETF draft. > The draft appears to have been adopted by the WG in December 2008 as draft-ietf-sieve-notify-sip-message-00, but otherwise correct. (See: http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/history/ ) > 4. October 6, 2011: The IESG approves the IETF draft for > publication as an RFC. > > 5. December 14th, 2011: Huawei files an IPR disclosure with the > IETF informing it of patent CN 200710076523.4 > Correct. The dates for the -convert draft (also just re-last called) were slightly different, but the circumstances were largely the same. pr > On 1/25/12 2:17 PM, The IESG wrote: >> The IESG has received a request from the Sieve Mail Filtering Language WG >> (sieve) to consider the following document: >> - 'Sieve Notification Mechanism: SIP MESSAGE' >> 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@ietf.org mailing lists by 2012-02-08. Exceptionally, comments may be >> sent toiesg@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 >> http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/ >> >> >> The following IPR Declarations may be related to this I-D: >> >> http://datatracker.ietf.org/ipr/1658/ >> >> -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 --------------010602010108090808070707 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 1/25/12 3:35 PM, Adam Roach wrote:
Just to make sure I understand the sequence of events:
  1. August 21, 2007: Huawei files a patent (CN 200710076523.4) on using SIP for SIEVE notifications. The inventor is listed as a single Huawei employee.

  2. August 30, 2007: That same Huawei employee and two additional authors publish an IETF draft ( draft-melnikov-sieve-notify-sip-message-00) on using SIP for SIEVE notifications.

Correct, except let's call it an "Internet Draft" for precision's sake.

  1. September 2007 - September 2011: The SIEVE working group discusses and improves the IETF draft.

The draft appears to have been adopted by the WG in December 2008 as draft-ietf-sieve-notify-sip-message-00, but otherwise correct.

(See: http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/history/ )

  1. October 6, 2011: The IESG approves the IETF draft for publication as an RFC.

  2. December 14th, 2011: Huawei files an IPR disclosure with the IETF informing it of patent CN 200710076523.4

Correct.

The dates for the -convert draft (also just re-last called) were slightly different, but the circumstances were largely the same.

pr

On 1/25/12 2:17 PM, The IESG wrote: 
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@ietf.org mailing lists by 2012-02-08. Exceptionally, comments may be
sent to iesg@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
http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/


The following IPR Declarations may be related to this I-D:

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

    

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
--------------010602010108090808070707-- From adam@nostrum.com Wed Jan 25 13:36:00 2012 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBEE11E8098; Wed, 25 Jan 2012 13:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kByVcQUxcqYx; Wed, 25 Jan 2012 13:35:59 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 69B7621F8637; Wed, 25 Jan 2012 13:35:59 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q0PLZww6072081 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 25 Jan 2012 15:35:58 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4F2075BE.5070201@nostrum.com> Date: Wed, 25 Jan 2012 15:35:58 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: ietf@ietf.org References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> In-Reply-To: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------010506060102000406040900" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Wed, 25 Jan 2012 17:51:02 -0800 Cc: sieve@ietf.org, The IESG , IETF-Announce Subject: Re: [sieve] Second Last Call: (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:36:00 -0000 This is a multi-part message in MIME format. --------------010506060102000406040900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Just to make sure I understand the sequence of events: 1. August 21, 2007: Huawei files a patent (CN 200710076523.4) on using SIP for SIEVE notifications. The inventor is listed as a single Huawei employee. 2. August 30, 2007: That same Huawei employee and two additional authors publish an IETF draft ( draft-melnikov-sieve-notify-sip-message-00) on using SIP for SIEVE notifications. 3. September 2007 - September 2011: The SIEVE working group discusses and improves the IETF draft. 4. October 6, 2011: The IESG approves the IETF draft for publication as an RFC. 5. December 14th, 2011: Huawei files an IPR disclosure with the IETF informing it of patent CN 200710076523.4 Is that correct? Am I leaving anything out? /a On 1/25/12 2:17 PM, The IESG wrote: > The IESG has received a request from the Sieve Mail Filtering Language WG > (sieve) to consider the following document: > - 'Sieve Notification Mechanism: SIP MESSAGE' > 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@ietf.org mailing lists by 2012-02-08. Exceptionally, comments may be > sent to iesg@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 > http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/ > > > The following IPR Declarations may be related to this I-D: > > http://datatracker.ietf.org/ipr/1658/ > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --------------010506060102000406040900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Just to make sure I understand the sequence of events:
  1. August 21, 2007: Huawei files a patent (CN 200710076523.4) on using SIP for SIEVE notifications. The inventor is listed as a single Huawei employee.

  2. August 30, 2007: That same Huawei employee and two additional authors publish an IETF draft ( draft-melnikov-sieve-notify-sip-message-00) on using SIP for SIEVE notifications.

  3. September 2007 - September 2011: The SIEVE working group discusses and improves the IETF draft.

  4. October 6, 2011: The IESG approves the IETF draft for publication as an RFC.

  5. December 14th, 2011: Huawei files an IPR disclosure with the IETF informing it of patent CN 200710076523.4

Is that correct? Am I leaving anything out?

/a


On 1/25/12 2:17 PM, The IESG wrote: 
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@ietf.org mailing lists by 2012-02-08. Exceptionally, comments may be
sent to iesg@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
http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/


The following IPR Declarations may be related to this I-D:

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



_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

--------------010506060102000406040900-- From adrian@olddog.co.uk Wed Jan 25 13:51:03 2012 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A38D11E80A6; Wed, 25 Jan 2012 13:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXzq9mBsDjSb; Wed, 25 Jan 2012 13:51:02 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 68A8611E8098; Wed, 25 Jan 2012 13:51:01 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0PLoxMV018421; Wed, 25 Jan 2012 21:50:59 GMT Received: from 950129200 (ixe-nat1.juniper.net [193.110.54.36]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0PLotqK018404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Jan 2012 21:50:57 GMT From: "Adrian Farrel" To: "'Adam Roach'" , References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> In-Reply-To: <4F2075BE.5070201@nostrum.com> Date: Wed, 25 Jan 2012 21:50:52 -0000 Message-ID: <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_033A_01CCDBAB.6BB38740" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ1rN/Cv+EkJDjjOH92vFKPRcb57QJJd//OlLmvmbA= Content-Language: en-gb X-Mailman-Approved-At: Wed, 25 Jan 2012 17:51:01 -0800 Cc: 'The IESG' , sieve@ietf.org, 'IETF-Announce' Subject: Re: [sieve] Second Last Call: (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:51:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_033A_01CCDBAB.6BB38740 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please also see US patent 20090204681 visible at http://ip.com/patapp/US20090204681 In my opinion, this second last call should be suspended until this significant breach of the IETF's IPR policy set out in BCP79 has been resolved. While it is important to find out what the IETF community's view of this situation is, there are two questions: 1. What does the WG think about the I-D being IPR encumbered and do they want to develop an alternate solution that is not encumbered? 2. How will the IETF handle the breach of IPR policy? I believe the document should be returned to the working group who are the main victims of the disruptive behaviour by the author. Thanks, Adrian From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Adam Roach Sent: 25 January 2012 21:36 To: ietf@ietf.org Cc: sieve@ietf.org; The IESG; IETF-Announce Subject: Re: Second Last Call: (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard Just to make sure I understand the sequence of events: 1. August 21, 2007: Huawei files a patent (CN 200710076523.4) on using SIP for SIEVE notifications. The inventor is listed as a single Huawei employee. 2. August 30, 2007: That same Huawei employee and two additional authors publish an IETF draft ( draft-melnikov-sieve-notify-sip-message-00) on using SIP for SIEVE notifications. 3. September 2007 - September 2011: The SIEVE working group discusses and improves the IETF draft. 4. October 6, 2011: The IESG approves the IETF draft for publication as an RFC. 5. December 14th, 2011: Huawei files an IPR disclosure with the IETF informing it of patent CN 200710076523.4 Is that correct? Am I leaving anything out? /a On 1/25/12 2:17 PM, The IESG wrote: The IESG has received a request from the Sieve Mail Filtering Language WG (sieve) to consider the following document: - 'Sieve Notification Mechanism: SIP MESSAGE' 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@ietf.org mailing lists by 2012-02-08. Exceptionally, comments may be sent to iesg@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 http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1658/ _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ------=_NextPart_000_033A_01CCDBAB.6BB38740 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please also see US patent = 20090204681 visible at  http://ip.com/patapp/US2009020468= 1

 

In my opinion, this second = last call should be suspended until this significant breach of the = IETF's IPR policy set out in BCP79 has been = resolved.

 

While it is important to find = out what the IETF community's view of this situation is, there are two = questions:

 

1. What does the WG think = about the I-D being IPR encumbered and do they want to develop an = alternate solution that is not encumbered?

 

2. How will the IETF handle = the breach of IPR policy?

 

I believe the document should = be returned to the working group who are the main victims of the = disruptive behaviour by the author.

 

Thanks,

Adrian

 

From: = ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of = Adam Roach
Sent: 25 January 2012 21:36
To: = ietf@ietf.org
Cc: sieve@ietf.org; The IESG; = IETF-Announce
Subject: Re: Second Last Call: = <draft-ietf-sieve-notify-sip-message-08.txt> (Sieve Notification = Mechanism: SIP MESSAGE) to Proposed = Standard

 

Just to make sure I = understand the sequence of events:

  1. August 21, 2007: = Huawei files a patent (CN 200710076523.4) on using SIP for SIEVE = notifications. The inventor is listed as a single Huawei = employee.
  2. August 30, 2007: = That same Huawei employee and two additional authors publish an IETF = draft ( draft-melnikov-sieve-notify-sip-message-00) on using SIP for = SIEVE notifications.
  3. September 2007 - = September 2011: The SIEVE working group discusses and improves the IETF = draft.
  4. October 6, 2011: The = IESG approves the IETF draft for publication as an = RFC.
  5. December 14th, 2011: = Huawei files an IPR disclosure with the IETF informing it of patent CN = 200710076523.4


Is that correct? = Am I leaving anything out?

/a


On 1/25/12 2:17 PM, The = IESG wrote: 

 
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@ietf.org mailing lists by =
2012-02-08. Exceptionally, comments may be
sent to =
iesg@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
http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/=

 
 
The following IPR Declarations may be related to this =
I-D:
 
   http://datatracker.ietf.or=
g/ipr/1658/
 
&nb=
sp;
 
_________________________=
______________________
IETF-Announce mailing =
list
IETF-Announce@ietf.org
https://www.=
ietf.org/mailman/listinfo/ietf-announce
 
------=_NextPart_000_033A_01CCDBAB.6BB38740-- From tnadeau@lucidvision.com Wed Jan 25 14:05:52 2012 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0487E11E80A6; Wed, 25 Jan 2012 14:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0JYTHDNsdgw; Wed, 25 Jan 2012 14:05:51 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id D5EB411E807A; Wed, 25 Jan 2012 14:05:49 -0800 (PST) Received: from [192.168.1.94] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 1540D2061BC7; Wed, 25 Jan 2012 17:05:49 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_C4ED6030-4854-4019-BCFC-9CF0133DD12A" From: Thomas Nadeau In-Reply-To: <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk> Date: Wed, 25 Jan 2012 17:05:48 -0500 Message-Id: References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Wed, 25 Jan 2012 17:51:02 -0800 Cc: sieve@ietf.org, 'The IESG' , 'Adam Roach' , ietf@ietf.org, 'IETF-Announce' Subject: Re: [sieve] Second Last Call: (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 22:05:52 -0000 --Apple-Mail=_C4ED6030-4854-4019-BCFC-9CF0133DD12A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Agree %100. On Jan 25, 2012, at 4:50 PM, Adrian Farrel wrote: > Please also see US patent 20090204681 visible at = http://ip.com/patapp/US20090204681 > =20 > In my opinion, this second last call should be suspended until this = significant breach of the IETF's IPR policy set out in BCP79 has been = resolved. > =20 > While it is important to find out what the IETF community's view of = this situation is, there are two questions: > =20 > 1. What does the WG think about the I-D being IPR encumbered and do = they want to develop an alternate solution that is not encumbered? > =20 > 2. How will the IETF handle the breach of IPR policy? > =20 > I believe the document should be returned to the working group who are = the main victims of the disruptive behaviour by the author. > =20 > Thanks, > Adrian > =20 > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf = Of Adam Roach > Sent: 25 January 2012 21:36 > To: ietf@ietf.org > Cc: sieve@ietf.org; The IESG; IETF-Announce > Subject: Re: Second Last Call: = (Sieve Notification = Mechanism: SIP MESSAGE) to Proposed Standard > =20 > Just to make sure I understand the sequence of events: > August 21, 2007: Huawei files a patent (CN 200710076523.4) on using = SIP for SIEVE notifications. The inventor is listed as a single Huawei = employee. > August 30, 2007: That same Huawei employee and two additional authors = publish an IETF draft ( draft-melnikov-sieve-notify-sip-message-00) on = using SIP for SIEVE notifications. > September 2007 - September 2011: The SIEVE working group discusses and = improves the IETF draft. > October 6, 2011: The IESG approves the IETF draft for publication as = an RFC. > December 14th, 2011: Huawei files an IPR disclosure with the IETF = informing it of patent CN 200710076523.4 >=20 > Is that correct? Am I leaving anything out? >=20 > /a >=20 >=20 > On 1/25/12 2:17 PM, The IESG wrote: > =20 > The IESG has received a request from the Sieve Mail Filtering Language = WG > (sieve) to consider the following document: > - 'Sieve Notification Mechanism: SIP MESSAGE' > as a Proposed Standard > =20 > 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: > =20 > https://datatracker.ietf.org/ipr/1658/ > =20 > 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@ietf.org mailing lists by 2012-02-08. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > =20 > Abstract > =20 > =20 > This document describes a profile of the Sieve extension for > notifications, to allow notifications to be sent over SIP MESSAGE. > =20 > =20 > =20 > =20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/ > =20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/ > =20 > =20 > The following IPR Declarations may be related to this I-D: > =20 > http://datatracker.ietf.org/ipr/1658/ > =20 > =20 > =20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > =20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf --Apple-Mail=_C4ED6030-4854-4019-BCFC-9CF0133DD12A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Agree %100.


On Jan = 25, 2012, at 4:50 PM, Adrian Farrel wrote:

From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org= ] On Behalf Of Adam = Roach
Sent: 25= January 2012 21:36
To: ietf@ietf.org
Cc: sieve@ietf.org; The IESG; = IETF-Announce
Subject: Re: Second Last Call: = <draft-ietf-sieve-notify-sip-message-08.txt> (Sieve Notification = Mechanism: SIP MESSAGE) to Proposed = Standard
Just to = make sure I understand the sequence of = events:
  1. August 21, 2007: Huawei files a patent (CN = 200710076523.4) on using SIP for SIEVE notifications. The inventor is = listed as a single Huawei employee.
  2. August 30, 2007: That = same Huawei employee and two additional authors publish an IETF draft ( = draft-melnikov-sieve-notify-sip-message-00) on using SIP for SIEVE = notifications.
  3. September 2007 - September 2011: The SIEVE = working group discusses and improves the IETF = draft.
  4. December 14th, 2011: Huawei files = an IPR disclosure with the IETF informing it of patent CN = 200710076523.4
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:
 
 
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@ietf.org mailing lists by 2012-02-08. =
Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain =
the
beginning of the Subject line to allow =
automated sorting.
 
 
   =
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
 
IESG discussion can be tracked via
 
 
The following IPR =
Declarations may be related to this I-D:
 
   =
 
 
IETF-Announce mailing list
Ietf@ietf.org

To: "adrian@olddog.co.uk" , 'Adam Roach' , "ietf@ietf.org" 
Date: Wed, 25 Jan 2012 17:39:43 -0500
Thread-Topic: Second Last Call:	 (Sieve	Notification Mechanism: SIP MESSAGE) to Proposed Standard
Thread-Index: AQJ1rN/Cv+EkJDjjOH92vFKPRcb57QJJd//OlLmvmbCAAA3hQA==
Message-ID: 
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com>, <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>
In-Reply-To: <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 25 Jan 2012 17:51:02 -0800
Cc: "sieve@ietf.org" 
Subject: Re: [sieve] Second Last Call:		(Sieve	Notification Mechanism: SIP MESSAGE) to Proposed Standard
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Jan 2012 22:39:55 -0000

> From: Adrian Farrel [adrian@olddog.co.uk]
>=20
> In my opinion, this second last call should be suspended until this
> significant breach of the IETF's IPR policy set out in BCP79 has been
> resolved.
> [...]
> I believe the document should be returned to the working group who are
> the main victims of the disruptive behaviour by the author.

If the facts are as outlined by Adam Roach, this is the only thing to do.

Dale

From sm@resistor.net  Wed Jan 25 20:53:39 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37D921F859E; Wed, 25 Jan 2012 20:53:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.62
X-Spam-Level: 
X-Spam-Status: No, score=-102.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fI7W3muyekuJ; Wed, 25 Jan 2012 20:53:38 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A893C21F859B; Wed, 25 Jan 2012 20:53:38 -0800 (PST)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0Q4rU9u027776; Wed, 25 Jan 2012 20:53:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327553617; i=@resistor.net; bh=sNYyDvrEhnaFfqYgD4yL9jikXh4IQIJxK5RZFaQ5XPU=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=yJX7gYm6psjtXZgt/xE1CkhAxzNZSN5E3POu2Bomz9+qZvkUP+MkL9qAt52M7mibw /1ua/1NdezHuMeoAMHBi+nwMPvu69pJgzRWkVeHyboZEBJtzASRHtaToazgB+EWAv/ h5gNcQfGJyRsdjFw6O194hMoVOB1Vl57axIef5GE=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327553617; i=@resistor.net; bh=sNYyDvrEhnaFfqYgD4yL9jikXh4IQIJxK5RZFaQ5XPU=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=nuk5bIaiacq+AwVaWS7evn1bBBGqetWtU6O0YJheHghzhcKuvb/vkmk65KBD3tCbD f1rqCvRkcLiXf6DDpjmgEmtuoFT9H1BmGzk6mdlYOfz5rb/q8xkF6pT7COFVM6qEuI G/SpRLwM6MKn5Bk6Lhrv7fF12acmDyxpLPPPhAGI=
Message-Id: <6.2.5.6.2.20120125181850.0995e2d0@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 25 Jan 2012 20:41:54 -0800
To: Pete Resnick 
From: SM 
In-Reply-To: <4F20AF20.40103@qualcomm.com>
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <4F20AF20.40103@qualcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: sieve@ietf.org, ietf@ietf.org
Subject: [sieve] Violation of IETF process (was: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard)
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 04:53:39 -0000

At 17:40 25-01-2012, Pete Resnick wrote:
>Correct, except let's call it an "Internet Draft" for precision's sake.

What this thread is actually about is a violation of IETF process 
(BCP) or IETF policy (Failure to comply with patent disclosure 
requirements is a violation of IETF policy, and the potential legal 
consequences to companies are considerable).

For context:

   "Qian Sun is apparently no longer an active IETF participant, and his
    co-workers who are active IETF participants asked their company to
    disclose against the two documents as soon as they discovered what
    had happened. That's where were are now."

Regards,
-sm 


From sm@resistor.net  Thu Jan 26 00:02:04 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0ABA11E8083; Thu, 26 Jan 2012 00:02:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.619
X-Spam-Level: 
X-Spam-Status: No, score=-102.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRklKlBgkn8x; Thu, 26 Jan 2012 00:02:02 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9613311E8075; Thu, 26 Jan 2012 00:02:02 -0800 (PST)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0Q81tu7001865; Thu, 26 Jan 2012 00:01:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327564921; i=@resistor.net; bh=3NyfV2Hx8FASqeKNnTIjj6bRYBJ8WeVkMtyXtQtGIZw=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=0DF4pQdOhowivAmONBj2NFqhCDt7I/Yo0EtUwa48YAmmuabz7CaVxtzedU/WjHHfT eVl3JKLkeK4vEMssCDwrGK55Gx6WQobFCJ7EizAoSoaHI4qsrFSfpqBlex8lpKmX+E +O3qhq27XxHqHglKYVAqdUQpGtN7CYYc6FT1kMMU=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327564921; i=@resistor.net; bh=3NyfV2Hx8FASqeKNnTIjj6bRYBJ8WeVkMtyXtQtGIZw=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=FnPkwuUGptVVF5ExB3HgwDL7OY0jU00nJvPtejLG1cs5ybYNuoyVsVCBxzqBpDOAz wgcWd4MqrsdaNlBut0rlxEoWF4GZ4A8rtevofFpX57Sn2UZmfDNf8RYfgK/a4QigQ6 FfFOgWrL0Ca6M5iu35BKNJGT4816JcjxgebyW3Sc=
Message-Id: <6.2.5.6.2.20120125215449.0c092680@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 25 Jan 2012 23:57:36 -0800
To: adrian@olddog.co.uk
From: SM 
In-Reply-To: <03de01ccdbee$33ce28b0$9b6a7a10$@olddog.co.uk>
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <4F20AF20.40103@qualcomm.com> <6.2.5.6.2.20120125181850.0995e2d0@resistor.net> <03de01ccdbee$33ce28b0$9b6a7a10$@olddog.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: sieve@ietf.org, ietf@ietf.org
Subject: Re: [sieve] Violation of IETF process (was: Second Last Call:	 (Sieve Notification	Mechanism: SIP MESSAGE) to Proposed Standard)
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 08:02:05 -0000

Hi Adrian,
At 21:48 25-01-2012, Adrian Farrel wrote:
>Why is Qian Sun still listed on the front page as an author. 
>Wouldn't it be more
>appropriate to move the name to the Acknowledgements section where the text
>could read...

As editorship is a WG Chair decision, it is up to the SIEVE WG Chairs 
to comment on why Qian Sun is still listed on the front page as an author.

>Some of the text of this document was provided by Qian Sun who 
>violated IETF IPR
>process by not disclosing related IPR that he had also authored and so is not
>listed as a named author of this document.

The above text does not mention company affiliation.

There is the following in the text in IPR statements:

   "Note: The individual submitting this template represents and
    warrants that he or she is authorized by the Patent Holder to
    agree to the above-selected licensing declaration."

The name provided in the IPR statement is "Director of licensing".

The violation has a negative impact on the IETF (see comment from 
Dave Crocker on this thread).  It raises questions which should not be asked.

Regards,
-sm 


From harald@alvestrand.no  Thu Jan 26 03:32:33 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D066221F867F; Thu, 26 Jan 2012 03:32:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.488
X-Spam-Level: 
X-Spam-Status: No, score=-110.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTuNO1Zq7jgl; Thu, 26 Jan 2012 03:32:33 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CFC5B21F864E; Thu, 26 Jan 2012 03:32:32 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 873DD39E149; Thu, 26 Jan 2012 12:32:31 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0+k-5YHScqS; Thu, 26 Jan 2012 12:32:31 +0100 (CET)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 0187839E04C; Thu, 26 Jan 2012 12:32:30 +0100 (CET)
Message-ID: <4F2139CE.3010508@alvestrand.no>
Date: Thu, 26 Jan 2012 12:32:30 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16
MIME-Version: 1.0
To: John C Klensin 
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com>	<4F2075BE.5070201@nostrum.com>	, <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>		<4F208AEF.5060406@qualcomm.com> <9E8747DFE73501D34065351E@PST.JCK.COM>
In-Reply-To: <9E8747DFE73501D34065351E@PST.JCK.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Pete Resnick , adrian@olddog.co.uk, sieve@ietf.org, ietf@ietf.org
Subject: Re: [sieve] Second Last	Call:	 (Sieve	Notifica	tion Mechanism: SIP MESSAGE) to Proposed Standard
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 11:32:34 -0000

John,

a worry I have with going out with such a massive demand set for this 
IPR code violation is that we'd be encouraging the other IPR behaviour 
we've seen: That of saying nothing.

The current Huawei people who caused this disclosure to be filed deserve 
our praise for doing the Right Thing now, even while the people in the 
past who did not deserve our condemnation.

On one point, however, I'm aligned:

On 01/26/2012 10:31 AM, John C Klensin wrote:
>
> (3) A request to the company involved to remove the reciprocity
> clause from the license stated in the disclosure statement.  As
> a show of good faith, they should agree to derive no benefit
> from the patent other than what praise accrues from having it
> awarded.
Indeed, this reciprocity clause is of the form that I used to complain 
to Cisco's IPR lawyer about Cisco making when I was at Cisco: It asserts 
the right of withdrawal of this license for *any* use of *any* patent 
against Huawei - that means that anyone who dares to depend on this 
license is effectively granting a license to *all* their patents to the 
holder of this patent.

The proper scope of reciprocity clauses is a fertile ground for debate 
(and nearly impossible to hold a debate on, unfortunately), but this 
type is one that I am not happy to see.

                       Harald


From john-ietf@jck.com  Thu Jan 26 01:31:44 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E104521F869F; Thu, 26 Jan 2012 01:31:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZUfuq6FxmyY; Thu, 26 Jan 2012 01:31:44 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3D29921F869D; Thu, 26 Jan 2012 01:31:44 -0800 (PST)
Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1RqLck-00059A-3M; Thu, 26 Jan 2012 04:28:06 -0500
Date: Thu, 26 Jan 2012 04:31:34 -0500
From: John C Klensin 
To: Pete Resnick 
Message-ID: <9E8747DFE73501D34065351E@PST.JCK.COM>
In-Reply-To: <4F208AEF.5060406@qualcomm.com>
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> ,	<033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Mailman-Approved-At: Thu, 26 Jan 2012 07:54:08 -0800
Cc: adrian@olddog.co.uk, sieve@ietf.org, ietf@ietf.org
Subject: Re: [sieve] Second Last Call:		(Sieve	Notifica tion Mechanism: SIP MESSAGE) to Proposed Standard
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 09:31:45 -0000

--On Wednesday, January 25, 2012 17:06 -0600 Pete Resnick
 wrote:

>...
> Before posting this Last Call (and the similar one for
> draft-ietf-sieve-convert), the documents *were* returned to
> the SIEVE WG to review the situation. With minimal complaint
> from the WG and no indication that the WG wished to change
> their decision on the documents, the chairs asked that I
> simply put it to the entire community as a Last Call. So I
> believe anything other than "go ahead with publication as is"
> will be done only if that is the consensus of the IETF
> community as a whole. The SIEVE chairs and I will be
> monitoring the discussion.

Pete,

(responding to this message, but I've read the subsequent ones)

It seems to me that a key question here is whether the original
author's decision to not disclose was made in violation of
company policy or whether the sequence of posting the I-D,
getting the document through the WG and Last Call, and then
posting the disclosure is a matter of company policy.  If such
behavior became a pattern, the IETF's IPR policy would be
essentially dead.

I believe that "go ahead with publication as is" would be
equivalent to encouraging such a pattern to develop and is
consequently not acceptable.

Consequently, I believe that at least the following should be
required:

(1) Revision of the IPR statement so it identifies the
responsible individual by name, department, and title.  I do not
believe that the rather anonymous "Director of Licensing" is
compliant with the intent of the IPR disclosure rules.   I will
leave it to the lawyers to advise on whether a document issued
without the name (not just title) of a responsible individual
would even be held to be valid in the various jurisdictions in
which the patent might be recognized.

(2) A request to the company involved for someone who can
formally speak for that company to publicly clarify that this
sequence of behavior occurred in violation of company policy.
If there are internal rewards to individuals for filing and/or
being awarded patents, I assume that a decision that the actions
violate company policy would cause such awards to be withheld in
this case, even though the IETF would have no way to verify
whether or not that occurred.

(3) A request to the company involved to remove the reciprocity
clause from the license stated in the disclosure statement.  As
a show of good faith, they should agree to derive no benefit
from the patent other than what praise accrues from having it
awarded.

(4) Removal of the offending individual from the list of authors
to the acknowledgments with text similar to that suggested by
Adrian.  Unless the company involved is willing to provide the
clarification suggested in (2) above, and possibly the license
modification suggested in (3) above, all names of authors
associated with that company should be removed to the
acknowledgements and the company affiliation explicitly
identified there.  In either case, this should be viewed as a
response to a policy violation and not entangled with any more
general discussion of listed authors on I-Ds or RFCs.

(5) Unless the clarification suggested in (2) can be provided,
each IETF participant who is associated with the relevant
company and who is in an IETF-related leadership or
decision-making position (WG Chairs; Editors; IESG, IAB, IAOC,
Nomcom, members; etc.) should be asked to make a conscientious
personal review as to whether this type of action sufficiently
compromises his or her position that resignation or some other
action would be appropriate and, as appropriate, to review IETF
policies with whatever management chains are relevant.  I am
_not_ suggesting that anyone be asked to resign, only that they
engage in careful consideration of the issues and their
implications.

Just my opinion.
regards,

    john


From adam@nostrum.com  Wed Jan 25 19:44:19 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5942221F8634; Wed, 25 Jan 2012 19:44:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRnX1lrQUW7k; Wed, 25 Jan 2012 19:44:18 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id BB2CB21F8623; Wed, 25 Jan 2012 19:44:15 -0800 (PST)
Received: from hydra-en0.roach.at (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q0Q3iDCB027339 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 25 Jan 2012 21:44:14 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <4F20CC0D.7080502@nostrum.com>
Date: Wed, 25 Jan 2012 21:44:13 -0600
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: adrian@olddog.co.uk
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>
In-Reply-To: <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>
Content-Type: multipart/alternative; boundary="------------080001000700090806090408"
Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism)
X-Mailman-Approved-At: Thu, 26 Jan 2012 07:54:10 -0800
Cc: sieve@ietf.org, ietf@ietf.org
Subject: Re: [sieve] Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 03:44:19 -0000

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

On 1/25/12 15:50, Jan 25, Adrian Farrel wrote:
>
> Please also see US patent 20090204681 visible at 
> http://ip.com/patapp/US20090204681
>
Well, at least U.S. patent application. And, for that matter, 
International Application PCT/CN2008/072066:

   http://www.wipo.int/patentscope/search/en/WO2009024088

The geographic scope of the intended patent protection for this 
invention appears to be broader than was revealed by the IPR disclosure.

/a

--------------080001000700090806090408
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    On 1/25/12 15:50, Jan 25, Adrian Farrel wrote:
    

      
      
      
      
      
      
      
      

        
Please also see US patent 20090204681 visible at
             http://ip.com/patapp/US20090204681
          

      

    

    Well, at least U.S. patent application. And, for that matter,
    International Application PCT/CN2008/072066:

    

      http://www.wipo.int/patentscope/search/en/WO2009024088

    

    The geographic scope of the intended patent protection for this
    invention appears to be broader than was revealed by the IPR
    disclosure.

    

    /a

  


--------------080001000700090806090408--

From adrian@olddog.co.uk  Wed Jan 25 21:49:04 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6290021F8600; Wed, 25 Jan 2012 21:49:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5aMNwq3LTKG; Wed, 25 Jan 2012 21:49:03 -0800 (PST)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 8099421F85FF; Wed, 25 Jan 2012 21:49:03 -0800 (PST)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0Q5n1NH017854;  Thu, 26 Jan 2012 05:49:01 GMT
Received: from 950129200 (50-76-52-225-ip-static.hfc.comcastbusiness.net [50.76.52.225]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0Q5muCO017829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Jan 2012 05:48:59 GMT
From: "Adrian Farrel" 
To: "'SM'" , "'Pete Resnick'" 
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com>	<4F2075BE.5070201@nostrum.com> <4F20AF20.40103@qualcomm.com> <6.2.5.6.2.20120125181850.0995e2d0@resistor.net>
In-Reply-To: <6.2.5.6.2.20120125181850.0995e2d0@resistor.net>
Date: Thu, 26 Jan 2012 05:48:55 -0000
Message-ID: <03de01ccdbee$33ce28b0$9b6a7a10$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ1rN/Cv+EkJDjjOH92vFKPRcb57QJJd//OAalY3MwBxFrssZSeyD0w
Content-Language: en-gb
X-Mailman-Approved-At: Thu, 26 Jan 2012 07:54:10 -0800
Cc: sieve@ietf.org, ietf@ietf.org
Subject: Re: [sieve] Violation of IETF process (was: Second Last Call:	 (Sieve Notification	Mechanism: SIP MESSAGE) to Proposed Standard)
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 05:49:04 -0000

All that is great.

Why is Qian Sun still listed on the front page as an author. Wouldn't it be more
appropriate to move the name to the Acknowledgements section where the text
could read...

Some of the text of this document was provided by Qian Sun who violated IETF IPR
process by not disclosing related IPR that he had also authored and so is not
listed as a named author of this document.

Adrian

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of SM
> Sent: 26 January 2012 04:42
> To: Pete Resnick
> Cc: sieve@ietf.org; ietf@ietf.org
> Subject: Violation of IETF process (was: Second Last Call:
 sip-message-08.txt> (Sieve Notification Mechanism: SIP MESSAGE) to Proposed
> Standard)
> 
> At 17:40 25-01-2012, Pete Resnick wrote:
> >Correct, except let's call it an "Internet Draft" for precision's sake.
> 
> What this thread is actually about is a violation of IETF process
> (BCP) or IETF policy (Failure to comply with patent disclosure
> requirements is a violation of IETF policy, and the potential legal
> consequences to companies are considerable).
> 
> For context:
> 
>    "Qian Sun is apparently no longer an active IETF participant, and his
>     co-workers who are active IETF participants asked their company to
>     disclose against the two documents as soon as they discovered what
>     had happened. That's where were are now."
> 
> Regards,
> -sm
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf


From dhc@dcrocker.net  Wed Jan 25 22:12:58 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532FD5E8002; Wed, 25 Jan 2012 22:12:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.67
X-Spam-Level: 
X-Spam-Status: No, score=-6.67 tagged_above=-999 required=5 tests=[AWL=-0.071,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e01KwhBhNbHI; Wed, 25 Jan 2012 22:12:57 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 160245E8001; Wed, 25 Jan 2012 22:12:57 -0800 (PST)
Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0Q6CoUk027481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2012 22:12:55 -0800
Message-ID: <4F20EEDD.5040605@dcrocker.net>
Date: Wed, 25 Jan 2012 22:12:45 -0800
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: ietf@ietf.org
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>
In-Reply-To: <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 25 Jan 2012 22:12:56 -0800 (PST)
X-Mailman-Approved-At: Thu, 26 Jan 2012 07:54:10 -0800
Cc: sieve@ietf.org, 'The IESG' , 'IETF-Announce' 
Subject: Re: [sieve] Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 06:12:58 -0000

On 1/25/2012 1:50 PM, Adrian Farrel wrote:
> I believe the document should be returned to the working group who are the main
> victims of the disruptive behaviour by the author.


The working group might be the closest and could reasonably have the highest 
sense of frustration -- Pete's later posting notwithstanding -- but forgive my 
noting that they are not the main victims.

Variously the IETF and the Internet community are the main victims.  The IETF 
for the rather sustained violation of its policies and the Internet community 
for the delay in being able to use a mechanism that presumably would be useful.

Somehow, an apology does not seem sufficient.  Something more substantial is 
warranted.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From bob.hinden@gmail.com  Thu Jan 26 05:52:52 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD6321F85AA; Thu, 26 Jan 2012 05:52:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.572
X-Spam-Level: 
X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5F1EPSX+Pp0y; Thu, 26 Jan 2012 05:52:52 -0800 (PST)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 153E621F859B; Thu, 26 Jan 2012 05:52:52 -0800 (PST)
Received: by pbdu7 with SMTP id u7so266172pbd.31 for ; Thu, 26 Jan 2012 05:52:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=fQmL6GWsmjXqUMiYZ8sV+V8w+VDdA8wEIdFnkch0ccM=; b=hRjalfB59Op9sptQbHtLu88DWn51Ua32VHx1ySvCgUi3COgQC+nRjiw3RS8CWP6i+Z zMFSSKyQZ/g21jT40nteDb5GUbRbZ5Vh6eMjHy64g1w42HIjyrXyXSG0lhuw2hxQC6iD sNJXsn25qa9ypi0H1a6Svb8T7qN2P57P7b/+s=
Received: by 10.68.74.132 with SMTP id t4mr5460632pbv.22.1327585971889; Thu, 26 Jan 2012 05:52:51 -0800 (PST)
Received: from [172.240.6.218] (201.166.23.218.cable.dyn.cableonline.com.mx. [201.166.23.218]) by mx.google.com with ESMTPS id t5sm11491666pbn.3.2012.01.26.05.52.49 (version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 05:52:51 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Bob Hinden 
In-Reply-To: <4F20EEDD.5040605@dcrocker.net>
Date: Thu, 26 Jan 2012 07:52:47 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <20DB0302-3267-4928-95C0-D85F264E2876@gmail.com>
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk> <4F20EEDD.5040605@dcrocker.net>
To: dcrocker@bbiw.net
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Thu, 26 Jan 2012 07:54:09 -0800
Cc: sieve@ietf.org, The IESG , Bob Hinden , ietf@ietf.org
Subject: Re: [sieve] Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 13:52:53 -0000

On Jan 26, 2012, at 12:12 AM, Dave CROCKER wrote:

>=20
>=20
> On 1/25/2012 1:50 PM, Adrian Farrel wrote:
>> I believe the document should be returned to the working group who =
are the main
>> victims of the disruptive behaviour by the author.
>=20
>=20
> The working group might be the closest and could reasonably have the =
highest sense of frustration -- Pete's later posting notwithstanding -- =
but forgive my noting that they are not the main victims.
>=20
> Variously the IETF and the Internet community are the main victims.  =
The IETF for the rather sustained violation of its policies and the =
Internet community for the delay in being able to use a mechanism that =
presumably would be useful.

+1

Bob


>=20
> Somehow, an apology does not seem sufficient.  Something more =
substantial is warranted.
>=20
> d/
> --=20
>=20
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf


From john-ietf@jck.com  Thu Jan 26 06:08:19 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A587D21F8665; Thu, 26 Jan 2012 06:08:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qf8tY5nbobu5; Thu, 26 Jan 2012 06:08:18 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id B94FE21F8630; Thu, 26 Jan 2012 06:08:18 -0800 (PST)
Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1RqPwI-0005Ts-GC; Thu, 26 Jan 2012 09:04:34 -0500
Date: Thu, 26 Jan 2012 09:08:04 -0500
From: John C Klensin 
To: Harald Alvestrand 
Message-ID: 
In-Reply-To: <4F2139CE.3010508@alvestrand.no>
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> ,	<033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com> <9E8747DFE73501D34065351E@PST.JCK.COM> <4F2139CE.3010508@alvestrand.no>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Mailman-Approved-At: Thu, 26 Jan 2012 07:54:09 -0800
Cc: Pete Resnick , adrian@olddog.co.uk, sieve@ietf.org, ietf@ietf.org
Subject: Re: [sieve] Second Last	Call:		(Sieve	Not ifica	tion Mechanism: SIP MESSAGE) to Proposed Standard
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 14:08:19 -0000

--On Thursday, January 26, 2012 12:32 +0100 Harald Alvestrand
 wrote:

> John,
> 
> a worry I have with going out with such a massive demand set
> for this IPR code violation is that we'd be encouraging the
> other IPR behaviour we've seen: That of saying nothing.

I understand this concern, but that takes us into lawyer
territory.  Since the courts, at least in some countries, have
ruled that patents are unenforceable if the technology was
pushed forward into standards in violation of disclosure rules
(that is a deliberately-vague summary, not an attempt to state
the legal situation), I don't know if companies would be better
off saying nothing, ever, until they ambushed someone in court,
or disclosing later.  If the IETF needs to make decisions on
that basis, I'd like us to get clear advice (if such a thing is
possible -- a combination about the situation, not the source of
advice) from Counsel.

> The current Huawei people who caused this disclosure to be
> filed deserve our praise for doing the Right Thing now, even
> while the people in the past who did not deserve our
> condemnation.

Absolutely.  While I recognize it as difficult, that is
precisely why I'd like to have Huawei clarify that those who did
not disclose in the past did so in violation of what I hope is
the company policy to conform to the rules of any standards body
in which their employees are participating.  If that is actually
the case (as I assume it is), then my proposed "demand set" is
not "massive": we adjust the authorship to remove the inventor,
we try to get the reciprocity clause narrowed or removed, and we
move on.  

The question of whether the IETF should accept and file a
disclosure statement that is "signed" only by title, especially
a title whose meaning is unclear outside the particular company,
ought to be largely separate from this discussion: it is really
an issue that I'd hope that the IETF Trust would discuss with
Counsel and then appropriately advise the Secretariat and the
community about how such statements should be handled.  If we
actually don't have any rules or guidance today, it may be
unreasonable to ask Huawei to amend their filing on that basis.

Note that removing the broad reciprocity provision from this
particular IPR disclosure /licensing statement ought to be less
problematic from Huawei's standpoint than potentially having the
patent (and potentially related ones) invalidated or rendered
unenforceable -- an action that would be completely outside our
control.

> On one point, however, I'm aligned:
> 
> On 01/26/2012 10:31 AM, John C Klensin wrote:
>> 
>> (3) A request to the company involved to remove the
>> reciprocity clause from the license stated in the disclosure
>> statement.  As a show of good faith, they should agree to
>> derive no benefit from the patent other than what praise
>> accrues from having it awarded.
> Indeed, this reciprocity clause is of the form that I used to
> complain to Cisco's IPR lawyer about Cisco making when I was
> at Cisco: It asserts the right of withdrawal of this license
> for *any* use of *any* patent against Huawei - that means that
> anyone who dares to depend on this license is effectively
> granting a license to *all* their patents to the holder of
> this patent.

> The proper scope of reciprocity clauses is a fertile ground
> for debate (and nearly impossible to hold a debate on,
> unfortunately), but this type is one that I am not happy to
> see.

While I agree, I think it is a separate discussion.  That
discussion probably needs to start with a core principle of the
IETF IPR policy that we do not constrain the conditions that can
be adopted and disclosed at all.  If we are not going to change
that, then Huawei (or Cisco, or many others) are certainly
permitted to insert such a clause.  If there is a problem in the
IETF, it is only that WGs may not have been sufficiently
diligent about evaluating the possible effects of such
provisions on the practice of potentially-standard technologies.


I think that, for this situation and any that might be similar
to it in the future, we need to concentrate on the particulars
of the situation and the degree to which it is appropriate for a
company to benefit from the inappropriate behavior of someone
who presumably works for them, is being sponsored by them to
participate in the IETF, etc.  I deliberately wrote my note so
that it could evolve into a general set of guidelines on such
issues should the community think that appropriate.

I'm also conflicted about the information (or lack thereof) that
we have available.  My personal sense of justice says that we
should really understand, for example, whether there is any
chance that the inventor was not aware of the patent
application.  Others have made similar suggestions.  On the
other hand, it is possible that trying to dig out and evaluate
that information would turn this situation into far more of a
judicial-like provision than I'm comfortable with.  Again,
advice from the Trust and Counsel would be very much in order if
it is feasible (and the reasons would be interesting and useful
information if it is not).

    john


    




From adrian@olddog.co.uk  Thu Jan 26 07:26:03 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3934B21F869E; Thu, 26 Jan 2012 07:26:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdDYmcZpYN-R; Thu, 26 Jan 2012 07:26:02 -0800 (PST)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCB921F869C; Thu, 26 Jan 2012 07:26:02 -0800 (PST)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0QFQ0eo016963;  Thu, 26 Jan 2012 15:26:00 GMT
Received: from 950129200 (50-76-52-225-ip-static.hfc.comcastbusiness.net [50.76.52.225]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0QFPv7q016951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Jan 2012 15:25:59 GMT
From: "Adrian Farrel" 
To: "'SM'" 
Date: Thu, 26 Jan 2012 15:25:55 -0000
Message-ID: <007f01ccdc3e$ce46a0c0$6ad3e240$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AczcPsfLBlK92TXNQSiBzRJyVE+x8A==
Content-Language: en-gb
X-Mailman-Approved-At: Thu, 26 Jan 2012 07:54:10 -0800
Cc: sieve@ietf.org, ietf@ietf.org
Subject: Re: [sieve] Violation of IETF process (was: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard)
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 15:26:03 -0000

> >Why is Qian Sun still listed on the front page as an author.
> >Wouldn't it be more
> >appropriate to move the name to the Acknowledgements section where the
> > text could read...
> 
> As editorship is a WG Chair decision, it is up to the SIEVE WG Chairs
> to comment on why Qian Sun is still listed on the front page as an author.
> 
> >Some of the text of this document was provided by Qian Sun who
> > violated IETF IPR process by not disclosing related IPR that he had
> > also authored and so is not listed as a named author of this document.
> 
> The above text does not mention company affiliation.

I have not made any statement about what the company has done.

> There is the following in the text in IPR statements:
> 
>    "Note: The individual submitting this template represents and
>     warrants that he or she is authorized by the Patent Holder to
>     agree to the above-selected licensing declaration."
> 
> The name provided in the IPR statement is "Director of licensing".

I don't view *disclosing* as a problem here. In fact disclosure is to be
encouraged.

My issue is with the individual. BCP 79 is very clear about individual
responsibilities wrt IPR that they are aware of.

It is the individual who breaks the IETF's IPR policy if they make contributions
when there is IPR that they are aware of that is not disclosed in a timely
fashion.

> The violation has a negative impact on the IETF (see comment from
> Dave Crocker on this thread).  It raises questions which should not be asked.

Questions that should not be asked should not, by definition, be asked.
I wonder if you are concerned about corporate and anti-trust issues.

AFAICS, this issue has nothing to do with that.

I do agree that sanctions applied to individuals should be proportionate and
should consider the circumstances. 

I am also interested in the discussion about whether moving an author's name
from the front page to the Acknowledgements (with an explanation) would have an
impact on discussions of IPR policy violation in court. This will need
professional legal advice - my feeling was that previous I-D versions would
still show the author as previously listed (including the revision of the I-D at
the time the IPR was disclosed), and that the note in the Acknowledgements
section and the discussion on IETF lists (e.g. the WG list) would provide
traceability on the reasoning.

But I come back to this point because I think it is important: the violation
here is of the individual contributor's responsibility under BCP79.

Cheers,
Adrian



From presnick@qualcomm.com  Thu Jan 26 08:10:48 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61BB21F8661; Thu, 26 Jan 2012 08:10:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.559
X-Spam-Level: 
X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ehfsvfv5JhCq; Thu, 26 Jan 2012 08:10:47 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 6567A21F8604; Thu, 26 Jan 2012 08:10:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1327594247; x=1359130247; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F217A7C.6080908@qualcomm.com>|Date:=20Th u,=2026=20Jan=202012=2010:08:28=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20John=20C=20Klensin=20|CC:=20,=20,=20|Subject:=20Re:=20Second=20Last=09Cal l:=09=0D=0A =20(Sieve=09Notifica=09tion=20Mechanism:=20SIP=20MESSAGE) =20to=20Proposed=20Standard|References:=20<20120125201714 .3903.82295.idtracker@ietfa.amsl.com>=09<4F2075BE.5070201 @nostrum.com>=09,=09<033901ccdbab$6bae0900$430a1b00$@oldd og.co.uk>=09=09<4F208AEF.5060406@qualcomm .com>=20<9E8747DFE73501D34065351E@PST.JCK.COM> |In-Reply-To:=20<9E8747DFE73501D34065351E@PST.JCK.COM> |Content-Type:=20text/plain=3B=20charset=3D"ISO-8859-1" =3B=20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-Originating-IP:=20[172.30.48.1]; bh=s1p9ZSNgTQ8FhGxnCDIVkVUWprNeJN8aIIPLv+ZGzrQ=; b=BPB/rUi2xw6HTQia9U/Oc+83ZEEZVz3zbDKtd19D15oQyUulcceTurWT 1K8GrlDyCx5h0Yy4/r3mUkKZYzThlj4Q011ZCnbVUr9f15CDztjQKiWE/ CmZLsSaPL/XKCwXrUtScGlJDjkzU4PdlNItGYQfJgheKh9OP5bhXQfq0c s=;
X-IronPort-AV: E=McAfee;i="5400,1158,6600"; a="155798045"
Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 26 Jan 2012 08:10:40 -0800
X-IronPort-AV: E=Sophos;i="4.71,574,1320652800"; d="scan'208";a="157179713"
Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 26 Jan 2012 08:10:39 -0800
Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 26 Jan 2012 08:08:31 -0800
Message-ID: <4F217A7C.6080908@qualcomm.com>
Date: Thu, 26 Jan 2012 10:08:28 -0600
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: John C Klensin 
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com>	<4F2075BE.5070201@nostrum.com>	, <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>		<4F208AEF.5060406@qualcomm.com> <9E8747DFE73501D34065351E@PST.JCK.COM>
In-Reply-To: <9E8747DFE73501D34065351E@PST.JCK.COM>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.48.1]
Cc: adrian@olddog.co.uk, sieve@ietf.org, ietf@ietf.org
Subject: Re: [sieve] Second Last	Call:	 (Sieve	Notifica	tion Mechanism: SIP MESSAGE) to Proposed Standard
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 16:10:49 -0000

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:

> It seems to me that a key question here is whether the original
> author's decision to not disclose was made in violation of
> company policy or whether the sequence of posting the I-D,
> getting the document through the WG and Last Call, and then
> posting the disclosure is a matter of company policy.

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.

> Consequently, I believe that at least the following should be
> required:
>
> (1) Revision of the IPR statement so it identifies the
> responsible individual by name, department, and title.  I do not
> believe that the rather anonymous "Director of Licensing" is
> compliant with the intent of the IPR disclosure rules.   I will
> leave it to the lawyers to advise on whether a document issued
> without the name (not just title) of a responsible individual
> would even be held to be valid in the various jurisdictions in
> which the patent might be recognized.
>    

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."

> (2) A request to the company involved for someone who can
> formally speak for that company to publicly clarify that this
> sequence of behavior occurred in violation of company policy.
> If there are internal rewards to individuals for filing and/or
> being awarded patents, I assume that a decision that the actions
> violate company policy would cause such awards to be withheld in
> this case, even though the IETF would have no way to verify
> whether or not that occurred.
>    

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.

> (3) A request to the company involved to remove the reciprocity
> clause from the license stated in the disclosure statement.  As
> a show of good faith, they should agree to derive no benefit
> from the patent other than what praise accrues from having it
> awarded.
>    

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.

> (4) Removal of the offending individual from the list of authors
> to the acknowledgments with text similar to that suggested by
> Adrian.  Unless the company involved is willing to provide the
> clarification suggested in (2) above, and possibly the license
> modification suggested in (3) above, all names of authors
> associated with that company should be removed to the
> acknowledgements and the company affiliation explicitly
> identified there.  In either case, this should be viewed as a
> response to a policy violation and not entangled with any more
> general discussion of listed authors on I-Ds or RFCs.
>    

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).

> (5) Unless the clarification suggested in (2) can be provided,
> each IETF participant who is associated with the relevant
> company and who is in an IETF-related leadership or
> decision-making position (WG Chairs; Editors; IESG, IAB, IAOC,
> Nomcom, members; etc.) should be asked to make a conscientious
> personal review as to whether this type of action sufficiently
> compromises his or her position that resignation or some other
> action would be appropriate and, as appropriate, to review IETF
> policies with whatever management chains are relevant.  I am
> _not_ suggesting that anyone be asked to resign, only that they
> engage in careful consideration of the issues and their
> implications.
>    

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

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


From cyrus@daboo.name  Thu Jan 26 08:42:25 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE49321F84DF for ; Thu, 26 Jan 2012 08:42:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.056
X-Spam-Level: 
X-Spam-Status: No, score=-99.056 tagged_above=-999 required=5 tests=[AWL=3.543, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEtV3z5WiVsb for ; Thu, 26 Jan 2012 08:42:25 -0800 (PST)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 440FD21F84DE for ; Thu, 26 Jan 2012 08:42:25 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 9B45E20DE875 for ; Thu, 26 Jan 2012 11:42:24 -0500 (EST)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZHBvcYAt-zA for ; Thu, 26 Jan 2012 11:42:19 -0500 (EST)
Received: from vp0101wa-dhcp96.apple.com (unknown [17.224.23.96]) by daboo.name (Postfix) with ESMTPSA id B8D4120DE862 for ; Thu, 26 Jan 2012 11:42:18 -0500 (EST)
Date: Thu, 26 Jan 2012 08:42:20 -0800
From: Cyrus Daboo 
To: sieve@ietf.org
Message-ID: <14563BD9F3AB1B6DC6B13EE9@vp0101wa-dhcp96.apple.com>
X-Mailer: Mulberry/4.1.0a3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size=1081
Subject: [sieve] IPR issues
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 16:42:25 -0000

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.

-- 
Cyrus Daboo


From sm@resistor.net  Thu Jan 26 08:53:46 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360EF21F85C0; Thu, 26 Jan 2012 08:53:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.619
X-Spam-Level: 
X-Spam-Status: No, score=-102.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sChsI+53ZFVg; Thu, 26 Jan 2012 08:53:44 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E2621F85BD; Thu, 26 Jan 2012 08:53:43 -0800 (PST)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0QGrZaB029089; Thu, 26 Jan 2012 08:53:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327596822; i=@resistor.net; bh=4bHfjVN59IGoV4GAq8SfGsSVqD7wE5Yi2FwXWgPiQLg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=iY5Ncpw8sPLmywiDtzH9OoUk7Wvu4OBiKKAp/QVcfXynkhu3xy29q4txwaJ1NMk8J xdtL0XBtid4NDRYkCG+DFvI/R4PzCTZcaLNFckDV0C3i8AdKNTPRhBqC65R0sDLwSg p/PRZcLKaU4sdN6fJdDnbzEGrp0BAqUjAVykX8Gw=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327596822; i=@resistor.net; bh=4bHfjVN59IGoV4GAq8SfGsSVqD7wE5Yi2FwXWgPiQLg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=Y7p3esm+6ZkXJXGMTF8I8yAQM71ZlMMtLwc39l11lYBNwiyzbtJtUl5BIlvPOW0GN zZ4OXOKkRogIEc6XSE4Q5bEloNBQjYH3yNK4C1BmU7591eE9icll2ASesQdR7Ii7av KF4ry7nKofShkVus4CNEiiYaCFHtlYHCYpKVdfNI=
Message-Id: <6.2.5.6.2.20120126073506.0b20a180@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 26 Jan 2012 08:51:14 -0800
To: adrian@olddog.co.uk
From: SM 
In-Reply-To: <007f01ccdc3e$ce46a0c0$6ad3e240$@olddog.co.uk>
References: <007f01ccdc3e$ce46a0c0$6ad3e240$@olddog.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: sieve@ietf.org, ietf@ietf.org
Subject: Re: [sieve] Violation of IETF process (was: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard)
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 16:53:46 -0000

At 07:25 26-01-2012, Adrian Farrel wrote:
>I have not made any statement about what the company has done.

Ok.

>I don't view *disclosing* as a problem here. In fact disclosure is to be
>encouraged.

I too don't view disclosing as a problem here.  It is possible to 
compare the statement with other such statements and see the differences.

>My issue is with the individual. BCP 79 is very clear about individual
>responsibilities wrt IPR that they are aware of.

Yes.

>It is the individual who breaks the IETF's IPR policy if they make 
>contributions
>when there is IPR that they are aware of that is not disclosed in a timely
>fashion.

Yes.

>Questions that should not be asked should not, by definition, be asked.
>I wonder if you are concerned about corporate and anti-trust issues.

I am concerned that individuals who are sponsored by their company 
will end up being the escape goat.  I am concerned that the Note Well 
might end up being ignored.  If individuals do not understand the 
Note Well, it is unlikely that they will understand any future 
antitrust policy.

>I am also interested in the discussion about whether moving an author's name
>from the front page to the Acknowledgements (with an explanation) 
>would have an
>impact on discussions of IPR policy violation in court. This will need
>professional legal advice - my feeling was that previous I-D versions would

Yes.

>But I come back to this point because I think it is important: the violation
>here is of the individual contributor's responsibility under BCP79.

That is the point being discussed.

Regards,
-sm 


From sm@resistor.net  Thu Jan 26 09:34:56 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591BE21F8667; Thu, 26 Jan 2012 09:34:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.619
X-Spam-Level: 
X-Spam-Status: No, score=-102.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbTTrThW4R-p; Thu, 26 Jan 2012 09:34:55 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E9E21F8661; Thu, 26 Jan 2012 09:34:54 -0800 (PST)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0QHYlW1013941; Thu, 26 Jan 2012 09:34:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327599293; i=@resistor.net; bh=FZXzlmOaSWWS7ThwfOdR0BCc9144/yc53Ipe2hPr0gI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=Qyy1q7FC0vtuwvtZl9JFmDDS7DIw5iqDEy30JSGAt4MXHvIN0kYvxIDhf2QOJsu9T KzcVtdosB+uFmGjmgB77igWJWSvNdBeCmdReanfbhO9IPwdI5qm6AVxY9n3WESCDjC GPDfnHwpc9k9lNLvEWVkeWROHCF0hPN47RmiFue8=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327599293; i=@resistor.net; bh=FZXzlmOaSWWS7ThwfOdR0BCc9144/yc53Ipe2hPr0gI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=pA53uPvxi1GKS7/t+do6S+Ryxg8RZtyCOtblYcW73enA6NgxWU/TROxHEa3yePZng idRcyaezqhx/vDImID8FQxrW8mnZKGwwMIz1/crXUZPb1445r6x50WLkVvsuvf1dDT xmwKl7/cRVOiSRuygNGDaa4O/74DF+L7GmD23RlU=
Message-Id: <6.2.5.6.2.20120126085545.0b1fa288@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 26 Jan 2012 09:15:00 -0800
To: Pete Resnick 
From: SM 
In-Reply-To: <4F217A7C.6080908@qualcomm.com>
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com> <9E8747DFE73501D34065351E@PST.JCK.COM> <4F217A7C.6080908@qualcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: sieve@ietf.org, ietf@ietf.org
Subject: Re: [sieve] Second Last	Call:	 (Sieve	Notifica	tion Mechanism: SIP MESSAGE) to Proposed Standard
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 17:34:56 -0000

Hi Pete,
At 08:08 26-01-2012, Pete Resnick wrote:
>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

The status of the memo in the drafts have this statement:

   "This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79."

Have the authors been asked whether they have any issue with the above?

The is a question in the write-up: "Has an IPR disclosure related to 
this document been filed?"  Has the Document Shepherd been asked 
about that before the Second Last Call?

The minutes from the last WG session does not mention who chaired the 
session.  Did the WG Chair bring the Note Well to the attention of the WG?

Regards,
-sm 


From cyrus@daboo.name  Thu Jan 26 13:44:10 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDA321F8745; Thu, 26 Jan 2012 13:44:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.418
X-Spam-Level: 
X-Spam-Status: No, score=-101.418 tagged_above=-999 required=5 tests=[AWL=1.181, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fwe20TyvWgeQ; Thu, 26 Jan 2012 13:44:09 -0800 (PST)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id EAB8621F8633; Thu, 26 Jan 2012 13:44:08 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 87F6820E1D55; Thu, 26 Jan 2012 16:44:02 -0500 (EST)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 880eWLdfeZjw; Thu, 26 Jan 2012 16:44:01 -0500 (EST)
Received: from vp0101wa-dhcp96.apple.com (unknown [17.224.23.96]) by daboo.name (Postfix) with ESMTPSA id C175F20E1D48; Thu, 26 Jan 2012 16:44:00 -0500 (EST)
Date: Thu, 26 Jan 2012 13:44:26 -0800
From: Cyrus Daboo 
To: SM , Pete Resnick 
Message-ID: <94D30033CC80C1031A15FD7A@vp0101wa-dhcp96.apple.com>
In-Reply-To: <6.2.5.6.2.20120126085545.0b1fa288@resistor.net>
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com>	<9E8747DFE73501D34065351E@PST.JCK.COM> <4F217A7C.6080908@qualcomm.com> <6.2.5.6.2.20120126085545.0b1fa288@resistor.net>
X-Mailer: Mulberry/4.1.0a3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size=531
Cc: sieve@ietf.org, ietf@ietf.org
Subject: Re: [sieve] Second Last Call:  (Sieve Notifica tion Mechanism: SIP MESSAGE) to Proposed Standard
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 21:44:10 -0000

Hi SM,

--On January 26, 2012 9:15:00 AM -0800 SM  wrote:

> The minutes from the last WG session does not mention who chaired the
> session.  Did the WG Chair bring the Note Well to the attention of the WG?

I was the chair present at that meeting. Apologies for not including that 
detail in the minutes. All the meetings I chair include the Note Well as 
the second slide in presentations I put together (which seems to be common 
practice), and indeed you can see that in the uploaded slides.

-- 
Cyrus Daboo


From john-ietf@jck.com  Thu Jan 26 09:37:17 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A1721F84B9; Thu, 26 Jan 2012 09:37:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UULw1hBwuw57; Thu, 26 Jan 2012 09:37:16 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 05D2821F84AA; Thu, 26 Jan 2012 09:37:16 -0800 (PST)
Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1RqTCb-0005l9-4D; Thu, 26 Jan 2012 12:33:37 -0500
Date: Thu, 26 Jan 2012 12:37:06 -0500
From: John C Klensin 
To: Pete Resnick 
Message-ID: 
In-Reply-To: <4F217A7C.6080908@qualcomm.com>
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> ,	<033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com> <9E8747DFE73501D34065351E@PST.JCK.COM> <4F217A7C.6080908@qualcomm.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Mailman-Approved-At: Thu, 26 Jan 2012 13:45:38 -0800
Cc: adrian@olddog.co.uk, sieve@ietf.org, ietf@ietf.org
Subject: Re: [sieve] Second Last	Call:	 (Sieve	Notifica	tion Mechanism: SIP MESSAGE) to Proposed Standard
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 17:37:17 -0000

--On Thursday, January 26, 2012 10:08 -0600 Pete Resnick
 wrote:

> 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:
> 
>> It seems to me that a key question here is whether the
>> original author's decision to not disclose was made in
>> violation of company policy or whether the sequence of
>> posting the I-D, getting the document through the WG and Last
>> Call, and then posting the disclosure is a matter of company
>> policy.
> 
> 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.

Excellent.   I had hoped that was the situation.  It obviously
makes things much easier (and some of my earlier comments
irrelevant).   With all the effort we go to ("Note Well" and
otherwise) to be sure that people are informed about the policy,
I have trouble generating sympathy for someone who says "didn't
underatand", but that is another matter (and perhaps just my
problem).

>> Consequently, I believe that at least the following should be
>> required:
>> 
>> (1) Revision of the IPR statement so it identifies the
>> responsible individual by name, department, and title.  I do
>> not believe that the rather anonymous "Director of Licensing"
>> is compliant with the intent of the IPR disclosure rules.   I
>> will leave it to the lawyers to advise on whether a document
>> issued without the name (not just title) of a responsible
>> individual would even be held to be valid in the various
>> jurisdictions in which the patent might be recognized.
>>    
> 
> 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?

The former.

> 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.

That is correct.  I believe I suggested in a later note that
this is an area to which it would be good if the Trust paid some
attention and advised the Secretariat and others accordingly.

>> (2) A request to the company involved for someone who can
>> formally speak for that company to publicly clarify that this
>> sequence of behavior occurred in violation of company policy.
>> If there are internal rewards to individuals for filing and/or
>> being awarded patents, I assume that a decision that the
>> actions violate company policy would cause such awards to be
>> withheld in this case, even though the IETF would have no way
>> to verify whether or not that occurred.
> 
> 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.

That was my assumption.  On the other hand, if it is already
clear that this was either a misunderstanding, a violation of
company policy, or both, it might not be necessary.

>> (3) A request to the company involved to remove the
>> reciprocity clause from the license stated in the disclosure
>> statement.  As a show of good faith, they should agree to
>> derive no benefit from the patent other than what praise
>> accrues from having it awarded.

> 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.

I was only suggesting asking.  If they say "no", which they
obviously have the right to do, it is, as others have pointed
out, the WG's problem to consider what that is an issue.  If the
WG is indifferent on the issue, it seems to me that the relevant
AD has a problem, but that problem is _not_ bound to the
disclosure issue.

>> (4) Removal of the offending individual from the list of
>> authors to the acknowledgments with text similar to that
>> suggested by Adrian.  Unless the company involved is willing
>> to provide the clarification suggested in (2) above, and
>> possibly the license modification suggested in (3) above, all
>> names of authors associated with that company should be
>> removed to the acknowledgements and the company affiliation
>> explicitly identified there.  In either case, this should be
>> viewed as a response to a policy violation and not entangled
>> with any more general discussion of listed authors on I-Ds or
>> RFCs.

> 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. 

That was my assumption.

> 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?

If the other authors from that company have already told us that
they were not aware of the patent application until very late in
the process and that they moved diligently toward getting an
appropriate disclosure filed as soon as they did find out, my
suggestion is moot.

I was concerned about the (thoroughly unlikely in this case)
possibility that the other authors from that company were
personally aware of the IPR but had been, e.g., advised that
they were not to make the disclosure because someone else would
take responsibility for it.

> 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).

Understood.  My separate concerns about the implications of that
policy should a company ever choose to deliberately hide
relevant IPR from IETF participants do not apply to this case
and should not be part of the discussion.
 
>> (5) Unless the clarification suggested in (2) can be provided,
>> each IETF participant who is associated with the relevant
>> company and who is in an IETF-related leadership or
>> decision-making position (WG Chairs; Editors; IESG, IAB, IAOC,
>> Nomcom, members; etc.) should be asked to make a conscientious
>> personal review as to whether this type of action sufficiently
>> compromises his or her position that resignation or some other
>> action would be appropriate and, as appropriate, to review
>> IETF policies with whatever management chains are relevant.
>> I am _not_ suggesting that anyone be asked to resign, only
>> that they engage in careful consideration of the issues and
>> their implications.

> 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.

Complete agreement.  I would, for the record, make much the same
suggestion about behavior in other situations that appeared to
push the boundaries of codes of professional ethics of the
professional societies of which many of us are members.  Like
the IETF's IPR rules, those provisions are intended to be taken
seriously rather than as decoration that can be safely ignored.
The issue is an individual one, not an IETF one, and the current
issue is relevant only insofar as it should encourage all of us
--not just those involved in this document-- to take our various
personal and professional obligations seriously and to consider
the implications of circumstances in which various of them might
come into conflict.

best,
    john


From mrex@sap.com  Thu Jan 26 13:29:45 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3DA21F8705; Thu, 26 Jan 2012 13:29:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.16
X-Spam-Level: 
X-Spam-Status: No, score=-10.16 tagged_above=-999 required=5 tests=[AWL=0.089,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4G87zg0pdF-q; Thu, 26 Jan 2012 13:29:44 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1DC21F8636; Thu, 26 Jan 2012 13:29:44 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0QLTgj2018710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jan 2012 22:29:42 +0100 (MET)
From: Martin Rex 
Message-Id: <201201262129.q0QLTgDN002510@fs4113.wdf.sap.corp>
To: presnick@qualcomm.com (Pete Resnick)
Date: Thu, 26 Jan 2012 22:29:42 +0100 (MET)
In-Reply-To: <4F217A7C.6080908@qualcomm.com> from "Pete Resnick" at Jan 26, 12 10:08:28 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
X-Mailman-Approved-At: Thu, 26 Jan 2012 13:45:38 -0800
Cc: john-ietf@jck.com, adrian@olddog.co.uk, sieve@ietf.org, ietf@ietf.org
Subject: Re: [sieve] Second Last Call: 
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 21:29:45 -0000

Pete Resnick 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.


Somehow that sounds unconvincing to me.  While I've never been through
the patent application process myself, from what I've heard, it is
non-trivial and usually taken care of by the company's legal department.

Normally, patent lawyers of a company's legal department should have
sufficient clue about participation in SDOs that they should know
to ask employees the right questions.


-Martin

From sm@resistor.net  Thu Jan 26 14:37:46 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3794321F8615 for ; Thu, 26 Jan 2012 14:37:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.612
X-Spam-Level: 
X-Spam-Status: No, score=-102.612 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuZRikAzsogh for ; Thu, 26 Jan 2012 14:37:45 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B878621F8603 for ; Thu, 26 Jan 2012 14:37:45 -0800 (PST)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0QMbV24023863; Thu, 26 Jan 2012 14:37:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327617456; i=@resistor.net; bh=rm9mVYhEgDmKrnK5MuXtWcDJcMJQaHp2qeRpKXZ114c=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=iaG83mHDYOZsTDTe6yD61u4iKpWtLT6cdcujhJItSWCV2Z2d6tupenA3KXFmEXWIg Wb2J+VxDiFdJxCm5Kn4sb+MOzgHgWp887quMsGvVM4YWx9l3FRIrM3F9VzksiTrQP3 wT26DmDlNUCqIFIbAw/htqG7nJf58sMcl6PZur48=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327617456; i=@resistor.net; bh=rm9mVYhEgDmKrnK5MuXtWcDJcMJQaHp2qeRpKXZ114c=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=rKnNqV3LeL8WnFsgPoZe7c9+e4z+90F6o9tEIEXtNHkcdqZez7lE/2aoFcDaa8rtz TImMvpXx1knfQ1xWkc5FXnjGJb/lKIRYD8BIfu9hZjtrq17OhByhV2VV4XUsxqSdrr ifxAhTWTpBGV0+G6KWPweJFS2sa52As2Z9QWh4ow=
Message-Id: <6.2.5.6.2.20120126142611.0a791a10@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 26 Jan 2012 14:37:23 -0800
To: Cyrus Daboo 
From: SM 
In-Reply-To: 
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com>  <4F21ABF2.7040002@qualcomm.com> <6.2.5.6.2.20120126115633.0cd39770@resistor.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: sieve@ietf.org
Subject: Re: [sieve] Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 22:37:46 -0000

Hi Cyrus,
At 13:42 26-01-2012, Cyrus Daboo wrote:
>There is feedback along those lines on the SIEVE WG mailing list. 
>Please see the thread started by Pete on this issue last year: 
>. 
>That thread covers all the WG debate on this issue up until the two 
>recent last calls.

That's the "do nothing" alternative.  Peter mentioned that it is a bad idea.

At 13:44 26-01-2012, Cyrus Daboo wrote:
>I was the chair present at that meeting. Apologies for not including 
>that detail in the minutes. All the meetings I chair include the 
>Note Well as the second slide in presentations I put together (which 
>seems to be common practice), and indeed you can see that in the 
>uploaded slides.

Thanks.

Regards,
-sm 


From arnt@gulbrandsen.priv.no  Fri Jan 27 00:01:29 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B212B21F8525; Fri, 27 Jan 2012 00:01:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n26Aco2nP5vP; Fri, 27 Jan 2012 00:01:28 -0800 (PST)
Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id C18A521F8522; Fri, 27 Jan 2012 00:01:28 -0800 (PST)
Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 49D96F8C438; Fri, 27 Jan 2012 08:01:26 +0000 (UTC)
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1327651285-609-608/10/10; Fri, 27 Jan 2012 08:01:25 +0000
Message-Id: <4F2259D5.5010805@gulbrandsen.priv.no>
Date: Fri, 27 Jan 2012 09:01:25 +0100
From: Arnt Gulbrandsen 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0
Mime-Version: 1.0
To: ietf@ietf.org, sieve@ietf.org
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com> <9E8747DFE73501D34065351E@PST.JCK.COM> <4F217A7C.6080908@qualcomm.com>
In-Reply-To: <4F217A7C.6080908@qualcomm.com>
Content-Type: text/plain; charset=iso-8859-1
Subject: Re: [sieve] Second Last	Call:	 (Sieve	Notifica	tion Mechanism: SIP MESSAGE) to Proposed Standard
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 08:01:29 -0000

Pete Resnick 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.

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

From arnt@gulbrandsen.priv.no  Fri Jan 27 00:04:42 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492DA21F8526 for ; Fri, 27 Jan 2012 00:04:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lJp1X7+jx7S for ; Fri, 27 Jan 2012 00:04:41 -0800 (PST)
Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5D66621F8525 for ; Fri, 27 Jan 2012 00:04:41 -0800 (PST)
Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 49A15F8C436; Fri, 27 Jan 2012 08:04:35 +0000 (UTC)
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1327651474-609-608/10/11; Fri, 27 Jan 2012 08:04:34 +0000
Message-Id: <4F225A92.1020807@gulbrandsen.priv.no>
Date: Fri, 27 Jan 2012 09:04:34 +0100
From: Arnt Gulbrandsen 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0
Mime-Version: 1.0
To: sieve@ietf.org
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com> <9E8747DFE73501D34065351E@PST.JCK.COM> <4F217A7C.6080908@qualcomm.com> <6.2.5.6.2.20120126085545.0b1fa288@resistor.net>
In-Reply-To: <6.2.5.6.2.20120126085545.0b1fa288@resistor.net>
Content-Type: text/plain; charset=iso-8859-1
Subject: Re: [sieve] Second Last	Call:	 (Sieve	Notifica	tion Mechanism: SIP MESSAGE) to Proposed Standard
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 08:04:42 -0000

>   "This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79."

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

From NED+mta-filters@mauve.mrochek.com  Fri Jan 27 12:55:42 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEC921F86DD for ; Fri, 27 Jan 2012 12:55:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.37
X-Spam-Level: 
X-Spam-Status: No, score=-1.37 tagged_above=-999 required=5 tests=[AWL=-1.229,  BAYES_40=-0.185, DATE_IN_PAST_03_06=0.044]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzgCNpCOsveN for ; Fri, 27 Jan 2012 12:55:42 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE1E21F870B for ; Fri, 27 Jan 2012 12:55:42 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBA6UGFFF40181JG@mauve.mrochek.com> for sieve@ietf.org; Fri, 27 Jan 2012 12:55:39 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OB7OO3V69C00ZUIL@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Fri, 27 Jan 2012 12:55:34 -0800 (PST)
From: NED+mta-filters@mauve.mrochek.com
Message-id: <01OBA6UDJOXS00ZUIL@mauve.mrochek.com>
Date: Fri, 27 Jan 2012 09:17:26 -0800 (PST)
In-reply-to: "Your message dated Thu, 26 Jan 2012 08:42:20 -0800" <14563BD9F3AB1B6DC6B13EE9@vp0101wa-dhcp96.apple.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; Format=flowed
References: <14563BD9F3AB1B6DC6B13EE9@vp0101wa-dhcp96.apple.com>
To: Cyrus Daboo 
Cc: sieve@ietf.org
Subject: Re: [sieve] IPR issues
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 20:55:42 -0000

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

From aaron@serendipity.cx  Tue Jan 31 09:41:59 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2714211E80EC for ; Tue, 31 Jan 2012 09:41:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.367
X-Spam-Level: 
X-Spam-Status: No, score=-101.367 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fB9KVeJy5IcG for ; Tue, 31 Jan 2012 09:41:58 -0800 (PST)
Received: from slice.serendipity.cx (slice.serendipity.cx [67.23.2.90]) by ietfa.amsl.com (Postfix) with ESMTP id 9892911E8080 for ; Tue, 31 Jan 2012 09:41:58 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by slice.serendipity.cx (Postfix) with ESMTPSA id 83B1D18008 for ; Tue, 31 Jan 2012 09:41:38 -0800 (PST)
Received: by vcbfk14 with SMTP id fk14so254146vcb.31 for ; Tue, 31 Jan 2012 09:41:40 -0800 (PST)
Received: by 10.220.148.201 with SMTP id q9mr13051891vcv.33.1328031700120; Tue, 31 Jan 2012 09:41:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.111.164 with HTTP; Tue, 31 Jan 2012 09:41:19 -0800 (PST)
In-Reply-To: <01OB4UBRD5QU00ZUIL@mauve.mrochek.com>
References: <4F1ABE14.5020601@isode.com>  <01OB4UBRD5QU00ZUIL@mauve.mrochek.com>
From: Aaron Stone 
Date: Tue, 31 Jan 2012 09:41:19 -0800
Message-ID: 
To: Ned Freed 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Sieve mailing list 
Subject: Re: [sieve] Sieve include: interactions with MIME loops
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jan 2012 17:41:59 -0000

Posting this now.

On Mon, Jan 23, 2012 at 5:00 PM, Ned Freed  wrote:
>> On Sat, Jan 21, 2012 at 5:31 AM, Alexey Melnikov
>>  wrote:
>> > I am looking at the new text in draft-ietf-sieve-include-14.txt:
>> >
>> > 3.5. =A0Interaction with Other Extensions
>> >
>> > =A0 =A0 =A0 =A0When "include" is used with the Editheader extension [R=
FC5293], any
>> > =A0 =A0 =A0 =A0changes made to headers in a script MUST be propagated =
both to and
>> > =A0 =A0 =A0 =A0from included scripts. =A0By way of example, if a scrip=
t deletes one
>> > =A0 =A0 =A0 =A0header and add another, then includes a second script, =
the included
>> > =A0 =A0 =A0 =A0script MUST NOT see the removed header, and MUST see th=
e added
>> > =A0 =A0 =A0 =A0header. =A0Likewise, if the included script adds or rem=
oves a header,
>> > =A0 =A0 =A0 =A0upon returning to the including script, subsequent acti=
ons MUST see
>> > =A0 =A0 =A0 =A0the added headers and MUST NOT see the removed headers.
>> >
>> > =A0 =A0 =A0 =A0When "include" is used with the MIME extension [RFC5703=
]
>> > =A0 =A0 =A0 =A0"foreverypart" control structure, the included script M=
UST be
>> > =A0 =A0 =A0 =A0presented with the current MIME part as though it were =
the entire
>> > =A0 =A0 =A0 =A0message. =A0A script SHALL NOT have any special control=
 over the
>> > =A0 =A0 =A0 =A0control structure it was included from. =A0In the MIME =
example once
>> > =A0 =A0 =A0 =A0again, a "stop" or "return" in an included script canno=
t directly
>> > =A0 =A0 =A0 =A0terminate or continue flow of a "foreverypart" block. =
=A0In such a
>> > =A0 =A0 =A0 =A0case, the included script should set a global variable =
that the
>> > =A0 =A0 =A0 =A0including script can test.
>> >
>> > This makes me think that it is not clear what effect the "reject" acti=
on
>> > would have if called in an included script within a "foreverypart" blo=
ck.
>> > 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
>> entire message.
>
> I don't agree; I think it should simply set reject as the script result
> and continue. It's possible that some other action that's compatible with
> reject (e.g., notify) would be done later. If you want it to halt you
> can put stop after the reject.
>
>> I think stop does the same, except with the implicit
>> keep as the default.
>
> Right, but stop should be the only thing that terminates execution.
>
>> Some text in an additional "interactions with other extensions"
>> subsection should state this.
>
>> Oh man, here goes another rev.
>
> Good thing they're cheap.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ned

From internet-drafts@ietf.org  Tue Jan 31 10:08:50 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9697521F8557; Tue, 31 Jan 2012 10:08:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byliWtse7z95; Tue, 31 Jan 2012 10:08:50 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3448C21F8510; Tue, 31 Jan 2012 10:08:50 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.64p1
Message-ID: <20120131180850.29578.64908.idtracker@ietfa.amsl.com>
Date: Tue, 31 Jan 2012 10:08:50 -0800
Cc: sieve@ietf.org
Subject: [sieve] I-D Action: draft-ietf-sieve-include-15.txt
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jan 2012 18:08:50 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. 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


From barryleiba.mailing.lists@gmail.com  Tue Jan 31 13:07:48 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE5721F8679 for ; Tue, 31 Jan 2012 13:07:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.942
X-Spam-Level: 
X-Spam-Status: No, score=-102.942 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQ1gzyMZm45R for ; Tue, 31 Jan 2012 13:07:48 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 29B9021F8675 for ; Tue, 31 Jan 2012 13:07:48 -0800 (PST)
Received: by ghbg16 with SMTP id g16so319031ghb.31 for ; Tue, 31 Jan 2012 13:07:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=EfmL85X8eVuh/lgdVrMZrUR0fhTtJMzE3Jyo1hApx6Y=; b=HQvjnw+O3yv5sCkv0m5vlPCn4B6esr2Bl5BpU0K2ZFJDRFflwJRZYS8PfeuSEL8nM9 l/T0qjd+8/wn11SnVzYu5hyXvUkdFiUZrlbVlhL4Yk4VAC2dqCAYYwAJ+JarNGuq/BKF Pa/WNukoiPRGbOu4p7B3iv19Jz7rLLYMBIOec=
MIME-Version: 1.0
Received: by 10.236.133.210 with SMTP id q58mr15634536yhi.6.1328044067848; Tue, 31 Jan 2012 13:07:47 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.146.136.20 with HTTP; Tue, 31 Jan 2012 13:07:47 -0800 (PST)
In-Reply-To: 
References: <4F1ABE14.5020601@isode.com>  <01OB4UBRD5QU00ZUIL@mauve.mrochek.com> 
Date: Tue, 31 Jan 2012 16:07:47 -0500
X-Google-Sender-Auth: xld1l9McobDFrbeFOnNGVR_oe1o
Message-ID: 
From: Barry Leiba 
To: Aaron Stone 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Sieve mailing list 
Subject: Re: [sieve] Sieve include: interactions with MIME loops
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jan 2012 21:07:48 -0000

> Posting this now.

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.

>>> Oh man, here goes another rev.
>>
>> Good thing they're cheap.

Indeed.

Barry, shepherding

From aaron@serendipity.cx  Tue Jan 31 13:59:52 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D80A11E8083 for ; Tue, 31 Jan 2012 13:59:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.395
X-Spam-Level: 
X-Spam-Status: No, score=-101.395 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vJ8urmmoJK4 for ; Tue, 31 Jan 2012 13:59:51 -0800 (PST)
Received: from slice.serendipity.cx (slice.serendipity.cx [67.23.2.90]) by ietfa.amsl.com (Postfix) with ESMTP id B597311E8080 for ; Tue, 31 Jan 2012 13:59:51 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by slice.serendipity.cx (Postfix) with ESMTPSA id EA62411005B for ; Tue, 31 Jan 2012 13:59:19 -0800 (PST)
Received: by vcbfk14 with SMTP id fk14so488981vcb.31 for ; Tue, 31 Jan 2012 13:59:22 -0800 (PST)
Received: by 10.220.213.200 with SMTP id gx8mr13616602vcb.13.1328047162455; Tue, 31 Jan 2012 13:59:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.111.164 with HTTP; Tue, 31 Jan 2012 13:59:02 -0800 (PST)
In-Reply-To: 
References: <4F1ABE14.5020601@isode.com>  <01OB4UBRD5QU00ZUIL@mauve.mrochek.com>  
From: Aaron Stone 
Date: Tue, 31 Jan 2012 13:59:02 -0800
Message-ID: 
To: Barry Leiba 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Sieve mailing list 
Subject: Re: [sieve] Sieve include: interactions with MIME loops
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jan 2012 21:59:52 -0000

Oof :(  Thanks for reviewing the changes!

On Tue, Jan 31, 2012 at 1:07 PM, Barry Leiba  wrot=
e:
>> Posting this now.
>
> That looks like what we want (the -15 version). =A0Now just put out a
> -16 to fix the "foreverpart" typo you just introduced, and we'll move
> it along.
>
>>>> Oh man, here goes another rev.
>>>
>>> Good thing they're cheap.
>
> Indeed.
>
> Barry, shepherding

From NED+mta-filters@mauve.mrochek.com  Tue Jan 31 19:54:23 2012
Return-Path: 
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D0B11E809D for ; Tue, 31 Jan 2012 19:54:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.189
X-Spam-Level: 
X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.410,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dwBWPsUFE2q for ; Tue, 31 Jan 2012 19:54:23 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id E478411E8096 for ; Tue, 31 Jan 2012 19:54:22 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBG6MVWJGW014X0O@mauve.mrochek.com> for sieve@ietf.org; Tue, 31 Jan 2012 19:54:18 -0800 (PST)
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=iso-8859-1
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBEI37480W00ZUIL@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Tue, 31 Jan 2012 19:54:13 -0800 (PST)
From: NED+mta-filters@mauve.mrochek.com
Message-id: <01OBG6MT36UG00ZUIL@mauve.mrochek.com>
Date: Tue, 31 Jan 2012 19:54:05 -0800 (PST)
In-reply-to: "Your message dated Tue, 31 Jan 2012 09:41:19 -0800" 
References: <4F1ABE14.5020601@isode.com>  <01OB4UBRD5QU00ZUIL@mauve.mrochek.com> 
To: Aaron Stone 
Cc: Sieve mailing list , Ned Freed 
Subject: Re: [sieve] Sieve include: interactions with MIME loops
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Feb 2012 03:54:23 -0000

> Posting this now.

Looks good to me.

				Ned

> On Mon, Jan 23, 2012 at 5:00 PM, Ned Freed  wrote:
> >> On Sat, Jan 21, 2012 at 5:31 AM, Alexey Melnikov
> >>  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
> >> entire message.
> >
> > I don't agree; I think it should simply set reject as the script result
> > and continue. It's possible that some other action that's compatible with
> > reject (e.g., notify) would be done later. If you want it to halt you
> > can put stop after the reject.
> >
> >> I think stop does the same, except with the implicit
> >> keep as the default.
> >
> > Right, but stop should be the only thing that terminates execution.
> >
> >> Some text in an additional "interactions with other extensions"
> >> subsection should state this.
> >
> >> Oh man, here goes another rev.
> >
> > Good thing they're cheap.
> >
> >                                Ned
> _______________________________________________
> sieve mailing list
> sieve@ietf.org
> https://www.ietf.org/mailman/listinfo/sieve