Minute takers: Marco Tiloca
Jabber scribes: Marco Tiloca
Remember that the note well applies, for IPR but also for WG
processes and code of conduct. Please be nice to each other.
MT: Adopted today as WG document.
CB: It is in a pretty good shape already. It's about being sure that we
collect target attributes already around, and that we have a good
RH: Can you automate the extraction of target attributes?
CB: It might require natural language processing.
CB: I haven't formally checked for its consistency with the CoRE
charter, but it's pretty clear that it acts as maintenance of RFC 6690,
based on a direction now coming from RFC 8288.
(no objections heard)
CB: Timeline for this draft?
MT: Complete on Q1 2023?
CB: If possible, we can even try for WGLC this year, at least starting
MJK: I agree with Carsten, this can go quickly. This document can encode
a lot of policies. It has to be correct as to registration and good
maintainance of the registry.
MT: For information, we'll soon submit a revision of -core-oscore-edhoc,
where some target attributes will be renamed to correctly use "-"
instead of the underscore character. Then -core-target-attr can be
MT: Also related to attributes from -core-oscore-edhoc, I'd expect some
bikeshadding around their names, to have an EDHOC-related prefix and to
see if it's possible to shorten them. That would probably happen during
WGLC of -core-oscore-edhoc and spans over both documents.
MT: Ari also had a comment during the adoption call, on having the
definition of target attributes more specific, especially those from
-core-oscore-discovery. However, especially those have a general meaning
that holds in contexts different than OSCORE groups.
CB: We have to find a balance on the level of specificity.
MT: Yes, I am ust trying to avoid a sort of "point squatting", where two
attributes are registered, and they mean the same thing but just in
CB: At the same time, we can't really prevent people from misusing
CB: There is a new PR for one of the open issues now. See
https://github.com/core-wg/href/pull/58 . This addresses the issue on
rootless no-authority CRIs without path.
MT: It looks good at a first glance. You can ask Thomas and Christian
for a review.
CB: Will do.
MT: It was discussed how to address the remaining issues. Do you plan a
PR for those?
MT: An exception is the issue about test vectors. Do you plan more
interop/comparison at least with Thomas?
MT: We also have the wiki (see link above) where to collect the negative
integers to pre-register as abbreviations of URI schemes.
MT: The idea was to first extend the minimal set of usual suspects in
the CDDL definition of a CRI (including also coap+, coaps+, ...), and
then take this minimal set as starting point for the registration in
CB: We may want to include also MQTT.
MT: Then it's about what we want to further pick up from other existing
CB: Another problem is that some URI registrations are not permanent
MT: That's one more thing to factor in the definition of a good
registration policy. It's not going to be easy.
CB: We need to find a balance in terms of flexibility, while still
giving clear criteria to the Designated Expert.
MT: Timeline for this draft?
CB: We might be able to start a WGLC this year.
MT: I went through them. On 7 of them, I just agree with the proposal
from Francesca. I have comments on the other 3 ones.
MT: On https://www.rfc-editor.org/errata/eid4895 , can't this also be
verified instead of hold for doc update?
FP: I think it requires more work, has implications for IANA, and feels
cleaner in a separate document updating RFC 7252.
CB: Yes, and that document can be -corrclar, see
MT: On https://www.rfc-editor.org/errata/eid4948 , I double-checked and
think that the content is correct. Like Francesca said, it's probably
not possible to use the notation [...] and we may have to re-include a
lot of unchanged text too.
FP: That's maybe something to check with the RFC Editor.
CB: I can do that.
MT: On https://www.rfc-editor.org/errata/eid4954 , I was leaning towards
verifying this one, but like for the first discussed errata, it's better
to have it hold for an update, due to the IANA implications.
CB: And again the updating document can be -corrclar.
MT: Also, probably other documents made the some mistake that this
errata is trying to fix in RFC 7252.
CB: -corrclar can update those documents too; let's just hope they're
not too many.
MT: At least they're clearly identifiable from the "CoAP
CB: On https://www.rfc-editor.org/errata/eid5429 , I agree that it
should be rejected. When updating RFC 7252, -corrclar can clarify on
this point too, providing the rationale behind the contested design,
also supported by the LWIG document
FP: Please provide a pointer in a reply to the thread in the mailing
CB: Will do.
MT: A good place for collecting these points is the "CoAP FAQ" in the
CoRE WG Wiki, see https://github.com/core-wg/wiki/wiki/CoAP-FAQ . Most
of the current entries are potential material for -corrclar.
CB: Based on a quick look on the list of erratas, I agree with the
MT: Let's confirm at the next interim meeting in two weeks.
MT: Next interim meetings in 2 weeks is planned to be about -core-sid
and on confirming the resolution of the erratas.