Thanks Klaus and Esko. > If the preferred Content-Format cannot be returned, then a 4.06 "Not > Acceptable" MUST be sent as a response, unless another error code takes > precedence for this response.
Well, RFC7252 refers to a singular content format. In our case we are talking about a dual content format (286 or 281 and 280 or 284) returned in a 62 multipart-content. Would it be a violation of RFC7252, since RFC7252's text had single content format responses in mind only? > Maybe the draft-ietf-core-multipart-ct should extend the semantics of > "Accept" to cover this case? I think that is good idea. The simplest way to do that would be encode the 3 content formats (for example 62, 286 and 280) into a single CF included in the Accept option which tells the server what combination of content formats to send back. Would that violate RFC7252 because the Content-Formats needs to be actual CFs defined in the IANA registry and not a combination of them? Panos >From a previous thread with Jim S., I was under the impression that In the >virtual CoAP WG meeting a month back we went through in some explicit detail >that both Content-Format and Max-Age have no meaning when appearing on a >request and therefore should not be there. -----Original Message----- From: Ace <[email protected]> On Behalf Of Klaus Hartke Sent: Tuesday, February 12, 2019 10:19 AM To: Esko Dijk <[email protected]> Cc: [email protected] Subject: Re: [Ace] ace-coap-est-08: using /skg with Accept Option set to TBD287 Esko Dijk wrote: > So the client asks for 286, but gets 62 (which has 286 embedded in it > as one of the parts). At first sight this appears incompatible with > CoAP RFC7252 logic. > > A strict server implementation might return 4.06 Not Acceptable since > the server code has registered the response type to be 62; and the > client asks something different. RFC 7252 is quite strict about this: If the preferred Content- Format cannot be returned, then a 4.06 "Not Acceptable" MUST be sent as a response, unless another error code takes precedence for this response. That's a MUST, not a SHOULD. Since a client might actually support multiple formats, it might make sense to indicate all supported formats in order of preference e.g. as query parameters: Client: POST /.well-known/est/skg?ct=TBD287&ct=281 Accept: 62 ... Server: 2.04 Content-Format: 62 Payload: (multipart containing TBD287) Klaus _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
