Subject: Sieve subaddress extension draft

From: Ken Murchison <[email-masked]>
Date: Mon, 13 Mar 2000 13:39:14 -0500

I just wrote a draft for an extension to allow comparing against
user+detail addresses.  It can be obtained using either http or ftp,
from:

http://www.oceana.com/ftp/drafts/draft-murchison-sieve-subaddress-00.txt
ftp://ftp.oceana.com/pub/drafts/draft-murchison-sieve-subaddress-00.txt

I'm not crazy about the names of the capability or the optional
arguments, so if anyone has any better suggestions...  As always, all
comments/suggestions/flames (flames MUST have a well thought out
suggestion :^) are welcome.

BTW, both this extension and the regex extension are implemented in the
latest version of CMU Sieve.

Regards,
Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: Ken Murchison <[email-masked]>
Date: Mon, 13 Mar 2000 14:37:09 -0500

Michael Salmon wrote:
> Ken Murchison wrote:
> > Michael Salmon wrote:
> > > Ken Murchison wrote:
> > > It is usually called a detailed or detail address.
> >
> > I know, I used ":detail" as one of the optional args.  But what do you
> > call the capability, "detail", "detailed", "detailed-address"?  None of
> > these seemed to work very well.
> 
> I think that "detailed-address" is as good as "subaddress" but perhaps
> you should focus on the fact that you are writing to a folder and name
> the capability "folder-addressing" and then rename the address selector
> to ":folder". I think that the capability and the selector should be
> related.

I agree that "detailed-address" is a better description, but don't you
think its a little long for a require line?  I was hoping to come up
with a meaningful, yet succinct capability identifier.

As far as ":folder", I didn't want to make any assumptions as to the
nature of the detailed address.  I would agree that in most cases the
"detail" probably is a folder, but I don't think it has to be (no other
uses come to mind right now, though).

This is a good discussion.  Hopefully some others will chime in and we
can get some more ideas and come to some sort of consensus.

Regards,
Ken

---

From: Michael Salmon <[email-masked]>
Date: Tue, 14 Mar 2000 09:36:10 +0100

> with a meaningful, yet succinct capability identifier.

Maybe it could have an alias of detadd? My guess is that most sieve
scripts will be generated by GUI's and that require will not be
generated by anything so mundane as actually writing them so it probably
doesn't matter how long they are. After more thought I think that
"detail-addressing" is nearer english when combined with require.

> uses come to mind right now, though).

You could use the same argument against :user, it probably should be
:mailbox or :maildrop, mailbox is itself a bit ambiguous. If you used
:folder then you could replace :user with :cabinet ;^), I think that
Mulberry already does.

/Michael

Date: Tue, 14 Mar 2000 09:36:10 +0100
From: Michael Salmon <[email-masked]>
Organization: Ericsson Utvecklings AB
To: [email-masked]
Subject: Re: Sieve subaddress extension draft
Sender: [email-masked]

> with a meaningful, yet succinct capability identifier.

Maybe it could have an alias of detadd? My guess is that most sieve
scripts will be generated by GUI's and that require will not be
generated by anything so mundane as actually writing them so it probably
doesn't matter how long they are. After more thought I think that
"detail-addressing" is nearer english when combined with require.

> uses come to mind right now, though).

You could use the same argument against :user, it probably should be
:mailbox or :maildrop, mailbox is itself a bit ambiguous. If you used
:folder then you could replace :user with :cabinet ;^), I think that
Mulberry already does.

/Michael

Date: Mon, 13 Mar 2000 14:37:09 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Michael Salmon <[email-masked]>
CC: [email-masked]
Subject: Re: Sieve subaddress extension draft
Sender: [email-masked]

Regards,
Ken

Date: Mon, 13 Mar 2000 13:39:14 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
Subject: Sieve subaddress extension draft
Sender: [email-masked]

Regards,
Ken

Date: Fri, 10 Mar 2000 21:58:59 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
Subject: Re: Sieve regex extension draft update
Sender: [email-masked]

Ken Murchison wrote:
> 
> An updated version of this draft can be obtained from
> ftp://ftp/pub/drafts/draft-murchison-sieve-regex-01.txt

Sorry.  Obviously, only I can reach this server with a non-fully
qualified name.  Here is the complete URL.

ftp://ftp.oceana.com/pub/drafts/draft-murchison-sieve-regex-01.txt

Date: Fri, 10 Mar 2000 18:01:23 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
Subject: Sieve regex extension draft update
Sender: [email-masked]

An updated version of this draft can be obtained from
ftp://ftp/pub/drafts/draft-murchison-sieve-regex-01.txt

All comments and suggestions are welcome.

Ken

Date: Thu, 02 Mar 2000 20:37:21 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Tim Showalter <[email-masked]>
CC: [email-masked]
Subject: Re: Is: draft status; was: Re: Sieve regex extension
Sender: [email-masked]

Tim Showalter wrote:

> I'm pretty busy at the moment.  I will try and get a draft out soon.
> If everyone is fine with the semantic I want changed, then I'll change
> it in the document and hopefully get it out sometime next week, and
> then head for last call.
> 
> I believe I should also last call the vacation extension at the same
> time.  If you happen to agree, now would be an excellent time to read
> it and send me corrections.

Unless I'm reading this line from [VACATION] incorrectly:

"If the parameter given to ":days" is greater than the minimum value,
then the minimum value is used instead." 

Shouldn't this read "less than" instead of "greater than"?

Ken

Date: Wed, 01 Mar 2000 18:11:30 -0500
From: Matthew Wall <[email-masked]>
To: [email-masked]
cc: Tim Showalter <[email-masked]>, Ken Murchison <[email-masked]>
Subject: Re: Is: draft status; was: Re: Sieve regex extension
Sender: [email-masked]

-- On Wednesday, March 1, 2000 2:02 PM -0800 the entity known as Tim 
Showalter <[email-masked]> wrote:

<begin quote>

>
> I believe I should also last call the vacation extension at the same
> time.  If you happen to agree, now would be an excellent time to read
> it and send me corrections.

<end quote>

To which Matthew Wall offers this response on Wed, 01 Mar 2000 18:11:23 
-0500:

Agreed, and I will 8-).

- mw

To: Matthew Wall <[email-masked]>
Cc: [email-masked], Ken Murchison <[email-masked]>
Subject: Re: Is: draft status; was: Re: Sieve regex extension
From: Tim Showalter <[email-masked]>
Date: 01 Mar 2000 14:02:58 -0800
Lines: 23
Sender: [email-masked]

Matthew Wall <[email-masked]> writes:

> -- On Wednesday, March 1, 2000 9:39 AM -0500 the entity known as Ken 
> Murchison <[email-masked]> wrote:

> > When might you get to this?  Alexey suggested that I add an example or
> > two to the regex spec, but I want this to jive with the wording in the
> > base spec.
> 
> Yah, in point of fact, let me generalize this and suggest there's enough 
> modest implementation experience that we should do a last round of 
> revisions and submit this for extended last call. Time's a wastin'.

I'm pretty busy at the moment.  I will try and get a draft out soon.
If everyone is fine with the semantic I want changed, then I'll change
it in the document and hopefully get it out sometime next week, and
then head for last call.

I believe I should also last call the vacation extension at the same
time.  If you happen to agree, now would be an excellent time to read
it and send me corrections.

Tim

Date: Wed, 01 Mar 2000 16:07:07 -0500
From: Matthew Wall <[email-masked]>
To: [email-masked]
cc: Ken Murchison <[email-masked]>, Tim Showalter <[email-masked]>
Subject: Is: draft status; was: Re: Sieve regex extension
Sender: [email-masked]

-- On Wednesday, March 1, 2000 9:39 AM -0500 the entity known as Ken 
Murchison <[email-masked]> wrote:

<begin quote>

>
> When might you get to this?  Alexey suggested that I add an example or
> two to the regex spec, but I want this to jive with the wording in the
> base spec.

<end quote>

To which Matthew Wall offers this response on Wed, 01 Mar 2000 16:05:14 
-0500:

Yah, in point of fact, let me generalize this and suggest there's enough 
modest implementation experience that we should do a last round of 
revisions and submit this for extended last call. Time's a wastin'.

???

- Matt

Date: Wed, 01 Mar 2000 09:39:17 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Tim Showalter <[email-masked]>
CC: [email-masked]
Subject: Re: Sieve regex extension
Sender: [email-masked]

Tim Showalter wrote:
> 
> Randall Gellens <[email-masked]> writes:
> 
> > At 3:17 PM -0500 2/9/00, Ken Murchison wrote:
> >
> > >CMU Sieve currently strips all single backslashes in quoted strings,
> > >which seems to be one reasonable implementation based on the working in
> > >the spec.  This behavior requires that any escaped meta-character in a
> > >regex must be preceded by two backslashes.  This behavior also effects
> > >the :matches match-type in the base spec and imapflags as defined in
> > >draft-melnikov-sieve-imapflags-02.
> > >
> > >I am not up to speed on the discussions that led to the current wording
> > >in the spec, but I'd like to see all escape sequences passed through
> > >untouched, or perhaps be context-sensitive as hinted at in the spec.
> > >But, "this is just my opinion, and I could be wrong."
> >
> > I agree with you.  Two backslashes should mean one literal backslash.
> > "\." in a regexp should mean a literal dot.  "\\." should mean a
> > literal backslash followed by any character.  Otherwise it's too
> > confusing.
> 
> I believe that this is impossible to correctly parse without passing
> information between the parser and the lexer in a very unsavory way.
> In particular, if you're trying to decide what a backslash means at
> the lexer level, you can't, and you have to wait until the string is
> used in context.
> 
> I'm not happy that the spec says what it does.  It was a mistake.
> 
> For consistancy, I believe only \ and \" should be significant in a
> string; to escape a metacharacter, the syntax should be "\\?" (i.e.,
> match a literal question mark).  The sequence "\\\?" is not
> syntactically legal.
> 
> Programmers can grasp this (it's what C, Perl, and some Lisp
> implementations do) and no one else will understand it, no matter what
> we decide.
> 
> I would like to change the spec to reflect the behavior implemented in
> CMU's Sieve implementation.

Tim,

When might you get to this?  Alexey suggested that I add an example or
two to the regex spec, but I want this to jive with the wording in the
base spec.

Ken