Subject: sieve vacation draft, :mime

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 25 Sep 2007 13:29:59 +0200

Hi,

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.

I suggest that
   a) content-type MUST be included (since if it's not included, what's 
the point of :mime?)
   b) content-transfer-encoding MAY be included, and if it's not 
included, the c-t-e is 7bit
   c) header fields defined in 2822 MUST NOT be included (e.g. received, 
to, subject)
   d) other header fields MAY be included (e.g. x-loop, x-message-flag, 
content-disposition)

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 25 Sep 2007 13:51:41 +0200

Oops.

Arnt Gulbrandsen writes:
> ...

  e) MIME-Version MUST NOT be included

Arnt

---

From: Ned Freed <[email-masked]>
Date: Tue, 25 Sep 2007 08:53:37 -0700 (PDT)

> 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.

>    a) content-type MUST be included (since if it's not included, what's

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.

> 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,

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,

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

---

From: Ned Freed <[email-masked]>
Date: Tue, 25 Sep 2007 10:21:25 -0700 (PDT)

>   e) MIME-Version MUST NOT be included

MIME-Version isn't an entity header, so this is already covered as well.

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 25 Sep 2007 22:48:51 +0200

Ned Freed writes:
> MIME entities are only supposed to contain MIME headers,

The definition in 2045 contains this sentence:

    Any sort of field may be present in the header of an entity,
    but only those fields whose names begin with "content-" actually have
    any MIME-related meaning.

> 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.

I agree that once a document is in the queue, the threshold for 
attempting a change should be high. Higher than e.g. the threshold for 
issuing an erratum.

The reason I'm unhappy today is that I just discovered lots of test 
cases. (I wasn't an implementer two years ago, I'm afraid.) I don't 
want to have to write code and tests for e.g. Subject being present in 
both :mime and :subject.

In fact, if your intention as document editor was that only MIME header 
fields should be present, I think I'll be quiet now and write some code 
to discard all other header fields. That's simple to implement and it's 
always possible to write more complicated code if someone complains.

Arnt