**Session Date/Time:** 20 Aug 2025 07:00

# [ASDF](../wg/asdf.html)

## Summary

This interim meeting focused on aligning the `instance-information` and `sdf-non-affordance` drafts by introducing a common concept of "SDF context." The new `draft-rohit-asdf-protocol-mappings` was introduced, with a proposal to fast-track its adoption, pending a discussion on its name to avoid confusion with existing documents. Significant updates were made to the NIPY draft, including a new approach to problem types and refinements to extension mechanisms. The group also decided on a new process for reviewing NIPY issues and scheduled the next interim.

## Key Discussion Points

### Administrative
*   **Note-taking:** Ari volunteered to take notes.
*   **Agenda Review:** An item was added to discuss `instance-information` in the context of `sdf-non-affordance`. Updates from Junga and Yan were also requested.
*   **Note Well Reminder:** Standard IETF policies apply, the meeting is recorded, and participants should adhere to the code of conduct.
*   **Working Group Document Updates:**
    *   A new draft, `draft-rohit-asdf-protocol-mappings`, has been posted, co-authored by Rohit, S.B., and the Chair. This draft aims to standardize SDF protocol mappings, likely via a registry, to enable interaction with external ecosystems (e.g., Bluetooth, Zigbee, HTTP).
    *   The `digital-twin` and `sdf-non-affordance` drafts were formally adopted as working group documents.
    *   NIPY has posted several new versions addressing various issues.

### Instance Information & SDF Non-Affordance Alignment
*   Yan presented on the conceptual conflict between the `instance-information` and `sdf-non-affordance` drafts, which was previously discussed in Madrid.
*   A potential alignment using `SDF context` as a common concept was proposed.
*   The `instance-information` draft has already been updated to use `SDF context`, replacing previous `$context` and `offdevice` property concepts, and this update works well.
*   There's a need for "litmus tests" to guide when to use `SDF property` versus `SDF context`.
*   Junga confirmed plans to update the `sdf-non-affordance` draft to incorporate the `SDF context` keyword.
*   The authors of the relevant documents will collaborate to ensure alignment, particularly in examples, acknowledging that this might take time due to availability.

### SDF Protocol Mappings Draft (`draft-rohit-asdf-protocol-mappings`)
*   Rohit introduced the new draft, which was split from the NIPY document. It consolidates protocol mapping-related text and adds examples for protocols like CoAP (using CDDL) and HTTP. The NIPY draft now normatively references this new document.
*   Carsten emphasized the usefulness of the document and proposed an accelerated process for making it a working group document, given its origin from an existing work item. He anticipated minimal controversy.
*   Carsten also raised concerns about potential confusion due to naming, noting that the existing `sdf-mapping` document uses "map" differently. He suggested working on a paragraph to explain how the two documents combine rather than compete. He also suggested a broader review of terminology related to "map" or "mapping" across the working group.
*   The Chair agreed to fast-track the adoption process with Michael but noted the importance of agreeing on a clear, descriptive name before formal adoption to avoid year-long confusion.

### NIPY Updates
*   Bart proposed a new process for NIPY issue review: for clearly solved issues, he will email the list for a week-long review period, only bringing complex or contentious issues to interim meetings. This was agreed upon.
*   **Issues closed:**
    *   **149 (Query parameters percent encoded):** All reserved characters are now percent-encoded (in draft-12).
    *   **146 (Remove 'manage' keyword):** The "manage" keyword was removed, and "connection" is now part of the regular path (e.g., `connections`). (Note: a typo in the description was noted).
    *   **145 (Protocol mapping to separate draft):** Done, now `draft-rohit-asdf-protocol-mappings`.
    *   **143 (MQTT client object to boolean):** Changed from an empty object to a boolean, as discussed in Madrid.
    *   **141 (URI template for API paths):** Updated for `/connection` and query parameters.
    *   **150 (Inconsistencies in example):** Fixed JSON pointer URL inconsistencies (SDF thing vs. SDF object).
    *   **128 (Supporting write and read in a single value):** Updated to support different content types and introduced a new `nipy+json` media type for JSON-formatted bodies. Text regarding "raw binary data" was clarified to mean "the actual representation as such."
*   **Issues Open (requiring further action/discussion):**
    *   **139 (Problem Types):**
        *   NIPY now uses its own problem types and a new dedicated registry, moving away from HTTP problem types and removing the NIPY prefix.
        *   Carsten noted this establishes a precedent for allocating code points in a similar namespace to RFC 9457 (HTTP Problem Details). He recommended involving IANA and the working group that developed RFC 9457 (HTTPAPI) to ensure proper registry management.
        *   Draft-12 already incorporates these changes. Bart will initiate contact with the HTTPAPI list, referencing the current draft.
    *   **136 (Limitations on extensions):**
        *   The draft's text describing the *reasons* for extensions (e.g., "complex set of NIPY operations," "more efficiently") was discussed for being potentially too restrictive.
        *   Discussion on the `SHOULD` requirement for extensions to leverage the `/extensions` path element. Carsten argued that a `SHOULD` would "never pass" and suggested changing it to `MUST` to ensure collision-free naming.
        *   The group agreed to change `SHOULD` to `MUST`.
        *   Further discussion is needed on mechanisms for managing extension names (IANA registry, domain names for vendor-specific extensions) and how these would be reflected in URI templates.
    *   **50 (Action without binary data):**
        *   An inconsistency in Draft-12 was noted: `extensions/manage/transmit` should be `extensions/ID/transmit` or similar, as "manage" was removed from the general path structure.
        *   The specific issue about "request body can contain binary data" was not clearly reflected in the current text or PR, suggesting a possible incorrect PR link or unaddressed change. This issue remains open for re-evaluation.

## Decisions and Action Items

*   **Decision:** The `instance-information` and `sdf-non-affordance` drafts will align using the `SDF context` keyword.
*   **Decision:** NIPY issue review process will be streamlined: Bart will email the list with proposed closed issues for review, and only complex issues will be discussed in meetings.
*   **Decision:** NIPY Problem Types: The group will pursue creating a NIPY-specific problem types registry.
*   **Decision:** NIPY Extensions: The `SHOULD` for using the `/extensions/{extension-name}` path element will be changed to `MUST`.

*   **Action Item:** Junga and Yan to update the `sdf-non-affordance` draft to use `SDF context`.
*   **Action Item:** Authors of `instance-information` and `sdf-non-affordance` to collaborate on aligning documents and examples, including developing litmus tests for `SDF property` vs. `SDF context`.
*   **Action Item:** Chairs (with Rohit) to fast-track the adoption process for `draft-rohit-asdf-protocol-mappings`.
*   **Action Item:** Before `draft-rohit-asdf-protocol-mappings` adoption, the WG will agree on a descriptive name to avoid conflict with `sdf-mapping`.
*   **Action Item:** Bart to draft an email to the HTTPAPI working group and IANA regarding the NIPY problem types registry, referencing the current `draft-ietf-asdf-nipy`.
*   **Action Item:** Bart (and the WG) to clarify the intended types of NIPY extensions, how they should be registered/named (e.g., IANA, domain names for vendor-specific), and how such naming reflects in URI templates, updating issue 136.
*   **Action Item:** Bart to re-evaluate and address issue 50 regarding "Action without binary data" and the inconsistency in the `extensions/manage/transmit` path in Draft-12.

## Next Steps

*   **Next Interim Meeting:** September 24th, 1 hour earlier than today's slot (9:00 Helsinki time / 8:00 Central European Time). The Chair will request the slot.