**Session Date/Time:** 23 Sep 2025 13:00

# [WISH](../wg/wish.html)

## Summary

The WISH Working Group held an interim meeting to review and address open issues in the WISH draft, with a focus on preparing for final edits ahead of IETF 124 in Montreal. Key discussions revolved around defining error handling, discoverability for players, and the role of events within the V1 specification. Several issues were prioritized for immediate action, while others require further consensus on the mailing list.

## Key Discussion Points

*   **Issue #39: Server-side offer error codes:**
    *   Lorenzo's implementation feedback highlighted ambiguities in error handling for server-side offers.
    *   Discussion recalled previous HTTP Directorate review feedback discouraging fixed error codes in the spec and suggesting the use of problem statement bodies.
    *   A challenge was noted with including a problem statement body if the response body is intended for an offer.
    *   The group acknowledged the need to properly define error codes, considering general HTTP error codes (e.g., 400, 406) versus potential 2xx responses for partial successes.
    *   It was suggested that learnings from addressing Issue #36 (WIP RFC Editor changes) might inform the resolution of this issue.
*   **Issue #36: Backporting RFC Editor changes from WIP:**
    *   This issue was identified as a high priority.
    *   It was agreed that all lessons learned from the significant effort to satisfy HTTP requirements for the WIP specification should be backported to WISH.
*   **Issue #29: Client must silently ignore unknown fields in the event:**
    *   This was considered a small but important change to add language to the draft.
    *   The intent is to provide flexibility for future extensions and allow clients to gracefully handle unknown fields without failure.
    *   A sense of those present indicated support for this change.
*   **Issues #19 & #20: Events via Data Channel / Keeping events in V1:**
    *   A prior meeting reportedly reached a consensus to remove the event framework from the main WISH V1 spec and move it to a separate draft.
    *   Concerns were raised that this would significantly reduce the utility of WISH V1, as the event framework is reportedly in active use.
    *   The idea of keeping events in V1 but allowing for extensibility (e.g., via data channels in a separate document) was discussed.
    *   Given the differing views, it was decided to re-poll the mailing list to establish current consensus on whether the event framework should remain in WISH V1.
*   **Issue #15: Discoverability as a WISH URL:**
    *   The importance of discoverability for media players to identify and correctly handle WISH URLs was emphasized, contrasting with WIP where the URL is explicitly known for publishing actions.
    *   Initial options considered included adding a file extension (like HLS .m3u8), a new URL scheme (like RTMP), or a JSON-returning endpoint.
    *   The JSON endpoint idea was deemed likely to increase round trips and was less favored.
    *   A suggestion was made to define the `GET` behavior for a WISH URL and then leverage `HEAD` requests. A `HEAD` request could return HTTP headers indicating the resource is an SDP offer, allowing players to discover it.
    *   There was a sense of agreement to pursue the `HEAD` request approach as the most promising path forward.
*   **Issue #7: Codec Negotiation Error:**
    *   In WIP, codec negotiation was an "all or nothing" proposition; partial success was not allowed.
    *   Discussion focused on whether WISH V1 should be more lenient, allowing for partial success.
    *   Specifically, it was proposed to allow rejection of individual M-lines for non-media components (like data channels) without failing the entire offer, to facilitate future extensibility.
    *   For V1, the direction for WISH is to allow media partials, and data channels can be dropped from the offer without rejecting the whole.
*   **Issue #6: Define behavior if publish stream ends:**
    *   The need for a mechanism to notify players when a published stream ends was discussed.
    *   This issue is directly dependent on the resolution of the event framework discussion (#19/#20). If events are part of V1, a server-sent event would be the preferred notification method.

## Decisions and Action Items

*   **Issue #39 (Error Codes):** Needs resolution, potentially informed by #36 learnings.
*   **Issue #36 (RFC Editor changes from WIP):** Prioritized for immediate backporting.
*   **Issue #29 (Client must silently ignore unknown fields):** To be implemented by adding language to the draft.
*   **Issues #19, #20 (Events in V1 / Data Channels):** Consensus to be re-polled on the mailing list to decide if the event framework (including server-sent events) should remain in WISH V1.
*   **Issue #15 (Discoverability):** The group will pursue defining discoverability via `HEAD` requests.
    *   **Action Item:** Dan to create a Pull Request (PR) defining the `HEAD` request behavior for WISH URLs.
*   **Issue #7 (Codec Negotiation Error):** For WISH V1, the approach is to allow media partials, and data channels can be dropped from the offer.
*   **Issue #6 (Define behavior if publish stream ends):** Resolution is contingent on the mailing list discussion for issues #19 and #20 regarding events.
*   **Action Item:** Dan to send an email to the mailing list to initiate discussion and seek consensus on the event framework (#19, #20, and #6).
*   **Action Item:** Dan to review and address all remaining issues marked as "required" within the next two weeks.

## Next Steps

*   Address outstanding issues, particularly #36 (WIP RFC editor changes) and #39 (error codes).
*   Actively engage the mailing list for consensus on the event framework and its inclusion in WISH V1.
*   Submit PRs for agreed-upon changes, such as silent ignoring of unknown fields and `HEAD` request discoverability.
*   Complete remaining "required" issues to prepare for a stable draft ahead of IETF 124 in Montreal.