[Top] [All Lists]

Re: draft-degener-sieve-editheader-01.txt

2004-01-15 17:50:31

But in the (more common) case where
the filter is operating on behalf of the recipient, I would want to be
able to do the changes I want done.  (kind of a tautology there.)

I don't think we have enough data to judge which use of
this proposed extension is common.

And.. what about replaceheader?

As mentioned in section 9.1, replaceheader is no longer in the draft.
My implementation still has it, but it's a vendor-specific extension
after encountering determined opposition from some members of the
work group.  If you implement it, the rules with respect to duplication
would be the same as for add- and deleteheader.

Hmm- certainly seems like replaceheader is a convenient shortcut
for "deleteheader" and "replaceheader" -- except that you lose
position, which I consider a loss (for reasons given above).

You lose count, too; if multiple headers of the same sort are present,
you can't generally rename them (e.g., Cc to Resent-Cc) because you
can't loop in sieve.

This response brings up a couple new questions too, which can only
be explained by my ignorance I'm afraid, but here goes:

Is there a separate work group for "editheader"?

There's no IETF work group (anymore) for sieve -- so all extensions are
formally private submissions, although they do tend to refernce to this
mailing list as a point of discussion.

How does a vendor-specific extension get specified vis-a-vis "require" ?

RFC 3028, section 6.1.  Their name starts with "vnd."

And in that light, could not the rules for duplication also become
"vendor-specific" ?

In general, I don't think that's a good way of dealing with conflicting
opinions about details of an implementation.