On Sun, 2005-04-24 at 15:07 +0100, Alexey Melnikov wrote:
Hi group,
I would like to solicit some comments on the last remaining issue in the
Sieve variables draft.
The latest version of the document prohibits all numeric second (and
lower) level namespaces, e.g. a variable name "foo.1.3" is not legal.
My personal opinion (chair hat off) is that we should allow for such
variable names, just in case we later on decide to allow variable names
based on MIME part numbering, or something similar. Does anybody have
any opinion in support or against this change?
sorry to go off on a tangent, but going over the text again, I realised
that the draft has no actual connection between the term "numbered
variable" and the "num-variable" syntax element. I therefore added the
following to clarify:
3.2. Numbered variables
A "numbered variable" has a name consisting only of decimal digits
and has no namespace component.
another issue is what to do about unknown namespaces. the current draft
is actually silent, so I'd say this applies: "Unknown variables are
replaced
by the empty string." that is bad, IMHO. I suggest an addition to
section 3:
Namespaces are meant for future extensions which make internal state
available through variables. These variables SHOULD be put in a
namespace with the same name as its capability string. Notice that
the user can not specify a namespace when setting variables with SET.
+ References to namespaces without a prior require statement for the
+ relevant extension MUST cause a syntax error.
the other option is to leave the variable reference unexpanded, the same
way "${foo,bar}" is. that's fine, too, but I think users will prefer
the error (typo) to be flagged.
--
Kjetil T.