Subject: envelope test syntax?

From: Cyrus Daboo <[email-masked]>
Date: Tue, 11 May 2004 18:09:26 -0400

The envelope test syntax in RFC3028 is given as:

   Syntax:   envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
             <envelope-part: string-list> <key-list: string-list>

But that is different than the address test syntax:

   Syntax:   address [ADDRESS-PART] [COMPARATOR] [MATCH-TYPE]
             <header-list: string-list> <key-list: string-list>

[COMPARATOR] and [ADDRESS-PART] being switched, which seems odd for a tests 
that are so similar.

The example for the envelope test uses the same syntax as the address test.

What is the correct syntax for the envelope test? Either the example is 
wrong, or the syntax definition is wrong.

-- 
Cyrus Daboo

---

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 11 May 2004 18:43:02 -0400

> wrong, or the syntax definition is wrong.

Tagged arguments can be given in any order; my impression was that
the variations in those paragraphs simply illustrated that fact.

  From 2.6.2:

      Tagged arguments must appear before positional arguments, but
      they may appear in any order with other tagged arguments.  For
      simplicity of the specification, this is not expressed in the
      syntax definitions with commands, but they still may be
      reordered arbitrarily provided they appear before positional
      arguments.  Tagged arguments may be mixed with optional
      arguments.

  and 2.6.3:

      Optional arguments are exactly like tagged arguments except that
      they may be left out, in which case a default value is implied.

OTOH perhaps I am missing the point :-)

mm

---

From: Tim Showalter <[email-masked]>
Date: Tue, 11 May 2004 17:26:21 -0700

> [COMPARATOR] and [ADDRESS-PART] being switched, which seems odd for a 
> tests that are so similar.

This is a slight oversight.  I never noticed it because arguments may 
appear in any order.  (2.6.2 says this for tagged arguments; 2.6.3 says 
optional arguments are exactly like tagged arguments.)  Obviously this 
was not written by cut-and-paste.

I'm pretty sure I can convince myself that this is what it says, but 
then, I can probably do that for a lot of my mistakes.

I'll try to improve this part in the future.

Tim

---

From: [email-masked]
Date: Tue, 11 May 2004 21:01:57 -0700 (PDT)

> the variations in those paragraphs simply illustrated that fact.

That was my interpretation as well.

> OTOH perhaps I am missing the point :-)

Me too, perhaps...

				Ned

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 12 May 2004 00:30:38 -0400

Hi [email-masked],

>> OTOH perhaps I am missing the point :-)

It turns out that I fooled myself into believing the SIEVE implementation I 
am using was treating the tagged arguments as order dependent in envelope. 
In actual fact there is a configuration issue with the local mailer that 
means envelope is getting the local part of the actual RCPT TO's and not 
the domain and as a result the test is failing.

That said, I have wondered for a while whether it would not be better to 
have a formal ABNF syntax for the commands and tests. Would that actually 
be possible or useful?

-- 
Cyrus Daboo

---

From: Tim Showalter <[email-masked]>
Date: Wed, 12 May 2004 00:50:21 -0700

Cyrus Daboo wrote:

> have a formal ABNF syntax for the commands and tests. Would that 
> actually be possible or useful?

I don't think so.  Programming languages are typically specified as 
Sieve is, in terms of tokens, a formal grammar, and a standard library. 
  We could do what you suggest--in fact, the early drafts did so.  It 
was not very readable or particularly helpful.  Extensions would have to 
extend the grammar, and that's error-prone and not at all in line with 
what programming languages usually do.  Worse, you wouldn't be able to 
parse the general language without knowing all the extensions a 
particular script used.

Tim

---

From: [email-masked]
Date: Wed, 12 May 2004 07:18:18 -0700 (PDT)

> Sieve is, in terms of tokens, a formal grammar, and a standard library.

I concur. The problem with fully specifying ABNF for
commands and tests is that it tends to imply that's all there is, which
then clashes with future extensions.

> was not very readable or particularly helpful.

We tried this with MIME as well - we had ABNF for the initial
set of content-types. It did much more harm than good.

> Extensions would have to

Bingo.

				Ned

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 12 May 2004 12:36:57 -0400

> the domain and as a result the test is failing.

BTW I sent you an entry the other day for the 'sieve implementations'
page, in response to your note to the list.  Not trying to nag, but
I'm wondering if the message got to you.  OK, maybe I'm trying to nag. 

mm

---

From: Matthew Elvey <[email-masked]>
Date: Wed, 12 May 2004 17:44:11 -0700

On 5/12/2004 12:50 AM, Tim Showalter sent forth electrons to convey:

>
> Cyrus Daboo wrote:
>
>> That said, I have wondered for a while whether it would not be better 
>> to have a formal ABNF syntax for the commands and tests. Would that 
I wrote some "Tips for reading the RFC 
<http://www.ietf.org/rfc/rfc3028.txt?number=3028>:"
http://www.elvey.com/it/sieve/#_Toc9582052
some time ago (apologies for the sucky formatting; I redid the page and 
lost the new version somehow became demotivated).