Esko Dijk <esko.d...@iotconsultancy.nl> wrote:
> object is a Voucher/VR. So to be compliant to the draft I can remove
> support for cf=18 as soon as TBD3 is allocated. I still don't see how
> cf=18 could be 'wanton extension of the protocol' as it is just using
> CoAP/COSE defined mechanisms that apparently are overruled by
> draft-constrained-voucher.The issue of interopability only comes up if there are clients which escape into the wild which use cf=18. If your server continues to accept cf=18, that's your problem :-) When we switches from /.well-known/est to /.well-known/brski, I left the processing in my server at first, because I needed to run through testing the client code (pledge and Registrar). And unit testing. And then I fixed all the clients and unit tests to use the new thing. (I do need to remove the old path now: Make before Break) Anyway, let's ask for an early allocation. We'll be 3-6 months before we get past the IESG and into IANA land to get a number. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
