headers
Ken Murchison | 1 Nov 2000 03:53

Re: sieve 13, corrections made during last-call discussion


Tim Showalter wrote:
> 
> Ken Murchison <ken <at> oceana.com> writes:
> 
> > > 2.4.2.3. Addresses
> > >
> > > A number of commands call for email addresses, which are also a subset
> > > of strings.  These addresses must be compliant with [IMAIL].
> > > Implementations are required to parse as specified by the "mailbox"
> > > definition in section 6.1, not as "address" is specified in that
> > > section.  "Group" syntax MUST NOT be used (if multiple addresses are
> > > requierd, use a string-list).
> >
> >   ^^^^^^^^
> >
> > Are you punting on the fact that "mailbox" allows "route"?  Or do you
> > want to restrict "mailbox" to:
> >
> > mailbox       = addr-spec
> >       / phrase "<" addr-spec ">"
> 
> That is the restriction I want.  source routes are obsolete, are listed
> as obsolete in drums, and I see no reason to allow them.
> 
> New text:
> 
>         A number of commands call for email addresses, which are also a
>         subset of strings.  These addresses must be compliant with
>         [IMAIL].  Implementations are required to parse as specified by
(Continue reading)

Permalink | Reply | 8 comments |
headers
Nigel Swinson | 1 Nov 2000 13:24

Re: draft-melnikov-sieve-imapflags-04.txt

> >  If they are I'd go for:
> >
> > keep :globalflags :plus [...]
> > keep :globalflags :minus [...]
> >
> > Which might even be better than :globalflags+ and definately better than :globalflags_plus.
> 
> In this case it is better to have ":globalflags plus [...]" or ":globalflags minus [...]" (no colon in
front of plus/minus), because it is confusing (tagged argument that requires another argument, hrrrrr ).

Ah yeah, it does say in the SIEVE spec:
- To simplify this specification, tagged arguments SHOULD NOT take
- tagged arguments as arguments.

Ok so the tagged optional argument "globalflags" may optionally take 2 arguments where both are
positional.  The first being "plus" / "minus", the second being a list of flags.  Yeah I'd be happy with that.

Nigel
Permalink | Reply | 1 comment |
headers
Tim Showalter | 2 Nov 2000 23:24

Re: sieve 13, corrections made during last-call discussion

Ken Murchison <ken <at> oceana.com> writes:

> Here's another fly in the ointment: What about 'domain-literals'?  Even
> [IMAIL] discourages that they be used.  Should we just define the syntax
> of what sieve should support in its entirety, or am I just being a pain
> in the ass now?  (taking a 4 year-old trick-or-treating will do that to
> you :^)

I really don't want to define the whole syntax.

I have no problem with allowing domain literals, or, in fact, any of the
comment stuff that's in 822.  Those are potentially useful, and while
they're discouraged, there's no real good way around them.

Okay, one more time:

2.4.2.3. Addresses

A number of commands call for email addresses, which are also a subset
of strings.  When these addresses are used in outbound contexts,
addresses must be compliant with [IMAIL], but are further constrained.
Using the symbols defined in [IMAIL], section 6.1, the syntax of an
address is:

.nf
	sieve-address = addr-spec		; simple address
		      / phrase addr-spec	; name & addr-spec
.fi

That is, routes and group syntax are not permitted.  If multiple
(Continue reading)

Permalink | Reply | 7 comments |
headers
Ken Murchison | 3 Nov 2000 02:51

Re: sieve 13, corrections made during last-call discussion


Tim Showalter wrote:
> 
> Ken Murchison <ken <at> oceana.com> writes:
> 
> > Here's another fly in the ointment: What about 'domain-literals'?  Even
> > [IMAIL] discourages that they be used.  Should we just define the syntax
> > of what sieve should support in its entirety, or am I just being a pain
> > in the ass now?  (taking a 4 year-old trick-or-treating will do that to
> > you :^)
> 
> I really don't want to define the whole syntax.
> 
> I have no problem with allowing domain literals, or, in fact, any of the
> comment stuff that's in 822.  Those are potentially useful, and while
> they're discouraged, there's no real good way around them.
> 
> Okay, one more time:
> 
> 2.4.2.3. Addresses
> 
> A number of commands call for email addresses, which are also a subset
> of strings.  When these addresses are used in outbound contexts,
> addresses must be compliant with [IMAIL], but are further constrained.
> Using the symbols defined in [IMAIL], section 6.1, the syntax of an
> address is:
> 
> .nf
>         sieve-address = addr-spec               ; simple address
>                       / phrase addr-spec        ; name & addr-spec
(Continue reading)

Permalink | Reply | 5 comments |
headers
Lawrence Greenfield | 3 Nov 2000 03:48
Picon

Re: sieve 13, corrections made during last-call discussion

   Date: Thu, 02 Nov 2000 20:51:01 -0500
   From: Ken Murchison <ken <at> oceana.com>

   One last point (I promise :^)  Are you going to use sieve-address in the
   formal grammar for redirect/vacation?  I think just saying that
   addresses "are also a subset
   of strings" leaves room for someone to do:

   redirect text:
   Nobody
   (test user)
   <foo <at> bar.com>
   .
   ;

   Do we really want to allow this?  This should still parse OK, but it's
   pretty ugly.  Maybe stating that addresses are a subset of
   quoted-strings would be better?  Or better yet, define: 

I don't think we should care about ugliness.  It's ugly but it's a legal
address with a single interpretation, so it's fine.

We want the least sane rules, not the prettiest addresses.

Larry
Permalink | Reply | 4 comments |
headers
Ken Murchison | 3 Nov 2000 04:14

Re: sieve 13, corrections made during last-call discussion

Quoting Lawrence Greenfield <leg+ <at> andrew.cmu.edu>:

>    Date: Thu, 02 Nov 2000 20:51:01 -0500
>    From: Ken Murchison <ken <at> oceana.com>
> 
>    One last point (I promise :^)  Are you going to use sieve-address in
> the
>    formal grammar for redirect/vacation?  I think just saying that
>    addresses "are also a subset
>    of strings" leaves room for someone to do:
> 
>    redirect text:
>    Nobody
>    (test user)
>    <foo <at> bar.com>
>    .
>    ;
> 
>    Do we really want to allow this?  This should still parse OK, but
> it's
>    pretty ugly.  Maybe stating that addresses are a subset of
>    quoted-strings would be better?  Or better yet, define: 
> 
> I don't think we should care about ugliness.  It's ugly but it's a legal
> address with a single interpretation, so it's fine.
> 
> We want the least sane rules, not the prettiest addresses.

Fine.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ken Murchison | 3 Nov 2000 17:18

Re: sieve 13, corrections made during last-call discussion


Tim Showalter wrote:
> 
> Okay, one more time:
> 
> 2.4.2.3. Addresses
> 
> A number of commands call for email addresses, which are also a subset
> of strings.  When these addresses are used in outbound contexts,
> addresses must be compliant with [IMAIL], but are further constrained.
> Using the symbols defined in [IMAIL], section 6.1, the syntax of an
> address is:
> 
> .nf
>         sieve-address = addr-spec               ; simple address
>                       / phrase addr-spec        ; name & addr-spec
> .fi

Just looked at this one last time.  I don't know if this is an nroff
fart or an oversight, but the grammar should be:

	sieve-address	= addr-spec			; simple address
			/ phrase "<" addr-spec ">"	; name & addr-spec

You might already have the "< >" in your source, but just wanted to make
sure.

Ken
--

-- 
Kenneth Murchison     Oceana Matrix Ltd.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Showalter | 3 Nov 2000 22:25

Re: sieve 13, corrections made during last-call discussion

Lawrence Greenfield <leg+ <at> andrew.cmu.edu> writes:

> We want the least sane rules, not the prettiest addresses.

agreed.

Tim
Permalink | Reply | 0 comments |
headers
Tim Showalter | 4 Nov 2000 02:14

Re: draft-melnikov-sieve-imapflags-04.txt

Also, I am strongly in favor of showing empty flags as [], not as NIL or
"".  NIL is syntactically an identifier, and requires a grammar change;
"" is not a valid IMAP flag, but it looks like a string.  I really hate
:flags "".

"Nigel Swinson" <Nigel <at> Swinson.com> writes:

> > >  If they are I'd go for:
> > >
> > > keep :globalflags :plus [...]
> > > keep :globalflags :minus [...]
> > >
> > > Which might even be better than :globalflags+ and definately
> > > better than :globalflags_plus.
> > 
> > In this case it is better to have ":globalflags plus [...]" or
> > ":globalflags minus [...]" (no colon in front of plus/minus),
> > because it is confusing (tagged argument that requires another
> > argument, hrrrrr ).
> 
> Ah yeah, it does say in the SIEVE spec:
> - To simplify this specification, tagged arguments SHOULD NOT take
> - tagged arguments as arguments.
> 
> Ok so the tagged optional argument "globalflags" may optionally take 2
> arguments where both are positional.  The first being "plus" /
> "minus", the second being a list of flags.  Yeah I'd be happy with
> that.

:globalflags minus requires a grammar change.  Syntactically, the bare
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roland Pope | 8 Nov 2000 21:45
Picon

Redirects that create mail loops

To quote from the RFC.

<snip>
   Implementations SHOULD take measures to implement loop control,
   possibly including adding headers to the message or counting received
   headers.  If an implementation detects a loop, it causes an error.
<snip>

What sort of error should this cause? Should a message be generated back to
the sender saying that a mail loop was detected? It would appear in the
current Cyrus 1.6.24 implementation, mails are silently deleted on loop
detection. Should there be an explicit definiton of how this sort of error
should be handled Eg. DSN?

Thanks
Roland Pope
Permalink | Reply | 1 comment |

Gmane