I-D Action:draft-ietf-sieve-managesieve-06.txt

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.

_______________________________________________

Re: draft-freed-sieve-in-xml status?

On Mon, Dec 29, 2008 at 8:26 AM, Alexey Melnikov
<alexey.melnikov <at> isode.com> 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

Re: draft-freed-sieve-in-xml status?

On Sun, Dec 28, 2008 at 10:31 PM, Ned Freed <ned.freed <at> mrochek.com> wrote:
>
>> On Sun, Dec 14, 2008 at 9:59 PM, Ned Freed <ned.freed <at> mrochek.com> wrote:
>> >> On Sun, Dec 14, 2008 at 6:06 PM, Ned Freed <ned.freed <at> mrochek.com> 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.

Re: draft-freed-sieve-in-xml status?

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

Re: draft-freed-sieve-in-xml status?

Re: draft-freed-sieve-in-xml status?

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

Re: draft-freed-sieve-in-xml status?

Re: draft-freed-sieve-in-xml status?

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

Re: draft-freed-sieve-in-xml status?

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.

Re: draft-freed-sieve-in-xml status?

> 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