Re: [Ace] Embedded Content Types

["Panos Kampanakis (pkampana)" <[e-mail]>]

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 <[e-mail]> 
Sent: Thursday, February 21, 2019 6:35 PM
To: 'Carsten Bormann' <[e-mail]>
Cc: Panos Kampanakis (pkampana) <[e-mail]>; 'ace' <[e-mail]>; 'Klaus Hartke' <[e-mail]>; [e-mail]
Subject: RE: [Ace] Embedded Content Types

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


> -----Original Message-----
> From: Carsten Bormann <[e-mail]>
> Sent: Thursday, February 21, 2019 2:52 PM
> To: Jim Schaad <[e-mail]>
> Cc: Panos Kampanakis (pkampana) <[e-mail]>; ace 
> <[e-mail]>; Klaus Hartke <[e-mail]>; 
> draft-ietf-ace-coap- [e-mail]
> Subject: Re: [Ace] Embedded Content Types
> 
> On Feb 21, 2019, at 23:31, Jim Schaad <[e-mail]> 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