Description

Work on a format to replace link-format is going on around the CoRAL format, and chances are CRIs are the first part of that that can become stable. CRIs are a CBOR based representation of the information in a URI (largely compatible, and where it's not it's in areas that implementations often don't get right anyway), and especially suitable when CoAP requests are later built from it.

The data structure that uri_parser produces is almost aligned with the CRI information model, and I think it'd be convenient to align them to the point where such a struct can be used as an internal representation of a CRI. Then, CRIs from CoRAL documents could be preprocessed into uri_parser_result, and requests built from them.

The current discrepancies are:

• host is currently in text form; CRIs have either a text DNS name or a binary representation of the IP literal. Parsing this early would make sense as it makes the later use easier, but might be problematic with the uri_parser_result notion of using the original URI as immutable backing store (and even if mutation is allowed, which might make sense, the text form is shorter than the binary form for some addresses).
  • CRIs don't have a zone identifier; that's OK, and the internal representation would have one.
• port is numeric in CRI; could be changed easily.
  • CRIs allow omitting the port; as long as we only convert internal representations to CRIs where we know the scheme, that can be handled at conversion time.
• path and query are delimited by their delimiting characters '/' and '&'. CRIs can contain almost arbitrary texts (including '/' in path components and '&' in query components), which would be percent-escaped in URIs -- but we can choose not to support such URIs at all (the current uri_parser doesn't, as it'd need to percent-decode them for mapping into CoAP) for starters. When converting a CRI, that might need to be taken in mutably to allow replacing the CBOR characters with the agreed-on delimiters. (Long-term, being able to express all CRIs would be nice, especially because we do proxying with it, but let's take this step by step)

Useful links

• CRI draft: https://tools.ietf.org/html/draft-ietf-core-href-14
• How it'd be used: CoRAL: https://tools.ietf.org/html/draft-ietf-core-coral-03
• uri_parser result for comparison: https://riot-os.org/api/structuri__parser__result__t.html
• uri_parser main use case: Proxying gcoap: add simple forward-proxy #13790

Next steps

I'd keep this around as a tracking issue while uri_parser is being developed on during proxy development; when actual CRI support is added, it can be closed in that PR.