TDoc: S4-260080

[Technical] The contribution proposes adding “IMS extension support” and “review protocol for extensions” as requirements, but TR 26.870 clause 4.2 should state concrete media/system requirements (e.g., session setup, media negotiation, synchronization) rather than vague process statements; specify what IMS/SIP/SDP capabilities are actually needed (new SDP attributes, new media types, MSRP/data channel, etc.).

[Technical] Several requirements assume “network performs transcoding from video to immersive media codecs” and “network-based rendering/face rendering,” which is a strong architectural choice; TR 26.870 requirements should be phrased technology/placement-neutral (edge/device/network) unless SA4 has agreed on normative functional split assumptions.

[Technical] “Support for 4K + HDR uplink video” is underspecified and potentially unrealistic for uplink in many deployments; it needs frame rate, chroma, bit depth, HDR format (HDR10/HLG/Dolby Vision), latency/jitter targets, and whether it is mandatory or optional/tiered.

[Technical] Eye tracking is introduced as a requirement but no performance constraints are given (sampling rate, end-to-end latency budget, accuracy, coordinate system, time-stamping); without these, it is not actionable for codec/transport/synchronization work in SA4.

[Technical] “User intention understanding capability (via voice/gesture)” is not a media delivery requirement unless mapped to explicit interfaces and data exchange (event streams, metadata formats, privacy controls, timing alignment with media); otherwise it reads as an AI feature requirement outside SA4 scope.

[Technical] The use case mixes classic conversational media with sensor/biometric data (blood pressure, heart rate) but does not specify how such data is transported (RTP/RTCP extensions, data channel, HTTP-based side channel) nor how it is synchronized with audio/video/immersive rendering.

[Technical] “Tiered QoE support taking device capabilities into account” needs definition of tiers and the adaptation mechanisms (scalable coding, simulcast, layered rendering, viewport-dependent delivery, bitrate/latency trade-offs); otherwise it duplicates generic QoE statements already present in many TRs.

[Technical] The multi-device scenario (smart TV + cameras + watches + sensors) implies multi-stream capture and tight synchronization, but no requirement is stated for common time base, clock sync, or inter-stream lip-sync/scene-sync tolerances—key for immersive calling.

[Technical] The “eye-contact enablement” story implies sending “facial picture” plus eye tracking to render a face; this raises identity/spoofing and consent requirements (authenticity of rendered representation, user control, watermarking/indication) that are not addressed but are critical for a calling service.

[Technical] The text repeatedly references “6G system” and “AI technologies (e.g., LLM)” in a way that may conflict with TR 26.870’s 5G/3GPP system framing; requirements should be expressed in 3GPP-system-agnostic terms or aligned to the TR’s agreed scope and terminology.

[Editorial] The contribution claims “updates to clause 4.2” but provides no proposed change text, no exact requirement wording, and no indication of how the new items integrate with existing 4.2 structure; reviewers cannot assess consistency or redundancy without the actual delta.

[Editorial] Terminology is inconsistent/unclear (“immersive media codecs,” “split-rendering,” “spatial computing rendering,” “multi-media transporting”); these should be aligned with existing SA4 terms (e.g., MIV, V3C, RTP-based immersive media, split rendering definitions) or explicitly defined.

[Editorial] Several statements are ambiguous or non-testable (e.g., “protocol extensions should be possible,” “review protocol for extensions,” “system fulfills user intention”); requirements in TR 26.870 should be phrased as verifiable capabilities with clear conditions and outcomes.