ietf-mta-filters
[Top] [All Lists]

Re: The last remaining issue in the Sieve variables draft

2005-04-26 05:21:34

I'd really rather they just expose the one.  The extension can then
detail which if any varaibles in the namespace are writable.

exactly.  I don't think the wording restricts this?

I guess it doesn't restrict it, but it does discourage it, and I don't think it should be discouraged in the way it currently does. I'd be happier we we said:

-   Such extensions SHOULD state whether its namespace is modifiable with
-   the "set" action.
+ Such extensions SHOULD state which if any of the variables in its namespace
+  are modifiable with the "set" action.

> there's no namespace for numbered variables, so I don't think it is
> redundant.

You are saying that an extension may expose a namespace, and that
namespace may itself contain numbered variables can't it?

no, my current copy includes this definition:

  A "numbered variable" has a name consisting only of decimal digits
  and has no namespace component.

Ok I checked draft-ietf-sieve-variables-02.txt before I posted and didn't see a mention about this. I don't think you should say that. I don't see why numbered varaibles shouldn't have a namespace component. What if we decide to expose the mime structure in variables? Surely we'll want numbered variables?

the term "numbered variable" is restricted to the magic match variables.
perhaps I should replace the term with "match variable" -- might be less
confusing?

Well I've been thinking of Alexey's example:

SET "annotate.body.2.1" "\\Seen";

I thought he'd used numbered variables with the SET action, so whatever we do, we really ought to permit that kind of thing if the annoate extension or some other such extension wishes it.

Why can't we just detail that the numbered varaibles made available as a side effect of using matches or regex are read only rather than saying that all numbered variables can not be set? I guess if you want to introduce/replace with the term "match variables" then that should give the clarity and freedom I'm hoping for :o)

So that extension will also detail if it's variables are writable.
Hence why can't a new extension expose a namespace containing writable
numbered variables?

they can expose writable variables with all-digit name components.

Ok good :o) It's definately seems to be a terminology issue then, cos we have num-variable defined in draft-ietf-sieve-variables-02.txt by:

     variable-ref        =  "${" *namespace variable-name "}"
     variable-name       =  num-variable / identifier
     namespace           =  identifier "."
     num-variable        =  1*DIGIT

Yet when I hear "Numeric Variables", I think it's a variable-ref with a variable-name which is a num-variable.

Nigel