[Fwd: I-D Action:draft-george-sieve-autoreply-00.txt]

Robins and I wrote a draft about using auto responders with presence 
tests and external lists. This version is quite raw, but hopefully 
people can get an idea on how various Sieve extensions can be combined 
together to satisfy use cases.

Feedback on the document would be appreciated. In particular I would 
like to know if people think that this should be an Informational 
document (as currently it doesn't define a Sieve extension), or whether 
it should be a Standard Track thing.

A New Internet-Draft is available from the on-line Internet-Drafts directories.

[Fwd: More information requested on publication status of draft-crocker-email-arch]

FYI.

From: Alexey Melnikov <alexey.melnikov <at> isode.com>
Subject: More information requested on publication status of draft-crocker-email-arch
Date: 2009-05-26 21:40:16 GMT

There have been two Last Call notices sent to the IETF for:

    'Internet Mail Architecture' <draft-crocker-email-arch> as a 
Proposed Standard

The IESG has received a concern about the intended publication status of 
this document and wishes to confirm the community's preferences.
As the shepherding AD I would like to request more feedback on this 
topic. Please send your answers by the end of June 3rd.
You can either reply to this message, send your response directly to 
iesg <at> ietf.org, or send it directly to me and Tony Hansen <tony <at> att.com>.

Please indicate your preference for publishing the document as:

    1. Proposed Standard, as queried in the two Last Call notices

    2. Informational

Questions and remarks on draft-ietf-sieve-include-01.txt

Hi,

First of all, I am very glad that the work on the specification is being 
continued now. This week I quickly updated my implementation to match 
the new specification. Merging import and export into a single global 
command is a good choice. The use of a global variable namespace is also 
a good idea (but I did not implement that yet).

During implementation I collected some remarks and questions:

- Where the ManageSieve protocol specifies what characters are allowed 
for a script name, the include extension for the Sieve language does 
not. Would it be useful to adopt the same limitations? Especially things 
like '/' can cause problems.

- For the global command I would expect text stating that the variables 
extension is required when it is used.

- The global command is required to follow 'require' or another global 
command. I am worried what happens when other extensions have commands 
with similar requirements. Shouldn't we account for this eventuality?

- Are there any special security implications for using variables in the 
value argument in the include command, i.e. to include a script 
specified by a variable? Is that even (intended to be) allowed?

- The scope of the :once modifier could be a bit confusing. I am 
assuming it holds for the whole Sieve execution and not only for the 
identical include commands within the current script.

[sieve-in-xml] Example Scripts For Integration Testing

i'm much happier with the current sieve-in-xml draft. we hope to ship
JSieve soon with experimental preview partial support with the hope
that usage by developers may help to understand whether any issues
have been missed, with a complete implementation would be targetted
for the next release.

however, to confidently ship a library claiming full support, a
reasonably large and fully debugged corpus of integration tests is
needed: basically, example sieve scripts together with corresponding
sieve-in-xml documents. IMO this is the sort of data which is usually
best developed and debugged collectively.

from the sieve working group charter:

<blockquote cite='http://www.ietf.org/html.charters/sieve-charter.html'>
(5) Produce one or more informational RFCs containing a set of test
scripts and test email messages that are to be filtered by the scripts,
and the expected results of that filtering. This will serve as the basis
of a interoperability test suite to help determine the suitability of
moving the base specification and selected extensions to Draft status.
</blockquote>

as i read this, a collection of example sieve scripts and sieve-in-xml
documents is out of scope for this group (hopefully people will jump
in if my reading is incorrect)

so, i was wondering whether there is any interest from members of the
group in collaborating offshore (http://code.google.com, say) on
creating and debugging such a corpus as an open source project under a

notify and valid_notify_method

Supposed to return true if all exist and are valid and supported and 
generally polished, and false if at least one has some imperfection.

But what if the list is empty? Sounds like a degenerate true, agreed?

Arnt

New chair: Aaron Stone

Hi all,

With Alexey stepping up as AD this month, I asked Aaron Stone to join
Cyrus in chairing this group.  He's already listed on the WG charter.

Thanks Aaron for jumping into this, and thanks Alexey for all your hard work,
Lisa

RFC 5463 on Sieve Email Filtering: Ihave Extension

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

        
        RFC 5463

        Title:      Sieve Email Filtering: Ihave Extension 
        Author:     N. Freed
        Status:     Standards Track
        Date:       March 2009
        Mailbox:    ned.freed <at> mrochek.com
        Pages:      6
        Characters: 12481
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-freed-sieve-ihave-04.txt

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

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

Sieve WG is going to need a new co-chair

Folks,
Due to the pending upgrade to IESG status, I will be stepping down as a 
Sieve WG co-chair after the San Francisco IETF.

I've talked quickly to Cyrus about that and it looks like he will need a 
co-chair.
If you know a good candidate, please let Cyrus Daboo <cyrus <at> daboo.name>, 
Lisa Dusseault <lisa.dusseault <at> messagingarchitects.com> and myself know.
Volunteering for this is also encouraged.

Thank you,
Alexey

The 2008 / 2009 IETF Nominating committee is happy to announce the
selection of individuals to serve on the IESG.

First, our thanks and appreciation to those indivudals who have served
who will not be continuing on the IESG.  Your efforts are very much
appreciated.

The appointments, which have been approved by the confirming body are:

[draft-freed-sieve-in-xml-02] Nonimating Code Components

Apologies for the lateness of this submission. Note that this is a
general issue and
no criticism of the current draft is intended.

Background
----------
1. The IETF has issued a number of documents clarifying it's positions on
   rights issues required from contributors including RFC5377, BCP78 and BCP79.
   A license policy [1] has been issued by the IETF Trust together with a
   list of standard code components [2]. Code components are made available
   under a permissive open source license categorised in the
   "Simplified BSD License" family [3]. Some rights issues still remain
   unresolved or are delegated to the appropriate working group.

2. The Apache Software Foundation requires that the rights for all
source committed
   are audited. In particular, specific checks are required for all documents
   which are not originally created by the contributor. These include
both legal
   and ethical checks. I understand that this auditing is common amongst open
   source organisations.

3. draft-freed-sieve-in-xml contains section of source including the XML Schema
   (Appendix B) and RelaxNG (Appendix C) schemata, an extended example
   (Appendix A) and a stylesheet (Appendix D).
     3A. These are likely to be generally useful to implementors of
the specification,
         educators and expert users.
     3B. Rights to create and publish derivative works are required

Re: draft-ietf-sieve-notify-sip-message

Adam Roach wrote:

> Mary Barnes has asked me to perform an expert review on 
> draft-ietf-sieve-notify-sip-message for the RAI area.

Hi Adam,
Thank you for the review and sorry for the slow response.

> Overall, the approach in the document seems good. However, there are 
> two relatively minor details that cause me some concern. I think these 
> should be rather straightforward to fix.
>
> My first area of concern is that, while this seems a reasonable way to 
> perform this functionality in SIP, I don't think it's the only 
> reasonable way to do it in SIP. Consequently, this document needs to 
> take care not to preclude future SIP mechanisms for SIEVE 
> notifications. For example, the conveyance of more semantic 
> information in a PUBLISH message would be quite useful when there is a 
> dynamically changing community of parties interested in receiving 
> notifications. (The PUBLISH would be sent to an event agent, which 
> could then receive SUBSCRIBE requests from interested parties). This 
> may be applicable, for example, when monitoring shared resources, such 
> as technical support email queues.
>
> However, the draft makes an implicit assumption that any SIEVE 
> notification method URI starting with "sip:" necessarily will make use 
> of the mechanism it defines, and never any other. There is no means 
> for disambiguating among multiple mechanisms. In fact, the draft seems 
> to go out of its way to ruin an extensibility mechanism that it would 

[draft-freed-sieve-in-xml-02] Unknown Markup

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