Subject: draft-homme-sieve-variables-03.txt

From: Tony Hansen <[email-masked]>
Date: Wed, 11 Aug 2004 11:21:26 -0400

It says this:

    This extension changes the semantics of quoted-string, multi-line-
    literal and multi-line-dotstuff found in [SIEVE] to enable the inclu-
    sion of the value of variables.  The syntax follows [ABNF].

but never gives the redefined ABNF for quoted-string, multi-line-literal 
nor multi-line-dotstuff.

Nits below.

	Tony Hansen
	[email-masked]

201c201
<    scripts which include a require clause for the "variables"
<    extension.
---
 >    scripts that include a require clause for the "variables"
 >    extension.
242c242
<    When the string is evaluated, substrings matching variable-ref
<    shall
---
 >    When the string is evaluated, substrings matching variable-ref
 >    SHALL
244c244
<    string shall be done.  Variable names are case insensitive.
---
 >    string SHALL be done.  Variable names are case insensitive.
407c407
<    stops.  Variable names are case insensitive.
---
 >    stops.  Variable names are case insensitive, so ${foo} and ${FOO}
 >    refer to the same variable.
437c437
<    Modifiers are applied on value before it is stored in the variable.
---
 >    Modifiers are applied on a value before it is stored in the
 >    variable.
463,466c463,466
<       set :length "var" "${var}";            => "15"
<       set :lower "var" "${var}";             => "jumbled letters"
<       set :upperfirst "var" "${var}";        => "JuMBlEd lETteRS"
<       set :upperfirst :lower "var" "${var}"; => "Jumbled letters"
---
 >       set :length "var2" "${var}";            => "15"
 >       set :lower "var2" "${var}";             => "jumbled letters"
 >       set :upperfirst "var2" "${var}";        => "JuMBlEd lETteRS"
 >       set :upperfirst :lower "var2" "${var}"; => "Jumbled letters"
473c473
<    The value is the decimal number of letters in the expansion,
---
 >    The value is the decimal number of characters in the expansion,
578,580c578,579
<    When numbered variables are used, strings can contain arbitrary
<    values controlled by the sender of the e-mail if the author of the
<    script isn't careful.
---
 >    When numbered variables are used, and the author of the script
 >    isn't careful, strings can contain arbitrary values controlled by
 >    the sender of the e-mail.

---

From: [email-masked]
Date: Wed, 11 Aug 2004 09:34:12 -0700 (PDT)

> but never gives the redefined ABNF for quoted-string, multi-line-literal

I don't get this at all. Why would redefining the _semantics_ of something
change its _syntax_? Not only do I thini redefning the syntax of the things you
list is unnecessary, I view it as quite harmful and I strongly oppose adding
it. I base this on having had to deal with similar "overlapped" syntax in the
MIME draft, which ended up causing lots of confusion and no enlightenment.

Perhaps the problem is the trailing statement referring to [ABNF]. This could
be moved to a separate section if it is confusing for it to be there.

> Nits below.

The fixes for the nits look fine to me.

				Ned

---

From: Tony Hansen <[email-masked]>
Date: Wed, 11 Aug 2004 17:25:22 -0400

[email-masked] wrote:

> I don't get this at all. Why would redefining the _semantics_ of
> something change its _syntax_? Not only do I thini redefning the
> syntax of the things you list is unnecessary, I view it as quite
> harmful and I strongly oppose adding it. I base this on having had to
> deal with similar "overlapped" syntax in the MIME draft, which ended
> up causing lots of confusion and no enlightenment.
> 
> Perhaps the problem is the trailing statement referring to [ABNF].
> This could be moved to a separate section if it is confusing for it
> to be there.

Okay, I guess my problem is that I was thinking it really changed the 
syntax. When I was reading it, and looked at the definition of 
quoted-string, etc., I thought "doesn't this mean that quoted-string 
needs to change to

	 quoted-string = DQUOTE *(CHAR / "${" *(DIGIT / LETTER) "}")
			 DQUOTE

?"

But if you want to treat the parsing of the string separately from the 
language parsing, then I guess it really does mean that only the 
semantics is changing, and hence, no ABNF changes are required.

At this point, I'll just say "it can be done either way" and forego any 
further comment.

	Tony Hansen
	[email-masked]

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 12 Aug 2004 11:22:39 +0200

> but never gives the redefined ABNF for quoted-string, multi-line-literal 

my very first draft (not submitted) tried to make a change to the
syntax, but it was pointed out on this list that it was ambiguous:
*CHAR expands to valid variable references.  I tried to rewrite the
syntax to avoid the problem, but it got really convoluted.  list
consensus at the time was to leave the syntax alone and change the
semantics.  this also mimics the natural way of implementing the
extension, IMHO.

I do agree the wording in that paragraph is a little confusing, though.
perhaps it's better to put the grammar _below_ the explanation of the
procedure.  also, the reference to [ABNF] is a better fit in the
conventions paragraph in the introduction:

    Conventions for notations are as in [SIEVE] section 1.1, including
-   use of [KEYWORDS].  In this document, "character" means a [UNICODE]
+   use of [KEYWORDS] and [ABNF].  In this document, "character" means a

my copy now says:

3.  Interpretation of strings

   This extension changes the semantics of quoted-string, multi-line-
   literal and multi-line-dotstuff found in [SIEVE] to enable the inclu-
   sion of the value of variables.

   When a string is evaluated, substrings matching variable-ref shall be
   replaced by the value of variable-name.  Only one pass through the
   string shall be done.  Variable names are case insensitive, so "foo"
   and "FOO" refer to the same variable.  Unknown variables are replaced
   by the empty string.

      variable-ref        =  "${" variable-name "}"
      variable-name       =  num-variable / *namespace identifier
      namespace           =  identifier "."
      num-variable        =  1*DIGIT

   Examples:
      [...]

>  >    When the string is evaluated, substrings matching variable-ref

is it appropriate to use these capitalised forms everywhere?  if so,
this should(!) be a MUST.

> <    stops.  Variable names are case insensitive.

hmm, a little duplication.  I guess it doesn't hurt to point it out
twice, though.

thank you for your nits, with the exception of SHALL, they have been
incorporated in my copy.

-- 
Kjetil T.

---

From: Tony Hansen <[email-masked]>
Date: Thu, 12 Aug 2004 10:28:09 -0400

Kjetil Torgrim Homme wrote:

> ...
> ...

looks good

> this should(!) be a MUST.

SHALL and MUST are equivalent in strength. See [KEYWORDS].

	Tony Hansen
	[email-masked]

---

From: [email-masked]
Date: Thu, 12 Aug 2004 07:32:54 -0700 (PDT)

> syntax to avoid the problem, but it got really convoluted.

Exacly. I ran into the same thing in MIME when I tried to fix the
ABNF there that did this. The solution was to dump it all. I don't
believe I've seen a single complaint that this was done.

> list

Given the recent addition of text making it clear extensions may need
access to unexpanded parameters, it is pretty much the only way to
implement it.

> +   use of [KEYWORDS] and [ABNF].  In this document, "character" means a

Much better.

>    Examples:

This sounds fine to me.

				Ned

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 12 Aug 2004 18:46:46 +0200

> SHALL and MUST are equivalent in strength. See [KEYWORDS].

doh!

but I still think it makes the text needlessly formal.

        When a string is evaluated, substrings matching variable-ref
        shall be replaced by the value of variable-name.  Only one pass
        through the string shall be done.

consider a rewrite such as

        When a string is evaluated, substrings matching variable-ref are
        replaced by the value of variable-name.  The string is only
        passed through once.

is this text less binding for the implementor?

sorry about the stylistic quibbling, I'm just curious.
-- 
Kjetil T.

---

From: Tony Hansen <[email-masked]>
Date: Thu, 12 Aug 2004 13:05:09 -0400

> sorry about the stylistic quibbling, I'm just curious.

I think the formality is necessary. Consider this:

     When a string is evaluated, substrings matching variable-ref
     MUST BE replaced by the value of variable-name.  The string
     MUST BE passed through exactly once.

	Tony Hansen
	[email-masked]

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 12 Aug 2004 20:34:12 +0200

>      MUST BE passed through exactly once.

okay, but I stuck to your first patch, only changing "shall" into
"SHALL" :-)

-- 
Kjetil T.

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 12 Aug 2004 14:42:35 -0400

Hi Kjetil,

> okay, but I stuck to your first patch, only changing "shall" into

I think it has to be a MUST - we can't allow implementations to ignore 
variables when they are actually used!

-- 
Cyrus Daboo

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 12 Aug 2004 20:46:23 +0200

On Thu, 2004-08-12 at 14:42 -0400, Cyrus Daboo wrote:
> Kjetil Torgrim Homme <[email-masked]> wrote:
> 

I'm kind of glad to see it's not only I who misremembers [KEYWORDS] :-)

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

-- 
Kjetil T.

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 12 Aug 2004 15:02:00 -0400

Hi Kjetil,

>    definition is an absolute requirement of the specification.

I guess I read SHALL as SHOULD. As a quick (pointless) exercise I just 
grep'd my entire rfc document cache looking for MUST and SHALL (without 
double-quotes around them) and got:

MUST  - 28010
SHALL -  1777

Somehow MUST seems much more of an imperative to me than SHALL...

-- 
Cyrus Daboo