Re: [sieve] Notify (RFC 5435) questions

[[e-mail]]

> On Tue, Sep 29, 2009 at 8:55 AM, Barry Leiba
> <[e-mail]> wrote:
>  [...]
> > I agree that it'd be better to put it into the variables spec.  You
> > know I'm not suggesting going through everything to say where you can
> > and can't do variable substitution; you should know me better than
> > that.  But Hannah has a point: the variables spec says this:
> >
> >   This extension changes the semantics of quoted-string, multi-line-
> >   literal and multi-line-dotstuff found in [SIEVE] to enable the
> >   inclusion of the value of variables.
> >
> > ...and the grammar for "importance" uses none of those three syntax
> > constructions.  Taken at its word, that would imply that variable
> > substitution doesn't apply here.

> I am fine with this being reported as an Erratum. Do you want to do that?

I'm not fine with it and don't want to do it. Again, this is a slippery slope.
We have any number of specifications: relational (:count, :value), imapflags
(list-of-flags), and date (:zone, :originalzone) to name a few which, like
notary, use an overlay ABNF syntax to further restrict the allowed values of a
partameter and which have the same "problem" you cite here. If we're to
"correct" this "error", we need to "correct" all the others, and it places yet
another silly requirement on future specifications that do this.

I will also point out that it isn't even necessary for ABNF to be involved.
This overly creative reading (and like it or not, that's what it is) of syntax
restriction could be extended to other paramters whose syntax is restricted in
other ways, such as date-part values in the date extension, the reason value in
the vacation extension, and so on.

Look, I get that overlay syntaxes are inherently subject to this sort of
confusion. It's why got rid of all of them from MIME in the transition from RFC
1521 to RFCs 2045 and 2046. The diffference is in MIME the overlay syntaxes
turned out not to be essentially useless. THis is not the case in Sieve.

Again, the place to deal with this is in the variables specification. Something
along the lines of "specifications for other Sieve extensions may employ ABNF
or other syntax specification tools to restrict the allowed values of certain
strings. When this is done it doesn't imploy that variable substitutions cannot
take place. Rather, the ability for variable substitution to occur is linked to
the string's role in the core Sieve grammer specified in RFC 5228". I can
support this sort of erratum.


> > We might change RFC 5229 to add that
> > variables can substitute for literal strings as well.  Or we might
> > decide that it's clear enough, and doesn't need changing.

I don't know what you mean by "literal string" here, so I don't know
what purpose, if any, this serves.

				Ned