Subject: Are extension names case insensitive

From: Gisle Aas <[email-masked]>
Date: 01 May 2003 18:36:14 -0700

I was not able to tell from RFC 3028 if the extension names provided
with the require statement are case-insensitive or not.  Should this
work?

   REQUIRE "FILEINTO";
   fileinto "FOO";

The closest thing I find is section 2.1 that says:

   Tokens in the ASCII range are considered case-insensitive.

Should strings (as the argument to require) be considered tokens in
this regard?

Regards,
Gisle Aas,
ActiveState

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: 02 May 2003 19:24:20 +0200

[Gisle Aas]:
>
>   I was not able to tell from RFC 3028 if the extension names
>   provided with the require statement are case-insensitive or not.
>   Should this work?
>   
>      REQUIRE "FILEINTO";
>      fileinto "FOO";

I'd say no.

>   Should strings (as the argument to require) be considered tokens
>   in this regard?

I agree it isn't clearly stated, but strings are called "literal
data", and you can do case sensitive matching (using the "i;octet"
comparator) on literal strings.  from this I conclude that strings
preserve case unless otherwise stated.  but then there is this tidbit:

[2.7.3 Comparators]:
|  In order to allow for language-independent, case-independent matches,
|  the match type may be coupled with a comparator name.  [...]
|
|  All implementations MUST support the "i;octet" comparator (simply
|  compares octets) and the "i;ascii-casemap" comparator (which treats
|  uppercase and lowercase characters in the ASCII subset of UTF-8 as
|  the same).  If left unspecified, the default is "i;ascii-casemap".

I find it dubious to apply this default comparator on actions where no
match type can be specified or is explicitly specified.  in other
words, I don't think it is right to say that REQUIRE has an implicit
:IS match type.

-- 
Kjetil T.

---

From: [email-masked]
Date: Fri, 02 May 2003 11:36:56 -0700 (PDT)

> I'd say no.

I'd say yes. It isn't like we're going to define FILEINTO to have a different
meaning than fileinto, so implementations get maximum interop by performing
a case-insensitive comparison in this context.

> preserve case unless otherwise stated.  but then there is this tidbit:

Case preservation does not imply case sensitivity on comparisons.

> words, I don't think it is right to say that REQUIRE has an implicit

We have case-insensitive tokens and string comparisons are case-insensitive
by default. I'm sorry, but what's dubious is the assrtion that require should
be case-sensitive.

				Ned

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: 02 May 2003 22:17:43 +0200

[Ned Freed]:
>
>   [Kjetil Torgrim Homme]:
>   > [Gisle Aas]:
>   > >   Should this work?
>   > >
>   > >      REQUIRE "FILEINTO";
>   > >      fileinto "FOO";
>   >
>   > I'd say no.
>   
>   I'd say yes. It isn't like we're going to define FILEINTO to have
>   a different meaning than fileinto, so implementations get maximum
>   interop by performing a case-insensitive comparison in this
>   context.

but an implementation that allows that will create an incompatibility
which didn't exist before.  or perhaps it already exists?  Cyrus does
case-sensitive comparison on the capability string.  (added whitespace
also makes the comparison fail.)

  line 1: unsupported feature

what do others do?

>   Case preservation does not imply case sensitivity on comparisons.

agreed, I only showed that literal strings in Sieve preserve case.

the question is whether a match is implied.

>   We have case-insensitive tokens and string comparisons are
>   case-insensitive by default. I'm sorry, but what's dubious is the
>   assrtion that require should be case-sensitive.

how about FILEINTO itself?  the folder name is case sensitive in IMAP
(with the exception of the prefix "INBOX").  shouldn't Sieve do
case-insensitive matching on existing folders to find the correct one,
and then store into it?

if "INBOX.foo" exists and you do FILEINTO "Inbox.Foo", Cyrus will file
the message into "INBOX".

-- 
Kjetil T.

---

From: [email-masked]
Date: Fri, 02 May 2003 13:57:14 -0700 (PDT)

> which didn't exist before.

Incompatible only in the sense that something that has only one reasonable
interpretation wasn't interpreted in a reasonable way.

> or perhaps it already exists?  Cyrus does

And my implementation does it in a case-insensitive fashion. And I have
seen scripts written that take advange of this fact.

I see no reaosn to expect that added whitespace would be allowed, however.

> case-insensitive matching on existing folders to find the correct one,

That would depend on the characteristics of the underlying store. IMAP allows
for either case-sensitive or case-insensitive names. It is even possible for
the same IMAP server to handle different parts of its folder namespace in
different ways.

The way this should work is that sieve should act in a case-preserving fashion.
Once the message hits the message store the rules for folder name in that store
should apply. 

There's also the issue of internationalized mailbox names. The IMAP
specifications defines a modified form of UTF-7 for this. Sieve, on the other
hand, uses UTF-8. A case-preserving conversion from UTF-8 to modified UTF-7
is therefore appropriate in some cases.

Command arguments are a very different matter than command names. There is a
lengthy tradition in the IETF of treating command names and capability strings
and so on in a case-insensitive fashion. The exact opposite is true of
arguments: They need to preserve case, and if appropriate act in a
case-sensitive fashion. 

> the message into "INBOX".

A perfectly reasonable action on its part INO. Another reasonable alternative
would have been to create the folder "Inbox.Foo".

				Ned

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: 03 May 2003 01:49:02 +0200

[Ned Freed]:
>
>   > but an implementation that allows that will create an
>   > incompatibility which didn't exist before.
>   
>   Incompatible only in the sense that something that has only one
>   reasonable interpretation wasn't interpreted in a reasonable way.

hah! :-)

to answer Gisle's question, though: a Sieve generator needs to use the
lower case capability string, simply due to the sizable market
penetration of Cyrus.  a Sieve processor should do case-insensitive
matching.

>   Command arguments are a very different matter than command
>   names. There is a lengthy tradition in the IETF of treating
>   command names and capability strings and so on in a
>   case-insensitive fashion. The exact opposite is true of arguments:
>   They need to preserve case, and if appropriate act in a
>   case-sensitive fashion.

this is an argument I accept, but I won't accept that the wording in
the Sieve RFC mandates this.  luckily, this isn't a big problem, I
can't think of any actions other than REQUIRE and FILEINTO which are
affected by this.  going quickly through the drafts: INCLUDE might use
a note about this issue; NOTIFY is explicit on :id but not :method;
IMAPFLAGS is constrained by IMAP, but doesn't state the case
sensitivity explicitly; RELATIONAL is OK, since literal strings in
ABNF are case-insensitive.

(it seems to me it would have been better to use tags rather than
strings as capability identifiers.  that would restrict the allowable
names nicely.  water under the bridge, anyhow.)

>   > if "INBOX.foo" exists and you do FILEINTO "Inbox.Foo", Cyrus
>   > will file the message into "INBOX".
>   
>   A perfectly reasonable action on its part INO. Another reasonable
>   alternative would have been to create the folder "Inbox.Foo".

yes, that was my point.

-- 
Kjetil T.