# Back-on-track meeting on CoRAL (2023-01-20)

[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

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

### 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**: check PR 47 test vectors against implementations, merge (supports 43/44 and possibly 46)

### Latest discussions

* Carsten and Marco had a focused, hands-on meeting on 2022-12-16.
* https://notes.ietf.org/tC_vDEnhTzSaPby_axdslQ

* Most issues can be closed in the next revision;
* #43 and #44 should be possible to close

"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)

CA: If I'm on a constrained device, seeing PET would already make me bail on using it, so meh. But if I see a host name I'd pass it on, and someone hands me ["www.example", "com"], then I'd either try resolving (www, example, com) or (www.example, com) on implementation details.

A CRI with such a dot are invalid. What harm can come to a user that does not check?

CB: Classes "really valid", "denormalized" (a subclass of "invalid"), "invalid". Should we create room for the denormalize case?

CA: Two chocies are "consumer MUST check" or "consumer that doesn't check *and* relies on URI for security is screwed".
CB: Possible consequences? a deserved "resource not found", or creating a resource under an invalid name? It's a security consideration b/c differences in error handling can be used for fingerprinting.
CA: "... *and* does not want to leak even one bit for fingerprinting".

CA: "SHOULD" with sec cons for "if you swallow without digesting, be prepared for these possible..."
CB: Will need to be explicit about impls that don't do PET at all.

CB, summarizing: We have that problem of the dot already in PET, but there it was in an extension and now it's in the base spec. 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.
CB: Not sure where to put the text. (We don't have "Interoperability considerations").
MT: A new section 5.4, including interop considerations? CB: 2.2?

* #46 should be possible to close, by merging the related PR #58
DONE

* #52 and #53 should be possible to close after testing, by merging the related PR #47

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

* #50 is about a specific implementation; possible to close when merging PR #47
CA will create a new issue about specific points to clarify in the specification --> https://github.com/core-wg/href/issues/59

* Need to test with Thomas;

* Possible good direction on the registration of negative integer registration for current & future URI schemes (see also the notes linked above).
* PR #57 - https://github.com/core-wg/href/pull/57

CoRE interim meeting on 2023-01-18
https://datatracker.ietf.org/meeting/interim-2023-core-01/session/core

Resolution: 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).

### Open issues

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

* 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

* Empty paths with the two no-authority versions (CLOSED)
* https://github.com/core-wg/href/issues/46

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

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

### PRs

* Forbid rootless no-authority CRIs without path (MERGED)
* https://github.com/core-wg/href/pull/58

* 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
* Minutes interim meeting 2022-10-12: https://datatracker.ietf.org/doc/minutes-interim-2022-core-14-202210121600/
* Slides interim meeting 2022-10-12: https://datatracker.ietf.org/meeting/interim-2022-core-14/materials/slides-interim-2022-core-14-sessa-20221012-core-href-00.pdf
* Minutes interim meeting 2023-01-18: https://datatracker.ietf.org/doc/minutes-interim-2023-core-01-202301181500/
* Slides interim meeting 2023-01-18: https://datatracker.ietf.org/meeting/interim-2023-core-01/materials/slides-interim-2023-core-01-sessa-constrained-resource-identifiers-00.pdf

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

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

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