Minutes interim-2021-core-05: Wed 16:00
minutes-interim-2021-core-05-202105121600-00

# CoRE Virtual interim - 2021-05-12 - 14:00 UTC

Chairs:

* Marco Tiloca, RISE
* Jaime Jiménez, Ericsson

## Remote instructions

material: https://datatracker.ietf.org/meeting/interim-2021-core-05/session/core
webex: https://ietf.webex.com/ietf/j.php?MTID=mb2d62b1da561183acc59e83e93a5dae6
jabber: core@jabber.ietf.org
codimd: https://codimd.ietf.org/notes-ietf-interim-2021-core-05-core?both

Minute takers: Christian, Marco
Jabber scribes:

## Participants

1. Marco Tiloca, RISE
2. Christian Amsüss
3. Michael Richardson, Sandelman Software Works
4. Rikard Höglund, RISE
5. Carsten Bormann, TZI
6. Scott Rose, NIST
7. Thomas Fossati, arm
8. Göran Selander, Ericsson
9. John Mattsson, Ericsson
10. Klaus Hartke, Ericsson
11. Mike Jones, Microsoft

*[MT]: Marco Tiloca
*[JJ]: Jaime Jiménez
*[FP]: Francesca Palombini
*[CB]: Carsten Bormann
*[CA]: Christian Amsüss
*[KH]: Klaus Hartke
*[RH]: Rikard Höglund
*[TF]: Thomas Fossati
*[DN]: David Navarro
*[GS]: Göran Selander
*[BS]: Bilhanan Silverajan
*[AS]: Alan Soloway
*[MCR]: Michael Richardson
*[MJ]: Mike Jones

## Agenda

### Note Well

Remember that the [note well](https://datatracker.ietf.org/submit/note-well/)
applies, for [IPR](https://tools.ietf.org/html/bcp79) but also for [WG
processes](https://tools.ietf.org/html/bcp25) and [code of
conduct](https://tools.ietf.org/html/bcp54). Try to be nice.

### Bluesheets / Jabber & Minutes / Agenda bashing

Fill the "Participants" list and other info above.

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

[no slides as nothing high-level changed; looking at draft for CDDL]

CB: CDDL for a CRI reference (allows both absolute CRIs and to be combined with
a base in relative resolution) (section 5.1 "CBOR Serialization" of document)

CB: Changes compared to RFC3986: Splitting query by "&" (same as CoAP), allow
numeric label for scheme, allow binary addresses -- but all details. New:
"discard" := "this is a relative reference, and this many path components need
to be thrown away". A consolidated ../../../. A relative reference not starting
with ../ discards 1 (./), and discard 0 does not change the path at all.

CB: Same high-level structure -- but before the components were numbered, and
now there is a syntax to step through to find what goes into which section.
[looking at Table 1, "Values of the Variables T and E"]

MCR: Do you want to have a co-author from W3C, or Mark Nottingham?
CB: Depends on whether we want to replace URIs (which we don't). In the end,
some 3986 expert should look at this, but they will be irritated by not having
percent encoding at all. MCR: I'd rather have this happened early. CB: When
things are in good shape, we should tell them. MCR: Do early; they need to feel
we can still change things. KH: Still some bugs in text. When they are fixed,
approach URI community. Latest and greatest is in PR... MCR: who would use CRIs
apart from CoRAL? KH: anyone using URIs with CBOR.  For example, Carsten's IAF.
MCR asks how a URL and a CRI could be distinguished. CA clarifies that the []
is not an array, but a placeholder for a CBORSEQ.

MT: clear what is missing and how to move forward.

KH: good if more people implement this.
TF: I can give it a shot.

### CoRE option for well known resources

https://github.com/lake-wg/edhoc/issues/87

Presented slides:
-
https://www.ietf.org/staging/slides-interim-2021-core-05-sessa-core-option-for-well-known-resources-ss1217.pdf

CA: Would be useful to have an option to shorten a URI.
CB: The query would still be seen by the parser.

MCR: Is this for CoRE or for future well-known?
CA: This could rather be all an IANA table; alternatives have to be discussed

CA: More feasible for deployments where all know about this and use it.

CA: Is this urgent (also thinking of EDHOC) and valuable as a generalization?

GS: Need to digest this, the overall approach seems right

MT: on the parallel with the EDHOC option, maybe that's true only as a
particular case. The EDHOC part of the combined EDHOC+OSCORE request with the
EDHOC option is intended to be consumed by the same EDHOC resource where EDHOC
message_1 of that EDHOC session was sent. But the server may have multiple
EDHOC resources, e.g. to support multiple applicability statements. CA: Yes,
you need to be careful if there are multiple EDHOC resources on the server.

GS: Multiple alternatives to compare?

CB: Why option number 501?
CA: 2-byte space, value not hit by combination of previous options + EDHOC
option. Trying to avoid those for now. CA: Could do in 1+1 just as well, was
trying to emphasize that savings can easily be achieved even w/o standards
action. GS: If we do this, lower option numbers are fine, right? CA: Yes.

KH: I have a URI. How do I know whether to use DTLS or EDHOC?
GS: Based on the applicability statement, guiding on understanding it's an
EDHOC message. KH: Is there a coape://? Can coaps:// also mean EDHOC? CB:
Doesn't make sense. In order to be able to use DTLS, you need lots of context
already. That ton of context could just as well tell you that this coaps URI
goes via EDHOC. MCR: Don't agree it needs that much context. KH: If you have
the context that tells you to use edhoc, you could also from that context know
that EDHOC is to be used. And while we're at it, that could also provision us
with the context to pick the right CoRAL dictionary. GS: /.well-known/ EDHOC is
just an example, which can make things homogeneous. KH: A solution to the
18-byte problem would be for the application to define something else. KH: So
.well-known/coral next? Have been discussing these context for some time --
security contexts, vocabularies. CB: When you are "tossed a URI" is not how it
works. There must be a reason to dereference that URI, and that reason is the
first element of that context. Whatever supplies that reason can define other
things. KH: Can we standardize something there, or is that too application
dependent to try? CB: Can try to give it vocabulary. That may be as far as we
get, but may still be useful. TF: Are we reinventing DIDs? For discovery of
security contexts and other stuff that is API(?) dependent. CB: The impression
DIDs left in my brain are "just another layer of indirection".

### Problem details for CoAP APIs

https://datatracker.ietf.org/doc/draft-ietf-core-problem-details/

GH issues:
- https://github.com/core-wg/core-problem-details/issues

Presented slides:
-
https://datatracker.ietf.org/meeting/interim-2021-core-05/materials/slides-interim-2021-core-05-sessa-problem-details-00.pdf

TF: Recap on document timeline. Worked resumed recently along with CoRAL.

TF: Some open issues/points are feasible to close in the short term. We may
have one or two resubmissions before the IETF 111 cut-off.

KH: Some points are very tight related to CoRAL, but problem-detail may be
brought to conclusion anyway, and then go on hold until also CoRAL is
completed, before we can finalize it.

CB: Anything we can learn from the JSON document?
TF: Maybe, from
[HTTPAPI](https://datatracker.ietf.org/doc/draft-ietf-httpapi-rfc7807bis/),
we'll check

CB: For the x- problem, it's also about efficiency in encoding. It's important
to get the processors in place, IANA, etc. Good to think how to make 1st/2nd
class citizens.

KH: From discussions ... want low barrier of entry. For first prototype and
dummy values, shouldn't have to interact with IANA or anyone like that. Want to
mix and match problem details from different domains. SIDs are good for the
world they're applied to (consecutive increasing IDs, mechanism for
properties), but CoRAL and PD in the end might be less formally organized than
CoMI world, where developers build APIs and put in error code and just put
value somewhere without registering an account. KH: Right now we have as a
proposal namespace tables, which allow using items from multiple vocabs even if
some of these are private and some are public. Doesn't even have to be defined
for that purpose (eg. can pull in IANA registries). There are unresolved
issues, in particular: which to use? ... and then we get back to "If we have
more context to a URI, can we stick security details and tables in there was
well"?

### AOB

CA: "tossed URIs" for mailing lists

CB: On Tuesday had discussion on https://JSONpath.com and regexps. Wrote
another with yet another regexp scheme, but it's not yet another new one
because it's a subset of everything else. Look at iRegExp draft if you care
about regular expressions.
https://datatracker.ietf.org/doc/draft-bormann-jsonpath-iregexp/

MT: announcing agenda for next interim - CoRAL document and relation between
CoRAL and SDF.

MCR: CoRE YANG/SID stuff has been waiting for revised ID for months ... chairs?
CB: Still trying to get meeting between people knowing about the drafts.
KH: Any implementors outside the group of authors?
MCR: Me; depending on this for ANIMA constrained voucher. Authors are
unresponsive, regularly, for years. CB: One option to short-circuit them, go
ahead and fix things. If WG wants me to do that, I will. MCR: Let me help. So
just send PRs on the documents? CB: Also merge them, publish new draft. MT:
Check with Francesca. CB: Chairs will need to decide who editors of these are.
Interested in knowing why things are that weird there, and for that it'd help
to get by the authors.

KH: On next interim, not sure what I should prepare on the CoRAL-SDF relation.
CB: On CoRAL/SDF, the interesting thing are the thing descriptions where they
now emulate SDF with TD templates. Maybe in CoRAL space we would want to look
at that too. No idea how this will [break up].

CB: Relatable work on CBOR-LD
- Proposal: https://digitalbazaar.github.io/cbor-ld-spec/
- Running JS code: https://github.com/digitalbazaar/cborld