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