RFC 5436 on Sieve Notification Mechanism: mailto

[[e-mail]]

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

        
        RFC 5436

        Title:      Sieve Notification Mechanism: mailto 
        Author:     B. Leiba, M. Haardt
        Status:     Standards Track
        Date:       January 2009
        Mailbox:    [e-mail], 
                    [e-mail]
        Pages:      12
        Characters: 26519
        Updates:    RFC3834

        I-D Tag:    draft-ietf-sieve-notify-mailto-10.txt

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

This document describes a profile of the Sieve extension for
notifications, to allow notifications to be sent by electronic mail.  
[STANDARDS TRACK]

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute



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 n113qsTA069944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 20:52:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n113qsg2069943; Sat, 31 Jan 2009 20:52:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n113qrYm069937 for <[e-mail]>; Sat, 31 Jan 2009 20:52:53 -0700 (MST) (envelope-from [e-mail])
Received: by bosco.isi.edu (Postfix, from userid 70) id 688502044BF; Sat, 31 Jan 2009 19:52:53 -0800 (PST)
To: [e-mail], [e-mail]
Subject: RFC 5437 on Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP)
From: [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
Date: Sat, 31 Jan 2009 19:52:53 -0800 (PST)
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>

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

        
        RFC 5437

        Title:      Sieve Notification Mechanism: Extensible Messaging 
                    and Presence Protocol (XMPP) 
        Author:     P. Saint-Andre, A. Melnikov
        Status:     Standards Track
        Date:       January 2009
        Mailbox:    [e-mail], 
                    [e-mail]
        Pages:      14
        Characters: 28448
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-sieve-notify-xmpp-09.txt

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

This document describes a profile of the Sieve extension for
notifications, to allow notifications to be sent over the Extensible
Messaging and Presence Protocol (XMPP), also known as Jabber.
[STANDARDS TRACK]

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute




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 n113qhQd069927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 20:52:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n113qhn8069926; Sat, 31 Jan 2009 20:52:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n113qhNx069920 for <[e-mail]>; Sat, 31 Jan 2009 20:52:43 -0700 (MST) (envelope-from [e-mail])
Received: by bosco.isi.edu (Postfix, from userid 70) id 1F96E2044BD; Sat, 31 Jan 2009 19:52:43 -0800 (PST)
To: [e-mail], [e-mail]
Subject: RFC 5436 on Sieve Notification Mechanism: mailto
From: [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
Date: Sat, 31 Jan 2009 19:52:43 -0800 (PST)
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>

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

        
        RFC 5436

        Title:      Sieve Notification Mechanism: mailto 
        Author:     B. Leiba, M. Haardt
        Status:     Standards Track
        Date:       January 2009
        Mailbox:    [e-mail], 
                    [e-mail]
        Pages:      12
        Characters: 26519
        Updates:    RFC3834

        I-D Tag:    draft-ietf-sieve-notify-mailto-10.txt

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

This document describes a profile of the Sieve extension for
notifications, to allow notifications to be sent by electronic mail.  
[STANDARDS TRACK]

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute




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 n113qeSE069916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 20:52:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n113qep1069915; Sat, 31 Jan 2009 20:52:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n113qTps069908 for <[e-mail]>; Sat, 31 Jan 2009 20:52:39 -0700 (MST) (envelope-from [e-mail])
Received: by bosco.isi.edu (Postfix, from userid 70) id 5A9452044BB; Sat, 31 Jan 2009 19:52:29 -0800 (PST)
To: [e-mail], [e-mail]
Subject: RFC 5435 on Sieve Email Filtering: Extension for Notifications
From: [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
Date: Sat, 31 Jan 2009 19:52:29 -0800 (PST)
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>

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

        
        RFC 5435

        Title:      Sieve Email Filtering: Extension for 
                    Notifications 
        Author:     A. Melnikov, Ed.,
                    B. Leiba, Ed.,
                    W. Segmuller, T. Martin
        Status:     Standards Track
        Date:       January 2009
        Mailbox:    [e-mail], 
                    [e-mail], 
                    [e-mail],  [e-mail]
        Pages:      17
        Characters: 36181
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-sieve-notify-12.txt

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

Users go to great lengths to be notified as quickly as possible that
they have received new mail.  Most of these methods involve polling
to check for new messages periodically.  A push method handled by the
final delivery agent gives users quicker notifications and saves
server resources.  This document does not specify the notification
method, but it is expected that using existing instant messaging
infrastructure such as Extensible Messaging and Presence Protocol
(XMPP), or Global System for Mobile Communications (GSM) Short
Message Service (SMS) messages will be popular.  This document
describes an extension to the Sieve mail filtering language that
allows users to give specific rules for how and when notifications
should be sent.  [STANDARDS TRACK]

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute




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 n0UMbne0008729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 15:37:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UMbneJ008728; Fri, 30 Jan 2009 15:37:49 -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-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UMbbAm008716 for <[e-mail]>; Fri, 30 Jan 2009 15:37:48 -0700 (MST) (envelope-from [e-mail])
Received: by bwz5 with SMTP id 5so310351bwz.10 for <[e-mail]>; Fri, 30 Jan 2009 14:37:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=UdECObcTU52rP9AT+58Ah1FhpA9Q0wFijWaT0GsAEIM=; b=V5+tLOS/MEF+UnbY5Iab4+Y31pF+vIq8RM2lbh0CIPfxysxlQosNiVjgdD/qoZLONk mA4rKmutQwFIoV0OcAwp5/5kAAYcXAVoV9U4VgoC4e4Xwfg9O+5IydikMnK0p85EWcwa Di7atUq4k50YmbIUmmgFmrs2breb3gBX20FVo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=xejQVIXjUOkVbo053t0T649m+o4FC5UJc3iwqKZ9C9Xevxelf0ljhpBapYn89tHJHk KjL3zKSQ5w3ESbJJcc2JbstCd46xkx+HaSA1fJCEyrXCwJI/kfji5QHAoCFXLkB//b5M kJMHQCoLBSTi0vC78rF7Tx+/5XZqtvZILA+YA=
MIME-Version: 1.0
Received: by 10.180.245.15 with SMTP id s15mr414950bkh.169.1233355056928; Fri,  30 Jan 2009 14:37:36 -0800 (PST)
Date: Fri, 30 Jan 2009 22:37:36 +0000
Message-ID: <[e-mail]>
Subject: [draft-freed-sieve-in-xml-02] Unknown Markup
From: Robert Burrell Donkin <[e-mail]>
To: 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>

(i left till last since i find this issue difficult to explain and
easy to misunderstand.
i have proposed the de facto status quo, as i see it. it is a
reasonable position
though probably not one that i would strongly advocate.)

Background
----------
A. Validation
 Validating that an arbitrary XML document satisfies an specific schema
 (as opposed to satisfying schema it declares) is - in practice -
 inconvenient. As a library author, I would not validate unless
 this was explicitly required by the specification for the following
 reasons:

 1. Though - in theory - modern validating parsers run almost
    as fast non-validating parser, there is still - in practice -
    a performance hit associated with obtaining a copy
    of the schema and parsing it. A catelog would be required for
    urn:ietf:params:xml:ns:sieve which is often inconvenient.

 2. When dealing with a mixed namespace, it is often inconvenient
    to validate unless a unified schema is available. When mixing
    a urn:ietf:params:xml:ns:sieve with unknown namespaces,
    obtaining such a schema would be difficult unless the document
    supplied one.

 3. Schema validation is not - in practice - quite as portable as
    might be desired.

 Instead, I would attempt to process the document and then stop
 the processing with an error if elements were encountered that
 could not be mapped.

 It is therefore likely that some processor implementations will choose
 not to validation using a schema.

B. Extension
 Future extension and versioning of schema is still an open problem.

 Suppose that a later revision of this specification adds attribute
 "foo" to "displayblock", and that this attribute may be safely
 ignored by any older processors which do not understand it. Older
 processor which validation the document will reject the it. Those
 which do not will work fine.

 The ability to extend the specification will therefore vary on the
 choice made by implementors to valid or not. This makes the
 ability to extend the specification less certain.

Issue
-----
The expected behaviour when a processor encounters a document
containing markup which it does not understand is not clear.

Proposal
--------
A processor MAY validate documents against the standard schema and MAY
reject any which do not conform. For any document that a processor does
not reject as invalid, any markup that the processor cannot understand
by reference to this specification MAY be discarded.

Rationale
---------
I think it is better to say something explicit about this issue. This
proposal is not one that I particularly favour but is the de facto status
quo as I see it. It is not unreasonable.



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 n0UJqg6U002040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 12:52:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UJqgRN002039; Fri, 30 Jan 2009 12:52:42 -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-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UJqell002032 for <[e-mail]>; Fri, 30 Jan 2009 12:52:41 -0700 (MST) (envelope-from [e-mail])
Received: by bwz5 with SMTP id 5so239289bwz.10 for <[e-mail]>; Fri, 30 Jan 2009 11:52:39 -0800 (PST)
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:content-type :content-transfer-encoding; bh=vVGvlUb9LKCXbzjUnzbjhOBW7p9cCdHhvhbXm7nFYnA=; b=i3Vnex504B87XrlcRNLldaJcUwmMhezuRQn0/Ezif2VcaD7zJlSkJ5sxd2ITY7gQJH zS4zdDGYkKoWk72QYMm99My9C2mLZsAF+KtoHiZD2DH6Xgr+9VxrATK0+az1er1wuqJt SJHi+TTJBLCipzF0tB32LdDGjVUATioglcXbM=
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 :content-type:content-transfer-encoding; b=jGHas3o5TO6DPgIUAnP9tRvytTRRNNH4SDhOiOnfL0fPoK9rjcZM5jGdO0nlw2eEdC YK3Lx7lP/MxHFghWFvIlRWdG/y9RYDaCGGBVoPJddBzwDpITnQnUGstrCBg0gesBWwkU QxzfpxbALYEpdo3qyuahddc+5Q7hrJh/9AIj0=
MIME-Version: 1.0
Received: by 10.181.216.14 with SMTP id t14mr551635bkq.8.1233345159285; Fri,  30 Jan 2009 11:52:39 -0800 (PST)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Fri, 30 Jan 2009 19:52:39 +0000
Message-ID: <[e-mail]>
Subject: Re: [draft-freed-sieve-in-xml-02] Escaping "*/" In Structured  Comments
From: Robert Burrell Donkin <[e-mail]>
To: 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>

On Fri, Jan 30, 2009 at 7:09 PM, Philip Guenther
<[e-mail]> wrote:
> On Fri, 30 Jan 2009, Robert Burrell Donkin wrote:
> ...
>> Proposal
>> --------
>> To "4.2. Structured Comments" Add:
>>
>>  If "*/" is found in the XML content, when mapped into a comment it
>>  would prematurely terminate that comment. Escaping of this sequence
>>  would often be inconvenient for processors. Editors SHALL NOT include
>>  "*/" within displayblock, displaydata or foreign markup. Processors MAY
>>  regard documents containing "*/" in foreign markup, displayblock
>>  or displaydata as invalid.
>
> Ick.  Wouldn't it be better to tell processors to generate '#' style
> comments instead of /*...*/ style comments, at least in that case?

better for some editors but worse for some processors and line endings
would also need some thought. this would be tricky to implement in
XSLT (say).

i think it not unreasonable to expect sieve editors to adopt a
meta-data schema that plays well with Sieve

>> To "5. Security Considerations" Add:
>>
>>  Little effective protection can be offered by a processor to the user
>>  of a malicious editor.
>
> How is this specific to sieve-in-xml and not just a general consideration
> for anyone using any editor for any purpose?

yes, it is a general consideration. i thought the rest of that section similar.

- 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 n0UJICWE000756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 12:18:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UJICcP000755; Fri, 30 Jan 2009 12:18:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UJI0Zo000747 for <[e-mail]>; Fri, 30 Jan 2009 12:18:11 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id C00D74AC5B; Fri, 30 Jan 2009 20:17:59 +0100 (CET)
Received: from [e-mail] (HELO lochnagar) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1233343079-9030-1/6/97 (3 recipients); Fri, 30 Jan 2009 20:17:59 +0100
Message-Id: <7BYuAbmrBYL+LrlFbeaiTA.md5@lochnagar>
Date: Fri, 30 Jan 2009 20:18:40 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: [draft-freed-sieve-in-xml-02] Emphasis Whitespace Preservation
Cc: Robert Burrell Donkin <[e-mail]>, Ned Freed <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
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>

Ned Freed writes:
> In any case, I agree with you that emphasizing this is a good idea and 
> will add the suggested requirement to the specification.

An example using vacation mighth also help, perhaps vacation :text since 
trimming whitespace often $#@$#@$! breaks that.

Arnt



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 n0UJ9U8w000298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 12:09:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UJ9UhO000297; Fri, 30 Jan 2009 12:09:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UJ9JbS000283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 30 Jan 2009 12:09:29 -0700 (MST) (envelope-from [e-mail])
Received: from spork.sendmail.com (tls.sendmail.com [209.246.26.41]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id n0UJCgcG029736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 Jan 2009 11:12:42 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1233342762; bh=3+wtNDIiHKpYLy5AnYidJB22xSvJtVnCEzlw ui6iz1Y=; h=Received:X-DKIM:DKIM-Signature:Date:From:X-X-Sender:To: cc:Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type:X-MM-Ex-RefId; b=YmaZr9z3UOVOxkKtm0GT8yi Evnpm00j5bt8yjKAVuXi2X0/BxxcTxshktV0rYaJiORWPLrpx6ojGmKhTTkkNK+ZmRi ds1CcYCc78vKXG7BcODDfi2vdVEMIOipU3RHQDK9K2+5oK7SqSeL7Lr++tgu/4CX+r5 VMun+Vmsjk0SWg=
Received: from [10.210.202.20] ([10.210.202.20]) (authenticated bits=0) by spork.sendmail.com (Switch-3.3.3mp/Switch-3.3.2mp) with ESMTP id n0UJ9EZD012563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 11:09:15 -0800
X-DKIM: Sendmail DKIM Filter v2.5.6 spork.sendmail.com n0UJ9EZD012563
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=spork.dkim; t=1233342556; bh=3+wtNDIiHKpYLy5AnYidJB22xSvJtVnCEzlw ui6iz1Y=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID: References:MIME-Version:Content-Type; b=ZcnPPW0OI+VfNmaBFkLcFKpBSZ vir7RnBYo9a0Sr95NtTKEoXYOW1jiPJ7A1ZfShtpTA/zDVsf9wVB8wbAAhjHE9B7BQI csAgFuq5TDdYR6mOqEVuhrCq0aUaaPwFbTvhkL6bdvoZYrDHQx4Cjvyq9aDxitIp65t wqanutDO8o0=
Date: Fri, 30 Jan 2009 11:09:14 -0800
From: Philip Guenther <[e-mail]>
X-X-Sender: [e-mail]
To: Robert Burrell Donkin <[e-mail]>
cc: MTA filtering mailing list <[e-mail]>
Subject: Re: [draft-freed-sieve-in-xml-02] Escaping "*/" In Structured Comments
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
User-Agent: Alpine 2.00 (BSO 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MM-Ex-RefId: 149371::090130110915-1112CB90-546C33EF/0-0/0-1
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>

On Fri, 30 Jan 2009, Robert Burrell Donkin wrote:
...
> Proposal
> --------
> To "4.2. Structured Comments" Add:
> 
>  If "*/" is found in the XML content, when mapped into a comment it
>  would prematurely terminate that comment. Escaping of this sequence
>  would often be inconvenient for processors. Editors SHALL NOT include
>  "*/" within displayblock, displaydata or foreign markup. Processors MAY
>  regard documents containing "*/" in foreign markup, displayblock
>  or displaydata as invalid.

Ick.  Wouldn't it be better to tell processors to generate '#' style 
comments instead of /*...*/ style comments, at least in that case?


> To "5. Security Considerations" Add:
> 
>  Little effective protection can be offered by a processor to the user
>  of a malicious editor.

How is this specific to sieve-in-xml and not just a general consideration 
for anyone using any editor for any purpose?


Philip Guenther



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 n0UJ8WgQ000262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 12:08:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UJ8WYv000261; Fri, 30 Jan 2009 12:08:32 -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 n0UJ8Ut8000254 for <[e-mail]>; Fri, 30 Jan 2009 12:08:30 -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]; Fri, 30 Jan 2009 11:08:27 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 30 Jan 2009 11:08:24 -0800 (PST)
Date: Fri, 30 Jan 2009 10:53:09 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: [draft-freed-sieve-in-xml-02] Emphasis Whitespace Preservation
In-reply-to: "Your message dated Fri, 30 Jan 2009 10:42:23 -0800" <[e-mail]>
To: Aaron Stone <[e-mail]>
Cc: Robert Burrell Donkin <[e-mail]>, MTA filtering mailing list <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[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>

> Also, the RFC Editor will want to add Oxford commas and quotes around
> "str", "num", and "tag" for clarity :-)

Yes, I'm well aware of the RFC Editor's fondness for Oxford commas, so I try to
include them when I'm writing specifications even though I generally don't use
them in other contexts. If you spot any place I've left out one of these commas
let me know and I'll insert it. (Minimizing the number of changes the RFC
Editor does makes the AUTH48 process go smoother.)

As for Oxford quotes, I'm not entirely clear on the convention the RFC Editor
prefers, so I looked at a few published RFCs. It seems the general idea is to
quote it the first time it appears (but not counting an appearance in a section
title) but not subsequently. I'll try and follow that practice in the next
revision.

				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 n0UIhJIS099210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 11:43:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UIhJFC099209; Fri, 30 Jan 2009 11:43:19 -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 n0UIhI1t099203 for <[e-mail]>; Fri, 30 Jan 2009 11:43:18 -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]; Fri, 30 Jan 2009 10:43:16 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 30 Jan 2009 10:43:14 -0800 (PST)
Date: Fri, 30 Jan 2009 10:41:01 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: [draft-freed-sieve-in-xml-02] Emphasis Whitespace Preservation
In-reply-to: "Your message dated Fri, 30 Jan 2009 17:27:44 +0000" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
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>

> Issue
> -----
> Implicit whitespace preservation.

> Original
> --------
> In "4. XML Representation of Sieve"

>   String, number, and tag arguments are represented as str, num, and
>   tag elements respectively.  The actual string, number, or tag
>   identifier appears as text inside the element.  None of these
>   elements have any defined attributes.  Several examples of arguments
>   have already appeared in the preceding control, action and test
>   examples.

> Proposal
> --------
>   String, number, and tag arguments are represented as str, num, and
>   tag elements respectively.  The actual string, number, or tag
>   identifier appears as text inside the element.  None of these
>   elements have any defined attributes.  Several examples of arguments
>   have already appeared in the preceding control, action and test
>   examples. Any whitespace in the str body content MUST be preserved
>   by the processor.


> Rationale
> ---------
> This isn't a major issue but based on experience with HTML, developers
> too often assume that whitespace should be trimmed. It is therefore
> worthwhile emphasizing explicitly that whitespace is expected to be
> preserved.

Yeah, it sort of falls out of the whole empty whitespace text node thing and
how whitespace is dealt with in stylesheets. In any case, I agree with you that
emphasizing this is a good idea and will add the suggested requirement to
the specification.

				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 n0UIdNuV099033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 11:39:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UIdN1l099032; Fri, 30 Jan 2009 11:39:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UIdDh7099023 for <[e-mail]>; Fri, 30 Jan 2009 11:39:23 -0700 (MST) (envelope-from [e-mail])
Received: from serendipity.cx (unknown [10.10.10.34]) by mail.serendipity.cx (Postfix) with ESMTP id A4EA62936; Fri, 30 Jan 2009 10:42:58 -0800 (PST)
MIME-Version: 1.0
Date: Fri, 30 Jan 2009 10:42:23 -0800
From: Aaron Stone <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
Subject: Re: [draft-freed-sieve-in-xml-02] Emphasis Whitespace Preservation
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>
X-Sender: [e-mail]
User-Agent: RoundCube Webmail/0.2
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
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>

On Fri, 30 Jan 2009 17:27:44 +0000, Robert Burrell Donkin
<[e-mail]> wrote:
> Issue
> -----
> Implicit whitespace preservation.
> 
> Original
> --------
> In "4. XML Representation of Sieve"
> 
>   String, number, and tag arguments are represented as str, num, and
>   tag elements respectively.  The actual string, number, or tag
>   identifier appears as text inside the element.  None of these
>   elements have any defined attributes.  Several examples of arguments
>   have already appeared in the preceding control, action and test
>   examples.
> 
> Proposal
> --------
>   String, number, and tag arguments are represented as str, num, and
>   tag elements respectively.  The actual string, number, or tag
>   identifier appears as text inside the element.  None of these
>   elements have any defined attributes.  Several examples of arguments
>   have already appeared in the preceding control, action and test
>   examples. Any whitespace in the str body content MUST be preserved
>   by the processor.
> 
> 
> Rationale
> ---------
> This isn't a major issue but based on experience with HTML, developers
> too often assume that whitespace should be trimmed. It is therefore
> worthwhile emphasizing explicitly that whitespace is expected to be
> preserved.

+1, whitespace should be preserved for string arguments.

Also, the RFC Editor will want to add Oxford commas and quotes around
"str", "num", and "tag" for clarity :-)

Aaron



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 n0UIcgdj099005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 11:38:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UIcgXQ099004; Fri, 30 Jan 2009 11:38:42 -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 n0UIcfm5098998 for <[e-mail]>; Fri, 30 Jan 2009 11:38:41 -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]; Fri, 30 Jan 2009 10:38:39 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 30 Jan 2009 10:38:37 -0800 (PST)
Date: Fri, 30 Jan 2009 10:19:46 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: [draft-freed-sieve-in-xml-02] Minor Improvements
In-reply-to: "Your message dated Fri, 30 Jan 2009 16:39:32 +0000" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
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>

> (Some minor suggestions, typos, etc. I've batched these up since they
> are not substantial.)

> In "3. Grammatical structure of Sieve"
> ======================================
> Original
> --------
>    Finally, comments are allowed between lexical elements in a Sieve
>    script.  It is very important that comments be preserved in the XML
>    representation.

> Comment
> -------
> This is covered later but perhaps a little justification should be
> offered at this point for the last remark

> Suggested
> ---------
>    Finally, comments are allowed between lexical elements in a Sieve
>    script. One important use case for comments is encoding meta-data
>    about the script, a facility which is lacking in the Sieve language.
>    Therefore comments should be preserved in the XML representation.

Good idea. I'll add this or something very close to it.

> In "4.1. XML Display Directives"
> ================================
> Original
> --------
>    However, such information can be represented in XML very easily so it
>    makes sense to define a framework to do this as part of the XML
>    format.  Implementations may choose to use structured comments to
>    retain this information when the script is converted to normal Sieve
>    format.

> Comment
> -------
> I think "may" should be "MAY"

> Suggested
> ---------
>    However, such information can be represented in XML very easily so it
>    makes sense to define a framework to do this as part of the XML
>    format.  Implementations MAY choose to use structured comments to
>    retain this information when the script is converted to normal Sieve
>    format.

Seems reasonable. Changed.

> In "4.2. Structured Comments"
> =============================
> Original
> --------
>    2.  Displaydata elements are placed in Sieve bracketed comments
>        begining with the string "/* [|" and ending with the string "|]
>        */".

> Comments
> --------
> Typo (begining)
> Easier to read when quoted text is not split

> Suggested
> ---------
>    2.  Displaydata elements are placed in Sieve bracketed comments
>        beginning with the string "/* [|" and ending with the string
>        "|] */".

Good catch - since I'm usually looking at the XML source I tend to miss stuff
like this in the final output. Unfortunately AFAIK xml2fc doesn't have a
"nonbreaking space" construct available, so I had to reword the sentence to get
the break to appear in the right place.

Of course the RFC Editor gets a crack at this, and has been known to reword
things, so this problem may reappear. I'll try to be alert to it during the
final approval process so we don't end up with this problem in the RFC.

> Original
> --------
>    3.  The begininng of a displayblock element is mapped to a bracketed
>        Sieve comment beginning with the string "/* [*" which then lists
>        any displayblock attribute names and values in XML format.  The
>        end of a displaydata element is mapped to a comment of the form
>        "/* *] */".

> Comments
> --------
> Typo (begininng)

> Suggested
> ---------
>    3.  The beginning of a displayblock element is mapped to a bracketed
>        Sieve comment beginning with the string "/* [*" which then lists
>        any displayblock attribute names and values in XML format.  The
>        end of a displaydata element is mapped to a comment of the form
>        "/* *] */".

Fixed.

Thanks for the review. I'll post a revised draft in a day or to that includes
these and a few other fixes.

				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 n0UHRtQV095348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 10:27:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UHRtSI095347; Fri, 30 Jan 2009 10:27:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.240]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UHRi7B095331 for <[e-mail]>; Fri, 30 Jan 2009 10:27:54 -0700 (MST) (envelope-from [e-mail])
Received: by rv-out-0708.google.com with SMTP id c5so618129rvf.34 for <[e-mail]>; Fri, 30 Jan 2009 09:27:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=1DJTmOraVLdpkYHw7Jg8cADhEjr/D7/723zfeMDIwcE=; b=L+7ctksUZsfpuSFaXkJWwCqwwu9/dDVVzY+cXcCGTZrIG0UKtveGTtOlvO0Ln6SkJF EpoxAuTJ4bBkdCwvxWNu3UCRPDc7zkYstkiwhOjPGdqWtsKb+M5feKd/QmJ6Omd7ZQ4W 9BrrW+JNles0u28ru4t2iGelEz4Z9RrDbIiqs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=tufFfjwz6svNSysCvRk6rbZXs6mkUIFtcOzLLXDDMJ+ZS8AxoM8ENCvwNa/1pyP82o qWLP2XpRRjsD7yEfoo1MV7ZH8ei+6LHYh1dTJ0rGT/H/TTO0wdExyQY9G4XFwnOBnSBC meVxaQXJRMsVIH+MmO3ei4Etjs5kTLmdLhpMg=
MIME-Version: 1.0
Received: by 10.114.168.1 with SMTP id q1mr550867wae.152.1233336464213; Fri,  30 Jan 2009 09:27:44 -0800 (PST)
Date: Fri, 30 Jan 2009 17:27:44 +0000
Message-ID: <[e-mail]>
Subject: [draft-freed-sieve-in-xml-02] Emphasis Whitespace Preservation
From: Robert Burrell Donkin <[e-mail]>
To: 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>

Issue
-----
Implicit whitespace preservation.

Original
--------
In "4. XML Representation of Sieve"

  String, number, and tag arguments are represented as str, num, and
  tag elements respectively.  The actual string, number, or tag
  identifier appears as text inside the element.  None of these
  elements have any defined attributes.  Several examples of arguments
  have already appeared in the preceding control, action and test
  examples.

Proposal
--------
  String, number, and tag arguments are represented as str, num, and
  tag elements respectively.  The actual string, number, or tag
  identifier appears as text inside the element.  None of these
  elements have any defined attributes.  Several examples of arguments
  have already appeared in the preceding control, action and test
  examples. Any whitespace in the str body content MUST be preserved
  by the processor.


Rationale
---------
This isn't a major issue but based on experience with HTML, developers
too often assume that whitespace should be trimmed. It is therefore
worthwhile emphasizing explicitly that whitespace is expected to be
preserved.



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 n0UHDNOX094375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 10:13:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UHDNn7094374; Fri, 30 Jan 2009 10:13:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UHDC8O094358 for <[e-mail]>; Fri, 30 Jan 2009 10:13:23 -0700 (MST) (envelope-from [e-mail])
Received: by wa-out-1112.google.com with SMTP id k17so256069waf.26 for <[e-mail]>; Fri, 30 Jan 2009 09:13:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=fqi9tekbNSzv27XCrHnbSmp1f14xToAQMYzQBPiSN7w=; b=S95t8dTqCoX5XtKC1IYYKFVpadpIo9qJKvRaPuRBNXCF9qQC/sIV65rbxY11ty1WVG i/zDFrXBsgjspOJANl4GQjYeTFmhjQL8Ruj4WG7n5ZI4LlzZfbEfNL4AlWUA+3phzDhM 3snuN0VHKKPCClR1MGKS6v78wtt/mYoH6Y1cc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=M2jIhQ2A7Z0T6MAg3zjfKTNMO41QY9x0tPtvFZq1m7d7cqZJjcowpCGyE+U71kUJph mKoQGExA1gU+6FNby6TB01yB8LzZ4hOZk+YxGPtHiBqzGjoTeBON31gfU8UyLe0759ci +IEzNS8uzwdAP5LlZ6CyAOIfWuvZ7Jw24pzBc=
MIME-Version: 1.0
Received: by 10.114.197.10 with SMTP id u10mr908942waf.174.1233335592332; Fri,  30 Jan 2009 09:13:12 -0800 (PST)
Date: Fri, 30 Jan 2009 17:13:12 +0000
Message-ID: <[e-mail]>
Subject: [draft-freed-sieve-in-xml-02] Escaping "*/" In Structured Comments
From: Robert Burrell Donkin <[e-mail]>
To: 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>

Issue
-----
No discussion is made about the merits of escaping content which will
be transformed into structured comments. For example, the following
fragment might be used to smuggle content into the script:

<displayblock><trouble>*/
if header :contains "from" "[e-mail]" {
     discard;
}
/*</trouble></displayblock>

Proposal
--------
To "4.2. Structured Comments" Add:

 If "*/" is found in the XML content, when mapped into a comment it
 would prematurely terminate that comment. Escaping of this sequence
 would often be inconvenient for processors. Editors SHALL NOT include
 "*/" within displayblock, displaydata or foreign markup. Processors MAY
 regard documents containing "*/" in foreign markup, displayblock
 or displaydata as invalid.

To "5. Security Considerations" Add:

 Little effective protection can be offered by a processor to the user
 of a malicious editor.

Rationale
---------
Only limited protection can be offered to the user by a processor against
a malicious or buggy editor. The effectiveness of that protection should
b weighed against the implementation complexity. Escaping is inconvenient
for processors and introduces complexity for very little security gain.
Editors control the meta-data they wish to insert and it is simpler just
to ensure that this meta-data does not contain "*/".



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 n0UH4YXp093658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 10:04:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UH4Ywj093657; Fri, 30 Jan 2009 10:04:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UH4N2v093638 for <[e-mail]>; Fri, 30 Jan 2009 10:04:33 -0700 (MST) (envelope-from [e-mail])
Received: by wf-out-1314.google.com with SMTP id 25so559906wfc.28 for <[e-mail]>; Fri, 30 Jan 2009 09:04:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=tA/F2TE5sxdi71SjK6T+TtRX1ln9Ro3fOjpMYPnWgIc=; b=Vwy6tiM2eqqsm1Lsj/FtxP/1Cmf84XZ8eH0yUB+bY4UOlxFEtEtUQU7DcIFuXZcrTA VEby6Cm+HbIABIh4AM48fzIlk/xy5pNIY1oYEwemUXQ2TzbqimNuygD3epgSR1g+6WGb LBTpGowq0wqV4CcToZCcIrH+2UKwLzE+d4QwI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=cF43DN0JuHBiDf48tagxGv8zv1SCR/WFKTiAhVZxX4t/jNwKvBu6RtVBHWSc03IQZJ 9s0Bw8m2RT+C0kku903ZmIuZ+CByOdeFcKKNlZMkiBUE03Nxv37buhOSN4C7YpLxiKVR xi48mxVPCC6t7b3/5MLVA78Mz1kRkKiWBTrX0=
MIME-Version: 1.0
Received: by 10.115.91.11 with SMTP id t11mr909834wal.117.1233335062439; Fri,  30 Jan 2009 09:04:22 -0800 (PST)
Date: Fri, 30 Jan 2009 17:04:22 +0000
Message-ID: <[e-mail]>
Subject: [draft-freed-sieve-in-xml-02] Preservation Of Meta-Data During An  Editing Session
From: Robert Burrell Donkin <[e-mail]>
To: 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>

Issue
-----
Clarify expectations of meta-data preservation during editing.

Proposal
--------

To "4.1. XML Display Directives" add:

  Editors MAY use displayblock, displaydata and foreign namespaces to associate
  meta-data which SHOULD be preserved by the processor during Sieve script
  translation. Some editors find it inconvenient to preserve this
additional data
  during an editing session. Editors MAY preserve this data during an editing
  session for compatibility with other editors.

Rationale
---------

Use Case A:
 A class of XML editors work on document structure, as expressed by
the schema. These
 editors find it inconvenient to work with schema containing elements
not intended
 to be user editable.

Use Case B:
 An editor may find it difficult to reconcile it's own meta-data with
meta-data added
 previously by a different implementation. This makes it difficult to preserve
 foreign meta-data during an editing session.

The proposal clarifies this issue by recommending (but not insisting) that
editors preserve existing meta-data during an editing session.



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 n0UGhXIg092586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 09:43:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UGhXOW092585; Fri, 30 Jan 2009 09:43:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UGhM1o092572 for <[e-mail]>; Fri, 30 Jan 2009 09:43:32 -0700 (MST) (envelope-from [e-mail])
Received: by wa-out-1112.google.com with SMTP id k17so250102waf.26 for <[e-mail]>; Fri, 30 Jan 2009 08:43:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=Lq2Crbp0ASJxx43tJ1EcZ3hFpr4qEkiXAugdr8O5+fU=; b=f9lax3iuXVmPUsBniWN9O1IFVpeb6vrudSkoAelE42uxlgewWasvsEKeiS1/Hd931+ haN/GjoEwwkDpsswydsuLqYAwCqJrCmJGOG5UhU+EkleB+WQUNsIEK51zx736G+GWBXq W3qZ5UgkEBvTGzOoCcsuaoXTMuaSHEewcOGCM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=Uy0MRf7dPBu7bvvvg2s7FlNJsH1Ts5Oj9SJHSHLcfHWFCV8HWhhMslYs294ZUtQnVk I7Nl9i8UtKqROMu3FEeBkB6I9PtksqzTdewBarJL3w2w++VAO5nfChmQy6/1yDrzxXbE HyNST93opFObWYXUk5GtvNY4Z7yL7xxn+ZUOE=
MIME-Version: 1.0
Received: by 10.114.67.2 with SMTP id p2mr888064waa.208.1233333802009; Fri, 30  Jan 2009 08:43:22 -0800 (PST)
Date: Fri, 30 Jan 2009 16:43:21 +0000
Message-ID: <[e-mail]>
Subject: [draft-freed-sieve-in-xml-02] Commentary On displayblock and  displaydata Elements
From: Robert Burrell Donkin <[e-mail]>
To: 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>

I regard displayblock and displaydata as inelegant and I do not see
their necessity.

However, I am satisfied that the new draft both describes them well,
provides a rationale
for their existance, and specifies a clear and reasonable way to map
them into a Sieve script.
As an library author, this is sufficient.

I therefore have no complaint about their inclusion in the draft.

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 n0UGditK092311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 09:39:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UGdiBe092309; Fri, 30 Jan 2009 09:39:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.250]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UGdWvV092298 for <[e-mail]>; Fri, 30 Jan 2009 09:39:43 -0700 (MST) (envelope-from [e-mail])
Received: by rv-out-0708.google.com with SMTP id c5so596122rvf.34 for <[e-mail]>; Fri, 30 Jan 2009 08:39:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=gn+YbRYJbL9eETbtqe2x6gq8UvsXfwUnKqUqQPJfQDM=; b=ADHpcDMrwJAg6mFOJRZT/KhkZsXvAfDCfW+rAoy0Xes4o/D2TUe5qSdGHOTbRzW9So 44OOehWrKd4cqwodqnMHU2zSjVndgZj0rtLv4JVRTCSKyhkTSZiKmMbxcckIGzlZp+Nw BFUSArKiCs71zRIqY9ypXPSTYGKGc4jl3Xe5Y=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=f9z8TXd4OLU05spJkGgeFW9ued0atW/P4sHzhSGIMuZKHSgfQyJ/2kMCjduFidVmI8 OlyYiVTxieblYjzAeEdXDK/xO4uIGgqhnee8pmN02+luKLelZbT1OoDvJzxHHR+CijYe nEhx5sqq5YdftQVMPWi5qGWIYHBLJhRSOBPTQ=
MIME-Version: 1.0
Received: by 10.114.111.1 with SMTP id j1mr891743wac.153.1233333572575; Fri,  30 Jan 2009 08:39:32 -0800 (PST)
Date: Fri, 30 Jan 2009 16:39:32 +0000
Message-ID: <[e-mail]>
Subject: [draft-freed-sieve-in-xml-02] Minor Improvements
From: Robert Burrell Donkin <[e-mail]>
To: [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>

(Some minor suggestions, typos, etc. I've batched these up since they
are not substantial.)

In "3. Grammatical structure of Sieve"
======================================
Original
--------
   Finally, comments are allowed between lexical elements in a Sieve
   script.  It is very important that comments be preserved in the XML
   representation.

Comment
-------
This is covered later but perhaps a little justification should be
offered at this point for the last remark

Suggested
---------
   Finally, comments are allowed between lexical elements in a Sieve
   script. One important use case for comments is encoding meta-data
   about the script, a facility which is lacking in the Sieve language.
   Therefore comments should be preserved in the XML representation.


In "4.1. XML Display Directives"
================================
Original
--------
   However, such information can be represented in XML very easily so it
   makes sense to define a framework to do this as part of the XML
   format.  Implementations may choose to use structured comments to
   retain this information when the script is converted to normal Sieve
   format.

Comment
-------
I think "may" should be "MAY"

Suggested
---------
   However, such information can be represented in XML very easily so it
   makes sense to define a framework to do this as part of the XML
   format.  Implementations MAY choose to use structured comments to
   retain this information when the script is converted to normal Sieve
   format.


In "4.2. Structured Comments"
=============================
Original
--------
   2.  Displaydata elements are placed in Sieve bracketed comments
       begining with the string "/* [|" and ending with the string "|]
       */".

Comments
--------
Typo (begining)
Easier to read when quoted text is not split

Suggested
---------
   2.  Displaydata elements are placed in Sieve bracketed comments
       beginning with the string "/* [|" and ending with the string
       "|] */".

Original
--------
   3.  The begininng of a displayblock element is mapped to a bracketed
       Sieve comment beginning with the string "/* [*" which then lists
       any displayblock attribute names and values in XML format.  The
       end of a displaydata element is mapped to a comment of the form
       "/* *] */".

Comments
--------
Typo (begininng)

Suggested
---------
   3.  The beginning of a displayblock element is mapped to a bracketed
       Sieve comment beginning with the string "/* [*" which then lists
       any displayblock attribute names and values in XML format.  The
       end of a displaydata element is mapped to a comment of the form
       "/* *] */".



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 n0TMEZIN043196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 15:14:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0TMEZSp043195; Thu, 29 Jan 2009 15:14:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.184]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TMEN5k043173 for <[e-mail]>; Thu, 29 Jan 2009 15:14:34 -0700 (MST) (envelope-from [e-mail])
Received: by mu-out-0910.google.com with SMTP id w9so116064mue.4 for <[e-mail]>; Thu, 29 Jan 2009 14:14:22 -0800 (PST)
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:content-type :content-transfer-encoding; bh=3PBdw+5SCKZg7GcFz7d5IboHPg9leuIA0YtYsp0We5Q=; b=eqrltJZpwzsZFFErny5UAcr0n1ZcVBqvlzyVHn5YaHA8Fqe+NyHz2ZYNLO3fMZB6tX 3nsh1pDQ3uBAkixX5unsBBVb9JEVToWZMP9gHUeQRVsKBDYqBlzb2TJcXRFFovUkr6im 3GKWZmd5fb5VlTAKGiu5Dq2fNNIM1BASE31ig=
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 :content-type:content-transfer-encoding; b=IMruhqXD2WXMQj0R36k85JTmcKiuQw+5GyC+grz758gjuMhCo/5MVvDp0aKLK2sm+d MKa9HbIO5rdxYoURJ7o3kmOQfBVccSdeswb4ftKv4umhobcOKNIC7mdq71bFj3Z0fYqY yXpONfICYI53eHqDVsC9m563hITLw6EKRknCQ=
MIME-Version: 1.0
Received: by 10.181.58.9 with SMTP id l9mr173259bkk.98.1233267262591; Thu, 29  Jan 2009 14:14:22 -0800 (PST)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 29 Jan 2009 22:14:22 +0000
Message-ID: <[e-mail]>
Subject: Re: WGLC on draft-freed-sieve-in-xml-02.txt
From: Robert Burrell Donkin <[e-mail]>
To: [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>

On Thu, Jan 15, 2009 at 10:43 PM, Alexey Melnikov
<[e-mail]> wrote:
>
> Hi folk,
> With my co-chair hat on:
>
> This message officially starts the Sieve Working Group Last Call for the
>  following document:
>
> Sieve Email Filtering:  Sieves and display directives in XML
>
> <http://www.ietf.org/internet-drafts/draft-freed-sieve-in-xml-02.txt>
>
> The Working Group Last Call for this document starts on January 15th and
> will end on January 30th. Please send any comments to the Sieve mailing list
> or to the document authors. If you chose to do the latter, please CC both
> Cyrus Daboo <[e-mail]> and Alexey Melnikov
> <[e-mail]>. Reviews that found no issues are also welcomed,
> so if you review the document and find it acceptable, please let the mailing
> list/authors+chairs know as well.
>
> Also, in order to simplify tracking of various issues, please clearly mark
> each issue in the message (ideally in the subject header field, sending 1
> issue per email message). Also, I would strongly encourage to provide
> specific suggestions for solving issues you've raised (or at least show an
> example of how your issue can be addressed).

i'm in general much happier with this draft. i have a small number of
issues which i'll raise in separate mails tomorrow.

- 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 n0MEZPNL070916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2009 07:35:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0MEZPfg070915; Thu, 22 Jan 2009 07:35:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0MEZCl4070902 for <[e-mail]>; Thu, 22 Jan 2009 07:35:23 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id CC89D4AC44; Thu, 22 Jan 2009 15:35:11 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1232634911-9030-1/6/10 for [e-mail]; Thu, 22 Jan 2009 15:35:11 +0100
Message-Id: <4fmKg5w/[e-mail]>
Date: Thu, 22 Jan 2009 15:35:38 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: ihave and server upgrades
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
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>

Ned Freed writes:
>> I don't suppose there's anything to do about it, but it still riles me.
>
> Me too. In fact I had to deal with exactly this case recently because 
> I just improved checking of tagged arguments in our implementation. 
> And I have to agree there's nothing to be done about it.

Heh. Improve it to handle this.

Consider the extensions random, which provides a test which returns true 
or false randomly, and well, which provides a tag for fileinto.

require [ "random", "ihave" ];
if anyof( random, not ihave "well" ) {
     fileinto :well "a";
} elsif random {
     fileinto :well "b";
} else {
     fileinto :well "c";
}

Two of those three blocks are bad. Which ones? I have NOT improved my 
code to the point of handling this.

> A similar case I've seen come up many times over the years  is that of 
> scripting languages that allow abbreviations. So you write something 
> like this in a script:
>
>    $ rec foo

(REXX?)

> I suppose another way to think of it is as an untested code path 
> which, when finally activated, is found to contain a bug. But thqt 
> doesn't provide much solace either.

No... I hate it when person x changing something here breaks something 
for person y over there. Too great potential for sending either/both of 
them chasing wild geese.

Arnt



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 n0LLp6me011105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 14:51:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0LLp6mF011104; Wed, 21 Jan 2009 14:51:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx-p2.cc.nd.edu (mx-p2.cc.nd.edu [129.74.250.58]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0LLosB1011081 for <[e-mail]>; Wed, 21 Jan 2009 14:51:05 -0700 (MST) (envelope-from [e-mail])
Received: from osgood.cc.nd.edu (osgood.cc.nd.edu [129.74.250.227]) by mx-p2.cc.nd.edu (Switch-3.3.0/Switch-3.3.0) with ESMTP id n0LLpgHH027824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 21 Jan 2009 16:51:43 -0500
Received: from [172.19.226.65] (nat20.cc.nd.edu [129.74.4.120]) (authenticated bits=0) by osgood.cc.nd.edu (Switch-3.2.2/Switch-3.2.2) with ESMTP id n0LLopeI015515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 21 Jan 2009 16:50:52 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 21 Jan 2009 16:50:49 -0500
From: Paul Russell <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: ihave and server upgrades
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: 129.74.250.227
X-ND-MTA-Date: Wed, 21 Jan 2009 16:51:43 EST
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>

On 1/21/2009, someone who shall remain nameless wrote:
> 
> A similar case I've seen come up many times over the years  is that of
> scripting languages that allow abbreviations. So you write something like this
> in a script:
> 
>     $ rec foo
> 
> where rec is an abbreviation for "recover". This works because there's no other
> command that begins with "rec". Then the system is upgraded, and a new "recall"
> command is added. And the script breaks because now "rec" is ambiguous. (And
> yes, this example really happened.)

Gosh, I can't remember the last time I was bitten by that kind of sloppy coding,
but it was probably shortly after I started programming on an IBM 370-148, back
when dinosaurs still roamed the earth.

-- 
Paul Russell, Senior Systems Administrator
OIT Messaging Services Team
University of Notre Dame
[e-mail]



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 n0LGnDrp095055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 09:49:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0LGnDK7095054; Wed, 21 Jan 2009 09:49:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0LGnCBL095048 for <[e-mail]>; Wed, 21 Jan 2009 09:49:13 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.33] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 170412936; Wed, 21 Jan 2009 08:51:57 -0800 (PST)
Subject: Re: ihave and server upgrades
From: Aaron Stone <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Cyrus Daboo <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>, Arnt Gulbrandsen <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <1232552267.11360.37.camel@turtle> <[e-mail]>
Content-Type: text/plain
Date: Wed, 21 Jan 2009 08:49:19 -0800
Message-Id: <1232556559.11360.42.camel@turtle>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.2 
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>

On Wed, 2009-01-21 at 10:46 -0500, Jeffrey Hutzelman wrote:
> --On Wednesday, January 21, 2009 07:37:46 AM -0800 Aaron Stone 
> <[e-mail]> wrote:
> 
> >
> > On Wed, 2009-01-21 at 09:57 -0500, Cyrus Daboo wrote:
> >> Hi Kjetil,
> >>
> >> --On January 21, 2009 2:37:50 PM +0100 Kjetil Torgrim Homme
> >> <[e-mail]> wrote:
> >>
> >> >> I don't suppose there's anything to do about it, but it still riles
> >> >> me.
> >> >
> >> > good point.  one solution is to remove dead code (e.g, like Cyrus'
> >> > "byte compile") from the script at upload time.
> >>
> >> Or when you upgrade a server, the server ought to have a "sieve lint"
> >> tool  that can scan all existing scripts (as would happen during an
> >> upload a  script) and report problems that the admin can take action on.
> >
> > I don't think that's realistic -- some extensions can be implemented
> > entirely by the interpreter, with no need for any other part of the mail
> > system to get involved. So if the interpreter (a shared library, let's
> > say) is upgraded, there's no good way to inform the mail system what
> > changed and to run a lint process.
> 
> I think you're misinterpreting Cyrus's point.  The idea is not that the 
> mail system somehow automagically looks for problems and starts notifying 
> people about them.  The idea is that there is a tool the admin can run to 
> look for problems in a script.  Depending on the implementation model, this 
> might come with the interpreter or with the mail server.

Ah, the existence of such a tool is certainly reasonable (as I note to
myself to write one for my mail server). And to Cyrus' reply on reading
release notes, yes, that's very reasonable, too.

Failing both, though, I'd handle it just like any other unexpected
runtime failure of a script -- drop a note in the user's Inbox
indicating that their Sieve script isn't working and all mail will be
delivered to their Inbox for now.

Aaron



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 n0LGNTRG093486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 09:23:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0LGNTMF093485; Wed, 21 Jan 2009 09:23:29 -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 n0LGNIs5093476 for <[e-mail]>; Wed, 21 Jan 2009 09:23:28 -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, 21 Jan 2009 08:23:16 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Wed, 21 Jan 2009 08:23:13 -0800 (PST)
Date: Wed, 21 Jan 2009 08:12:32 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: ihave and server upgrades
In-reply-to: "Your message dated Wed, 21 Jan 2009 13:54:52 +0100" <[e-mail]>
To: Arnt Gulbrandsen <[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>

> I implemented ihave. It was easy. I ran into a strange point, though.

>      require "ihave";
>      if ihave "foo" {
>          foo :dwimfactor 4;
>      }

> There are three cases.

> 1. Server supports foo at upload. Upload results in a managesieve error
> such as "NO Maximum DWIM factor is 3". Fine.

> 2. Server doesn't support foo, period. Upload succeeds, execution
> succeeds. Fine.

> 3. Server doesn't support foo at upload, but is later upgraded to a new
> version which supports foo. Now the script fails when run. Not so fine.
> It riles me that one thing can break because another is upgraded.

> I don't suppose there's anything to do about it, but it still riles me.

Me too. In fact I had to deal with exactly this case recently because I just
improved checking of tagged arguments in our implementation. And I have to
agree there's nothing to be done about it.

A similar case I've seen come up many times over the years  is that of
scripting languages that allow abbreviations. So you write something like this
in a script:

    $ rec foo

where rec is an abbreviation for "recover". This works because there's no other
command that begins with "rec". Then the system is upgraded, and a new "recall"
command is added. And the script breaks because now "rec" is ambiguous. (And
yes, this example really happened.)

I suppose another way to think of it is as an untested code path which, when
finally activated, is found to contain a bug. But thqt doesn't provide much
solace either.

				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 n0LFkcav091009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 08:46:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0LFkc9R091008; Wed, 21 Jan 2009 08:46:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0LFkQ9D090994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 21 Jan 2009 08:46:37 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n0LFkGbC006367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 10:46:16 -0500 (EST)
Date: Wed, 21 Jan 2009 10:46:20 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Aaron Stone <[e-mail]>, Cyrus Daboo <[e-mail]>
cc: Kjetil Torgrim Homme <[e-mail]>, Arnt Gulbrandsen <[e-mail]>, [e-mail], [e-mail]
Subject: Re: ihave and server upgrades
Message-ID: <[e-mail]>
In-Reply-To: <1232552267.11360.37.camel@turtle>
References: <[e-mail]>	 <[e-mail]>	 <[e-mail]> <1232552267.11360.37.camel@turtle>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
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>

--On Wednesday, January 21, 2009 07:37:46 AM -0800 Aaron Stone 
<[e-mail]> wrote:

>
> On Wed, 2009-01-21 at 09:57 -0500, Cyrus Daboo wrote:
>> Hi Kjetil,
>>
>> --On January 21, 2009 2:37:50 PM +0100 Kjetil Torgrim Homme
>> <[e-mail]> wrote:
>>
>> >> I don't suppose there's anything to do about it, but it still riles
>> >> me.
>> >
>> > good point.  one solution is to remove dead code (e.g, like Cyrus'
>> > "byte compile") from the script at upload time.
>>
>> Or when you upgrade a server, the server ought to have a "sieve lint"
>> tool  that can scan all existing scripts (as would happen during an
>> upload a  script) and report problems that the admin can take action on.
>
> I don't think that's realistic -- some extensions can be implemented
> entirely by the interpreter, with no need for any other part of the mail
> system to get involved. So if the interpreter (a shared library, let's
> say) is upgraded, there's no good way to inform the mail system what
> changed and to run a lint process.

I think you're misinterpreting Cyrus's point.  The idea is not that the 
mail system somehow automagically looks for problems and starts notifying 
people about them.  The idea is that there is a tool the admin can run to 
look for problems in a script.  Depending on the implementation model, this 
might come with the interpreter or with the mail server.



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 n0LFj40K090866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 08:45:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0LFj4WI090865; Wed, 21 Jan 2009 08:45:04 -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 n0LFj3c0090857 for <[e-mail]>; Wed, 21 Jan 2009 08:45:04 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id A45B910F8D9C; Wed, 21 Jan 2009 10:45:03 -0500 (EST)
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 cvrDDEIwgajt; Wed, 21 Jan 2009 10:45:03 -0500 (EST)
Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id D522510F8D95; Wed, 21 Jan 2009 10:45:01 -0500 (EST)
Date: Wed, 21 Jan 2009 10:44:59 -0500
From: Cyrus Daboo <[e-mail]>
To: Aaron Stone <[e-mail]>
cc: Kjetil Torgrim Homme <[e-mail]>, Arnt Gulbrandsen <[e-mail]>, [e-mail]
Subject: Re: ihave and server upgrades
Message-ID: <[e-mail]>
In-Reply-To: <1232552267.11360.37.camel@turtle>
References: <[e-mail]>	 <[e-mail]>	 <[e-mail]> <1232552267.11360.37.camel@turtle>
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=942
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 Aaron,

--On January 21, 2009 7:37:46 AM -0800 Aaron Stone <[e-mail]> 
wrote:

>> Or when you upgrade a server, the server ought to have a "sieve lint"
>> tool  that can scan all existing scripts (as would happen during an
>> upload a  script) and report problems that the admin can take action on.
>
> I don't think that's realistic -- some extensions can be implemented
> entirely by the interpreter, with no need for any other part of the mail
> system to get involved. So if the interpreter (a shared library, let's
> say) is upgraded, there's no good way to inform the mail system what
> changed and to run a lint process.

Well the system administrator better read the release notes and those 
better say that the interpreter was changed significantly and that all 
existing scripts should be checked. An admin blindly doing upgrades without 
checking release notes/instructions is asking for trouble...

-- 
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 n0LFbq3B090486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 08:37:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0LFbq4o090485; Wed, 21 Jan 2009 08:37:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0LFbeML090462 for <[e-mail]>; Wed, 21 Jan 2009 08:37:51 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.33] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id A2B002936; Wed, 21 Jan 2009 07:40:25 -0800 (PST)
Subject: Re: ihave and server upgrades
From: Aaron Stone <[e-mail]>
To: Cyrus Daboo <[e-mail]>
Cc: Kjetil Torgrim Homme <[e-mail]>, Arnt Gulbrandsen <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 21 Jan 2009 07:37:46 -0800
Message-Id: <1232552267.11360.37.camel@turtle>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.2 
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>

On Wed, 2009-01-21 at 09:57 -0500, Cyrus Daboo wrote:
> Hi Kjetil,
> 
> --On January 21, 2009 2:37:50 PM +0100 Kjetil Torgrim Homme 
> <[e-mail]> wrote:
> 
> >> I don't suppose there's anything to do about it, but it still riles me.
> >
> > good point.  one solution is to remove dead code (e.g, like Cyrus' "byte
> > compile") from the script at upload time.
> 
> Or when you upgrade a server, the server ought to have a "sieve lint" tool 
> that can scan all existing scripts (as would happen during an upload a 
> script) and report problems that the admin can take action on.

I don't think that's realistic -- some extensions can be implemented
entirely by the interpreter, with no need for any other part of the mail
system to get involved. So if the interpreter (a shared library, let's
say) is upgraded, there's no good way to inform the mail system what
changed and to run a lint process.

Aaron



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 n0LF0R9U087674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 08:00:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0LF0R4p087673; Wed, 21 Jan 2009 08:00:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0LF0Qva087667 for <[e-mail]>; Wed, 21 Jan 2009 08:00:27 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id CE8CE4AC4B; Wed, 21 Jan 2009 16:00:25 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1232550025-52018-1/6/37 for [e-mail]; Wed, 21 Jan 2009 16:00:25 +0100
Message-Id: <[e-mail]>
Date: Wed, 21 Jan 2009 16:00:50 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: ihave and server upgrades
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
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>

Cyrus Daboo writes:
> Or when you upgrade a server, the server ought to have a "sieve lint" 
> tool that can scan all existing scripts (as would happen during an 
> upload a script) and report problems that the admin can take action 
> on.

Personally I like that better. Or at least so the admin will know what's 
broken (ie. that it's not the upgraded server).

Arnt



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 n0LEwFrs087501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 07:58:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0LEwE2G087500; Wed, 21 Jan 2009 07:58:15 -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 n0LEw3A8087488 for <[e-mail]>; Wed, 21 Jan 2009 07:58:13 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 1B91710F89C1; Wed, 21 Jan 2009 09:58:03 -0500 (EST)
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 A3QZ8GublDyd; Wed, 21 Jan 2009 09:58:02 -0500 (EST)
Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 9A6FC10F89BA; Wed, 21 Jan 2009 09:58:01 -0500 (EST)
Date: Wed, 21 Jan 2009 09:57:59 -0500
From: Cyrus Daboo <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>, Arnt Gulbrandsen <[e-mail]>
cc: [e-mail]
Subject: Re: ihave and server upgrades
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[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=528
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 Kjetil,

--On January 21, 2009 2:37:50 PM +0100 Kjetil Torgrim Homme 
<[e-mail]> wrote:

>> I don't suppose there's anything to do about it, but it still riles me.
>
> good point.  one solution is to remove dead code (e.g, like Cyrus' "byte
> compile") from the script at upload time.

Or when you upgrade a server, the server ought to have a "sieve lint" tool 
that can scan all existing scripts (as would happen during an upload a 
script) and report problems that the admin can take action on.

-- 
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 n0LDc5sh081703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 06:38:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0LDc5S4081702; Wed, 21 Jan 2009 06:38:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0LDbrMZ081690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 21 Jan 2009 06:38:04 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1LPdHE-0003nP-Az; Wed, 21 Jan 2009 14:37:52 +0100
Received: from feh.linpro.no ([87.238.42.45]) by mail-mx4.uio.no with esmtpsa (TLSv1:CAMELLIA256-SHA:256) user kjetilho (Exim 4.69) (envelope-from <[e-mail]>) id 1LPdHD-0007F2-UD; Wed, 21 Jan 2009 14:37:52 +0100
Subject: Re: ihave and server upgrades
From: Kjetil Torgrim Homme <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Wed, 21 Jan 2009 14:37:50 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) 
Content-Transfer-Encoding: 7bit
X-UiO-SPF-Received: 
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: E23C428527592861F0CAE6B44BBBADF0325529A4
X-UiO-SPAM-Test: remote_host: 87.238.42.45 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 152 max/h 3 blacklist 0 greylist 0 ratelimit 0
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>

On Wed, 2009-01-21 at 13:54 +0100, Arnt Gulbrandsen wrote:
> I implemented ihave. It was easy. I ran into a strange point, though.
> 
>      require "ihave";
>      if ihave "foo" {
>          foo :dwimfactor 4;
>      }
> 
> There are three cases.
> 
> 1. Server supports foo at upload. Upload results in a managesieve error 
> such as "NO Maximum DWIM factor is 3". Fine.
> 
> 2. Server doesn't support foo, period. Upload succeeds, execution 
> succeeds. Fine.
> 
> 3. Server doesn't support foo at upload, but is later upgraded to a new 
> version which supports foo. Now the script fails when run. Not so fine. 
> It riles me that one thing can break because another is upgraded.
> 
> I don't suppose there's anything to do about it, but it still riles me.

good point.  one solution is to remove dead code (e.g, like Cyrus' "byte
compile") from the script at upload time.

-- 
regards,
Kjetil T.



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 n0LCsfuk079502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 05:54:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0LCsffS079501; Wed, 21 Jan 2009 05:54:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0LCsS3K079487 for <[e-mail]>; Wed, 21 Jan 2009 05:54:39 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 9DCA34AC44; Wed, 21 Jan 2009 13:54:27 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1232542467-52018-1/6/32 for [e-mail]; Wed, 21 Jan 2009 13:54:27 +0100
Message-Id: <[e-mail]>
Date: Wed, 21 Jan 2009 13:54:52 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: ihave and server upgrades
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
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>

I implemented ihave. It was easy. I ran into a strange point, though.

     require "ihave";
     if ihave "foo" {
         foo :dwimfactor 4;
     }

There are three cases.

1. Server supports foo at upload. Upload results in a managesieve error 
such as "NO Maximum DWIM factor is 3". Fine.

2. Server doesn't support foo, period. Upload succeeds, execution 
succeeds. Fine.

3. Server doesn't support foo at upload, but is later upgraded to a new 
version which supports foo. Now the script fails when run. Not so fine. 
It riles me that one thing can break because another is upgraded.

I don't suppose there's anything to do about it, but it still riles me.

Arnt



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 n0KFS1Fe021757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jan 2009 08:28:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0KFS1H9021756; Tue, 20 Jan 2009 08:28:01 -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 n0KFS0bU021749 for <[e-mail]>; Tue, 20 Jan 2009 08:28:00 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 30) id BC3C83A69F9; Tue, 20 Jan 2009 07:28:15 -0800 (PST)
X-idtracker: yes
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, sieve mailing list <[e-mail]>, sieve chair <[e-mail]>
Subject: Protocol Action: 'A Protocol for Remotely Managing  Sieve Scripts' to Proposed Standard 
Message-Id: <[e-mail]>
Date: Tue, 20 Jan 2009 07:28:15 -0800 (PST)
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>

The IESG has approved the following document:

- 'A Protocol for Remotely Managing Sieve Scripts '
   <draft-ietf-sieve-managesieve-09.txt> as a Proposed Standard

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

The IESG contact persons are Lisa Dusseault and Chris Newman.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-managesieve-09.txt

Technical Summary

  Sieve scripts allow users to filter incoming email.  Message stores
  are commonly sealed servers so users cannot log into them, yet users
  must be able to update their scripts on them.  This document
  describes a protocol "ManageSieve" for securely managing Sieve
  scripts on a remote server.  This protocol allows a user to have
  multiple scripts, and also alerts a user to syntactically flawed
  scripts.

Working Group Summary
  There was a discussion on the mailing list about use of synchronizing 
  literals in the protocol. An earlier version incorrectly documented  
  existing practice and at the same time was inconsistent with IMAP  
  LITERAL+ extension. So there was a concern that some existing  
  implementation might implement this incorrectly. However the author 
  is not aware of any such implementation.

  More recently, there has been discussion of the overall command 
  structure, mandatory-to-implement security mechanisms, and of some 
  specific details in the sieve URL format. Consensus appears to have 
  been reached on all of these issues.

Document Quality
  There are multiple server and client implementations of the 
  ManageSieve protocol. The following is an incomplete list of servers 
  implementing ManageSieve: CMU, Dbmail, Dovecot, Isode, ArchiveOpteryx, 
  pysieved (Python Managesieve Server), Citadel.

  The following clients are known to implement ManageSieve: Mulberry, 
  Phil Pennock's sieve-connect, Polymer, Ruby/ManageSieve,  
  Net-ManageSieve (perl), SIEVE plugin for Thunderbird, KMail, gsieve,
  Emacs-based ManageSieve implementation.

  Note that many if not most of these implementtations were written 
  according to earlier versions of the specification and may require 
  updates to be compliant with the current version.

Personnel

  Ned Freed is the Document Shepherd.
  Lisa Dusseault reviewed this for the IESG.



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 n0KFQqhs021698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jan 2009 08:26:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0KFQqbZ021697; Tue, 20 Jan 2009 08:26:52 -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 n0KFQqTj021691 for <[e-mail]>; Tue, 20 Jan 2009 08:26:52 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 30) id 89E6328C1F8; Tue, 20 Jan 2009 07:26:41 -0800 (PST)
X-idtracker: yes
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, sieve mailing list <[e-mail]>, sieve chair <[e-mail]>
Subject: Protocol Action: 'Sieve Email Filtering: Ihave  Extension' to Proposed Standard 
Message-Id: <[e-mail]>
Date: Tue, 20 Jan 2009 07:26:41 -0800 (PST)
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>

The IESG has approved the following document:

- 'Sieve Email Filtering: Ihave Extension '
   <draft-freed-sieve-ihave-04.txt> as a Proposed Standard

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

The IESG contact persons are Lisa Dusseault and Chris Newman.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-freed-sieve-ihave-04.txt

Technical Summary


This document describes the "ihave" extension to the Sieve email
filtering language.  The "ihave" extension provides a means to write
scripts that can take advantage of optional Sieve features but can
still run when those optional features are not available.  The
extension also defines a new error control command intended to be
used to report situations where no combination of available
extensions satisfies the needs of the script.

Working Group Summary

There were some discussions about whether the ihave test should only 
enable an extension for the if block it is used in, or whether it 
should enable the extension till the end of the script. The latter 
was chosen due to perceived ease of implementability and this represents 
rough consensus of the WG.

Document Quality

There is at least 1 server implementations of this document. At least 1
more server vendor is implementing it and at least a 3 more are interested
in implementing it.

At least 4 people have reviewed the document. Majority of posted comments
were addressed in the latest revision.

Personnel

Alexey Melnikov is the Document Shepherd.  Lisa Dusseault is the
Sponsoring AD.



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 n0HJTm8k098869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Jan 2009 12:29:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0HJTmMD098868; Sat, 17 Jan 2009 12:29:48 -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 n0HJTlEx098860 for <[e-mail]>; Sat, 17 Jan 2009 12:29:47 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 672683A694D; Sat, 17 Jan 2009 11:30:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sieve-managesieve-09.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Sat, 17 Jan 2009 11:30:01 -0800 (PST)
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           : A Protocol for Remotely Managing Sieve Scripts
	Author(s)       : A. Melnikov, T. Martin
	Filename        : draft-ietf-sieve-managesieve-09.txt
	Pages           : 52
	Date            : 2009-01-17

Sieve scripts allow users to filter incoming email.  Message stores
are commonly sealed servers so users cannot log into them, yet users
must be able to update their scripts on them.  This document
describes a protocol "ManageSieve" for securely managing Sieve
scripts on a remote server.  This protocol allows a user to have
multiple scripts, and also alerts a user to syntactically flawed
scripts.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-managesieve-09.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-ietf-sieve-managesieve-09.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 n0G9IATj007205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2009 02:18:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0G9IACh007204; Fri, 16 Jan 2009 02:18:10 -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 n0G9HxAE007193 for <[e-mail]>; Fri, 16 Jan 2009 02:18:10 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.144.84] (92.40.144.84.sub.mbb.three.co.uk [92.40.144.84])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <SXBQxQBwvnF=@rufus.isode.com>; Fri, 16 Jan 2009 09:17:58 +0000
Message-ID: <[e-mail]>
Date: Fri, 16 Jan 2009 09:17:43 +0000
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: Aaron Stone <[e-mail]>
CC: [e-mail]
Subject: Re: Next Sieve drafts to work on
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>

Aaron Stone wrote:

>On Thu, Jan 15, 2009, Alexey Melnikov <[e-mail]> said:
>  
>
>>Folks,
>>I've just checked our milestones and found there:
>>
>>Feb 2009   WGLC RegEx
>>Mar 2009   WGLC Include/multi-script
>>
>>We don't have drafts for either item yet. I think Ned is already doing 
>>lots of work in this WG, so chairs would appreciate if somebody can step 
>>up to the plate and volunteer to edit one of these documents. We already 
>>have 1 volunteer for include/multiscript, but, speaking personally, I 
>>would prefer to have 2 people on each document. Any takers?
>>    
>>
>If the one volunteer wasn't already me, I volunteer me :-)
>  
>
That was you.

Any other takers?

>Should new revisions of the documents be posted from the expired
>revisions?
>  
>
That would be fine with me. We have 2 expired drafts to choose from.



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 n0G7sQun002105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2009 00:54:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0G7sQtJ002104; Fri, 16 Jan 2009 00:54:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0G7sDdf002090 for <[e-mail]>; Fri, 16 Jan 2009 00:54:24 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id A6CA24AC6C; Fri, 16 Jan 2009 08:54:12 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.0.5) with esmtp id 1232092452-96043-1/6/5 (4 recipients); Fri, 16 Jan 2009 08:54:12 +0100
Message-Id: <[e-mail]>
Date: Fri, 16 Jan 2009 08:54:28 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: draft-freed-sieve-in-xml status?
Cc: Ned Freed <[e-mail]>, Aaron Stone <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <PCbmC+s//[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1231700263.16458.102.camel@turtle> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
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>

Ned Freed writes:
> Really, I think this is just lack of familiarity with how things play out in
> the XML world more than anything.

I am indeed not familiar with the XML world.

> Everywhere you look in XML-based languages you'll find <comment>, 
> <annotation>, and similar constructs.

Fine then. When in Rome, etc.

Other stuff later; I'm squeezed now.

Arnt



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 n0G3n6gY091102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jan 2009 20:49:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0G3n6eZ091101; Thu, 15 Jan 2009 20:49:06 -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 n0G3mtnP091077 for <[e-mail]>; Thu, 15 Jan 2009 20:49:05 -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]; Thu, 15 Jan 2009 19:48:52 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 15 Jan 2009 19:48:49 -0800 (PST)
Date: Thu, 15 Jan 2009 19:40:26 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
In-reply-to: "Your message dated Thu, 15 Jan 2009 09:54:40 +0100" <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail], Ned Freed <[e-mail]>, Aaron Stone <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <PCbmC+s//[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1231700263.16458.102.camel@turtle> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

> Ned Freed writes:
> >> Ned Freed writes:
> >> > The other issue here is how to map this stuff to regular Sieve. The
> >> > stylesheet given in the appendix maps displaydata and displayblock
> >> > material into structured comments. This can easily be
> >> > extended/changed to cover the handling of material in other
> >> > namespaces. But do we want to formalize the structured comment
> >> > convention?
> >>
> >> My desire for structured comments is vanishingly small. My two cents.
> >
> > I don't think we have a choice. The problem is the XML representation
> > is richer and since it isn't intended as a storage format there  has
> > to be a way to map the additional information to something in regular
> > sieve. Unless we want to do something along the lines of the meta
> > extension Kjetil proposed - which I don't think we want to do, pretty
> > much the only place for it is in comments.

> I didn't reply... but at least I would have preferred such a meta thingy
> at 302 time. Now it may be too late.

If it was in the base specificaiton, maybe. But having to support a brand new
Sieve extension in order to handle preservation of XML content while round
tripping scripts sounds like a bad idea to me.

> > I apologize for not being clearer here - I made this sound like it's a
> > processor quality thing, which it isn't.

> You were clear enough for me at least.

> > The problem is more fundamental: In XML comments are not considered to
> > be part of the infoset. This means conforming XML processors are
> > explicitly allowed to drop them. Which in turn means you cannot count
> > on them being available for processing.

> Sure. The question is whether that's a problem.

> If you write a script in xmlsieve, convert it and then convert it back,
> then any comments you added may have been deleted. AFAICT this is not a
> problem.

Well, I don't know about you, but if I have a complex script that I have
carefully commented, and when I use a new GUI editor on it that transforms it
to XML and back again and loses the comments in the process, I'm not going to
be  a happy camper.

Sure, there are lots of cases where it doesn't matter and comments can be
dropped, assuming there are any there in the first place. But there are
going to be cases where comments need to be preserved and any mapping
needs to support that.

Really, I think this is just lack of familiarity with how things play out in
the XML world more than anything. Everywhere you look in XML-based
languages you'll find <comment>, <annotation>, and similar constructs.

For better or worse, XML just doesn't worry too much about this stuff.

> If you write it in plain old sieve, convert it and then convert it back,
> then comments are preserved due to <comment>. AFAICT this is neat, but
> it's not clear to me that it's necessary. (Btw. Now that I think about
> it. Is whitespace preserved in arguments?)

Whitespace in string constants darned well better be preserved. (And come to
think of it, I need to put in something about how to map text: constructs.)
Whitespace in comments can also be preserved for the most part - there may be
some edges where it's a bit difficult. But whitespace between lexical tokens in
either representation isn't going to be preserved. The solution I adopted in
the sample stylesheet was to output stuff using a simple indentation scheme.

				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 n0G0imtE081652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jan 2009 17:44:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0G0imDP081651; Thu, 15 Jan 2009 17:44:48 -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 n0G0ilsP081645 for <[e-mail]>; Thu, 15 Jan 2009 17:44:47 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id D5B253A691B; Thu, 15 Jan 2009 16:45:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-freed-sieve-notary-04.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu, 15 Jan 2009 16:45:01 -0800 (PST)
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: Delivery Status Notifications Extension
	Author(s)       : N. Freed
	Filename        : draft-freed-sieve-notary-04.txt
	Pages           : 8
	Date            : 2009-01-15

This document describes the "envelope-dsn" and "redirect-dsn"
extensions to the Sieve email filtering language.  The "envelope-dsn"
extension provides access to additional envelope information provided
by the delivery status notification extension to SMTP defined in RFC
3461.  The "redirect-dsn" extension extends Sieve's redirect action
to provide control over delivery status notification parameters.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-freed-sieve-notary-04.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-notary-04.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 n0G0RWxf081034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jan 2009 17:27:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0G0RWjs081033; Thu, 15 Jan 2009 17:27:32 -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 n0G0RLJ5081014 for <[e-mail]>; Thu, 15 Jan 2009 17:27:32 -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]; Thu, 15 Jan 2009 16:27:18 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 15 Jan 2009 16:27:13 -0800 (PST)
Date: Thu, 15 Jan 2009 16:23:52 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: I-D Action:draft-freed-sieve-notary-03.txt
In-reply-to: "Your message dated Thu, 15 Jan 2009 22:15:35 +0000" <[e-mail]>
To: Aaron Stone <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[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>

> Hi Ned, a really brief review below...

Thanks for taking the time to do it.

> On Thu, Jan 15, 2009, [e-mail] said:

> >
> > 	Title           : Sieve Email Filtering: Delivery Status Notifications Extension
> > 	Author(s)       : N. Freed
> > 	Filename        : draft-freed-sieve-notary-03.txt
> > 	Pages           : 8
> > 	Date            : 2009-01-15
> >
> > This document describes the "envelope-dsn" and "redirect-dsn"
> > extensions to the Sieve email filtering language.  The "envelope-dsn"
> > extension provides access to additional envelope information provided
> > by the delivery status notification extension to SMTP defined in RFC
> > 3461.  The "redirect-dsn" extension extends Sieve's redirect action
> > to provide control over delivery status notification parameters.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-freed-sieve-notary-03.txt
> >

> In Section 4.0:

>    The "relational" extension [RFC5231] adds a match type called
>    ":count".  The count of an envelope test of with an envelope-part of
>                                            ^^^^

> Leftover word "of".

Fixed.

> In Section 4.1 I do not understand the examples :-(

Not sure what to say to that ... I tried some wordsmithing in hopes of making
things clearer, but really, I don't think these are all that complex or obscure
as long as you understand the DSN extension, which seems like a prerequisite
here.

> In Section 5.0:

>    Usage:   redirect [NOTIFY] [RET] <address: string>

> It seems awkward to me to mix the formal EBNF with the more casual usage
> description. This would be better IMHO:

>    Usage:   redirect [:notify "value"] [:ret "FULL"|"HDRS"]
>                 <address: string>

> (Unless other extensions are already doing inline EBNF, in which case
> consistency says keep it that way, but I personally don't prefer it.)

I'm not sure what the state of play is but this has already confused at least
one reader I know of. So I'm going to try it your way.

> Also Section 5.0:

>    These parameters are only available when the delivery status
>    notification (DSN) ESMTP extension is available; they are simply
>    ignored and MUST NOT cause an error if the DSN extension is
>    unavailable.

> Easier to understand like this:

>    These parameters are only available when the delivery status
>    notification (DSN) ESMTP extension is available. When the DSN
>    extension is not available, the parameters MUST be ignored and
>    MUST NOT cause an error.

Changed.

> Section 5.1:

>    One possible use of :notify on redirect is to ccmbine the copy
>                                                  ^^^
> Misspell of "combine".

Fixed.

				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 n0FNguFl078981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jan 2009 16:42:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0FNgu9O078980; Thu, 15 Jan 2009 16:42:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0FNgtRO078974 for <[e-mail]>; Thu, 15 Jan 2009 16:42:55 -0700 (MST) (envelope-from [e-mail])
Received: from serendipity.palo-alto.ca.us (unknown [10.10.10.34]) by mail.serendipity.cx (Postfix) with SMTP id 0734F1F8F; Thu, 15 Jan 2009 15:45:02 -0800 (PST)
Date: Thu, 15 Jan 2009 23:45:02 -0000
To: "Alexey Melnikov" <[e-mail]>, <[e-mail]>
Subject: Re: Next Sieve drafts to work on
From: "Aaron Stone" <[e-mail]>
X-Mailer: TWIG 2.8.3
Message-ID: <[e-mail]>
In-Reply-To: <[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>

On Thu, Jan 15, 2009, Alexey Melnikov <[e-mail]> said:

> 
> Folks,
> I've just checked our milestones and found there:
> 
> Feb 2009   WGLC RegEx
> Mar 2009   WGLC Include/multi-script
> 
> We don't have drafts for either item yet. I think Ned is already doing 
> lots of work in this WG, so chairs would appreciate if somebody can step 
> up to the plate and volunteer to edit one of these documents. We already 
> have 1 volunteer for include/multiscript, but, speaking personally, I 
> would prefer to have 2 people on each document. Any takers?
> 

If the one volunteer wasn't already me, I volunteer me :-)

Should new revisions of the documents be posted from the expired
revisions?

Aaron




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 n0FMsLLn077335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jan 2009 15:54:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0FMsLZD077334; Thu, 15 Jan 2009 15:54:21 -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 n0FMsKJQ077328 for <[e-mail]>; Thu, 15 Jan 2009 15:54:21 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.202.159] (92.40.202.159.sub.mbb.three.co.uk [92.40.202.159])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 15 Jan 2009 22:54:18 +0000
Message-ID: <[e-mail]>
Date: Thu, 15 Jan 2009 22:53:18 +0000
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: [e-mail]
Subject: Next Sieve drafts to work on
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>

Folks,
I've just checked our milestones and found there:

Feb 2009   WGLC RegEx
Mar 2009   WGLC Include/multi-script

We don't have drafts for either item yet. I think Ned is already doing 
lots of work in this WG, so chairs would appreciate if somebody can step 
up to the plate and volunteer to edit one of these documents. We already 
have 1 volunteer for include/multiscript, but, speaking personally, I 
would prefer to have 2 people on each document. Any takers?




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 n0FMiEZS077013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jan 2009 15:44:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0FMiEg7077012; Thu, 15 Jan 2009 15:44:14 -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 n0FMi32j076999 for <[e-mail]>; Thu, 15 Jan 2009 15:44:13 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.202.159] (92.40.202.159.sub.mbb.three.co.uk [92.40.202.159])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 15 Jan 2009 22:44:00 +0000
Message-ID: <[e-mail]>
Date: Thu, 15 Jan 2009 22:43:03 +0000
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: [e-mail]
Subject: WGLC on draft-freed-sieve-in-xml-02.txt
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>

Hi folk,
With my co-chair hat on:

This message officially starts the Sieve Working Group Last Call for the  following document:

Sieve Email Filtering:  Sieves and display directives in XML

<http://www.ietf.org/internet-drafts/draft-freed-sieve-in-xml-02.txt>

The Working Group Last Call for this document starts on January 15th and 
will end on January 30th. Please send any comments to the Sieve mailing 
list or to the document authors. If you chose to do the latter, please 
CC both Cyrus Daboo <[e-mail]> and Alexey Melnikov 
<[e-mail]>. Reviews that found no issues are also 
welcomed, so if you review the document and find it acceptable, please 
let the mailing list/authors+chairs know as well.

Also, in order to simplify tracking of various issues, please clearly 
mark each issue in the message (ideally in the subject header field, 
sending 1 issue per email message). Also, I would strongly encourage to 
provide specific suggestions for solving issues you've raised (or at 
least show an example of how your issue can be addressed).

Thank you,
Alexey, Sieve WG co-chairs



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 n0FMDe63075929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jan 2009 15:13:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0FMDeoH075928; Thu, 15 Jan 2009 15:13:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0FMDTas075921 for <[e-mail]>; Thu, 15 Jan 2009 15:13:39 -0700 (MST) (envelope-from [e-mail])
Received: from serendipity.palo-alto.ca.us (unknown [10.10.10.34]) by mail.serendipity.cx (Postfix) with SMTP id BA3232936; Thu, 15 Jan 2009 14:15:35 -0800 (PST)
Date: Thu, 15 Jan 2009 22:15:35 -0000
To: "Ned Freed" <[e-mail]>
Subject: Re: I-D Action:draft-freed-sieve-notary-03.txt
From: "Aaron Stone" <[e-mail]>
X-Mailer: TWIG 2.8.3
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Cc: <[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>

Hi Ned, a really brief review below...


On Thu, Jan 15, 2009, [e-mail] said:

> 
> 	Title           : Sieve Email Filtering: Delivery Status Notifications Extension
> 	Author(s)       : N. Freed
> 	Filename        : draft-freed-sieve-notary-03.txt
> 	Pages           : 8
> 	Date            : 2009-01-15
> 
> This document describes the "envelope-dsn" and "redirect-dsn"
> extensions to the Sieve email filtering language.  The "envelope-dsn"
> extension provides access to additional envelope information provided
> by the delivery status notification extension to SMTP defined in RFC
> 3461.  The "redirect-dsn" extension extends Sieve's redirect action
> to provide control over delivery status notification parameters.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-freed-sieve-notary-03.txt
> 

In Section 4.0:

   The "relational" extension [RFC5231] adds a match type called
   ":count".  The count of an envelope test of with an envelope-part of
                                           ^^^^

Leftover word "of".

In Section 4.1 I do not understand the examples :-(

In Section 5.0:

   Usage:   redirect [NOTIFY] [RET] <address: string>

It seems awkward to me to mix the formal EBNF with the more casual usage
description. This would be better IMHO:

   Usage:   redirect [:notify "value"] [:ret "FULL"|"HDRS"]
                <address: string>

(Unless other extensions are already doing inline EBNF, in which case
consistency says keep it that way, but I personally don't prefer it.)

Also Section 5.0:

   These parameters are only available when the delivery status
   notification (DSN) ESMTP extension is available; they are simply
   ignored and MUST NOT cause an error if the DSN extension is
   unavailable.

Easier to understand like this:

   These parameters are only available when the delivery status
   notification (DSN) ESMTP extension is available. When the DSN
   extension is not available, the parameters MUST be ignored and
   MUST NOT cause an error.

Section 5.1:

   One possible use of :notify on redirect is to ccmbine the copy
                                                 ^^^
Misspell of "combine".

Cheers!
Aaron



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 n0FITxW7067311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jan 2009 11:29:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0FITxTP067310; Thu, 15 Jan 2009 11:29: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.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0FITmtQ067278 for <[e-mail]>; Thu, 15 Jan 2009 11:29:59 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 9EBC928C27C; Thu, 15 Jan 2009 10:30:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-freed-sieve-notary-03.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu, 15 Jan 2009 10:30:01 -0800 (PST)
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: Delivery Status Notifications Extension
	Author(s)       : N. Freed
	Filename        : draft-freed-sieve-notary-03.txt
	Pages           : 8
	Date            : 2009-01-15

This document describes the "envelope-dsn" and "redirect-dsn"
extensions to the Sieve email filtering language.  The "envelope-dsn"
extension provides access to additional envelope information provided
by the delivery status notification extension to SMTP defined in RFC
3461.  The "redirect-dsn" extension extends Sieve's redirect action
to provide control over delivery status notification parameters.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-freed-sieve-notary-03.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-notary-03.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 n0FHim7V063265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jan 2009 10:44:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0FHim7V063264; Thu, 15 Jan 2009 10:44:48 -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 n0FHillS063258 for <[e-mail]>; Thu, 15 Jan 2009 10:44:47 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id D617F28C245; Thu, 15 Jan 2009 09:45:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sieve-managesieve-08.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu, 15 Jan 2009 09:45:01 -0800 (PST)
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           : A Protocol for Remotely Managing Sieve Scripts
	Author(s)       : A. Melnikov, T. Martin
	Filename        : draft-ietf-sieve-managesieve-08.txt
	Pages           : 51
	Date            : 2009-01-15

Sieve scripts allow users to filter incoming email.  Message stores
are commonly sealed servers so users cannot log into them, yet users
must be able to update their scripts on them.  This document
describes a protocol "ManageSieve" for securely managing Sieve
scripts on a remote server.  This protocol allows a user to have
multiple scripts, and also alerts a user to syntactically flawed
scripts.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-managesieve-08.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-ietf-sieve-managesieve-08.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 n0FGEnU4058430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jan 2009 09:14:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0FGEn4E058429; Thu, 15 Jan 2009 09:14:49 -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 n0FGEm1J058423 for <[e-mail]>; Thu, 15 Jan 2009 09:14:48 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id D377728C14B; Thu, 15 Jan 2009 08:15:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sieve-managesieve-07.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu, 15 Jan 2009 08:15:02 -0800 (PST)
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           : A Protocol for Remotely Managing Sieve Scripts
	Author(s)       : A. Melnikov, T. Martin
	Filename        : draft-ietf-sieve-managesieve-07.txt
	Pages           : 51
	Date            : 2009-01-15

Sieve scripts allow users to filter incoming email.  Message stores
are commonly sealed servers so users cannot log into them, yet users
must be able to update their scripts on them.  This document
describes a protocol "ManageSieve" for securely managing Sieve
scripts on a remote server.  This protocol allows a user to have
multiple scripts, and also alerts a user to syntactically flawed
scripts.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-managesieve-07.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-ietf-sieve-managesieve-07.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 n0F8sfij032503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jan 2009 01:54:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0F8sfY2032502; Thu, 15 Jan 2009 01:54:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0F8sSHF032490 for <[e-mail]>; Thu, 15 Jan 2009 01:54:39 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 016634AC46; Thu, 15 Jan 2009 09:54:26 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.0.5) with esmtp id 1232009666-21270-1/6/28 (4 recipients); Thu, 15 Jan 2009 09:54:26 +0100
Message-Id: <[e-mail]>
Date: Thu, 15 Jan 2009 09:54:40 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: draft-freed-sieve-in-xml status?
Cc: Ned Freed <[e-mail]>, Aaron Stone <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <PCbmC+s//[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1231700263.16458.102.camel@turtle> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
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>

Ned Freed writes:
>> Ned Freed writes:
>> > The other issue here is how to map this stuff to regular Sieve. The
>> > stylesheet given in the appendix maps displaydata and displayblock
>> > material into structured comments. This can easily be
>> > extended/changed to cover the handling of material in other
>> > namespaces. But do we want to formalize the structured comment
>> > convention?
>>
>> My desire for structured comments is vanishingly small. My two cents.
>
> I don't think we have a choice. The problem is the XML representation 
> is richer and since it isn't intended as a storage format there  has 
> to be a way to map the additional information to something in regular 
> sieve. Unless we want to do something along the lines of the meta 
> extension Kjetil proposed - which I don't think we want to do, pretty 
> much the only place for it is in comments.

I didn't reply... but at least I would have preferred such a meta thingy 
at 302 time. Now it may be too late.

> I apologize for not being clearer here - I made this sound like it's a 
> processor quality thing, which it isn't.

You were clear enough for me at least.

> The problem is more fundamental: In XML comments are not considered to 
> be part of the infoset. This means conforming XML processors are 
> explicitly allowed to drop them. Which in turn means you cannot count 
> on them being available for processing.

Sure. The question is whether that's a problem.

If you write a script in xmlsieve, convert it and then convert it back, 
then any comments you added may have been deleted. AFAICT this is not a 
problem.

If you write it in plain old sieve, convert it and then convert it back, 
then comments are preserved due to <comment>. AFAICT this is neat, but 
it's not clear to me that it's necessary. (Btw. Now that I think about 
it. Is whitespace preserved in arguments?)

>> I wish I'd kept my mouth shut. So many of these things are just 
>> better than some even worse alternative.
>
> Yeah, that's the nature of the beast, I'm afraid.

Yes.

Arnt



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 n0F41qkG019369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jan 2009 21:01:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0F41q8M019368; Wed, 14 Jan 2009 21:01:52 -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 n0F41cFL019358 for <[e-mail]>; Wed, 14 Jan 2009 21:01:49 -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, 14 Jan 2009 20:01:31 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Wed, 14 Jan 2009 20:01:27 -0800 (PST)
Date: Wed, 14 Jan 2009 15:23:12 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
In-reply-to: "Your message dated Mon, 12 Jan 2009 12:25:09 +0100" <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail], Ned Freed <[e-mail]>, Aaron Stone <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <PCbmC+s//[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1231700263.16458.102.camel@turtle> <[e-mail]> <[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>

> Ned Freed writes:
> > The other issue here is how to map this stuff to regular Sieve. The
> > stylesheet given in the appendix maps displaydata and displayblock
> > material into structured comments. This can easily be
> > extended/changed to cover the handling of material in other
> > namespaces. But do we want to formalize the structured comment
> > convention?

> My desire for structured comments is vanishingly small. My two cents.

I don't think we have a choice. The problem is the XML representation is richer
and since it isn't intended as a storage format there  has to be a way to map
the additional information to something in regular sieve. Unless we want to do
something along the lines of the meta extension Kjetil proposed - which I don't
think we want to do, pretty much the only place for it is in comments.

> > Finally, there's the issue of how to handle other comments, which
> > we've discussed in the past but may be worth revisiting now.
> > Currently regular Sieve comments are mapped to <comment></comment>
> > blocks rather than to proper XML comments. The reason for this is
> > that not all XML processors provide access to stuff inside of <!--
> > foo --> constructs, so comments may get lost when converting from
> > Sieve-in-XML back to regular Sieve. Do we want to continue to do
> > things this way?

> It's a decent reason at least, but it doesn't make me very happy.

I apologize for not being clearer here - I made this sound like it's 
a processor quality thing, which it isn't.

The problem is more fundamental: In XML comments are not considered to be part
of the infoset. This means conforming XML processors are explicitly allowed to
drop them. Which in turn means you cannot count on them being available
for processing.

> > In any case, here's a concrete proposal for how to move forward:
> >
> > (1) Add the necessary stuff to allow use of XML in other namespaces
> >     whereever displaydata is currently allowed.

This has been done in the new revision of the draft.

> > (2) Drop displaydata, making the use of namespaces required if you want
> >     to embed other stuff inside of a Sieve-in-XML.

This has not. I don;t think we have consensus on this yet, and it is much
easier to remove something than to put it back in once it is gone.

> > (3) Add a section defining the structured comment convention for
> >     representing this other stuff in regular Sieve format.

Done.

> > (4) Change displayblock to just block, making it clear it can be used for
> >     other sorts of groupings.

Not done yet, as it kinda depends on the removal of displaydata to make
sense.

> > (5) Leave the current mapping of unstructured Sieve comments to
> >     <comment></comment> blocks alone.

This was actually inconsistent in places and required some changes.

> OK.

> I wish I'd kept my mouth shut. So many of these things are just better
> than some even worse alternative.

Yeah, that's the nature of the beast, I'm afraid.

> <comment> exists so that even bad XML processors must preserve comments
> in a round-trip conversion, which seems weak justification. Not so weak
> that I actively disagree, but weak enough to make me unhappy.

Mostly agreed, except that such processors are in fact fully compliant and
therefore not considered "bad", at least in any sense that matters.

				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 n0ENN5bU007550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jan 2009 16:23:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0ENN5Vb007549; Wed, 14 Jan 2009 16:23:05 -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 n0ENMsCT007541 for <[e-mail]>; Wed, 14 Jan 2009 16:23:05 -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, 14 Jan 2009 15:22:48 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Wed, 14 Jan 2009 15:22:43 -0800 (PST)
Date: Wed, 14 Jan 2009 15:05:14 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
In-reply-to: "Your message dated Sun, 11 Jan 2009 19:47:47 -0800" <1231732067.16458.214.camel@turtle>
To: Aaron Stone <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1231732067.16458.214.camel@turtle>
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>

First of all, I've been holding off on responding to this thread because
I wanted to get a new version pushed out. I have now done so. The
new version contains a fair number of changes, including:

(1) Definition of a URN for our namespace and registration of said URN with
    IANA.
(2) Allow material from other namespaces in Sieve XML.
(3) Specify the structured comment convention (this was implicit in the
    stylesheet example but needed to become explicit).
(4) Addition of a compact Relax NG grammar.
(5) Made the handling of comments consistent.
(5) Cleaned up a number of bugs in the schema and stylesheet.

And now back to the discussion.

> Let's try to keep this conversation on the path of concrete examples.

I agree and will try to do so.

> I had no idea what this entire thread was about until Robert gave a
> specific XML snippet to illustrate what he wanted to do, and you gave a
> different one in response to illustrate the document state.

> My current understanding from trying to follow this thread is that this
> snippet (from Robert) is not valid according to the document:

>      <control name="if">
>        <mix:editor-specific foo='bar'></mix:editor-specific>
>        <test name="header">
>          <tag>is</tag>
>          <str>Sender</str>
>          <str>[e-mail]</str>
>        </test>
>        <action name="fileinto">
>          <str>filter</str>
>        </action> <comment>move to "filter" mailbox</comment>
>      </control>

This is now valid according to both schema in the document.

> This is syntactically valid XML, but semantically the element from the
> 'mix' namespace isn't going to make sense to a naive Sieve-XML parser.
> By some magic of XML specification buzzwords, I gather that the above
> snippet can be declared valid or invalid by the schema definition.

Yes. As I explained previously, a schema gets to control whether or not
elements in other namespaces are allowed, and where. I have allowed them in
most of so-called "complex" elements, i.e., elements that in turn contain other
elements.

> How are mixed-namespace documents like this handled by XML parsers /
> editors / UIs / etc? Is it reasonable to disallow a mixed namespace like
> this?

That reallly depends on the application. Keep in mind that this is a building
block, not a finished protocol or service. Even asssuming every application out
there ends up embedding elements from other namespaces, in a typical setup
you're going to use additional schemata to constrain those elements in various
ways. This is entirely reasonable - XML fully support the idea of having
multiple schemata in play for different namespaces.

> Is there a reason not to allow such mixing?

IMO no.

> What if someone wants to use the Sieve-XML schema within a larger
> document? For example:

>     <foomail:config>
>       <foomail:service service="smtp">
>         <foomail:port>25</foomail:port>
>         <foomail:listen>127.0.0.1</foomail:listen>
>       </foomail:service>
>       <foomail:user id="1">
>         <foomail:name>Username</foomail:name>
>         <foomail:sieves>
>           <foomail:sieve>
>             <foomail:name>On vacation</foomail:name>
>             <foomail:script>
>               <sieve:action name="vacation">
>                 <sieve:str>I'm away on vacation.</sieve:str>
>               </sieve:action>
>             </foomail:script>
>           </foomail:sieve>
>         </foomail:sieves>
>       </foomail:user>
>     </foomail:config>

This is also fine, modulo a couple of details - you're missing the
necessary xmlns attributes to identify the namespaces and the <sieve:sieve>
wrapper around the entire script. Fixing these, you'd end up with:

    <foomail:config xmlns:foomail="http://exammple.com/foomail"
                    xmlns:sieve="urn:ietf:params:xml:ns:sieve">
      <foomail:service service="smtp">
        <foomail:port>25</foomail:port>
        <foomail:listen>127.0.0.1</foomail:listen>
      </foomail:service>
      <foomail:user id="1">
        <foomail:name>Username</foomail:name>
        <foomail:sieves>
          <foomail:sieve>
            <foomail:name>On vacation</foomail:name>
            <sieve:sieve>
	      <sieve:control name="require">
		<sieve:str>vacation</sieve:str>
	      </sieve:control>
              <sieve:action name="vacation">
                <sieve:str>I'm away on vacation.</sieve:str>
              </sieve:action>
            </sieve:sieve>
          </foomail:sieve>
        </foomail:sieves>
      </foomail:user>
    </foomail:config>

Of course this is just one possible variant out of many - you could use
different prefixes, or use no prefix for one of the two namespaces, you
could have an additional set of wrapper elemenets or even switch some
foomail elements to attributes and use fewer, etc. etc.

				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 n0EIfTOL092597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jan 2009 11:41:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0EIfTTV092596; Wed, 14 Jan 2009 11:41:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0EIfIQb092575 for <[e-mail]>; Wed, 14 Jan 2009 11:41:28 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 12E054AC46; Wed, 14 Jan 2009 19:41:17 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.0.5) with esmtp id 1231958476-21270-1/6/24 (5 recipients); Wed, 14 Jan 2009 19:41:16 +0100
Message-Id: <[e-mail]>
Date: Wed, 14 Jan 2009 19:41:29 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: draft-freed-sieve-in-xml status?
Cc: Robert Burrell Donkin <[e-mail]>, Ned Freed <[e-mail]>, Aaron Stone <[e-mail]>
References: <[e-mail]> <PCbmC+s//[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1231700263.16458.102.camel@turtle> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
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 Burrell Donkin writes:
> if a parser is generally expected to map the data block to sieve 
> comments, [...]

Well, is it? That's the big question, isn't it?

Arnt



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 n0EGkkIS083108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jan 2009 09:46:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0EGkkN6083107; Wed, 14 Jan 2009 09:46:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.184]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0EGkYvV083079 for <[e-mail]>; Wed, 14 Jan 2009 09:46:45 -0700 (MST) (envelope-from [e-mail])
Received: by fk-out-0910.google.com with SMTP id 18so353981fkq.10 for <[e-mail]>; Wed, 14 Jan 2009 08:46:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=uMHJ6nhTMjQtU00tGtgpB7mgg8pZ7oiHUOWOObfburs=; b=vTR81JA5lsp9ObaDdSo2pUbQqHph9t4c9nbJFAxcBtdqTDFiEHbDDTTmU8W2uRMMiW 0PNDxgvLmanBUn6YM8b4fBfuSrQQAYSlOcrSaJ7CL4KUxQU+mvMRXkAH+UnbymjCTOE2 wB6WccxAwEOnB9eHQ73GKznSTlH7oJVpLesrw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=aomYB7bmMHrOIJMiqtQWPWnKNBJrKezKv+cdvkWZPF8/ASAOYdtqN3S/Xf6OIpF3sj YtnjZp/tt1Oys9LISexBDyOoSkXAmGCBjgKz0u3Gtx4i7i+H9Sk3IRU4KEQ/zi/QEBQi yiSMx7aZ8KQyT0SMoBieqSeZ4gUtvELIgyFPM=
Received: by 10.181.220.19 with SMTP id x19mr80246bkq.136.1231951593700; Wed, 14 Jan 2009 08:46:33 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Wed, 14 Jan 2009 08:46:33 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 14 Jan 2009 16:46:33 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Arnt Gulbrandsen" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [e-mail], "Ned Freed" <[e-mail]>, "Aaron Stone" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <PCbmC+s//[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1231700263.16458.102.camel@turtle> <[e-mail]> <[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>

On Mon, Jan 12, 2009 at 11:25 AM, Arnt Gulbrandsen
<[e-mail]> wrote:
>
> Ned Freed writes:
>>
>> The other issue here is how to map this stuff to regular Sieve. The
>> stylesheet given in the appendix maps displaydata and displayblock material
>> into structured comments. This can easily be extended/changed to cover the
>> handling of material in other namespaces. But do we want to formalize the
>> structured comment convention?
>
> My desire for structured comments is vanishingly small. My two cents.
>
>> Finally, there's the issue of how to handle other comments, which we've
>> discussed in the past but may be worth revisiting now. Currently regular
>> Sieve comments are mapped to <comment></comment> blocks rather than to
>> proper XML comments. The reason for this is that not all XML processors
>> provide access to stuff inside of <!-- foo --> constructs, so comments may
>> get lost when converting from Sieve-in-XML back to regular Sieve. Do we want
>> to continue to do things this way?
>
> It's a decent reason at least, but it doesn't make me very happy.

modelling sieve comments as elements (as opposed to XML comments) is a
very natural and obvious way to map these domains and separates the
concerns of commenting on the XML serialization from comments in the
sieve script.

>> In any case, here's a concrete proposal for how to move forward:
>>
>> (1) Add the necessary stuff to allow use of XML in other namespaces
>>    whereever displaydata is currently allowed.
>>
>> (2) Drop displaydata, making the use of namespaces required if you want
>>    to embed other stuff inside of a Sieve-in-XML.
>>
>> (3) Add a section defining the structured comment convention for
>>    representing this other stuff in regular Sieve format.
>>
>> (4) Change displayblock to just block, making it clear it can be used for
>>    other sorts of groupings.
>>
>> (5) Leave the current mapping of unstructured Sieve comments to
>>    <comment></comment> blocks alone.
>
> OK.
>
> I wish I'd kept my mouth shut. So many of these things are just better than
> some even worse alternative.
>
> <comment> exists so that even bad XML processors must preserve comments in a
> round-trip conversion, which seems weak justification. Not so weak that I
> actively disagree, but weak enough to make me unhappy.

XML comments tend to be difficult to preserve when transforming
documents and so on.  XML binders are unlikely to support semantic
content in comments, so it's not just bad XML processors which are
going to have problems.

using an element to model the comment part of the grammar is very
natural and makes the relationship between the XML structure and the
sieve structure clear and obvious.

if a parser is generally expected to map the data block to sieve
comments, replacing both separate block structures with support for
structure comments would not only make this clear and obvious but
would mean that the XML structure would have a simple and obvious
isomorphism to the Sieve structure.

- 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 n0EGVB9h081180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jan 2009 09:31:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0EGVB11081179; Wed, 14 Jan 2009 09:31:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0EGUxbd081147 for <[e-mail]>; Wed, 14 Jan 2009 09:31:10 -0700 (MST) (envelope-from [e-mail])
Received: by fk-out-0910.google.com with SMTP id 18so349180fkq.10 for <[e-mail]>; Wed, 14 Jan 2009 08:30:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=+AJm8eQSTFqBEzRt/2+Jj50TLy5UHUDfK71+H4GJ+4A=; b=Z6CpxHLO5bXulivgcVjlVpYwVUXSsLyPTTal4nr1r3xR6FO569E5dFuA5enaFYWGXd QfyZMqN4ZMgHq+j3dbn4aqkhPzT0f2/v1HJru/6+HqbtzktmesY8eeuNx5yaTL8akV+h GDiiwjxp3A3qZ2cmrjspfa5ZmHbXAP78IiFqI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=hUOb79JQyKf8Ak7MJI4kERa3TzqeG1VBXNLVVf/Tyq+i3GI10HTa93KomMnmTgBHkm IW265yCHB9JxOta5p4APXzvMEECElhM97EtiBgHl3VsmdBIBrfk9mRnSgEWBEHTZaiKq FhTUppLLC1SOQDCfkhyZBGUFUBZe8C0K8A2o8=
Received: by 10.181.37.6 with SMTP id p6mr70781bkj.197.1231950657706; Wed, 14 Jan 2009 08:30:57 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Wed, 14 Jan 2009 08:30:57 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 14 Jan 2009 16:30:57 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Alexey Melnikov" <[e-mail]>
Subject: Re: How to get implementors involved (was Re: draft-freed-sieve-in-xml status?)
Cc: "Ned Freed" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

On Thu, Dec 25, 2008 at 12:06 PM, Alexey Melnikov
<[e-mail]> wrote:
> Robert Burrell Donkin wrote:
>>>>
>>>> IMO it is a method (but not the only one) of producing reliable
>>>> relatively bug free software. i think this is a reasonable
>>>> pre-requisite for good interoperability. a good suite should aim to
>>>> reduce the numbers of poor implementations which claim compatibility
>>>> rather than try to ensure that good implementations interoperate
>>>> perfectly.
>>>>
>>>
>>> I'm always cautious about extrapolating from limited data - and we
>>> haven't seen
>>> all that much use of scripts being moved from one implementation to
>>> another.
>>> But to the extent we have, the problems that have shown up have been
>>> interop
>>> issues. Unfortunately there are several Sieve implementations out there
>>> that
>>> have chosen to ignore the extensions we've defined and roll their own to
>>> do
>>> things the base specification does not cover.
>>>
>>
>> is there any (lightweight) way for implementors to let this group know
>> about the extensions they've rolled? (other than showing on this list)
>>
>
> I think subscribing to the mailing list is a low enough bar, but if people
> think that that is too heavyweight, then they may contact me directly.

i did ask a few people a few months ago but they declined. my
experiences in this group have not been positive enough for me to be
to be able to offer them any encouragement to join.

i have some private correspondence which i may be able to get
permission to forward to you.

> But note that such contacts are going to be purely informal in their nature
> and have nothing to do with me be the Sieve WG chair. I just happen to know
> authors of various Sieve extensions ;-) and also happen own sieve.info
> domain.

ok

- 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 n0DFoAOo099534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2009 08:50:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0DFoA4P099533; Tue, 13 Jan 2009 08:50:10 -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 n0DFnxne099514 for <[e-mail]>; Tue, 13 Jan 2009 08:50:09 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id B4A3610B9F5A; Tue, 13 Jan 2009 10:49:58 -0500 (EST)
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 Z7bqGsqaDWGa; Tue, 13 Jan 2009 10:49:58 -0500 (EST)
Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 98C0C10B9F53; Tue, 13 Jan 2009 10:49:57 -0500 (EST)
Date: Tue, 13 Jan 2009 10:49:55 -0500
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
cc: Alexey Melnikov <[e-mail]>
Subject: Re: Recommended ManageSieve TCP port 2000 is already allocated to Cisco SCCP
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <05a301c974ec$911d4c10$[e-mail]> <h5Wo2mXiNb1sS/[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=715
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,

--On January 13, 2009 7:22:28 AM -0800 Ned Freed <[e-mail]> 
wrote:

>> The latest ManageSieve draft already does that ;-).
>
> Sorry, forgot that was in there.
>
> Given that support for SRV records is already required, old servers that
> are listening on port 2000 can be made to work with a new client that
> defaults to a different port simply by adding an appropriate SRV record.
> And an old client that goes straight to port 2000 on the named server
> isn't going to interoperate with a new SRV-dependent setup anyway. So I
> see no compelling reason to continue to mess around with port 2000. Let's
> just get a new port assigned, put it in there and be done with it.

+1

-- 
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 n0DFXnK0098454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2009 08:33:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0DFXnvY098453; Tue, 13 Jan 2009 08:33:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from excalibur.hozed.org (excalibur.hozed.org [209.234.73.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0DFXaNX098436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 13 Jan 2009 08:33:48 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) (uid 1000) by excalibur.hozed.org with local; Tue, 13 Jan 2009 09:33:27 -0600 id 000055CA.496CB447.00006FCD
Date: Tue, 13 Jan 2009 09:33:27 -0600
From: Troy Benjegerdes <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Arnt Gulbrandsen <[e-mail]>, [e-mail], Dan Wing <[e-mail]>, Alexey Melnikov <[e-mail]>
Subject: Re: Recommended ManageSieve TCP port 2000 is already allocated to Cisco SCCP
Message-ID: <[e-mail]>
References: <[e-mail]> <05a301c974ec$911d4c10$[e-mail]> <h5Wo2mXiNb1sS/[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.13 (2006-08-11)
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>

On Tue, Jan 13, 2009 at 09:38:13AM -0500, Jeffrey Hutzelman wrote:
> 
> --On Tuesday, January 13, 2009 09:28:27 AM +0100 Arnt Gulbrandsen 
> <[e-mail]> wrote:
> 
> >Pushing SCCCP out of the way isn't going to work very well... I suggest
> >getting a new port (x) and using these rules:
> >
> >Clients MUST try port x first. If a client gets connection refused on the
> >right port number, it MAY try 2000, but in that case it should watch out
> >for SCCCP. Sieve banners look like <example>, and always contain a line
> >starting with "SIEVE " and one starting with "IMPLEMENTATION ". SCCCP
> >banners look like <example>, and always <dan?>.
> 
> Instead of standardizing a multi-port search procedure, I suggest we 
> standardize the use of DNS SRV records to discover managesieve servers.
> 
> -- Jeff

I would second the DNS SRV record approach. It would be quite convenient
to have a MUA that used DNS SRV records to find it's IMAP, SMTP-MSA,
and Managesieve servers.



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 n0DFTn2U098063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2009 08:29:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0DFTn56098062; Tue, 13 Jan 2009 08:29:49 -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 n0DFTmSv098056 for <[e-mail]>; Tue, 13 Jan 2009 08:29:49 -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]; Tue, 13 Jan 2009 07:29:46 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 13 Jan 2009 07:29:41 -0800 (PST)
Date: Tue, 13 Jan 2009 07:22:28 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Recommended ManageSieve TCP port 2000 is already allocated to Cisco SCCP
In-reply-to: "Your message dated Tue, 13 Jan 2009 15:02:37 +0000" <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Ned Freed <[e-mail]>, Jeffrey Hutzelman <[e-mail]>, Arnt Gulbrandsen <[e-mail]>, [e-mail], Dan Wing <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
References: <[e-mail]> <05a301c974ec$911d4c10$[e-mail]> <h5Wo2mXiNb1sS/[e-mail]> <[e-mail]> <[e-mail]> <[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>

> On Tue, Jan 13, 2009 at 2:59 PM, Ned Freed <[e-mail]> wrote:
> >
> >> --On Tuesday, January 13, 2009 09:28:27 AM +0100 Arnt Gulbrandsen
> >> <[e-mail]> wrote:
> >
> >> > Pushing SCCCP out of the way isn't going to work very well... I suggest
> >> > getting a new port (x) and using these rules:
> >> >
> >> > Clients MUST try port x first. If a client gets connection refused on
> >> > the
> >> > right port number, it MAY try 2000, but in that case it should watch out
> >> > for SCCCP. Sieve banners look like <example>, and always contain a line
> >> > starting with "SIEVE " and one starting with "IMPLEMENTATION ". SCCCP
> >> > banners look like <example>, and always <dan?>.
> >
> >> Instead of standardizing a multi-port search procedure, I suggest we
> >> standardize the use of DNS SRV records to discover managesieve servers.
> >
> > Excellent idea. I strongly support doing this.

> The latest ManageSieve draft already does that ;-).

Sorry, forgot that was in there.

Given that support for SRV records is already required, old servers that are
listening on port 2000 can be made to work with a new client that defaults to a
different port simply by adding an appropriate SRV record. And an old client
that goes straight to port 2000 on the named server isn't going to interoperate
with a new SRV-dependent setup anyway. So I see no compelling reason to
continue to mess around with port 2000. Let's just get a new port assigned, put
it in there and be done with it.

				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 n0DFBlHM096882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2009 08:11:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0DFBlpL096881; Tue, 13 Jan 2009 08:11:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0DFBaRG096872 for <[e-mail]>; Tue, 13 Jan 2009 08:11:46 -0700 (MST) (envelope-from [e-mail])
Received: by wf-out-1314.google.com with SMTP id 25so46087wfc.28 for <[e-mail]>; Tue, 13 Jan 2009 07:11:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=zhO6rYYe6/tEtlq0kCtB4kXXmpDbH8cRJQua69QnS8I=; b=soyyiPdGUfyzgr4x8Se1nXRQ7Jh/Vg4+IKimxUs+2xcFDEvMLp2hX/OMa7O6RuUANH 9l4AH0c8jJ8pFTYjG34oELxRSLudRb21o/dnAjKsJPh1YAsmQdz5UqdV2PxBBNLcndFw xRozY0Z7dwx8DnUdXN9hpArbUq9j9Cz+LdlTY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=B4ebtiAmD7WsrPuD7888G6IQ6DQ65K+PPoHk7ir7PJrqK+QNyAiPwzJJk1mtGRjCY1 G0QMQyJq79n7J+Ls1vrSD4wsumjrTP99IM+ysBt8cd2DsVaHQGCX0lkpNgtmScIm2B7y TGKhzjfej9JKW21AvIUQAbKIkqKmXAdxOOm/w=
Received: by 10.143.2.19 with SMTP id e19mr12907649wfi.96.1231859496134; Tue, 13 Jan 2009 07:11:36 -0800 (PST)
Received: by 10.143.42.15 with HTTP; Tue, 13 Jan 2009 07:11:36 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 13 Jan 2009 15:11:36 +0000
From: "Alexey Melnikov" <[e-mail]>
To: "Arnt Gulbrandsen" <[e-mail]>
Subject: Re: Recommended ManageSieve TCP port 2000 is already allocated to Cisco SCCP
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <05a301c974ec$911d4c10$[e-mail]> <h5Wo2mXiNb1sS/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Google-Sender-Auth: 0fd65642a78e165e
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>

On Tue, Jan 13, 2009 at 3:07 PM, Arnt Gulbrandsen
<[e-mail]> wrote:
> Alexey Melnikov writes:
>> The latest ManageSieve draft already does that ;-).
>
> Did you use the text I suggested ages ago? I had misgivings later...

I don't remember which version I've used. Please review the latest draft.



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 n0DF7Ips096600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2009 08:07:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0DF7Ibp096597; Tue, 13 Jan 2009 08:07:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0DF7FDv096590 for <[e-mail]>; Tue, 13 Jan 2009 08:07:16 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 321F44AC46; Tue, 13 Jan 2009 16:07:15 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.0.5) with esmtp id 1231859234-21270-1/6/12 (6 recipients); Tue, 13 Jan 2009 16:07:14 +0100
Message-Id: <[e-mail]>
Date: Tue, 13 Jan 2009 16:07:28 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Recommended ManageSieve TCP port 2000 is already allocated to Cisco SCCP
Cc: Dan Wing <[e-mail]>, Alexey Melnikov <[e-mail]>, Ned Freed <[e-mail]>, Jeffrey Hutzelman <[e-mail]>
References: <[e-mail]> <05a301c974ec$911d4c10$[e-mail]> <h5Wo2mXiNb1sS/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[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>

Alexey Melnikov writes:
> The latest ManageSieve draft already does that ;-).

Did you use the text I suggested ages ago? I had misgivings later...

Arnt



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 n0DF2nS3096389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2009 08:02:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0DF2ntn096388; Tue, 13 Jan 2009 08:02:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yw-out-1718.google.com (yw-out-1718.google.com [74.125.46.156]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0DF2cHd096368 for <[e-mail]>; Tue, 13 Jan 2009 08:02:48 -0700 (MST) (envelope-from [e-mail])
Received: by yw-out-1718.google.com with SMTP id 5so19775ywr.4 for <[e-mail]>; Tue, 13 Jan 2009 07:02:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=g9ltuouPmEgZ63xBUieJIF1vqzMOx8uO0QHjZSMoLB0=; b=eV5b09BUl9Ob2reO1913knlagsRF/Ku3sCfBcUZ1EON+jtd1CVPQmj45fDaoTy3g// WnMxsy3IE/Bh+P+XCgBWVBofhuFOV8XzaBsRPlQoylccHfiNVpJ6W1TPpN9gkMI2dK43 wZmtWBJvcPCEqQPtFesRuiWoFa7P15CAmxTHQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=duv6l9Lf5eXE1fJyRlrf5WHbODSdoB0aocCkv30l5EExv1PHWAj7TavQ2zGxcrqINB SGFAYLH4oHa0n8GXBnXEV3vrcgheKvB+cxBuEyPUNuOqKpUWTPWt6IL5EaetuJW1wmiB cqKwbzmtxdo3qi+JiWG6y1777FNZoDemSh5BA=
Received: by 10.142.191.5 with SMTP id o5mr4165025wff.244.1231858957612; Tue, 13 Jan 2009 07:02:37 -0800 (PST)
Received: by 10.143.42.15 with HTTP; Tue, 13 Jan 2009 07:02:37 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 13 Jan 2009 15:02:37 +0000
From: "Alexey Melnikov" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Subject: Re: Recommended ManageSieve TCP port 2000 is already allocated to Cisco SCCP
Cc: "Jeffrey Hutzelman" <[e-mail]>, "Arnt Gulbrandsen" <[e-mail]>, [e-mail], "Dan Wing" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <05a301c974ec$911d4c10$[e-mail]> <h5Wo2mXiNb1sS/[e-mail]> <[e-mail]> <[e-mail]>
X-Google-Sender-Auth: 2b423c3b39121494
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>

On Tue, Jan 13, 2009 at 2:59 PM, Ned Freed <[e-mail]> wrote:
>
>> --On Tuesday, January 13, 2009 09:28:27 AM +0100 Arnt Gulbrandsen
>> <[e-mail]> wrote:
>
>> > Pushing SCCCP out of the way isn't going to work very well... I suggest
>> > getting a new port (x) and using these rules:
>> >
>> > Clients MUST try port x first. If a client gets connection refused on
>> > the
>> > right port number, it MAY try 2000, but in that case it should watch out
>> > for SCCCP. Sieve banners look like <example>, and always contain a line
>> > starting with "SIEVE " and one starting with "IMPLEMENTATION ". SCCCP
>> > banners look like <example>, and always <dan?>.
>
>> Instead of standardizing a multi-port search procedure, I suggest we
>> standardize the use of DNS SRV records to discover managesieve servers.
>
> Excellent idea. I strongly support doing this.

The latest ManageSieve draft already does that ;-).



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 n0DF0Akm096187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2009 08:00:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0DF0ABw096186; Tue, 13 Jan 2009 08:00:10 -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 n0DExxgv096129 for <[e-mail]>; Tue, 13 Jan 2009 08:00:09 -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]; Tue, 13 Jan 2009 06:59:57 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 13 Jan 2009 06:59:54 -0800 (PST)
Date: Tue, 13 Jan 2009 06:59:26 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Recommended ManageSieve TCP port 2000 is already allocated to Cisco SCCP
In-reply-to: "Your message dated Tue, 13 Jan 2009 09:38:13 -0500" <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Arnt Gulbrandsen <[e-mail]>, [e-mail], Dan Wing <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <05a301c974ec$911d4c10$[e-mail]> <h5Wo2mXiNb1sS/[e-mail]> <[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>

> --On Tuesday, January 13, 2009 09:28:27 AM +0100 Arnt Gulbrandsen
> <[e-mail]> wrote:

> > Pushing SCCCP out of the way isn't going to work very well... I suggest
> > getting a new port (x) and using these rules:
> >
> > Clients MUST try port x first. If a client gets connection refused on the
> > right port number, it MAY try 2000, but in that case it should watch out
> > for SCCCP. Sieve banners look like <example>, and always contain a line
> > starting with "SIEVE " and one starting with "IMPLEMENTATION ". SCCCP
> > banners look like <example>, and always <dan?>.

> Instead of standardizing a multi-port search procedure, I suggest we
> standardize the use of DNS SRV records to discover managesieve servers.

Excellent idea. I strongly support doing 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 n0DEt8Q7095203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2009 07:55:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0DEt8ZU095202; Tue, 13 Jan 2009 07:55:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0DEsvFN095171 for <[e-mail]>; Tue, 13 Jan 2009 07:55:07 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id AB9474AC72; Tue, 13 Jan 2009 15:54:56 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.0.5) with esmtp id 1231858496-21270-1/6/11 for [e-mail]; Tue, 13 Jan 2009 15:54:56 +0100
Message-Id: <J2+FlgMufCh++uZa/[e-mail]>
Date: Tue, 13 Jan 2009 15:55:10 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Recommended ManageSieve TCP port 2000 is already allocated to Cisco SCCP
References: <[e-mail]> <05a301c974ec$911d4c10$[e-mail]> <h5Wo2mXiNb1sS/[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
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>

Jeffrey Hutzelman writes:
> Instead of standardizing a multi-port search procedure, I suggest we 
> standardize the use of DNS SRV records to discover managesieve 
> servers.

I thought so too, but I couldn't formulate a good and complete set of 
rules. That's why I haven't suggested that (for a couple of years).

The best I could come up with is:

1. Get a port (x) from IANA.
2. Servers listen to port x by default, but must be configurable to use 
another port.
3. Clients do an SRV lookup for _managesieve._tcp.target and fall back 
to target port x if no SRV record is found.

It's possible to make old clients work (except for the literal/literal+ 
problem) by pointing at port 2000 in the SRV record. But I'm not happy 
enough to really like this solution.

Arnt



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 n0DEcZID094303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2009 07:38:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0DEcZs6094302; Tue, 13 Jan 2009 07:38:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0DEcNNr094291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 13 Jan 2009 07:38:34 -0700 (MST) (envelope-from [e-mail])
Received: from 68-246-211-13.pools.spcsdns.net (173-101-174-117.pools.spcsdns.net [173.101.174.117]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n0DEcDcN021051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2009 09:38:15 -0500 (EST)
Date: Tue, 13 Jan 2009 09:38:13 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>, [e-mail]
cc: Dan Wing <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Recommended ManageSieve TCP port 2000 is already allocated to Cisco SCCP
Message-ID: <[e-mail]>
In-Reply-To: <h5Wo2mXiNb1sS/[e-mail]>
References: <[e-mail]> <05a301c974ec$911d4c10$[e-mail]> <h5Wo2mXiNb1sS/[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.185.41
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>

--On Tuesday, January 13, 2009 09:28:27 AM +0100 Arnt Gulbrandsen 
<[e-mail]> wrote:

> Pushing SCCCP out of the way isn't going to work very well... I suggest
> getting a new port (x) and using these rules:
>
> Clients MUST try port x first. If a client gets connection refused on the
> right port number, it MAY try 2000, but in that case it should watch out
> for SCCCP. Sieve banners look like <example>, and always contain a line
> starting with "SIEVE " and one starting with "IMPLEMENTATION ". SCCCP
> banners look like <example>, and always <dan?>.

Instead of standardizing a multi-port search procedure, I suggest we 
standardize the use of DNS SRV records to discover managesieve servers.

-- Jeff



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 n0DAr7Jl079428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2009 03:53:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0DAr7IM079427; Tue, 13 Jan 2009 03:53:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0DAr4cR079421 for <[e-mail]>; Tue, 13 Jan 2009 03:53:05 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 1ACF24AC46; Tue, 13 Jan 2009 11:53:04 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.0.5) with esmtp id 1231843983-21270-1/6/9 (4 recipients); Tue, 13 Jan 2009 11:53:03 +0100
Message-Id: <[e-mail]>
Date: Tue, 13 Jan 2009 11:53:17 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: draft-freed-sieve-in-xml status?
Cc: Robert Burrell Donkin <[e-mail]>, Ned Freed <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> </te0ORth/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
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 Burrell Donkin writes:
> On 1/12/09, Arnt Gulbrandsen <[e-mail]> wrote:
>> It isn't limited to that. Borderline issues are in, only issues which 
>> do not apply to delivery over the internet are out.
>
> I think that makes sense to me now

("borderline" -> "border-straddling")

> So, providing a use case could be equally applied to a synchronously 
> processed mail, it doesn't matter that the known examples are in 
> servers using asynchronous processing, right?

Right. Provided that people think the known examples have plausible 
in-scope parallels.

Arguing ONLY from out-of-scope use cases has bad karma.

Arnt



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 n0D8STjE069835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2009 01:28:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0D8STZb069834; Tue, 13 Jan 2009 01:28:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0D8SGr5069815 for <[e-mail]>; Tue, 13 Jan 2009 01:28:28 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 4007C4AC46; Tue, 13 Jan 2009 09:28:14 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.0.5) with esmtp id 1231835293-21270-1/6/5 (3 recipients); Tue, 13 Jan 2009 09:28:13 +0100
Message-Id: <h5Wo2mXiNb1sS/[e-mail]>
Date: Tue, 13 Jan 2009 09:28:27 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Recommended ManageSieve TCP port 2000 is already allocated to Cisco SCCP
Cc: Dan Wing <[e-mail]>, Alexey Melnikov <[e-mail]>
References: <[e-mail]> <05a301c974ec$911d4c10$[e-mail]>
In-Reply-To: <05a301c974ec$911d4c10$[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
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>

Pushing SCCCP out of the way isn't going to work very well... I suggest 
getting a new port (x) and using these rules:

Clients MUST try port x first. If a client gets connection refused on 
the right port number, it MAY try 2000, but in that case it should 
watch out for SCCCP. Sieve banners look like <example>, and always 
contain a line starting with "SIEVE " and one starting with 
"IMPLEMENTATION ". SCCCP banners look like <example>, and always 
<dan?>.

Servers MUST listen to port x, and MAY also listen to 2000 to cater to 
old clients.

Client and server implementers using port 2000 should note that 
some/many old servers and clients have a bug wrt. literals. Sending 
correct literals may cause the peer to detect a "syntax error", and so 
does sending incorrect literals.

Arnt



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 n0CJX7RF036037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2009 12:33:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0CJX7Lv036036; Mon, 12 Jan 2009 12:33:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0CJWumb036005 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for <[e-mail]>; Mon, 12 Jan 2009 12:33:07 -0700 (MST) (envelope-from [e-mail])
X-IronPort-AV: E=Sophos;i="4.37,254,1231113600";  d="scan'208";a="121766635"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 12 Jan 2009 19:32:55 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0CJWtbx006810; Mon, 12 Jan 2009 11:32:55 -0800
Received: from dwingwxp01 ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0CJWt1h014143; Mon, 12 Jan 2009 19:32:55 GMT
From: "Dan Wing" <[e-mail]>
To: "'Alexey Melnikov'" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: RE: Recommended ManageSieve TCP port 2000 is already allocated to Cisco SCCP
Date: Mon, 12 Jan 2009 11:32:55 -0800
Message-ID: <05a301c974ec$911d4c10$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Thread-Index: Acl06yAD8c3W28brRuWgHO3w4kbR4wAAQNAQ
In-Reply-To: <[e-mail]>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1406; t=1231788775; x=1232652775; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22Dan=20Wing=22=20<[e-mail]> |Subject:=20RE=3A=20Recommended=20ManageSieve=20TCP=20port= 202000=20is=20already=20allocated=20to=20Cisco=20SCCP |Sender:=20; bh=w1yP7ptslGJtVmkc+mw3yxl31NoaJDBZ8BUY5k0EflI=; b=sIWI1Ny+10OdOCJVJbuU4+dTULay3BMwJ3lxN2Yb+E9KKAO4OlwpE8R5Ro Wug2AUy1VdzjWi2OUs5QxJ1n4CUS8JqYCzXG3oRAdgGzM/6tXD5DntoBpciB A2JgZ1ILav6vYI6sVRSgZg7ommbbNF2IBzuqsPpnrc6dtaNXXFPsM=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
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>

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Alexey Melnikov
> Sent: Monday, January 12, 2009 11:23 AM
> To: Dan Wing; [e-mail]
> Subject: Recommended ManageSieve TCP port 2000 is already 
> allocated to Cisco SCCP
> 
> On Mon, Jan 5, 2009 at 11:21 PM, Amanda Baber via RT
> <[e-mail]> wrote:
> > IESG:
> >
> > IANA has questions about draft-ietf-sieve-managesieve-05.txt:
> >
> > - This document requests the allocation of a TCP port that has
> > already been registered (2000, Cisco SCCP). Should the existing
> > registration be changed from "Cisco SCCP" to "ManageSieve"?
> 
> Dan,
> ManageSieve was invented about 10 years ago and some implementations
> used port 2000 (unfortunately without registering it with IANA). How
> widely is Cisco SCCP implemented and would be changing the IANA
> allocated port number an option for you?

SCCP is our proprietary signaling protocol between our VoIP phones
and Unified Communication Manager (formerly called Call Manager),
with somewhere above 6 million IP phones in the field (as of 
2005, 
<http://newsroom.cisco.com/dlls/global/asiapac/news/2005/pr_09-23.html>,
most of which use SCCP.

-d

> To the WG: how widespread is usage of port 2000 for ManageSieve? Are
> people using any other port numbers?



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 n0CJMi40035624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2009 12:22:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0CJMiGB035623; Mon, 12 Jan 2009 12:22:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yx-out-1718.google.com (yx-out-1718.google.com [74.125.44.152]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0CJMXR2035613 for <[e-mail]>; Mon, 12 Jan 2009 12:22:44 -0700 (MST) (envelope-from [e-mail])
Received: by yx-out-1718.google.com with SMTP id 36so4951669yxh.4 for <[e-mail]>; Mon, 12 Jan 2009 11:22:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=SWAvWlUt6dUmTiXGGAhhtkR9MTRVZFgvBy8s8ov5BUs=; b=DDZ+rECMYj0zSTfnrB33iI2ZOa/7Uwo5ITCb9OlI3MUw9VfE0Kv4YaYYy0VZFeK31e exJZVDi5wGJv29D6AaebvxksgTqZZQbaP73gkSon7L+5TMmwVuZNQJ+iIiY7NZbmrnPK EFAwqiKI9wxtyVdaaN8kQIk5Sf2PgBsO5bJSo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=hbLnneMnjfKDzsxK9lPuq9H1TYCg/GUk/PVSGI4xkSTMT2EDghfLuEB098kUp+STQj EE1heL4NQk31dwvl8BYdMvep03BFcZh5SCpZgtPDr4YSo/1X2H8ldZr1Gs6HAI6CBb3D DfpRDnwcx0d4wYZLNy4p8Rp20UeA8emTOVknc=
Received: by 10.143.6.19 with SMTP id j19mr12498004wfi.128.1231788152579; Mon, 12 Jan 2009 11:22:32 -0800 (PST)
Received: by 10.143.42.15 with HTTP; Mon, 12 Jan 2009 11:22:32 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 12 Jan 2009 19:22:32 +0000
From: "Alexey Melnikov" <[e-mail]>
To: "Dan Wing" <[e-mail]>, [e-mail]
Subject: Recommended ManageSieve TCP port 2000 is already allocated to Cisco SCCP
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Google-Sender-Auth: 9cca278710a4ee1e
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>

On Mon, Jan 5, 2009 at 11:21 PM, Amanda Baber via RT
<[e-mail]> wrote:
> IESG:
>
> IANA has questions about draft-ietf-sieve-managesieve-05.txt:
>
> - This document requests the allocation of a TCP port that has
> already been registered (2000, Cisco SCCP). Should the existing
> registration be changed from "Cisco SCCP" to "ManageSieve"?

Dan,
ManageSieve was invented about 10 years ago and some implementations
used port 2000 (unfortunately without registering it with IANA). How
widely is Cisco SCCP implemented and would be changing the IANA
allocated port number an option for you?

To the WG: how widespread is usage of port 2000 for ManageSieve? Are
people using any other port numbers?



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 n0CHFO6t029114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2009 10:15:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0CHFOQl029113; Mon, 12 Jan 2009 10:15:24 -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-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0CHFB6F029069 for <[e-mail]>; Mon, 12 Jan 2009 10:15:22 -0700 (MST) (envelope-from [e-mail])
Received: by bwz5 with SMTP id 5so21452605bwz.10 for <[e-mail]>; Mon, 12 Jan 2009 09:15:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=netM9NacJGCQsIYHLQTXdMSBE2/8S4XZba7ROH4Ro3Q=; b=ASLMtPd4t/dWnOlQh9019KJsGuoPzAT/m4IgfGCKNTBKatRyQbMxz1a1TsUg5wlAD5 88N07qbCVYV5zGQxPPkXWNULttCB7b/dW+d8+bFXPspl+S1yiwt8I6jV2yxwW7CQ+qJg HfaWejI1MaOgO8ZktLNx2TLz39JY7ZehDQisk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ecpDM/gwjNuol1zEPyjVe9hkc8PGXwEB4AWbyT1uGreXNmR8mc1u65xKKWxiAOk1TF 6QMjVtK3s3aFM139o5upy/f73OIDX6g8xfFTfIXLeM8jKV0SpLRZvGBsVVvDoH4o33nY /D8RgNPzyfhFYH34Ktg41WXD0yLiDOUiIhgSU=
Received: by 10.180.222.14 with SMTP id u14mr11037048bkg.141.1231780275820; Mon, 12 Jan 2009 09:11:15 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Mon, 12 Jan 2009 09:11:15 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 12 Jan 2009 17:11:15 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Arnt Gulbrandsen" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [e-mail], "Ned Freed" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> </te0ORth/[e-mail]> <[e-mail]> <[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>

On 1/12/09, Arnt Gulbrandsen <[e-mail]> wrote:
> Robert Burrell Donkin writes:
>> On Mon, Jan 12, 2009 at 10:38 AM, Arnt Gulbrandsen
>> <[e-mail]> wrote:
>>> How to spool mail on disk is out of scope, and now to operate on the
>>> spooled mail is, too.
>>
>> AIUI spooling does not imply that it's stored to disc, just that the
>> SMTP transaction has completed and that the mail has been committed
>> to permanent storage.
>
> Careless of me. Please allow me to rephrase my sentence: =ABHow to spool
> mail is out of scope, and now to operate on the spooled mail is, too=BB.

Ok

>> however, the limit of the end of the SMTP transaction is an arbitrary
>> restriction based on a particular mail server architecture. there are
>> many ways that mail can enter a system over the public internet
>> before final delivery. the working group documentation is anything
>> but clear on the point that this working group is limited to the
>> consideration of filter a single protocol (SMTP).
>
> It isn't limited to that. Borderline issues are in, only issues which do
> not apply to delivery over the internet are out.

I think that makes sense to me now

So, providing a use case could be equally applied to a synchronously
processed mail, it doesn't matter that the known examples are in
servers using asynchronous processing, right?

> Is there any such issue in Ned's draft?

This issue arose from disputes about whether some use cases were in
scope. I should have been a bit careful not to let it spiral out of
control but some of Ned's at hominem comments got to me a little more
than they deserved.

Thanks

Robert

>
> Arnt
>



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 n0CF1tth021658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2009 08:01:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0CF1tWg021657; Mon, 12 Jan 2009 08:01:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0CF1huK021629 for <[e-mail]>; Mon, 12 Jan 2009 08:01:54 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 3A1864AC6A; Mon, 12 Jan 2009 16:01:43 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.0.5) with esmtp id 1231772502-21270-1/6/1 (4 recipients); Mon, 12 Jan 2009 16:01:42 +0100
Message-Id: <[e-mail]>
Date: Mon, 12 Jan 2009 16:01:54 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: draft-freed-sieve-in-xml status?
Cc: Robert Burrell Donkin <[e-mail]>, Ned Freed <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> </te0ORth/[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Mime-Version: 1.0
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 Burrell Donkin writes:
> On Mon, Jan 12, 2009 at 10:38 AM, Arnt Gulbrandsen
> <[e-mail]> wrote:
>> How to spool mail on disk is out of scope, and now to operate on the=20
>> spooled mail is, too.
>
> AIUI spooling does not imply that it's stored to disc, just that the=20
> SMTP transaction has completed and that the mail has been committed=20
> to permanent storage.

Careless of me. Please allow me to rephrase my sentence: =ABHow to spool=20
mail is out of scope, and now to operate on the spooled mail is, too=BB.

> however, the limit of the end of the SMTP transaction is an arbitrary=20
> restriction based on a particular mail server architecture. there are=20
> many ways that mail can enter a system over the public internet=20
> before final delivery. the working group documentation is anything=20
> but clear on the point that this working group is limited to the=20
> consideration of filter a single protocol (SMTP).

It isn't limited to that. Borderline issues are in, only issues which do=20
not apply to delivery over the internet are out.

Is there any such issue in Ned's draft?

Arnt



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 n0CDsI16014498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2009 06:54:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0CDsIGD014497; Mon, 12 Jan 2009 06:54:18 -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-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0CDs6Pg014477 for <[e-mail]>; Mon, 12 Jan 2009 06:54:17 -0700 (MST) (envelope-from [e-mail])
Received: by bwz5 with SMTP id 5so21263513bwz.10 for <[e-mail]>; Mon, 12 Jan 2009 05:54:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=8Y9lyJ2EcjiDl0fzhl0m7cxTq+s7o/L1kuAjn4ZO/mU=; b=OMahpijjsMqNAfRSEg6ibPG6YdlQftZJsDXRhvPnfFOlK8TwZNsTpGOcv+/B/LFVWD n0A0mJ8/SAD/S//aS8Wx4S38HUeY/l1IP0ipx1uyHP21on3EpC7aiS581IrBBti/KzbQ Otvx81CyH4gbCUXcREuYzCWya4G/Z8H3MOG7Q=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=VgHYXib/YCeTsOJp4e5oKMeXhuzXooYpYjdjeqkKIGdRW6X9JmH7ckShmuoUKl4iRN +wkeNS+fgqkiN0OHSpgtrzwJySbQCMgUdL0AUH3+YguehmgR6Tm/31+jWRHjx2PrvEl/ 6yAOJlaYU8rI7cYkN5z9B3bNoBJT42KI3+h40=
Received: by 10.181.50.1 with SMTP id c1mr10991823bkk.3.1231768214601; Mon, 12 Jan 2009 05:50:14 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Mon, 12 Jan 2009 05:50:14 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 12 Jan 2009 13:50:14 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Aaron Stone" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: "Ned Freed" <[e-mail]>, [e-mail]
In-Reply-To: <1231732067.16458.214.camel@turtle>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1231732067.16458.214.camel@turtle>
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>

On Mon, Jan 12, 2009 at 3:47 AM, Aaron Stone <[e-mail]> wrote:
> On Sun, 2009-01-11 at 18:30 -0800, Ned Freed wrote:
>> > so, just to ensure i understand this issue - you've decided to support
>> > namespaces fully and drop support for namespace unaware parsers?
>>
>> > (FWIW this is fine by me)
>>
>> Nope. I've decided not to specify any sort of "standard namespace prefix"
>> in the document. That's all.
>>
>> I have no idea what you mean by "support namespaces fully". But given the tone
>> of your most recent responses I'm no longer willing to spend time in a
>> give-and-take trying to figure what you mean by this.
>
> Let's try to keep this conversation on the path of concrete examples. I
> had no idea what this entire thread was about until Robert gave a
> specific XML snippet to illustrate what he wanted to do, and you gave a
> different one in response to illustrate the document state.

this isn't what i wanted to do but it was intended to illustrate a
point. i will try to remember to include more examples in future,
though.

> My current understanding from trying to follow this thread is that this
> snippet (from Robert) is not valid according to the document:
>
>     <control name="if">
>       <mix:editor-specific foo='bar'></mix:editor-specific>
>       <test name="header">
>         <tag>is</tag>
>         <str>Sender</str>
>         <str>[e-mail]</str>
>       </test>
>       <action name="fileinto">
>         <str>filter</str>
>       </action> <comment>move to "filter" mailbox</comment>
>     </control>
>
> This is syntactically valid XML, but semantically the element from the
> 'mix' namespace isn't going to make sense to a naive Sieve-XML parser.

yes - i think this goes to the heart of the discussion

> By some magic of XML specification buzzwords, I gather that the above
> snippet can be declared valid or invalid by the schema definition.
>
> How are mixed-namespace documents like this handled by XML parsers /
> editors / UIs / etc?

it depends on the approach

generative approaches generally handle this poorly. hand crafted
approaches handle this fine. these days, using SAX directly is rare
and DOM is out of fashion (too slow) so generative approaches tend to
dominate (at least in the java and .NET).

generative editors struggle with semantically mixed domains: it needs
some clue about which are annotations and which are sieve. this can be
fixed by editing the schema to remove the annotations.

> Is it reasonable to disallow a mixed namespace like
> this? Is there a reason not to allow such mixing?

disallowing mixed means that the schema can be used directly to
generate a good domain model which maps easily to the nodes in a sieve
processor.

allowing mixing means that existing editors which use their own
annotations can be used reasonably directly. mixed content makes
binding more fiddly.

most likely, the XML binding would either need to be done by hand,
some kind of DOM used or a SAX filter with conventional XML binding
framework upstream. not a major issue when loading the XML directly
from a stream, quite possibly more difficult if you want to use a
framework of some kind (eg web services).

a secondary question is what library creators (as opposed to
application creators) should do when they encounter mixed markup. i
think it's reasonable just to ignore it and concentrate just on the
elements which have semantic meaning in sieve (but others may
disagree).

> What if someone wants to use the Sieve-XML schema within a larger
> document? For example:
>
>    <foomail:config>
>      <foomail:service service="smtp">
>        <foomail:port>25</foomail:port>
>        <foomail:listen>127.0.0.1</foomail:listen>
>      </foomail:service>
>      <foomail:user id="1">
>        <foomail:name>Username</foomail:name>
>        <foomail:sieves>
>          <foomail:sieve>
>            <foomail:name>On vacation</foomail:name>
>            <foomail:script>
>              <sieve:action name="vacation">
>                <sieve:str>I'm away on vacation.</sieve:str>
>              </sieve:action>
>            </foomail:script>
>          </foomail:sieve>
>        </foomail:sieves>
>      </foomail:user>
>    </foomail:config>


this isn't usually such a problem since the foomail schema can either
specify any element, or just include sieve.

(this is very similar to SOAP so i'll include some general comments
about web services)

in practice, though, most generative approaches to web services don't
work that well with schema that include arbitrary elements. so, the
main issue would be whether the particular web service framework would
work without editing the schema.

- 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 n0CDHTaa011776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2009 06:17:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0CDHTlv011774; Mon, 12 Jan 2009 06:17:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.184]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0CDHHM7011762 for <[e-mail]>; Mon, 12 Jan 2009 06:17:28 -0700 (MST) (envelope-from [e-mail])
Received: by fk-out-0910.google.com with SMTP id 18so5552285fkq.10 for <[e-mail]>; Mon, 12 Jan 2009 05:17:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=XHdFozUEuoDCVRXw5E/mTvmtZVrHP6guKHVULP+g0qc=; b=dpDvIa20zPFolKEzAoBOrXDoSPA3NjZXa18WWpywx7vL2pjQciPZrEt1+USQTS0ZXW Qb2yd5uX+60wGv7EFpdiCiHG/HBw20ZJuY11ilo9KHE7KEAnDiQKQtDcx3YSmC9Q2g28 L73t3E1tJLBtu6ckZ/JNwLGJfyNAVzjrQcCSE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=wNIj/x5aMIagOLcDBzQlTY1+MtLCNriYZ1v1bLbh42Q9WimXFbxhXcCpvGdMEhJ/90 W1tdEkr2i/Hy1PIZ3pcNyTIEJO0Rxf6WenzcGEplfxR84KQpVmJ6pMzkzbQJLql0P6In 0OvQqwGI4WKibyjLios3cfI5cQHznUfCY9mPM=
Received: by 10.180.214.15 with SMTP id m15mr10966883bkg.78.1231766236819; Mon, 12 Jan 2009 05:17:16 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Mon, 12 Jan 2009 05:17:16 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 12 Jan 2009 13:17:16 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Arnt Gulbrandsen" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [e-mail], "Ned Freed" <[e-mail]>
In-Reply-To: </te0ORth/[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> </te0ORth/[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>

On Mon, Jan 12, 2009 at 10:38 AM, Arnt Gulbrandsen
<[e-mail]> wrote:
> Robert Burrell Donkin writes:
>>
>> I undestand now that this working group has been intentionally chartered
>> to exclude mail servers with a spooling architecture. Can anybody explain
>> why the IETF decided to exclude this class of mail server from it's
>> specification process?
>
> The IETF limits itself to things used over the public internet.

agreed

> How to spool
> mail on disk is out of scope, and now to operate on the spooled mail is,
> too.

AIUI spooling does not imply that it's stored to disc, just that the
SMTP transaction has completed and that the mail has been committed to
permanent storage.

however, the limit of the end of the SMTP transaction is an arbitrary
restriction based on a particular mail server architecture. there are
many ways that mail can enter a system over the public internet before
final delivery. the working group documentation is anything but clear
on the point that this working group is limited to the consideration
of filter a single protocol (SMTP).

- 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 n0CBP0fG004298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2009 04:25:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0CBP0hB004297; Mon, 12 Jan 2009 04:25:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0CBOwRd004288 for <[e-mail]>; Mon, 12 Jan 2009 04:24:59 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id A133C4AC5A; Mon, 12 Jan 2009 12:24:57 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1231759497-75452-1/6/25 (4 recipients); Mon, 12 Jan 2009 12:24:57 +0100
Message-Id: <[e-mail]>
Date: Mon, 12 Jan 2009 12:25:09 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: draft-freed-sieve-in-xml status?
Cc: Ned Freed <[e-mail]>, Aaron Stone <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <PCbmC+s//[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1231700263.16458.102.camel@turtle> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
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>

Ned Freed writes:
> The other issue here is how to map this stuff to regular Sieve. The 
> stylesheet given in the appendix maps displaydata and displayblock 
> material into structured comments. This can easily be 
> extended/changed to cover the handling of material in other 
> namespaces. But do we want to formalize the structured comment 
> convention?

My desire for structured comments is vanishingly small. My two cents.

> Finally, there's the issue of how to handle other comments, which 
> we've discussed in the past but may be worth revisiting now. 
> Currently regular Sieve comments are mapped to <comment></comment> 
> blocks rather than to proper XML comments. The reason for this is 
> that not all XML processors provide access to stuff inside of <!-- 
> foo --> constructs, so comments may get lost when converting from 
> Sieve-in-XML back to regular Sieve. Do we want to continue to do 
> things this way?

It's a decent reason at least, but it doesn't make me very happy.

> In any case, here's a concrete proposal for how to move forward:
>
> (1) Add the necessary stuff to allow use of XML in other namespaces
>     whereever displaydata is currently allowed.
>
> (2) Drop displaydata, making the use of namespaces required if you want
>     to embed other stuff inside of a Sieve-in-XML.
>
> (3) Add a section defining the structured comment convention for
>     representing this other stuff in regular Sieve format.
>
> (4) Change displayblock to just block, making it clear it can be used for
>     other sorts of groupings.
>
> (5) Leave the current mapping of unstructured Sieve comments to
>     <comment></comment> blocks alone.

OK.

I wish I'd kept my mouth shut. So many of these things are just better 
than some even worse alternative.

<comment> exists so that even bad XML processors must preserve comments 
in a round-trip conversion, which seems weak justification. Not so weak 
that I actively disagree, but weak enough to make me unhappy.

Arnt



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 n0CAcZWS000627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2009 03:38:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0CAcZVj000626; Mon, 12 Jan 2009 03:38:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0CAcNLH000606 for <[e-mail]>; Mon, 12 Jan 2009 03:38:34 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 5F24F4AC6A; Mon, 12 Jan 2009 11:38:22 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1231756701-75452-1/6/23 (4 recipients); Mon, 12 Jan 2009 11:38:21 +0100
Message-Id: </te0ORth/[e-mail]>
Date: Mon, 12 Jan 2009 11:38:33 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: draft-freed-sieve-in-xml status?
Cc: Robert Burrell Donkin <[e-mail]>, Ned Freed <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
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 Burrell Donkin writes:
> I undestand now that this working group has been intentionally 
> chartered to exclude mail servers with a spooling architecture. Can 
> anybody explain why the IETF decided to exclude this class of mail 
> server from it's specification process?

The IETF limits itself to things used over the public internet. How to 
spool mail on disk is out of scope, and now to operate on the spooled 
mail is, too.

There are some borderline cases. Sieve is one. The text format for IPv4 
and IPv6 addresses are another. I guess ARP is a third, come to think 
of it. I suppose RFCs 2852 and/or 5321 might contain words about spools 
and timeouts. But in general, the IETF is about the public internet.

Maybe the IETF should have a wider scope. I don't want to discuss that 
(not here and now, perhaps even never).

Arnt



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 n0C7xGJT091771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2009 00:59:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0C7xGaw091770; Mon, 12 Jan 2009 00:59:16 -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-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0C7xEFs091764 for <[e-mail]>; Mon, 12 Jan 2009 00:59:15 -0700 (MST) (envelope-from [e-mail])
Received: by bwz5 with SMTP id 5so20945164bwz.10 for <[e-mail]>; Sun, 11 Jan 2009 23:59:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Q8EgoE66jgv+kHvXSk9TvdNu0o4iPJY06yJa84lcnY0=; b=Nc4ggufXvyWxtVfkHYgOF4UaHAgd0nUX2DpR4XNeIJ/VxzyTmunrXMVZVqw/wI4VDP p+A6d9AVi6rmnEDgCQQGd949xUgo80/DpNWED7h1QltNXbYrkut8SAh+YYT1FQbHoQqM cXH2gE8nOvmE5Z7Lb7Q6FiMhNdkhP7v467VeY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=evfaTmZ+mPbRSsjxCiJISX28PrTCYg4Y/WLT8f1gW39/4mohKstJKtmLBVVo5XE1YZ 8hABBo2lkNrasR1/QyYirSgc1akRL8AFmIo45fsZojApbU4iSJfFiTOAHQZxq8j1iper yCYuaqWlxJbbYTYog3qn+k4zw9xvsqPK1hoUk=
Received: by 10.181.199.11 with SMTP id b11mr9947429bkq.105.1231747153873; Sun, 11 Jan 2009 23:59:13 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Sun, 11 Jan 2009 23:59:13 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 12 Jan 2009 07:59:13 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

On 1/12/09, Ned Freed <[e-mail]> wrote:
>> so, just to ensure i understand this issue - you've decided to support
>> namespaces fully and drop support for namespace unaware parsers?
>
>> (FWIW this is fine by me)
>
> Nope. I've decided not to specify any sort of "standard namespace prefix"
> in the document. That's all.
>
> I have no idea what you mean by "support namespaces fully". But given the
> tone
> of your most recent responses I'm no longer willing to spend time in a
> give-and-take trying to figure what you mean by this.

This point arose from the discussion on namespace support. Since then
you have moved from a refusal to support namespacing to effectively
dropping your requirement to support compatibility with legacy
namespace unaware parsers. Fine by me.

Robert

>
> 				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 n0C7f1XC091096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2009 00:41:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0C7f1wn091095; Mon, 12 Jan 2009 00:41:01 -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-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0C7em69091083 for <[e-mail]>; Mon, 12 Jan 2009 00:40:59 -0700 (MST) (envelope-from [e-mail])
Received: by bwz5 with SMTP id 5so20929687bwz.10 for <[e-mail]>; Sun, 11 Jan 2009 23:40:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=+Hooew0dQzxoWn40S0Y+sE2v6mhLfZltGUUekeMAvfo=; b=oIsy1CJQhyNPvgGPfTAND735hXbeO9BpZAq21o/Skh52IMCs4bBG++fS/fyKOh6bTf AtWeSLyJHmGAZhV8PT40uYR2Z8yGm1BtlsVUuti8sLcdGxo8julGrJiZw+U+RnhzZtyg vscKn8lx3d6TjMXtJvC+6QFFHhLdt5If1Qe7s=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Tu/Im7PS8QNh9SMY2eX+A+bv6y4nmqP0t+MYdwJF1THhNSpcwpZJDayfYjSQQSfPMq Py2udt5++/ns333LgWoKg3aCy8EcGDsJ9T9oJW6NCJaIpA+SHV41MlLeYiHUDMObEp4R PCm0YT3C1WhBEkQa5RzTpspyRA5wktGdrYbw8=
Received: by 10.181.201.18 with SMTP id d18mr10875321bkq.125.1231746047550; Sun, 11 Jan 2009 23:40:47 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Sun, 11 Jan 2009 23:40:47 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 12 Jan 2009 07:40:47 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

On 1/12/09, Ned Freed <[e-mail]> wrote:
>> On Sun, Jan 11, 2009 at 6:21 PM, Ned Freed <[e-mail]> wrote:
>
>> <snip>
>
>> >> > But really, this entire discussion has gone very far afield. Like it
>> >> > or not,
>> >> > Sieve is intended to be a language used to process email messages at
>> >> > or around
>> >> > the time of final delivery.
>> >> > The fact that it can be adapted for other uses may
>> >> > be interesting to you but simply is not relevant in the context of
>> >> > the work
>> >> > this group is chartered to do.
>> >
>> >> is this http://www.ietf.org/html.charters/sieve-charter.html the
>> >> charter?
>> >
>> > Yes
>
>> could anyone kindly point me to the sections which indicate that only
>> mail servers of a particular class of architecture are in scope?
>
> I've already done so in previous messages. It's the very first thing RFC
> 5228,
> the Sieve base specification, says:
>
>    This document describes a language for filtering email messages at
>    time of final delivery.
>
> Final delivery is a formal term used in many IETF email standards. It refers
> to
> the point at which the message exists the SMTP transport infrastructure and
> enters the message store.
>
> As its charter makes clear, the current Sieve group is chartered to work on
> a
> very specific set of Sieve extensions. There is nothing in there about
> revisiting the scope of applicability of Sieve.

Thank you for taking the time to explain.

I undestand now that this working group has been intentionally
chartered to exclude mail servers with a spooling architecture. Can
anybody explain why the IETF decided to exclude this class of mail
server from it's specification process?

Robert

>
> 				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 n0C3qvQ5080697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2009 20:52:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0C3qvD5080696; Sun, 11 Jan 2009 20:52:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0C3qlPn080684 for <[e-mail]>; Sun, 11 Jan 2009 20:52:57 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.33] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id F26BC2940; Sun, 11 Jan 2009 19:54:27 -0800 (PST)
Subject: Re: draft-freed-sieve-in-xml status?
From: Aaron Stone <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: Robert Burrell Donkin <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Sun, 11 Jan 2009 19:47:47 -0800
Message-Id: <1231732067.16458.214.camel@turtle>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.2 
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>

On Sun, 2009-01-11 at 18:30 -0800, Ned Freed wrote:
> > so, just to ensure i understand this issue - you've decided to support
> > namespaces fully and drop support for namespace unaware parsers?
> 
> > (FWIW this is fine by me)
> 
> Nope. I've decided not to specify any sort of "standard namespace prefix"
> in the document. That's all.
> 
> I have no idea what you mean by "support namespaces fully". But given the tone
> of your most recent responses I'm no longer willing to spend time in a
> give-and-take trying to figure what you mean by this.

Let's try to keep this conversation on the path of concrete examples. I
had no idea what this entire thread was about until Robert gave a
specific XML snippet to illustrate what he wanted to do, and you gave a
different one in response to illustrate the document state.

My current understanding from trying to follow this thread is that this
snippet (from Robert) is not valid according to the document:

     <control name="if">
       <mix:editor-specific foo='bar'></mix:editor-specific>
       <test name="header">
         <tag>is</tag>
         <str>Sender</str>
         <str>[e-mail]</str>
       </test>
       <action name="fileinto">
         <str>filter</str>
       </action> <comment>move to "filter" mailbox</comment>
     </control>

This is syntactically valid XML, but semantically the element from the
'mix' namespace isn't going to make sense to a naive Sieve-XML parser.
By some magic of XML specification buzzwords, I gather that the above
snippet can be declared valid or invalid by the schema definition.

How are mixed-namespace documents like this handled by XML parsers /
editors / UIs / etc? Is it reasonable to disallow a mixed namespace like
this? Is there a reason not to allow such mixing?

What if someone wants to use the Sieve-XML schema within a larger
document? For example:

    <foomail:config>
      <foomail:service service="smtp">
        <foomail:port>25</foomail:port>
        <foomail:listen>127.0.0.1</foomail:listen>
      </foomail:service>
      <foomail:user id="1">
        <foomail:name>Username</foomail:name>
        <foomail:sieves>
          <foomail:sieve>
            <foomail:name>On vacation</foomail:name>
            <foomail:script>
              <sieve:action name="vacation">
                <sieve:str>I'm away on vacation.</sieve:str>
              </sieve:action>
            </foomail:script>
          </foomail:sieve>
        </foomail:sieves>
      </foomail:user>
    </foomail:config>

Aaron



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 n0C3Kmo3079959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2009 20:20:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0C3Km13079958; Sun, 11 Jan 2009 20:20:48 -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 n0C3Kl3r079952 for <[e-mail]>; Sun, 11 Jan 2009 20:20:47 -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]; Sun, 11 Jan 2009 19:20:44 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 11 Jan 2009 19:20:41 -0800 (PST)
Date: Sun, 11 Jan 2009 18:45:16 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
In-reply-to: "Your message dated Sun, 11 Jan 2009 10:57:43 -0800" <1231700263.16458.102.camel@turtle>
To: Aaron Stone <[e-mail]>
Cc: Ned Freed <[e-mail]>, Arnt Gulbrandsen <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <PCbmC+s//[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1231700263.16458.102.camel@turtle>
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>

> > So I guess the question for the group here is what extensibility model do we
> > really want here? Do we want to require enclosure of material from other XML
> > sources in displaydata blocks, or do we want to allow other stuff to appear
> > without such blocks as long as it's in another namespace?

> I plead ignorance to the finer details of the XML Schema stuff described
> above, but off the cuff, not requiring displaydata seems cleaner to me.

Unfortunately, it's not quite that simple. The question is whether or not to
require the use of namespaces in order to embed stuff inside of a Sieve script
expressed in XML.

Both XML Schema and Relax let you say "allow any additional elements you want
here as long as it's in a different namespace". Alternately, you can say "allow
absolutely anything here", but if you do that you have to put  it inside of a
container element of some sort, which is exactly what
<displaydata> is.

What you cannot do is simply allow arbitrary content in the same namespace at
the same level as other elements that are schema validated. (Actually, you can
specify something like this in Relax, but the result is that you're validating
almost nothing.)

> Is the reason for the displaydata tag to tell an otherwise ignorant
> Sieve-XML-only program that the contents of the displaydata should be
> handled as verbatim data?

Yes, more or less. There has to be some indication that this content lies
outside the Sieve schema. That can done either with a namespace label or
with a container element.

So if we want to rely on namespaces, which IMO is a fine thing to do, we can
simply loosen the schema to allow material from other namespaces in and drop
displaydata entirely. (Displayblock, OTOH, still serves a useful purpose - you
need something like it to provide a higher level grouping construct.)

The other issue here is how to map this stuff to regular Sieve. The stylesheet
given in the appendix maps displaydata and displayblock material into
structured comments. This can easily be extended/changed to cover the handling
of material in other namespaces. But do we want to formalize the structured
comment convention?

Finally, there's the issue of how to handle other comments, which we've
discussed in the past but may be worth revisiting now. Currently regular Sieve
comments are mapped to <comment></comment> blocks rather than to proper XML
comments. The reason for this is that not all XML processors provide access to
stuff inside of <!-- foo --> constructs, so comments may get lost when
converting from Sieve-in-XML back to regular Sieve. Do we want to continue
to do things this way?

In any case, here's a concrete proposal for how to move forward:

(1) Add the necessary stuff to allow use of XML in other namespaces
    whereever displaydata is currently allowed.

(2) Drop displaydata, making the use of namespaces required if you want
    to embed other stuff inside of a Sieve-in-XML.

(3) Add a section defining the structured comment convention for
    representing this other stuff in regular Sieve format.

(4) Change displayblock to just block, making it clear it can be used for
    other sorts of groupings.

(5) Leave the current mapping of unstructured Sieve comments to
    <comment></comment> blocks alone.

Comments?

				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 n0C2a2is077889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2009 19:36:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0C2a2VQ077888; Sun, 11 Jan 2009 19:36:02 -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 n0C2a1DT077882 for <[e-mail]>; Sun, 11 Jan 2009 19:36:01 -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]; Sun, 11 Jan 2009 18:35:59 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 11 Jan 2009 18:35:56 -0800 (PST)
Date: Sun, 11 Jan 2009 18:30:28 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
In-reply-to: "Your message dated Sun, 11 Jan 2009 22:05:18 +0000" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

> so, just to ensure i understand this issue - you've decided to support
> namespaces fully and drop support for namespace unaware parsers?

> (FWIW this is fine by me)

Nope. I've decided not to specify any sort of "standard namespace prefix"
in the document. That's all.

I have no idea what you mean by "support namespaces fully". But given the tone
of your most recent responses I'm no longer willing to spend time in a
give-and-take trying to figure what you mean by 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 n0C2EuU9077182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2009 19:14:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0C2Euwj077181; Sun, 11 Jan 2009 19:14:56 -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 n0C2EjZ9077171 for <[e-mail]>; Sun, 11 Jan 2009 19:14:55 -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]; Sun, 11 Jan 2009 18:14:43 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 11 Jan 2009 18:14:40 -0800 (PST)
Date: Sun, 11 Jan 2009 18:05:01 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
In-reply-to: "Your message dated Sun, 11 Jan 2009 22:01:34 +0000" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

> On Sun, Jan 11, 2009 at 6:21 PM, Ned Freed <[e-mail]> wrote:

> <snip>

> >> > But really, this entire discussion has gone very far afield. Like it or not,
> >> > Sieve is intended to be a language used to process email messages at or around
> >> > the time of final delivery.
> >> > The fact that it can be adapted for other uses may
> >> > be interesting to you but simply is not relevant in the context of the work
> >> > this group is chartered to do.
> >
> >> is this http://www.ietf.org/html.charters/sieve-charter.html the charter?
> >
> > Yes

> could anyone kindly point me to the sections which indicate that only
> mail servers of a particular class of architecture are in scope?

I've already done so in previous messages. It's the very first thing RFC 5228,
the Sieve base specification, says:

   This document describes a language for filtering email messages at
   time of final delivery.

Final delivery is a formal term used in many IETF email standards. It refers to
the point at which the message exists the SMTP transport infrastructure and
enters the message store.

As its charter makes clear, the current Sieve group is chartered to work on a
very specific set of Sieve extensions. There is nothing in there about
revisiting the scope of applicability of Sieve.

				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 n0C26B28076718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2009 19:06:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0C26BQU076717; Sun, 11 Jan 2009 19:06:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0C260Uk076707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sun, 11 Jan 2009 19:06:10 -0700 (MST) (envelope-from [e-mail])
Received: from fife.sendmail.com (fife.sendmail.com [209.246.26.50]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id n0C28rII014989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 11 Jan 2009 18:08:53 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1231726133; bh=QNLpUvl6f9UE3W94WMQaSxUzPM7fIoSoJVrO BouyqOU=; h=Received:X-DKIM:DKIM-Signature:Date:From:X-X-Sender:To: cc:Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type:X-MM-Ex-RefId; b=CgBxYZBXzH/BAVsxACAGH1a m7XrEcPxTe9ulznDjyWN0tBS7Jnkx3MQzH/g0HMs8vATWUQTOMrBqY2uPHL0oRP3ZLV u05i9vI9S48A6kIWJHFIv3LWC/c+YzvCjGaP/U4dsVtLH2ST+ZLUfxoJMsU8W/vxYOm Jfsfiw3Fnh4ljQ=
Received: from [10.210.202.20] ([10.210.202.20]) (authenticated bits=0) by fife.sendmail.com (Switch-3.3.3mp/Switch-3.3.2mp) with ESMTP id n0C25wtq019738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2009 18:05:58 -0800
X-DKIM: Sendmail DKIM Filter v2.5.6 fife.sendmail.com n0C25wtq019738
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=fife.dkim; t=1231725959; bh=QNLpUvl6f9UE3W94WMQaSxUzPM7fIoSoJVrOB ouyqOU=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID: References:MIME-Version:Content-Type; b=H2GkE0qRie6/jxL+L7BHQ7gXOf NDqEAO36Xt6OZvcAFqhGlagX8eFt0KFRtwCDLcujgzQ3xDbPFq5pv7DRb1T1Zz37pBQ UwdU3dQXdB1eAfH1rSBei39Nbt6wDY64tOaxHDHTu3MLW+tVjmNHBg8AfeZ46aXNkQv vVS1Ei1wX3g=
Date: Sun, 11 Jan 2009 18:05:55 -0800
From: Philip Guenther <[e-mail]>
X-X-Sender: [e-mail]
To: Robert Burrell Donkin <[e-mail]>
cc: Ned Freed <[e-mail]>, [e-mail]
Subject: Re: draft-freed-sieve-in-xml status?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>  <[e-mail]>  <[e-mail]>  <[e-mail]>  <[e-mail]>  <[e-mail]>  <[e-mail]> <[e-mail]>  <[e-mail]>  <[e-mail]> <[e-mail]>
User-Agent: Alpine 2.00 (BSO 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MM-Ex-RefId: 149371::090111180558-11670B90-004A4D08/0-0/99-17
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>

On Sat, 10 Jan 2009, Robert Burrell Donkin wrote:
...
> we're currently adding xml serialisation for jsieve over at apache. 
> there are number of concrete use cases that this serialisation needs to 
> satisfy.

This entire discussion might have been less painful if the concrete use 
cases the jsieve developers have had been brought up at the beginning.  
The discussion that has progressed has been almost completely abstract; 
the one time someone actually said "for example, such-and-such doesn't 
work" the subthread seemed to resolve itself almost directly.  As is, the 
"does it support namespaces" thread is completely confused in my mind 
because I have been unable to determine what you consider necessary and 
sufficient, Robert.

(Fortunately, I'm just a bystander on this doc, so I'm not sweating my 
failure here.)


Philip Guenther



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 n0BM5NXR068526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2009 15:05:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0BM5NvQ068525; Sun, 11 Jan 2009 15:05:23 -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-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0BM5K5Y068518 for <[e-mail]>; Sun, 11 Jan 2009 15:05:21 -0700 (MST) (envelope-from [e-mail])
Received: by bwz5 with SMTP id 5so20576514bwz.10 for <[e-mail]>; Sun, 11 Jan 2009 14:05:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Vwb30xxvFsFubnibO733HGE7GfH+oNMl6CgRHSqln+A=; b=ptEjwprMpOkLvnp2fgc4U+vaXzR9G+hHfyd38kPSgP0HKK+LdcTLSjkfuKn7gboLrI 94sPxgNQMKxi9XRje1ZalSuGgYzDmHm/Pqz+SgRt3HTj+Sva4uWo806M+iltDAWhSnbO U36cTqRhrZhuMj2mgGwTCcLGEjtrJqEJX+88I=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=jf16azr0VjGsOscBxKwAH1lepO4aoKkSTZtF0w/AdiAohAx4V/T8rLf1lKHbxab5OT ISqm0x85oLSuzbo6CtpEYPaEkhl+VYoJ3e27PrQegJbOVn1mDyyPu96UOJhEFfB2PyvT bGF8rXkr6/nXeap8yO1+rjh9lkEa+faiG9Z64=
Received: by 10.181.146.11 with SMTP id y11mr10717190bkn.5.1231711518705; Sun, 11 Jan 2009 14:05:18 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Sun, 11 Jan 2009 14:05:18 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sun, 11 Jan 2009 22:05:18 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

On Sun, Jan 11, 2009 at 6:21 PM, Ned Freed <[e-mail]> wrote:
>> > AFAIK the specific namespace prefix that gets bound to the namespace name is
>> > not something that can or should be standardized. Rather, it is declared on a
>> > per-document basis using an xmlns attribute. Any agent out there that supports
>> > namespaces should support the use of xmlns to pick whatever prefix a given
>> > document binds to the urn:ietf:params:xml:sieve namespace.
>
>> this choice of namespace prefix is the root cause of incompatibility
>> between namespace aware and unaware parsers
>
>> for example, 'sieve:abc' is just a name to unaware parsers while aware
>> parsers understand this as a namespace prefix and a local part. the
>> namespace prefix is resolved to a URI and that is used as the basis of
>> comparison. specifing a standard prefix (for example, sieve) ensures
>> that in both cases equality works as expected.
>
> This is finally something I can understand as a rationale for wanting
> to define a standard namespace prefix.
>
> This doesn't appear to be specific to Sieve-in-XML either - if this makes sense
> it should be something we're doing in similar XML specifications. So the first
> thing I did was check out a bunch of other RFCs - not an exhaustive search but
> I did check a dozen or so - to see if this has been done and if so, how. But
> AFAICT this has not been done elsewhere. The closest thing to it are statements
> of the general form "this document uses the prefix foo to identify the bar
> namespace throughout". This falls far short of a "MUST use foo: as the
> namespace prefix" or even a SHOULD. In fact some RFCs go out of their way to
> make it clear the use of a particular prefix is NOT being standardized.
>
> For example, RFC 5023 (ATOM) has this to say:
>
>  This specification uses the prefix "app:" for the namespace name. The prefix
>  "atom:" is used for "http://www.w3.org/2005/Atom", the namespace name of the
>  Atom Syndication Format [RFC4287]. These namespace prefixes are not
>  semantically significant.
>
> Note that last sentence and the lack of any compliance language.
>
> In other words, this is apparently not current practice for IETF use of XML.
> But should it be? I decided the answer to this general question is a little
> above my pay grade. Fortunately, the IETF has this thing called the XML
> directorate, where people with XML issues can reach out to folks with real
> expertise.
>
> I sent a query to the directorate yesterday, which included your statement
> verbatim, and received two responses almost immediately, from Tim Bray and Lisa
> Dusseault. (Tim you probably know - he's one of the coauthors of the XML
> namespace specification, among other stuff. And Lisa is the area director
> responsible for this WG.) I've asked for permission to resend their responses
> to the Sieve WG, but in the meantime what I can say is that both were opposed
> to doing this on the grounds that prefixes cannot be tied down this way because
> of the potential for conflicts.
>
> Given the apparently lack of stated support from others in the group and the
> lack of support for this from the directorate, I now regard this issue
> as closed.

so, just to ensure i understand this issue - you've decided to support
namespaces fully and drop support for namespace unaware parsers?

(FWIW this is fine by me)

- 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 n0BM1bGx068427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2009 15:01:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0BM1bC2068426; Sun, 11 Jan 2009 15:01:37 -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-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0BM1atE068418 for <[e-mail]>; Sun, 11 Jan 2009 15:01:36 -0700 (MST) (envelope-from [e-mail])
Received: by bwz5 with SMTP id 5so20573905bwz.10 for <[e-mail]>; Sun, 11 Jan 2009 14:01:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=s9RLg8UriIqhfmsqLMam1pqjlagAhrEZxdNXLBNqKp0=; b=oV/HAYCvA3POkgANz/hb2SJaENwg9h8whTK+6FzKBYJeNKAHHBYYsZ8tp4NLgDT8iZ /VJyQ51P0were8+dtwEax7i3lpGWA7/hK9sURS2swvOjDPwfEeEAqC+mevDq9vNxlFUt 5ub2FTJ4f+dyJa1y1IKVGGNmz/L3Fswy1HqHs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=bHFYb8VWWPMNEs6FVswiyfnz1DPi1rVjEK1moDAQT6jwi9xBUD0IQbO7Rnn9mn3zgO POy97HH9INwdL5BI+FzE80hwL46zby+dgbINPIj4+W3GirbOD9VI5ouvbpA7vPkXntAh woJUdt8OpD6Cgh1N55rVm1G3r7PCratbnLhfs=
Received: by 10.180.213.14 with SMTP id l14mr10708217bkg.107.1231711294912; Sun, 11 Jan 2009 14:01:34 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Sun, 11 Jan 2009 14:01:34 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sun, 11 Jan 2009 22:01:34 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

On Sun, Jan 11, 2009 at 6:21 PM, Ned Freed <[e-mail]> wrote:

<snip>

>> > But really, this entire discussion has gone very far afield. Like it or not,
>> > Sieve is intended to be a language used to process email messages at or around
>> > the time of final delivery.
>> > The fact that it can be adapted for other uses may
>> > be interesting to you but simply is not relevant in the context of the work
>> > this group is chartered to do.
>
>> is this http://www.ietf.org/html.charters/sieve-charter.html the charter?
>
> Yes

could anyone kindly point me to the sections which indicate that only
mail servers of a particular class of architecture are in scope?

- 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 n0BLw5Lf068311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2009 14:58:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0BLw5xN068310; Sun, 11 Jan 2009 14:58:05 -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-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0BLvqML068301 for <[e-mail]>; Sun, 11 Jan 2009 14:58:03 -0700 (MST) (envelope-from [e-mail])
Received: by bwz5 with SMTP id 5so20570899bwz.10 for <[e-mail]>; Sun, 11 Jan 2009 13:57:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=dirx6j02/h+9Cw+fznvucmyzq0uor7+JEkf/hnRjrvE=; b=xeSCg22e1z60gVzbjEh2LF7pEfmU2VqpWcYxpwTKpheJpfuCRoOadfq8wE02H3RA2t BiJgmfRFA8/9LUxG7DnrEHw+zuGOsiLUvPJz3wO5s2tqIvG66stETC6AyU3SJMpa1k4H zW/m6daOjuC92ABtBQhSsWFG/OioqelVVTOBY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=HDghvda4if9OL593oQWYfQLap3LkMOyiJItp+lX3ybTNfLJBYpbqGqkkVtA8AFhskD sb7sP2fLGI6/4Bwp9i2qxFNVQZ0k6MlldG9ho7NF8TKTy8l+U+/+3n9FIcrFM5D3K/I8 LQ/CmtQ+7Ax2S96BMIJwtIInq7gcM7wgtCEzQ=
Received: by 10.180.244.19 with SMTP id r19mr9749059bkh.9.1231711071294; Sun, 11 Jan 2009 13:57:51 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Sun, 11 Jan 2009 13:57:51 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sun, 11 Jan 2009 21:57:51 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

On Sun, Jan 11, 2009 at 6:21 PM, Ned Freed <[e-mail]> wrote:

<snip>

>> >> for the class of application (enterprise mail servers is a name that's
>> >> sometimes used but quite possibly that's not familiar to others in the
>> >> group), unfortunately it is
>> >
>> > Robert, developing enterprise and ISP class mail servers is what I do for a
>> > living. I've been doing it for over 20 years now. So I think this is something
>> > I might know just a little bit about.
>
>> i am not unaware of your background but i fail to see why i should
>> respect your arguments when you are so clearly uninformed about a
>> class of mail server which are almost a decade old now
>
> And by the same token, why should I respect any of your arguments when you
> clearly have minimal knoeledge of overall email architecture, Sieve semanticss,
> or IETF processes?

ad hominem are widely acknowledged to be the best way to win
discussions on the internet and play a vital role in the creation of
high standard specifications

i think i understand why the IEFT is now held in such low regard by
most modern developers and why i was warned against participating in
this group

- 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 n0BLHKSS067101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2009 14:17:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0BLHKIp067100; Sun, 11 Jan 2009 14:17:20 -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 n0BLH9WI067087 for <[e-mail]>; Sun, 11 Jan 2009 14:17:19 -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]; Sun, 11 Jan 2009 13:17:06 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 11 Jan 2009 13:17:00 -0800 (PST)
Date: Sun, 11 Jan 2009 10:21:25 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
In-reply-to: "Your message dated Sat, 10 Jan 2009 18:20:48 +0000" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

> > AFAIK the specific namespace prefix that gets bound to the namespace name is
> > not something that can or should be standardized. Rather, it is declared on a
> > per-document basis using an xmlns attribute. Any agent out there that supports
> > namespaces should support the use of xmlns to pick whatever prefix a given
> > document binds to the urn:ietf:params:xml:sieve namespace.

> this choice of namespace prefix is the root cause of incompatibility
> between namespace aware and unaware parsers

> for example, 'sieve:abc' is just a name to unaware parsers while aware
> parsers understand this as a namespace prefix and a local part. the
> namespace prefix is resolved to a URI and that is used as the basis of
> comparison. specifing a standard prefix (for example, sieve) ensures
> that in both cases equality works as expected.

This is finally something I can understand as a rationale for wanting
to define a standard namespace prefix.

This doesn't appear to be specific to Sieve-in-XML either - if this makes sense
it should be something we're doing in similar XML specifications. So the first
thing I did was check out a bunch of other RFCs - not an exhaustive search but
I did check a dozen or so - to see if this has been done and if so, how. But
AFAICT this has not been done elsewhere. The closest thing to it are statements
of the general form "this document uses the prefix foo to identify the bar
namespace throughout". This falls far short of a "MUST use foo: as the
namespace prefix" or even a SHOULD. In fact some RFCs go out of their way to
make it clear the use of a particular prefix is NOT being standardized.

For example, RFC 5023 (ATOM) has this to say:

 This specification uses the prefix "app:" for the namespace name. The prefix
 "atom:" is used for "http://www.w3.org/2005/Atom", the namespace name of the
 Atom Syndication Format [RFC4287]. These namespace prefixes are not
 semantically significant.

Note that last sentence and the lack of any compliance language.

In other words, this is apparently not current practice for IETF use of XML.
But should it be? I decided the answer to this general question is a little
above my pay grade. Fortunately, the IETF has this thing called the XML
directorate, where people with XML issues can reach out to folks with real
expertise.

I sent a query to the directorate yesterday, which included your statement
verbatim, and received two responses almost immediately, from Tim Bray and Lisa
Dusseault. (Tim you probably know - he's one of the coauthors of the XML
namespace specification, among other stuff. And Lisa is the area director
responsible for this WG.) I've asked for permission to resend their responses
to the Sieve WG, but in the meantime what I can say is that both were opposed
to doing this on the grounds that prefixes cannot be tied down this way because
of the potential for conflicts.

Given the apparently lack of stated support from others in the group and the
lack of support for this from the directorate, I now regard this issue
as closed.

> >> for the class of application (enterprise mail servers is a name that's
> >> sometimes used but quite possibly that's not familiar to others in the
> >> group), unfortunately it is
> >
> > Robert, developing enterprise and ISP class mail servers is what I do for a
> > living. I've been doing it for over 20 years now. So I think this is something
> > I might know just a little bit about.

> i am not unaware of your background but i fail to see why i should
> respect your arguments when you are so clearly uninformed about a
> class of mail server which are almost a decade old now

And by the same token, why should I respect any of your arguments when you
clearly have minimal knoeledge of overall email architecture, Sieve semanticss,
or IETF processes?

> > But really, this entire discussion has gone very far afield. Like it or not,
> > Sieve is intended to be a language used to process email messages at or around
> > the time of final delivery.
> > The fact that it can be adapted for other uses may
> > be interesting to you but simply is not relevant in the context of the work
> > this group is chartered to do.

> is this http://www.ietf.org/html.charters/sieve-charter.html the charter?

Yes.

				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 n0BLE2ci066955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2009 14:14:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0BLE2KJ066954; Sun, 11 Jan 2009 14:14:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0BLDn0K066939 for <[e-mail]>; Sun, 11 Jan 2009 14:14:01 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 692BD4AC5A; Sun, 11 Jan 2009 22:13:47 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1231708426-75452-1/6/21 (4 recipients); Sun, 11 Jan 2009 22:13:46 +0100
Message-Id: <[e-mail]>
Date: Sun, 11 Jan 2009 22:13:57 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: draft-freed-sieve-in-xml status?
Cc: Robert Burrell Donkin <[e-mail]>, Ned Freed <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <PCbmC+s//[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
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>

Ned Freed writes:
> So I guess the question for the group here is what extensibility model 
> do we really want here? Do we want to require enclosure of material 
> from other XML sources in displaydata blocks, or do we want to allow 
> other stuff to appear without such blocks as long as it's in another 
> namespace?

Using displaydata for that purpose sounds like a hack, or do I 
misunderstand? "Displaydata" doesn't sound like a natural name for 
importing data from another schema.

The uses cases I've thought of involve sieve stuff embedded in a greater 
context, not other stuff included in the sieve blah. So I don't care 
very much about how importing things into sieve... but if that is to be 
allowed, allowing it properly is better than hackily.

Arnt



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 n0BJ2sQ3061131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2009 12:02:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0BJ2sRU061130; Sun, 11 Jan 2009 12:02:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0BJ2hJh061120 for <[e-mail]>; Sun, 11 Jan 2009 12:02:53 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.33] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 0176540FF; Sun, 11 Jan 2009 11:04:21 -0800 (PST)
Subject: Re: draft-freed-sieve-in-xml status?
From: Aaron Stone <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: Robert Burrell Donkin <[e-mail]>, Arnt Gulbrandsen <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <PCbmC+s//[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Sun, 11 Jan 2009 10:57:43 -0800
Message-Id: <1231700263.16458.102.camel@turtle>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.2 
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>

On Sun, 2009-01-11 at 07:48 -0800, Ned Freed wrote:
> > no, not at all
> 
> > i'll explain at more length what i meant
> 
> > the draft does not allow xml from other namespaces within sieve
> > fragments. for example (assuming sieve is the default namespace and
> > mix is some other namespace), the following is excluded by the current
> > draft schema:
> 
> >      <control name="if">
> >        <mix:editor-specific foo='bar'></mix:editor-specific>
> >        <test name="header">
> >          <tag>is</tag>
> >          <str>Sender</str>
> >          <str>[e-mail]</str>
> >        </test>
> >        <action name="fileinto">
> >          <str>filter</str>
> >        </action> <comment>move to "filter" mailbox</comment>
> >      </control>
> 
> > does my comment make sense now?
> 
> Nope. First of all, it simply isn't true: The <displaydata> element is defined
> as an xsd:any without a namespace attribute (which defaults to ##any, meaning
> any namespace is allowed) and with a processContents attribute set to skip,
> meaning no schema is required for anything inside. So your example can be
> written:
> 
>       <control name="if">
>         <displaydata>
>           <mix:editor-specific foo='bar'></mix:editor-specific>
>         </displaydata>
>         <test name="header">
>           <tag>is</tag>
>           <str>Sender</str>
>           <str>[e-mail]</str>
>         </test>
>         <action name="fileinto">
>           <str>filter</str>
>         </action> <comment>move to "filter" mailbox</comment>
>       </control>
> 
> and be schema-valid. (Actually, I cheated a little here - the schema in the
> current draft has a bug where it is missing displaydata and displayblock in the
> first choice in the command type definition. This has to be fixed for the
> above to validate. But this has nothing to do with the use or non-use
> of other namespaces.)
> 
> Now, perhaps your objection is that you have to use displaydata containers in
> order to embed material from other namespaces and you don't want to have to do
> that. If so, that's easily remedied by adding some
> 
>           <xsd:any namespace="##other" processContents="lax"/>
> 
> directives. The equivalent in Relax is something like:
> 
>    any = element * { mixed { ( any | attribute * { text } )* } }
>    extelements = element * - ( local:* | sieve:* ) { any }*
>    extattributes = attribute * - ( local:* | sieve:* ) { text }*
>    extnodes = ( extattributes extelements)
> 
> So I guess the question for the group here is what extensibility model do we
> really want here? Do we want to require enclosure of material from other XML
> sources in displaydata blocks, or do we want to allow other stuff to appear
> without such blocks as long as it's in another namespace?

I plead ignorance to the finer details of the XML Schema stuff described
above, but off the cuff, not requiring displaydata seems cleaner to me.

Is the reason for the displaydata tag to tell an otherwise ignorant
Sieve-XML-only program that the contents of the displaydata should be
handled as verbatim data?

Aaron



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 n0BIIa1B059307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2009 11:18:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0BIIaTY059306; Sun, 11 Jan 2009 11:18:36 -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 n0BIIOrR059289 for <[e-mail]>; Sun, 11 Jan 2009 11:18:35 -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]; Sun, 11 Jan 2009 10:18:08 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 11 Jan 2009 10:18:05 -0800 (PST)
Date: Sun, 11 Jan 2009 07:48:27 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
In-reply-to: "Your message dated Sun, 11 Jan 2009 10:13:33 +0000" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: Ned Freed <[e-mail]>, Arnt Gulbrandsen <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <PCbmC+s//[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

> no, not at all

> i'll explain at more length what i meant

> the draft does not allow xml from other namespaces within sieve
> fragments. for example (assuming sieve is the default namespace and
> mix is some other namespace), the following is excluded by the current
> draft schema:

>      <control name="if">
>        <mix:editor-specific foo='bar'></mix:editor-specific>
>        <test name="header">
>          <tag>is</tag>
>          <str>Sender</str>
>          <str>[e-mail]</str>
>        </test>
>        <action name="fileinto">
>          <str>filter</str>
>        </action> <comment>move to "filter" mailbox</comment>
>      </control>

> does my comment make sense now?

Nope. First of all, it simply isn't true: The <displaydata> element is defined
as an xsd:any without a namespace attribute (which defaults to ##any, meaning
any namespace is allowed) and with a processContents attribute set to skip,
meaning no schema is required for anything inside. So your example can be
written:

      <control name="if">
        <displaydata>
          <mix:editor-specific foo='bar'></mix:editor-specific>
        </displaydata>
        <test name="header">
          <tag>is</tag>
          <str>Sender</str>
          <str>[e-mail]</str>
        </test>
        <action name="fileinto">
          <str>filter</str>
        </action> <comment>move to "filter" mailbox</comment>
      </control>

and be schema-valid. (Actually, I cheated a little here - the schema in the
current draft has a bug where it is missing displaydata and displayblock in the
first choice in the command type definition. This has to be fixed for the
above to validate. But this has nothing to do with the use or non-use
of other namespaces.)

Now, perhaps your objection is that you have to use displaydata containers in
order to embed material from other namespaces and you don't want to have to do
that. If so, that's easily remedied by adding some

          <xsd:any namespace="##other" processContents="lax"/>

directives. The equivalent in Relax is something like:

   any = element * { mixed { ( any | attribute * { text } )* } }
   extelements = element * - ( local:* | sieve:* ) { any }*
   extattributes = attribute * - ( local:* | sieve:* ) { text }*
   extnodes = ( extattributes extelements)

So I guess the question for the group here is what extensibility model do we
really want here? Do we want to require enclosure of material from other XML
sources in displaydata blocks, or do we want to allow other stuff to appear
without such blocks as long as it's in another namespace?

				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 n0BADkCu036441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2009 03:13:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0BADkkD036440; Sun, 11 Jan 2009 03:13:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.240]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0BADYRB036415 for <[e-mail]>; Sun, 11 Jan 2009 03:13:45 -0700 (MST) (envelope-from [e-mail])
Received: by rv-out-0708.google.com with SMTP id c5so11571702rvf.34 for <[e-mail]>; Sun, 11 Jan 2009 02:13:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ewP0sb0uCjoBhX+KJ+u3/qVaA+ax4ibtRtBFMg1+Awk=; b=PEQECPLYxGwLqze3OBO5z7OJGtUQY3ZeoOlDw2uSi6rM6SBlDTgwLBXB2WPCdplCR+ A/8QozgadFOX0COyOwApivYqzW6z4ppP6p0ToIqO0LrmN/QHT1jXEtg7aim10URqbU+z mhnucOC9amghmGDaC1KttUonjhBfTOgPYO+YA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=k91cyjgxd63oj2vcGs+zotj1tafxhXIMmJ8ChxTDxSNAnUi79Qp7Rbzyy/YvdMv4z2 nYRlaW9dila/DmH7GF08DnCDtkM3bAFyupDn5cg8r5eOZfnrwiU/QilCUjmvqXn6s7yh 9Hhc1Y1PqIksS0p4VKamMqX1qghrMK1I2nITE=
Received: by 10.114.60.19 with SMTP id i19mr18208977waa.62.1231668814030; Sun, 11 Jan 2009 02:13:34 -0800 (PST)
Received: by 10.114.126.11 with HTTP; Sun, 11 Jan 2009 02:13:33 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sun, 11 Jan 2009 10:13:33 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: "Arnt Gulbrandsen" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <PCbmC+s//[e-mail]> <[e-mail]> <[e-mail]> <[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>

On Sun, Jan 11, 2009 at 1:18 AM, Ned Freed <[e-mail]> wrote:
>
>> On Wed, Jan 7, 2009 at 7:38 PM, Ned Freed <[e-mail]> wrote:
>> >
>> >
>> >> Alexey Melnikov writes:
>> >> > If we want to allow for magic comments, it make sense for them to be
>> >> > in a separate namespace. But then magic comments are typically
>> >> > implementation specific. So I unless we want to startadize them, I
>> >> > don't think the document needs another namespace.
>> >
>> >> Each generator may want to use a namespace of its own for its particular
>> >> foo. I am not an expert in this. If that's considered good XML taste,
>> >> then that should be illustrated in an example or two.
>> >
>> > I certainly want to allow that - indeed, I don't know of a way to disallow
>> > it.
>> > But I don't want to require this approach.
>
>> AFACT the current draft does not allow mixing of namespaces
>
> Say what? All the current draft does is define a way to represent Sieve scripts
> in XML. Nowhere does it specify how the resulting representation is to be used.
> It could be used as a standalone thing where a given XML object only contains
> Sieve content and nothing else. Or it could be used to embed Sieve material
> inside of some more general sort of XML content (of course using namespaces to
> keep things clear) - which in fact is exactly one of the ways we're using it.
>
> You appear to be confusing this specification with others the IETF has done
> that use XML as part of defining a protocol, e.g., XMPP. In such cases where
> the goal is specifically for clients and servers written by different people to
> be able to interoperate and that means there have to be tight constraints on
> what can appear on the wire.

no, not at all

i'll explain at more length what i meant

the draft does not allow xml from other namespaces within sieve
fragments. for example (assuming sieve is the default namespace and
mix is some other namespace), the following is excluded by the current
draft schema:

     <control name="if">
       <mix:editor-specific foo='bar'></mix:editor-specific>
       <test name="header">
         <tag>is</tag>
         <str>Sender</str>
         <str>[e-mail]</str>
       </test>
       <action name="fileinto">
         <str>filter</str>
       </action> <comment>move to "filter" mailbox</comment>
     </control>

does my comment make sense now?

- 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 n0B2TOr9015952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Jan 2009 19:29:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0B2TOqW015951; Sat, 10 Jan 2009 19:29:24 -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 n0B2TB4d015937 for <[e-mail]>; Sat, 10 Jan 2009 19:29:22 -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]; Sat, 10 Jan 2009 18:29:08 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sat, 10 Jan 2009 18:29:03 -0800 (PST)
Date: Sat, 10 Jan 2009 17:18:40 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
In-reply-to: "Your message dated Sat, 10 Jan 2009 18:03:03 +0000" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: Ned Freed <[e-mail]>, Arnt Gulbrandsen <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <PCbmC+s//[e-mail]> <[e-mail]> <[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>

> On Wed, Jan 7, 2009 at 7:38 PM, Ned Freed <[e-mail]> wrote:
> >
> >
> >> Alexey Melnikov writes:
> >> > If we want to allow for magic comments, it make sense for them to be
> >> > in a separate namespace. But then magic comments are typically
> >> > implementation specific. So I unless we want to startadize them, I
> >> > don't think the document needs another namespace.
> >
> >> Each generator may want to use a namespace of its own for its particular
> >> foo. I am not an expert in this. If that's considered good XML taste,
> >> then that should be illustrated in an example or two.
> >
> > I certainly want to allow that - indeed, I don't know of a way to disallow
> > it.
> > But I don't want to require this approach.

> AFACT the current draft does not allow mixing of namespaces

Say what? All the current draft does is define a way to represent Sieve scripts
in XML. Nowhere does it specify how the resulting representation is to be used.
It could be used as a standalone thing where a given XML object only contains
Sieve content and nothing else. Or it could be used to embed Sieve material
inside of some more general sort of XML content (of course using namespaces to
keep things clear) - which in fact is exactly one of the ways we're using it.

You appear to be confusing this specification with others the IETF has done
that use XML as part of defining a protocol, e.g., XMPP. In such cases where
the goal is specifically for clients and servers written by different people to
be able to interoperate and that means there have to be tight constraints on
what can appear on the wire.

Sieve-in-XML is not a protocol or service. It is at most a tool someone can use
in building a protocol or service that needs to operate on Sieve content.
Exactly how it would be used to, say, have a Javascript-based Sieve editor
fetch and return Sieve content from a central server would require considerable
elaboration beyond what's already there. (This would be true even if XML were
not involved - I would expect in many cases for applications to require certain
Sieve extensions be supported and possibly be unable to deal with some others.)

Here's a concrete example of how this might play out. Suppose we decide to
define an extension to the managesieve protocol to allow clients to fetch and
store sieves using the XML representaation. In addition to the usual rigamarole
of having to specify the extension name, new commands or arguments, and so on,
such an extension would have to specify exactly what sort of XML would be used.
Are namespaces  allowed? Required? Can other content be included in the XML or
is it forbidden? 

I actually toyed with the idea of including a managesieve extension in this
specification for fetching and returning XML. I eventually decided against it
because I was concerned that we might run into the problems that have plagued
similar specifications in the past, most notably the abortive attempt to define
XCal, an XML representation of iCal. To the extent such specificastions look
like they are attempting to replace an original format with an XML-based one,
there has been opposition from people who are not, shall we say, believers in
the XML religion. This is also the reason I avoided coining any sort of cute
name for this like XSieve.

				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 n0AIKxOj098897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Jan 2009 11:20:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0AIKxXX098896; Sat, 10 Jan 2009 11:20:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0AIKm4g098851 for <[e-mail]>; Sat, 10 Jan 2009 11:20:58 -0700 (MST) (envelope-from [e-mail])
Received: by wa-out-1112.google.com with SMTP id j32so5718146waf.26 for <[e-mail]>; Sat, 10 Jan 2009 10:20:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=dnh/kVnWs6GoAmD2xvbQ4x1u3bB39BcYcKaOLjMbtL0=; b=wegRCU3fzGxfH16OnFXZwroCNJXW9IlWqQww9jyecJ3638pqvNk+YbJabJxUrhNJGU qGGU/ZdXKYp47+dU1q3yX5SbKXZxj0NNMj7e8jgYaggyfUBlfh3Ptn/BJHm2/Dfat6na mlaBx3KsspbHrcfLDXzTeZkXjS1J/2nPGLeCc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=wQIxPwCNh6dPmh63pFLcVDq+IDPfsgi7BVTw4Po2v80EenJtC8rp00zi5r/IFMspT0 t9JimoCzoNeq6na4HSJ/6DxINO8JMlWOSJsuRcmD09K87h6RGmnw1WWST/oh2fQMs8vX 9gO+oNeCo9hi37fqAvZR3sTRKgLRVEaQBrwxY=
Received: by 10.114.59.1 with SMTP id h1mr16054320waa.87.1231611648143; Sat, 10 Jan 2009 10:20:48 -0800 (PST)
Received: by 10.114.126.11 with HTTP; Sat, 10 Jan 2009 10:20:48 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sat, 10 Jan 2009 18:20:48 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

On Thu, Jan 8, 2009 at 4:27 PM, Ned Freed <[e-mail]> wrote:
>> > > however (in my experience) the generative tools commonly used for XML
>> > > and web service binding, and editor generation tend not to offer good
>> > > relax support. IMO the draft should offer secondary informative XML
>> > > Schema or Schemata to assist developers using these tools.
>
>> > The problem is that the unique particle attribution limitation in XML Schema
>> > effectively precludes using it without some compromises. I am therefore opposed
>> > to continuing to include it.
>
>> adopting a standard prefix - sieve, say - is all that is required
>
> To get around the unique particle attribution restriction that prevents XML
> Schema from describing many legitimate schemata? If that's truly the case a lot
> of XML developers would love to hear more.
>
>> is this really too much to ask?
>
> I fail to see what defining a prefix has to do with the use or non-use of XML
> Schema, but for about the tenth time, I have already added a namespace name
> registration to the specification.
>
> AFAIK the specific namespace prefix that gets bound to the namespace name is
> not something that can or should be standardized. Rather, it is declared on a
> per-document basis using an xmlns attribute. Any agent out there that supports
> namespaces should support the use of xmlns to pick whatever prefix a given
> document binds to the urn:ietf:params:xml:sieve namespace.

this choice of namespace prefix is the root cause of incompatibility
between namespace aware and unaware parsers

for example, 'sieve:abc' is just a name to unaware parsers while aware
parsers understand this as a namespace prefix and a local part. the
namespace prefix is resolved to a URI and that is used as the basis of
comparison. specifing a standard prefix (for example, sieve) ensures
that in both cases equality works as expected.

<snip>

>> for the class of application (enterprise mail servers is a name that's
>> sometimes used but quite possibly that's not familiar to others in the
>> group), unfortunately it is
>
> Robert, developing enterprise and ISP class mail servers is what I do for a
> living. I've been doing it for over 20 years now. So I think this is something
> I might know just a little bit about.

i am not unaware of your background but i fail to see why i should
respect your arguments when you are so clearly uninformed about a
class of mail server which are almost a decade old now

> But really, this entire discussion has gone very far afield. Like it or not,
> Sieve is intended to be a language used to process email messages at or around
> the time of final delivery.
> The fact that it can be adapted for other uses may
> be interesting to you but simply is not relevant in the context of the work
> this group is chartered to do.

is this http://www.ietf.org/html.charters/sieve-charter.html the charter?

- 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 n0AI3Emw098039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Jan 2009 11:03:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0AI3EG8098038; Sat, 10 Jan 2009 11:03:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.242]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0AI33aa098030 for <[e-mail]>; Sat, 10 Jan 2009 11:03:14 -0700 (MST) (envelope-from [e-mail])
Received: by rv-out-0708.google.com with SMTP id c5so11214232rvf.34 for <[e-mail]>; Sat, 10 Jan 2009 10:03:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ha1xH+KM9Ln23pIw8SRZb8HAUUaEAX4SC5UPhY1tWcA=; b=NrB9mpR5E5/o9SzSf4hR/5tE7uLMHB2oe6y62gTotqoAPvJbM6jQfkF/45Llzcfkos 55fnHsz50AqilmCpv3fl6cHYTIfIepsrfotqMbXpMwBrJw1yAj8wvRnNV1KK9USH1gc5 FzAtosUURC6K0do5fVhiKWvgQ2b6A+pSjJuL4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=jQ/g9LcSoaFZ8idGXqosMZrv1Og48d5GPLm2VYNsOdfZqzhtyKfa4rpwb3isbfxMdN 0c2JlhGBSDfBHBexHF+33Hbk4LZJJeHzEfQQyHpEjkcW+8K8F5H2yoxnNjs0LaOyyvbi BYk1khUAH7arXibb5zjZQjeLejsEhgsNdJxfE=
Received: by 10.114.211.1 with SMTP id j1mr17757401wag.176.1231610583357; Sat, 10 Jan 2009 10:03:03 -0800 (PST)
Received: by 10.114.126.11 with HTTP; Sat, 10 Jan 2009 10:03:03 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sat, 10 Jan 2009 18:03:03 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: "Arnt Gulbrandsen" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <PCbmC+s//[e-mail]> <[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>

On Wed, Jan 7, 2009 at 7:38 PM, Ned Freed <[e-mail]> wrote:
>
>
>> Alexey Melnikov writes:
>> > If we want to allow for magic comments, it make sense for them to be
>> > in a separate namespace. But then magic comments are typically
>> > implementation specific. So I unless we want to startadize them, I
>> > don't think the document needs another namespace.
>
>> Each generator may want to use a namespace of its own for its particular
>> foo. I am not an expert in this. If that's considered good XML taste,
>> then that should be illustrated in an example or two.
>
> I certainly want to allow that - indeed, I don't know of a way to disallow
> it.
> But I don't want to require this approach.

AFACT the current draft does not allow mixing of namespaces

- 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 n0AI0ZCI097953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Jan 2009 11:00:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0AI0ZY7097952; Sat, 10 Jan 2009 11:00:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0AI0NrN097945 for <[e-mail]>; Sat, 10 Jan 2009 11:00:34 -0700 (MST) (envelope-from [e-mail])
Received: by wa-out-1112.google.com with SMTP id j32so5714251waf.26 for <[e-mail]>; Sat, 10 Jan 2009 10:00:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=g7AHO3RoxZQ1Q4GNm0d1DOyYio+qNlaciVn0s4cC4GI=; b=Pi5E8SUttEpgCMMnfbXlIdcyOr5npRXp7aUgF4swhPw/VWnMLAg6Hall7pq5OuLVLz 1thZMOFxd9LAhi0Juto6zaHt7aZquqY1ZXqbbmi/scpBlFawSJbtJSXFufY/0hC5+Yd7 SkIta2ETDhSiVMQ5Mi2os/+JeoxvUKofXNe+M=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=vJjUNkT5q7s2j0rIkP5TUotosi704Z/xZf0PZOdzkZMyoPaaIl81EgYZ5e10hrDkI6 AmG0RZS4UozXpXUiOIvfkHpmS07C8ceVSEf8lB3j32K3XLOEmWKJKPwxca0wi+/1yFag teSHv0F6nAy2BzvgO9xFUNlq4XzVE1t92IenQ=
Received: by 10.115.22.1 with SMTP id z1mr17729134wai.216.1231610423318; Sat, 10 Jan 2009 10:00:23 -0800 (PST)
Received: by 10.114.126.11 with HTTP; Sat, 10 Jan 2009 10:00:23 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sat, 10 Jan 2009 18:00:23 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Alexey Melnikov" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: "Ned Freed" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

On Wed, Jan 7, 2009 at 8:06 AM, Alexey Melnikov
<[e-mail]> wrote:
> On Wed, Jan 7, 2009 at 1:07 AM, Ned Freed <[e-mail]> wrote:
>  [...]
>>
>> > 2. a decision will also need to be taken about the mixture of domains.
>> > mixing sieve with annotations about sieve means that the schema has to
>> > be edited (to separate these concerns) before being used in modern
>> > generators. unless this is supported at least implicitly by the
>> > specification, it just means that an alternative specification will be
>> > needed for these use cases.
>> I take this to mean that you want separate namespaces for annotations and
>> sieve
>> proper. I'm against this because I dislike the complexity it adds, which I
>> see
>> as unnecessary. And unless there's some evidence of support for your view
>> from
>> other quarters I'm not going to revisit this.
>
>
> Excuse my ignorance, but I fail to see why it would be necessary to use a
> different namespace for Sieve comments. Programs that interpret Sieve from
> XML representation would just ignore such elements. Programs that generate
> XML representation automatically (e.g. from some rule based UI) are unlikely
> to generate them anyway.

for generative web services, i agree that this is mainly annoying and
inelegant. however, a library which claims compatibility would need to
deal with them if they are mandatory which would is a PITA.

> Am I missing some use

using eclipse (for example) it's possible to generate an editor from a
schema. mixing the domains means that the annotations will appear as
editable to the user.

- 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 n0AHqP1j097729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Jan 2009 10:52:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0AHqPYI097728; Sat, 10 Jan 2009 10:52:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.249]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0AHqEg5097715 for <[e-mail]>; Sat, 10 Jan 2009 10:52:24 -0700 (MST) (envelope-from [e-mail])
Received: by rv-out-0708.google.com with SMTP id c5so11209749rvf.34 for <[e-mail]>; Sat, 10 Jan 2009 09:52:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=+K76u72tb6jnmLv0ol+a951eLRACQdn8xsxgx/bNCe4=; b=uWKDORR6XAzJich7mR0cr32wHobkQyMs2KGZpXjDXKQiaxoKddUsccTdDNpS6LSAl9 iNWrcDUzuP1sqWm2O6eAaMivdCMmjwBMggyg4+mxkscDr5XwqVax05opMPw5XcOlDp5U Pe2OR+O6i6W+pWnkBE0kBmtaZE2wSPfEGnvkw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=fBA5UmRsjwtcXOE2x35hxctBgf61HE+LY2EbvswOBb4NpBJrGm0atdglBKzhsHTimC 4Iexth+Bca3yAjzMBpNv1frcJp7twhh/zE/Yqz2ALdvaZ9VNFZMbW9+uAnntenQE8VLR LbGTR2teVG9jzBgzyJQv7bHizKzkx/QI0JhAc=
Received: by 10.114.148.2 with SMTP id v2mr12255959wad.169.1231609933840; Sat, 10 Jan 2009 09:52:13 -0800 (PST)
Received: by 10.114.126.11 with HTTP; Sat, 10 Jan 2009 09:52:13 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sat, 10 Jan 2009 17:52:13 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: "Alexey Melnikov" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

On Wed, Jan 7, 2009 at 12:07 AM, Ned Freed <[e-mail]> wrote:
>> (i'm unlikely to contribute to a flawed specification unless there is
>> some hope that it will be fixed)
>
> First of all, there is no such thing as a perfect specification; they are all
> flawed to some extent. It's the nature of the beast.
>
> Second, and perhaps more to the point, we demand rough consensus on
> specifications, nothing more. I could probably list a couple of things I'm
> unhappy about or don't agree with in any specification I've participated in
> developing, and for the major ones I can easily list a dozen issues or more.
> Once more this is the nature of the beast. But the fact that I didn't agree
> with the consensus on some points - and in some cases on many points - didn't
> prevent me from contributing to those efforts.

thanks for the explaination

we're currently adding xml serialisation for jsieve over at apache.
there are number of concrete use cases that this serialisation needs
to satisfy. the current draft is currently unsatisfactory so we'll
probably just need to go ahead and create a competing standard. i
think this would be a shame.

my experience on this group hasn't exactly been pleasent for me
(thankfully most of the name calling has been in private). there don't
seem to be very many other implementators on this list with my
background so i'm consistently in a monority of one here. i'm unlikely
to waste energy contributing to a competing standard.

>> using XML Schema as the formal definition means that decisions have to
>> be taken which are forced by the language which would not be required
>> by an alternative formal method.
>
> Which is now irrelevant since we're not using XML Schema any more.
>
>> 1. a decision will be needed to either use the default namespace or
>> another namespace. this will mean either sacrificing user who are
>> still using parsers from the 1990s or sacrificing those who need
>> explicit namespacing.
>
> Perhaps I don't understand what you're after here, but since the specification
> now defines a namespace this also appears to me to be irrelevant.

to maintain compatibility between namespace aware and unaware parsers
this is necessary but not sufficient. also required is a standard
prefix.

>> 2. a decision will also need to be taken about the mixture of domains.
>> mixing sieve with annotations about sieve means that the schema has to
>> be edited (to separate these concerns) before being used in modern
>> generators. unless this is supported at least implicitly by the
>> specification, it just means that an alternative specification will be
>> needed for these use cases.
>
> I take this to mean that you want separate namespaces for annotations and sieve
> proper. I'm against this because I dislike the complexity it adds, which I see
> as unnecessary. And unless there's some evidence of support for your view from
> other quarters I'm not going to revisit this.

without correct separation of concerns, the specification cannot be
used for generation. for developers working in modern langauges using
modern toolsets, this is a major limitation. it just means that
another standard will be required to support these use cases.

making support for annotations optional would be good enough for me.
ideally, i would like to see any mixture of XML allowed by the
specification. this would allow editors based on different principles
to claim support without having to adopt the recommended system of
annotations.

>> ATM lack of namespace support and a failure to separate the concerns
>> in the design of schema means that the specification is useless to me
>> and many other developers using modern, namespace aware tools. by
>> applying methods used in other RFCs facing these issues, it should be
>> possible to create a specification suitable for both legacy and modern
>> tooling.
>
> I'm afraid I just don't see it. The pointers you have given so far have been to
> specifications I regard as overdesigned to the point of near unreadability.

in the xml community, these specifications are usually held in high
regard. it's just surprisingly hard to explain that it works just how
you'd hope it would.

- 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 n08MdJS0077294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 15:39:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08MdJXg077293; Thu, 8 Jan 2009 15:39:19 -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 n08Md8IY077283 for <[e-mail]>; Thu, 8 Jan 2009 15:39:18 -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]; Thu, 8 Jan 2009 14:38:31 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 08 Jan 2009 09:07:54 -0800 (PST)
Date: Thu, 08 Jan 2009 08:27:34 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
In-reply-to: "Your message dated Wed, 07 Jan 2009 00:57:51 +0000" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

> > > however (in my experience) the generative tools commonly used for XML
> > > and web service binding, and editor generation tend not to offer good
> > > relax support. IMO the draft should offer secondary informative XML
> > > Schema or Schemata to assist developers using these tools.

> > The problem is that the unique particle attribution limitation in XML Schema
> > effectively precludes using it without some compromises. I am therefore opposed
> > to continuing to include it.

> adopting a standard prefix - sieve, say - is all that is required

To get around the unique particle attribution restriction that prevents XML
Schema from describing many legitimate schemata? If that's truly the case a lot
of XML developers would love to hear more.

> is this really too much to ask?

I fail to see what defining a prefix has to do with the use or non-use of XML
Schema, but for about the tenth time, I have already added a namespace name
registration to the specification.

AFAIK the specific namespace prefix that gets bound to the namespace name is
not something that can or should be standardized. Rather, it is declared on a
per-document basis using an xmlns attribute. Any agent out there that supports
namespaces should support the use of xmlns to pick whatever prefix a given
document binds to the urn:ietf:params:xml:sieve namespace.

> >> > But I'm sitll a little confused as to what you're asking for here. If you're
> >> > asking for removal of the explicit inline XML syntax examples in favor of a
> >> > more abstract approach, I'd be fine with that if there's a WG consensus to make
> >> > such a change.
> >
> >> no - i'm very happy with the syntax examples
> >
> >> i would like to see the approach used in RFC 5023 (and others)
> >> adopted, adding a normative description of the XML and making the
> >> schema only informative.
> >
> > Personally, I find RFC 5023 approach, like the XOPEN object descriptions it's
> > similar to, to be almost totally unreadable. Maybe it's the only reasonable way
> > to do it when the element structure is quite complex, but that's not the case
> > here.
> >
> > So, absent some fairly strong support for this from others in the group, I'm
> > not going to pursue this.

> is there anyone else in group - excepting you and myself - who cares
> enough to contribute at all to this discussion?

Well, quite a few people have cared enough to discuss other aspects of this
document in the past, and now that the topic of comment mapping has come
up a number are joining in again.

In other words, it seems people care about the document, just not about most of
the issues you have raised.

> for the class of application (enterprise mail servers is a name that's
> sometimes used but quite possibly that's not familiar to others in the
> group), unfortunately it is

Robert, developing enterprise and ISP class mail servers is what I do for a
living. I've been doing it for over 20 years now. So I think this is something
I might know just a little bit about.

But really, this entire discussion has gone very far afield. Like it or not,
Sieve is intended to be a language used to process email messages at or around
the time of final delivery. The fact that it can be adapted for other uses may
be interesting to you but simply is not relevant in the context of the work
this group is chartered to do. I am therefore not going to continue to respond
further to this discussion of what applications developers do or do not need to
know about email and the specifics of header and envelpe handling. In fact I
regret having continued the discussion to this point.

				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 n07KBZlW098335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 13:11:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n07KBZFN098334; Wed, 7 Jan 2009 13:11:35 -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 n07KBOfu098324 for <[e-mail]>; Wed, 7 Jan 2009 13:11:35 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 0681410936E4; Wed,  7 Jan 2009 15:11:24 -0500 (EST)
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 uIh7tsqfV4Bu; Wed,  7 Jan 2009 15:11:23 -0500 (EST)
Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 3235F10936DD; Wed,  7 Jan 2009 15:11:21 -0500 (EST)
Date: Wed, 07 Jan 2009 15:11:18 -0500
From: Cyrus Daboo <[e-mail]>
To: Ned Freed <[e-mail]>, Arnt Gulbrandsen <[e-mail]>
cc: [e-mail]
Subject: Re: draft-freed-sieve-in-xml status?
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]> <[e-mail]> <[e-mail]> <[e-mail]> <PCbmC+s//[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=990
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 Ned,

--On January 7, 2009 11:38:02 AM -0800 Ned Freed <[e-mail]> 
wrote:

>> Each generator may want to use a namespace of its own for its particular
>> foo. I am not an expert in this. If that's considered good XML taste,
>> then that should be illustrated in an example or two.
>
> I certainly want to allow that - indeed, I don't know of a way to
> disallow it.
> But I don't want to require this approach.
>
> It also occurs to me that as a practical matter, a lot of Sieve generators
> produce what amounts to a list of rules. (Our implementation works this
> way.)
> Perhaps an example of a "rule list" sieve done first with the built in
> annotation capabilities and then again using the separate namespace
> approach
> would be helpful. Thoughts?

Could this be done in an Appendix that lists some current common practice 
with sieve scripts and how that might be re-worked for XML? I don't think 
it needs to be part of the main body of the spec.

-- 
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 n07Jg4rH096520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 12:42:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n07Jg4Fo096519; Wed, 7 Jan 2009 12:42:04 -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 n07JfpFq096506 for <[e-mail]>; Wed, 7 Jan 2009 12:42:02 -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, 7 Jan 2009 11:41:50 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Wed, 07 Jan 2009 11:41:47 -0800 (PST)
Date: Wed, 07 Jan 2009 11:38:02 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
In-reply-to: "Your message dated Wed, 07 Jan 2009 15:59:33 +0100" <PCbmC+s//[e-mail]>
To: Arnt Gulbrandsen <[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]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <PCbmC+s//[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>

> Alexey Melnikov writes:
> > If we want to allow for magic comments, it make sense for them to be
> > in a separate namespace. But then magic comments are typically
> > implementation specific. So I unless we want to startadize them, I
> > don't think the document needs another namespace.

> Each generator may want to use a namespace of its own for its particular
> foo. I am not an expert in this. If that's considered good XML taste,
> then that should be illustrated in an example or two.

I certainly want to allow that - indeed, I don't know of a way to disallow it.
But I don't want to require this approach.

It also occurs to me that as a practical matter, a lot of Sieve generators
produce what amounts to a list of rules. (Our implementation works this way.)
Perhaps an example of a "rule list" sieve done first with the built in
annotation capabilities and then again using the separate namespace approach
would be helpful. Thoughts?

				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 n07Fqr4x084486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 08:52:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n07FqrU7084485; Wed, 7 Jan 2009 08:52:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n07Fqekh084470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 7 Jan 2009 08:52:52 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1LKahz-0006kq-H1; Wed, 07 Jan 2009 16:52:39 +0100
Received: from feh.linpro.no ([87.238.42.45]) by mail-mx5.uio.no with esmtpsa (TLSv1:CAMELLIA256-SHA:256) user kjetilho (Exim 4.69) (envelope-from <[e-mail]>) id 1LKahy-00085a-WB; Wed, 07 Jan 2009 16:52:39 +0100
Subject: Re: draft-freed-sieve-in-xml status?
From: Kjetil Torgrim Homme <[e-mail]>
Reply-To: [e-mail]
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail]
In-Reply-To: <PCbmC+s//[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <PCbmC+s//[e-mail]>
Content-Type: text/plain
Date: Wed, 07 Jan 2009 16:52:36 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) 
Content-Transfer-Encoding: 7bit
X-UiO-SPF-Received: 
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: CE6EA58D733F2B67DCF4DEB3ED965AA0B0835186
X-UiO-SPAM-Test: remote_host: 87.238.42.45 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 135 max/h 3 blacklist 0 greylist 0 ratelimit 0
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>

On Wed, 2009-01-07 at 15:59 +0100, Arnt Gulbrandsen wrote:
> Alexey Melnikov writes:
> > If we want to allow for magic comments, it make sense for them to be 
> > in a separate namespace. But then magic comments are typically 
> > implementation specific. So I unless we want to startadize them, I 
> > don't think the document needs another namespace.
> 
> Each generator may want to use a namespace of its own for its particular 
> foo. I am not an expert in this. If that's considered good XML taste, 
> then that should be illustrated in an example or two.

I think that it's bad to make the XML representation more expressive
than the basic Sieve language.  we can't have two types of comments in
XML Sieve, and just one type in plain Sieve.  if we want to cater for
"magic comments", we should make a mechanism for it in Sieve itself.

one way would be to add a new "action", like
   "meta" UP-TO-DATE TOKEN TEXT
where UP-TO-DATE is a boolean, TOKEN is a unique identifier (e.g.
domainname of the implementer, I wouldn't want an IANA registry), and
TEXT is opaque information.  the specification should say that the
"meta" is attached to the next non-"meta" statement, and if that
statement changes semantic meaning, UP-TO-DATE for unknown TOKENs should
be set to FALSE.  if a statement is removed, all "meta" statements
associated with it should be removed as well.

(I only spent five minutes on this "spec", so take it for what it's
worth ;-)
-- 
regards,
Kjetil T.



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 n07ExgPZ081191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 07:59:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n07ExgWL081190; Wed, 7 Jan 2009 07:59:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n07ExUpD081177 for <[e-mail]>; Wed, 7 Jan 2009 07:59:41 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 57BCE4AC44; Wed,  7 Jan 2009 15:59:30 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1231340370-64703-1/6/6 for [e-mail]; Wed, 7 Jan 2009 15:59:30 +0100
Message-Id: <PCbmC+s//[e-mail]>
Date: Wed, 7 Jan 2009 15:59:33 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: draft-freed-sieve-in-xml status?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
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>

Alexey Melnikov writes:
> If we want to allow for magic comments, it make sense for them to be 
> in a separate namespace. But then magic comments are typically 
> implementation specific. So I unless we want to startadize them, I 
> don't think the document needs another namespace.

Each generator may want to use a namespace of its own for its particular 
foo. I am not an expert in this. If that's considered good XML taste, 
then that should be illustrated in an example or two.

Arnt



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 n07E5O87078573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 07:05:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n07E5OmA078572; Wed, 7 Jan 2009 07:05:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n07E5DxM078554 for <[e-mail]>; Wed, 7 Jan 2009 07:05:24 -0700 (MST) (envelope-from [e-mail])
Received: by wf-out-1314.google.com with SMTP id 25so8402392wfc.28 for <[e-mail]>; Wed, 07 Jan 2009 06:05:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=TaSwGwQf5qZNX17/dgkN47a/jtmYdGR4AhFpzs/5Fpg=; b=nLqv6hptNCFDYMFUiGHIo2tiUal38DMeHY+jPsWCvnriNR98EWKfTMyKMMBuQd9Hv5 sQatAE4FE0wwwgbvg9+cPWteHPrMUS5WCKYntDtuFmL+dQtv8DHyKEABor+ZMUBCQ36T +5/Ld152qBrc8DO4KpZACe8rIW52KZPi0QxDM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=KeAnr6n9RJ/FJOzXnHcGN9YZRQISMfEdFrzpVZM2/1BcEY9bCCafY4li7pHpbk+sbj 4L+kbVnPMqkRca4T5w01IbZR3HsxHQ46g6Fa3olFcpOfPvr90KyxQ+WBSgfQhtAwtXlb H9fm9ESGHBfNX+ghSItsf0wv4dTAs9CBky1eU=
Received: by 10.142.164.10 with SMTP id m10mr9670069wfe.27.1231337113543; Wed, 07 Jan 2009 06:05:13 -0800 (PST)
Received: by 10.143.42.15 with HTTP; Wed, 7 Jan 2009 06:05:13 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 7 Jan 2009 15:05:13 +0100
From: "Alexey Melnikov" <[e-mail]>
To: "Arnt Gulbrandsen" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_310886_29301460.1231337113532"
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Google-Sender-Auth: 8d81d72a36a8a108
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>

------=_Part_310886_29301460.1231337113532
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Wed, Jan 7, 2009 at 1:43 PM, Arnt Gulbrandsen
<[e-mail]>wrote:

> Alexey Melnikov writes:
>
>> Programs that generate XML representation automatically (e.g. from some
>> rule based UI) are unlikely to generate them anyway.
>>
> Uhm. Programs do generate sieve comments, typically containing magic syntax
> specific to the generator.
>
>  Am I missing some use cases?
>>
>
> I think the draft would do well to suggest how magic generator-specific
> syntax ought to be handled, with an example or two. Magic stuff should not
> be syntactically similar to a sieve comment.

+1.

If we want to allow for magic comments, it make sense for them to be in a
separate namespace. But then magic comments are typically implementation
specific. So I unless we want to startadize them, I don't think the document
needs another namespace.

------=_Part_310886_29301460.1231337113532
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div class="gmail_quote">On Wed, Jan 7, 2009 at 1:43 PM, Arnt Gulbrandsen <span dir="ltr">&lt;<a href="mailto:[e-mail]">[e-mail]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="Ih2E3d">Alexey Melnikov writes:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Programs that generate XML representation automatically (e.g. from some rule based UI) are unlikely to generate them anyway.<br>
</blockquote></div>Uhm. Programs do generate sieve comments, typically containing magic syntax specific to the generator. <br><br>
<div class="Ih2E3d">
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Am I missing some use cases?<br></blockquote><br></div>I think the draft would do well to suggest how magic generator-specific syntax ought to be handled, with an example or two. Magic stuff should not be syntactically similar to a sieve comment.</blockquote>

<div>+1.</div>
<div>&nbsp;</div>
<div>If we want to allow for magic comments, it make sense for them to be in a separate namespace. But then magic comments are typically implementation specific. So I unless we want to startadize them, I don&#39;t think the document needs another namespace.</div>

<div>&nbsp;</div></div>

------=_Part_310886_29301460.1231337113532--



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 n07ChdPn073513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 05:43:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n07Chdc0073512; Wed, 7 Jan 2009 05:43:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n07Cha9e073503 for <[e-mail]>; Wed, 7 Jan 2009 05:43:38 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 319034AC44; Wed,  7 Jan 2009 13:43:36 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1231332215-64703-1/6/5 for [e-mail]; Wed, 7 Jan 2009 13:43:35 +0100
Message-Id: <[e-mail]>
Date: Wed, 7 Jan 2009 13:43:39 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: draft-freed-sieve-in-xml status?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
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>

Alexey Melnikov writes:
> Programs that generate XML representation automatically (e.g. from 
> some rule based UI) are unlikely to generate them anyway.

Uhm. Programs do generate sieve comments, typically containing magic 
syntax specific to the generator.

> Am I missing some use cases?

I think the draft would do well to suggest how magic generator-specific 
syntax ought to be handled, with an example or two. Magic stuff should 
not be syntactically similar to a sieve comment.

Arnt



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 n07874qt057183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 01:07:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n07874Ig057182; Wed, 7 Jan 2009 01:07:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.243]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0786qTF057158 for <[e-mail]>; Wed, 7 Jan 2009 01:07:03 -0700 (MST) (envelope-from [e-mail])
Received: by rv-out-0708.google.com with SMTP id c5so9108375rvf.34 for <[e-mail]>; Wed, 07 Jan 2009 00:06:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=AvAQ8eyP+izLGFFppLI9ei1uvZXJ0wOxMVJhjRdX2e4=; b=GueVLkksGNBlYuYB9oyYwXLauLK0jk8/rlubNmsM0DwiyFbxEqfpAjcGep1/P1zVnj bjvXi/cVP52g1/shqZcdl2iTleQT7zxlzST75txXxMHXFjaFAcW5zBJzTWtYFoh/1pr1 39V/qkgzD4bEc6GTYWFlipP1yDk5/FJxYEtcY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=g09KsBPWA20vW/XZyJTHjQxnSLeaP7Dy3Zv4Evdxq8jIhU3PHgPG9aKKZgn4BVy1F8 RPVKL4KycuWSeU3hksbe2rRhBS97hJ8kKvyFiN+fjvkZBT13OZ9cT4mZW9JQZL9A4rlu ezuXwpm+/NIj+VLTz61E6WxWouyA4I3JEv6z8=
Received: by 10.142.156.19 with SMTP id d19mr9536910wfe.289.1231315612546; Wed, 07 Jan 2009 00:06:52 -0800 (PST)
Received: by 10.143.42.15 with HTTP; Wed, 7 Jan 2009 00:06:52 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 7 Jan 2009 09:06:52 +0100
From: "Alexey Melnikov" <[e-mail]>
To: "Robert Burrell Donkin" <[e-mail]>, "Ned Freed" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_306215_10019195.1231315612539"
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Google-Sender-Auth: 02fe873feae6b1fb
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>

------=_Part_306215_10019195.1231315612539
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Wed, Jan 7, 2009 at 1:07 AM, Ned Freed <[e-mail]> wrote:
 [...]

> > 2. a decision will also need to be taken about the mixture of domains.
> > mixing sieve with annotations about sieve means that the schema has to
> > be edited (to separate these concerns) before being used in modern
> > generators. unless this is supported at least implicitly by the
> > specification, it just means that an alternative specification will be
> > needed for these use cases.
> I take this to mean that you want separate namespaces for annotations and
> sieve
> proper. I'm against this because I dislike the complexity it adds, which I
> see
> as unnecessary. And unless there's some evidence of support for your view
> from
> other quarters I'm not going to revisit this.


Excuse my ignorance, but I fail to see why it would be necessary to use a
different namespace for Sieve comments. Programs that interpret Sieve from
XML representation would just ignore such elements. Programs that generate
XML representation automatically (e.g. from some rule based UI) are unlikely
to generate them anyway.
Am I missing some use cases?

------=_Part_306215_10019195.1231315612539
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div class="gmail_quote">On Wed, Jan 7, 2009 at 1:07 AM, Ned Freed <span dir="ltr">&lt;<a href="mailto:[e-mail]">[e-mail]</a>&gt;</span> wrote:</div>
<div class="gmail_quote">&nbsp;[...]<br></div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="Ih2E3d">&gt; 2. a decision will also need to be taken about the mixture of domains.<br>&gt; mixing sieve with annotations about sieve means that the schema has to<br>&gt; be edited (to separate these concerns) before being used in modern<br>
&gt; generators. unless this is supported at least implicitly by the<br>&gt; specification, it just means that an alternative specification will be<br>&gt; needed for these use cases.<br></div>I take this to mean that you want separate namespaces for annotations and sieve<br>
proper. I&#39;m against this because I dislike the complexity it adds, which I see<br>as unnecessary. And unless there&#39;s some evidence of support for your view from<br>other quarters I&#39;m not going to revisit this.</blockquote>

<div>&nbsp;</div>
<div>Excuse my ignorance, but I fail to see why it would be necessary to use a different namespace for Sieve comments. Programs that interpret Sieve from XML representation would just ignore such elements. Programs that generate XML representation automatically (e.g. from some rule based UI) are unlikely to generate them anyway.<br>
</div>
<div>Am I missing some use cases?</div>
<div>&nbsp;</div>

------=_Part_306215_10019195.1231315612539--



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 n073b03f045746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jan 2009 20:37:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n073b0cT045745; Tue, 6 Jan 2009 20:37:00 -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 n073am7P045733 for <[e-mail]>; Tue, 6 Jan 2009 20:36:59 -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]; Tue, 6 Jan 2009 19:36:46 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 06 Jan 2009 19:36:43 -0800 (PST)
Date: Tue, 06 Jan 2009 16:07:36 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
In-reply-to: "Your message dated Tue, 06 Jan 2009 23:01:57 +0000" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

> (i'm unlikely to contribute to a flawed specification unless there is
> some hope that it will be fixed)

First of all, there is no such thing as a perfect specification; they are all
flawed to some extent. It's the nature of the beast.

Second, and perhaps more to the point, we demand rough consensus on
specifications, nothing more. I could probably list a couple of things I'm
unhappy about or don't agree with in any specification I've participated in
developing, and for the major ones I can easily list a dozen issues or more.
Once more this is the nature of the beast. But the fact that I didn't agree
with the consensus on some points - and in some cases on many points - didn't
prevent me from contributing to those efforts.

> using XML Schema as the formal definition means that decisions have to
> be taken which are forced by the language which would not be required
> by an alternative formal method.

Which is now irrelevant since we're not using XML Schema any more.

> 1. a decision will be needed to either use the default namespace or
> another namespace. this will mean either sacrificing user who are
> still using parsers from the 1990s or sacrificing those who need
> explicit namespacing.

Perhaps I don't understand what you're after here, but since the specification
now defines a namespace this also appears to me to be irrelevant.

> 2. a decision will also need to be taken about the mixture of domains.
> mixing sieve with annotations about sieve means that the schema has to
> be edited (to separate these concerns) before being used in modern
> generators. unless this is supported at least implicitly by the
> specification, it just means that an alternative specification will be
> needed for these use cases.

I take this to mean that you want separate namespaces for annotations and sieve
proper. I'm against this because I dislike the complexity it adds, which I see
as unnecessary. And unless there's some evidence of support for your view from
other quarters I'm not going to revisit this.

> ATM lack of namespace support and a failure to separate the concerns
> in the design of schema means that the specification is useless to me
> and many other developers using modern, namespace aware tools. by
> applying methods used in other RFCs facing these issues, it should be
> possible to create a specification suitable for both legacy and modern
> tooling.

I'm afraid I just don't see it. The pointers you have given so far have been to
specifications I regard as overdesigned to the point of near unreadability.

				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 n070vt7M037721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jan 2009 17:57:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n070vtui037720; Tue, 6 Jan 2009 17:57:55 -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-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n070vq21037712 for <[e-mail]>; Tue, 6 Jan 2009 17:57:53 -0700 (MST) (envelope-from [e-mail])
Received: by bwz5 with SMTP id 5so15349620bwz.10 for <[e-mail]>; Tue, 06 Jan 2009 16:57:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=gx759oNeARk68IptmnT18/Q2alpoAwJiARIQIywUeiA=; b=xzzXU77a6ohEHIa2h7mH6y8cwDPe+P3i3b1lF0koMHJm1TCOZkxppy0/OTdbneEt0T yWyU2sLq87MrbafFg2DhmWetvSFNY6LOvaP21jdLimLguF67cVFkocIV84bxQKbfkbBX ih9eqRqcQGQ8r5QWg6v3TR1IX9H7ROZvPezxg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=hjLYj6w7K8Uvqa+QSRGh1IvoZZ5tlzwCM73OL+6F2skY2z56pFXiNiVm0gPkerNKvC vUapPrSHKHP3i5XYJAJR45ZwknNLymreOnArjuYFyR80SRSsfmt4hbs3AA1lXe3vwPvM 0/du/9MSv01w3LnGn5c2ONFQZ2Hgway+pZQ2Q=
Received: by 10.181.224.3 with SMTP id b3mr8689319bkr.183.1231289871873; Tue, 06 Jan 2009 16:57:51 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Tue, 6 Jan 2009 16:57:51 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 7 Jan 2009 00:57:51 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

On Sun, Dec 28, 2008 at 10:31 PM, Ned Freed <[e-mail]> wrote:
>
>> On Sun, Dec 14, 2008 at 9:59 PM, Ned Freed <[e-mail]> wrote:
>> >> On Sun, Dec 14, 2008 at 6:06 PM, Ned Freed <[e-mail]> wrote:
>> >> >> i note that the draft describes the infoset rather than defining it in
>> >> >> the standard way. is there a reason for this decision?
>> >> >
>> >> > I don't know what "the standard way" is you're referring to. Perhaps you
>> >> > could provide a reference to an RFC where this has been used?
>> >
>> >> AIUI XML is maintained by w3c (rather than IEFT) so is a
>> >> recommendation. http://www.w3.org/TR/xml-infoset/ is the current
>> >> document.
>> >
>> > Quite true, however, the IETF has its own specification for XML is supposed to
>> > be used in RFCs: RFC 3470. And while infosets are mentioned as one approach to
>> > specifying things about an XML format, there's no recommendation, let alone
>> > requirement, that they be used.
>> >
>> >> > This document is a little unusual in that it's defining a mapping of, if you
>> >> > will, a non-XML infoset onto XML. As such, the natural approach seemed to be to
>> >> > first discuss the structure of the language being mapped, then explain the
>> >> > mapping, and finish up with additional unique-to-XML semantics.
>> >
>> >> i agree that most of this arangement is natural. it's just jumping to
>> >> a schema seems - to me - a little premature and inflexible.
>> >
>> > First of all, the use of XML Schema is in fact too inflexible to be allowed
>> > to continue. The next revision will use Relax instead.
>
>> XML schema is flexible but the flexibility comes at the price of
>> readability. one of relax variants would be a better choice.
>
>> however (in my experience) the generative tools commonly used for XML
>> and web service binding, and editor generation tend not to offer good
>> relax support. IMO the draft should offer secondary informative XML
>> Schema or Schemata to assist developers using these tools.
>
> The problem is that the unique particle attribution limitation in XML Schema
> effectively precludes using it without some compromises. I am therefore opposed
> to continuing to include it.

adopting a standard prefix - sieve, say - is all that is required

is this really too much to ask?

>> > But I'm sitll a little confused as to what you're asking for here. If you're
>> > asking for removal of the explicit inline XML syntax examples in favor of a
>> > more abstract approach, I'd be fine with that if there's a WG consensus to make
>> > such a change.
>
>> no - i'm very happy with the syntax examples
>
>> i would like to see the approach used in RFC 5023 (and others)
>> adopted, adding a normative description of the XML and making the
>> schema only informative.
>
> Personally, I find RFC 5023 approach, like the XOPEN object descriptions it's
> similar to, to be almost totally unreadable. Maybe it's the only reasonable way
> to do it when the element structure is quite complex, but that's not the case
> here.
>
> So, absent some fairly strong support for this from others in the group, I'm
> not going to pursue this.

is there anyone else in group - excepting you and myself - who cares
enough to contribute at all to this discussion?

>> >> sieve). there is a large and growing requirement for integration
>> >> between mail and enterprise systems (typically coding in Java and .NET
>> >> but also ruby and python). developers from enterprise backgrounds are
>> >> typically strong on web+xml but very weak on mail.
>> >
>> > Yep, I've seen a lot of this as well. And the problem emcompasses far more than
>> > Sieve: For example, a lot of people who are unfamiliar with email don't
>> > understand very basic concepts such as the separation between envelope and
>> > message content. (This particular issue actually pokes through into Sieve in
>> > the form of whether an envelope or header test is appropriate.)
>
>> i beg to differ slightly on this one
>
>> some enterprise mail processing may happen during the SMTP transaction
>> but it is more typical for the mail processing after storage. not all
>> mail stored arrives through SMTP and so it is typical for any envelope
>> information to be reduced to simple MIME headers.
>
> Robert, with all due respect, you may have substantial expertise on the XML
> front,  but your comments here are actually doing little more than illustrate
> the validity of my argument that there's a general issue with people not
> getting how email works that isn't going to get fixed by anything we do here.

ned - with all due respect - your comments illustrate a lack of
understanding of this class of mail server

> If you want this addressed the place to look is the email architecure
> specifications being worked on by Dave Crocker.
>
> And it is NOT typical for envelope information to be stored as headers.

for the class of application (enterprise mail servers is a name that's
sometimes used but quite possibly that's not familiar to others in the
group), unfortunately it is

> There are several reasons for this:
>
> (1) Envelopes only exist between the time of submission and final delivery.
>    Transport actions do record certain bits of envelope information in
>    trace header fields and final delivery is supposed to copy some additional
>    envelope information into a couple of header fields, but these are NOT
>    a message envelope and it is mistake to assume they are.
>
> (2) During the time the envelope exists it is highy mutable, often changing
>    form at every hop. This makes header storage of envelope information
>    somewhat problematic.

true

> (3) There are several SMTP extension that add to the envelope in various ways,
>    requiring negotiation of what envelope information can and cannot be
>    passed from one system to another. This tends to interact badly with
>    schemes that store envelope information as a static part of the message.

(when SMTP delivery is just the first step in mail processing, this
isn't such a problem)

> (4) The fact that protocols other than SMTP are used for various email
>    operations doesn't necessarily impact header/envelope separability.
>    Other protocols maintain this separation and at least one of them, X.400,
>    actually has a far greater degree of separation than SMTP does.

(not all protocol maintain this separation and if any mail enters
through those protocols, this information will not be available)

> (5) Because there are effectively no controls on what ends up in headers, it
>    is fairly easy for the separation between "header" headers and "envelope"
>    headers to get lost. Among other things, this can create serious
>    security vulnerabilities.

(only during SMTP delivery )

> Now, this is not to say there aren't various ad-hoc schemes in use where active
> envelope information ends up getting stuffed into the header. Such schemes date
> back to BITNET's use of X-Envelope-To: to work around the 8x8 limit and
> probably long before. But in my experience at least these things invariably
> fail to provide a full and correct mapping for all of the possible information
> that can exist in an SMTP (or X.400) envelope. And as a consequence they
> invariably cause problems because of their inability to truly express envelope
> semantics.
>
> Indeed, if you have to capture envelope information in a static form - the main
> current use-case for this is compliance archiving - in most cases you're better
> off NOT using header-based schemes. We even have a standard format defined for
> this: Batch SMTP. Although the format that's probably used the most is the one
> Exchange generates that they call "envelope journaling", which puts the
> envelope in the first text part of a MIME multipart. (On a side note, if anyone
> knows where there's a precise and complete specification of the syntax used for
> envelope journaling, I've appreciate a pointer.)

i agree that stuffing this information into headers is a bad idea (i
intended to observe not advocate above)

i disagree that this is a protocol problem with a protocol solution -
it's simply a poor choice of data representation by the designers.
more modern approaches to meta-data use namespacing and this prevents
loss of information. (this is often then compounded by confusing a
dead MIME document with a live email.)

>> most developers in
>> these mail processing environments do not need to understand the
>> difference between envelope and message content because - for them -
>> there is no difference.
>
> Yeah, that's what a lot of them think. The problem is they're quite simply
> wrong, and it is isn't a harmless thing to be wrong about. I get plenty of
> support calls from customers who got screwed by this lack of understanding.
>
> And it is NOT a minor detail when someone sets up a compliance archiving system
> that ends up in many cases not being able to determine who actually sent or
> received a given message. (I only wish I was making up this example.)

:-)

(that's why containers are now often used in the enterprise)

>> Sieve works very well as a general MIME document processing language.
>
> Actuallly that's not Sieve's purpose at all and it isn't something Sieve is
> currently good at. In fact we've only recently taken the first fairly tentative
> step down the MIME processing path with the MIME loops extension and possibly
> the convert extension. We'll see how well that turns out, but I have to say I'm
> not optimistic that it will replace existing ad-hoc MIME processing facilities
> like MIMEdefang.

AIUI these limitations only apply to multipart documents. outside
email, multipart documents are not so common and sieve works fine on
those.

>> the envelope tests are - in many ways - peculiar since the rest of the
>> specification really isn't mail specific. there are potentially some
>> very interesting applications in this area so it would be a shame - i
>> think - for the expert group to focus too strongly on SMTP at the
>> expense of other IMHO equally valid Sieve use cases.
>
> I don't object to the use of Sieve in other contexts - in principle. But the
> devil is in the details. A good example of this is the use of Sieve in an IMAP
> server as defined in draft-ietf-lemonade-imap-sieve-05.txt. This doesn't seem
> like too much of a stretch from existing usage, but when I reviewed this
> document a while back I found all sorts of semantic mismatches, some of them
> quite serious.
>
>> > But here's the dilemma: This stuff is complicated and in some cases fairly
>> > subtle. This in turn means that the reiteration of even a subset of the
>> > underlying design principles that implementors need to know takes up a lot of
>> > space and will still fall short of the mark of giving the necessary guidance.
>> > But it may lead to the belief that reading this specification (or for that
>> > matter this one and RFC 5228) is in fact sufficient to understand how to use
>> > Sieve. It quite simply isn't.
>
>> again, i beg to differ
>
>> sieve is very similar structurally to the guerrilla standards used in
>> enterprise mail system for more than 5 years now. for most mail
>> processing applications, only the container builders need to have a
>> good understanding of the protocols. application developers are
>> offered a safe environment and an OOP interface. i see no reason why
>> sieve should be any different.
>
> Understanding of the protocols isn't necessary, but I'm very much afraid  that
> there's no avoiding an understanding of email semantics if you want things to
> work properly. We may wish it were otherwise, but it just isn't.

depends on what you mean by that

if you're talking about processing as part of SMTP processing (or any
other protocol) then i agree

but often when people think they are processing email, the use case
boils down to essentially processing a dead MIME document with
meta-data that has been previously delivered through some protocol or
other. they may do some other protocol stuff - such as forwarding some
result - but that's essentially acting as an email client. this is
usually within the capability of most general developers without a
good understanding of email semantics.

- 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 n06N2B8C032880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jan 2009 16:02:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n06N2Bg1032879; Tue, 6 Jan 2009 16:02:11 -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-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n06N1wtg032855 for <[e-mail]>; Tue, 6 Jan 2009 16:02:10 -0700 (MST) (envelope-from [e-mail])
Received: by bwz5 with SMTP id 5so15256464bwz.10 for <[e-mail]>; Tue, 06 Jan 2009 15:01:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=TZYKR3OQXq+SQaujU/8pcEDvCpgcZWoROvhBh1bLMCA=; b=Kqb8deQl9QIzHcgJviDAKaaq4BzG0/hwHfMuPT9KXcLaTnIBvD7yvRoS5ejiVB5S7G cYXRUI9mayJJpTgSJ7pIcNqzhKAjA7TQS7Q0m4EwOv3wvDS7Zaya5R3VWKWXuXcec4Sx wq3GBGzAyc7PBXshIfrA27lFMsyX9fmtt/pQs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=bWrTC6nayww6H/X6aiQynVKlajdi2eo+UCejg0bkl8kYjKvtCOfOAp0nHUWTkm+2n8 ru6jfyo1r5A3EeU8q423bgXCJWNAMH0t65vw85eqxPbcPWpiJKQSgclIy20GF1J0Zs+d 18IGJTERZQAlzqGi4RT+maf0i8C0iWno8ZWaE=
Received: by 10.181.193.15 with SMTP id v15mr7696637bkp.168.1231282917420; Tue, 06 Jan 2009 15:01:57 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Tue, 6 Jan 2009 15:01:57 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 6 Jan 2009 23:01:57 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Alexey Melnikov" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: "Ned Freed" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

On Mon, Dec 29, 2008 at 8:26 AM, Alexey Melnikov
<[e-mail]> wrote:
> Ned Freed wrote:
>>>>
>>>> But I'm sitll a little confused as to what you're asking for here. If
>>>> you're
>>>> asking for removal of the explicit inline XML syntax examples in favor
>>>> of a
>>>> more abstract approach, I'd be fine with that if there's a WG consensus
>>>> to make
>>>> such a change.
>>>>
>>>
>>> no - i'm very happy with the syntax examples
>>>    i would like to see the approach used in RFC 5023 (and others)
>>> adopted, adding a normative description of the XML and making the
>>> schema only informative.
>>>
>>
>> Personally, I find RFC 5023 approach, like the XOPEN object descriptions
>> it's
>> similar to, to be almost totally unreadable. Maybe it's the only
>> reasonable way
>> to do it when the element structure is quite complex, but that's not the
>> case
>> here.
>>
>
> Speaking as an individual: I tend to agree with Ned here. I prefer having
> some formal syntax for defining XML + some examples demonstrating different
> Sieve features.
> I think adding a descriptive definition of XML is a fair bit of work for
> little gain. However, I would not oppose to having some descriptive
> definition (which I think should be informative), especially if somebody
> suggests some text ;-).

(i'm unlikely to contribute to a flawed specification unless there is
some hope that it will be fixed)

using XML Schema as the formal definition means that decisions have to
be taken which are forced by the language which would not be required
by an alternative formal method.

1. a decision will be needed to either use the default namespace or
another namespace. this will mean either sacrificing user who are
still using parsers from the 1990s or sacrificing those who need
explicit namespacing.

2. a decision will also need to be taken about the mixture of domains.
mixing sieve with annotations about sieve means that the schema has to
be edited (to separate these concerns) before being used in modern
generators. unless this is supported at least implicitly by the
specification, it just means that an alternative specification will be
needed for these use cases.

ATM lack of namespace support and a failure to separate the concerns
in the design of schema means that the specification is useless to me
and many other developers using modern, namespace aware tools. by
applying methods used in other RFCs facing these issues, it should be
possible to create a specification suitable for both legacy and modern
tooling.

- 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 n01Jxv8n096141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2009 12:59:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n01JxvQm096140; Thu, 1 Jan 2009 12:59:57 -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 n01Jxorl096130 for <[e-mail]>; Thu, 1 Jan 2009 12:59:57 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 197F128C169; Thu,  1 Jan 2009 12:00:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sieve-managesieve-06.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu,  1 Jan 2009 12:00:02 -0800 (PST)
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           : A Protocol for Remotely Managing Sieve Scripts
	Author(s)       : A. Melnikov, T. Martin
	Filename        : draft-ietf-sieve-managesieve-06.txt
	Pages           : 50
	Date            : 2009-01-01

Sieve scripts allow users to filter incoming email.  Message stores
are commonly sealed servers so users cannot log into them, yet users
must be able to update their scripts on them.  This document
describes a protocol "ManageSieve" for securely managing Sieve
scripts on a remote server.  This protocol allows a user to have
multiple scripts, and also alerts a user to syntactically flawed
scripts.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-managesieve-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-ietf-sieve-managesieve-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--