TDoc: S4-260019

1) Technical Accuracy

1.1 Mischaracterisation of the normative scope and ownership

• The summary states: “IMS Data Channel applications defined in 3GPP TS 26.114.”
  
  Issue: TS 26.114 is an SA4 codec/media handling specification (IMS conversational multimedia), and while it may include aspects related to conversational services and media, the definition and service requirements for “IMS Data Channel applications” (and any “Data Channel” feature) typically span multiple specs and groups (SA1 requirements, SA2 architecture, CT protocols, SA4 media). Claiming that the applications are “defined” in TS 26.114 is at best imprecise and may be misleading.
  
  Suggestion: Use more accurate wording such as “specified/handled in TS 26.114 (media aspects)” and cite the primary spec(s) where the Data Channel feature is actually defined (service requirements and architecture).

1.2 Overstated regulatory conclusion (“expected to be subject to telecom regulation”)

• The summary asserts: “When IMS Data Channel is part of IMS telephony services … expected to be subject to local telecom regulation.”
  
  Issue: This is a strong statement and reads like a regulatory determination. In most jurisdictions, regulatory classification depends on the service offered to end users (e.g., ECS/ICS concepts in EU, “telecommunications service” vs “information service” in US, etc.), not on whether a feature is “part of IMS telephony” at a technical level. A Data Channel used within a telephony session does not automatically make the content itself regulated as telecom; it may be treated as an ancillary service, an application-layer feature, or content, depending on local law.
  
  Risk: The statement could be interpreted as 3GPP taking a legal position, which 3GPP generally avoids.

1.3 Ambiguity between “IMS telephony services” and “standalone Data Channel”

• The summary introduces “standalone Data Channel” as “other services.”
  
  Issue: The term “standalone” is not clearly defined here. Is it:


• a Data Channel established outside an IMS telephony session but still within IMS?


• a non-IMS service using similar technology?


• a WebRTC-like data channel?
  
  Without definition, the regulatory discussion is not technically anchored and may be internally inconsistent.

1.4 Technology/content conflation (HTML/JavaScript)

• The summary frames the question as “HTML and JavaScript content (typically not subject to telecom regulation).”
  
  Issue: Whether HTML/JS is regulated is not a technical property; it depends on the service context and jurisdiction. Also, “HTML/JS content” implies a browser-like execution environment on the UE, which raises security and platform questions that are not addressed (see completeness).

2) Completeness

2.1 Missing references to the exact question and original LS text

• The review text references “Question 6” but does not include:


• the exact wording of Question 6 from NG UPG, or


• the exact SA1 reply text.
  
  Impact: It is hard to verify whether SA1’s response is accurate, complete, or appropriately scoped. A reviewer cannot assess whether the response actually addresses the question.

2.2 Missing normative/spec references beyond TS 26.114

• If the topic is “IMS Data Channel,” the document should reference:


• the service requirements spec(s) (SA1),


• architecture spec(s) (SA2),


• protocol specs (CT), and


• security/privacy specs (SA3), as applicable.
  
  Gap: Only TS 26.114 is mentioned, which is insufficient and likely not the primary anchor for “application” behaviour.

2.3 No analysis of security, execution environment, and content handling

• Discussing HTML/JavaScript implies:


• code execution on UE,


• sandboxing,


• origin/authentication of content,


• integrity protection,


• update/refresh behaviour,


• interaction with the call UI and user consent.
  
  Gap: None of these are addressed, yet they are central to both feasibility and regulatory concerns (e.g., consumer protection, malware, lawful intercept boundaries, privacy).

2.4 No clarification of what 3GPP can/should standardize

• The response says it is “not within scope to determine which regulation(s) HTML/JS would be subject to.” That is reasonable, but incomplete without stating:


• what 3GPP can do (e.g., define technical hooks for compliance, transparency, user consent, logging, policy control),


• what is out of scope (legal classification).
  
  This would make the liaison more actionable.

3) Impact Assessment (on specs and implementations)

3.1 Potential downstream interpretation risk

• Even if the LS is non-normative, statements like “expected to be subject to telecom regulation” may be used by:


• regulators as “industry position,”


• operators to justify compliance burdens,


• vendors to implement restrictive behaviours.
  
  Impact: Could inadvertently influence implementation and deployment decisions without technical basis.

3.2 Interworking and product implications not assessed

• If “Data Channel applications” can carry active content (HTML/JS), implementations may need:


• a rendering engine,


• a secure runtime,


• content validation,


• policy enforcement.
  
  Impact: Major complexity and fragmentation risk across UE platforms and vendors. The document does not assess this.

3.3 No assessment of backward compatibility / feature negotiation

• If regulatory treatment differs by service context, implementations may need:


• explicit signalling of service type/context,


• policy control hooks,


• user consent flows.
  
  Gap: No mention of how existing IMS clients or networks would distinguish “telephony context” vs “other services.”

4) Feasibility

4.1 Practical implementability of “HTML/JavaScript content” in IMS context is unclear

• If the intent is to deliver executable web content over an IMS Data Channel, feasibility depends on:


• UE capability standardization (or explicit non-standardization),


• security model (sandbox, permissions),


• content provenance (signing, trusted sources),


• lifecycle management (caching, revocation).
  
  Assessment: Without these, the proposal is not implementable in a consistent, interoperable way.

4.2 Regulatory compliance cannot be “implemented” without technical hooks

• If the liaison implies telecom regulation may apply, then implementers will ask:


• How to support lawful intercept boundaries?


• How to ensure emergency services constraints (if applicable)?


• How to ensure accessibility/consumer transparency?
  
  Assessment: The LS provides no technical guidance, so it is not actionable for implementers.

5) Weaknesses in Argumentation / Methodology

5.1 Lacks a clear separation between legal classification and technical standardization

• The response appears to drift into legal conclusions (“expected to be subject…”) while also disclaiming scope. This is internally inconsistent.

5.2 No jurisdictional neutrality

• 3GPP typically avoids statements that assume a universal regulatory model. The summary’s framing (“telecom regulation” vs “not telecom regulation”) is too binary and not globally valid.

5.3 Undefined terms and missing context

• “IMS telephony services,” “standalone Data Channel,” and “applications” are not defined, making the response hard to interpret and easy to misapply.

6) Suggestions for Improvement

6.1 Tighten terminology and cite the correct specs

• Replace “defined in TS 26.114” with precise references:


• identify the primary spec(s) defining the Data Channel feature and its usage,


• clarify whether TS 26.114 is only referenced for media handling aspects.


• Define “IMS telephony service” in terms of 3GPP service definitions (or reference the relevant SA1 service requirement clauses).

6.2 Rephrase to avoid legal determinations

• Replace “expected to be subject to local telecom regulation” with neutral language, e.g.:


• “Regulatory treatment is jurisdiction-dependent and typically depends on the service offering and national definitions; 3GPP does not determine classification.”


• If SA1 wants to be helpful, it can add:


• “When used as part of a regulated telephony offering, operators may need to consider applicable obligations for the overall service.”

6.3 Make the liaison actionable by identifying technical considerations (without giving legal advice)

Add a short list of technical aspects that may be relevant for compliance and risk management, such as:

- content provenance and integrity (signing, authentication),

- UE execution environment constraints (sandboxing, permissions),

- user consent and transparency,

- policy control and operator configuration,

- logging/auditing hooks (where appropriate),

- security and privacy considerations (coordinate with SA3).

6.4 Clarify the “standalone Data Channel” scenario

• Explicitly describe the scenarios NG UPG is asking about:


• within an IMS telephony session,


• within other IMS sessions,


• outside IMS (if relevant).


• If “standalone” is not a 3GPP-defined service, say so and limit the response accordingly.

6.5 Include the exact Question 6 text and the exact SA1 reply text in the contribution (or as an attachment)

• This is essential for traceability and for SA plenary to consolidate responses correctly.

6.6 Engage the right groups for a coordinated response

• Recommend that SA consolidates inputs from:


• SA2 (architecture/service context),


• SA3 (security model for active content),


• CT (signalling/negotiation),


• SA4 (media/data channel handling),


• SA6 (application enablement, if applicable).
  
  This will prevent SA1’s response from being interpreted as the sole “3GPP position.”

Bottom line

As summarized, the liaison response is directionally cautious (“not within scope to determine regulations”) but undermined by imprecise spec referencing, undefined scenarios, and an over-strong statement implying regulatory classification. It should be rewritten to be jurisdiction-neutral, technically anchored (correct specs/definitions), and more actionable by highlighting relevant technical considerations without making legal assertions.