**Session Date/Time:** 18 Jun 2025 14:00

# [CORE](../wg/core.html)

## Summary

The CORE Working Group held an interim meeting to discuss progress on two key documents: "Concise Resource Identifiers (CIS) for CoAP (`href`)" and "CoAP Corrections and Clarifications (`core-clar`)". Discussions focused on addressing feedback from an AD review for `href`, and resolving open Pull Requests and issues for `core-clar`. Key decisions included clarifying the handling of zone identifiers and 2S-Key algorithms in `href`, refining the description of query parameters and blockwise (BIRD) operation in `core-clar`, and updating error handling for confirmable and non-confirmable messages. An informative reference for "CoRE" in DNS-over-CoAP was also agreed upon.

## Key Discussion Points

*   **Concise Resource Identifiers (`href`)**
    *   **Zone Identifiers:** The current status of zone identifiers in URIs is complex and evolving (RFC 6874 is still in force but intended for obsolescence). For CIS, the representation of zone IDs for IPv6 addresses is clear. The working group agreed that progress on `href` should not be delayed waiting for the URI situation to fully settle, especially given existing applications using zone identifiers.
    *   **2S-Key Algorithm:** It was noted that `href` normatively references RFC 3490 for the 2S-Key algorithm, despite RFC 3490 being obsoleted by RFC 5890. However, RFC 5890 itself refers back to RFC 3490 for the definition of 2S-Key. This situation, while unusual, was acknowledged to likely require attention from the IESG rather than a change within `href`. Removing 2S-Key considerations from `href` was deemed undesirable.
*   **CoAP Corrections and Clarifications (`core-clar`)**
    *   **Query Parameters:** Discussion revisited the duality in how query parameters are treated: as inherent parts of a URI (RFC 3986) versus as mechanisms for server-side resource handler selection. The consensus was to describe this duality in the document, acknowledging both perspectives.
    *   **Blockwise-Improved Reliability and Datagrams (BIRD) Gaps:** The concept of a "gap" was introduced for protocol components that are fully specified but lack the necessary context for wider use. BIRD was highlighted as an example, primarily specified for reliable transports like TCP/WebSockets but having undefined usage contexts for other transports. It was noted that RFC 8323's language implying restriction of BIRD to TCP/WebSockets was too "draconian" and simply meant the context hadn't been defined. A new "dangerous reading" was identified: that `size exponent 7` might be used for other purposes by other transports, which needs to be addressed. The need to clarify how BIRD could be used with OSCORE (e.g., through pre-configuration or negotiation via ED items) was discussed.
    *   **Proxy-Scheme Default:** The working group discussed the need for text explaining how a default proxy scheme simplifies the work of forward proxies. It was proposed to incubate this text in `core-clar` and then transition it to the `href` document, where the `Proxy-Scheme Number` is being defined.
    *   **Confirmable vs. Non-Confirmable Error Handling (Issues 48 & 14):** The discussion centered on aligning error responses (like 405 Method Not Allowed or 402 Bad Option) for both confirmable (CON) and non-confirmable (NON) messages. Specifically, RFC 7252's constraint that a 405 response must be "piggybacked" for CON messages was identified as problematic. It was argued that this constraint is not enforceable in a CoAP ecosystem with proxies (which can ACK independently) and would "break so much of CoAP." The intention was interpreted as allowing 405/402 for both CON (piggybacked if possible, otherwise separate) and NON messages (as regular responses).
*   **DNS-over-CoAP (DSO) CoRE Definition:** A request was made for a clearer definition of "CoRE" as used in DNS-over-CoAP. The suggestion to refer to RFC 6690 (which defines CoRE) and RFC 7228 (which defines "constrained") was accepted, noting that both documents provide relevant context.

## Decisions and Action Items

*   **For `href`:**
    *   The push-back on delaying `href` for the URI zone identifier situation to settle is justified.
    *   No changes are immediately required regarding the RFC 3490 (2S-Key) normative reference; this issue will likely be addressed by the IESG.
    *   **Action:** Kirsten to address outstanding AD review comments from Mike, update the `href` Internet-Draft, and ensure all relevant mailing lists (including CORE) are CC'd in future email replies.
*   **For `core-clar`:**
    *   The description of the duality of query parameter interpretation is accepted as the intended solution for the relevant Pull Request.
    *   **Action:** Kirsten to add text to PR 45 (BIRD Gaps) clarifying how BIRD could be used with OSCORE, possibly via ED items or pre-knowledge, without a full protocol specification. The problematic language in RFC 8323 regarding BIRD usage will be clarified, and the "gap" category will be added.
    *   The text concerning the default proxy scheme will be incubated in `core-clar` and then pushed into the `href` document as an update.
    *   The "piggybacked" constraint for 405/402 responses to confirmable messages in RFC 7252 will be removed/re-stated as non-enforceable to allow consistent error handling across CON and NON messages, providing more informative responses than a simple reset.
*   **For DNS-over-CoAP:**
    *   **Action:** The next version of the DNS-over-CoAP draft should informatively reference RFC 6690 for the definition of CoRE and RFC 7228 for the definition of "constrained."

## Next Steps

*   Kirsten will work on updating the `href` Internet-Draft within the next five days, aiming for a new version by early next week.
*   Reviews are requested for the updated `core-clar` Pull Requests, particularly for the Query Parameters and BIRD Gaps sections.
*   The next CORE interim meeting is scheduled for July 2nd.
*   Another interim meeting is planned for August 27th, after IETF 120 Madrid, allowing for four meetings before IETF 121 Morio.