Subject: Generalizing subaddress

From: Ken Murchison <[email-masked]>
Date: Thu, 23 Mar 2006 19:25:37 -0500

I was tasked at Tuesday's Sieve WG meeting with trying to make the 
language in the subaddress draft even more general than it currently is, 
but as Philip noted in another thread, doing so makes it very difficult 
to describe when :detail is present/empty/not present.  I have not found 
a way to describe these states without relying on some type of 
'delimiter' or 'separator'.

Consider this a plea for some suggested text.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

---

From: Dave Cridland <[email-masked]>
Date: Fri, 24 Mar 2006 13:13:30 +0000

On Fri Mar 24 00:25:37 2006, Ken Murchison wrote:
> language in the subaddress draft even more general than it 
> currently is, but as Philip noted in another thread, doing so makes 
> it very difficult to describe when :detail is present/empty/not 
> present.  I have not found a way to describe these states without 
> relying on some type of 'delimiter' or 'separator'.
> 

I think much of Ken's problem here is that he's trying to build a 
standard method for doing something with unstandardized local part 
formats.

Perhaps what's actually needed is some kind of informational document 
describing various mechanisms that exist for subaddressing and 
similar local-part "encodings", and then using the subaddress Sieve 
extension to access those encodings.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 24 Mar 2006 14:43:29 +0100

Dave Cridland writes:
>> language in the subaddress draft even more general than it currently 
>> is, but as Philip noted in another thread, doing so makes it very 
>> difficult to describe when :detail is present/empty/not present.  I 
>> have not found a way to describe these states without relying on 
>> some type of 'delimiter' or 'separator'.
>>

Agreed.

> extension to access those encodings.

Maybe. But that paragraph brings forth RFC 1925 in my mind. 
Specifically, 6a, but also 6, 7, 7a and 8.

How about just specifying that
a) this extension is limited to subaddresses which use separators,
b) a future extension may lift that restriction, and
c) the separator may consist of one character, of several characters or 
even of a zero-width boundary such as e.g. "letter on one side, 
nonletter on the other"?

Arnt
(who thinks 1925 should be on the standards track)

---

From: Dave Cridland <[email-masked]>
Date: Fri, 24 Mar 2006 13:54:59 +0000

On Fri Mar 24 13:43:29 2006, Arnt Gulbrandsen wrote:
>>> I was tasked at Tuesday's Sieve WG meeting with trying to make 
>>> the language in the subaddress draft even more general than it 
>>> currently is, but as Philip noted in another thread, doing so 
>>> makes it very difficult to describe when :detail is 
>>> present/empty/not present.  I have not found a way to describe 
>>> these states without relying on some type of 'delimiter' or 
>>> 'separator'.
>>> 
>> Perhaps what's actually needed is some kind of informational 
>> document describing various mechanisms that exist for 
>> subaddressing and similar local-part "encodings", and then using 
>> the subaddress Sieve extension to access those encodings.
> 
You have a sound point, although my premise for moving the definition 
to a distinct document was primarily because it's useful on its own, 
see (5).

> c) the separator may consist of one character, of several 
> characters or even of a zero-width boundary such as e.g. "letter on 
> one side, nonletter on the other"?
> 
> 
I'm mildly concerned you're infringing on (9) and (10), but if we're 
going to dump any idea of addressing subaddresses further [if you can 
follow that] then I'd like to canvas implementors on what they think 
a subaddress is, whether it sometimes/usually fits this description, 
and whether we might as well chop it further. (Say, by insisting on a 
'+' postfix ).

FWIW, trying to bend in VERP and similar mechanisms strikes me as (5).

> (who thinks 1925 should be on the standards track)

I think you could advance it straight to Draft status on the basis of 
multiple independent interoperable implementations, at least.

Dave.

---

From: Michael Haardt <[email-masked]>
Date: Fri, 24 Mar 2006 15:47:11 +0100

> >relying on some type of 'delimiter' or 'separator'.

If the encoding of a detail depends on the target address, determining
if it contains no, an empty or a non-empty detail part depends on the
target address, too.  It can not be described in the subaddress extension.

I suggest:

   The ":detail" argument specifies the detail sub-part of the local-part
   of an address.  The encoding of the detail sub-part is dependent on
   the encompassing mail system and recipient address.  If the recipient
   address is not encoded to contain a detail part, the test evaluates
   to false.  An encoded empty detail information causes an empty key
   ("").

Something sounds wrong there, but a native speaker can certainly fix it.

> standard method for doing something with unstandardized local part 

Exactly.

> extension to access those encodings.

I agree, although I would like to keep that purely informational and allow
the extension to make use of methods not described in such a document.
Yet it may reduce the amount of new encoding schemes arising just because
people never saw existing approaches to the problem.

Michael

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 24 Mar 2006 15:56:36 +0100

> FWIW, trying to bend in VERP and similar mechanisms strikes me as (5).

Hm.

That's not what I tried. I tried to define separator strongly enough 
that it can be used, and weakly enough that no implementer thinks he 
can process other people's subaddresses except as a 100% opaque 
address.

> multiple independent interoperable implementations, at least.

Oh? The last adjective seems rather out of place ;)

Arnt

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Tue, 28 Mar 2006 02:27:24 +0200

> Something sounds wrong there, but a native speaker can certainly fix it.

sounds good to me, but I'm not a native speaker, either :-)  I assume
you mean the "Note" following the paragraph should be removed, too.

the introduction needs to be made less explicit, it says:

.  Introduction

   Subaddressing is the practice of augmenting (usually with a suffix)
   the local-part of an [RFC2822] address with some "detail" information
   to indicate that the message should be delivered to the mailbox
   specified by the "detail" information.  A "separator character
   sequence" (typically "+"), forms the boundary between the "user"
   (original local-part) and "detail" sub-parts of the address, much
   like the "@" character forms the boundary between the local-part and
   domain.

I suggest to change the last sentence:

        One common way of encoding "detail" information is to add a
        "separator character sequence", for instance "+", to form a
        boundary between the "user" (original local-part) and "detail"
        sub-parts [...]

the examples are fine, but a more "esoteric" example would be nice.  I
suggest BATV as an informative reference.  it only applies to bounce
messages, of course (since a remote recipient can't decode it), but it's
an example of an opaque encoding with information which could be
presented to the user through this extension if the server administrator
chooses to.
-- 
Kjetil T.

---

From: Ned Freed <[email-masked]>
Date: Mon, 27 Mar 2006 17:44:28 -0800 (PST)

> >    to false.  An encoded empty detail information causes an empty key

I suggest changing the last sentence to something like 'An encoded empty
detail sub-part will product the empty key value ("").'

> presented to the user through this extension if the server administrator

I have to say I'm not wild about using system-level examples in this
context. As I tried to point out at the meeting last week, the intent
behind this extension is to provide a means for users to extract subaddress
information from their addresses in a portable way. It isn't clear to me
it is appropriate to use this mechanism for BATV, or SRS, or anything
similar, so I'm hesitant to have examples of such usage.

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 29 Mar 2006 18:32:56 -0800

Dave Cridland wrote:

>> c) the separator may consist of one character, of several characters 
>> or even of a zero-width boundary such as e.g. "letter on one side, 
>> nonletter on the other"?
>
> follow that] then I'd like to canvas implementors on what they think a 
> subaddress is, whether it sometimes/usually fits this description, and 
> whether we might as well chop it further. (Say, by insisting on a '+' 
> postfix

Existing implementation already use '-' or '--'.
This was already discussed on the mailing list, so lets not revisit this 
decision.

> ).

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 29 Mar 2006 18:35:21 -0800

Dave Cridland wrote:

>> have not found a way to describe these states without relying on some 
>> type of 'delimiter' or 'separator'.
>>
> describing various mechanisms that exist for subaddressing and similar 
> local-part "encodings", and then using the subaddress Sieve extension 
> to access those encodings.

Previous attempts to do this have failed (partially due to the help of 
DJB). I think Chris had a draft on this.

So I remain skeptical if the new effort is going to be more successful.

---

From: Aaron Stone <[email-masked]>
Date: Thu, 30 Mar 2006 11:26:04 -0800

> > On Fri Mar 24 00:25:37 2006, Ken Murchison wrote:
[snip]
> So I remain skeptical if the new effort is going to be more successful.

I first became aware of subaddressing in a bug posted to the DBMail bug
tracker by a user who wanted username+mailbox addressing to be delivered
to the right mailbox. It turned out to require a fairly invasive set of
changes to the way we were looking up valid user accounts. Getting the
mailbox spec passed along the delivery chain was less difficult.

The real issue that I see here is that the mail delivery agent has to
make a decision about whether or not an address refers to a user on the
system -- parsing the address as needed to find the local user account
-- and then the Sieve engine presents the parsed address to the script.

In the case of DBMail and libSieve, only the verbatim address is passed;
the two code bases happen to perform the same decoding. What we're
looking at, then, is a de-facto standard that both codebases adhere to.
If either side of that interface changes its decoding pattern, then it
all breaks down. If a user posts a patch to the DBMail bug tracker
providing support for some other subaddress format, then I would have to
put it on hold, saying, "This can't go in until I've rewritten the patch
for libSieve, otherwise you won't be able to use Sieve with this new
subaddress format."

Implicit in the Sieve subaddress draft is that there is a format of
either: userSEPdetail@domain or detailSEPuser@domain. In database terms,
we would be violating "first normal form" if :user were further
internally formatted and required a regex to parse. It would also mean
explaining mail-system-internals to the script authors. Basically,
exactly what we're trying to prevent with this spec.

As I understand the debate to date, there are two questions holding
things up: more subaddress parts, and more complex, possibly nested,
encodings. I think I've seen the two-part-subaddress but
double-encoded-detail dismissed as being something the implementation
can handle already -- like username+=XYZ-BASE64-123=@domain. That's easy
to resolve, but probably should be treated more directly in the RFC.

Now then, there's the more and more complex patterns... my suggestion is
to accept a new fact:

1.  There is always a "user" part, which refers to an account
    in the email system.
2.  There might be a "detail" part.
3.  There might be a couple of detail parts.

We currently accept and act on facts 1 and 2. The proposals on 3 all
seem to have suggested adding more names; :detail, :mailbox, :voicemail,
whatever. The names are inherently specific to some interpretation of
the fields in the subaddress coding, thereby creating a standard, and
then putting us in need of writing that standard, which nobody wants to
do because there are so many systems already out there. How about this:

3A. :detail0 is an alias for :detail. :detail1, :detail2 ... :detailn
    refer to other parts of the subaddress; implementation defined,
    with common uses documented in an informal manner, just enough to
    give new implementors an idea of what's already out there.

Thanks for reading if you got this far! I hope that my suggested change
is well received. If not, forget that part and just remember that no
matter what the subaddressing scheme is, there has to be some agreement
between the email account lookup and the Sieve script about what parts
of the subaddress are what in the mail system, and that implies at least
a de-facto standard or contract of some kind among the codebases.

Aaron

Subject: Re: Generalizing subaddress
From: Aaron Stone <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Date: Thu, 30 Mar 2006 11:26:04 -0800
Sender: [email-masked]

> > On Fri Mar 24 00:25:37 2006, Ken Murchison wrote:
[snip]
> So I remain skeptical if the new effort is going to be more successful.

I first became aware of subaddressing in a bug posted to the DBMail bug
tracker by a user who wanted username+mailbox addressing to be delivered
to the right mailbox. It turned out to require a fairly invasive set of
changes to the way we were looking up valid user accounts. Getting the
mailbox spec passed along the delivery chain was less difficult.

The real issue that I see here is that the mail delivery agent has to
make a decision about whether or not an address refers to a user on the
system -- parsing the address as needed to find the local user account
-- and then the Sieve engine presents the parsed address to the script.

In the case of DBMail and libSieve, only the verbatim address is passed;
the two code bases happen to perform the same decoding. What we're
looking at, then, is a de-facto standard that both codebases adhere to.
If either side of that interface changes its decoding pattern, then it
all breaks down. If a user posts a patch to the DBMail bug tracker
providing support for some other subaddress format, then I would have to
put it on hold, saying, "This can't go in until I've rewritten the patch
for libSieve, otherwise you won't be able to use Sieve with this new
subaddress format."

Implicit in the Sieve subaddress draft is that there is a format of
either: userSEPdetail@domain or detailSEPuser@domain. In database terms,
we would be violating "first normal form" if :user were further
internally formatted and required a regex to parse. It would also mean
explaining mail-system-internals to the script authors. Basically,
exactly what we're trying to prevent with this spec.

As I understand the debate to date, there are two questions holding
things up: more subaddress parts, and more complex, possibly nested,
encodings. I think I've seen the two-part-subaddress but
double-encoded-detail dismissed as being something the implementation
can handle already -- like username+=XYZ-BASE64-123=@domain. That's easy
to resolve, but probably should be treated more directly in the RFC.

Now then, there's the more and more complex patterns... my suggestion is
to accept a new fact:

1.  There is always a "user" part, which refers to an account
    in the email system.
2.  There might be a "detail" part.
3.  There might be a couple of detail parts.

We currently accept and act on facts 1 and 2. The proposals on 3 all
seem to have suggested adding more names; :detail, :mailbox, :voicemail,
whatever. The names are inherently specific to some interpretation of
the fields in the subaddress coding, thereby creating a standard, and
then putting us in need of writing that standard, which nobody wants to
do because there are so many systems already out there. How about this:

3A. :detail0 is an alias for :detail. :detail1, :detail2 ... :detailn
    refer to other parts of the subaddress; implementation defined,
    with common uses documented in an informal manner, just enough to
    give new implementors an idea of what's already out there.

Thanks for reading if you got this far! I hope that my suggested change
is well received. If not, forget that part and just remember that no
matter what the subaddressing scheme is, there has to be some agreement
between the email account lookup and the Sieve script about what parts
of the subaddress are what in the mail system, and that implies at least
a de-facto standard or contract of some kind among the codebases.

Aaron

Date: Wed, 29 Mar 2006 18:35:21 -0800
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: [email-masked]
Subject: Re: Generalizing subaddress
Sender: [email-masked]

Date: Wed, 29 Mar 2006 18:32:56 -0800
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Generalizing subaddress
Sender: [email-masked]

Date: Tue, 28 Mar 2006 08:20:23 +0100
Subject: Re: document status: 3028bis, body, editheader
From: Dave Cridland <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
Cc: <[email-masked]>, Ned Freed <[email-masked]>
Sender: [email-masked]

On Tue Mar 28 03:07:20 2006, Kjetil Torgrim Homme wrote:
> On Sat, 2006-03-25 at 09:26 -0800, Ned Freed wrote:
> 
> > > I thought Dave Cridland's suggestion to specify matching 
> behaviour in
> > > the comparator itself was intriguing:
> > >
> > > http://permalink.gmane.org/gmane.ietf.mta-filters/2689
> > >
> > > unfortunately, [draft-newman-i18n-comparator-08] says «the 
> equality test
> > > MUST be reflexive, symmetric and transitive», so "EQUAL" can't 
> be used.
> > > I must admit I don't quite understand how :matches and :regex 
> work with
> > > comparators, though.
> > > > I think of it this way: A comparator has as one of it's 
> components a
> > normalization operation. Pull that operation out, apply it, and 
> then
> > perform the glob or regex operation on the result. Note that the
> > output of the normalization is best seen as a series of 
> nonnegative
> > integers or someting similar, not octets or characters.
> 
> 
> thanks.
> 
> so you split your match pattern into constant strings without the
> wildcards, send each to the comparator which returns a list of 
> start and
> end points for each matched constant string, and then see if you can
> find a sequence of (start, end) for each constant string where the
> intervals between the constant strings match the wildcards.  *phew*
> 
> that will work for :matches (although I doubt anyone will actually
> implement it that way -- so the pluggable comparator idea goes out 
> the
> window), but not for :regex.  unless I'm missing something again :-)
> 
> 
I think we have to document reality here. The reality seems to be 
that not only do comparators have a normalization operation, but they 
also have a match operation. I *suspect* that the matching function 
has '?', '%', and '*' wildcards, although only two are used in Sieve.

I'd like to float the notion that somebody writes text suitable to 
document this at the comparator level.

We'd want to define this such that existing usage is captured, and 
sensible definitions for i;basic* apply, such that '?' wildcard 
behaviour works as expected.

Dave.

Subject: Re: document status: 3028bis, body, editheader
From: Kjetil Torgrim Homme <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: [email-masked]
Date: Tue, 28 Mar 2006 04:07:20 +0200
Sender: [email-masked]

--=-rubO0Oqsvm3DZucUGjGc
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sat, 2006-03-25 at 09:26 -0800, Ned Freed wrote:

> > I thought Dave Cridland's suggestion to specify matching behaviour in
> > the comparator itself was intriguing:
> >
> > http://permalink.gmane.org/gmane.ietf.mta-filters/2689
> >
> > unfortunately, [draft-newman-i18n-comparator-08] says =ABthe equality t=
est
> > MUST be reflexive, symmetric and transitive=BB, so "EQUAL" can't be use=
d.
> > I must admit I don't quite understand how :matches and :regex work with
> > comparators, though.
>=20
>=20
> I think of it this way: A comparator has as one of it's components a
> normalization operation. Pull that operation out, apply it, and then
> perform the glob or regex operation on the result. Note that the
> output of the normalization is best seen as a series of nonnegative
> integers or someting similar, not octets or characters.

thanks.

so you split your match pattern into constant strings without the
wildcards, send each to the comparator which returns a list of start and
end points for each matched constant string, and then see if you can
find a sequence of (start, end) for each constant string where the
intervals between the constant strings match the wildcards.  *phew*

that will work for :matches (although I doubt anyone will actually
implement it that way -- so the pluggable comparator idea goes out the
window), but not for :regex.  unless I'm missing something again :-)

> > another possibility is to have a capability which adds an action which
> > changes the default comparator to reduce the verbosity.
>=20
>=20
> It makes scripts a bit shorter, but at the expense of having something
> with far-reaching impact specified at the top and not where the impact
> is felt. I'm far from convinced this is a good tradeoff.

what do you mean by impact?  server load?

> > another possibility is to allow the wildcard comparator, so
> > that :comparator "*" =AB[selects] the collation with the broadest scope
> > (preferably international scope), the most recent table versions and th=
e
> > greatest number of supported operations.=BB  (the comparators the serve=
r
> > chooses from would have to be "require"d in advance, I think, although
> > =ABrequire "comparator-*"=BB is a possibility)
>=20
>=20
> I really don't like this - now you have scripts working in subtlely
> different ways in different places. This is big steps backwards, I
> think.

you can reduce the problem by not doing require on more comparators than
you need.  e.g., if you do

  require "comparator-i;basic;uca=3D3.1.1;uv=3D3.2";
  require "comparator-i;ascii-numeric";
  require "comparator-*";

it's quite obvious which comparator has the =ABbroadest international
scope=BB (just to make it clear, this is the wording about the behaviour
of "*" from [COLLATION]).

> > > And good luck using i;basic;uca=3D3.1.1;uv=3D3.2 to trap specific seq=
uences of
> > > illegal 8bit in headers. Such stuff is rarely if ever in UTF-8, in my
> > > experience at least.
> >
> > this is impossible today, isn't it?
>=20
> It is done all the time and the base specification allows it, more or
> less.

well, that's in contention.

> > how do you specify the string to compare with?
>=20
>=20
> You just do it. Nothing in the current sieve specification says that
> it is an error to specify material that isn't valid utf-8.

8.1.     Lexical Tokens

   Sieve scripts are encoded in UTF-8.  The following assumes a valid
   UTF-8 encoding; special characters in Sieve scripts are all ASCII.

"are" is considered equivalent with a MUST, isn't it?

> (This is now prohibited by the ABNF in the revised base specification,
> and IMO this restriction needs to be removed for string constants.

I strongly disagree.  let's not make a charset soup on purpose.

> It is at a minimum in direct conflict with the vacation
> specification.)

not relevant, since vacation hasn't left draft status.

> > in any case, if you want to trap raw non-UTF8 in headers,
> > you should use i;octet.
>=20
>=20
> Agreed, but in practice scripts often don't specify this.

such scripts are broken and rely on undocumented behaviour IMO.

> >  but then again:
> >
> > 5.7.  Octet Collation
> >
> >    The i;octet (Section 9.5) collation is only usable with protocols
> >    based on octet-strings.  Clients and servers MUST NOT use i;octet
> >    with other protocols.
> >
> > which would disqualify the use of i;octet with Sieve, since 3028bis say=
s:
> >
> >    The language is represented in UTF-8, as specified in [UTF-8].
>=20
>=20
> Represent doesn't mean things are restricted to UTF-8.

yes, this is fine.  the message can contain octet strings even if the
script itself can not.  sorry about the red herring.

> If it did it would be in direct conflict with later language in the
> same document, which quite specifically allows material in other
> charsets in strings.

what language are you thinking of?

> > the collation-draft exempts RFC 3028 from this "MUST NOT", but it's not
> > clear to me that a 3028bis can get the same exemption.
>=20
>=20
> It better or backwards compatibility goes down the toilet, which is
> not acceptable as far as I'm concerned.

how about implementations where "?" matches a Unicode character even for
the default comparator?  which implementation gets to define backwards
compatibility?

> > notice that
> > "represented in UTF-8" only means constant strings can't contain raw
> > octets which are illegal UTF-8 sequences.
>=20
>=20
> I disagree 100% that that is what it means. And since the
> specification later talks about putting non-UTF-8 material in constant
> strings in section 2.4.2.4, it seems it agrees with me.

it's not clear that 2.4.2.4 expects the Sieve implementation to decode
the embedded MIME document into raw octets.  I would expect the
opposite, that the MIME headers and encoded data supplied in the script
are copied verbatim.

> > which brings us back to the
> > discussion on character escapes from a year ago.
>=20
> > http://comments.gmane.org/gmane.ietf.mta-filters/2030
>=20
> > I'd like to suggest we implement (2), but with the extension defined in
> > the base spec.
>=20
>=20
> I have no problem with this and would like to see it happen,

I'm glad to hear it.  I guess I should submit text for consideration :-)

> Regardless of whether you write some sequence that's illegal in UTF-8
> directly as a series of octets in a string constant or indirectly
> using some sort of encoding, you're still presenting the sieve
> interpreter with text that isn't in utf-8 at some level.

the Sieve interpreter needs to handle non-UTF-8 already. that is, header
bodies which are encoded in an unknown charset must be handled as
octet-strings.

looking at the current draft, I think this excerpt from 2.7.2 needs a
little tweak:

   If implementations fail to support the above behavior, they MUST
   conform to the following:

      No two strings can be considered equal if one contains octets
      greater than 127.

(this is unchanged since 3028).  I believe it should be allowed to
compare such strings using i;octet.  I don't have suitable replacement
text, though.

> Any attempt to enforce some sort of rule that nothing but utf-8 can be
> present is still going to fail. And any +Unnnn sort of scheme is
> inherently incapable of representing UTF-8 anyway.

well, yes, it represents a Unicode code point, not an octet sequence.
but as we have established, with the correct comparator, you can use "?"
to see that the *client visible* representation of Sieve strings is in
fact UTF-8.
--=20
Kjetil T.

--=-rubO0Oqsvm3DZucUGjGc
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.10.0">
</HEAD>
<BODY>
On Sat, 2006-03-25 at 09:26 -0800, Ned Freed wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">&gt; I thought Dave Cridland's suggestion to specify matching behaviour in</FONT>
<FONT COLOR="#000000">&gt; the comparator itself was intriguing:</FONT>
&gt;
<FONT COLOR="#000000">&gt; <A HREF="http://permalink.gmane.org/gmane.ietf.mta-filters/2689">http://permalink.gmane.org/gmane.ietf.mta-filters/2689</A></FONT>
&gt;
<FONT COLOR="#000000">&gt; unfortunately, [draft-newman-i18n-comparator-08] says &#171;the equality test</FONT>
<FONT COLOR="#000000">&gt; MUST be reflexive, symmetric and transitive&#187;, so &quot;EQUAL&quot; can't be used.</FONT>
<FONT COLOR="#000000">&gt; I must admit I don't quite understand how :matches and :regex work with</FONT>
<FONT COLOR="#000000">&gt; comparators, though.</FONT>

</PRE>
    <FONT COLOR="#000000">I think of it this way: A comparator has as one of it's components a</FONT> <FONT COLOR="#000000">normalization operation. Pull that operation out, apply it, and then perform</FONT> <FONT COLOR="#000000">the glob or regex operation on the result. Note that the output of the</FONT> <FONT COLOR="#000000">normalization is best seen as a series of nonnegative integers or someting</FONT> <FONT COLOR="#000000">similar, not octets or characters.</FONT><BR>
</BLOCKQUOTE>
<BR>
thanks.<BR>
<BR>
so you split your match pattern into constant strings without the wildcards, send each to the comparator which returns a list of start and end points for each matched constant string, and then see if you can find a sequence of <TT>(start, end)</TT> for each constant string where the intervals between the constant strings match the wildcards.&nbsp; *phew*<BR>
<BR>
that will work for <TT>:matches</TT> (although I doubt anyone will actually implement it that way -- so the pluggable comparator idea goes out the window), but not for <TT>:regex.</TT>&nbsp; unless I'm missing something again :-)<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">&gt; another possibility is to have a capability which adds an action which</FONT>
<FONT COLOR="#000000">&gt; changes the default comparator to reduce the verbosity.</FONT>

</PRE>
    <FONT COLOR="#000000">It makes scripts a bit shorter, but at the expense of having something with</FONT> <FONT COLOR="#000000">far-reaching impact specified at the top and not where the impact is felt. I'm</FONT> <FONT COLOR="#000000">far from convinced this is a good tradeoff.</FONT><BR>
</BLOCKQUOTE>
<BR>
what do you mean by impact?&nbsp; server load?<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">&gt; another possibility is to allow the wildcard comparator, so</FONT>
<FONT COLOR="#000000">&gt; that :comparator &quot;*&quot; &#171;[selects] the collation with the broadest scope</FONT>
<FONT COLOR="#000000">&gt; (preferably international scope), the most recent table versions and the</FONT>
<FONT COLOR="#000000">&gt; greatest number of supported operations.&#187;  (the comparators the server</FONT>
<FONT COLOR="#000000">&gt; chooses from would have to be &quot;require&quot;d in advance, I think, although</FONT>
<FONT COLOR="#000000">&gt; &#171;require &quot;comparator-*&quot;&#187; is a possibility)</FONT>
</PRE>
    <BR>
    <FONT COLOR="#000000">I really don't like this - now you have scripts working in subtlely different </FONT><FONT COLOR="#000000">ways in different places. This is big steps backwards, I think.</FONT><BR>
</BLOCKQUOTE>
<BR>
you can reduce the problem by not doing require on more comparators than you need.&nbsp; e.g., if you do<BR>
<BR>
<TT>&nbsp; require &quot;com</TT><TT><FONT COLOR="#000000">parator-i;basic;uca=3.1.1;uv=3.2&quot;;</FONT></TT><BR>
<TT>&nbsp; require &quot;comparator-i;ascii-numeric&quot;;</TT><BR>
<TT>&nbsp; require &quot;comparator-*&quot;;</TT><BR>
<BR>
it's quite obvious which comparator has the &#171;broadest international scope&#187; (just to make it clear, this is the wording about the behaviour of &quot;*&quot; from [COLLATION]).<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">&gt; &gt; And good luck using i;basic;uca=3.1.1;uv=3.2 to trap specific sequences of</FONT>
<FONT COLOR="#000000">&gt; &gt; illegal 8bit in headers. Such stuff is rarely if ever in UTF-8, in my</FONT>
<FONT COLOR="#000000">&gt; &gt; experience at least.</FONT>
&gt;
<FONT COLOR="#000000">&gt; this is impossible today, isn't it?</FONT>
</PRE>
    <FONT COLOR="#000000">It is done all the time and the base specification allows it, more or less.</FONT><BR>
</BLOCKQUOTE>
<BR>
well, that's in contention.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">&gt; how do you specify the string to compare with?</FONT>
</PRE>
    <BR>
    <FONT COLOR="#000000">You just do it. Nothing in the current sieve specification says that it is an</FONT> <FONT COLOR="#000000">error to specify material that isn't valid utf-8.</FONT><BR>
</BLOCKQUOTE>
<BR>
<TT>8.1.&nbsp;&nbsp;&nbsp;&nbsp; Lexical Tokens</TT><BR>
<BR>
<TT>&nbsp;&nbsp; Sieve scripts are encoded in UTF-8.&nbsp; The following assumes a valid</TT><BR>
<TT>&nbsp;&nbsp; UTF-8 encoding; special characters in Sieve scripts are all ASCII.</TT><BR>
<BR>
&quot;are&quot; is considered equivalent with a MUST, isn't it?<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">(This is now prohibited by</FONT> <FONT COLOR="#000000">the ABNF in the revised base specification, and IMO this restriction needs to</FONT> <FONT COLOR="#000000">be removed for string constants.</FONT><BR>
</BLOCKQUOTE>
<BR>
I strongly disagree.&nbsp; let's not make a charset soup on purpose.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">It is at a minimum in direct conflict with the</FONT> <FONT COLOR="#000000">vacation specification.)</FONT>
</BLOCKQUOTE>
<PRE>

</PRE>
not relevant, since vacation hasn't left draft status.
<PRE>

</PRE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">&gt; in any case, if you want to trap raw non-UTF8 in headers,</FONT>
<FONT COLOR="#000000">&gt; you should use i;octet.</FONT>

</PRE>
    <FONT COLOR="#000000">Agreed, but in practice scripts often don't specify this.</FONT><BR>
</BLOCKQUOTE>
<BR>
such scripts are broken and rely on undocumented behaviour IMO.
<PRE>

</PRE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">&gt;  but then again:</FONT>
&gt;
<FONT COLOR="#000000">&gt; </FONT><FONT COLOR="#000000"><TT>5.7.&nbsp; Octet Collation</TT></FONT>
&gt;
<FONT COLOR="#000000"><TT>&gt;    The i;octet (Section 9.5) collation is only usable with protocols</TT></FONT>
<FONT COLOR="#000000"><TT>&gt;    based on octet-strings.  Clients and servers MUST NOT use i;octet</TT></FONT>
<FONT COLOR="#000000"><TT>&gt;&nbsp;&nbsp;&nbsp; with other protocols.</TT></FONT>
&gt;
<FONT COLOR="#000000">&gt; which would disqualify the use of i;octet with Sieve, since 3028bis says:</FONT>
&gt;
<FONT COLOR="#000000">&gt;&nbsp;&nbsp;&nbsp; The language is represented in UTF-8, as specified in [UTF-</FONT>8].

</PRE>
    <FONT COLOR="#000000">Represent doesn't mean things are restricted to UTF-8.</FONT><BR>
</BLOCKQUOTE>
<BR>
yes, this is fine.&nbsp; the message can contain octet strings even if the script itself can not.&nbsp; sorry about the red herring.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">If it did it would be in</FONT> <FONT COLOR="#000000">direct conflict with later language in the same document, which quite</FONT> <FONT COLOR="#000000">specifically allows material in other charsets in strings.</FONT><BR>
</BLOCKQUOTE>
<BR>
what language are you thinking of?<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">&gt; the collation-draft exempts RFC 3028 from this &quot;MUST NOT&quot;, but it's not</FONT>
<FONT COLOR="#000000">&gt; clear to me that a 3028bis can get the same exemption.</FONT>

</PRE>
    <FONT COLOR="#000000">It better or backwards compatibility goes down the toilet, which is not</FONT> <FONT COLOR="#000000">acceptable as far as I'm concerned.</FONT><BR>
</BLOCKQUOTE>
<BR>
how about implementations where &quot;?&quot; matches a Unicode character even for the default comparator?&nbsp; which implementation gets to define backwards compatibility?<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">&gt; notice that</FONT>
<FONT COLOR="#000000">&gt; &quot;represented in UTF-8&quot; only means constant strings can't contain raw</FONT>
<FONT COLOR="#000000">&gt; octets which are illegal UTF-8 sequences.</FONT>

</PRE>
    <FONT COLOR="#000000">I disagree 100% that that is what it means. And since the specification later</FONT> <FONT COLOR="#000000">talks about putting non-UTF-8 material in constant strings in section 2.4.2.4,</FONT> <FONT COLOR="#000000">it seems it agrees with me.</FONT><BR>
</BLOCKQUOTE>
<BR>
it's not clear that 2.4.2.4 expects the Sieve implementation to decode the embedded MIME document into raw octets.&nbsp; I would expect the opposite, that the MIME headers and encoded data supplied in the script are copied verbatim.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">&gt; which brings us back to the</FONT>
<FONT COLOR="#000000">&gt; discussion on character escapes from a year ago.</FONT>

<FONT COLOR="#000000">&gt; <A HREF="http://comments.gmane.org/gmane.ietf.mta-filters/2030">http://comments.gmane.org/gmane.ietf.mta-filters/2030</A></FONT>

<FONT COLOR="#000000">&gt; I'd like to suggest we implement (2), but with the extension defined in</FONT>
<FONT COLOR="#000000">&gt; the base spec.</FONT>

</PRE>
    <FONT COLOR="#000000">I have no problem with this and would like to see it happen,</FONT><BR>
</BLOCKQUOTE>
<BR>
I'm glad to hear it.&nbsp; I guess I should submit text for consideration :-)<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">Regardless of whether you write some</FONT> <FONT COLOR="#000000">sequence that's illegal in UTF-8 directly as a series of octets in a string</FONT> <FONT COLOR="#000000">constant or indirectly using some sort of encoding, you're still presenting the</FONT> <FONT COLOR="#000000">sieve interpreter with text that isn't in utf-8 at some level.</FONT><BR>
</BLOCKQUOTE>
<BR>
the Sieve interpreter needs to handle non-UTF-8 already. that is, header bodies which are encoded in an unknown charset must be handled as octet-strings.<BR>
<BR>
looking at the current draft, I think this excerpt from 2.7.2 needs a little tweak:<BR>
<BR>
<PRE>
   If implementations fail to support the above behavior, they MUST
   conform to the following:

      No two strings can be considered equal if one contains octets
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; greater than 127.

</PRE>
(this is unchanged since 3028).&nbsp; I believe it should be allowed to compare such strings using <TT>i;octet</TT>.&nbsp; I don't have suitable replacement text, though.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">Any attempt to</FONT> <FONT COLOR="#000000">enforce some sort of rule that nothing but utf-8 can be present is still going</FONT> <FONT COLOR="#000000">to fail. And any +Unnnn sort of scheme is inherently incapable of representing</FONT> <FONT COLOR="#000000">UTF-8 anyway.</FONT><BR>
</BLOCKQUOTE>
<BR>
well, yes, it represents a Unicode code point, not an octet sequence.&nbsp; but as we have established, with the correct comparator, you can use &quot;<TT>?</TT>&quot; to see that the *<B>client visible*</B> representation of Sieve strings is in fact UTF-8.<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<PRE>
-- 
Kjetil T.

</PRE>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>

--=-rubO0Oqsvm3DZucUGjGc--

Cc: Michael Haardt <[email-masked]>, [email-masked]
To: Kjetil Torgrim Homme <[email-masked]>
Date: Mon, 27 Mar 2006 17:44:28 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Generalizing subaddress
Sender: [email-masked]

				Ned

Subject: Re: Generalizing subaddress
From: Kjetil Torgrim Homme <[email-masked]>
To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Date: Tue, 28 Mar 2006 02:27:24 +0200
Sender: [email-masked]

.  Introduction

Subject: Re: Sieve mime loop issues list
From: Kjetil Torgrim Homme <[email-masked]>
To: Nigel Swinson <[email-masked]>
Cc: IETF MTA Filters List <[email-masked]>
Date: Tue, 28 Mar 2006 02:08:29 +0200
Sender: [email-masked]

--=-h7Ln7RcOAxUVddDOzd9t
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Fri, 2006-03-24 at 13:10 +0000, Nigel Swinson wrote:

> > > #1: Need to deal with nested for_every_part loops. What will this do:
> > >     for_every_part { if (some test here) { for_every_part { ... } } }
> > 
> > My inclination is to ban them, or at least allow an implementation-defined
> > limit which can be set to 1. (Actually, such a limit is allowed implicitly for
> > almost anything in sieve by the base spec.)
> 
> 
> I would like the nested for_every_part to operate on the child nodes
> of the current context body part, not always operate on all the body
> parts of the root message.  This to me is the obvious behaviour.  If
> Ned wants to (understandably) ban them from his implementation, that's
> fine by me ;o) 

I don't see the point.  for_every_part will recurse through all headers,
so you'll do the test everywhere anyway.  if you like, you can set a
variable[1] and conditionally run "for_every_part" once more afterwards.
if "for_every_part" allowed you to restrict recursion (ie. a modifier
":onelevel"), I can possibly see the utility of nested calls.

[1] of course not guaranteed to be available, but assuming
implementation support, if the admin turned off variables, he's not
likely to support mime loops either.

> Although it isn't very explicit, I think I'm right in saying the
> default match type for mime is "is"?  So that means if :type matches
> against type/subtype, then I would be very confused if I wrote :type
> "text" and it didn't match against text/plain.

I'd think :type "text" was a syntax error or at best a leftover from RFC
1049.  I'd expect the "text/*" syntax I see for MIME types everywhere
else, but of course ":is" must (probably MUST, but I didn't check) be
the default match type for consistency with the rest of Sieve.

> I suggest:
> - :type to match against type, 
> - :subtype to match against subtype
> - :contenttype to match against type/subtype

my suggestion:

      * :type to match against full "media type/subtype"
      * :mediatype to match against just "media type"
      * :subtype to match against just "subtype"

although I _really_ think the latter two are redundant.
-- 
Kjetil T.

--=-h7Ln7RcOAxUVddDOzd9t
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.10.0">
</HEAD>
<BODY>
On Fri, 2006-03-24 at 13:10 +0000, Nigel Swinson wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">&gt; &gt; #1: Need to deal with nested for_every_part loops. What will this do:</FONT>
<FONT COLOR="#000000">&gt; &gt;     for_every_part { if (some test here) { for_every_part { ... } } }</FONT>
<FONT COLOR="#000000">&gt; </FONT>
<FONT COLOR="#000000">&gt; My inclination is to ban them, or at least allow an implementation-defined</FONT>
<FONT COLOR="#000000">&gt; limit which can be set to 1. (Actually, such a limit is allowed implicitly for</FONT>
<FONT COLOR="#000000">&gt; almost anything in sieve by the base spec.)</FONT>

</PRE>
    <FONT COLOR="#000000">I would like the nested for_every_part to operate on the child nodes of the current context body part, not always operate on all the body parts of the root message.  This to me is the obvious behaviour.  If Ned wants to (understandably) ban them from his implementation, that's fine by me ;o) </FONT><BR>
</BLOCKQUOTE>
<BR>
I don't see the point.&nbsp;<TT> for_every_part</TT> will recurse through all headers, so you'll do the test everywhere anyway.&nbsp; if you like, you can set a variable[1] and conditionally run &quot;<TT>for_every_part</TT>&quot; once more afterwards.&nbsp; if &quot;<TT>for_every_part</TT>&quot; allowed you to restrict recursion (ie. a modifier &quot;<TT>:onelevel</TT>&quot;), I can possibly see the utility of nested calls.<BR>
<BR>
[1] of course not guaranteed to be available, but assuming implementation support, if the admin turned off variables, he's not likely to support mime loops either.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    <FONT COLOR="#000000">Although it isn't very explicit, I think I'm right in saying the default match type for mime is &quot;is&quot;?  So that means if :type matches against type/subtype, then I would be very confused if I wrote :type &quot;text&quot; and it didn't match against text/plain.</FONT>
</BLOCKQUOTE>
<PRE>

</PRE>
I'd think <TT>:type &quot;text&quot;</TT> was a syntax error or at best a leftover from RFC 1049.&nbsp; I'd expect the &quot;<TT>text/*</TT>&quot; syntax I see for MIME types everywhere else, but of course &quot;<TT>:is</TT>&quot; must (probably MUST, but I didn't check) be the default match type for consistency with the rest of Sieve.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">I suggest:</FONT>
<FONT COLOR="#000000">- :type to match against type, </FONT>
<FONT COLOR="#000000">- :subtype to match against subtype</FONT>
<FONT COLOR="#000000">- :contenttype to match against type/subtype</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
my suggestion:
<>
    <LI><TT>:type</TT> to match against full &quot;<I>media type/subtype</I>&quot;
    <LI><TT>:mediatype</TT> to match against just &quot;<I>media type</I>&quot;
    <LI><TT>:subtype</TT> to match against just &quot;<I>subtype</I>&quot;
</UL>
<BR>
although I _<B>really</B>_ think the latter two are redundant.<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<PRE>
-- 
Kjetil T.

</PRE>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>

--=-h7Ln7RcOAxUVddDOzd9t--

Cc: Ned Freed <[email-masked]>, [email-masked]
To: Kjetil Torgrim Homme <[email-masked]>
Date: Sat, 25 Mar 2006 09:26:25 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: document status: 3028bis, body, editheader
Sender: [email-masked]

> On Wed, 2006-03-22 at 16:12 -0800, Ned Freed wrote:
> > > I find the description of the awkwardness of "\\" highly amusing
> > > juxtaposed with the requirement of all tests in Sieve[1] to have the
> > > argument :comparator "i;basic;uca=3.1.1;uv=3.2" (and the matching
> > > "require" statement).
> >
> > One man's meat is another man's poison... There are plenty of scripts that
> > depend on comparators continuing to work the way they always have.

> that doesn't mean we can't find a better way than the above.

Even assuming we can "find a better way" (we haven't done so thus far) for
future scripts to use, the installed base issue remains.

> I thought Dave Cridland's suggestion to specify matching behaviour in
> the comparator itself was intriguing:

> http://permalink.gmane.org/gmane.ietf.mta-filters/2689

> unfortunately, [draft-newman-i18n-comparator-08] says «the equality test
> MUST be reflexive, symmetric and transitive», so "EQUAL" can't be used.
> I must admit I don't quite understand how :matches and :regex work with
> comparators, though.

I think of it this way: A comparator has as one of it's components a
normalization operation. Pull that operation out, apply it, and then perform
the glob or regex operation on the result. Note that the output of the
normalization is best seen as a series of nonnegative integers or someting
similar, not octets or characters.

> another possibility is to have a capability which adds an action which
> changes the default comparator to reduce the verbosity.

It makes scripts a bit shorter, but at the expense of having something with
far-reaching impact specified at the top and not where the impact is felt. I'm
far from convinced this is a good tradeoff.

> another possibility is to allow the wildcard comparator, so
> that :comparator "*" «[selects] the collation with the broadest scope
> (preferably international scope), the most recent table versions and the
> greatest number of supported operations.»  (the comparators the server
> chooses from would have to be "require"d in advance, I think, although
> «require "comparator-*"» is a possibility)

I really don't like this - now you have scripts working in subtlely different 
ways in different places. This is big steps backwards, I think.

> > > to be honest, I find it absurd that such verbiage
> > > is forced upon users.  we need to find a better way.
> >
> > > [1] outside of the US of A, anyway.
> >
> > This has nothing to do with geography and everything to do with backwards
> > compatibility. Some of the scripts I'm referring to were written and are used
> > outside the US.
> >
> > And good luck using i;basic;uca=3.1.1;uv=3.2 to trap specific sequences of
> > illegal 8bit in headers. Such stuff is rarely if ever in UTF-8, in my
> > experience at least.

> this is impossible today, isn't it?

It is done all the time and the base specification allows it, more or less.

> how do you specify the string to compare with?

You just do it. Nothing in the current sieve specification says that it is an
error to specify material that isn't valid utf-8. (This is now prohibited by
the ABNF in the revised base specification, and IMO this restriction needs to
be removed for string constants. It is at a minimum in direct conflict with the
vacation specification.)

> in any case, if you want to trap raw non-UTF8 in headers,
> you should use i;octet.

Agreed, but in practice scripts often don't specify this.

>  but then again:

> 5.7.  Octet Collation

>    The i;octet (Section 9.5) collation is only usable with protocols
>    based on octet-strings.  Clients and servers MUST NOT use i;octet
>    with other protocols.

> which would disqualify the use of i;octet with Sieve, since 3028bis says:

>    The language is represented in UTF-8, as specified in [UTF-8].

Represent doesn't mean things are restricted to UTF-8. If it did it would be in
direct conflict with later language in the same document, which quite
specifically allows material in other charsets in strings.

The wording is a bit peculiar (and it needs to be clarified in the revision),
but the intent here was for UTF-8 to always be assumed when it was necessary to
assume a charset. So, in something like a string argument to fileinto, the
argument is to be interpreted in utf-8, never anything else. But in something
like, say, a whole MIME object, you have to be able to specify stuff in other
charsets.

Now, the base specification doesn't come out and say you can use this ability
in a header test. So I suppose it can be argued that it is more or less open as
to how an implementation should behave when this is done, which is why I said
"more or less" previously.

> the collation-draft exempts RFC 3028 from this "MUST NOT", but it's not
> clear to me that a 3028bis can get the same exemption.

It better or backwards compaatibility goes down the toilet, which is not
acceptable as far as I'm concerned.

> notice that
> "represented in UTF-8" only means constant strings can't contain raw
> octets which are illegal UTF-8 sequences.

I disagree 100% that that is what it means. And since the specification later
talks about putting non-UTF-8 material in constant strings in section 2.4.2.4,
it seems it agrees with me.

> which brings us back to the
> discussion on character escapes from a year ago.

> http://comments.gmane.org/gmane.ietf.mta-filters/2030

> I'd like to suggest we implement (2), but with the extension defined in
> the base spec.

I have no problem with this and would like to see it happen, but it may or may
not be relevant to the matter at hand. Regardless of whether you write some
sequence that's illegal in UTF-8 directly as a series of octets in a string
constant or indirectly using some sort of encoding, you're still presenting the
sieve interpreter with text that isn't in utf-8 at some level. Any attempt to
enforce some sort of rule that nothing but utf-8 can be present is still going
to fail. And any +Unnnn sort of scheme is inherently incapable of representing
UTF-8 anyway.

The ability to write octets using some sort of encoding is certainly helpful
when the script is presented in an editor or otherwise displayed. And the
intent of the resulting script is much much much clearer. That's why I support
the extension, not because it adds a capability that isn't there now.

> note that if the base spec adds the restriction on
> extensions that they can't modify other "require" statements, the
> analysis of string escapes can be performed statically by a byte
> compiler.

Agreed.

				Ned

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 24 Mar 2006 15:35:30 -0500
To: Nigel Swinson <[email-masked]>
Cc: Tony Hansen <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: Sieve mime loop issues list
Sender: [email-masked]

On Fri, Mar 24, 2006 at 01:10:58PM -0000, Nigel Swinson wrote:
> > > #1: Need to deal with nested for_every_part loops. What will this do:
> > >     for_every_part { if (some test here) { for_every_part { ... } } }
> > 
> > My inclination is to ban them, or at least allow an implementation-defined
> > limit which can be set to 1. (Actually, such a limit is allowed implicitly for
> > almost anything in sieve by the base spec.)
> 
> I would like the nested for_every_part to operate on the child nodes
> of the current context body part, not always operate on all the body
> parts of the root message.  This to me is the obvious behaviour.  If Ned
> wants to (understandably) ban them from his implementation, that's fine
> by me ;o)

I agree.  Whether script writers will actually make use of such a
construct may be in question, but I am in favor of at least not
prohibiting it.  Per above, the draft could say that an implementation
must only support only 1 level of nesting but may support more.

> 
> > > #2: Need to decide if there would be a "mime" shorthand for testing the
> > > type/subtype, without requiring
> > 
> > >     if allof (mime :type "multipart", mime :subtype "alternative") ?
> > 
> > How about getting rid of :subtype and making :type check the whole thing? A
> > subtype is only meaningful in the context of a particular type; the only
> > exception to this are suffix tags, and checking those would require :matches
> > anyway. 
> >
> > And :matches can easily be used to check the primary type by itself. I see no
> > strong reason to prefer
> > 
> >     if mime :type "text" ...
> > 
> > over
> > 
> >     if mime :type :matches "text/*" ...
>  
> Although it isn't very explicit, I think I'm right in saying the
> default match type for mime is "is"?  So that means if :type matches
> against type/subtype, then I would be very confused if I wrote :type
> "text" and it didn't match against text/plain.

This because the word ":type" makes one think of "type" part of the
content type description?  (i.e., with a different :tag you wouldn't be
as confused?)  Personally I don't see it as all that confusing, but I
see the point, and a different :name would be reasonable.

> I suggest:
> - :type to match against type, 
> - :subtype to match against subtype
> - :contenttype to match against type/subtype

Having just one that selects the entire type/subtype string, allowing
the application of different match-types to the test, would make :type
and :subtype options somewhat redundant.  However, having :type and
:subtype don't really hurt, and are easy to implement.  But I think the
most important point is to have an option to test the entire string,
since as I mentioned

    allof (mime :anychild :type "multipart",
           mime :anychild :subtype "alternative")
and
    mime :anychild :contenttype "multipart/alternative"

are not necessarily equivalent (if the sub-tests of the first one match
different children).  Granted, there aren't that many subtypes that are
duplicated across the mime types world, and the above is not the best
example (maybe something with "xml" would be better), but that doesn't
mean we shouldn't be able to have a reliable atomic test.

> I prefer
> >     header :mime
> >     exists :mime
> >     address :mime
> Over 
> >    mimeheader
> >    mimeexists
> >    mimeaddress

ditto

-mm-

Date: Fri, 24 Mar 2006 12:01:16 -0500
From: Cyrus Daboo <[email-masked]>
To: Nigel Swinson <[email-masked]>, Tony Hansen <[email-masked]>
cc: IETF MTA Filters List <[email-masked]>
Subject: Re: Sieve mime loop issues list
Sender: [email-masked]

Hi Nigel,

--On March 24, 2006 12:10:58 PM +0000 Nigel Swinson 
<[email-masked]> wrote:

> I prefer
>>     header :mime
>>     exists :mime
>>     address :mime
> Over
>>    mimeheader
>>    mimeexists
>>    mimeaddress

I prefer your preference too - since I will be updating the doc I will go 
ahead with this approach unless there are any objections.

-- 
Cyrus Daboo

Date: Fri, 24 Mar 2006 15:56:36 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Generalizing subaddress
Cc: Ken Murchison <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Hm.

Arnt

Date: Fri, 24 Mar 2006 15:47:11 +0100
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: Generalizing subaddress
Sender: [email-masked]

I suggest:

Exactly.

Michael

Date: Fri, 24 Mar 2006 13:54:59 +0000
Subject: Re: Generalizing subaddress
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Ken Murchison <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Dave.

Date: Fri, 24 Mar 2006 14:43:29 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Generalizing subaddress
Cc: Ken Murchison <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Agreed.

Arnt

Date: Fri, 24 Mar 2006 13:13:30 +0000
Subject: Re: Generalizing subaddress
From: Dave Cridland <[email-masked]>
To: Ken Murchison <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Dave.

From: "Nigel Swinson" <[email-masked]>
To: "Tony Hansen" <[email-masked]>
Cc: "IETF MTA Filters List" <[email-masked]>
Subject: Re: Sieve mime loop issues list
Date: Fri, 24 Mar 2006 13:10:58 -0000
Sender: [email-masked]

> > #1: Need to deal with nested for_every_part loops. What will this do:
> >     for_every_part { if (some test here) { for_every_part { ... } } }
> 
> My inclination is to ban them, or at least allow an implementation-defined
> limit which can be set to 1. (Actually, such a limit is allowed implicitly for
> almost anything in sieve by the base spec.)

I would like the nested for_every_part to operate on the child nodes of the current context body part, not always operate on all the body parts of the root message.  This to me is the obvious behaviour.  If Ned wants to (understandably) ban them from his implementation, that's fine by me ;o) 

> > #2: Need to decide if there would be a "mime" shorthand for testing the
> > type/subtype, without requiring
> 
> >     if allof (mime :type "multipart", mime :subtype "alternative") ?
> 
> How about getting rid of :subtype and making :type check the whole thing? A
> subtype is only meaningful in the context of a particular type; the only
> exception to this are suffix tags, and checking those would require :matches
> anyway. 
>
> And :matches can easily be used to check the primary type by itself. I see no
> strong reason to prefer
> 
>     if mime :type "text" ...
> 
> over
> 
>     if mime :type :matches "text/*" ...

Although it isn't very explicit, I think I'm right in saying the default match type for mime is "is"?  So that means if :type matches against type/subtype, then I would be very confused if I wrote :type "text" and it didn't match against text/plain.

I suggest:
- :type to match against type, 
- :subtype to match against subtype
- :contenttype to match against type/subtype

> > #3: We need to add some way to look at parameter lists:
> >     Content-Type: text/plain; charset="foo"

I currently have:

 MimeClause ::= "x_mime" [COMPARATOR] [MATCH-TYPE]
 <header-list: string-list> [<parameter-list: string-list>] <key-list: string-list>
 MimeClause ::= "x_mime" :filename <key-list: string-list>
 MimeClause ::= "x_mime" :type <key-list: string-list>
 MimeClause ::= "x_mime" :subtype <key-list: string-list>

So if you don't have a :type/:subtype/:filename, then you must specify a list of header names, a list of parameter names, and the search strings.  "type" and "subtype" are supported as psuedo parameter names of the bit before the first ";".  If there are no parameter names, then it matches against the text before the first ";".  :type/:subtype/:filename then become short hands:

mime :type "text"
mime "Content-Type" "type" "text

mime :subtype "plain"
mime "Content-Type" "subtype" "plain"

mime :filename "junk.txt"
anyof (
    mime "Content-Disposition" "filemane""junk.txt"'
    mime "Content-Type" "name" "junk.txt"
)
 
> > The following issues/comments were raised at the meeting:
> >     interactions with variables
> >     notifications
> >     notifications to calendar service
> >     address tests, exists tests
> >     add tests mimeheader, mimeparameter
> 

I prefer

>     header :mime
>     exists :mime
>     address :mime

Over 

>    mimeheader
>    mimeexists
>    mimeaddress
> 
> but I do want to see some way to do address and exists tests on inner
> headers. This is actually quite a bit more important than a parameter
> test IMO.

I agree

Nigel

Cc: Ned Freed <[email-masked]>, IETF MTA Filters List <[email-masked]>
To: Philip Guenther <[email-masked]>
Date: Thu, 23 Mar 2006 17:26:01 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Sieve mime loop issues list
Sender: [email-masked]

> Ned Freed <[email-masked]> writes:
> >> #3: We need to add some way to look at parameter lists:
> >>     Content-Type: text/plain; charset="foo"
> >
> >Agreed, but mostly because of RFC 2231.

> It also avoids problems with comments and quoting (dang structured fields!).

> ...
> >but I do want to see some way to do address and exists tests on inner
> >headers. This is actually quite a bit more important than a parameter
> >test IMO.

> Do you mean "the MIME header of inner parts" or do you mean "the
> headers of nested message/rfc822 parts"?   If both, how should they
> be differentiated?

AFAIK we have not defined a field that involves an address for a MIME
part. So unless you want to avoid false matches on bogons in MIME parts,
I don't think this makes a difference.

In any case, you probably could rig up something to only test message/rfc822
parts using variables, assuming the traversal is top-down.

Chris Newman also suggests renaming this as foreach, in order to make it
clearer we're still not Turing-complete.

				Ned

To: Ned Freed <[email-masked]>
Cc: IETF MTA Filters List <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Sieve mime loop issues list 
Date: Thu, 23 Mar 2006 16:56:46 -0800
Sender: [email-masked]

Ned Freed <[email-masked]> writes:
>> #3: We need to add some way to look at parameter lists:
>>     Content-Type: text/plain; charset="foo"
>
>Agreed, but mostly because of RFC 2231.

It also avoids problems with comments and quoting (dang structured fields!).

...
>but I do want to see some way to do address and exists tests on inner
>headers. This is actually quite a bit more important than a parameter
>test IMO.

Do you mean "the MIME header of inner parts" or do you mean "the
headers of nested message/rfc822 parts"?   If both, how should they
be differentiated?

Philip Guenther

Date: Thu, 23 Mar 2006 19:25:37 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked]
Subject: Generalizing subaddress
Sender: [email-masked]

Cc: IETF MTA Filters List <[email-masked]>
To: Tony Hansen <[email-masked]>
Date: Thu, 23 Mar 2006 15:30:29 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Sieve mime loop issues list
Sender: [email-masked]

> Here is the list of issues with the MIME LOOP draft that need to be
> worked on, as discussed at the Sieve meeting this week.

> #1: Need to deal with nested for_every_part loops. What will this do:
>     for_every_part { if (some test here) { for_every_part { ... } } }

My inclination is to ban them, or at least allow an implementation-defined
limit which can be set to 1. (Actually, such a limit is allowed implicitly for
almost anything in sieve by the base spec.)

> #2: Need to decide if there would be a "mime" shorthand for testing the
> type/subtype, without requiring

>     if allof (mime :type "multipart", mime :subtype "alternative") ?

How about getting rid of :subtype and making :type check the whole thing? A
subtype is only meaningful in the context of a particular type; the only
exception to this are suffix tags, and checking those would require :matches
anyway. That is, there's no practical difference between

    if mime :subtype :matches "*+xml" ...

and

    if mime :type : matches "*+xml" ...

And :matches can easily be used to check the primary type by itself. I see no
strong reason to prefer

    if mime :type "text" ...

over

    if mime :type :matches "text/*" ...

> #3: We need to add some way to look at parameter lists:
>     Content-Type: text/plain; charset="foo"

Agreed, but mostly because of RFC 2231.

> The following issues/comments were raised at the meeting:
>     interactions with variables
>     notifications
>     notifications to calendar service
>     address tests, exists tests
>     add tests mimeheader, mimeparameter

I'll repeat that I have no real preference between

    header :mime
    exists :mime
    address :mime

and

   mimeheader
   mimeexists
   mimeaddress

but I do want to see some way to do address and exists tests on inner
headers. This is actually quite a bit more important than a parameter
test IMO.

				Ned

Date: Thu, 23 Mar 2006 16:59:59 -0500
From: Tony Hansen <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
Subject: Sieve mime loop issues list
Sender: [email-masked]

Here is the list of issues with the MIME LOOP draft that need to be
worked on, as discussed at the Sieve meeting this week.

#1: Need to deal with nested for_every_part loops. What will this do:
    for_every_part { if (some test here) { for_every_part { ... } } }

#2: Need to decide if there would be a "mime" shorthand for testing the
type/subtype, without requiring

    if allof (mime :type "multipart", mime :subtype "alternative") ?

#3: We need to add some way to look at parameter lists:
    Content-Type: text/plain; charset="foo"

The following issues/comments were raised at the meeting:
    interactions with variables
    notifications
    notifications to calendar service
    address tests, exists tests
    add tests mimeheader, mimeparameter

	Tony Hansen
	[email-masked]

Subject: Re: document status: 3028bis, body, editheader
From: Kjetil Torgrim Homme <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: [email-masked]
Date: Thu, 23 Mar 2006 06:07:47 +0100
Sender: [email-masked]

On Wed, 2006-03-22 at 16:12 -0800, Ned Freed wrote:
> > I find the description of the awkwardness of "\\" highly amusing
> > juxtaposed with the requirement of all tests in Sieve[1] to have the
> > argument :comparator "i;basic;uca=3.1.1;uv=3.2" (and the matching
> > "require" statement).
> 
> One man's meat is another man's poison... There are plenty of scripts that
> depend on comparators continuing to work the way they always have.

that doesn't mean we can't find a better way than the above.

I thought Dave Cridland's suggestion to specify matching behaviour in
the comparator itself was intriguing:

http://permalink.gmane.org/gmane.ietf.mta-filters/2689

unfortunately, [draft-newman-i18n-comparator-08] says «the equality test
MUST be reflexive, symmetric and transitive», so "EQUAL" can't be used.
I must admit I don't quite understand how :matches and :regex work with
comparators, though.

another possibility is to have a capability which adds an action which
changes the default comparator to reduce the verbosity.

another possibility is to allow the wildcard comparator, so
that :comparator "*" «[selects] the collation with the broadest scope
(preferably international scope), the most recent table versions and the
greatest number of supported operations.»  (the comparators the server
chooses from would have to be "require"d in advance, I think, although
«require "comparator-*"» is a possibility)

> > to be honest, I find it absurd that such verbiage
> > is forced upon users.  we need to find a better way.
> 
> > [1] outside of the US of A, anyway.
> 
> This has nothing to do with geography and everything to do with backwards
> compatibility. Some of the scripts I'm referring to were written and are used
> outside the US.
> 
> And good luck using i;basic;uca=3.1.1;uv=3.2 to trap specific sequences of
> illegal 8bit in headers. Such stuff is rarely if ever in UTF-8, in my
> experience at least.

this is impossible today, isn't it?  how do you specify the string to
compare with?  in any case, if you want to trap raw non-UTF8 in headers,
you should use i;octet.  but then again:

5.7.  Octet Collation

   The i;octet (Section 9.5) collation is only usable with protocols
   based on octet-strings.  Clients and servers MUST NOT use i;octet
   with other protocols.

which would disqualify the use of i;octet with Sieve, since 3028bis says:

   The language is represented in UTF-8, as specified in [UTF-8].

the collation-draft exempts RFC 3028 from this "MUST NOT", but it's not
clear to me that a 3028bis can get the same exemption.  notice that
"represented in UTF-8" only means constant strings can't contain raw
octets which are illegal UTF-8 sequences.  which brings us back to the
discussion on character escapes from a year ago.

http://comments.gmane.org/gmane.ietf.mta-filters/2030

I'd like to suggest we implement (2), but with the extension defined in
the base spec.  note that if the base spec adds the restriction on
extensions that they can't modify other "require" statements, the
analysis of string escapes can be performed statically by a byte
compiler.
-- 
Kjetil T.

Cc: Philip Guenther <[email-masked]>, [email-masked]
To: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 22 Mar 2006 16:12:07 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: document status: 3028bis, body, editheader
Sender: [email-masked]

> On Mon, 2006-03-20 at 22:59 -0800, Philip Guenther wrote:
> > I've made one tweak for the next rev to the wording in section 2.7.1
> > regarding ':match' and the definition of 'character'; I had overlooked
> > an off-list comment at the turn of the year.  The paragraph now
> > reads:
> >    The ":matches" match type specifies a wildcard match using the
> >    characters "*" and "?"; the entire value must be matched.  "*"
> >    matches zero or more characters in the value and "?" matches a single
> >    character in the value, where the comparator that is used (see 2.7.3)
> >    defines what a character is.  For example, the comparators "i;octet"
> >    and "en;ascii-casemap" define a character to be a single octet so "?"
> >    will always match exactly one octet when one of those comparators is
> >    in use.  In contrast, the comparator "i;basic;uca=3.1.1;uv=3.2"
> >    defines a character to be any UTF-8 octet sequence encoding one
> >    Unicode character and thus "?" may match more than one octet.  "?"
> >    and "*" may be escaped as "\\?" and "\\*" in strings to match against
> >    themselves.  The first backslash escapes the second backslash;
> >    together, they escape the "*".  This is awkward, but it is
> >    commonplace in several programming languages that use globs and
> >    regular expressions.

> I find the description of the awkwardness of "\\" highly amusing
> juxtaposed with the requirement of all tests in Sieve[1] to have the
> argument :comparator "i;basic;uca=3.1.1;uv=3.2" (and the matching
> "require" statement).

One man's meat is another man's poison... There are plenty of scripts that
depend on comparators continuing to work the way they always have.

  to be honest, I find it absurd that such verbiage
> is forced upon users.  we need to find a better way.

> [1] outside of the US of A, anyway.

This has nothing to do with geography and everything to do with backwards
compatibility. Some of the scripts I'm referring to were written and are used
outside the US.

And good luck using i;basic;uca=3.1.1;uv=3.2 to trap specific sequences of
illegal 8bit in headers. Such stuff is rarely if ever in UTF-8, in my
experience at least.

				Ned

Cc: Philip Guenther <[email-masked]>, [email-masked]
To: Alexey Melnikov <[email-masked]>
Date: Wed, 22 Mar 2006 15:54:25 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: 3028bis: post-meeting changes
Sender: [email-masked]

> Philip Guenther wrote:

> >These are in response to the discussions earlier today in Dallas.
> >The log of the jabber room can be found at:
> >	http://www.ietf.org/meetings/ietf-logs/[email-masked]/2006-03-21.html
> >
> >
> >Opinions on any of the following, whether yeah or nay, are appreciated,
> >especially on the last point.
> >
> >
> >1. The first paragraph of section 4.1 ("Action fileinto") now reads:
> >
> >   The "fileinto" action delivers the message into the specified folder.
> >   Implementations SHOULD support fileinto, but in some environments
> >   this may be impossible.  Implementations MAY place restrictions on
> >   folder names; use of an invalid folder name MAY be treated as an
> >   error or result in delivery to an implementation-defined folder.  If
> >   the implementation uses a different encoding scheme than UTF-8 for
> >   folder names, it SHOULD reencode the folder name from UTF-8 to its
> >   encoding scheme.  For example, the Internet Message Access Protocol
> >   [IMAP] uses modified UTF-7, such that a folder argument of "odds &
> >   ends" would appear in IMAP as "odds &- ends".
> >
> >
> I like that.

So do I. +1.

> >(Hmm, need to tweak the line wrap...)
> >
> >
> >2. In the Security Considerations section, I've added:
> >
> >    Use of the "redirect" command to generate notifications may
> >    easily overwhelm the target address, especially if it was not
> >    designed to handle large message.
> >
> >
> This is intentionally vague, but it is probably Ok with me.

Agree, but s/message./messages./

				Ned

Subject: Re: document status: 3028bis, body, editheader
From: Kjetil Torgrim Homme <[email-masked]>
To: Philip Guenther <[email-masked]>
Cc: [email-masked]
Date: Wed, 22 Mar 2006 23:24:33 +0100
Sender: [email-masked]

On Mon, 2006-03-20 at 22:59 -0800, Philip Guenther wrote:
> I've made one tweak for the next rev to the wording in section 2.7.1
> regarding ':match' and the definition of 'character'; I had overlooked
> an off-list comment at the turn of the year.  The paragraph now
> reads:
>    The ":matches" match type specifies a wildcard match using the
>    characters "*" and "?"; the entire value must be matched.  "*"
>    matches zero or more characters in the value and "?" matches a single
>    character in the value, where the comparator that is used (see 2.7.3)
>    defines what a character is.  For example, the comparators "i;octet"
>    and "en;ascii-casemap" define a character to be a single octet so "?"
>    will always match exactly one octet when one of those comparators is
>    in use.  In contrast, the comparator "i;basic;uca=3.1.1;uv=3.2"
>    defines a character to be any UTF-8 octet sequence encoding one
>    Unicode character and thus "?" may match more than one octet.  "?"
>    and "*" may be escaped as "\\?" and "\\*" in strings to match against
>    themselves.  The first backslash escapes the second backslash;
>    together, they escape the "*".  This is awkward, but it is
>    commonplace in several programming languages that use globs and
>    regular expressions.

I find the description of the awkwardness of "\\" highly amusing
juxtaposed with the requirement of all tests in Sieve[1] to have the
argument :comparator "i;basic;uca=3.1.1;uv=3.2" (and the matching
"require" statement).  to be honest, I find it absurd that such verbiage
is forced upon users.  we need to find a better way.

[1] outside of the US of A, anyway.
-- 
Kjetil T.

Subject: Re: 3028bis: post-meeting changes
From: Kjetil Torgrim Homme <[email-masked]>
To: Philip Guenther <[email-masked]>
Cc: [email-masked]
Date: Wed, 22 Mar 2006 23:05:51 +0100
Sender: [email-masked]

On Tue, 2006-03-21 at 19:09 -0800, Philip Guenther wrote:
>    encoding scheme.  For example, the Internet Message Access Protocol
>    [IMAP] uses modified UTF-7, such that a folder argument of "odds &
>    ends" would appear in IMAP as "odds &- ends".

the added text is good, but s/such/so/ ?  (I'm not a native speaker ...)

> 2. In the Security Considerations section, I've added:
> 
>     Use of the "redirect" command to generate notifications may
>     easily overwhelm the target address, especially if it was not
>     designed to handle large message.

if the target is just a plain e-mail account, this sounds like a bizarre
caveat, so perhaps "target service" or "target system" is better to get
into the right context.  (also s/message/messages/)

> Concerns about different capabilities enabling the same action or
> test are better addressed, IMHO, by reexamining the naming and
> review policy for the registry.
> 
> For example, perhaps we should
> 1) adjust the vendor namespace rules to instead be FCFS registration
>    of trees ("vnd.acme.*"),
> 2) break out a namespace for draft extensions (ala Alexey's
>    "X-DRAFT-[IW]#-name" proposal for IMAP extension drafts), and
> 3) switch the rest of the namespace from FCFS to Specification
>    required or IETF Consensus (c.f. RFC 2434)
> 
> I included (2) because we've had problems with extensions that saw
> significant change after a long period of statis (e.g., 'notify'
> and 'imapflags'), but perhaps the above is an overreaction.

all of these seem like overkill to me.

we could either suggest a version number be part of all capability
names, or we could just say the suffix "" is version 1, and tack on "2",
"3" etc as needed for the next versions.  we don't have to be creative
with every new "next generation" capability.
-- 
Kjetil T.

Date: Wed, 22 Mar 2006 13:51:37 -0800
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: [email-masked]
Subject: Re: 3028bis: post-meeting changes
Sender: [email-masked]

Philip Guenther wrote:

>
>Concerns about different capabilities enabling the same action or
>test are better addressed, IMHO, by reexamining the naming and
>review policy for the registry.
>
>For example, perhaps we should
>1) adjust the vendor namespace rules to instead be FCFS registration
>   of trees ("vnd.acme.*"),
>2) break out a namespace for draft extensions (ala Alexey's
>   "X-DRAFT-[IW]#-name" proposal for IMAP extension drafts), and
>3) switch the rest of the namespace from FCFS to Specification
>   required or IETF Consensus (c.f. RFC 2434)
>
>I included (2) because we've had problems with extensions that saw
>significant change after a long period of statis (e.g., 'notify'
>and 'imapflags'), but perhaps the above is an overreaction.
>
Sounds good to me.

Date: Wed, 22 Mar 2006 13:50:30 -0800
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: [email-masked]
Subject: Re: 3028bis: post-meeting changes
Sender: [email-masked]

Philip Guenther wrote:

>3. IANA template
>
>I think we should simply drop the "Capability name" and "Capability
>arguments" fields, leaving:
>
The proposal from the meeting was:
Have a require capability name.
Have a short description of what an extension does.
Have separate lists for all new tests/actions/etc., so that we can avoid 
incompatible action/test/etc. names between multiple extensions.

>   Capability keyword:
>   Standards Track/IESG-approved experimental RFC number:
>   Person and email address to contact for further information:
>
>As I see it, there are two major concerns for the registry:
> 1) capabilities should be unique, so that require "foo" has the
>    same meaning everywhere it works
> 2) given a standardized capability, you need to be able to find
>    the current RFC describing it
>
>Concerns about different capabilities enabling the same action or
>test are better addressed, IMHO, by reexamining the naming and
>review policy for the registry.
>
I still think have a single true place for listing all actions/tests is 
a good thing.

Date: Wed, 22 Mar 2006 13:43:09 -0800
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: [email-masked]
Subject: Re: 3028bis: post-meeting changes
Sender: [email-masked]

Philip Guenther wrote:

>These are in response to the discussions earlier today in Dallas.
>The log of the jabber room can be found at:
>	http://www.ietf.org/meetings/ietf-logs/[email-masked]/2006-03-21.html
>
>
>Opinions on any of the following, whether yeah or nay, are appreciated,
>especially on the last point.
>
>
>1. The first paragraph of section 4.1 ("Action fileinto") now reads:
>
>   The "fileinto" action delivers the message into the specified folder.
>   Implementations SHOULD support fileinto, but in some environments
>   this may be impossible.  Implementations MAY place restrictions on
>   folder names; use of an invalid folder name MAY be treated as an
>   error or result in delivery to an implementation-defined folder.  If
>   the implementation uses a different encoding scheme than UTF-8 for
>   folder names, it SHOULD reencode the folder name from UTF-8 to its
>   encoding scheme.  For example, the Internet Message Access Protocol
>   [IMAP] uses modified UTF-7, such that a folder argument of "odds &
>   ends" would appear in IMAP as "odds &- ends".
>  
>
I like that.

>(Hmm, need to tweak the line wrap...)
>
>
>2. In the Security Considerations section, I've added:
>
>    Use of the "redirect" command to generate notifications may
>    easily overwhelm the target address, especially if it was not
>    designed to handle large message.
>  
>
This is intentionally vague, but it is probably Ok with me.

Cc: [email-masked]
To: Michael Haardt <[email-masked]>
Date: Wed, 22 Mar 2006 12:33:41 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: document status: 3028bis, body, editheader
Sender: [email-masked]

> On Wed, Mar 22, 2006 at 11:07:55AM -0800, Ned Freed wrote:
> > > Fixing the draft to not use "header" when it means "header field"
> > > wouldn't be hard.  Ditto for aligning with 2822 on "field body".
> > > Does anyone actually think that change would be a _bad_ thing?
> >
> > Sure sounds like a good thing to me. However, the material tested by header is
> > not, precisely speaking, the "body of the named header field". There's also
> > unfolding and decoding to consider. I suppose we could say "the unfolded and
> > decoded body of the named header field", although it's a bit of a mouthful.

> Insert a reference to RFC 2822 for unfolding and say MIME-decoded with
> a reference to RFC 2047 instead of decoded to make it worse, and I will
> be happy, too.  Honestly, I am glad for each bit of precision when it
> comes to specifications.

WFM

				Ned

Date: Wed, 22 Mar 2006 21:09:51 +0100
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: document status: 3028bis, body, editheader
Sender: [email-masked]

On Wed, Mar 22, 2006 at 11:07:55AM -0800, Ned Freed wrote:
> > Fixing the draft to not use "header" when it means "header field"
> > wouldn't be hard.  Ditto for aligning with 2822 on "field body".
> > Does anyone actually think that change would be a _bad_ thing?
> 
> Sure sounds like a good thing to me. However, the material tested by header is
> not, precisely speaking, the "body of the named header field". There's also
> unfolding and decoding to consider. I suppose we could say "the unfolded and
> decoded body of the named header field", although it's a bit of a mouthful.

Insert a reference to RFC 2822 for unfolding and say MIME-decoded with
a reference to RFC 2047 instead of decoded to make it worse, and I will
be happy, too.  Honestly, I am glad for each bit of precision when it
comes to specifications.

Michael

Date: Wed, 22 Mar 2006 20:57:10 +0100
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: document status: 3028bis, body, editheader
Sender: [email-masked]

On Wed, Mar 22, 2006 at 05:05:20PM +0100, Arnt Gulbrandsen wrote:
> Could you please elaborate?
> 
> Do you mean that ascii-casemap should consider two octet strings to be 
> equal if they are the same after decoding UTF-8?

That's what I would like indeed, but as I said, it would break all
implementations and for that reason and because RFC 3028 is interpreted
differently by the majority (read: anybody but me in the first place),
I doubt the change can happen.

> Should it do Unicode 
> composition/decomposition?

I don't know what that is, as I don't know much about Unicode at all.
Are you talking about encoding/decoding unicode characters in octets
or something different?

The way you ask implies that there are multiple ways how a unicode
character can be encoded in UTF-8.  Is that correct? I always assumed
UTF-8 was a 1:1 encoding of Unicode.

> As it is, I'm suggesting that 0x80 0x82 is equal to precisely one 
> string, namely 0x80 0x20, and that independently of whether 0x80 0x82 
> is meant to be a character encoded in UTF-8 or something else.

You raise a very interesting point.  How do I match this?

Subject: =?utf-8?q?=80=82?=

That sequence is not valid UTF-8 encoding.  Sieve scripts must be valid
UTF-8, so you can not match the above.  That is fine for comparators
operating on characters, but a true octet-wise comparator will be
crippled.  It has been suggested to encode each of the code points
0x80 and 0x82 in UTF-8 and the comparator had to decode the literal.
Very ugly, and I don't think existing implementations work that way.

As far as I remember, the consensus was: The above is a problem not
worth discussing.  Let Sieve scripts continue to be valid UTF-8, and
let's be unable to match certain values.  If anybody has a problem,
he better invents some kind of "raw" header test.  I agree.

Thus, we can't talk about the octet sequence 0x80 0x82 in Sieve. :-)

But I got distracted.  As long as we consider ":is" or ":contains",
there is no problem really, because both behave the same, no matter
if they decode UTF-8 or just work on octets, as long as we have valid
UTF-8 encoding.  The "?" wildcard is the problem: Should it match an
octet or a character?

Since all (most?) implementations ignore unicode and just work on octets,
"?" matches an octet, too.  Now that is weird to users, because if their
unicode aware client displays a one-character subject, "?" will only match
it if it is an US-ASCII character, and if it is a German umlaut character,
"??" matches it, because those are encoded in two octets.

That's where it becomes obvious if a comparator works on octets or
characters.  RFC 3028 does not specify that as clear as required and
the installed base unfortunately decided for octets, not characters.
The latest 3028bis draft follows that decision, and clearly so.

Of course the comparator specification has the last word on this.  I guess
you see the problem now, and should you decide that "en;ascii-case"
works on characters and "?" matches a unicode character, you had my vote
and I would change my implementation within 5 minutes.  *ducks and hides*

Michael

Cc: Mark E Mallett <[email-masked]>, [email-masked]
To: Philip Guenther <[email-masked]>
Date: Wed, 22 Mar 2006 11:07:55 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: document status: 3028bis, body, editheader
Sender: [email-masked]

> "Mark E. Mallett" <[email-masked]> writes:
> >On Tue, Mar 21, 2006 at 01:37:28PM -0800, Philip Guenther wrote:
> ...
> >> Section 5.7:
> >>    The "header" test evaluates to true if the value of any of the named
> >>    headers, ignoring leading and trailing whitespace, matches any key.
> >
> >Now this brings up the question of what the "value of a header" is.  In
> >RFC2822-speak, it would probably really be the "field body of the named
> >header fields" .  "header" is used a lot in the draft to mean "header
> >field" so that's probably not worth going into (much as I would love to
> >suggest it), but the "value of a header" seems cloudy.  OTOH it's a lot
> >better than the current rfc3028.

> Fixing the draft to not use "header" when it means "header field"
> wouldn't be hard.  Ditto for aligning with 2822 on "field body".
> Does anyone actually think that change would be a _bad_ thing?

Sure sounds like a good thing to me. However, the material tested by header is
not, precisely speaking, the "body of the named header field". There's also
unfolding and decoding to consider. I suppose we could say "the unfolded and
decoded body of the named header field", although it's a bit of a mouthful.

				Ned

To: "Mark E. Mallett" <[email-masked]>
From: Philip Guenther <[email-masked]>
Cc: [email-masked]
Subject: Re: document status: 3028bis, body, editheader 
Date: Wed, 22 Mar 2006 10:40:21 -0800
Sender: [email-masked]

"Mark E. Mallett" <[email-masked]> writes:
>On Tue, Mar 21, 2006 at 01:37:28PM -0800, Philip Guenther wrote:
...
>> Section 5.7:
>>    The "header" test evaluates to true if the value of any of the named
>>    headers, ignoring leading and trailing whitespace, matches any key.
>
>Now this brings up the question of what the "value of a header" is.  In
>RFC2822-speak, it would probably really be the "field body of the named
>header fields" .  "header" is used a lot in the draft to mean "header
>field" so that's probably not worth going into (much as I would love to
>suggest it), but the "value of a header" seems cloudy.  OTOH it's a lot
>better than the current rfc3028.

Fixing the draft to not use "header" when it means "header field"
wouldn't be hard.  Ditto for aligning with 2822 on "field body".
Does anyone actually think that change would be a _bad_ thing?

...
>BTW I notice that in 5.1:
>
>   The address test matches Internet addresses ...
>
>this is the only one of the descriptions in section 5 that doesn't put
>the verb in quotes in its opening sentence.  <..>

Fixed.  I've also fixed the 'anyof' and 'allof' tests to match.

Philip Guenther

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 22 Mar 2006 13:12:07 -0500
To: Philip Guenther <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: document status: 3028bis, body, editheader
Sender: [email-masked]

On Tue, Mar 21, 2006 at 01:37:28PM -0800, Philip Guenther wrote:
> Alexey Melnikov <[email-masked]> writes:
> ...
> >I think you've missed a couple of issues I've reported:
> >1). I can't see any text about stripping leading/trailing whitespaces 
> >(text moved from the relational extension)
> 
> Section 5.7:
>    The "header" test evaluates to true if the value of any of the named
>    headers, ignoring leading and trailing whitespace, matches any key.

Now this brings up the question of what the "value of a header" is.  In
RFC2822-speak, it would probably really be the "field body of the named
header fields" .  "header" is used a lot in the draft to mean "header
field" so that's probably not worth going into (much as I would love to
suggest it), but the "value of a header" seems cloudy.  OTOH it's a lot
better than the current rfc3028.  To illustrage (not very good, but clearer):

    The "header" test compares the body of the named headers against the
    specified keys.  For the purpose of this test, The body of a
    header is what remains after removing the header's name and its
    following colon, and then ignoring any leading and trailing whitespace.

Then in:

   If a header listed in the header-names argument exists, it contains
   the empty key ("").  However, if the named header is not present, it
   does not match any key, including the empty key.  So if a message
   contained the header

would be "its body contains" and "its body does not contain"

BTW I notice that in 5.1:

   The address test matches Internet addresses ...

this is the only one of the descriptions in section 5 that doesn't put
the verb in quotes in its opening sentence.  i.e. for consistency's sake
it would be

   The "address" test ..

mm

Date: Wed, 22 Mar 2006 17:06:42 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: document status: 3028bis, body, editheader
Cc: Michael Haardt <[email-masked]>
Sender: [email-masked]

I wrote:
> As it is, I'm suggesting that 0x80 0x82 is equal to precisely one 
> string, namely 0x80 0x20,

Ack! Typo. 0x80 0x82 both time, of course

Date: Wed, 22 Mar 2006 17:05:20 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: document status: 3028bis, body, editheader
Cc: Michael Haardt <[email-masked]>
Sender: [email-masked]

Could you please elaborate?

Do you mean that ascii-casemap should consider two octet strings to be 
equal if they are the same after decoding UTF-8? Should it do Unicode 
composition/decomposition?

As it is, I'm suggesting that 0x80 0x82 is equal to precisely one 
string, namely 0x80 0x20, and that independently of whether 0x80 0x82 
is meant to be a character encoded in UTF-8 or something else.

Arnt

Date: Wed, 22 Mar 2006 16:51:33 +0100
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: document status: 3028bis, body, editheader
Sender: [email-masked]

On Wed, Mar 22, 2006 at 07:13:31AM -0800, Alexey Melnikov wrote:
> I've already sent a comment to Arnt asking him to allow en;ascii-casemap 
> to work on Unicode characters. The advantage of this is that Unicode 
> characters outside of ASCII are legal and not going to cause matching 
> failure anymore.
> I though you agreed to this in one of your messages to the mailing list.
> 
> So, are there any objections to change en;ascii-casemap to work on 
> Unicode characters?

I would appreciate it, because right now the base spec does not allow
to match one arbitrary character.  To begin with, I interpreted 3028 to
talk of unicode characters, not octets, because the text was confusing
and nothing else made sense to me.  I just changed my implementation to
match octets for RFC conformance, after we discussed the topic to death.
It sounded like all other implementations already worked that way before.

Changing the comparator breaks all existing implementations.

If it was just for me, I'd say: So what? It is a change for the better,
having en;ascii-casemap working on octets stinks, using variables
"?" matches a single octet of a multibyte UTF-8 sequence (which is bad
and unexpected to most users) and progress sometimes has to break things.

But I am afraid somebody is going to say something about "compatibility"
and "violating existing standards" and stuff.  I can almost hear it.
Sieve is now widespread and since we could always invent a new comparator,
that works like "en;ascii-casemap" but on characters, perhaps you really
shouldn't listen to me. ;-)

Michael

Date: Wed, 22 Mar 2006 16:38:18 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: document status: 3028bis, body, editheader
Cc: Alexey Melnikov <[email-masked]>, Philip Guenther <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> I've already sent a comment to Arnt asking him to allow 
> en;ascii-casemap to work on Unicode characters. The advantage of this 
> is that Unicode characters outside of ASCII are legal and not going 
> to cause matching failure anymore.
> I though you agreed to this in one of your messages to the mailing list.

I felt a little bad about that and sat on it. Call it intuition. And 
indeed I changed my mind later. Now I think the most appropriate policy 
is for ascii-casemap to treat all codepoints it doesn't know as 
non-letters, ie. there's no specific tie to unicode. A UTF-8 octet 
stream encoding a proper word or pure 8-bit junk: No difference to 
ascii-casemap.

Sound good?

Arnt

Date: Wed, 22 Mar 2006 10:32:11 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked]
Subject: Re: 3028bis: post-meeting changes
Sender: [email-masked]

Philip Guenther wrote:
> These are in response to the discussions earlier today in Dallas.
> The log of the jabber room can be found at:
> 	http://www.ietf.org/meetings/ietf-logs/[email-masked]/2006-03-21.html
> 
> 
> Opinions on any of the following, whether yeah or nay, are appreciated,
> especially on the last point.
> 
> 
> 1. The first paragraph of section 4.1 ("Action fileinto") now reads:
>  ...
> 2. In the Security Considerations section, I've added:
> 
>     Use of the "redirect" command to generate notifications may
>     easily overwhelm the target address, especially if it was not
>     designed to handle large message.

These look good to me.

> 3. IANA template

I need to give this some more thought.

Date: Wed, 22 Mar 2006 07:13:31 -0800
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: [email-masked]
Subject: Re: document status: 3028bis, body, editheader
Sender: [email-masked]

Philip Guenther wrote:

>Alexey Melnikov <[email-masked]> writes:
>...
>  
>
>>I think you've missed a couple of issues I've reported:
>>1). I can't see any text about stripping leading/trailing whitespaces 
>>(text moved from the relational extension)
>>    
>>
>
>Section 5.7:
>   The "header" test evaluates to true if the value of any of the named
>   headers, ignoring leading and trailing whitespace, matches any key.
>
>(This was present in rev -04 too)
>  
>
Ah, my fault. I've only checked the diff between -03 and -04. I didn't 
realized that you've already addressed the issue.
[...]**

>>Philip Guenther wrote:    
>>
>...
>  
>
>>>I've made one tweak for the next rev to the wording in section 2.7.1
>>>regarding ':match' and the definition of 'character'; I had overlooked
>>>an off-list comment at the turn of the year.  The paragraph now
>>>reads:
>>>  The ":matches" match type specifies a wildcard match using the
>>>  characters "*" and "?"; the entire value must be matched.  "*"
>>>  matches zero or more characters in the value and "?" matches a single
>>>  character in the value, where the comparator that is used (see 2.7.3)
>>>  defines what a character is.  For example, the comparators "i;octet"
>>>  and "en;ascii-casemap" define a character to be a single octet so "?"
>>>      
>>>
>>I don't think en;ascii-casemap is working on octets. So either the 
>>comparators draft need to be changed, or this sentence need to be changed.
>>    
>>
>Sure it is.  Section 9.2.1 of draft-newman-i18n-comparator-08 seems to
>concur.
>  
>
In another section it says that no comparator but i;octet should operate 
on octets.

I've already sent a comment to Arnt asking him to allow en;ascii-casemap 
to work on Unicode characters. The advantage of this is that Unicode 
characters outside of ASCII are legal and not going to cause matching 
failure anymore.
I though you agreed to this in one of your messages to the mailing list.

So, are there any objections to change en;ascii-casemap to work on 
Unicode characters?

From: Philip Guenther <[email-masked]>
To: [email-masked]
Subject: 3028bis: post-meeting changes
Date: Tue, 21 Mar 2006 19:09:46 -0800
Sender: [email-masked]

These are in response to the discussions earlier today in Dallas.
The log of the jabber room can be found at:
	http://www.ietf.org/meetings/ietf-logs/[email-masked]/2006-03-21.html

Opinions on any of the following, whether yeah or nay, are appreciated,
especially on the last point.

1. The first paragraph of section 4.1 ("Action fileinto") now reads:

   The "fileinto" action delivers the message into the specified folder.
   Implementations SHOULD support fileinto, but in some environments
   this may be impossible.  Implementations MAY place restrictions on
   folder names; use of an invalid folder name MAY be treated as an
   error or result in delivery to an implementation-defined folder.  If
   the implementation uses a different encoding scheme than UTF-8 for
   folder names, it SHOULD reencode the folder name from UTF-8 to its
   encoding scheme.  For example, the Internet Message Access Protocol
   [IMAP] uses modified UTF-7, such that a folder argument of "odds &
   ends" would appear in IMAP as "odds &- ends".

(Hmm, need to tweak the line wrap...)

2. In the Security Considerations section, I've added:

    Use of the "redirect" command to generate notifications may
    easily overwhelm the target address, especially if it was not
    designed to handle large message.

3. IANA template

I think we should simply drop the "Capability name" and "Capability
arguments" fields, leaving:

   Capability keyword:
   Standards Track/IESG-approved experimental RFC number:
   Person and email address to contact for further information:

As I see it, there are two major concerns for the registry:
 1) capabilities should be unique, so that require "foo" has the
    same meaning everywhere it works
 2) given a standardized capability, you need to be able to find
    the current RFC describing it

Concerns about different capabilities enabling the same action or
test are better addressed, IMHO, by reexamining the naming and
review policy for the registry.

For example, perhaps we should
1) adjust the vendor namespace rules to instead be FCFS registration
   of trees ("vnd.acme.*"),
2) break out a namespace for draft extensions (ala Alexey's
   "X-DRAFT-[IW]#-name" proposal for IMAP extension drafts), and
3) switch the rest of the namespace from FCFS to Specification
   required or IETF Consensus (c.f. RFC 2434)

I included (2) because we've had problems with extensions that saw
significant change after a long period of statis (e.g., 'notify'
and 'imapflags'), but perhaps the above is an overreaction.

Thoughts?

Philip Guenther

To: Alexey Melnikov <[email-masked]>
From: Philip Guenther <[email-masked]>
Cc: [email-masked]
Subject: Re: document status: 3028bis, body, editheader 
Date: Tue, 21 Mar 2006 13:37:28 -0800
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:
...
>I think you've missed a couple of issues I've reported:
>1). I can't see any text about stripping leading/trailing whitespaces 
>(text moved from the relational extension)

Section 5.7:
   The "header" test evaluates to true if the value of any of the named
   headers, ignoring leading and trailing whitespace, matches any key.

(This was present in rev -04 too)

>2). I think IANA template is not precisely defined, I am not clear on 
>what is the difference between "capability name" and "capability 
>keyword"? Is the former supposed to be a human readable phrase? Also, 
>what should be put into "Capability arguments" if an extension supports 
>multiple actions/tests.

Hmm, the template is really aimed towards new tests and actions, while
just about every part of the sieve grammar has been extended in some
way.  Checking the previously published RFCs, we've tended to just
register the name and ignore the "Capability arguments" part.  For
example, the spamtest and virustest registrations in RFC 3685 don't give
the arguments.

My inclination would be to drop the "name" and "arguments" fields.
Opinions?

>Philip Guenther wrote:
...
>>I've made one tweak for the next rev to the wording in section 2.7.1
>>regarding ':match' and the definition of 'character'; I had overlooked
>>an off-list comment at the turn of the year.  The paragraph now
>>reads:
>>   The ":matches" match type specifies a wildcard match using the
>>   characters "*" and "?"; the entire value must be matched.  "*"
>>   matches zero or more characters in the value and "?" matches a single
>>   character in the value, where the comparator that is used (see 2.7.3)
>>   defines what a character is.  For example, the comparators "i;octet"
>>   and "en;ascii-casemap" define a character to be a single octet so "?"
>
>I don't think en;ascii-casemap is working on octets. So either the 
>comparators draft need to be changed, or this sentence need to be changed.

Sure it is.  Section 9.2.1 of draft-newman-i18n-comparator-08 seems to
concur.

...
>>draft-ietf-sieve-editheader-04.txt
>>----------------------------------
>>
>>This has been reading for submission for a while; I think the
>>write-up is even done.  This last rev was basically editorial.
>>  
>>
>(Chair hat on): The draft needs to address the issue with 
>leading/trailing spaces.

You just mean in deleteheader's matching?  Or are there other places I
don't see?

I'll change the text in deleteheader to refer to the base-spec's
'header' test for details of matching values against patterns.

Philip Guenther

Date: Tue, 21 Mar 2006 11:54:48 -0800
From: Alexey Melnikov <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
CC: [email-masked]
Subject: Re: Dallas meeting slides
Sender: [email-masked]

Mark E. Mallett wrote:

>On Tue, Mar 21, 2006 at 08:59:29AM -0800, Alexey Melnikov wrote:
>  
>
>><https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65>
>>Look for the Sieve section.
>>
>>Note that slides contain a couple of errors (e.g. year in the new 
>>milestones (the right column) should be 2006), but the chairs hope to 
>>upload the updated slides before the meeting.
>>    
>>
>
>Re the page on the notify draft, currently page 11:
>
>   To do:
>       Need to bring back and update old examples using
>       denotify
>
>Does this mean that somebody wants "denotify" back?  Or am I
>misinterpreting the bullet item?
>  
>
No. This means rewriting old example with denotify to use notify + 
variables.

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 21 Mar 2006 13:33:11 -0500
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: Dallas meeting slides
Sender: [email-masked]

On Tue, Mar 21, 2006 at 08:59:29AM -0800, Alexey Melnikov wrote:
> <https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65>
> Look for the Sieve section.
> 
> Note that slides contain a couple of errors (e.g. year in the new 
> milestones (the right column) should be 2006), but the chairs hope to 
> upload the updated slides before the meeting.

Re the page on the notify draft, currently page 11:

   To do:
       Need to bring back and update old examples using
       denotify

Does this mean that somebody wants "denotify" back?  Or am I
misinterpreting the bullet item?

mm

Date: Tue, 21 Mar 2006 08:59:29 -0800
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Dallas meeting slides
Sender: [email-masked]

<https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65>
Look for the Sieve section.

Note that slides contain a couple of errors (e.g. year in the new 
milestones (the right column) should be 2006), but the chairs hope to 
upload the updated slides before the meeting.

Date: Tue, 21 Mar 2006 10:32:27 -0600
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Slides for the meeting today
Sender: [email-masked]

--==========AEEB27AEED0558C25DA0==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi folks,
Attaches is a PDF of the slides we will be using in today's meeting.

As a reminder the jabber chat room is [email-masked]' and the 
audio stream is: <http://videolab.uoregon.edu/events/ietf/ietf657.m3u>.

-- 
Cyrus Daboo

--==========AEEB27AEED0558C25DA0==========
Content-Type: application/pdf; name="Dallas.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Dallas.pdf"; size=44026

--==========AEEB27AEED0558C25DA0==========--

Date: Tue, 21 Mar 2006 07:52:45 -0800
From: Alexey Melnikov <[email-masked]>
To: Michael Haardt <[email-masked]>
CC: [email-masked]
Subject: Re: document status: 3028bis, body, editheader
Sender: [email-masked]

Michael Haardt wrote:

>> 2) should 3028bis recommend/require that fileinto map UTF-8 to mUTF-7
>>    when working with an IMAP store?
>>    
>>
>Somehow the question does not sound right to me, see below.
>  
>
>>   Implementations MAY place restrictions on
>>   folder names; use of an invalid folder name MAY be treated as an
>>   error or result in delivery to an implementation-defined folder.
>>    
>>
>That is a very good path between all alternatives and I like it as it
>is.
>  
>
>>Should it say more than this in either direction?  I pondered adding
>>text about mapping UTF-8 to mUTF-7 and a supporting example (the
>>the open issues entry), but it couldn't find a wording that didn't
>>feel like one step too far beyond the scope of sieve.
>>    
>>
>
>I would appreciate a requirement that says: If the implementation uses
>a different unicode encoding scheme than UTF-8 for folder names, it MUST
>translate the folder name from UTF-8 to its encoding scheme.
>  
>
I like that.
UTF-8 to mUTF7 can be given as an informative example.

>It would fit into the general picture of Sieve that uses UTF-8 everywhere
>and relies on the implementation to convert.
>  
>

Date: Tue, 21 Mar 2006 07:48:48 -0800
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: [email-masked]
Subject: Re: document status: 3028bis, body, editheader
Sender: [email-masked]

Philip Guenther wrote:

>To either head-off or prime the conversation for tomorrow...
>
>draft-ietf-sieve-3028bis-06.txt
>-------------------------------
>
>The primary issue for the base-spec has been whether it's description
>of matching is inline with that description in the collation doc,
>draft-newman-i18n-comparator.  I _believe_ the current drafts are
>in agreement on the details.  Either confirmation or corrections
>from others are needed.
>  
>
I think you've missed a couple of issues I've reported:
1). I can't see any text about stripping leading/trailing whitespaces 
(text moved from the relational extension)
2). I think IANA template is not precisely defined, I am not clear on 
what is the difference between "capability name" and "capability 
keyword"? Is the former supposed to be a human readable phrase? Also, 
what should be put into "Capability arguments" if an extension supports 
multiple actions/tests.

>I've made one tweak for the next rev to the wording in section 2.7.1
>regarding ':match' and the definition of 'character'; I had overlooked
>an off-list comment at the turn of the year.  The paragraph now
>reads:
>   The ":matches" match type specifies a wildcard match using the
>   characters "*" and "?"; the entire value must be matched.  "*"
>   matches zero or more characters in the value and "?" matches a single
>   character in the value, where the comparator that is used (see 2.7.3)
>   defines what a character is.  For example, the comparators "i;octet"
>   and "en;ascii-casemap" define a character to be a single octet so "?"
>  
>
I don't think en;ascii-casemap is working on octets. So either the 
comparators draft need to be changed, or this sentence need to be changed.

>   will always match exactly one octet when one of those comparators is
>   in use.  In contrast, the comparator "i;basic;uca=3.1.1;uv=3.2"
>   defines a character to be any UTF-8 octet sequence encoding one
>   Unicode character and thus "?" may match more than one octet.  "?"
>   and "*" may be escaped as "\\?" and "\\*" in strings to match against
>   themselves.  The first backslash escapes the second backslash;
>   together, they escape the "*".  This is awkward, but it is
>   commonplace in several programming languages that use globs and
>   regular expressions.
>
>
>As listed in the doc, the open issues are:
>  
>
My personal answers (chair hat off) to these questions:

> 1) is 'reject' going back in here as a "do the the best you can" action?
>  
>
I would rather keep it separate, as reject is still going through 
massive changes.

> 2) should 3028bis recommend/require that fileinto map UTF-8 to mUTF-7
>    when working with an IMAP store?
>  
>
Yes please.

>The latter thought actually came about from pondering the description
>of fileinto after a suggestion that all the fileinto examples in
>spec should use a consistent style of folder naming (e.g., always
>using a prefix of "INBOX.").  I felt it better to leave the spec
>mixed, if just to avoid the implication that a particular style was
>meant to be mandated.
>
I agree.

>Indeed, I went ahead and inserted the text
>in section 4.1:
>   Implementations MAY place restrictions on
>   folder names; use of an invalid folder name MAY be treated as an
>   error or result in delivery to an implementation-defined folder.
>  
>
Yes, the text should be carefully worded to make it clear that this 
restriction is on mailstores supporting IMAP.

>Should it say more than this in either direction?  I pondered adding
>text about mapping UTF-8 to mUTF-7 and a supporting example (the
>the open issues entry), but it couldn't find a wording that didn't
>feel like one step too far beyond the scope of sieve.
>
>
>draft-ietf-sieve-body-03.txt
>----------------------------
>
>This had been blocked pending the settling of the comparator/charset
>wording in the base spec.  Again, I believe it to be in agreement
>but confirmation is needed.  At that point, this can be put into
>the submission queue behind the 3028bis.
>
>
>draft-ietf-sieve-editheader-04.txt
>----------------------------------
>
>This has been reading for submission for a while; I think the
>write-up is even done.  This last rev was basically editorial.
>  
>
(Chair hat on): The draft needs to address the issue with 
leading/trailing spaces.
Also there might be some interaction with reject I would like to discuss 
(I will send a separate email on this).

Date: Tue, 21 Mar 2006 15:26:52 +0100
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: document status: 3028bis, body, editheader
Sender: [email-masked]

On Mon, Mar 20, 2006 at 10:59:50PM -0800, Philip Guenther wrote:
> I've made one tweak for the next rev to the wording in section 2.7.1
> regarding ':match' and the definition of 'character'; I had overlooked
> an off-list comment at the turn of the year.  The paragraph now
> reads:

Sounds very good to me.

>  2) should 3028bis recommend/require that fileinto map UTF-8 to mUTF-7
>     when working with an IMAP store?

Somehow the question does not sound right to me, see below.

>    Implementations MAY place restrictions on
>    folder names; use of an invalid folder name MAY be treated as an
>    error or result in delivery to an implementation-defined folder.

That is a very good path between all alternatives and I like it as it
is.

> Should it say more than this in either direction?  I pondered adding
> text about mapping UTF-8 to mUTF-7 and a supporting example (the
> the open issues entry), but it couldn't find a wording that didn't
> feel like one step too far beyond the scope of sieve.

I would appreciate a requirement that says: If the implementation uses
a different unicode encoding scheme than UTF-8 for folder names, it MUST
translate the folder name from UTF-8 to its encoding scheme.

It would fit into the general picture of Sieve that uses UTF-8 everywhere
and relies on the implementation to convert.

Michael

From: Philip Guenther <[email-masked]>
To: [email-masked]
Subject: document status: 3028bis, body, editheader
Date: Mon, 20 Mar 2006 22:59:50 -0800
Sender: [email-masked]

To either head-off or prime the conversation for tomorrow...

draft-ietf-sieve-3028bis-06.txt
-------------------------------

The primary issue for the base-spec has been whether it's description
of matching is inline with that description in the collation doc,
draft-newman-i18n-comparator.  I _believe_ the current drafts are
in agreement on the details.  Either confirmation or corrections
from others are needed.

I've made one tweak for the next rev to the wording in section 2.7.1
regarding ':match' and the definition of 'character'; I had overlooked
an off-list comment at the turn of the year.  The paragraph now
reads:
   The ":matches" match type specifies a wildcard match using the
   characters "*" and "?"; the entire value must be matched.  "*"
   matches zero or more characters in the value and "?" matches a single
   character in the value, where the comparator that is used (see 2.7.3)
   defines what a character is.  For example, the comparators "i;octet"
   and "en;ascii-casemap" define a character to be a single octet so "?"
   will always match exactly one octet when one of those comparators is
   in use.  In contrast, the comparator "i;basic;uca=3.1.1;uv=3.2"
   defines a character to be any UTF-8 octet sequence encoding one
   Unicode character and thus "?" may match more than one octet.  "?"
   and "*" may be escaped as "\\?" and "\\*" in strings to match against
   themselves.  The first backslash escapes the second backslash;
   together, they escape the "*".  This is awkward, but it is
   commonplace in several programming languages that use globs and
   regular expressions.

As listed in the doc, the open issues are:
 1) is 'reject' going back in here as a "do the the best you can" action?
 2) should 3028bis recommend/require that fileinto map UTF-8 to mUTF-7
    when working with an IMAP store?

The latter thought actually came about from pondering the description
of fileinto after a suggestion that all the fileinto examples in
spec should use a consistent style of folder naming (e.g., always
using a prefix of "INBOX.").  I felt it better to leave the spec
mixed, if just to avoid the implication that a particular style was
meant to be mandated.  Indeed, I went ahead and inserted the text
in section 4.1:
   Implementations MAY place restrictions on
   folder names; use of an invalid folder name MAY be treated as an
   error or result in delivery to an implementation-defined folder.

Should it say more than this in either direction?  I pondered adding
text about mapping UTF-8 to mUTF-7 and a supporting example (the
the open issues entry), but it couldn't find a wording that didn't
feel like one step too far beyond the scope of sieve.

draft-ietf-sieve-body-03.txt
----------------------------

This had been blocked pending the settling of the comparator/charset
wording in the base spec.  Again, I believe it to be in agreement
but confirmation is needed.  At that point, this can be put into
the submission queue behind the 3028bis.

draft-ietf-sieve-editheader-04.txt
----------------------------------

This has been reading for submission for a while; I think the
write-up is even done.  This last rev was basically editorial.

Philip Guenther

Date: Mon, 20 Mar 2006 08:25:49 -0800
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Jabber server for IETF has moved
Sender: [email-masked]

For people who want to participate in the Sieve meeting remotely, please 
read:
<http://www.ietf.org/meetings/text_conf.html>

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-3028bis-06.txt 
Date: Wed, 08 Mar 2006 15:50:02 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve: An Email Filtering Language
	Author(s)	: T. Showalter, P. Guenther
	Filename	: draft-ietf-sieve-3028bis-06.txt
	Pages		: 38
	Date		: 2006-3-8
	
This document describes a language for filtering email messages at
time of final delivery.  It is designed to be implementable on either
a mail client or mail server.  It is meant to be extensible, simple,
and independent of access protocol, mail architecture, and operating
system.  It is suitable for running on a mail server where users may
not be allowed to execute arbitrary programs, such as on black box
Internet Message Access Protocol (IMAP) servers, as it has no
variables, loops, or ability to shell out to external programs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-3028bis-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-3028bis-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-3028bis-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-3028bis-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-3028bis-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-body-03.txt 
Date: Wed, 08 Mar 2006 15:50:02 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Email Filtering: Body Extension
	Author(s)	: P. Guenther, J. Degener
	Filename	: draft-ietf-sieve-body-03.txt
	Pages		: 12
	Date		: 2006-3-8
	
This document defines a new primitive for the "Sieve" email
   filtering language that tests for the occurrence of one or more
   strings in the body of an email message.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-body-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-body-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-body-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-body-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-body-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-editheader-04.txt 
Date: Wed, 08 Mar 2006 15:50:02 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Email Filtering: Editheader Extension
	Author(s)	: P. Guenther, J. Degener
	Filename	: draft-ietf-sieve-editheader-04.txt
	Pages		: 9
	Date		: 2006-3-8
	
This document defines two new actions for the "Sieve" email
   filtering language that add and delete email header fields.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-editheader-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-editheader-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-editheader-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-editheader-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-editheader-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 7 Mar 2006 16:36:58 -0500
To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-rfc3598bis-02.txt
Sender: [email-masked]

On Mon, Mar 06, 2006 at 12:06:31AM +0100, Michael Haardt wrote:
> 
> As it is, all kinds of subadressing are in use, and given the broad range
> of possibilities, this extension almost certainly can not be used for all
> of them.  To begin with, it would only allow a single separator character
> and suffix details.  I showed some people use character sequences as
> separator and some use the detail as prefix.  Now the extension covers
> those cases, but that does not mean it covers everything.  That's why
> I vote for a system-defined method of determining user and detail part.

Me too.. I think the functionality of this extension is diminished by
specifying particular syntaxes of user and detail.  After all, it seems
to me that one thing this extension is trying to do is remove knowledge
of those syntax details from the script writer; this becomes more useful
with less simplistic localpart formations.

I think it's fine if the spec focuses on a couple of different styles of
subaddressing for the purposes of explanation and exposition.  But I
don't really know why you'd want to mandate whatever we can think up at
the moment as being the only ways addresses can be extended.  The
interpretation of the localpart is best left up to any implementation,
and not just in the ways that we know of now.

I could imagine having hashed addresses:  let's say
"b0359d533e48623bae1d2dad9f2aedc4" corresponds to mem-foo .  Or perhaps
"nfmoioesoee" would be mem-foo with some noise thrown in.  Seems to me
that a subaddress extension would be much more useful to these cases
than for the simple substring/separator cases being discussed (since
difficult uses better illustrate how the extension removes the burden of
decoding them from the user, and leaves it to the implementation).

While I'm here, re this comment upthread:

On Fri, Mar 03, 2006 at 12:24:14PM -0800, Philip Guenther wrote:
> My interpretation is that for that example address, the sieved handling
> mail for silverton.berkeley.edu would follow the qmail practice and
> split the localpart on the first '-', such that :user would specify
> 'djb' and :detail would specify 'sos-owner-God=heaven.af.mil'.  If you
> disagree or desire otherwise, please describe the additional (or
> alternative) processing you're looking for.

This brings up the fact that there are already user/detail formations
out there that are not as simplistic as they might appear.  qmail
actually doesn't split on the first '-' or whatever character is in use.
It splits according to one of its control files that allows the base
"user" and detail parts to be determined.  In a default installation the
hyphen separates the two, but you can't just look for the first one.  A
base user part can be "mem-of-nh" and it's completely legitimate to have
a detail of "for-my-house" with "mem-of-nh-for-my-house" being the
complete localpart.

One might think that you could look for the final recipient address in
that string, but not with any great reliability- the base user part in
the string does not have to be the same as the one that is delivered to.

Also, the user control file can (in effect) specify different
user/detail separator strings per user or even per detail per user.
It's not common for different separators for different users in a qmail
environment, but it's possible and it's done now and then.

Having done the basic split, qmail will look for subdetail splits in the
suffix, using a hardwired separator character, usually hyphen.  (I think
I have mentioned in the past that having only one detail level doesn't
completely satisfy there as it's common to use subdetail delegation.)  A
user part of "mem" could have different separator and detail formats
including "mem-first" and "mem..second" and "mem+third" .  (Or, indeed,
"mem-sieve" and "mem..sieve" and "mem+sieve" all of which are
different.)  Just to be clear, I'm not talking about aliases: I'm
talking about a particular user being able to use any detail string
using those formats.)

mm

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-refuse-reject-01.txt 
Date: Mon, 06 Mar 2006 02:50:01 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: The SIEVE mail filtering language - reject and refuse extensions
	Author(s)	: M. Elvey, A. Melnikov
	Filename	: draft-ietf-sieve-refuse-reject-01.txt
	Pages		: 0
	Date		: 2006-3-5
	
This memo defines the SIEVE mail filtering language (RFC
   <<3028bis>>) "reject" extension.
   
   A Joe-job is a spam run forged to appear as though it came from an
   innocent party, who is then generally flooded by the bounces,
   Message Disposition Notifications (MDNs) and messages with
   complaints.  The original Sieve "reject" action defined in RFC 3028
   required use of MDNs for rejecting messages, thus contributing to
   the flood of Joe-job spam to victims of Joe-jobs.  This document
   updates definition of "reject" to allow for rejecting messages
   during the SMTP transaction.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-refuse-reject-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-refuse-reject-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-refuse-reject-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-refuse-reject-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-refuse-reject-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 6 Mar 2006 00:06:31 +0100
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-rfc3598bis-02.txt
Sender: [email-masked]

On Sat, Mar 04, 2006 at 10:50:44PM -0800, Philip Guenther wrote:
> I guess my concern is that generalizing the wording will make it less
> precise and more difficult to understand.  Currently there are some
> fairly precise statements setting when :detail is or contains the empty
> key; if this all becomes just a system-defined abstract query, how can
> those requirements still be stated?

They can't, and I don't see why they should.  If subaddressing would be
specified by any standard, things would be different, but it is not.

Trying to standardize subadressing by creating a sieve extension that
is able to process a (large, but still a) subset of what is possible
does not look right to me.  If you want to define how subadressing
should work, for cleaning up the world-wide mess, then it should be
done outside the context of Sieve (perhaps as common best practice),
not by trying to set facts.

As it is, all kinds of subadressing are in use, and given the broad range
of possibilities, this extension almost certainly can not be used for all
of them.  To begin with, it would only allow a single separator character
and suffix details.  I showed some people use character sequences as
separator and some use the detail as prefix.  Now the extension covers
those cases, but that does not mean it covers everything.  That's why
I vote for a system-defined method of determining user and detail part.

To satisfy all needs, Exim sets the user and the detail part by generic
string expressions.  I will not cripple that to specify a separator
and a matching direction, but using that flexibility to express more
is obviously a violation of the extension that requires user and detail
part to be substrings - not something I am glad about.

Please don't focus on VERP.  I just quoted it because it was the first
application of subadressing not using substrings that came to my mind.
I am sure there is more, but I do not have a reference for crypted detail
parts or something like that.

Michael

Cc: Michael Haardt <[email-masked]>, [email-masked]
To: Philip Guenther <[email-masked]>
Date: Sun, 05 Mar 2006 08:25:40 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sieve-rfc3598bis-02.txt
Sender: [email-masked]

> Michael Haardt <[email-masked]> writes:
> >On Fri, Mar 03, 2006 at 12:24:14PM -0800, Philip Guenther wrote:
> ...
> >> I didn't think VERPs were an all-or-nothing choice.  A user may send
> >> some messages with VERP-style address and others with random tags in the
> >> subaddress portion.  Please explain how a system that 'decoded' VERPs
> >> would support that.
> >
> >Users usually do not send VERPs, but MLMs do.  The system that runs
> >the MLM would be configured to know which bounces belong to the MLM,
> >and set up subaddressing to decode VERP.  Mail that belongs to users
> >would be delivered with subaddressing set up as the local convention
> >for users is, i.e. <user+detail@domain>.

> So, the use-case you have in mind for the requested flexibility would be
> for sieve scripts running 'in front of' MLMs only?  That's a pretty
> specialized application.

I agree. I will also point out, again, that the VERP concept is distinct from
the specific encoding that's described, and may be MLM or even list specific.
It may make sense, for example, to incorporate some sort of keying mechanism to
prevent forged unsubscribes.

> >> VERPs are a optional encoding inside the subaddress encoding, ergo
> >> decoding of them should be separately performed or requested so that
> >> access to both levels can be provided.
> >
> >If you want ultimate configurability, indeed variables and string
> >expressions are needed.  But all I ask for is making the subaddress
> >specification less restrictive on issues outsides its scope and change
> >it into an abstraction that simply queries an abstract user and detail
> >part, not caring about how they are formed.

> I guess my concern is that generalizing the wording will make it less
> precise and more difficult to understand.  Currently there are some
> fairly precise statements setting when :detail is or contains the empty
> key; if this all becomes just a system-defined abstract query, how can
> those requirements still be stated?

I'm afraid I have to agree. Breaking the local-part apart into pieces
is one thing, decoding any encoding in there is quite another.

If you want a different example, consider how you'd embed a non-ASCII folder
name in a subaddress. The situation surrounding IMAP's use of modified UTF-7 is
already enough of a mess without allowing for decoding to occur as
part of sieve subaddress handling.

				Ned

To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-rfc3598bis-02.txt 
Date: Sat, 04 Mar 2006 22:50:44 -0800
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

Michael Haardt <[email-masked]> writes:
>On Fri, Mar 03, 2006 at 12:24:14PM -0800, Philip Guenther wrote:
...
>> I didn't think VERPs were an all-or-nothing choice.  A user may send
>> some messages with VERP-style address and others with random tags in the
>> subaddress portion.  Please explain how a system that 'decoded' VERPs
>> would support that.
>
>Users usually do not send VERPs, but MLMs do.  The system that runs
>the MLM would be configured to know which bounces belong to the MLM,
>and set up subaddressing to decode VERP.  Mail that belongs to users
>would be delivered with subaddressing set up as the local convention
>for users is, i.e. <user+detail@domain>.

So, the use-case you have in mind for the requested flexibility would be
for sieve scripts running 'in front of' MLMs only?  That's a pretty
specialized application.

>> VERPs are a optional encoding inside the subaddress encoding, ergo
>> decoding of them should be separately performed or requested so that
>> access to both levels can be provided.
>
>If you want ultimate configurability, indeed variables and string
>expressions are needed.  But all I ask for is making the subaddress
>specification less restrictive on issues outsides its scope and change
>it into an abstraction that simply queries an abstract user and detail
>part, not caring about how they are formed.

I guess my concern is that generalizing the wording will make it less
precise and more difficult to understand.  Currently there are some
fairly precise statements setting when :detail is or contains the empty
key; if this all becomes just a system-defined abstract query, how can
those requirements still be stated?

Philip Guenther

** As a footnote, VERP is _not_ an encoding but just the abstract idea
of using, well, Variable Envelope Return Paths.  The page that was
cited:
	http://cr.yp.to/proto/verp.txt
contains an example of a return-path that encodes an address, but it
does not actually provide anything like specification of an encoding.

Date: Sat, 04 Mar 2006 19:30:28 +0000
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Tentative agenda for the Sieve WG meeting in Dallas
Sender: [email-masked]

Ok folks,
Here is a draft agenda for the Dallas IETF meeting:

Agenda

- Introduction (blue sheets, scribe etc) (1 min)
- Agenda Bashing (2 mins)
- Report on completed work (2 mins)
- Spamtest draft status (10 mins)
- Date draft status (5 mins)
- Subaddress draft status (5 mins)
- Regex draft status (5 mins)
- Reject/refuse draft (10 mins)
- MIME loops draft (20 mins)
- Notification draft (20 mins)
- Base spec status, in particular review of
  comparators (draft-newman-i18n-comparator-07.txt) and Sieve (10 mins)
- Other topics:
  Manage Sieve protocol (5 mins)
  Include draft (15 mins)
  Proposals for adding exception handling/optional require to Sieve (10 
mins)

Total: 120 minutes.
===============
The suggested order might look backward, but I would like to discuss 
easy documents first.

The items in the list I am not sure about: Regex (there is a new draft, 
but there was no progress done on I18N and I don't know if Ned is 
attending), MIME loops (how much time do we need for this one?), date 
(are there any open issues?).
Also, 10 minutes for discussing comparators is not enough, but as the 
comparator draft also affects IMAPEXT WG, there would be a longer 
discussion happening there.

Any comments?

Alexey

Date: Sat, 04 Mar 2006 00:00:19 +0000
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Agenda for Sieve WG meeting in Dallas
Sender: [email-masked]

Hi everyone,
Dallas meeting is approaching, so it is time to talk about agenda for 
Sieve WG meeting.
Can I please see a show of hands (off-list please) about who from 
editors is planning to attend and if a person is not attending, whom he 
wants to nominate as a presenter.
I would also appreciate a short message from each editor about status or 
their documents (recent changes, todo list, open issues).

Alexey

P.S. Both Cyrus and I are planning to attend the meeting.

Date: Fri, 03 Mar 2006 23:46:03 +0000
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Survey of spamtest implementations
Sender: [email-masked]

Hi folks,
I would like how many server or client implementations support spamtest 
extension as defined in RFC 3685. Please send replies directly to me.

Thanks,
Alexey

Date: Sat, 4 Mar 2006 11:56:36 +0100
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-rfc3598bis-02.txt
Sender: [email-masked]

On Fri, Mar 03, 2006 at 12:24:14PM -0800, Philip Guenther wrote:
> My interpretation is that for that example address, the sieved handling
> mail for silverton.berkeley.edu would follow the qmail practice and
> split the localpart on the first '-', such that :user would specify
> 'djb' and :detail would specify 'sos-owner-God=heaven.af.mil'.  If you
> disagree or desire otherwise, please describe the additional (or
> alternative) processing you're looking for.

You misunderstand me.  The subaddress extension does not split addresses
on its own, but asks the underlying system to perform that operation,
and simply uses the results.  It does not specify if prefix or suffix
strings are to be used, but relies on the underlying system to know
the local convention:

   Note that
   the mechanisms used to define and/or query the separator character
   sequence and sub-part ordering used by the mail system are outside
   the scope of this document.

And things are good that way.

Unfortunately, it says: The only algorithm the underlying system may
perform is to use a separator for splitting the address in parts.

I ask to be less restrictive and allow the underlying system to split
the addresses in whatever way someone may want to configure it.

> > Why? VERP (http://cr.yp.to/proto/verp.txt) is a popular encoding
> > and if you relaxed the encoding specification, Sieve could be
> > used to decode it.  A filter in front of a MLM may be very useful.
> 
> You're looking for a means in sieved to extract the address
> <[email-masked]> from that address?  If so, what combination of
> keyword arguments would do that?  (What if _that_ address was a VERP?)

Yes.  Using :detail should be allowed to do that.  Let's not discuss
VERP, because as I said, it is a primitive encoding, but a great real
world example that shows substrings do not suffice.

> I didn't think VERPs were an all-or-nothing choice.  A user may send
> some messages with VERP-style address and others with random tags in the
> subaddress portion.  Please explain how a system that 'decoded' VERPs
> would support that.

Users usually do not send VERPs, but MLMs do.  The system that runs
the MLM would be configured to know which bounces belong to the MLM,
and set up subaddressing to decode VERP.  Mail that belongs to users
would be delivered with subaddressing set up as the local convention
for users is, i.e. <user+detail@domain>.

> VERPs are a optional encoding inside the subaddress encoding, ergo
> decoding of them should be separately performed or requested so that
> access to both levels can be provided.

If you want ultimate configurability, indeed variables and string
expressions are needed.  But all I ask for is making the subaddress
specification less restrictive on issues outsides its scope and change
it into an abstraction that simply queries an abstract user and detail
part, not caring about how they are formed.

Michael

To: Michael Haardt <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sieve-rfc3598bis-02.txt 
Date: Fri, 03 Mar 2006 12:24:14 -0800
Sender: [email-masked]

Michael Haardt <[email-masked]> writes:
...
>Quoting DJB:
>
>   Here is how VERPs work: each recipient of the message sees a
>   different envelope sender address. When a message to the
>   [email-masked] mailing list is sent to
>   [email-masked], for example, it has the following envelope sender:
>
>      djb-sos-owner-God=[email-masked]
>
>The "@" in the list member is replaced by "=".  A very primitive encoding,
>but an encoding, whereas the subaddress draft requires substrings.

My interpretation is that for that example address, the sieved handling
mail for silverton.berkeley.edu would follow the qmail practice and
split the localpart on the first '-', such that :user would specify
'djb' and :detail would specify 'sos-owner-God=heaven.af.mil'.  If you
disagree or desire otherwise, please describe the additional (or
alternative) processing you're looking for.

<from a previous message>
> Why? VERP (http://cr.yp.to/proto/verp.txt) is a popular encoding
> and if you relaxed the encoding specification, Sieve could be
> used to decode it.  A filter in front of a MLM may be very useful.

You're looking for a means in sieved to extract the address
<[email-masked]> from that address?  If so, what combination of
keyword arguments would do that?  (What if _that_ address was a VERP?)

Note that you can already extract that address using variables.  Doing
so requires knowledge of what prefixes should be stripped ala
"sos-owner-" in this case.  And no, you can't strip on the last '-'
before the '=' as the wrapped address may have a '-' in its localpart.

>To me, a subaddress is additional information encoded in the address.
>We already recognized that in general, subaddress decoding can only
>be done by receiving system for its own addresses.  If that involves
>splitting strings, translating characters or performing cryptographic
>operations, should not be of any concern to the extension that allows
>access to the decoded user and detail part.

I didn't think VERPs were an all-or-nothing choice.  A user may send
some messages with VERP-style address and others with random tags in the
subaddress portion.  Please explain how a system that 'decoded' VERPs
would support that.

VERPs are a optional encoding inside the subaddress encoding, ergo
decoding of them should be separately performed or requested so that
access to both levels can be provided.

Philip Guenther

Date: Fri, 3 Mar 2006 20:17:18 +0100
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-rfc3598bis-02.txt
Sender: [email-masked]

On Fri, Mar 03, 2006 at 09:03:05AM -0800, Ned Freed wrote:
> > This draft allows both prefix and suffix encoding, but still requires
> > both user and detail part to be substrings of the local part.
> 
> > Why? VERP (http://cr.yp.to/proto/verp.txt) is a popular encoding
> > and if you relaxed the encoding specification, Sieve could be
> > used to decode it.  A filter in front of a MLM may be very useful.
> 
> I fail to see the mismatch. In a VERP scheme the user part tells you the name
> of the list whie the detail part tells you the address that failed.

Quoting DJB:

   Here is how VERPs work: each recipient of the message sees a
   different envelope sender address. When a message to the
   [email-masked] mailing list is sent to
   [email-masked], for example, it has the following envelope sender:

      djb-sos-owner-God=[email-masked]

The "@" in the list member is replaced by "=".  A very primitive encoding,
but an encoding, whereas the subaddress draft requires substrings.

To me, a subaddress is additional information encoded in the address.
We already recognized that in general, subaddress decoding can only
be done by receiving system for its own addresses.  If that involves
splitting strings, translating characters or performing cryptographic
operations, should not be of any concern to the extension that allows
access to the decoded user and detail part.

Michael

Cc: [email-masked]
To: Michael Haardt <[email-masked]>
Date: Fri, 03 Mar 2006 09:03:05 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sieve-rfc3598bis-02.txt
Sender: [email-masked]

> On Fri, Feb 17, 2006 at 03:50:01PM -0500, [email-masked] wrote:
> > 	Title		: Sieve Email Filtering -- Subaddress Extension
> > 	Author(s)	: K. Murchison
> > 	Filename	: draft-ietf-sieve-rfc3598bis-02.txt
> > 	Pages		: 14
> > 	Date		: 2006-2-17

> This draft allows both prefix and suffix encoding, but still requires
> both user and detail part to be substrings of the local part.

> Why? VERP (http://cr.yp.to/proto/verp.txt) is a popular encoding
> and if you relaxed the encoding specification, Sieve could be
> used to decode it.  A filter in front of a MLM may be very useful.

I fail to see the mismatch. In a VERP scheme the user part tells you the name
of the list whie the detail part tells you the address that failed.

I suppose you could also use subdomains to encode some of this information
(VERP is an approach, not a particular encoding), but that's not how it is
normally done.

				Ned

Date: Fri, 3 Mar 2006 15:14:39 +0100
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-rfc3598bis-02.txt
Sender: [email-masked]

On Fri, Feb 17, 2006 at 03:50:01PM -0500, [email-masked] wrote:
> 	Title		: Sieve Email Filtering -- Subaddress Extension
> 	Author(s)	: K. Murchison
> 	Filename	: draft-ietf-sieve-rfc3598bis-02.txt
> 	Pages		: 14
> 	Date		: 2006-2-17

This draft allows both prefix and suffix encoding, but still requires
both user and detail part to be substrings of the local part.

Why? VERP (http://cr.yp.to/proto/verp.txt) is a popular encoding
and if you relaxed the encoding specification, Sieve could be
used to decode it.  A filter in front of a MLM may be very useful.

Michael

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-mime-loop-00.txt 
Date: Thu, 02 Mar 2006 15:50:01 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Extensions:  MIME Tests, MIME Bodypart Iteration, Replacement and Enclosure
	Author(s)	: T. Hansen, C. Daboo
	Filename	: draft-ietf-sieve-mime-loop-00.txt
	Pages		: 9
	Date		: 2006-3-2
	
   The current Sieve language has no way to look at individual MIME
   parts, looping mechanism, or any way to manipulate those individual
   parts.  This document defines extensions for each of these needs.

   This document is being discussed in the MTA-FILTERS mailing lists,
   [email-masked].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-mime-loop-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-mime-loop-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-mime-loop-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-mime-loop-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-mime-loop-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--