**Session Date/Time:** 08 Jun 2022 14:00

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

## Summary

This interim meeting of the CORE WG focused on two key documents: "Problem Details for HTTP APIs (CBOR)" (currently in Last Call) and "CBOR URI Reference (Href)", with a particular focus on CURIEs. Discussions for "Problem Details" revolved around clarifying the `title` field, handling human-readable text without language tags, and processing unknown entries. For "Href", the conversation highlighted the complexities of CURIEs in a CBOR context and the need for a structural alternative.

## Key Discussion Points

### Problem Details for HTTP APIs (CBOR)

*   **`title` Field Semantics**:
    *   The document's definition of `title` as "not varying across instances" was discussed. In RFC 7807, this tied to the problem type, which is now deprecated.
    *   A suggestion was made to remove the second sentence regarding invariance or clarify its intent: `title` should describe the *kind* of problem, not a specific instance (e.g., "not enough money" vs. "you have 54 euros").
    *   A sense of those present indicated that the title should be a "short, human-readable summary of the problem shape" without duplicating instance-specific details. An example contrasting generic vs. specific problem descriptions was requested for inclusion.
*   **Language Tags for Human-Readable Text (`title`, `detail`)**:
    *   Francesca asked why unadorned text (without a language tag) is allowed, given its human-readable nature.
    *   Three options were considered:
        1.  Make English the default.
        2.  Make the default depend on context, observing that CoAP currently lacks a standard for language negotiation.
        3.  Require a language tag (no unadorned text).
    *   The discussion leaned towards option 2, with a fallback to a specified default (e.g., RFC 3864 "en-US") in the absence of context. This would need consultation with the Internationalization Directorate.
    *   The overhead of adding a language tag (approx. 6 bytes for "en-US") was deemed acceptable in the grand scheme.
*   **Examples in Section 3.1**:
    *   Francesca suggested more examples of standard problem detail entries.
    *   Concerns were raised that additional examples might lead implementers to copy values directly without registering them, causing issues. A decision was made to keep the current single example.
*   **Handling Unknown Entries**:
    *   Joel's Ops Directorate review noted that the document only addressed unknown entries for consumers, not for forwarders or storers.
    *   The proposed solution was to add a "should recommended" to retain unknown entries when storing or forwarding, with exceptions for cases where it's "unbearably difficult" (e.g., format conversion) or if the forwarder's role is to filter/redact information.
*   **Publication Status**:
    *   The document is in Last Call, with AD reviews underway. Publication in June is still possible but requires efficient processing of reviews and AD ballots.
    *   The Internationalization Directorate review is anticipated.

### CBOR URI Reference (Href) and CURIEs

*   **CURIEs in CBOR Pact**:
    *   The new CBOR Pact environment allows powerful function tags, which could enable structural CURIE definitions.
    *   A proposed function tag could combine a base URI with a relative URI (e.g., `/foo/` + `/bar/` -> `/foo/bar/`).
    *   **Challenges**: The semantics of CURIEs are deeply tied to URI syntax, leading to "weird cases" where simple concatenation doesn't work as expected (e.g., `http:` + `//example.com`, or combining parts into a fragment identifier or hostname).
    *   This often necessitates converting CRIS back to URI strings, concatenating, and then converting back to CRIS, which undermines the purpose of using CRIS.
    *   A desire was expressed to operate semantically on CI/CI references directly.
*   **Subset of CURIEs**:
    *   The idea of defining a "sane" subset of CURIEs was discussed, possibly by developing a corpus of existing CURIE uses.
    *   The fundamental problem of CURIEs being "lexical" (like C preprocessor macros) was highlighted, leading to management difficulties.
    *   A "structural better CURIE" concept was proposed, fitting the CI paradigm and ideally backportable to URI space as a subset of lexical CURIEs.
*   **Scope for Href**:
    *   Given the complexity, a sense of those present indicated that the full problem of CURIE definition and structural alternatives should be spun off as a separate project and not addressed in the base CI/Href spec.
    *   The powerful nature of CBOR Pact function tags means the current Href document is unlikely to create future roadblocks.
    *   The work might become relevant for future CoRAL (CoAP Resource Abstract Layer) compression, particularly for expanding prefixes in dictionaries.

### AOB (Any Other Business)

*   The next CORE WG meeting will be a 2-hour session at IETF 113.
*   RFC 9193 ("Terminology for Well-Known URIs") has been published, resolving a long-standing dependency and defining terms and ABNF for media types and content formats, which should streamline future document writing.
*   The `cbor.me` tool was temporarily down, highlighting its importance to the community.

## Decisions and Action Items

### Problem Details for HTTP APIs (CBOR)

*   **Decision**: Refine the description of the `title` field to be a "short human-readable summary of the problem shape without duplicating instant-specific details contained in the other problem detail entries." Include a clarifying example.
*   **Decision**: For `title` and `detail` fields, allow language-tagged text; in the absence of context (for unadorned text), assume RFC 3864 "en-US" as a default. This decision will be cross-checked with the Internationalization Directorate.
*   **Decision**: No additional examples will be added to Section 3.1 to avoid misinterpretation of example numbers.
*   **Decision**: Add "should recommended" text to retain unknown entries when storing or forwarding problem details, except when "unbearably difficult" or for filtering/security purposes.
*   **Action Item**: Continue processing AD reviews and prepare for Telechat approval, targeting June publication.

### CBOR URI Reference (Href) and CURIEs

*   **Decision**: The development of a "structural better CURIE" and the comprehensive definition of CURIE semantics for CBOR are to be spun off as a separate future project. This work will not block the current Href document.
*   **Action Item**: The working group will explore "structural CURIEs" as a separate effort, potentially in the context of CoRAL or other applications needing URI compression/expansion.

### Other

*   **Action Item**: Carsten Bormann will provide a tutorial or wiki entry on generating RFC index entries, particularly for Markdown/Cramdown sources.

## Next Steps

*   Complete the Last Call process for "Problem Details for HTTP APIs (CBOR)".
*   Continue work on "CBOR URI Reference (Href)".
*   Prepare for the CORE WG meeting at IETF 113.
*   Initiate discussions or a new effort on "structural CURIEs" as a separate work item.