Re: 'header' test and whitespace

[Michael Haardt <michael@xxxxxxxxxxxxx>]

> > > I am personally Ok with adding :raw to the base spec, but do we need a
> > > new capability?
> > 
> > Yes, I'm afraid so. Perhaps something like rawheader? (I believe the header
> > test is the only one for which :raw makes sense.)
>
> what happens if you add a :raw argument and upload to today's
> implementations?  will they reject during upload?  will they ignore it
> during runtime?  will they bomb during runtime?

Adding something completely new like that sounds like a typical extension
to me, and indeed a rawheader test may be a better way than adding a flag.

When I mentioned it, all I wanted was to make sure we don't put something
in the way of being able to create that extension.  I don't know if
anybody will ever specify it, but I feel we should be able to, should
the need arise.

> the behaviour of "header" is under-specified in the current spec, and
> deployed implementations probably deviating behaviour.  the more
> detailed specs we're discussing here might make many of them obviously
> non-conforming where they were only arguably non-conforming before (i.e.
> not performing according to intent).  but is it important?  the number
> of capabilities makes life harder for both server and client
> implementors, and we should try to limit the number of them as much as
> possible.

Current implementations probably specify conforming to RFC 3028,
and that is not going to change.  RFC 3028 gives too much freedom,
mostly not intentionally, and that's a problem.  Most implementations
probably need minor tweaks to conform to the new standard, and they
will still conform to RFC 3028.  Nobody likes changes, but everybody
asks for interoperability.  In this case, it's a small price to pay.

The number of extensions is a problem indeed, because they reduce
interoperability.  But if you required a "full" implementation on systems
that currently offer only a minimal implementation, perhaps they wouldn't
be using Sieve at all, being even less interoperable.

Michael