**Session Date/Time:** 02 Feb 2022 16:00

# [TAPS](../wg/taps.html)

## Summary

The TAPS Working Group held an interim meeting to review open Pull Requests (PRs) and issues across the Architecture, API, and Implementation documents. Several PRs were reviewed and merged, addressing consistency, clarity, and typo fixes. Key discussions included the handling of framer properties, message context property inheritance, and refining endpoint specification. The working group also discussed the timing for a Working Group Last Call (WGLC) for the implementation document and confirmed plans for a session at IETF 113, with initial agenda topics. An initiative to create an accessible public summary of TAPS was also discussed.

## Key Discussion Points

*   **Framer Properties in Message Context**:
    *   The use of a broad "scope" parameter for framer properties in `message context` was identified as inconsistent with the existing `namespace` mechanism for `Transport Properties` (Section 4.1).
    *   The sense of those present was to utilize the existing `namespace` mechanism, where the framer name prepends the property name, making the API more consistent.
    *   The API document does not need to explicitly solve potential name collision issues between multiple framers; this is an implementer's concern.
*   **Local/Remote Endpoints for Listen/Initiate**:
    *   A PR proposing to change "must" to "should" for specifying local endpoints for `listen` and remote endpoints for `initiate` was discussed.
    *   For `listen`, it was agreed that a local endpoint *must* be specified, though default assignment (e.g., "don't care") could make "should" plausible with clarification.
    *   For `initiate`, a remote endpoint *must* be specified to identify the communication peer. Corner cases were deemed too niche.
    *   The original text's semantics ("If listener, must have local; may have remote. If initiator, must have remote; may have local") were affirmed, leading to the rejection of the proposed change as the text was considered semantically correct as is.
*   **Certificate Path Validation Reference**:
    *   Discussion arose on whether to add an informative reference to standard PKI specifications (e.g., RFC 5280) for certificate path validation, especially for customized validation scenarios.
    *   There was agreement that such a reference would be beneficial.
*   **Pre-shared Keys (PSK) Coverage**:
    *   A question was raised regarding explicit call-out for Pre-shared Key (PSK) support within security parameters, beyond existing mentions of keying material imports (Section 6.3.1).
    *   Further review is needed to ensure comprehensive coverage.
*   **Message Context Property Inheritance**:
    *   The current text on how message context properties inherit values from connection properties if not explicitly set was deemed unclear and subject to misinterpretation.
    *   The original intent was for message contexts to act as dictionaries of changes applied *over* connection defaults, not to hold a full state requiring creation from an existing connection.
    *   A proposal to clarify this by stating that unset message properties inherit from connection properties, or that they have an "inherit/default" value, was supported. This applies to a handful of specific message properties (e.g., reliability, priority, ordered).
*   **Working Group Last Call (WGLC) for Implementation Document**:
    *   The working group has completed WGLC for Architecture and API drafts.
    *   A WGLC for the implementation document was discussed to gather more feedback, given several outstanding issues.
    *   The sense of those present was to initiate the WGLC for the implementation document at IETF 113.
*   **IETF 113 TAPS Session**:
    *   Despite uncertainties regarding in-person attendance, a TAPS session at IETF 113 was deemed desirable.
    *   A 60-minute slot was preferred.
    *   Potential agenda items include a presentation on a new Go implementation, discussion/scrubbing for the implementation WGLC, and discussion of new protocol mapping documents (e.g., for QUIC).
*   **TAPS Public Summary/Outreach**:
    *   The idea of creating an accessible summary of TAPS (Architecture, API, Implementation) for new participants or reviewing bodies (like the IESG) was proposed.
    *   A Wikipedia page, similar to the ALTO WG's approach, was suggested as a highly accessible platform, alongside existing IETF and APNIC blog posts.
    *   Concerns about Wikipedia's open editing model were discussed, with the conclusion that the benefits of public accessibility outweigh the risks, and existing RFCs/drafts serve as references.

## Decisions and Action Items

*   **Decision**: The `namespace` mechanism in Section 4.1 (`Transport Properties`) will be used for framer properties, by prepending the framer's name to the property name.
    *   **Action Item**: Brian and Michael (and Philip who was tagged) to propose specific text (PR) clarifying this mechanism.
*   **Decision**: Sean's PR to change "must" to "should" for endpoint specification was rejected; the original text is to be retained.
    *   **Action Item**: Tommy to close the PR.
*   **Decision**: The PR to update outdated references was merged.
    *   **Action Item**: Tommy to merge the PR.
*   **Decision**: Corey's PR (number 1000) for "network vs. interface" wording fixes was approved and merged after a minor typo fix.
    *   **Action Item**: Tommy to fix the typo and merge the PR.
*   **Decision**: The PR clarifying framer synchronization requirements was merged.
    *   **Action Item**: Tommy to merge the PR.
*   **Decision**: The PR clarifying pre-connection immutability was merged, after removing a problematic sentence and fixing a typo.
    *   **Action Item**: Tommy to perform the edits and merge the PR.
*   **Decision**: The PR explaining address selection properties and preferences was merged.
    *   **Action Item**: Tommy to merge the PR.
*   **Decision**: Issue 9 regarding the default priority value of 100 was closed.
    *   **Action Item**: Tommy to close the issue.
*   **Action Item**: Colin to propose concise text (PR) for adding ASM multicast support using the rendezvous concept.
*   **Action Item**: Tommy to write text for an informative reference to PKI specifications (e.g., RFC 5280) regarding certificate path validation.
*   **Action Item**: Tommy to review with Chris to ensure pre-shared key (PSK) support is adequately covered in the document.
*   **Action Item**: Michael to make a PR clarifying message context property inheritance, possibly by adding a paragraph in Section 9.1.3 and/or per property.
*   **Decision**: Target a Working Group Last Call (WGLC) for the TAPS Implementation document to begin at IETF 113.
*   **Decision**: The TAPS Working Group will hold a 60-minute session at IETF 113.
*   **Action Item**: Martin to email Brian an outline for a TAPS summary/overview document (potentially for Wikipedia or blog posts), and Brian to fill in the text.

## Next Steps

*   Individual action items for PRs and issues are to be addressed.
*   Chairs to work on scheduling the TAPS session for IETF 113 and assembling an agenda based on discussed topics (Go implementation, Implementation WGLC, protocol mapping documents).
*   An email reminder will be sent out regarding the upcoming Internet-Draft submission cutoff (March 7th) to encourage updates to the API and Implementation documents before IETF 113.
*   The TAPS summary initiative (Martin and Brian) will proceed, with potential publication on Wikipedia and/or IETF blog.
*   No additional interim meeting is planned before IETF 113.