Subject: Re: [apps-discuss] Working Group Last Call ondraft-ietf-appsawg-multipart-form-data

From: Larry Masinter <[email-masked]>
Date: Wed, 8 Apr 2015 07:09:42 +0000

This was a working group last call comment that I think I overlooked.

On 11/11/14, 3:11 AM, "t.petch" <[email-masked]> wrote:

>I note that this I-D specifies
>
>   Encoding considerations:  Common use is BINARY.
>
>Looking at
>http://www.iana.org/assignments/media-types/multipart/related
>I see
>
>Encoding considerations:   Multipart content-types cannot have
>                           encodings.
>
>I have looked at more recent RFC, such as RFC6838, and can see nothing
>to gainsay this.  Does this restriction still apply?

I don’t know whether Multipart content-types can have encodings, or if not, why not.
But Encoding considerations apply even if they can’t be encoded, to tell you that transport is impossible if you have a 7-bit channel and you want to send content that needs either an 8-bit channel (BINARY) or an encoding.

Maybe the template name ‘Encoding considerations’ is too easy to take literally?

Larry

---

From: Ned Freed <[email-masked]>
Date: Fri, 10 Apr 2015 08:51:50 -0700 (PDT)

> I don’t know whether Multipart content-types can have encodings, or if not,

MIME specified that CTEs are not allowed on multipart and message top-level
types in email. (Web encoding: fields are a separate issue.) This was
done to avoid the possibility of nested encodings.

This restriction was recently lifted for the message/global part in EAI, but
not, AFAIK for any sort of multipart.

> But Encoding considerations apply even if they can’t be encoded, to tell
> you that transport is impossible if you have a 7-bit channel and you want to
> send content that needs either an 8-bit channel (BINARY) or an encoding.

Exactly right.

> Maybe the template name ‘Encoding considerations’ is too easy to take

Yes, that's definitely a problem.

				Ned