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