# Back-on-track meeting on CoRAL (2022-09-30)

[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

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

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

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

### Next steps

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.

## Registration of CRI negative integers for URI schemes?

* In general, how is extensibility for supporting further URI schemes addressed? No registry is defined at the moment for the negative integers encoding the used URI scheme.

See CDDL definition at https://datatracker.ietf.org/doc/html/draft-ietf-core-href#section-5.1

* For specific implications, see the two cases in point below, i.e., [-observe-multicast-notifications](https://datatracker.ietf.org/doc/draft-ietf-core-observe-multicast-notifications/) which in turn affects [-groupcomm-proxy](https://datatracker.ietf.org/doc/draft-tiloca-core-groupcomm-proxy/).

### Use in -observe-multicast-notifications

In [-observe-multicast-notifications](https://datatracker.ietf.org/doc/draft-ietf-core-observe-multicast-notifications/), the error informative response from the server also specifies two URIs, currently as text strings ("**OLD WAY**" below). Those are: i) the URI where the server will send multicast notifications to the listening clients; ii) the URI of the origin server (only scheme and authority).

The plan was to switch to using a CRI instead ("**NEW WAY**" below), see:

* [PR #13](https://github.com/core-wg/observe-multicast-notifications/pull/13) (to be completed);

* Overview in slides 8-9 of https://datatracker.ietf.org/meeting/114/materials/slides-114-core-core-observe-multicast-notifications-observe-notifications-as-coap-multicast-responses-00.pdf

**=== OLD WAY ===**

The informative response is now transporting transport-specific information in the 'tp_info' parameter.

informative_response_payload = {
  0 => array,  ; ’tp_info’, i.e., transport-specific information
? 1 => bstr,   ; ’ph_req’ (transport-independent information)
? 2 => bstr    ; ’last_notif’ (transport-independent information)
? 3 => uint    ; ’next_not_before’
}

tp_info = [
srv_addr   ; Addressing information of the server
? req_info ; Request data extension
]

srv_addr = (
  tp_id : int,  ; Identifier of the used transport protocol
+ elements      ; Number, format and encoding
                ; based on the value of ’tp_id’
)

req_info = (
+ elements  ; Number, format and encoding based on
            ; the value of ’tp_id’ in ’srv_addr’
)

A full example with for CoAP over UDP is

tp_info = [
    tp_id    : 1,             ; UDP as transport protocol
    srv_host : #6.260(bstr),  ; Src. address of multicast notifications
    srv_port : uint,          ; Src. port of multicast notifications
    token    : bstr,          ; Token of the phantom request and
                              ; associated multicast notifications
    cli_host : #6.260(bstr),  ; Dst. address of multicast notifications
  ? cli_port : uint           ; Dst. port of multicast notifications
]

This leverages the new "CoAP Transport Information" registry, which is initially populated as follows.

+-----------+-------------+-------+----------+-----------+------------+
| Transport | Description | Value | Srv Addr | Req Info  | Reference  |
| Protocol  |             |       |          |           |            |
+-----------+-------------+-------+----------+-----------+------------+
| Reserved  | This value  | 0     |          |           | [RFC-XXXX] |
|           | is reserved |       |          |           |            |
|           |             |       |          |           |            |
| UDP       | UDP is used | 1     | tp_id    |  token    | [RFC-XXXX] |
|           | as per      |       | srv_host |  cli_host |            |
|           | RFC7252     |       | srv_port | ?cli_port |            |
+-----------+-------------+-------+----------+-----------+------------+

**=== NEW WAY ===**

Transport a CRI that contains address components which identify a CoAP scheme, a host and a port, but no later components (i.e., with an empty local-part).

informative_response_payload = {
  0 => array,  ; ’tp_info’, i.e., transport-specific information
? 1 => bstr,   ; ’ph_req’ (transport-independent information)
? 2 => bstr    ; ’last_notif’ (transport-independent information)
? 3 => uint    ; ’next_not_before’
}

tp_info = [
    tpi_server    ; Addressing information of the server
  ? tpi_details   ; Additional information about the request
]

tpi_server = CRI  ; from draft-ietf-core-href, with no local part

tpi_details = (
+ elements  ; Number, format and encoding based on
            ; the URI scheme of 'tpi_server'
)

The 'tpi_server' element of 'tp_info' specifies the addressing information of the server in URI form. That URI contains (at least for the currently defined schemes) no path, query or fragment; it indicates a transport as described in [Section 1.1.1 of draft-ietf-core-transport-indication](https://datatracker.ietf.org/doc/html/draft-ietf-core-transport-indication-01#section-1.1.1)

The overall result for CoAP over UDP is as follows.

tp_info = [
    tpi_server        ; Addressing information of the server, as a CRI with scheme "coap"
    tpi_details_udp   ; Additional information about the request, when the CoAP over UDP is used
]

tpi_details_udp = (
    tpi_token,
    tpi_client
)

tpi_token = bytes
tpi_client = CRI / nil

The registry "CoAP Transport Information" would also change as follows.

OLD fields:
- Transport protocol
- Description
- Value
- SrvAddr
- ReqInfo
- Reference

NEW fields:
- Scheme
- The scheme as registered in the Uniform Resource Identifier (URI) Schemes registry, which also needs to have a corresponding number for CRIs
- MT: So, we cannot take for granted that such registration has happened already when the actual URI scheme was registered (see further details below). Also, a corresponding, registered negative integer is needed to have happened already.
- tpi_details
- The elements composing tpi_details when considering this scheme
- References
- Where it must be said how the elements in tpi_details are used by clients to configure an observation

From [PR #13](https://github.com/core-wg/observe-multicast-notifications/pull/13):

> Future specifications that consider CoAP multicast notifications transported over different transport protocols should:
> ...
> * Register a numeric scheme with CRIs.
> * Define elements of `tpi_details`, and register them in the "CoAP Transport Information" registry defined in ... this document.

So, we cannot take for granted that the registration of the numeric URI scheme to be included here has already happened when the actual URI scheme was registered. But it might have happened already thanks to other documents needing to do the registration first. Correct?

Also, if the registration of the numeric scheme did happen, where would that be requested? In the HREF document, there is no registry defined for the integer value used of future schemes (i.e., for other-scheme).

### Use in -groupcomm-proxy

A subset of the same semantics above from the error informative response is used in [groupcomm-proxy](https://datatracker.ietf.org/doc/draft-tiloca-core-groupcomm-proxy/), as limited to the information about the server.

This is used as value of the Response-Forwarding option, that the proxy includes in the responses relayed to the client, in order to provide server addressing information. This allows a client to: i) distinguish responses from different origin servers; ii) if possible, contact an individual origin server bypassing the proxy.

For [groupcomm-proxy](https://datatracker.ietf.org/doc/draft-tiloca-core-groupcomm-proxy/), the only subset of information needed is about scheme, host and port associated with the origin server. Basically, the byte serialization 'tpi_server' introduced in -observe-multicast-notifications would be the value of the Response-Forwarding option.

Consistently with the above, we have to update the registrations that [groupcomm-proxy](https://datatracker.ietf.org/doc/draft-tiloca-core-groupcomm-proxy/) does to the "CoAP Transport Information" registry, in the interest of supporting cases based on a reverse-proxy.

In the current registry format, the currently specified registrations look like this.

+----------+-------------+----------+--------------+---------------+
| 'tp_id'  | Element Set | Element  | CBOR Type    | Description   |
| Values   |             |          |              |               |
+----------+-------------+----------+--------------+---------------+
| 2, 3, 4, | Srv Addr    | srv_host | #6.260(bstr) | Address of    |
| 5, 6     |             |          |     (*)      | the server    |
|          |             +----------+--------------+---------------+
|          |             | srv_port | uint / null  | Port number   |
|          |             |          |              | of the server |
|          +-------------+----------+--------------+---------------+
|          | Req Info    | cli_host | #6.260(bstr) | Address of    |
|          |             |          |     (*)      | the client    |
|          |             +----------+--------------+---------------+
|          |             | cli_port | uint         | Port number   |
|          |             |          |              | of the client |
+----------+-------------+----------+--------------+---------------+

That is, it is about 5 new entries, covering the schemes "coaps", "coap+tcp", "coaps+tcp", "coap+ws", "coaps+ws".

Thinking of the new intended format for the registry:

- Scheme
- The scheme as registered in the Uniform Resource Identifier (URI) Schemes registry, which also needs to have a corresponding number for CRIs
- tpi_details
- The elements composing tpi_details when considering this scheme
- References
- Where it must be said how the elements in tpi_details are used by clients to configure an observation

in the column "tpi_details", those 5 new entries would have the same content of the only entry registered in observe-multicast-notifications when considering CoAP over UDP, i.e.:

tpi_token = bytes
tpi_client = CRI / nil

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

### 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 ...
- 2022-10-14, 13:30 UTC / 15:30 CEST
- https://meet.jit.si/TheCoRALNeedsToGrow