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