Subject: Re: Support for encoded-character

From: Ned Freed <[email-masked]>
Date: Sun, 01 Apr 2007 18:05:31 -0700 (PDT)

> Aaron Stone wrote:

> >After the Sieve interop yesterday evening sort of crumbled over
> >encoded-char, I implemented the hex side of things for libSieve.
> >
> >I also noticed that in 2038bis-12, 2.4.2.4, the sentence:
> >
> >   In the following script, message A is discarded, since the specified
> >   test string is equivalent to "$$$".
> >
> >...should refer to 'message B'.
> >
> >
> Indeed. I've sent Lisa/Chris a note saying that this needs to be fixed
> before publication.

Another issue I recently noticed about encoded-character refers to the WSP
production but does not define it. I don't see it defined or referenced
anywhere else in the specification either. Perhaps this should be changed to
white-space, which is defined?

				Ned

---

From: Philip Guenther <[email-masked]>
Date: Mon, 2 Apr 2007 12:56:35 -0600

On Sun, 1 Apr 2007, Ned Freed wrote:
...
> white-space, which is defined?

No, not unless you really think we want this:

"${unicode:110 /* a comment with a close brace } */ 69}"

to be an encoding of "Hi".

WSP is defined in the ABNF "Core rules" which are assumed as the base of 
all the ABNF snippets in 3028bis (c.f., DIGIT, CRLF, etc).

Philip Guenther

---

From: Ned Freed <[email-masked]>
Date: Mon, 02 Apr 2007 13:52:54 -0700 (PDT)

> all the ABNF snippets in 3028bis (c.f., DIGIT, CRLF, etc).

Sorry, missed that was one of the core rules. But that makes me wonder if LWSP
wouldn't be more appropriate...

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.

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?

				Ned

---

From: Philip Guenther <[email-masked]>
Date: Mon, 2 Apr 2007 23:36:26 -0600

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...)

> 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

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 04 Apr 2007 03:46:54 +0200

> script without including the CRLF in the string's value.  Hmm.

that could be useful, I guess, although I personally would have
preferred adopting the common convention of ending lines with backslash
if we need this capability.  sneaking it in through encoded-character is
probably easier, though.
-- 
Kjetil T.

---

From: Ned Freed <[email-masked]>
Date: Thu, 05 Apr 2007 10:20:09 -0700 (PDT)

> happens after dot-unstuffing, which only applies to text: blocks.

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

				Ned

---

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 6 Apr 2007 11:11:55 -0400

> if we need this capability.  sneaking it in through encoded-character is

FWIW, I agree with the LWSP - I don't see any reason to have to escape
any line endings inside of an encoded-character block when it should be
fairly evident that nobody would want to preserve the CRLF there anyway.
Make it easy to compose the strings, and less easy to make errors.

mm  (IMHO)