[sieve] Notary last call

[Cyrus Daboo <[e-mail]>]

Hi folks,
We issued a WG last call on the -deliverby changes to the notary extension 
(draft-freed-sieve-notary-05) at the IETF meeting last month. We are well 
past the last call end date and there have been no comments (positive or 
negative) on the list at all. Please review the changes that have been made 
to this document and respond on this list ASAP. We would like to send this 
to the IESG but we need to be sure it has had adequate review.

-- 
Cyrus Daboo


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7JLLRLm001530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Aug 2009 14:21:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7JLLRlq001529; Wed, 19 Aug 2009 14:21:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7JLLJMJ001508 for <[e-mail]>; Wed, 19 Aug 2009 14:21:25 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 19 Aug 2009 14:21:17 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Wed, 19 Aug 2009 14:21:15 -0700 (PDT)
Date: Wed, 19 Aug 2009 14:19:03 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Problem in RFC 5260 - Appendix A
In-reply-to: "Your message dated Tue, 18 Aug 2009 00:59:04 +0200" <[e-mail]>
To: Stephan Bosch <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hello,

> I've recently implemented the Sieve date extension specified in RFC
> 5260. One of the date parts available for matching is the 'julian' part.
> According to the text at page 3 it represents the following:

>       "julian"    => the Modified Julian Day, that is, the date
>                      expressed as an integer number of days since
>                      00:00 UTC on November 17, 1858 (using the Gregorian
>                      calendar).  This corresponds to the regular
>                      Julian Day minus 2400000.5.  Sample routines to
>                      convert to and from modified Julian dates are
>                      given in Appendix A.

> In a lazy mood, I copied the jday function from Appendix A into my
> implementation to generate the required Modified Julian Day (MJD). To my
> surprise this function does not yield the MJD, but rather just the
> regular Julian Day (rounded up to the nearest integer). So, for the date
> 17-08-2009 it yields 2455061 in stead of 55060 (at time 00:00:00). The
> text in Appendix A clearly states that the jday function returns the
> modified julian day, but apparently it does not. Other than that, the
> variable 'j' is declared but never used anywhere in the function.

> Is an erratum due for RFC 5260, or am I just blabbering nonsense? My
> expertise on date-time conversions is a bit bleak, but from what I could
> find on the net, the jday function is not a correct example for date to
> MJD conversion.

You're right - the code in the appendix doesn't have the necessary adjustment
in it. (Of course it's a trivial thing to add.)

As to  whether this should be dealt with by an erratum, that's one way, but
perhaps the better alternative is to republish so I can also add the phrase
"code component" to the appendix. That addresses the licensing issues for
reusing code in an RFC.

In any case, thanks for reporting this.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7HMxcNd025284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Aug 2009 15:59:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7HMxctR025283; Mon, 17 Aug 2009 15:59:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from cola.rename-it.nl (cola.rename-it.nl [217.119.231.192]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7HMxPTZ025263 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 17 Aug 2009 15:59:37 -0700 (MST) (envelope-from [e-mail])
Received: from wlan138155.mobiel.utwente.nl ([130.89.138.155]) by cola.rename-it.nl with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <[e-mail]>) id 1MdBAO-0006aK-OZ for [e-mail]; Tue, 18 Aug 2009 00:59:04 +0200
Message-ID: <[e-mail]>
Date: Tue, 18 Aug 2009 00:59:04 +0200
From: Stephan Bosch <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: [e-mail]
Subject: Problem in RFC 5260 - Appendix A
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-RenameIT-MailScanner-VirusScan: Found to be clean
X-RenameIT-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.862, required 5, autolearn=not spam, ALL_TRUSTED -0.40, AWL 1.14, BAYES_00 -2.60)
X-RenameIT-MailScanner-From: [e-mail]
X-Spam-Status: No
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

I've recently implemented the Sieve date extension specified in RFC 
5260. One of the date parts available for matching is the 'julian' part. 
According to the text at page 3 it represents the following:

      "julian"    => the Modified Julian Day, that is, the date
                     expressed as an integer number of days since
                     00:00 UTC on November 17, 1858 (using the Gregorian
                     calendar).  This corresponds to the regular
                     Julian Day minus 2400000.5.  Sample routines to
                     convert to and from modified Julian dates are
                     given in Appendix A.

In a lazy mood, I copied the jday function from Appendix A into my 
implementation to generate the required Modified Julian Day (MJD). To my 
surprise this function does not yield the MJD, but rather just the 
regular Julian Day (rounded up to the nearest integer). So, for the date 
17-08-2009 it yields 2455061 in stead of 55060 (at time 00:00:00). The 
text in Appendix A clearly states that the jday function returns the 
modified julian day, but apparently it does not. Other than that, the 
variable 'j' is declared but never used anywhere in the function.

Is an erratum due for RFC 5260, or am I just blabbering nonsense? My 
expertise on date-time conversions is a bit bleak, but from what I could 
find on the net, the jday function is not a correct example for date to 
MJD conversion.

Regards,

Stephan.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7HKSHRu017108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Aug 2009 13:28:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7HKSHoC017107; Mon, 17 Aug 2009 13:28:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7HKSA2j017098 for <[e-mail]>; Mon, 17 Aug 2009 13:28:16 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.185.38] (92.40.185.38.sub.mbb.three.co.uk [92.40.185.38])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 17 Aug 2009 21:28:09 +0100
Message-ID: <[e-mail]>
Date: Mon, 17 Aug 2009 21:27:58 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: MTA filtering mailing list <[e-mail]>
Subject: draft-ietf-sieve-mime-loop: meaning of :anychild when :mime is not present
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim Polk pointed out during the IESG review that the behavior of 
:anychild without :mime is not defined.
In a private exchange Tony listed alternatives

    1)    The ":anychild" tagged argument is used with the ":mime" tagged
    argument to modify its behavior.
or
    2)    The ":anychild" tagged argument is used with the ":mime" tagged
    argument to modify its behavior. The ":anychild" tagged argument
    is not used without the ":mime" tagged argument.
or
    3)    The ":anychild" tagged argument may only be used with the
    ":mime" tagged argument to modify its behavior.

and mentioned that he slightly prefers 1). Cyrus expressed his 
preference for option 3). I think we need to get WG consensus on this 
change.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7FLKbPG089222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Aug 2009 14:20:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7FLKbgB089221; Sat, 15 Aug 2009 14:20:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7FLKZqu089214 for <[e-mail]>; Sat, 15 Aug 2009 14:20:36 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.122.199] (92.40.122.199.sub.mbb.three.co.uk [92.40.122.199])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 15 Aug 2009 22:20:33 +0100
Message-ID: <[e-mail]>
Date: Sat, 15 Aug 2009 22:20:15 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Stephan Bosch <[e-mail]>
CC: [e-mail]
Subject: Re: Question about ManageSieve capabilities
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephan Bosch wrote:

> Hello,

Hi Stephan,

> Recently, I noticed that it can be useful or even important to have 
> the supported Sieve and ManageSieve capabilities depend on the 
> authenticated user. Because the identity of the connected user is not 
> known until the client authenticates, the capabilities reported upon 
> connect and after authentication are going to differ.
>
> Now I am wondering how to best implement a capability change upon 
> authentication. According to section 1.8 of the draft, the 
> capabilities are allowed to change after an AUTHENTICATE command, so 
> there is no problem there. However, there is still the problem of 
> reliably notifying the client that the capabilities have changed. 
> After AUTHENTICATE this can happen with an unsolicited capability 
> response directly after the command. However, the draft only mentions 
> this in relation to the establishment of a SASL security layer.
>
> Now I have a question:
>
> Is the server allowed to send the unsolicited capability response 
> after AUTHENTICATION also when just capabilities have changed and no 
> SASL security layer has come into effect?

I didn't think this should ever happen. (But to be frank I haven't 
thought about making the two SASL cases symmetrical.) My intent was that 
the client needs to reissue the CAPABILITY command explicitly if it 
wants to know about changes.

> This may be an important notion, because client implementations may 
> not expect this when it is not explicitly mentioned/allowed/prohibited 
> in the specification.

This can indeed be a problem for clients.
I suppose we can change the spec to allow for that, but this would need 
some information about how existing clients cope with this.

> So, for example, this is what I would like to do:
>
> S: "IMPLEMENTATION" "Example1 ManageSieved v001"
> S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
> S: "SIEVE" ""
> S: "VERSION" "1.0"
> S: OK
> C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xu"
> S: "IMPLEMENTATION" "Example1 ManageSieved v001"
> S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
> S: "SIEVE" "fileinto vacation relational copy date index enotify"
> S: "MAXREDIRECTS" "10"
> S: "NOTIFY" "mailto xmmp"
> S: "VERSION" "1.0"
> S: "OWNER" "[e-mail]"
> S: OK "Logged in."
>
> The alternative would be to rely upon the client to issue a CAPABILITY 
> command. This is somewhat less reliable, as clients may refrain from 
> doing so.
>
> So, what's the best way to go here?
>
> Regards,
>
> Stephan



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7DKU7Xa028619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Aug 2009 13:30:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7DKU7FC028618; Thu, 13 Aug 2009 13:30:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7DKU7xp028611 for <[e-mail]>; Thu, 13 Aug 2009 13:30:07 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 1EFCB28C204; Thu, 13 Aug 2009 13:30:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-freed-sieve-in-xml-06.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu, 13 Aug 2009 13:30:02 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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


	Title           : Sieve Email Filtering: Sieves and display directives in XML
	Author(s)       : N. Freed, S. Vedam
	Filename        : draft-freed-sieve-in-xml-06.txt
	Pages           : 32
	Date            : 2009-08-13

This document describes a way to represent Sieve email filtering
language scripts in XML.  Representing sieves in XML is intended not
as an alternate storage format for Sieve but rather as a means to
facilitate manipulation of scripts using XML tools.

The XML representation also defines additional elements that have no
counterparts in the regular Sieve language.  These elements are
intended for use by graphical user interfaces and provide facilities
for labeling or grouping sections of a script so they can be
displayed more conveniently.  These elements are represented as
specially structured comments in regular Sieve format.

Change History (to be removed prior to publication as an RFC

Changed representation of comments in XML to use a comment element.

Update references.

Added an IANA registration of a URN for the Sieve namespace.

Updated XML Schema to allow largely unrestricted use of material in
other namespaces.

Add compact Relax NG schema.

Updated example stylesheet to handle material in other namespaces.

Corrected stylesheet handling of <comment> elements.

Added a section defining the structured comment convention.

Moved the examples section to an appendix.

Added text to clarify that the examples in the various appendices are
in fact code components and may therefore be reused.

Added a section on validation requirements.

Clarified various editor requirements and trust issues, restricted
the use of "*/" in non-Sieve XML content.

Added XML reference.

Added a list of all presently defined controls, explained how unknown
controls would be handled.

Added a note about the need to remove quotes and other syntax
elements when converting to XML.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-freed-sieve-in-xml-06.txt

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

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

--NextPart
Content-Type: Message/External-body;
	name="draft-freed-sieve-in-xml-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7CLHsoJ036727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Aug 2009 14:17:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7CLHsE2036726; Wed, 12 Aug 2009 14:17:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7CLHrqV036720 for <[e-mail]>; Wed, 12 Aug 2009 14:17:53 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.60.62] (92.40.60.62.sub.mbb.three.co.uk [92.40.60.62])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <SoMxfgB9YRX=@rufus.isode.com>; Wed, 12 Aug 2009 22:17:51 +0100
Message-ID: <[e-mail]>
Date: Wed, 12 Aug 2009 22:17:40 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: MTA filtering mailing list <[e-mail]>
Subject: [Fwd: DISCUSS and COMMENT: draft-ietf-sieve-mime-loop]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------080200010308010405030106"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------080200010308010405030106
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

FYI.


--------------080200010308010405030106
Content-Type: message/rfc822;
 name="DISCUSS and COMMENT: draft-ietf-sieve-mime-loop"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="DISCUSS and COMMENT: draft-ietf-sieve-mime-loop"

Return-Path: <[e-mail]>
Received: from rufus.isode.com ([62.3.217.251])
	by canine (Isode M-Box/14.4v1) with LMTP; Wed, 12 Aug 2009 12:40:37 +0100 (BST)
Received: from mail.ietf.org ([64.170.98.32]) by rufus.isode.com (smtp external)
          via TCP with ESMTP id <[e-mail]> for <[e-mail]>;
          Wed, 12 Aug 2009 12:40:36 +0100
Received: by core3.amsl.com (Postfix, from userid 30)
	id 253913A69BC; Wed, 12 Aug 2009 04:40:30 -0700 (PDT)
From: Tim Polk <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: DISCUSS and COMMENT: draft-ietf-sieve-mime-loop 
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed, 12 Aug 2009 04:40:31 -0700 (PDT)

Discuss:
This is a good document overall, but there are a few issues that need to be addressed to
ensure consistency and interoperability of implementations.

(1) In section 3, the semantics of a "break" command that omits a name in a nested 
"foreverypart" is not clearly specified.  In this case, does the "break" terminate the closest 
enclosing loop, or the outermost?

(2) In section 4.1, the semantics of ":anychild" in the absence of the ":mime" tagged argument 
is not specified, but this construct is permitted by the ABNF and is not forbidden by the text.

Since sections 4.2 and 4.3 reference 4.1 for the behavior of ":anychild" this ambiguity ripples 
forward.

(3) In sections 4.2 and 4.3, the following text is ambiguous:

    "the use of "address" with no ":mime" and ":anychild" tagged arguments ..."

Does the no apply to both arguments or just one? if it applies to both, it might be clearer 
to state: 

    "the use of "address" when both the ":mime" and ":anychild" tagged arguments
     are omitted ..."

Comment:
There is at least one occurrence of "SIEVE" in section 11, but most (all?) other occurrences are "Sieve"

For consistency, suggest the global change
s/SIEVE/Sieve/


--------------080200010308010405030106--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7B8M6tA075817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Aug 2009 01:22:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7B8M5QN075816; Tue, 11 Aug 2009 01:22:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from cola.rename-it.nl (cola.rename-it.nl [217.119.231.192]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7B8LuUb075788 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 11 Aug 2009 01:22:05 -0700 (MST) (envelope-from [e-mail])
Received: from wlan138179.mobiel.utwente.nl ([130.89.138.179]) by cola.rename-it.nl with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <[e-mail]>) id 1Mamc2-0000jt-M7 for [e-mail]; Tue, 11 Aug 2009 10:21:42 +0200
Message-ID: <[e-mail]>
Date: Tue, 11 Aug 2009 10:21:40 +0200
From: Stephan Bosch <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: [e-mail]
Subject: Question about ManageSieve capabilities
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-RenameIT-MailScanner-VirusScan: Found to be clean
X-RenameIT-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.849, required 5, autolearn=not spam, ALL_TRUSTED -0.40, AWL 1.15, BAYES_00 -2.60)
X-RenameIT-MailScanner-From: [e-mail]
X-Spam-Status: No
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

Recently, I noticed that it can be useful or even important to have the 
supported Sieve and ManageSieve capabilities depend on the authenticated 
user. Because the identity of the connected user is not known until the 
client authenticates, the capabilities reported upon connect and after 
authentication are going to differ.

Now I am wondering how to best implement a capability change upon 
authentication. According to section 1.8 of the draft, the capabilities 
are allowed to change after an AUTHENTICATE command, so there is no 
problem there. However, there is still the problem of reliably notifying 
the client that the capabilities have changed. After AUTHENTICATE this 
can happen with an unsolicited capability response directly after the 
command. However, the draft only mentions this in relation to the 
establishment of a SASL security layer.

Now I have a question:

Is the server allowed to send the unsolicited capability response after 
AUTHENTICATION also when just capabilities have changed and no SASL 
security layer has come into effect?

This may be an important notion, because client implementations may not 
expect this when it is not explicitly mentioned/allowed/prohibited in 
the specification.

So, for example, this is what I would like to do:

S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
S: "SIEVE" ""
S: "VERSION" "1.0"
S: OK
C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xu"
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
S: "SIEVE" "fileinto vacation relational copy date index enotify"
S: "MAXREDIRECTS" "10"
S: "NOTIFY" "mailto xmmp"
S: "VERSION" "1.0"
S: "OWNER" "[e-mail]"
S: OK "Logged in."

The alternative would be to rely upon the client to issue a CAPABILITY 
command. This is somewhat less reliable, as clients may refrain from 
doing so.

So, what's the best way to go here?

Regards,

Stephan










Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n71A7Q1K043302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Aug 2009 03:07:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n71A7Qcl043301; Sat, 1 Aug 2009 03:07:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-bw0-f227.google.com (mail-bw0-f227.google.com [209.85.218.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n71A6xZi043208 for <[e-mail]>; Sat, 1 Aug 2009 03:07:06 -0700 (MST) (envelope-from [e-mail])
Received: by bwz27 with SMTP id 27so1686909bwz.10 for <[e-mail]>; Sat, 01 Aug 2009 03:06:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mCjwysiEgyV7pqbn5CEfSrmQCCQCBVBmTX8pCux2YDw=; b=wLwpdC2hW20O8aR6pGLkSDLYGcBmXta9vAOcUxUG3IKWlAVHmi3cLggSCMIPFgNBn9 UpKEZhV7/QTivxWDIW60dEHcbCfXvEW/4CYRI9fY5pB/geM1cETCSpJ97TzWZKmB4cio O8uZUBsRtZNLTqjzCD/PaVSsKcXXZqevn2hKg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RFyBKyWGQsnP5Ook3U9xqYcDUCJpn3NatCk9XSWNo04P6IwECZSJRARYHP4Mt/QiN/ f7LsoQeJeAMYeoj5xGeegQeV5LcsELL8IzvHUO786rMs3bFnX2BoEV9DbfsqPUOl3N88 WkN4lh75eyypXCFwUMqZclbc08YBy+3eya4cY=
MIME-Version: 1.0
Received: by 10.204.53.136 with SMTP id m8mr210395bkg.109.1249121218596; Sat,  01 Aug 2009 03:06:58 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 1 Aug 2009 11:06:58 +0100
Message-ID: <[e-mail]>
Subject: Re: [draft-melnikov-sieve-external-lists] 2.4 Proposed Error Handling  Clarifications
From: Robert Burrell Donkin <[e-mail]>
To: Cyrus Daboo <[e-mail]>
Cc: [e-mail], Jeffrey Hutzelman <[e-mail]>, MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

(thanks to barry for his detailed post)

On Sat, Aug 1, 2009 at 8:08 AM, Cyrus Daboo<[e-mail]> wrote:
> Hi Robert,
>
> --On July 31, 2009 10:07:06 AM +0100 Robert Burrell Donkin
> <[e-mail]> wrote:
>
>>> I'm sure there will be a summary in the WG minutes, when they're done.
>>
>> i'm sure that there will
>>
>> it would have been polite to inform the mailing list that changes - of
>> a fundamental nature - had been agreed at the meeting, and that any
>> discussions on - or analysis of - the recently posted draft 00 would
>> be wasted
>
> Note that an agenda for the meeting was posted to the list in the week prior
> to the meeting for feedback and to give participants a heads-up on what is
> going to be discussed. Minutes for the meeting will be available in the next
> few weeks. In the meantime there are jabber logs and audio recordings that
> can be used to check on what happened.
>
> In general I would suggest that if you do plan a detailed review of a
> document (not prompted by say a WG last call), that it makes sense to first
> contact the authors either directly or via the list to check on the status
> of the document to make sure there are no queued up changes that may be of
> significance. That is certainly advisable at around the time of an IETF
> meeting where drafts are often updated.
>
> In any case, your feedback on this and other documents is appreciated. If
> you do think that changes to the WG process are needed, it would probably be
> best to bring that up on the general IETF discussion list or the apps area
> list as I don't think this WG behaves much differently from many others.

unfortunately, i'm running out of time :-/

this also isn't my battle

FWIW

the IETF has issues with it's current process, or at least the general
perception of it's process

i'm probably a little atypical in that i develop mostly enterprise
Java and am involved with Sieve through the FOSS library writing i do
for kicks. i've tried hard to persuade downstream application authors
to get involved with the work of this group without success. the
impression many have is that the IETF is now too vendor driven,
political and closed. it may well be that this is a problem of
perception - and not substance - but that makes it no less real.

AIUI the IETF now seems more meeting focussed than in the 90's (quite
possibly for very good reasons) but this means that - if the process
is going to be seen as inclusive and open - efforts need to be made to
reach out from the meeting to the wider public. i think barry's
suggestions about ways to widen participation at meetings are
definitely worthwhile. there are also some simple things that any WG
could do to reach out to those who participate just on the lists (a
few more posts - for example - just briefly explaining the process and
encouraging wider participation even at the cost of a small amount of
repitition for regular readers).

perhaps the mechanics of the editing process could also be useful
reviewed. a distribution version control system such as git could
lower the cost of participation.

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7179BTj035483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Aug 2009 00:09:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7179Bbb035482; Sat, 1 Aug 2009 00:09:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from daboo.name (daboo.name [151.201.22.177]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n71793Qe035472 for <[e-mail]>; Sat, 1 Aug 2009 00:09:09 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 629AE177A035; Sat,  1 Aug 2009 03:09:02 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUNJqnBNwswb; Sat,  1 Aug 2009 03:08:57 -0400 (EDT)
Received: from dhcp-50e5.meeting.ietf.org (unknown [77.241.97.148]) by daboo.name (Postfix) with ESMTP id 9FB50177A02D; Sat,  1 Aug 2009 03:08:55 -0400 (EDT)
Date: Sat, 01 Aug 2009 09:08:53 +0200
From: Cyrus Daboo <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
cc: [e-mail], Jeffrey Hutzelman <[e-mail]>, MTA filtering mailing list <[e-mail]>
Subject: Re: [draft-melnikov-sieve-external-lists] 2.4 Proposed Error Handling 	Clarifications
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size=1526
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Robert,

--On July 31, 2009 10:07:06 AM +0100 Robert Burrell Donkin 
<[e-mail]> wrote:

>> I'm sure there will be a summary in the WG minutes, when they're done.
>
> i'm sure that there will
>
> it would have been polite to inform the mailing list that changes - of
> a fundamental nature - had been agreed at the meeting, and that any
> discussions on - or analysis of - the recently posted draft 00 would
> be wasted

Note that an agenda for the meeting was posted to the list in the week 
prior to the meeting for feedback and to give participants a heads-up on 
what is going to be discussed. Minutes for the meeting will be available in 
the next few weeks. In the meantime there are jabber logs and audio 
recordings that can be used to check on what happened.

In general I would suggest that if you do plan a detailed review of a 
document (not prompted by say a WG last call), that it makes sense to first 
contact the authors either directly or via the list to check on the status 
of the document to make sure there are no queued up changes that may be of 
significance. That is certainly advisable at around the time of an IETF 
meeting where drafts are often updated.

In any case, your feedback on this and other documents is appreciated. If 
you do think that changes to the WG process are needed, it would probably 
be best to bring that up on the general IETF discussion list or the apps 
area list as I don't think this WG behaves much differently from many 
others.

-- 
Cyrus Daboo



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7171xf2035221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Aug 2009 00:01:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7171xvk035220; Sat, 1 Aug 2009 00:01:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-px0-f204.google.com (mail-px0-f204.google.com [209.85.216.204]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7171tbW035213 for <[e-mail]>; Sat, 1 Aug 2009 00:01:56 -0700 (MST) (envelope-from [e-mail])
Received: by pxi42 with SMTP id 42so979951pxi.29 for <[e-mail]>; Sat, 01 Aug 2009 00:01:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=26lb0j/jnQawTTjhM4W9Z7yPrfbgDi9kttBzYgec8BM=; b=F+OHC6bNctLce2vv/TS+RTNxhUhhtzIeTedQviw3kpZNbOyVQ5Ngv2IP2NXHrBHWPC EGyTNcPVgdqeNQ4Fd4uhM39wTFYrTIzRJS8u/WrLMhiSi7vDhWNN8VGMLEBfVFT6Rejv dchnpP0jaCVFZbqI/udtRsxYhDlEy1N3enNEk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=MAI0WbheT6cXzfWqBLIwTf6s29PgPj4fUUAkh73GdxMIvJFyZpqYyiqy0BlpdWtj3j HZmxvvuH0MOv0TCs3kfujryMB/2vH23U6Rm/33pNgtdZJ5Db3tdibC/Ht615IJkFuHaI yQguIDH2cCJ6E8pN4n+LK6VeOu01553yMUAFM=
MIME-Version: 1.0
Received: by 10.114.39.11 with SMTP id m11mr1865453wam.87.1249110115298; Sat,  01 Aug 2009 00:01:55 -0700 (PDT)
Reply-To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 1 Aug 2009 03:01:55 -0400
Message-ID: <[e-mail]>
Subject: Re: [draft-melnikov-sieve-external-lists] 2.4 Proposed Error Handling  Clarifications
From: Barry Leiba <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert, I thought a bit about whether to send this reply privately,
but decided that it's important to say it on the mailing list.  I'm
going to use "I" throughout, because I have no authorization to speak
for anyone else, but I think most of the working group participants
would agree with what I say here.

Let me start by saying that I very much appreciate the time you've put
into thoroughly reviewing the documents and thinking through the
protocols, and into the detailed responses.  I especially like it when
you've given a statement of what you want to change and why, followed
by a suggestion of specific text for the change.

I also appreciate that you've jumped in and started contributing
directly.  Of course, I don't know how long you might have been
lurking before you did that... but it's very common for people to be
"afraid" to join in, and I'm glad that you don't seem to be.

Please do not take brief responses or those that may seem somewhat
curt to be dismissive, angry, or otherwise in a "Why don't you go
away?" sort of sense.  We're all very busy, we've been discussing this
stuff for a long time, and sometimes our answers are an attempt to
blurt a response out and get back to something else, or are in
reaction to seeing something raised that we've beaten to death before.
 None of it means that we don't want and appreciate your
contributions.  Please try to assume the best intentions when you're
reading, and forgive abrupt-seeming text.

So if what I've said, in particular, has come across as snarky,
dismissive, or even outwardly nasty, please accept my apology for that
-- none of it was meant that way, and it's just a question of being
too quick, and a poor choice of wording.

While the official work of the working group, as in all of the IETF,
happens on the mailing list, that has to be put into perspective.  It
means that any decision made is reviewed and discussed here, but there
are often preliminary decisions made off-list.  Sometimes a couple of
participants will get into a side discussion on their own.  There are
the discussions in the face-to-face meetings.  All that is fine, and
the results can come to the mailing list in a number of ways: perhaps
as a summary of a discussion, perhaps as a new issue posted on its
own, perhaps as a new draft for people to review.

In the case of the Security Considerations section, for example, I
made an observation a couple of weeks ago similar to yours.  Alexey
gave me the source XML for the document and I did some editing and
rewriting, including gutting the Security Considerations section and
re-doing much of it.  That was well after the deadline for posting new
I-Ds before the meeting, and anyway, Alexey needed to review it
himself first.

The meeting in Stockholm then bashed out the URI issue -- taking your
earlier comments on that into consideration, I'll note -- and came up
with a change to propose to the list, from an idea of Jeff H's.  That
change needs to be put into draft text, which the working group can
then review here and, no doubt, tweak.

Note that the times leading up to, and during the IETF meeting weeks
are horrendously busy for many of us.  We can't have time to do
everything that needs to be done... and to give you an idea, my
calendar for the IETF week went from 9 a.m. some days and 7:30 a.m.
others, to around 10 p.m., including breakfast meetings, working
lunches, evening informal BOF sessions, and working dinners.  Almost
every session during the day had something I needed to go to, and I
often had things scheduled during the breaks -- find someone and talk
with him about something.  I had an hour and a half free on Thursday
afternoon, and that was all the free time for the week... and I even
wound up talking with a colleague during half of that period as well.

Yes, it would have been nice if we could have posted the interim I-D
candidate to the mailing list.  And yes, it would have been nice if
we'd posted a summary of the face-to-face session by, say, the next
morning, so you'd know what was discussed.  That they didn't happen
yet just speaks to how busy everyone's been.  It'll happen.

I-Ds are, by definition, "works in progress", and they're always
changing -- some more or less than others.  I, too, have had review
items that have been overtaken by events.  It doesn't mean the review
was wasted, and it doesn't mean that it wasn't wanted.  Take it as
acknowledgment that someone else also saw the same thing you did, or
something similar, and fix-ups crossed in the ether.

I'll add one more thing on timing:
Because of how the IETF meeting weeks work, and because the
high-bandwidth nature of the face-to-face discussions can result in
major changes to parts or all of a document, reviews posted to the
mailing list during the meeting week (especially late in the week) are
less likely to dovetail with the in-meeting discussion.  In contrast,
reviews posted the week before the meeting, or the week before that,
are particularly *useful*, because they can be discussed in the
meeting.

It would also be great if you could participate in the in-meeting
discussions through the remote-participation facilities -- jabber and
the live audio stream.  Many participants find them to work very
well... and the IETF is starting to experiment with using in-meeting
WebEx conferencing to try to make it even better.

In sum:
I really do want your contributions, and I hope we don't annoy you too
much with how we've come to say things over time.  I think you'll
really find this to be a group that works well together, makes
progress, and respects everyone's input.

Barry


For reference:
Jabber logs...
   General: http://jabber.ietf.org/logs/
   Sieve WG: http://jabber.ietf.org/logs/sieve/
   Sieve at IETF 75: http://jabber.ietf.org/logs/sieve/2009-07-29.txt
Audio streams...
   Live IETF 75 (quiet now, of course):
http://www.ietf.org/meeting/75/audio.html
   The stream for each session is archived somewhere, but I can't find
it just now.
Meeting materials...
   General: https://datatracker.ietf.org/meeting/75/materials.html
   Sieve WG: (above, search for "sieve")