> These are reasonable points. > CoAP has congestion control, retransmissions, block-mode,... which are all > the things that TCP was doing for us. Re-inventing that would be silly. > So either all CoAP, or no-CoAP. > >> 2.2 However, i very much would like to re-use the CoAP "messaging model", >> aka: >> how messages over UDP are made reliable and in a limited fashion >> flow-controlled.
Here we are. I would assume that whatever “mini-CoAP” you start to design will grow features over time until it is indistinguishable from CoAP, except just different, looking like a bad example of NIH in the end. (From my IRTF perspective: When we designed CoAP, we didn’t have CBOR or CDDL available to us, so I think it would be an interesting research project to invent a CoAPng (next generation) that does use CBOR and CDDL. I’m just not so sure that this is what ANIMA wants to do.) I would expect that building a cGRASP around CoAP would have a little more design freedom than your garden-variety CoAP application. E.g., using a different port number might work around BCP190 (so no need to have /.well-known/coap-grasp in every message). The examples in Section 5 all use non-confirmable messages and then seem to hobble together confirmable messages and separate responses by adding options. Maybe the CoAP mechanisms are better for this; they have certainly received more design attention than what is sketched in Section 3. In any case, this is a non-trivial design effort, and it seems to me this is still a bit remote from a clear direction that the WG wants to work under, so I think this is the time for formative contributions as opposed to already adopting one (or, essentially, two) of them. Grüße, Carsten _______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
