**Session Date/Time:** 21 Jan 2026 07:00

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

## Summary

The ASDF Working Group held its first interim meeting of the year. Key discussions focused on the status and next steps for several drafts, including NIPSEY, SDF Protocol Mapping, Instance Information, SDF Non-Affordance, and Digital Twin. Significant progress was reported on NIPSEY and SDF Protocol Mapping, with a general sense of the working group that these drafts are nearing Working Group Last Call. Discussions also covered new features like Trigger APIs in NIPSEY, metadata handling in Instance Information, the use of `sdf:typeLink` for external references in Non-Affordance, and a smart building example in Digital Twin. The next interim meeting was scheduled for February 19th.

## Key Discussion Points

*   **NIPSEY (draft-ietf-asdf-nipsey):**
    *   Draft 16 was released, closing 11 issues, completing 6 new ones, with 4 still in progress.
    *   Updates included RFC XML integration, explicit BLE connection API explanations, CDDL for API definitions, and refining the "onboarding" concept to focus on device instance information.
    *   A new `protocol-information` keyword was introduced for optional, protocol-specific metadata in NIPSEY operations (e.g., BLE service maps).
        *   An open question arose regarding IANA registration for this keyword. Karsten suggested a registry for documentation, with a welcoming policy and expert review to maximize usefulness without impeding progress. Elliot concurred, advocating for a simple "first come, first serve" style registry.
    *   New **Trigger APIs** were added, enabling one device's action/event to trigger an action on another (e.g., a button press turning on a light). Triggers are installed on a NIPSEY gateway, which monitors the source device and calls a URL for the target action.
        *   Elliot raised concern about potential semantic knowledge requirements on the gateway, emphasizing adherence to the end-to-end model. Bart clarified the gateway acts as a simple event-to-URL caller; semantic knowledge for protocol mapping remains at the device level.
    *   An open question remains on adding an event type to the PubSub interface for trigger execution.
    *   IANA considerations for HTTP problem types and `protocol-information` are ongoing.
*   **SDF Protocol Mapping (draft-ietf-asdf-sdf-protocol-mapping):**
    *   Draft 3 was published, removing OpenAPI HTTP protocol mapping, adding security considerations, and moving the `protocol-information` schema to the NIPSEY draft.
    *   The draft is considered largely complete, pending minor tweaks.
*   **Instance Information (draft-ietf-asdf-instance-information):**
    *   Revision-01 was posted, featuring structural simplifications (removing redundant sections, new experimental application scenarios, removing "roads not taken" appendix).
    *   Renamed archetypes to "snapshot," "data," "construction," and "patch" messages.
    *   `timestamps` and `thing-id` were added to the info and instance SDF blocks, respectively, raising a question about the justification for their special treatment outside the SDF context.
    *   Introduced experimental scenarios for protocol binding information (using JSON pointers) and managing the state of affordances (external event histories for actions/events), acknowledging long-running actions are not yet fully covered.
    *   Alignment with Etri drafts has not yet restarted.
*   **SDF Non-Affordance (draft-ietf-asdf-non-affordance):**
    *   Updates included restructuring Section 4, clarifying `sdf:context` semantics, and adding a comparison table between `sdf:property` (interactive, maps to protocol ops) and `sdf:context` (static, descriptive, non-interactive).
    *   Introduced the use of `sdf:typeLink` within `sdf:context` to signal a resolvable reference to external resources (e.g., datasheets, certification documents, digital twin links), instructing tools not to generate API endpoints for them.
        *   Lorenzo suggested considering machine-readable formats for data sheet information. Karsten proposed further exploration of `sdf:typeLink` with web linking concepts, including `REL` (relationship) information, such as "documented by."
*   **Digital Twin (draft-ietf-asdf-digital-twin-architecture):**
    *   Updates in Volume 3 include a new smart building lighting system example (Section 5.4) demonstrating dual protocol support using MQTT for monitoring and CoAP for control.
    *   The example uses SDF relations to control lights based on occupancy, supporting use cases like energy optimization.
    *   Jungjong confirmed the use of SDF protocol mapping, noting its extension to MQTT and CoAP. Bart acknowledged this as a beneficial extension for the working group, though formal specification would be needed.

## Decisions and Action Items

*   **IANA Registration for `protocol-information`:** A sense of those present indicated that the `protocol-information` keyword should be IANA registered under a welcoming policy with expert review to ensure usefulness and timely progress. (Action: NIPSEY authors to propose IANA registry parameters).
*   **Working Group Last Call for NIPSEY and SDF Protocol Mapping:** A sense of those present indicated support for moving NIPSEY and SDF Protocol Mapping drafts towards Working Group Last Call. (Action: Lorenzo to schedule a meeting with Michael (co-chair) to discuss triggering WGLLC for both drafts after a final minor revision).
*   **Next Interim Meeting:** The next ASDF interim meeting will be held on **February 19th** at the same time. (Action: Lorenzo to schedule the meeting).

## Next Steps

*   **NIPSEY & SDF Protocol Mapping:** Authors will incorporate any remaining minor tweaks for one more revision, after which a formal Working Group Last Call is anticipated.
*   **Instance Information:** Authors will seek more implementation experience, re-engage with Etri for alignment of draft documents, and ensure all relevant use cases are covered.
*   **SDF Non-Affordance:** Authors will explore the use of `sdf:typeLink` in conjunction with web linking concepts, including relationship (`REL`) information.
*   **Digital Twin:** Authors plan to incorporate the SDF instance structure, consider additional protocols for SDF-based digital twin modeling, and extend the domain examples to energy and mobility systems.