[Top] [All Lists]

Re: Support for encoded-character

2007-04-05 10:42:15

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.

I think that's good enough then - the inference is clear.


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