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 2.4.2.4. (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, 2.4.2.4 specifically notes that encoded-character processing
happens after dot-unstuffing, which only applies to text: blocks.
Philip Guenther