TDoc: S4-260249

[Technical] The statement in NOTE 1 that “5G latency or jitter requirements do not apply” is too absolute; even file-based delivery can have user-experience constraints (e.g., time-to-first-render, progressive download), so the CR should qualify the conditions (offline vs interactive) and avoid implying no QoS considerations at all.

[Technical] Claiming “Standard 5G bearers specified in TS 23.501 are adequate” is underspecified and potentially misleading because TS 23.501 defines QoS framework and 5QI characteristics; the CR should indicate which QoS treatment is assumed (e.g., default/non-GBR, TCP-based delivery) or explicitly state that no specific 5QI is mandated.

[Technical] Mapping “3DGS File Delivery” to MMS (TS 26.140/26.143) and RCS messaging is questionable for typical 3DGS asset sizes; MMS/RCS have practical payload limits and store-and-forward behaviors that may not support large 3DGS datasets, so the CR should either constrain the use case (small assets/thumbnails) or prioritize HTTP-based delivery.

[Technical] The CR asserts a “file-based delivery model rather than streaming,” but 3DGS can be delivered progressively or as time-aligned animation streams (as mentioned under content generation); the mapping should address whether timed delivery uses DASH/MPEG-based streaming, MBS, or other 3GPP media streaming services rather than only “download/message-based assets.”

[Technical] The “time-aligned animation stream generation” function is mapped only to an on-UE application, but the CR does not explain how timing, synchronization, and clock/reference (e.g., with audio/video or pose streams) are handled within the 3GPP media framework; this is a gap if the clause is meant to be a workflow mapping.

[Technical] The mapping to “Media Access Function of Media Delivery architecture (TS 26.501)” for MMS/RCS/HTTP is not clearly justified; TS 26.501’s Media Delivery architecture typically assumes HTTP-based media access, and messaging services are not obviously “Media Access Function” instances—this needs architectural consistency or a rationale.

[Technical] “Low Packet Error Rate and reliable delivery required” is vague and somewhat contradictory with the earlier dismissal of QoS; if reliability is a requirement, the CR should clarify whether it relies on transport-layer reliability (TCP/QUIC) versus radio-layer QoS, and what failure/retry behavior is expected.

[Technical] Storage is mapped to “UE local storage (no 3GPP-specific mapping),” but the clause should at least mention whether any 3GPP enablers are relevant for content management (e.g., caching, content hosting, or application-layer DRM/security) if the intent is a comprehensive mapping.

[Editorial] The contribution references “3GPP TR 26.501” and “TS 26.501” interchangeably; TS 26.501 is a Technical Specification, so the document should use consistent and correct document type references.

[Editorial] The CR summary says it introduces “a new clause (Clause 10)” but does not show the actual inserted text, table structure, or exact normative wording; for a CR review, the proposed clause text and precise edits are necessary to assess completeness and consistency.

[Editorial] The term “All in UE configuration” is used without a clear definition or cross-reference to earlier clauses in TR 26.958; the clause should explicitly define the configuration assumptions (where capture, encoding, delivery, rendering occur) to avoid ambiguity.

[Editorial] The mapping table items mix functions (“scene capture”) with deployment statements (“3DGS/XR Application on the UE”) and with 3GPP service names; the table would be clearer if it separated functional blocks, 3GPP enablers, and interfaces, and used consistent terminology aligned with TS 26.501 entities.