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

Poll: consensus to change the encoded-character extension

2007-04-10 10:20:58

Ned Freed wrote:

yes.  whitespace is only allowed between hex-pairs.  btw, how do you
feel about allowing CRLF as well as SPC and TAB between hex-pairs?
Is CRLF allowed inside other ${} expressions (variables)?
variables doesn't allow any whitespace at all.
Hmm, right, variables contain no arguments and we don't have functions
yet.  Thinking about string expressions, I certainly would like to
have CRLF as white space, but I also would like embedded comments in
that case.
I would like to allow CRLF but comments IMO go way too far.
From my reading of the mailing list it sounds like there is consensus to do the following change:

OLD:
  encoded-arb-octets   = "${hex:" hex-pair-seq "}"
  hex-pair-seq         = hex-pair *(WSP hex-pair)
                                    ^^^
NEW:
  encoded-arb-octets   = "${hex:" hex-pair-seq "}"
  hex-pair-seq         = hex-pair *(LWSP hex-pair)
                                    ^^^^

OLD:
  encoded-unicode-char = "${unicode:" unicode-hex-seq "}"
  unicode-hex-seq      = unicode-hex *(WSP unicode-hex)
                                       ^^^
NEW:
  encoded-unicode-char = "${unicode:" unicode-hex-seq "}"
  unicode-hex-seq      = unicode-hex *(LWSP unicode-hex)
                                       ^^^
  unicode-hex          = 1*6HEXDIG


And this needs to be updated if people want to allow for trailing LSWP (before the closing "}")

The argument for allowing CRLF is that it is really needed to allow reasonable
formatting of long runs of hex-encoded stuff. If, say, you want to write a few
hundred bytes worth of material, with the current proposal you either have to
put it all on one line, hope you can find a CRLF in there that you can leave
unencoded and thus create a line break (unlikely), or use a series of set
actions to build up the string piecemeal (ugly and requires variables support).

The same cannot be said of comments - you are free to put one in front of the
string or at the end and end up with something that's readable. Of course I
suppose you could argue that there are cases where it is clearer to have the
comment in the middle, but I have to say I find that to be a fairly contrived
case.
I don't think we have consensus to allow for comments.

 Just looking at encoded-character, I see no need for CRLF