[Top] [All Lists]

Re: Support for encoded-character

2007-04-02 22:48:52

On Mon, 2 Apr 2007, Ned Freed wrote:
Sorry, missed that was one of the core rules. But that makes me wonder if LWSP wouldn't be more appropriate...

That's an interesting idea, as it would let you 'wrap' a string in the script without including the CRLF in the string's value. Hmm.

We also have a card-before-the-horse problem, in that we don't refer to the use of ABNF for defining our grammars until section 8.1 but the ABNF for encoded-character is in (Well, to be fair, we do mention ABNF in the conventions section, but only to compare it to how Usage: statements are constructed.) The customary way to do this is to put the reference to ABNF in the conventions section. I can understand not bothering when ABNF was only used in one place, but that's no longer true.

True. There's also no real explanation of the "Syntax:" lines that 'define' MATCH-TYPE, COMPARATOR, and ADDRESS-PART, although real ABNF for those is included in section 8.2. <sigh> Perhaps this should be dealt with by
(1) including a specific statement in section 1.1 that ABNF is used for
    other syntax specifications in the body of the text, and
(2) replacing those "Syntax:" lines with their actual ABNF versions.

(This is turning into a long RFC editors note. It's feeling like I should pull together the changes and submit a new rev...)

Finally, I wonder if we should be explicit about how encoded-character
constructs interact with text: blocks. My reading is that they should work.
Does everyone else agree?

      If it's a string, then encoded-character affects its interpretation.
      text: blocks are strings.
MPP   The interpretation of text: blocks is affected by encoded-character

In addition, specifically notes that encoded-character processing happens after dot-unstuffing, which only applies to text: blocks.

Philip Guenther

<Prev in Thread] Current Thread [Next in Thread>