**Session Date/Time:** 23 Nov 2022 15:00

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

## Summary

This interim meeting of the CORE Working Group focused on three key areas: the recently adopted "Target Attributes" document, outstanding issues and a new Pull Request for the "href" document, and the resolution of several errata reports. Discussions on Target Attributes revolved around IANA registrations and alignment with the `edoc` document. For `href`, a new approach to differentiate "root-based" and "rootless" URIs was proposed, alongside efforts to define integer assignments for URI schemes. The bulk of the meeting addressed errata reports, with decisions made to handle significant updates, particularly those with IANA implications, through a dedicated "CORE Corrections and Clarifications" document.

## Key Discussion Points

### Target Attributes

*   The document has been adopted and the immediate focus is on ensuring initial IANA registrations.
*   **Registration Strategy**: The plan is to prioritize registrations for Target Attributes already defined in RFCs, aiming to progress faster than the `edoc` document.
*   **`edoc` Document Alignment**: A revision of the `core-oscar-edoc` document is planned, which will replace underscores with dashes in Target Attribute names and potentially add an `edoc` prefix for clarity. This may lead to further bike-shedding on name compression and prefixing.
*   **Charter Compliance**: The work on Target Attributes is considered maintenance for RFC 6690 and subsequent documents (e.g., RFC 8288), confirming it is within the WG's charter.
*   **Generic vs. Specific Connotation**: Discussion on classifying registered attributes as generic or specific. Concern was raised about "point squatting" or using the same name for different meanings. The document's role is primarily to enable correct registration and maintenance, rather than encoding extensive policy.
*   **Completion Target**: The group aims to complete the document, potentially reaching Working Group Last Call (WGLC), by the end of this year or early next year.

### href

*   **Pull Request for Path Semantics**: A new Pull Request addresses the ambiguity between "no slash" and "leading slash" cases in URIs.
    *   **Naming Proposal**: The terms "no slash" and "leading slash" are proposed to be replaced with "root-based" and "rootless," respectively, to better reflect their semantics, acknowledging potential overlap with "rooted" and "unrooted" for relative paths.
    *   **Rule for Rootless Paths**: A rootless path (e.g., `a:`) is required to have at least one path component (e.g., `a:b`). This avoids ambiguity with a root-based URI without a path component (e.g., `a:/`), which would both render as `a:` without the distinction. This implies ruling out the rootless URI without a path component.
    *   The PR currently captures the technical discussion and the chosen variant of handling the URI distinction.
*   **Test Vectors**: Another Pull Request is planned to address the test vectors, aiming for a functionally complete draft soon.
*   **URI Scheme Integer Assignments (Negative Integers)**:
    *   **Wiki for Collection**: A wiki is being used to collect URI schemes for which negative integer assignments are desired.
    *   **Initial List**: The current wiki list should be expanded to include existing well-known schemes (HTTP, HTTPS, CoAP, CoAPS) already covered in the CDDL definition of CRIs.
    *   **Provisional Registrations**: Discussion on whether to assign integers to provisionally registered schemes (e.g., MQTT). The current policy, which ignores provisional registrations, may need adaptation to optimize for number assignment, even if the scheme is not yet permanently registered.
    *   The group agreed that if a scheme like MQTT is in use, it should be possible to assign it a number without undue pain.

### Errata Resolution

*   **General Approach**: The group reviewed 10 errata reports for various RFCs, primarily RFC 7252.
    *   Consensus was reached on approving 7 of Francesca's proposals without further comment.
    *   For errata with IANA implications or requiring extensive discussion, the preference is to address them through a "CORE Corrections and Clarifications" document (referred to as "core-clarifications" or "core-clark") rather than direct Errata approval.
*   **Specific Errata Discussed (for RFC 7252)**:
    *   **Errata ID 4895**: Related to IANA registry column headings (editorial). Proposed to "Hold for Document Update" via a `core-clarifications` document. This would allow for a consistent fix across RFC 7252 and other documents that might have adopted the incorrect naming.
    *   **Errata ID 948**: Concerning notation with dots. Proposed for approval, but concern was raised about the RFC Editor's handling of "interspersed" text additions/changes.
    *   **Errata ID 954**: Involves IANA implications, similar to Errata ID 4895. Proposed to "Hold for Document Update" via `core-clarifications`.
    *   **Errata ID 5429**: Related to message IDs. Proposed for "Rejection" as an Errata, but the underlying issue and its rationale should be described in the `core-clarifications` document.

## Decisions and Action Items

*   **Target Attributes**:
    *   **DECISION**: Focus IANA registrations on RFC-defined Target Attributes first.
    *   **ACTION**: Karsten to add an initial minimal set of URI schemes (CoAP, CoAPS, MQTT) to the `href` wiki for integer assignments.
*   **href**:
    *   **DECISION**: Proceed with the Pull Request proposing "root-based" and "rootless" naming for URI path semantics, and the rule requiring rootless paths to have at least one path component.
    *   **ACTION**: Karsten to create additional Pull Request(s) for test vectors.
    *   **ACTION**: Karsten to add existing HTTP/HTTPS/CoAP/CoAPS scheme information to the `href` wiki to ensure completeness.
*   **Errata Resolution**:
    *   **DECISION**: For errata reports with IANA implications or requiring extensive discussion (e.g., IDs 4895, 954, 5429 for RFC 7252), these will be addressed by a future "CORE Corrections and Clarifications" document, rather than being approved as simple errata.
    *   **ACTION**: Marco to check with the RFC Editor regarding the handling of "interspersed" text additions/changes for Errata ID 948.
    *   **ACTION**: Karsten to reply to the Errata ID 5429 thread with a pointer to the relevant discussion/rationale (initially the `erwig-coap` document, then the `core-clarifications` document once updated).
    *   **ACTION**: Utilize the `core-clarifications` wiki in the CORE repository to track points related to errata that will be fixed in the `core-clarifications` document.

## Next Steps

*   **Next Interim Meeting (in two weeks)**:
    *   Confirm the proposed errata resolution plan.
    *   Discuss the `core-sid` document.
    *   Address any other emergent topics.
*   **Working Group Goals**: Aim for functional completion and potentially WGLC for the `href` document by the end of the year.