TDoc: S4-260119

[Technical] The contribution treats MPEG_gaussian_splatting_transport as a “nested extension inside KHR_gaussian_splatting.extensions”, but glTF extension governance/namespacing and validation rules typically require explicit registration and clear JSON schema; without normative references to the actual MPEG/Khronos drafts and their JSON structures, the proposed two-layer nesting risks being non-interoperable or even invalid in strict glTF validators.

[Technical] The stated graceful degradation (“render as standard point cloud using POSITION and COLOR_0”) is overstated: if splats rely on OPACITY/scale/rotation/SH for appearance, a POINTS fallback will not approximate splat rendering and may be misleading; TR text should qualify this as a debug/preview fallback and specify minimum attributes for meaningful fallback.

[Technical] The attribute list claims SCALE is in log-space and ROTATION is required, but no rationale or interoperability impact is discussed (e.g., quantization, decoding, coordinate conventions, handedness); TR 26.958 would need to capture these conventions precisely or risk implementers producing incompatible decoders.

[Technical] The SH signaling is described as SH_DEGREE_l_COEF_n with degree 0–3, but the mapping to actual coefficient counts, ordering, and whether coefficients are RGB triplets vs scalar per channel is unclear; the proposed “alternative layouts” (mpegProgressive/mpegPerChannel) need an unambiguous normative definition of coefficient indexing and reconstruction to avoid mismatched lighting.

[Technical] The proposal says DC term reconstructed from COLOR_0.rgb or carried via KHR SH_DEGREE_0_COEF_0, which creates two possible sources of truth; this needs a strict precedence rule and constraints (e.g., must match within tolerance) or decoders will diverge.

[Technical] “Progressive download” via progressive.stages listing accessor indices is underspecified: it doesn’t define whether stages are additive vs replacement, how partial accessors are fetched (byte ranges? separate buffers?), and how this maps to 5GMS segmenting; without a concrete packaging model, this is not actionable for 3GPP.

[Technical] The “timed delivery for 4D splats” relies on MPEG_accessor_timed and “circular buffers as defined by MPEG-I Scene Description,” but no details are provided on timestamping, random access, buffering constraints, or synchronization with audio/video; TR 26.958 would need at least a clear reference model for timing and synchronization to be useful.

[Technical] The document implies glTF is already “adopted” by TS 26.118/26.119, but does not specify which profiles/constraints (e.g., glTF 2.0 core vs specific extensions, binary GLB usage, buffer constraints); the integration argument is weak without aligning the proposed extensions to those existing 3GPP profiles.

[Technical] The comparison against PLY focuses on file size and missing features, but omits that PLY is often used with external metadata and that many pipelines use custom binary formats; the TR should avoid implying PLY is inherently non-extensible without clarifying it’s a container lacking standardized extension mechanisms.

[Technical] The contribution references SPZ and “Qualcomm’s L-GSC” as “being considered,” but does not clarify whether these are compatible with the proposed KHR/MPEG layering (e.g., as buffer compression extensions) or require different semantics; this weakens the recommendation of a single “primary format path.”

[Editorial] The document cites a “review draft published August 2025” for KHR_gaussian_splatting, which is future-dated relative to typical 3GPP timelines and raises credibility/versioning issues; the TR proposal should reference stable, publicly accessible draft identifiers/URLs and revision dates.

[Editorial] Proposed TR changes are described only at a high level (“include in Section 4 and new subsection under Section 11”) without concrete text, clause numbers, or proposed wording; for a 3GPP contribution, this makes it hard to assess exact impact and consistency with TR 26.958 structure and terminology.

[Editorial] Several terms are used without definition in 3GPP context (e.g., “canonical splat semantics,” “nested extensions mechanism,” “circular buffers”), and the contribution mixes Khronos/MPEG terminology with 3GPP service language; the TR additions should introduce a short glossary or align terms to existing TR 26.958 definitions.