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

From: Esko Dijk <[email-masked]>
Date: Tue, 12 Feb 2019 15:02:34 +0000

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-masked]<mailto:[email-masked]>

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 12 Feb 2019 16:19:02 +0100

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

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 12 Feb 2019 21:02:49 +0000

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-masked]> On Behalf Of Klaus Hartke
Sent: Tuesday, February 12, 2019 10:19 AM
To: Esko Dijk <[email-masked]>
Cc: [email-masked]
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.

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:

Server:
  2.04
  Content-Format: 62

Klaus

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 12 Feb 2019 22:35:34 +0100

>From the point of view of CoAP, there is just a representation with
content-format 62. A client can indicate that it accepts a
representation with content-format 62; the server then is required to
return either a representation with content-format 62 or an error.
CoAP is not aware that the representation happens to contain embedded
representations and therefore the content negotiation mechanism cannot
be used directly to negotiate the formats of those.

>>  Maybe the draft-ietf-core-multipart-ct should extend the semantics of "Accept" to cover this case?

A content format is not a protocol extension and cannot override the
protocol definition.

> 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…

The value of the Accept option in the request needs to be registered
in the IANA registry and the value of the Content-Format option in the
response must be the same as Accept value.

Of course, one possible solution is to drop the use of content format
ID 62 entirely and just register one ID for each possible combination.
(But then the client can still only include at most one Accept option
in its request.)

> 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…

Max-Age doesn't have a meaning in requests and therefore must not be
there. I'm not sure where that about the Content-Format option comes
from. If a POST request has a payload, then the format of that payload
is described by a Content-Format option. (A GET request doesn't have a
payload and therefore must not include a Content-Format option.)

Klaus

---

From: Peter van der Stok <[email-masked]>
Date: Wed, 13 Feb 2019 09:00:41 +0100

HI all,

I have seen at least two viable solutions to the content-format
associated with draft-ietf-core-multipart-ct.
Probably, there are more possibiities.
Of course est-coaps can take over any of those solutions, but it then
remains a local est-coaps solution.
IMO the problem is more general.

I suggest that a solution is standardized in either
draft-ietf-core-multipart-ct or in a new to create draft.
The current text can then be removed from est-coaps and replaced with a
refrence to the text to be created.

Reactions?

Peter
Klaus Hartke schreef op 2019-02-12 22:35:

> Maybe thedraft-ietf-core-multipart-ct  should extend the semantics of "Accept" to cover this case?

Klaus

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 13 Feb 2019 17:51:58 +0000

> CoAP is not aware that the representation happens to contain embedded representations and therefore the content negotiation mechanism cannot be used directly to negotiate the formats of those. 
> The value of the Accept option in the request needs to be registered in the IANA registry and the value of the Content-Format option in the response must be the same as Accept value.
> Of course, one possible solution is to drop the use of content format ID 62 entirely and just register one ID for each possible combination. (But then the client can still only include at most one Accept option in its request.)

Hmm, that is a fair point. I don't think it is warranted to register four more content formats for all possible format combinations in the multipart response. 

It looks to me that your proposal of using Uri-Query in the request in order for the client to define the supported formats of the requested resource/response is a good one.

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Klaus Hartke
Sent: Tuesday, February 12, 2019 4:36 PM
To: Panos Kampanakis (pkampana) <[email-masked]>
Cc: Esko Dijk <[email-masked]>; [email-masked]
Subject: Re: [Ace] ace-coap-est-08: using /skg with Accept Option set to TBD287

>From the point of view of CoAP, there is just a representation with
content-format 62. A client can indicate that it accepts a representation with content-format 62; the server then is required to return either a representation with content-format 62 or an error.
CoAP is not aware that the representation happens to contain embedded representations and therefore the content negotiation mechanism cannot be used directly to negotiate the formats of those.

>>  Maybe the draft-ietf-core-multipart-ct should extend the semantics of "Accept" to cover this case?

A content format is not a protocol extension and cannot override the protocol definition.

> 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…

The value of the Accept option in the request needs to be registered in the IANA registry and the value of the Content-Format option in the response must be the same as Accept value.

Of course, one possible solution is to drop the use of content format ID 62 entirely and just register one ID for each possible combination.
(But then the client can still only include at most one Accept option in its request.)

> 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…

Max-Age doesn't have a meaning in requests and therefore must not be there. I'm not sure where that about the Content-Format option comes from. If a POST request has a payload, then the format of that payload is described by a Content-Format option. (A GET request doesn't have a payload and therefore must not include a Content-Format option.)

Klaus

---

From: Esko Dijk <[email-masked]>
Date: Thu, 14 Feb 2019 08:15:07 +0000

Using a query is a good solution here; I would propose a query argument as short as possible because we deal with constrained networks and we want to avoid needless parsing in this case - the server only needs to select between two format choices here, returning X.509 cert or PKCS#7 with cert.
The choice of encoding of the private key format PKCS#8 or CMS-EnvelopedData is depending on the payload the client sent in the /skg request, as written in the draft.

So to request PKCS#7 format , the default:
POST /est/skg

And to request X.509 format, the alternative that the server MAY support:
POST /est/skg?x

The latter has the benefit of small Option size, and can easily scale to many more formats/parameters in the future if really needed.

In light of this discussion thread we would need to update the "ct=....." link format descriptions in the draft also, e.g.
OLD:
</est/skg>;rt="ace.est.skg";ct="62 280 284 281 TBD287"

NEW:
</est/skg>;rt="ace.est.skg";ct=62

Note that this format is now CoAP-correct but has the drawback that the client can't see whether the optional TBD287 is supported or not in the /skg function.

Best regards,
Esko

Esko Dijk IoT Consultancy |  Email/Skype: [email-masked]

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Klaus Hartke
Sent: Tuesday, February 12, 2019 4:36 PM
To: Panos Kampanakis (pkampana) <[email-masked]>
Cc: Esko Dijk <[email-masked]>; [email-masked]
Subject: Re: [Ace] ace-coap-est-08: using /skg with Accept Option set to TBD287

Klaus

---

From: Michael Richardson <[email-masked]>
Date: Thu, 14 Feb 2019 09:37:36 -0500

Panos Kampanakis (pkampana) <[email-masked]> wrote:
    > Hmm, that is a fair point. I don't think it is warranted to register
    > four more content formats for all possible format combinations in the
    > multipart response.

    > It looks to me that your proposal of using Uri-Query in the request in
    > order for the client to define the supported formats of the requested
    > resource/response is a good one.

It seems a totally adhoc way that totally subverts the content-type system.
It really seems like we need to take this to CORE.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Thu, 14 Feb 2019 10:03:23 -0500

CORE people, the thread is here:
    https://mailarchive.ietf.org/arch/msg/ace/L1QPw1zHAj15nsKMe8AFDu6dcmI

Esko Dijk <[email-masked]> wrote:
    > Using a query is a good solution here; I would propose a query argument
    > as short as possible because we deal with constrained networks and we
    > want to avoid needless parsing in this case - the server only needs to
    > select between two format choices here, returning X.509 cert or PKCS#7
    > with cert.

Using a query really seems broken to me...

    > And to request X.509 format, the alternative that the server MAY support:

Why not just use:
    POST /est/skx

It's even shorter, and it's much more obvious if it is not supported.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Esko Dijk <[email-masked]>
Date: Thu, 14 Feb 2019 15:11:29 +0000

> It really seems like we need to take this to CORE.

Well it's the definition of the multipart-ct that causes the subversion of the content-type system! CoAP as a protocol doesn't know about multipart. If we would like to re-use the proper CoAP content-type system, it means each possible combination of multipart that is being used or returned should get its own unique Content-Format ID assigned. Like Panos indicated that could amount in our case to 4 content-formats for /skg.
The use of a generic "multipart" type (62) effectively renders the CoAP content-format system useless for use in sub-content-format selection.

If not using this content-format system - using a query parameter is a fully CoAP compliant next-best way to handle this situation while still using the generic multipart type 62. The basic CoAP rules are thus still fulfilled, i.e. the resource offers type 62 and it returns type 62 always, while the query parameter merely influences the processing of POST on this resource as is quite common in HTTP/CoAP operations. For example in HTTP I could POST some data to a resource that creates different HTML layouts that can be selected by a query parameter:
 POST /genReport?layout=nice1
 { data }

It still returns one and the same content type (HTML) although the contents may be totally different, depending on the 'layout' parameter. Same reasoning goes for our multipart content-format. In CoAP semantics, the inner types of the multipart are in no way bound to the requested Content-Format and may be arbitrarily changed depending on query parameters. 

But I agree this can be taken to CoRE in context of the draft-multipart-ct discussion; see what people think about this issue.

Esko