1) Technical Accuracy

1.1 Mischaracterization / ambiguity of CAPIF scope vs. IMS use case

• The document suggests CAPIF (TS 23.222) “could potentially serve as a reference” for interworking between IMS sessions and external (non-IMS) content sources. This is plausible at a high level (API exposure and security), but the contribution does not acknowledge key scope differences:


• CAPIF is primarily an API exposure framework (onboarding, discovery, authorization, logging) for API invokers and API providers. It does not define IMS session-level interworking procedures (e.g., SIP dialog correlation, media plane integration, MSRP/data channel binding, etc.).


• The GSMA question is about “interworking between the IMS session and external content sources” (e.g., “pulling information from a public API”). CAPIF can help with secure API access, but it does not inherently solve session coupling (how the API result is injected into an ongoing IMS communication, how identity/consent is mapped, how policy is enforced per session).


• As written, the reply risks being interpreted as “CAPIF covers it” or “CAPIF is the intended solution,” which would be technically misleading without explicit caveats.

1.2 “Third-party API providers in non-3GPP systems” phrasing is questionable

• The statement “CAPIF architecture and procedures for third-party API providers in non-3GPP systems…” is imprecise. CAPIF is a 3GPP framework intended to support exposure and consumption of APIs; “non-3GPP systems” is not a CAPIF-defined category in a clean way. CAPIF can expose APIs implemented by various domains, but the document should be careful not to imply CAPIF standardizes “non-3GPP systems” procedures beyond the CAPIF interfaces and roles.

1.3 Security claim lacks specificity

• The reply states CAPIF can “securely expose capabilities” and “enable secure utilization.” While CAPIF indeed addresses security aspects, the reply does not specify which security properties are relevant to the GSMA question (e.g., mutual authentication, authorization, token-based access, auditing). Without that, the “secure manner” part of the question is not substantively answered.

2) Completeness

2.1 The reply does not actually answer the “plan to define procedures and architecture” question

• The question asks whether SA2/SA6 plans to define procedures/architecture. The response says SA6 has not yet studied it and will keep GSMA informed. This is not a clear “yes/no/under what conditions” answer.


• If SA6 has no plan, it should say so explicitly. If it might be addressed under an existing WI (FS_MMTel_Ph2_APP) or a future WI, that linkage is missing.

2.2 Missing references to IMS-specific enablers and relevant specs

• If the topic is “external data channel content access” in an IMS context, the reply should at least reference the IMS service architecture and any relevant IMS enablers (even if only to say “out of scope”):


• IMS architecture baseline (e.g., TS 23.228) and service capability interaction concepts.


• Any SA6 application enablers relevant to data channels / content insertion (depending on the exact feature context of FS_MMTel_Ph2_APP).


• Without these, the reply feels disconnected from the IMS session aspect of the GSMA question.

2.3 Missing analysis of what “interworking” means in this context

The reply does not clarify whether “interworking” refers to:

- Network-side retrieval of external content and injection into an IMS session (e.g., via an application server), or

- UE-side retrieval (UE calls public API directly) with IMS only carrying the resulting content, or

- Hybrid (network provides authorization/attestation; UE fetches content).

These are materially different architectures with different standardization needs.

2.4 Missing discussion of trust domain and “public API” realities

• GSMA explicitly mentions “public API.” CAPIF typically assumes a controlled onboarding and trust relationship. The reply does not address how CAPIF would apply when the API provider is truly public/untrusted/outside PLMN control, or what additional mechanisms would be needed (e.g., federation, external IdP, consent, API gateway policies).

3) Impact Assessment

3.1 Minimal immediate spec impact (as written)

• Since SA6 states it has not studied and does not propose normative changes, the immediate impact on existing specifications is minimal.

3.2 Risk of misdirection / scope creep

• Referencing CAPIF without clarifying boundaries could steer discussions toward adopting CAPIF for IMS session interworking without a clear gap analysis. This can create:


• Misalignment between SA6 (IMS application layer) and SA2 (system architecture) responsibilities.


• Potential duplication or conflict with existing API exposure frameworks (e.g., 5GC NEF exposure patterns) if not carefully positioned.

3.3 Potential implementation impact if CAPIF is later mandated

• If future work were to mandate CAPIF-like onboarding/security for IMS-related external content access, it could impose:


• New network functions (CAPIF core functions) or integration with existing API gateways.


• New UE/client behaviors (token handling, discovery) depending on where the API invoker resides.


• None of these impacts are acknowledged, so stakeholders cannot gauge complexity.

4) Feasibility

4.1 Feasibility depends on architecture choice (not provided)

• Using CAPIF as a “reference” is feasible only if the intended solution is API exposure/consumption within a managed trust framework. If the requirement is to securely access arbitrary “public APIs” during an IMS session, CAPIF alone may be insufficient without:


• Federation/roaming trust models


• External identity and consent handling


• Policy enforcement tied to IMS session context

4.2 Practical coupling to IMS session is non-trivial

• The key feasibility challenge is binding API access to an IMS session (identity, authorization, charging, policy, and user consent). The reply does not acknowledge this, which understates complexity.

5) Weaknesses

5.1 Non-committal and lacks actionable guidance

• “Not yet studied” + “keep informed” provides little value to GSMA. It does not indicate whether SA6 considers it in-scope, who should lead (SA2 vs SA6), or what timeline/WI vehicle might exist.

5.2 No gap analysis

• The reply does not identify what is missing today in 3GPP specs for the described use case:


• Is the gap security? session correlation? API discovery? authorization? data channel semantics?


• Without a gap analysis, CAPIF is mentioned as a generic “maybe,” which weakens the technical credibility.

5.3 Conflation risk: “external content access” vs “API exposure”

• The GSMA question is about interworking between IMS session and external content sources. CAPIF is about API exposure and consumption. The reply does not articulate how API consumption translates into “content access” within an IMS data channel context.

6) Suggestions (Constructive)

6.1 Provide a clearer, direct answer on “plans”

• Explicitly state one of the following (with rationale):


• SA6 has no plan (and why; e.g., out of scope, better handled by SA2/CT).


• SA6 plans to study under FS_MMTel_Ph2_APP (or propose a new study item), with a tentative timeline.


• SA6 believes SA2 should lead architecture; SA6 can support application aspects.

6.2 Add a short gap analysis and scope statement

Include 3–5 bullets clarifying:

- What “interworking” is assumed to mean (network-side vs UE-side vs hybrid).

- What aspects are potentially standardizable (security, authorization, discovery, session binding).

- What is likely out of scope (e.g., standardizing arbitrary public API schemas/content).

6.3 Clarify CAPIF applicability and limitations

If CAPIF is mentioned, add precise positioning:

- CAPIF can be a reference for secure API onboarding/discovery/authorization.

- CAPIF does not define IMS SIP/media procedures; additional work would be required for session coupling.

- Identify what additional specs/functions would be needed (e.g., an IMS AS acting as API invoker; mapping of IMS identity to API authorization context).

6.4 Add concrete references and alignment points

• Cite relevant IMS architecture/service enablers (at least TS 23.228) and any SA6 specs relevant to the “external data channel” feature context (if applicable).


• If the intent is to leverage 5GC exposure concepts, mention alignment with NEF/API exposure principles (without over-claiming).

6.5 Propose next steps for SA coordination

• Recommend SA2/SA6 joint discussion to determine:


• Whether the architecture belongs in SA2 (system architecture) and procedures in SA6 (IMS service/application).


• Whether a new study item is needed, with a clear problem statement and success criteria.

Bottom line

The reply is technically not wrong in pointing to CAPIF as a potentially relevant security/API framework, but it is too vague, does not answer the “plan” question, and lacks the necessary scope clarification and gap analysis to be useful. Adding explicit boundaries, references, and a concrete next-step proposal would significantly improve the contribution’s value and reduce the risk of misinterpretation.