On Fri, 2005-04-08 at 00:37 +0200, Michael Haardt wrote:
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.
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.
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.
clearly the draft should be fixed.
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.
"notify" is not an RFC so it's not appropriate to reference it. "copy"
has no actions.
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.
"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.