Re: [Ace] ace-coap-est-08: using /skg with Accept Option set to TBD287

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 <ace-bounces@ietf.org> On Behalf Of Klaus Hartke
Sent: Tuesday, February 12, 2019 10:19 AM
To: Esko Dijk <esko.dijk@iotconsultancy.nl>
Cc: ace@ietf.org
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
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace