Subject: [Ace] Embedded Content Types

From: Jim Schaad <[email-masked]>
Date: Wed, 20 Feb 2019 09:58:40 -0800

The CoRE working had an interesting virtual meeting this morning (my time)
where the main topic of discussion was how to deal with embedded content
types.  This is a current problem that needs to be addressed with the EST
document which is currently trying to deal with last call comments.  The log
from the meeting can be found at
https://etherpad.tools.ietf.org/p/core-interim-2019-02-20.

The takeaway from this that I got was:
1.  There is a real problem and we need to figure out the best ways to try
and deal with this in a generic manner.   This is a problem not only here,
but it the Publish/Subscribe CoRE document and in many other cases that we
can see.

2.  We are not going to get a general solution immediately so EST needs to
look at  doing something now.

3.  A couple of different possibilities where discussed that could be used:
a)  Return a list of links rather than a multipart content and let the
client sort through that list and download the things that they want.  This
is a purely reactive solution.
b) Use a different URI to ask for the different options.  This could be done
either by the use of a different URI path or by the use of a query
parameter.
c) Register a different content type for each of the possible return values.

There was a general preference for the use of a different URI as being the
solution that should be used today.  The idea of registering multiple
content types was generally disliked as it does not really extend well.
There was no specific preference on whether the use of a different URI path
or a query parameter would be preferred.  The use of a different URI would
allow for better discovery of capabilities.  

The idea of listing nested content types in the 'ct' link type was also
universally disliked.

The CoRE, T2TRG and other forums are expected to continue discussions on
this topic in different contexts such as Pub-Sub and CoRAL. To come up with
both proactive and reactive solutions to the more general problem.

Jim

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 20 Feb 2019 21:33:42 +0000

Hi Jim,

Thank you. Sorry I couldn't make it to the CORE interim meeting. 

I see the challenge with content-format ID explosion in option c. So I agree that in the long run, there needs to be a long-term solution and option b seems the best for the general case.

There are challenges with option b and EST-coaps though. If we broke the requests to different URIs, it means that a client needs to keep track of his transactions and on top of it he needs to correlate the key and the cert he receives at a later time. So, after pulling the two URIs he has to cryptographically confirm the key is tied to the certificate. Additionally, this deviates from the logic of the EST protocol which we are trying to profile on. We are adding new APIs to the protocol. 

Because of these challenges, I would like to use option c in the ETS-coaps draft. It is not violating RFC7252 and it does not affect the long term plan (option b) either. There are only to content types we are talking about in EST-coaps, a key and a cert. A key can be encrypted or not. A cert can be in PKCS#7 or plain pkix-cert. That makes four combinations. The number cannot explode further, so we could live with it in this context.

Any strong objections?

Rgs,
Panos

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Jim Schaad
Sent: Wednesday, February 20, 2019 12:59 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Ace] Embedded Content Types

The CoRE working had an interesting virtual meeting this morning (my time) where the main topic of discussion was how to deal with embedded content types.  This is a current problem that needs to be addressed with the EST document which is currently trying to deal with last call comments.  The log from the meeting can be found at https://etherpad.tools.ietf.org/p/core-interim-2019-02-20.

The takeaway from this that I got was:
1.  There is a real problem and we need to figure out the best ways to try
and deal with this in a generic manner.   This is a problem not only here,
but it the Publish/Subscribe CoRE document and in many other cases that we can see.

2.  We are not going to get a general solution immediately so EST needs to look at  doing something now.

3.  A couple of different possibilities where discussed that could be used:
a)  Return a list of links rather than a multipart content and let the client sort through that list and download the things that they want.  This is a purely reactive solution.
b) Use a different URI to ask for the different options.  This could be done either by the use of a different URI path or by the use of a query parameter.
c) Register a different content type for each of the possible return values.

There was a general preference for the use of a different URI as being the solution that should be used today.  The idea of registering multiple content types was generally disliked as it does not really extend well.
There was no specific preference on whether the use of a different URI path or a query parameter would be preferred.  The use of a different URI would allow for better discovery of capabilities.  

The idea of listing nested content types in the 'ct' link type was also universally disliked.

The CoRE, T2TRG and other forums are expected to continue discussions on this topic in different contexts such as Pub-Sub and CoRAL. To come up with both proactive and reactive solutions to the more general problem.

Jim

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

---

From: Jim Schaad <[email-masked]>
Date: Wed, 20 Feb 2019 16:39:43 -0800

> From: Panos Kampanakis (pkampana) <[email-masked]>
> Sent: Wednesday, February 20, 2019 1:34 PM
> To: Jim Schaad <[email-masked]>; [email-masked]; Klaus Hartke
> <[email-masked]>
> Subject: RE: [Ace] Embedded Content Types
> 
> Hi Jim,
> 
> I see the challenge with content-format ID explosion in option c. So I
agree
> that in the long run, there needs to be a long-term solution and option b
> seems the best for the general case.
> 
> There are challenges with option b and EST-coaps though. If we broke the
> requests to different URIs, it means that a client needs to keep track of
his
> transactions and on top of it he needs to correlate the key and the cert
he
> receives at a later time. So, after pulling the two URIs he has to
> cryptographically confirm the key is tied to the certificate.
Additionally, this
> deviates from the logic of the EST protocol which we are trying to profile
on.
> We are adding new APIs to the protocol.

[JLS]  I don't understand what you are saying here.  If you defined
/est/sgkA and /est/sgkB and said that the multipart content returned for
each of this is a fixed content type, then the client is going to send a
message to one of them in a consistent manner and both the key and the
certificate would be returned in a single response.  

The question of the key being encrypted is controlled by an attribute in the
CSR and thus there is no outside negotiation needed for that aspect.  The
only difference in content is the use of PKCS#7 vs bare certificate.

Jim

> 
> Because of these challenges, I would like to use option c in the ETS-coaps
> draft. It is not violating RFC7252 and it does not affect the long term
plan
> (option b) either. There are only to content types we are talking about in
EST-
> coaps, a key and a cert. A key can be encrypted or not. A cert can be in
> PKCS#7 or plain pkix-cert. That makes four combinations. The number cannot
> explode further, so we could live with it in this context.
> 
> Any strong objections?
> 
> Rgs,
> Panos
> 
> 
> 
> from the meeting can be found at https://etherpad.tools.ietf.org/p/core-
> interim-2019-02-20.
> 
client sort
> through that list and download the things that they want.  This is a
purely
> reactive solution.
parameter.
> solution that should be used today.  The idea of registering multiple
content
> types was generally disliked as it does not really extend well.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Feb 2019 02:10:37 +0100

On Feb 20, 2019, at 22:33, Panos Kampanakis (pkampana) <[email-masked]> wrote:
> 
> If we broke the requests to different URIs, it means that a client needs to keep track of his transactions and on top of it he needs to correlate the key and the cert he receives at a later time.

I think this is just a misunderstanding — the idea wasn’t to supply the parts under different URIs, but to make up different URIs for retrieving the different combinations coming in one multipart-core, in one transaction.

As in

/skg?sk=284&spk=281

(Where sk is short for “secret key” and spk for “signed public key” — substitute your own names.)

or, say

/skg/284,281

This provides full format agility while preserving the interaction model.

Grüße, Carsten

---

From: Peter van der Stok <[email-masked]>
Date: Thu, 21 Feb 2019 09:12:30 +0100

Hi, 

For me the est-coaps solution with different URIs is a good one.
as suggested by Carsten, /skg/ctnumbers seems straightforward.
In the return of /.well-known/core, the CT hints will help. No need to
define multiple content-format combinations.

Peter

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Feb 2019 10:37:26 -0500

Carsten Bormann <[email-masked]> wrote:
    > I think this is just a misunderstanding — the idea wasn’t to supply the
    > parts under different URIs, but to make up different URIs for
    > retrieving the different combinations coming in one multipart-core, in
    > one transaction.

    > This provides full format agility while preserving the interaction model.

I sure prefer this over other hacks.
Would the client say Accept: 62 to indicate it's willingness to receive a multipart?

It seems that multiple Accept: option headers may be allowed.

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

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 21 Feb 2019 21:32:17 +0000

Thanks Carsten. 

Let's say we use a query /skg?sk=xxx&spk=yyy. /skg/xxx,yyy is a different URI imo, so it changes the EST spec and that introduces changes that affect CAs that already implemented it. So let's say we do /skg?sk=xxx&spk=yyy. When I am doing resource discovery and the server is returning the content formats for skg, is he going to signal his supported formats with 
</est/skg>;rt="ace.est.skg";ct="62 xxx yyy"

RFC5272 says
> The Content-Format code "ct" attribute provides a hint about the 
> Content-Formats this resource returns.  Note that this is only a hint, 
> and it does not override the Content-Format Option of a CoAP response 
> obtained by actually requesting the representation of the resource. 
> [...] The Content-Format code attribute MAY include a space-separated 
> sequence of Content-Format codes, indicating that multiple 
> content-formats are available.

So it looks tome that ct="62 280 284 281 TBD287" could hint to the client that all the following formats are supported for the multipart. 

I had a chat with Klaus where he mentioned that he assumed the ct="63 xxx yyy" returned attribute values are the accepted values by the server in the "Accept" option. 

-----Original Message-----
From: Carsten Bormann <[email-masked]> 
Sent: Wednesday, February 20, 2019 8:11 PM
To: Panos Kampanakis (pkampana) <[email-masked]>
Cc: Jim Schaad <[email-masked]>; [email-masked]; Klaus Hartke <[email-masked]>; [email-masked]
Subject: Re: [Ace] Embedded Content Types

As in

/skg?sk=284&spk=281

or, say

/skg/284,281

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Thu, 21 Feb 2019 13:54:15 -0800

> Sent: Thursday, February 21, 2019 1:32 PM
> To: Carsten Bormann <[email-masked]>
> Cc: Jim Schaad <[email-masked]>; [email-masked]; Klaus Hartke
> <[email-masked]>; [email-masked]
> Let's say we use a query /skg?sk=xxx&spk=yyy. /skg/xxx,yyy is a different
> URI imo, so it changes the EST spec and that introduces changes that affect
> CAs that already implemented it. So let's say we do /skg?sk=xxx&spk=yyy.
> When I am doing resource discovery and the server is returning the content
> formats for skg, is he going to signal his supported formats with

This is why I would prefer doing something like "/est/skg" and "/est/skg/yyy".  This does not change any existing servers other than getting the ct values corrected in discovery.

> So it looks tome that ct="62 280 284 281 TBD287" could hint to the client that
> all the following formats are supported for the multipart.
> 
> I had a chat with Klaus where he mentioned that he assumed the ct="63 xxx
> yyy" returned attribute values are the accepted values by the server in the
> "Accept" option.

I would agree with Klaus that this is a correct answer.

Jim

> Cc: Jim Schaad <[email-masked]>; [email-masked]; Klaus Hartke
> <[email-masked]>; [email-masked]
> > If we broke the requests to different URIs, it means that a client needs to
> keep track of his transactions and on top of it he needs to correlate the key
> and the cert he receives at a later time.
> 
> I think this is just a misunderstanding — the idea wasn’t to supply the parts
> under different URIs, but to make up different URIs for retrieving the
> different combinations coming in one multipart-core, in one transaction.
> 
> As in
> 
> /skg?sk=284&spk=281
>

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 21 Feb 2019 22:11:21 +0000

> This is why I would prefer doing something like "/est/skg" and "/est/skg/yyy".

Not sure I am following. Are these two request URIs? Or in the discovery response?

-----Original Message-----
From: Jim Schaad <[email-masked]> 
Sent: Thursday, February 21, 2019 4:54 PM
To: Panos Kampanakis (pkampana) <[email-masked]>; 'Carsten Bormann' <[email-masked]>
Cc: [email-masked]; 'Klaus Hartke' <[email-masked]>; [email-masked]
Subject: RE: [Ace] Embedded Content Types

> Let's say we use a query /skg?sk=xxx&spk=yyy. /skg/xxx,yyy is a 
> different URI imo, so it changes the EST spec and that introduces 
> changes that affect CAs that already implemented it. So let's say we do /skg?sk=xxx&spk=yyy.
> When I am doing resource discovery and the server is returning the 
> content formats for skg, is he going to signal his supported formats 
> with

> > Content-Formats this resource returns.  Note that this is only a 
> > hint, and it does not override the Content-Format Option of a CoAP 
> > response obtained by actually requesting the representation of the resource.
> > [...] The Content-Format code attribute MAY include a 
> > space-separated sequence of Content-Format codes, indicating that 
> > multiple content-formats are available.
> 
> So it looks tome that ct="62 280 284 281 TBD287" could hint to the 
> client that all the following formats are supported for the multipart.
> 
> I had a chat with Klaus where he mentioned that he assumed the ct="63 
> xxx yyy" returned attribute values are the accepted values by the 
> server in the "Accept" option.

Jim

> keep track of his transactions and on top of it he needs to correlate 
> the key and the cert he receives at a later time.
> 
> I think this is just a misunderstanding — the idea wasn’t to supply 
> the parts under different URIs, but to make up different URIs for 
> retrieving the different combinations coming in one multipart-core, in one transaction.
> 
> As in
> 
> /skg?sk=284&spk=281
>

---

From: Jim Schaad <[email-masked]>
Date: Thu, 21 Feb 2019 14:31:05 -0800

I am thinking of two different URLs, that is not do the difference by a query parameter but by changing the URI.  This makes it easier because the client should be able to be deterministic about going to the same URI so it should do the second POST to the same location and there is no need for any existing code to be changed.  These would be two different URIs and there would be one additional URI returned in the query to well-known/core.

Jim

> Sent: Thursday, February 21, 2019 2:11 PM
> To: Jim Schaad <[email-masked]>; 'Carsten Bormann' <[email-masked]>
> This is why I would prefer doing something like "/est/skg" and
> "/est/skg/yyy".  This does not change any existing servers other than getting
> the ct values corrected in discovery.
> 
> 
> >
> > RFC5272 says

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Feb 2019 23:52:26 +0100

On Feb 21, 2019, at 23:31, Jim Schaad <[email-masked]> wrote:
> 
> I am thinking of two different URLs, that is not do the difference by a query parameter but by changing the URI.

Note that the query parameters are part of the URI, so fundamentally there is no difference between putting the info there or in the path part of the URI.

The path part can be slightly more concise.  We are more used to “computing” the query part.  I don’t have a strong preference.

But in either case it is good if discovery can find the URI being offered (including its query parameters, if those are used).

(And I agree that the “ct” target attribute really is for the top level media type; of course we could invent a new target attribute “ect” for embedded content formats [and fight against autocorrection for the rest of our lives :-)].)

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Thu, 21 Feb 2019 15:35:03 -0800

It is true that the query parameters are part of the type.  However, the use of two different URIs allows for the discovery to figure out if both versions are supported rather than having either a failure occur because the query parameter is not supported or getting the wrong answer back because it is not looked for.

Jim

> Sent: Thursday, February 21, 2019 2:52 PM
> To: Jim Schaad <[email-masked]>
> Cc: Panos Kampanakis (pkampana) <[email-masked]>; ace
> <[email-masked]>; Klaus Hartke <[email-masked]>; draft-ietf-ace-coap-
> [email-masked]
> Note that the query parameters are part of the URI, so fundamentally there
> is no difference between putting the info there or in the path part of the
> URI.
> 
> The path part can be slightly more concise.  We are more used to
> “computing” the query part.  I don’t have a strong preference.
> 
> But in either case it is good if discovery can find the URI being offered
> (including its query parameters, if those are used).
> 
> (And I agree that the “ct” target attribute really is for the top level media
> type; of course we could invent a new target attribute “ect” for embedded
> content formats [and fight against autocorrection for the rest of our lives :-
> )].)
> 
> Grüße, Carsten

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 22 Feb 2019 03:21:15 +0000

That comes with a set of problems. A simplification needs to take place. It is probably better to just mandate one content-type for cert to get away without complicated combined content types. We don't need to support TBD287 and 281 in the embedded responses. It makes more sense to not do so. 

As for why, there are a three reasons I can think of: 
1) Two separate URIs means we are adding state tracking for the CA. The CA now needs to support 
- EST that says "give me the key and a cert all at once and then forget about it".
- EST-coaps that says "give me a key. Remember this key/cert pair and serve the certificate until I decide to come back and get it". Now imagine I have 10000 of endpoints enrolling. The server keeps state for all of them and cannot forget them until he gets the equivalent requests. And then, what happens if a cert is lost on the way back? The CA is supposed to remember the key / cert for some time. There is a DoS vector right there. 

2) One more challenge with two URIs is that the client needs to somehow signal in the 2nd request to the server to tell him what key/cert he is expecting to get, so there is one more new thing the client now needs to do. 

3) Additionally, it sounds like we are doomed with the discovery. The server cannot tell the client what embedded types he supports, thus the client will just try asking different combinations until he gets a response.

That is why I think two URIs are a bad idea. A query type may be OK, but I can see Carsten and Klaus' point. We can just keep one cert content type in the multipart, that simplifies it. 

Rgs,
Panos

-----Original Message-----
From: Jim Schaad <[email-masked]> 
Sent: Thursday, February 21, 2019 6:35 PM
To: 'Carsten Bormann' <[email-masked]>
Cc: Panos Kampanakis (pkampana) <[email-masked]>; 'ace' <[email-masked]>; 'Klaus Hartke' <[email-masked]>; [email-masked]
Subject: RE: [Ace] Embedded Content Types

Jim

> <[email-masked]>; Klaus Hartke <[email-masked]>; 
> draft-ietf-ace-coap- [email-masked]
> > I am thinking of two different URLs, that is not do the difference 
> > by a query
> parameter but by changing the URI.
> 
> Note that the query parameters are part of the URI, so fundamentally 
> there is no difference between putting the info there or in the path 
> part of the URI.
> 
> But in either case it is good if discovery can find the URI being 
> offered (including its query parameters, if those are used).
> 
> (And I agree that the “ct” target attribute really is for the top 
> level media type; of course we could invent a new target attribute 
> “ect” for embedded content formats [and fight against autocorrection 
> for the rest of our lives :-
> )].)
> 
> Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Thu, 21 Feb 2019 19:55:08 -0800

Panos,

Someplace you are not understanding what I am saying.  

> Sent: Thursday, February 21, 2019 7:21 PM
> Cc: 'ace' <[email-masked]>; 'Klaus Hartke' <[email-masked]>
> That comes with a set of problems. A simplification needs to take place. It is
> probably better to just mandate one content-type for cert to get away
> without complicated combined content types. We don't need to support
> TBD287 and 281 in the embedded responses. It makes more sense to not do
> so.
> 
> - EST-coaps that says "give me a key. Remember this key/cert pair and serve
> the certificate until I decide to come back and get it". Now imagine I have
> 10000 of endpoints enrolling. The server keeps state for all of them and
> cannot forget them until he gets the equivalent requests. And then, what
> happens if a cert is lost on the way back? The CA is supposed to remember
> the key / cert for some time. There is a DoS vector right there.

I don't see this as occurring because that is not what I am suggestion.  In my world view there is no difference between doing the following:

POST /est/skg/XXX
POST /est/skg?ct=XXX

In both cases the client posts the CSR to the CA and returns a multipart response.  The response contains the private key and the certificate.  I would say that the difference between /est/skg and /est/skgXXX is that the first returns the certificate as a PKCS#2 and the second returns it as a bare certificate.  In both cases how one wraps the key (encrypted or not) is going to be based on either an attribute in the CSR or a decision on the part of the CA.  (It could be either encrypt w/ the key just given or don't issue certificate because you did not give me the needed attribute.)

If the CA does not need to spend a long time doing the processing of the certificate creation, then there is no need for a cache.  Using this method means that an RA which is using a current CA would send the post to the normal location on the CA and then convert the certificate to from a PKCS#7 to a plain certificate for the second URI, just like what you are probably thinking for the query parameter.  

By the way - you still have this same potential DOS for the case of manual intervention where the CA needs to keep the approval of the CSR around and match it against the request the second time it comes in when you say - ask me again later.  The expectation is that there would be a "limited" number of requests kept or for a limited amount of time.

> 
> 2) One more challenge with two URIs is that the client needs to somehow
> signal in the 2nd request to the server to tell him what key/cert he is
> expecting to get, so there is one more new thing the client now needs to do.

No, the client does not need to do this because the multipart always returns a single answer.

> 
> 3) Additionally, it sounds like we are doomed with the discovery. The server
> cannot tell the client what embedded types he supports, thus the client will
> just try asking different combinations until he gets a response.

That is the reason for doing the second URI.  The second URI can be identified by name and thus the client can know which combination is going to work.

Jim

> 
> That is why I think two URIs are a bad idea. A query type may be OK, but I can
> see Carsten and Klaus' point. We can just keep one cert content type in the
> multipart, that simplifies it.
> 
> Rgs,
> Panos
> 
> Cc: Panos Kampanakis (pkampana) <[email-masked]>; 'ace'
> <[email-masked]>; 'Klaus Hartke' <[email-masked]>; draft-ietf-ace-
> [email-masked]
> It is true that the query parameters are part of the type.  However, the use
> of two different URIs allows for the discovery to figure out if both versions
> are supported rather than having either a failure occur because the query
> parameter is not supported or getting the wrong answer back because it is
> not looked for.
> 
> Jim
> 
>

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 22 Feb 2019 04:09:42 +0000

OK, I was clearly misunderstanding what you were proposing. 
I can see that second URI working fine without affecting existing systems. Will update the draft. 

-----Original Message-----
From: Jim Schaad <[email-masked]> 
Sent: Thursday, February 21, 2019 10:55 PM
To: Panos Kampanakis (pkampana) <[email-masked]>; 'Carsten Bormann' <[email-masked]>
Cc: 'ace' <[email-masked]>; 'Klaus Hartke' <[email-masked]>
Subject: RE: [Ace] Embedded Content Types

Panos,

> That comes with a set of problems. A simplification needs to take 
> place. It is probably better to just mandate one content-type for cert 
> to get away without complicated combined content types. We don't need 
> to support
> TBD287 and 281 in the embedded responses. It makes more sense to not 
> do so.
> 
> - EST-coaps that says "give me a key. Remember this key/cert pair and 
> serve the certificate until I decide to come back and get it". Now 
> imagine I have
> 10000 of endpoints enrolling. The server keeps state for all of them 
> and cannot forget them until he gets the equivalent requests. And 
> then, what happens if a cert is lost on the way back? The CA is 
> supposed to remember the key / cert for some time. There is a DoS vector right there.

POST /est/skg/XXX
POST /est/skg?ct=XXX

> 
> 2) One more challenge with two URIs is that the client needs to 
> somehow signal in the 2nd request to the server to tell him what 
> key/cert he is expecting to get, so there is one more new thing the client now needs to do.

> 
> 3) Additionally, it sounds like we are doomed with the discovery. The 
> server cannot tell the client what embedded types he supports, thus 
> the client will just try asking different combinations until he gets a response.

Jim

> 
> That is why I think two URIs are a bad idea. A query type may be OK, 
> but I can see Carsten and Klaus' point. We can just keep one cert 
> content type in the multipart, that simplifies it.
> 
> Rgs,
> Panos
> 
> <[email-masked]>; 'Klaus Hartke' <[email-masked]>; 
> draft-ietf-ace- [email-masked]
> It is true that the query parameters are part of the type.  However, 
> the use of two different URIs allows for the discovery to figure out 
> if both versions are supported rather than having either a failure 
> occur because the query parameter is not supported or getting the 
> wrong answer back because it is not looked for.
> 
> Jim
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 22 Feb 2019 11:46:19 -0500

Carsten Bormann <[email-masked]> wrote:
    >> I am thinking of two different URLs, that is not do the difference by
    >> a query parameter but by changing the URI.

    > there is no difference between putting the info there or in the path

Really? Aren't there caching differences?
(Not that these things should ever be cached)

---

From: Jim Schaad <[email-masked]>
Date: Fri, 22 Feb 2019 09:14:19 -0800

> From: Michael Richardson <[email-masked]>
> Sent: Friday, February 22, 2019 8:46 AM
> Cc: Jim Schaad <[email-masked]>; Panos Kampanakis (pkampana)
> <[email-masked]>; ace <[email-masked]>; Klaus Hartke
by
> (Not that these things should ever be cached)

Not in CoAP, for CoAP options are part of the cache key.  I don't know for
sure about HTTP but normally it says only GETs and use the URI.  That would
say that options are part of the cache key.

Jim