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

From: Michael Haardt <[email-masked]>
Date: Fri, 08 Apr 2005 00:37:58 +0200

> > If everybody likes things that way, how about stating in the draft, that
> > it is up to the implementation how to compose the message?
>
> 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.

Because it is not clear at all that this freedom of implementation is
intentional.  RFC 3028 is very explicit about freedom of implementation
and that is a good thing.

> > I suggest to add: Vacation should be compatible with any other action.
> > (not SHOULD).  That tells the direction for authors of new extensions.
>
> that's true for every extension, no one will break compatibility
> needlessly.  I don't think adding such text is necessary.

RFC 3028, section 6:

   Extensions MUST state how they interact with constraints defined in
   section 2.10, e.g., whether they cancel the implicit keep, and which
   actions they are compatible and incompatible with.

RFC 3028, section 2.10.1:

   Extension actions MUST state how they interact with actions defined
   in this specification.

Vacation draft, section 3.7:

   Vacation does not affect Sieve's implicit keep action.

   Vacation can only be executed once per script.  A script will fail if
   two vacation actions are used.

   Implementations MUST NOT consider vacation used with discard, keep,
   fileinto, or redirect an error.

And what about reject? Not specified, in direct violation to RFC 3028, but
it is real easy to miss an action.  Is vacation compatible with notify or
the copy extension? There is no reason why not, but as a matter of fact,
it is up to the implementation and probably not intentionally so.

Until RFC 3028 defines the general policy that extensions are compatible
with each other unless specified otherwise, extensions are forced to do
that on their own.  IMHO formal definitions leave no room for assumptions,
but assumptions leave room for incompatibility.

Sorry for being so pedantic, but the specification is simply not complete
and I know from personal experience that it causes lots of unnecessary
and annoying work for someone writing a new implementation.

Michael

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Fri, 08 Apr 2005 01:38:46 +0200

> and that is a good thing.

there are a lot of things regarding the composing of the message which
is left to the implementation's discretion.  should the Subject use
quoted-printable or base64?  should the From header include the full
name of the vacationist or just the e-mail address?  and so on.  it's
impossible to make an exhaustive list of all these small decisions, and
it would be a distraction.

> it is real easy to miss an action.

clearly the draft should be fixed.

> Is vacation compatible with notify or

"notify" is not an RFC so it's not appropriate to reference it.  "copy"
has no actions.

> that on their own.

"forced"?  not really.  they are only forced to state compatibility with
the actions defined in the base spec.

the base spec can't define a general policy of "compatible" for all
extensions since it is truly "undefined" unless stated explicitly.  not
all extensions need be standards track, and we might see "informational"
extensions.  I don't think it is reasonable to require extensions to
evaluate compatibility with everything.

however, it wouldn't hurt if the base spec said that the mechanisms of
_standards track_ extensions can be combined unless otherwise stated in
either of the extensions.  such a statement would force extension
writers to review existing extensions before publishing.
-- 
Kjetil T.

---

From: Michael Haardt <[email-masked]>
Date: Fri, 8 Apr 2005 12:01:35 +0200

> should the Subject use
> quoted-printable or base64?

RFC 2047 says in section 4:

   The "Q" encoding is recommended for
   use when most of the characters to be encoded are in the ASCII
   character set; otherwise, the "B" encoding should be used.

So that's well defined to be optional, but with a suggestion.

Interestingly, the vacation draft does not specify that if non-ASCII
characters are used in the reason, MIME encoding is required, like it
does for the subject.  And as you write, sometimes even ASCII characters
need to be quoted.  That section still needs some work.

> should the From header include the full
> name of the vacationist or just the e-mail address?

RFC 2822, section 3.4:

   Normally, a mailbox is comprised of two parts: (1)
   an optional display name that indicates the name of the recipient
   (which could be a person or a system) that could be displayed to the
   user of a mail application, and (2) an addr-spec address enclosed in
   angle brackets ("<" and ">").

There is no suggestion, it is well defined to be optional, though.

And that's what I say: If something is optional, it should be specified
as such.

How is a MIME entity be used to form a message? A multi part message is
a very different thing from a single part message and what will be used
sounds pretty application specific to me, so the application specification
should say something about it, even if both are fine.

> writers to review existing extensions before publishing.

Good idea, I agree with that.

Michael

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Fri, 08 Apr 2005 13:08:24 +0200

> should say something about it, even if both are fine.

RFC 2046 says:

   The use of the "multipart" media type with only a single body part
   may be useful in certain contexts, and is explicitly permitted.

this is as explicit as your other examples.  a multi-part message with a
single leaf entity should be presented to the user as if it was a
single-part message.
-- 
Kjetil T.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 12 Apr 2005 10:50:06 +0100

>with each other unless specified otherwise, extensions are forced to do
IMHO, people tend to forget defaults, so saying something explicitly is 
always a better thing.

>  IMHO formal definitions leave no room for assumptions,
The current de-facto rule is that the latest published document should 
list how the extension described in it interacts with other previously 
published extensions.