# Back-on-track meeting on CoRAL (2023-04-28)

[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

## 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
- 2022-01-20 : https://hackmd.io/xIPfLf2XQkKRzgD5ZVHbPg
- 2022-02-03 : https://hackmd.io/UEq4nLHVS-S7d55nnDUvdQ
- 2022-02-24 : https://hackmd.io/sAG9yEVDTa-itpb9XNM_Qw
- 2022-03-03 : https://hackmd.io/rVkjuQIJSSOilVjaiV8Tbw
- 2022-03-17 : https://hackmd.io/kDoth9AWTgi3AeCxbbm2YA

## 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/
* 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

* Future compatibility: State unparsable CRIs are like NaN
* https://github.com/core-wg/href/issues/61

* CRIs allow ambiguious encodings for empty path list
* https://github.com/core-wg/href/issues/59

* 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

* Questions and oddities found updated micrurus implementation
* https://github.com/core-wg/href/issues/50

* Allowed over-PETting
* https://github.com/core-wg/href/issues/44

"The duty of checking is with the recipient; an intermediary that doesn't use (or merely does reference resolution) it may pass it on without being checked. Consumers and producers have to do it right; those who pass it on do not have to do the checks."? (for both over-PETting and placing dots in host segments).

We have that problem of the dot already in PET, but there it was in an extension and now it's in the base specification. So everyone using host names will have to do this right. But these also go through character set reduction, case insensitivity etc. For hostname elements, dots are forbidden. If you have the duty of correct production, you may delegate that to the party producing your input.

Put the text in a new section including interop considerations, e.g., as Section 5.4 or Section 2.2.

Another option is including this in the current Section 7 "Extended CRI: Accommodating Percent Encoding (PET)".

Actually, the whole section 7 can rather be "CRI Extensibility" and cover: the current content on PETting; the resolution above for issue 44; the resolution above for issue 60; the new anticipations from issue 61.

* Can't have overscaped dots
* https://github.com/core-wg/href/issues/43

### PRs

* Describe recomended error handling, forbid indefinite-length
* https://github.com/core-wg/href/pull/62

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

### Next steps

* 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: probably take out CoRAL "how to use with CoRAL" and examples into a separate draft (translate from old text form to CBOR EDN; park while CoRAL is completed); close to WGLC otherwise.

* 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

* HREF at the CoRE interim meeting on 2023-05-10
- https://datatracker.ietf.org/meeting/interim-2023-core-07/session/core

* Next design team meeting on
- 2023-05-12, 14:00 UTC / 16:00 CEST
- https://meet.jit.si/TheCoRALNeedsToGrow

## Setup of the packing tables

table content:

* 0: core.rt
* 1: core.if
* 2: core.a
* 3: core.s
* 4: core.ll
* 5: urn:iana:....:pubsub-terms

table pubsub-terms:

* 0: core.ps-subscriber
* 1: core.ps-publisher

113([ [] / thereof we'll later pick 2 /,
  [106("packed.example")] / thereof we'll later pick 3 /,
  [6(["https://", "/foo.html"]),
   6(["coap://", "/bar.cbor"]),
   6(["mailto:support@", ""])]
])


1130([cri'urn:iana:....:different-table', 2, 3, rump])

concrete document would contain:

1130([packed-5, 2, 3, [...]])

for [...], we now have an extended table setup:

* 0: NaN (if core table item 5 was unknown) or pubsub item 0
* 1: NaN (if core table item 5 was unknown) or pubsub item 1
* 2: core item 0 = core.rt

CB: So we embrace undefined outputs of unpacking? Possibly simple(23) / undefined.
CA: Having a concrete value would simplify debugging and also make spec'ing CoRAL easier, b/c we only need to say "skip undefined, it's likely from unpacking"
CB: Two variants of unpack operation, one in which undefined is fatal and one where it's just "undefined".
CA: It helps that CoRAL works preferably in open-world scenarios.
CA: 1130 in packed or companion document?
CB: undefined handling needs to be in base doc.
CA: Good, it can happen with the "By the application environment, e.g., a media type." cae that's already in there.

How to process:

struct TableParts {
    length: index,
    values: Either<ListFromDocument, ListFromRom, AllUndefined>,
    next: Maybe<TableParts>,
}

and whenever encountering a compressed item, the uncompressor traverses the current table parts head and walks until it finds the right index.

### How much does it make sense to split up literals into items?

A (from draft-ietf-cbor-packed-08)
     [2, 6(-30) / item 75 for core.osc.gconf:sign_params.key_type_capab.key_type /, 1],
     [2, 6(30) / item 76 for core.osc.gconf:sign_params.key_type_capab.curve /, 6],

B (from an alternative-universe CoRAL of the same custom CBOR)
     [2, 6(-30) / item 75 for core.osc.gconf:sign_params /, literal([1, [1, 6]]),

Possible criterion? "Does it ever make sense to query for the 6 without also querying for the 1 in front of it?"

<> <urn:core.osc.gconf:sign_params> "[1, [1, 6]]"##xsdext:cbor .

<> <urn:core.osc.gconf:sign_params> "8201820106"##xsdext:cborhex .

xsdext:cbor says `[1, [1, 6]]` = `[1,[1,6]]` = the cborhex thing.

CB: Elevating CBOR Diagnostic Notation to interchange format :-( -- but probably OK

CB: What are we losing here?
CA: Two questions -- do we allow it, and is it a good choice in a concrete situation?

X core:rt "foo" ,
          "bar" .

X core:rt '["foo", "bar"]'#cbor .

but that's a CBOR patching topic too.

CB: One issue w/ merge patch is that a single data structure both contains the address and the new value.
CB: Try to get CRDT properties.
CA: http://christian.amsuess.com/idea-incubator/rdf-crdt-and-user-interfaces/ (yes it's about user interfaces and that's far down the road)
... concluding PATCH is important.
CA: CBOR patching a CoRAL, or CoRAL patch?
CB: Maybe CoRAL patch can be an extension of CBOR patch.
CA: Sounds like RG material
CB: Maybe multiple steps ... starting from CBOR pointer (which we need for FETCH).

CB: How much can we learn from YANG CBOR? Where we talk about SIDs but on the wire we see deltas.