Talk about packed / tags

[chrysn]

In early phases of CRIs we talked about potential optimizations for particular URI patterns, eg. coap+sms://001555112358132134 into a more binary friendly format, https://base32stuff.onion/foo/bar as actual binary data or encoding LwM2M's paths like /1/2/3/3/1/5. We postponed that until the final stages, which we are now in.

At very least we probably want to say something about that CBOR packed is expected to be used in combination with CRIs.

I'm unsure on whether there will be many cases where there would be tags inside a CRI, especially because tags and packed don't do so well expanding to multiple items (although … could a packed table entry contain a CBOR sequence, and multiple items would expand like a CDDL group in an array? Wreaks havoc with parsers that use array length to decide content, but that's not how CDDL works).

Examples:

• http://base32ofbinarystuff.onion/foo/bar -> 12345(['binarystuff', [true, ["foo", "bar"]]]), with a tag expanding the binary stuff to a base URI and then having a 2nd item that is a CRI reference relative to it, or 12345(['binarystuff', ["foo", "bar"]]) whose CDDL would reach deeper into the CRI reference syntax
• coap://[2001:db8::1]/1/1/2/3 -> [0, ip'2001:db8::1', 64(h'01010203')] reusing an allocated tag because it does just the right thing, at least when pulled into a stand-in for array-of-strings?

[chrysn]

I think that the choice of whether any particular use of a CRI. Unless agreed on differently, packing and tags should not be expected to be supported (but maybe someone still tries if they have a way of recovery).

[chrysn]

Another example of a tag we'll want to use are tags 21..23 ("expected conversation to base…").

These examples seem to encourage using the stand-in concept is helpful here.