Draft: draft-ietf-core-multipart-ct

Commentary: 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 ) . 
  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 do n'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  ' 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 . — 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 
 do you want to re - integrate here or prefer to merge as - is ? 
 Since about 9 hours I 'm trying to write the union sentence ; crazy day . 
 And , yes , should stay in , but I do n'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 . 
  : Carsten seems to prefer failing hard and early ( draft - iab - protocol - maintenance ) .  loves simplicity and +1  's proposal . 
 Klaus has a point , but we already have a way to evolve : Define a new media type . I do n'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 do n'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 . 
 wdyt ? 
 sorry , hit the wrong button 
 LGTM
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.