Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt

From: Michael Haardt <[email-masked]>
Date: Thu, 07 Apr 2005 19:14:45 +0200

> Does the unexpanded subject strip Re:, or will I get another vacation 
> message if I reply to the first vacation message?

Are you talking about this?

vacation :subject "Re: Re: your mail" "Not here";

Currently, the subject will be "Re: Re: your mail".  Vacation only strips
off the "Re: ", if the subject was not specified.  For that reason,
there would have to be a variable with the stripped subject right now,
if you wanted that behaviour when using vacation with variables.

I don't see anything in RFC 3834 that talks about stripping "Re: ",
plus it suggests to use "Auto: ", but does not talk about stripping
that from the original subject, either.  How about that?

Did I say that I had only one open issue recently? Here are my remaining
notes from the Exim documentation:

----------
Semantics Of ":mime"

The draft does not specify how strings using MIME entities are used
to compose messages.  As a result, different implementations generate
different mails.  The Exim Sieve implementation splits the reason into
header and body.  It adds the header to the mail header and uses the body
as mail body.  Be aware, that other imlementations compose a multipart
structure with the reason as only part.  Both conform to the specification
(or lack thereof).
----------

If everybody likes things that way, how about stating in the draft, that
it is up to the implementation how to compose the message?

----------
Interaction With Other Sieve Elements

The draft describes the interaction with vacation, discard, keep,
fileinto and redirect.  It MUST describe compatibility with other
actions, but doesn't.  In this implementation, vacation is compatible
with any other action.
----------

I suggest to add: Vacation should be compatible with any other action.
(not SHOULD).  That tells the direction for authors of new extensions.

Michael

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 07 Apr 2005 21:06:19 +0200

> notes from the Exim documentation:

I don't see why, really.  it's implicit that an implementation is free
to choose how to implement it, as long as the result is functionally
identical.

(your method seems easiest and more natural.  with the alternative you
need to choose a boundary string for the multipart, and therefore you
must scan the reason string to avoid the potential collision.)

that's true for every extension, no one will break compatibility
needlessly.  I don't think adding such text is necessary.
-- 
Kjetil T.