# Back-on-track meeting on CoRAL (2023-12-08)

[toc]

https://datatracker.ietf.org/doc/draft-ietf-core-coral/

Issue reference: https://tzi.de/~cabo/corewgcoralnotif.pdf

## Attendees
* Marco Tiloca
* Carsten Bormann
* Christian Amsüss
* Thomas Fossati

## Pinned Info

* Open issues: https://github.com/core-wg/coral/issues
- PRs for changes, but self-approve
* List of open points from the first meeting
- https://hackmd.io/Gnd7ZsTBT3-1o5A-6gS-Bg?both
* CoRAL Roadmap
- https://hackmd.io/b3s4Ve8JRrK0goTIZ6F3yg
* Biweekly meetings at: https://meet.jit.si/TheCoRALNeedsToGrow
- 15:30 CET every second Friday
* Previous meetings
- 2021-04-12 : https://hackmd.io/Gnd7ZsTBT3-1o5A-6gS-Bg
- 2021-04-23 : https://hackmd.io/rCME8RAySnuuS1PmARzQ7A
- 2021-05-07 : https://hackmd.io/Sg4duT8gSxa_eRzo0qd_tw
- 2021-05-21 : https://hackmd.io/c747nqnPRtmE5VVbnN3pqA
- 2021-05-28 : https://hackmd.io/vrfj-jquRuKhuypg8yiO2g
- 2021-06-11 : https://hackmd.io/T-xV5sTtSIOooy7yAy3nfA
- 2021-06-18 : https://hackmd.io/nhQwV-loTpudN1ZNHzxeFQ
- 2021-06-25 : https://hackmd.io/AMezYzy-SKKTGi9O52GWiA
- 2021-07-02 : https://hackmd.io/wNqS_lNlRByqVsib10t2bg
- 2021-07-23 : https://hackmd.io/W2CiW8NtS9Sa2L-49eB07w
- 2021-09-03 : https://hackmd.io/vIQGHrQpRE-d35Ace2DJsw
- 2021-09-17 : https://hackmd.io/mnQuussISuSO2Agx4SRsKw
- 2021-10-01 : https://hackmd.io/sUAHjJUmQrSvMNOGPT3iKA
- 2021-10-08 : https://hackmd.io/5zUiZsWvSfCuqNQc-OAY3g
- 2021-10-15 : https://hackmd.io/upCF-PFEQ-ubQLfy0MYz4Q
- 2021-10-21 : https://hackmd.io/P8AvNxdCRG6RY1C4eyYvUQ
- 2021-11-05 : https://hackmd.io/qEww5zxRS_21PBWypuboFA
- 2021-11-19 : https://hackmd.io/hL31EUHRQsWQ-lF8osHRPQ
- 2021-12-03 : https://hackmd.io/CeoMtQZrSy28ZQxurn964g
- 2022-01-14 : https://hackmd.io/2MGs5msIQVOd0uz80SyFVA
- 2022-02-11 : https://hackmd.io/6NPjVADRSFGiIfZu1sdzTg
- 2022-02-25 : https://hackmd.io/J55j_cyuQByyR33avTmN6Q
- 2022-03-11 : https://hackmd.io/N7C16wYWR8SnUwIKYjvMLw
- 2022-04-08 : https://hackmd.io/Rs7w0n_ISd-WojtCqW8GQg
- 2022-04-22 : No minutes taken
- 2022-05-06 : https://hackmd.io/UPtbaaz0QfyLBC4aQbnlzQ
- 2022-05-20 : https://hackmd.io/FXDhWuixRh6ybd8NBKP4Zw
- 2022-06-24 : https://hackmd.io/Sp7SQjC-RPKsx6KM3gOq3w
- 2022-07-15 : https://hackmd.io/YvFt5E4ZT8WYO8w6MdFTcw
- 2022-09-16 : https://hackmd.io/JUtbE466TGaR1BO4Eaqf_A
- 2022-09-30 : https://hackmd.io/uuwpZ6UmTHyC0m9jIYUC4g
- 2022-10-18 : https://hackmd.io/OLXfh4gSSQezHHgpZP1aEg
- 2023-01-20 : https://hackmd.io/xIPfLf2XQkKRzgD5ZVHbPg
- 2023-02-03 : https://hackmd.io/UEq4nLHVS-S7d55nnDUvdQ
- 2023-02-24 : https://hackmd.io/sAG9yEVDTa-itpb9XNM_Qw
- 2023-03-03 : https://hackmd.io/rVkjuQIJSSOilVjaiV8Tbw
- 2023-03-17 : https://hackmd.io/kDoth9AWTgi3AeCxbbm2YA
- 2023-04-28 : https://hackmd.io/CphhDX2fSYuGv5mIu08SkA
- 2023-06-23 : https://hackmd.io/n0FT0tiORUa-M4JJWkCkZQ
- 2023-07-07 : https://hackmd.io/JbMAbYZ2TjuDlvcSeshKpw
- 2023-08-17 : https://hackmd.io/vofc0QN3ROe1ucyNAK6Qkg
- 2023-09-01 : https://hackmd.io/CYEF2k1TTF-Sid57n8ylxQ

## Users for CoRAL
* https://datatracker.ietf.org/doc/draft-hartke-t2trg-coral-reef/
* https://datatracker.ietf.org/doc/draft-tiloca-core-oscore-discovery/
* https://datatracker.ietf.org/doc/draft-ietf-core-coap-pubsub/ (to be included)
* https://datatracker.ietf.org/doc/draft-ietf-core-dynlink/ (not yet)
* https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-gm-admin/
* The CoRAL content was split out to draft-ietf-ace-oscore-gm-admin-coral
* https://datatracker.ietf.org/doc/draft-ietf-core-observe-multicast-notifications/

https://datatracker.ietf.org/doc/draft-ietf-core-href/referencedby/
https://datatracker.ietf.org/doc/draft-ietf-core-coral/referencedby/

## HREF

https://datatracker.ietf.org/doc/draft-ietf-core-href/

### Misc

https://github.com/core-wg/href/wiki/URIs-and-CRIs-in-CoAP-APIs

Collect considerations about adapting/extending CoAP APIs to use CRIs. Christian will start looking at that.

### Implementation status

Christian's implementation (Python, Rust) as per href-10 (both ongoing)
* https://gitlab.com/chrysn/micrurus
* With the exception of the authority=true fix
* https://gitlab.com/chrysn/cri-ref
* For constrained implementations (currently with caveats); can do everything except URI(ref)->CRI(ref).

Thomas' implementation (Go) as per href-10:
* https://github.com/thomas-fossati/href

Carsten's implementation (Ruby) as per href-07:
* Finishing corrections for last test vectors
* Fundamental problem with Ruby URI module needs to be worked around
* Not yet implemented: PET

#### Test vectors

Official test vectors
* https://github.com/core-wg/href/tree/main/tests

More material for test vectors from Carsten
* https://codimd.ietf.org/2Y2YyFstQ5uenofIGBa4IQ?both
* Plan to make the generator compatible with Thomas' Test Vector format
* Revised based on TF and CA feedback.

More material for test vectors from Thomas (JSON)
* https://notes.ietf.org/z5JRYLyGTLO94zMGoqqfmQ?both
* To be revised following the revision to the test vectors above.

**TO DO**: test with Thomas; check PR 47 test vectors against implementations, merge (supports 43/44 and possibly 46)

### Open issues

* (From the previous meeting) DNS CBOR content format will probably align with what we do with host parts, so all would be aligned again.

CB: We'll discuss this in the next CBOR meeting, also w/ regard to next steps on packed.
CA: If DNS CBOR goes with dot-separated strings, will we go back as well?
CB: What are the gaps in translation?
CA: There are things like `["Mr. X's printer", "_print", "_tcp", "local"]` -- completely URI incompatible, but valid DNS and AIU supported on the DNS-SD side.
CB: We want to do it the same way on both sides.

* (From the previous meeting) (Not yet recorded as an issue:) Should we have a content-format number (and, thus, a media type)?

MT: Can we send a set?
CB: Could be a CBOR sequence. Question: What are semantics of it? (Is it link-format w/o attributes? What about relative?)
\*: Do we have media types? At least there is one for text/uri-list
CB: Possible use when no Location-\* options are allowd.
CA: Aren't those cases where the client needs more information anyway?
CB: Not dismiss it for lack of imagination, but also don't do it w/o good example.

* (From the previous meeting) (Not yet recorded as an issue:) On CoAP options

MT: At some point also considered Proxy-Cri option. Another possible option: Proxy-Scheme (integer-only).
CA: And nothing to do for Location b/c that doesn't touch the scheme. Doing Proxy-Scheme, let's stick with 1's-complement b/c that makes 'coap' encode to 0 encode to header value b'' which is compact for transport-indication.
Probably no luck with a Proxy-Int-Scheme (Proxy-CScheme?) that fits in a single <=+12 delta. Proxy-CRI can have a large number. Could use 267 b/c it has the properties and we don't get <=+12 delta with any option anyway and reliably is 1+1.

CB: Could go into an appendix.

* (From the previous meeting) On constraints section (coming from that the dots in the hosts may need to go in there)

CA: Don't see much value in the section, it's rather disturbing the flow
CB: Can move that section to appendix, keeping only the normative parts.

* (From the previous meeting) CB on test vectors: Some test vectors actually test specific directions of conversions. Do we have a classification to apply? Some survive URIref-CRIref-URIref round-trip etc, others where a URI reference is normalized by that.
CA: Don't have a good classification off my head; don't have a term for "normalized URI reference".

* Add test vector for [null, true, ...]
* https://github.com/core-wg/href/issues/77

* Appendix A (and outside): Add selected test vectors
* https://github.com/core-wg/href/issues/53

The draft can include selected test vectors intended for the reader to better understand (e.g,. using JSON or another format); extensive, machine-readable test vectors can be placed in a repository (e.g., in CBOR diagnostic notation).

* vectors: Annotate with required features
* https://github.com/core-wg/href/issues/52

### PRs

* Add discussion of and CoAP Options for CRI use in CoAP
* https://github.com/core-wg/href/pull/81

* Make tests available as JSON and as CSV (RFC 4180)
* https://github.com/core-wg/href/pull/79

* Extra test vectors
* https://github.com/core-wg/href/pull/47

### On the WGLC reviews (most content is from the previous meeting)

https://mailarchive.ietf.org/arch/msg/core/zMRga4VsC73vFWBI5ULy3gvRPvI/

Good to get back to three outstanding comments.

* Section 5.1: "two leading null values (scheme and authority both not given) MUST be represented by using the discard alternative instead, and"

Is this actually the only case where to use discard?

Scheme and authority are both not given also in case the first two elements in the outer array are null (absent scheme) and true (absent authority followed by rootless path). Shouldn't discard be used also in this case?

* Section 5.1: "an empty path in a CRI MUST be represented as the empty array [] (note that for CRI-Reference there is a difference between empty and absent paths, represented by [] and null, respectively),"

Figure 1 still admits null as possible encoding of path also in a CRI. What is its meaning in that case?

(Note that the distinction above between absent (=null) and empty (=[]) path is limited to CRI references, as expected)

This is still useful, in the interest of eliding a sequence of trailing null, but Section 5.2 focuses only on CRI references.

It feels like, in a CRI: null does not have an actual meaning for path, which can simply be an array, possibly empty to indicate the empty path; when converting from abstract to transfer form, the empty array is converted to null; when converting from transfer form to abstract form, a null for the path element becomes the empty array encoding the empty path.

MT: For CRIs, path null is good for the elition, but what does it mean? The handling of abstract->transfer form is a way to address it.
CB: Overall good to better distinguish between abstract and transfer form.

* [Section 5.2]
>
> * "If scheme and/or authority are present in the transfer form (i.e., the outer array starts with null, a text string, or a negative integer), set discard to true."
>
> Isn't it sufficient to say: "If scheme is present in the transfer form (i.e., the outer array starts with null, a text string, or a negative integer), set discard to true." ?

[-]
scheme could be null (which counts as absent), but authority given: //facebook.com/foo

->
* If the outer array starts with true or an unsigned integer, i.e., discard is present
* If the outer array starts with null, a text string, or a negative integer, i.e. one or two of scheme and authority are present

Invariant: If scheme and/or authority are not null, the
discard value is not transferred (it must be true in this case).

Make Section 5.2 more explicit about ingestion vs. ?encoding?

CA thinking about how the 6-tuple model could be more ... palatable

URI-reference = URI / relative-ref

full URI vs. relative-ref (do not use absolute-URI term, which is full-URI with fragment discarded to be used as a base)

CRI ref
scheme: Maybe negative, authority: Maybe complex, discard: Maybe unsigned, path: Maybe list, query: Maybe nonempty list, fragment: Maybe text
relative CRI reference
scheme: null, rest like CRI ref
CRI ("full CRI" to avoid abusing the "absolute" term which has fragment:null but we don't really need it)
scheme: negative, authority: complex, discard: null, path: list, query: Maybe nonempty list, fragment: Maybe text

Extra rules for CRI ref: If discard is set, path must be non-null. If path is set, query must be non-null.

comparing to Rust-style / Haskell-style enum:

Cri(as in CRI, without discard)
CriRefAuthority(authority: complex, path: list, query: Maybe nonempty list, fragment: Maybe text)
CriWithDiscardZeroAndPath(path: list, query: Maybe nonempty list, fragment: Maybe text)
CriWithDiscardZeroAndQuery(query: Maybe nonempty list, framgent: Maybe text)
CriWithDiscardZeroAndFragment(fragment: Maybe text)
CriWithDiscad(discard: true or positive, path: list, query: Maybe nonempty list, fragment: Maybe reference)

>> URI("urn:foo").merge(URI("bar"))
=> #<URI::Generic urn:foo>
>> URI("urn:foo").merge(URI("/bar"))
=> #<URI::Generic urn:foo>
>> URI("urn:foo/baz").merge(URI("/bar"))
=> #<URI::Generic urn:foo/baz>
>> URI("urn:/foo/baz").merge(URI("/bar"))
=> #<URI::Generic urn:/bar>

CA: The requirement from Henk to convert URI references to CRI references is making thigngs hard. More precisely: That requirement *combined* with the requirement to make all URIs expressible (even if just through extensions) makes it hard. Let's check w/ Henk whether converting the "normal" URI references (no non-authority bases, no initial //) suffices. Might incur some redesign, but with great simplifications (like, no more need to make sure `/foo` resolves precisely as it does in URIs with a URN base).
CB: Complexity and compatibility. Be careful about where we have compatibility.

* Section 5.3: "If the value of discard is true in the CRI reference (which is implicitly the case when scheme and/or authority are present in the reference), ..."

From the ingesting process in Section 5.2, I understand that at this point both scheme and authority are *present* as element of the CRI reference as a data structure, with a value admitted by the CDDL definition in Figure 1.

You probably mean: "which is implicitly the case when scheme is non-null and/or authority is neither null nor true in the CRI reference".

CA: Section 5.2 should be (more clearly) stating an equivalence between absence/presence and null/true values.
MT: That's be an alternative way to address it.

CA sent a mail "URI->CRI conversion and complexity" on 2023-09-01 at 17:18. The reply from Henk had some comments, though starting with "tl;dr not blocking that proposal".

### Next steps

CB: Enumerate sources of complexity to decide what to shed
* URI model, and its corners
* relative references
* Being concise (CA: That's not negotiable)
We have some nice things exceeding the URI model, eg. discard=0.

* Close issues and PRs (see above)

* Tests between Carsten and Thomas

* CA: I'm playing around a bit with CRIs as API components in CoAP APIs. Probably not even non-normative material for here, but for us to keep in mind. CB: Maybe in the core-href wiki? -> https://github.com/core-wg/href/wiki/URIs-and-CRIs-in-CoAP-APIs

## CoRAL

https://datatracker.ietf.org/doc/draft-ietf-core-coral/

Would be good to have documented a list of application-independent minimal components that have to be implemented to be ready for running/using a CoRAL-based application. Examples:
- "HREF engine"
- "CoRAL document navigator"
- Minimal CoRAL vocabulary

### Open issues

\[MINIMAL] denotes what is related to a minimal version of CoRAL

* Linking to local resources
* https://github.com/core-wg/coral/issues/29

* Embedded representations and their context
* https://github.com/core-wg/coral/issues/27

* Security model \[MINIMAL]
* https://github.com/core-wg/coral/issues/21

* Language and direction tags in CBOR literals [practically resolved]
* https://github.com/core-wg/coral/issues/19

* How using forms maps to following links
* https://github.com/core-wg/coral/issues/17

* CRI vs array literal serialization \[MINIMAL]
* https://github.com/core-wg/coral/issues/16

* Revisiting the tree serialization \[MINIMAL]
* https://github.com/core-wg/coral/issues/9

* Default dictionary and dictionary parameter \[MINIMAL]
* https://github.com/core-wg/coral/issues/6

* Eliding data and must-understand
* https://github.com/core-wg/coral/issues/3

### Open PRs

* Add tag for packed CBOR by reference
* https://github.com/core-wg/coral/pull/28

* Add some examples based on STP
* https://github.com/core-wg/coral/pull/20

### Dependencies (CoRAL use cases)

The following documents depend on CoRAL:

* https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-gm-admin: taken out the content on CoRAL and related examples. This is now in a separate draft draft-ietf-ace-oscore-gm-admin-coral (waiting for Chairs's approval on 2023-07-07)

* https://datatracker.ietf.org/doc/draft-tiloca-core-oscore-discovery/
translate CoRAL examples (which will be the format to use), add security considerations, then maybe WGA; implemented: mostly a set of RD queries; (discuss registry for target attributes -> Simple separate document; retroactively populate registry with well-known target attributes)

### Next steps

* Close issues and PRs (see above)

### Sync with SDF

AP: generate slideware that extracts the most salient points
- structure of CoRAL
- relationship to RDF (including RDF examples \[PR])
- use of links
- instance vs. class
- potential use in SDF (data, forms, ...)

How far are we from a discussion with Michael Koster & co. ?

## AOB and next meeting

* Next design team meeting on
- ???, 15:00 UTC / 16:00 CET
- https://meet.jit.si/TheCoRALNeedsToGrow