I think we agreed previously that 3028bis should be more explicit about
the meaning of wildcards in the argument to :matches. I think it is
non-controversial, though, nobody would expect "abc" to match "b*".
That's a good example, thanks :o)
I would prefer the list of supported header names was explicit, though,
so that the extension could do the relevant decoding for the user.
notice that I omitted the number suffix for header.date, since RFC 2822
explicitly says there should be 1 and only 1 "Date" header.
But all headers are subject to RFC2047 and unwrapping aren't they? If we
explicitly list all headers available in the header scope, then that means
when somebody decides to use a new X- header or something like that, then
they would need to write their own Sieve extension to make it available in
the/another namespace. This sounds overburdensome to me. While I recognise
that the standard says that there are limits on certain headers like the
Data header, I think I'd much rather have the header "namespace" or array or
whatever generically hold all 2822 headers.
If there is some extra parsing or meaning to a particular header, then I
could see we could define a new namespace to access the headers in the more
specific way with access to the more specific parsing. Perhaps:
headers.content-type = "TEXT/PLAIN; charset=Windows-1252"
mimeheaders.content-type.type = "TEXT"
mimeheaders.content-type.subtype = "PLAIN"
mimeheaders.content-type.charset = "Windows-1252"
> I think it preferable to allow array syntax instead of variables
> starting with numbers.
I'm afraid I don't see that happening, the variables draft is too close
publication for such a change to the syntax.
So you are saying you'd prefer us to publish variables, then later realise
we needed this and have to have another standard or revision to allow us to
use array notation? I guess this is heading in the direction of Mark's
comments, now it seems we are talking about "stringvariables" not really
generic variables which will meet all the languages needs.
I suppose I was hoping to hear some technical reasons for why we wouldn't
want [] and rather have a completely non standard way of providing access to
what is really an array.
> If we were to do this then where would such a mechanism be specified?
> 3028bis, variables, new draft? I'd love it to be available in the
> variables spec...
the namespace feature of the variables draft was specifically added to
allow independent extensions to add "magic" variables.
Perhaps if we groups several generic namespaces together which apply to all
messages then we'd have enough for another spec. Perhaps headers, envelope,
message, server? It seems to be an excellent addition to the variables
extension if you ask me, but I recognize that this would all take a while to
hammer out. I just hope we don't go with a variables spec which limits our
choices when we get there :o(
Nigel