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
