Dear authors & WG, A question on the new -08 text regarding the /skg response: the text indicates the following request & response
Client: POST /.well-known/est/skg Accept: TBD287 Content-Format: 286 Server: 2.04 Content-Format: 62 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. Maybe the draft-ietf-core-multipart-ct should extend the semantics of “Accept” to cover this case? (Or would we rather fall back to returning PKCS#7 always, within the multipart content. It would be possible to define a /skg2 URI that returns the other multipart format. Or we could even define a new content format TBD which encodes a multipart type including a TBD287, so the client can use the Accept Option as normal to request the wanted multipart type.) Regards Esko Esko Dijk IoT Consultancy | Email/Skype: esko.d...@iotconsultancy.nl<mailto:esko.d...@iotconsultancy.nl>
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace