The sieve vacation draft doesn't say as much about :mime as it should.
IMO, it should specify precisely which header fields must, may and must
not be included in the :mime response.
First of all, as far as the current draft goes this discussion is happening
almost two years too late. Sieve vacation is in the RFC Editor queue - it is
currently blocked on the base specification. The only changes that have been
made to vacation since it was approved have been ones to align stuff like IANA
registrations with current publication requirements.
I suggest that
a) content-type MUST be included (since if it's not included, what's
the point of :mime?)
Strongly disagree. The point of :mime could have been to specify a text/plain
part in the US-ASCII charset that also includes content-description or
content-id fields. In such a case the content-type would be optional according
to MIME and I see no reason why Sieve vacation should impose additional
requiremens on the MIME entities it allows people to construct.
b) content-transfer-encoding MAY be included, and if it's not
included, the c-t-e is 7bit
This is already implicit in the definition of a MIME entity and IMO does not
need to be restated.
c) header fields defined in 2822 MUST NOT be included (e.g. received,
to, subject)
This is also implicit in the definition of a MIME entity and while I can see
some merit in restating this particular restriction I don't think it rises to
the level of revising a draft in the RFC Editor queue.
d) other header fields MAY be included (e.g. x-loop, x-message-flag,
content-disposition)
MIME entities are only supposed to contain MIME headers, so this is actually
changing and extending what the document currently allows. Absent a really
compelling case for adding this functionality I don't think now is the time
to revisit this decision.
Ned