Revisit whether we do need authority-less support

[chrysn]

(Yes I know, I brought this up initially... but we've come some way in CoRAL since then, and I'd like to reflect whether we're on the right track still).

Supporting URIs with no authority ("URN-style URIs"?) brings some complexity. Does that carry its weight?

I hope to come to a way forward within a few minutes today, and conclude this.

---

Scratchpad notes (primarily for design team meeting):

• note: The cases of inexpressible URIs (coap://host/user%40domain.com can not be expressed in CoAP, only coap://host/user@domain.com can be) might be more wide-spread in non-CoAP URIs than assumed due to file scheme thread), possibly we'd want to allow 32("mailto:me@my.domain") in all CRI positions for these cases and completeness' sake. (With profiles ruling them out for many applications).
• note: I don't see how we'd proxy to .
• argument to keep: CRIs can be used in mixed namespaces to build incompletely compressed vocabularies (compressing the CURIE part and spelling out the detail). Will we use that? Is it better than concatenating onto 32()s?
• argument to drop: If constrained applications would likely not do anything useful with them, they can just as well be URIs.
• argument to keep-but-not-implement: We should probably say something anyway so that processing assumed-invalid CRIs is no show-stopper but just "distinct from other CRIs" (and you usually compare only to known CRIs).

[cabo]

"did" (W3C d-something ID) is a URN-form URI that we probably need to support more, not less

[chrysn]

Looking at their syntax, they should really have put the method-name:method-specific-id into the authority component :-/

Now they have URLish identifiers (with their own path structure importing path-abempty after their prefix) but can't use discard-all.

sigh

I guess that settles it.

[chrysn]

Summarizing further discussion: For DID URLs (they are used in both forms, but both are authority-less) CRI URNs do provide useful preprocessing. It's not clear yet how useful DID URLs will really be, but if they will, support in CRIs will be helpful.

Thus URNs stay in CRIs for now; implementers can still skip them if they don't plan ever dereferencing or storing them.

[cabo]

Based on the agreement that we want to support URN-style URIs like DID, I think we can close this now.

[chrysn]

I'm not fully sold here. The complexity we'd have to allow in to capture ever CRI is substantial.

There's two values in CRIs: Providing a model that's easier to deal with than URIs, and serializing that model for CoAP URIs. Pushing the model to be all-encompassing threatens the simplicity of the CoAP serialization. A solution for DIDs might be to have URNs in the model (there limited to what a particular DID variation can do), and have serializations for DIDs and CoAP URIs that share parts of the model but not the full insanity.

[chrysn]

From today's discussion: Complexity is there in the model, .feature "extended-cri" makes that visible to whoever wants to use anything that needs it. OK with me.