Draft: draft-ietf-core-multipart-ct

Commentary: ( ) Q1 The Introduction says talks about “ request or response body ’ . However , when looking in RFC 7252 , I do n’t find ‘ body ’ anywhere . I assume that ‘ body ’ refers to what RFC 7252 calls ‘ payload ’ . If so , I suggest aligning the terminology . ( For some reason section 10.2.3 of RFC 7252 does use ‘ message - body ’ , without any explanation or reference , but I guess that is just an error ) Q2 Related to Q1 , the text says : “ can be used to combine representations of zero or more different media types into a single message ” I assume it means ‘ single message payload ’ ? Because , you are not combing other parts ( Codes , Tokens etc ) of the message , are you ? I think it would be more clear if you said ‘ combine multiple representations , each using the same or different media types , into a single message payload ’ . Q3 The draft uses both ‘ media type ’ and ‘ media - type ’ . RFC 7252 uses ‘ media type ’ ( there is one instance of ‘ media - type ’ , though ) , so maybe align with that ? 
 ⁨⁩ 
 Q1 is addressed in 
 Finally closed in 
 LGTM
Mailing list commentary: Hi , Unless I have missed it , I would appreciate if the issues below could be addressed . They should only be editorial . Regards , Christer Lähettäjä : core : tiistai 23 . heinäkuuta 2019 17.53 Vastaanottaja : Aihe : [ core ] MULTIPART - CT : A few editorial comments Hi , A few minor editorial comments on draft - ietf - core - multipart - ct-03 : ( I have n’t read the IESG review comments , so my apologies if someone has already raised these comments )
Hi Christer , thank you for alerting us to this oversight . ( And thank you for the critical reading in the first place ! ) Right . Body is an RFC 7959 term ( which was adapted from HTTP ’s “ Message Body ” , obviously ) . I did n’t really want to muddy the picture by explaining again that CoAP block - wise transfers can cut up a single body into multiple payloads ( as per RFC 7959 ) . The current text already might be misunderstood to say that this media type is CoAP specific , which it is not at all . We did n’t go to the trouble of having a formal terminology import section ( apart from the usual BCP14 boilerplate in 1.1 ) . We could add that text , reference 7959 and 7230 as well , and make this abundantly clear . Or we could leave it as it is . That is about the message - body on the HTTP side , so it is exactly as it should be . ( Actually , 1.2 of 7252 says » This specification requires readers to be familiar with all the terms and concepts that are discussed in [ RFC2616 ] , including " resource " , " representation " , " cache " , and " fresh " . ( Having been completed before the updated set of HTTP RFCs , RFC 7230 to RFC 7235 , became available , this specification specifically references the predecessor version -- RFC 2616 . ) In addition , this specification defines the following terminology : « [ … ] So this term is already defined in RFC 7252 , albeit implicitly only . ) Actually , it now says This memo defines application / multipart - core , an application- independent media - type that can be used to combine representations of zero or more different media types , each along with a CoAP   identifier , into a single representation , with minimal framing overhead . This combined representation may then be carried in a single message , such as a CoAP [ RFC7252 ] request or response body . ( Where “ message ” might be a whole block - wise transfer . ) Is that better ? To carry that in a single message , you would carry it in the message ’s payload ( or , theoretically , in an option , but we only do that in OSCORE so far ) . The new text above more clearly separates the representation combining from the ability to send it in a single message then . Yeah , that ’s a bit funny . I actually believe we should have used media - type throughout the history of the term , as this is an artificial construct that only loosely relates to media types ( types of media ) . But maybe this draft is not the place to correct this mistake which has been in place since 1996 . That one instance is in the construction “ media - type ranges ” , which is the normal way to compose composites in English . I ’ m sure the RFC editor will force us to do that anyway , but I have made the change to “ media type ” ( with a space ) in the editors ’ copy in case we get to submit another version . Waiting for to show this at https://core- ( And the RFC editor will make us expand abbreviations and all that , too . ) ,
Paragraph (version A):
This memo defines application/multipart-core, an application-
independent media type that can be used to combine representations of
zero or more different media types into a single message, such as a
CoAP request or response body, with minimal framing overhead, each
along with a CoAP Content-Format identifier.
Paragraph (version B):
This memo defines application/multipart-core, an application-
independent media type that can be used to combine representations of
zero or more different media types into a single message body,
carried e.g., as a CoAP request or response payload, with minimal
framing overhead, each along with a CoAP Content-Format identifier.
Paragraph (version A):
This memo defines application/multipart-core, an application-
independent media type that can be used to combine representations of
zero or more different media types, each along with a CoAP Content-
Format identifier, into a single representation, with minimal framing
overhead.  This combined representation may then be carried in a
single message, such as a CoAP RFC7252 request or response body.
Paragraph (version A):
This simple and efficient binary framing mechanism can be employed to
create application specific request and response bodies which build
on multiple already existing media types.
Paragraph (version B):
This memo defines application/multipart-core, an application-
independent media type that can be used to combine representations of
zero or more different media types, each along with a CoAP Content-
Format identifier, into a single representation, with minimal framing
overhead.  This combined representation may then be carried in a
single message body, such as a CoAP RFC7252 request or response
payload.
Paragraph (version B):
This simple and efficient binary framing mechanism can be employed to
create application specific message bodies which build on multiple
already existing media types.
Paragraph (version A):
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
various formats to be played out in that sequence, or search results
returned in order of relevance.
Paragraph (version B):
The individual representations in an application/multipart-core
message 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 various formats to be played out in that sequence,
or search results returned in order of relevance.
Paragraph (version A):
Also, future specifications might want to define rough equivalents
for other multipart media types with specific semantics not covered
by the present specification, such as multipart/alternative
(Section 5.1.4 of RFC2046), where several alternative representations
are provided in the message, but only one of those is to be selected
by the recipient for its use (this is less likely to be useful in a
constrained environment that has facilities for pre-flight
discovery).
Paragraph (version B):
Also, future specifications might want to define rough equivalents
for other multipart media types with specific semantics not covered
by the present specification, such as multipart/alternative
(Section 5.1.4 of RFC2046), where several alternative representations
are provided in the message body, but only one of those is to be
selected by the recipient for its use (this is less likely to be
useful in a constrained environment that has facilities for pre-
flight discovery).