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:
[email protected]<mailto:[email protected]>
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
