Content-Transfer-Encoding

[peteroupc]

The text for section 4.7 currently reads:

Previously, it was recommended that senders use a "Content-Transfer- Encoding" encoding (such ss quoted-printable) for each non-ASCII part of a multipart/form-data body. This recommendation is "deprecated": senders MUST NOT send any parts with a content-transfer-encoding header. No deployed implementations that send such bodies have been discovered.

But this precludes the use of multipart/form-data on 7-bit only transports, such as default SMTP, wherever non-ASCII form data has to be sent. This requirement, though, makes sense on transports that allow binary data, such as HTTP. Note also that the previous version of this draft was less strict in this respect. Moreover, as senders include forwarding proxies, this requirement unnecessarily applies to proxies. A better word would be "generate", rather than send.

I would prefer text like the following:

This recommendation is "deprecated": senders MUST NOT generate any parts with a content-transfer-encoding header field unless the part is being sent via a 7-bit only transport, in which case it may be necessary to use a transfer encoding such as "base64" or "quoted-printable". No deployed [...] Note that HTTP is not a 7-bit only transport.

Note:

Change "such ss quoted-printable" to "such as quoted-printable".

[masinter]

Do you know ANY implementations that generate multipart/form-data with CTE ? I imagine some might consume it, but the same question applies.

[peteroupc]

I don't mean to imply that I am aware of a current implementation that either "sends" or generates those kinds of header fields. I mean to state that as it's currently defined, it would be impossible to send a "multipart/form-data" entity with 8-bit bytes over a 7-bit only transport. If that is the intention, some additional text to the effect that such an entity is unsuitable for such a transport would be appropriate.

[masinter]

So either CTE is MAY or SHOULD NOT.

INteroperability considerations should say some implementations don't support it. Encoding considerations should point out "binary if non-ASCII headers or body"

[peteroupc]

For binary transports such as HTTP, I prefer "MUST NOT" or "SHOULD NOT" generate a Content-Transfer-Encoding header field on individual parts. For other transports (both 7-bit and "8-bit"), I prefer not to impose a requirement on whether this header field is to be generated on individual parts (nearly all other multipart media types don't impose additional restrictions in this respect).

[peteroupc]

An editorial change:

Change "is deprecated for use in contexts" to "is deprecated in contexts".

[masinter]

could you explain why? I like the extra "for use". The term 'deprecate' isn't a formal term in IETF, I'm using it to note that a MAY has turned into a SHOULD NOT, but not for all uses, just those uses in a particular context.

Do you think it is wrong or just extraneous. If wrong, why? If not, I'll claim editorial prerogative.

[peteroupc]

The words "for use" is not necessarily wrong. However, those words as they appear now imply that this media type (or the header field) is only "for use" in contexts that allow binary data, when this most likely isn't the case