# Back-on-track meeting on CoRAL (2023-02-24)

[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

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

* 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.

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

### PRs

* Draft text for URI-Scheme-ID registry
* https://github.com/core-wg/href/pull/57
* Wiki for URI Scheme IDs: https://github.com/core-wg/href/wiki/uri-schemes-that-we-want-numbers-for

**Resolution** from the 2023-01-20 Design Team Meeting: update the PR to reflect that:
* For all the currently registered schemes, an associated ID will be registered, which would mean quite a long IANA consideration section. Other than the 10 schemes already indicated in the CDDL definition, all the other schemes can get an ID in the 1+2 space.
* For any scheme registered in the future, the registration of an asssociated ID will happen automatically by IANA CC'ing the designated expert for the CRI list.
* In the 1+2 integer space, we can indicate a range of ID values for private use.
* The suggested new note for IANA to add to the "URI Schemes" registry will be updated to reflect the above.
* Strings become private-use only. Surface for x-dash problem is reduced to users of private use / unregistered schemes who later register it.
* IANA considerations will be long. Possibly defer to Bluetooth's list.

Note how this is somehow equivalent to how content-format values relate to media-type (yes, plus parameters, plus content coding ...)

Also, with strings being private-use, it can become a feature.

**Time line**: something to get WG feedback on mid-february, so there can be something WGLC'able mid-march in time for Yokohama? Progress on test vectors would be good (also for presentation).

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

### Next steps

* Close some issues and PRs (see above)

* Tests between Carsten and Thomas

* Converge on the registration policy for URI Scheme IDs

From IETF 114:

> * Implementation work should take around 6 more weeks after IETF 113. We probably need 1 more interim before a Working Group Last Call.
>
> * One or two revisions until we are done with the implementation testing, then discuss at an interim, then another revision.

* 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

* 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
* https://github.com/core-wg/coral/issues/21

* Language and direction tags in CBOR literals
* 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
* https://github.com/core-wg/coral/issues/16

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

* Default dictionary and dictionary parameter
* 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

* Expected revision before IETF 116?

CA: Unlikely; other things to prioritize.

### 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
- 2023-03-03, 15:00 UTC / 16:00 CEST
- https://meet.jit.si/TheCoRALNeedsToGrow