Michael Haardt wrote:
Do implementations have to support encodings of NUL ala ${hex:0}? If so,
that will be a barrier to this extension being broadly supported.
(I think it should be a "MAY support".)
Note that =00 in quoted printable has to be dealt with already.
An implementation that uses nul-terminated strings is already broken
and things will not get worse using an encoded NUL character in a string.
Right.
Which comes first, encoding replacement or variable expansion? Or are
they concurrent? Whatever the answer, the variables I-D will need to make
that clear.
(I think encoding replacement should come before variable expansion.)
I think they should be processed inside-out, but not in separate
passes. Variables introduce of the concept of strings (aka test
and action arguments) not being literals, but string expressions that
are evaluated. It makes sense that arguments of string functions
turn from literals to string expressions, too.
As a result, without variables, "${hex:${hex:4646}}" is a syntax error.
With variables, it is "FF".
I disagree. I think encoded-octet and variables should be independent
extensions.
Speaking as implementor I am more likely to implement encoded-octets first.
The next rev of the base-spec includes this:
Extensions MUST NOT change the behavior of the "require"
control command.
I believe that means that this extension can't be used in the capability
argument to 'require', so there's at least one place where Unicode
characters can't be encoded using ${unicode:...}.
That's right. The require argument can not contain variables either,
and I consider that a good thing [tm].
Agreed.