Thanks Jim. We have addressed all of them in the upcoming next iteration.
We also have addressed Klaus' feedbacks and will send a response to him this
week.
The only issue left is the embedded content types which is being discussed as
you know.
Panos
-Original Message-
From: Ace On
On Feb 20, 2019, at 22:33, Panos Kampanakis (pkampana)
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 misu
> -Original Message-
> From: Panos Kampanakis (pkampana)
> Sent: Wednesday, February 20, 2019 1:34 PM
> To: Jim Schaad ; ace@ietf.org; Klaus Hartke
>
> Cc: draft-ietf-ace-coap-...@ietf.org
> Subject: RE: [Ace] Embedded Content Types
>
> Hi Jim,
>
> Thank you. Sorry I couldn't make it
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
Hello Jim,
Thanks for your comments! I understand and I agree. In any case, my point
wasn’t really that there was no situation in which a 4.01 reply would make
sense. My point was that, in the way the draft is currently written, it asks a
RS to return 4.01 in certain cases, and in at least some
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
Hi Valery,
On 2019-02-19, 19:02, "Valery Smyslov" wrote:
> When done over CoAP, the message would be sent with CONfirmable, so it
> would be ACK'ed. I would make the first message CONfirmable too.
>
> That makes it much like IKEv2 is, where all messages are ACKed and the
>