Change:
create application specific request and response bodies which build on multiple already existing media types. <del> Applications using the application/multipart-core Content-Format define the semantics as well as the internal structure of the application/multipart-core representation according to the syntax described by the CDDL in mct-cddl. For example, one way to structure the sub-types specific to an application/multipart-core container is to always include them at the same fixed position.  This specification allows to indicate that an optional part is not present by substituting a null value for the representation of the part. Optionally, an application might use the general format defined here, but also register a new media type and an associated Content-Format identifier instead of using application/multipart-core. </del> <ins> The individual representations in an application/multipart-core body occur in a sequence, which may be employed by an application where such a sequence is natural, e.g. for a number of audio snippets in different formats to be played out in that sequence. In other cases, an application may be more interested in a bag of representations, which are distinguished by their Content-Format identifier, such as an audio snippet and a text representation accompanying it.  In such a case, the sequence in which these occur may not be relevant to the application.  This specification allows to indicate that an optional part is not present by substituting a null value for the representation of the part. A third situation that is common only ever has a single representation in the sequence, which is one of a set of formats possible.  This kind of union of formats may also make the presence of the actual representation optional, the omission of which leads to a zero-length array. Where these rules are not sufficient for an application, it might still use the general format defined here, but register a new media type and an associated Content-Format identifier to associate the representation with these more specific semantics instead of using application/multipart-core. </ins> 2.

Discussion:
So, a multipart representation can be processed up till the first error? Works for me.
I think we have to avoid saying "must check the whole thing before acting on any of it". The intention was not to say "If there is an error, you have to process up to the error". Is that what you read there?
mmm, that's not how I interpret "stop processing". Maybe "invalidate processing"?
But that is too close the meaning I'm trying to avoid. Maybe we can leave it slightly open as it is proposed now?
Sorry I'm not following: Which meaning are you trying to avoid? I think not removing the ambiguity in the text is a bad thing.
Nice, thanks (and also, my previous ship-it is still valid).
Klaus still sees a problem with assigning too much leeway to the application in giving the positioning special semantics. We'll need to discuss this a bit further...
I don't see how we could limit applications in this sense? It's intrinsically a piece of malleable data. And what's more important, your change here only talks about what happens on syntactic violations, which is as far as we can go to limit application leeway.
Well, this is introductory material that tells readers how this is supposed to be used. I made a proposal that I think reflects Klaus' sentiment. In the process, I lost the part that needed the fix requested by , but I think that is OK -- an introduction should not really have a MUST anyway. NAME — better?
Apart from the array, set and struct-like use cases, it'd be worth mentioning the "union" pattern that was discussed at the interim?
LGTM
NAME do you want to re-integrate af472b3 here or prefer to merge as-is?
Since about 9 hours I'm trying to write the union sentence; crazy day.
And, yes, af472b3 should stay in, but I don't care in which PR :-)
If you like the wording of the union pattern, this can go in and we can submit the next version.
Go for it! FWIW I like it very much.
Klaus: Carsten seems to prefer failing hard and early (draft-iab-protocol-maintenance). Thomas loves simplicity and +1 Carsten's proposal.
Klaus has a point, but we already have a way to evolve: Define a new media type.

I don't think there really is a need here to haphazardly send a new version of this to someone that might not understand it.
+1, as I said in other emails, we don't need to make it perfect now. Let's make it simple, use it and measure its ergonomics. We can always grab another code point in the future if this needs fixing.
NAME wdyt?
sorry, hit the wrong button
LGTM