#DNS over #CoAP because you can always run X over Y at an IETF hackathon.

#IETF123

As for multicast Block1 (block-wise PUT/POST request)… I think the block-size would have to be negotiated up front via a separate custom option.

Call it MCBlock1 (option 65000), unsigned integer consisting of:
- bits 0-3: SZX - Size exponent
- bit 4: P - Proposal
- bit 5: S - Master selection
- bit 6: C - Master cancellation

When a node wishes to send a blockwise file to a multicast group (via PUT or POST request payload) steps would be:

1. it sends a payload-less NON message to the group with the MCBlock1 option: SZX=its proposed block size exponent, P=1 (this is a proposal), S=0 & C=0 (no selections made)
2. The nodes that hear it, reply NON unicast, with their MCBlock1 responses; SZX=receiver's preferred SZX (same or less than sender), P=1, S=0 & C=0.
3. The sender picks one respondent, sends a UNICAST CON to that node with MCBlock1 with chosen SZX, P=0 (this is now the negotiated block size), S=1 ("I choose you") and C=0.
4. Respondent ACKs that CON message with Block1 set with a matching SZX (and block 0)… it has agreed.
5. Sender now sends to the group a NON message with MCBlock1 to the group: chosen SZX, P=0, S=0 and C=0.
6. The group nodes reply with a NON echoing the options as an acknowledgement.
7. Transfer begins using CON message Block1 with the agreed SZX … the chosen node ONLY sends the ACKs.

If the chosen node stops responding: sender sends a NON MCBlock1 C=1 unicast to that node, then goes back to step 3 to select another node… at step 4 the node responds with Block1 specifying the starting point, and the transfer resumes at step 7.

#CoAP #BlockwiseTransfer #RFC7959