Re: document status: 3028bis, body, editheader

On Wed, 2006-03-22 at 16:12 -0800, Ned Freed wrote:
> > I find the description of the awkwardness of "\\" highly amusing
> > juxtaposed with the requirement of all tests in Sieve[1] to have the
> > argument :comparator "i;basic;uca=3.1.1;uv=3.2" (and the matching
> > "require" statement).
> One man's meat is another man's poison... There are plenty of scripts that
> depend on comparators continuing to work the way they always have.
that doesn't mean we can't find a better way than the above.

I thought Dave Cridland's suggestion to specify matching behaviour in
the comparator itself was intriguing:

http://permalink.gmane.org/gmane.ietf.mta-filters/2689

unfortunately, [draft-newman-i18n-comparator-08] says «the equality test
MUST be reflexive, symmetric and transitive», so "EQUAL" can't be used.
I must admit I don't quite understand how :matches and :regex work with
comparators, though.

another possibility is to have a capability which adds an action which
changes the default comparator to reduce the verbosity.

another possibility is to allow the wildcard comparator, so
that :comparator "*" «[selects] the collation with the broadest scope
(preferably international scope), the most recent table versions and the
greatest number of supported operations.»  (the comparators the server
chooses from would have to be "require"d in advance, I think, although
«require "comparator-*"» is a possibility)

> > to be honest, I find it absurd that such verbiage
> > is forced upon users.  we need to find a better way.
> > [1] outside of the US of A, anyway.
> This has nothing to do with geography and everything to do with backwards
> compatibility. Some of the scripts I'm referring to were written and are used
> outside the US.
>
> And good luck using i;basic;uca=3.1.1;uv=3.2 to trap specific sequences of
> illegal 8bit in headers. Such stuff is rarely if ever in UTF-8, in my
> experience at least.
this is impossible today, isn't it?  how do you specify the string to
compare with?  in any case, if you want to trap raw non-UTF8 in headers,
you should use i;octet.  but then again:

5.7.  Octet Collation

   The i;octet (Section 9.5) collation is only usable with protocols
   based on octet-strings.  Clients and servers MUST NOT use i;octet
   with other protocols.

which would disqualify the use of i;octet with Sieve, since 3028bis says:

   The language is represented in UTF-8, as specified in [UTF-8].

the collation-draft exempts RFC 3028 from this "MUST NOT", but it's not
clear to me that a 3028bis can get the same exemption.  notice that
"represented in UTF-8" only means constant strings can't contain raw
octets which are illegal UTF-8 sequences.  which brings us back to the
discussion on character escapes from a year ago.

http://comments.gmane.org/gmane.ietf.mta-filters/2030

I'd like to suggest we implement (2), but with the extension defined in
the base spec.  note that if the base spec adds the restriction on
extensions that they can't modify other "require" statements, the
analysis of string escapes can be performed statically by a byte
compiler.
-- 
Kjetil T.