TDoc: S4-260222

[Technical] The new “3gpp-ar-animation” data channel definition lacks a normative mapping to WebRTC/RTCDataChannel payload type expectations (binary vs text) and does not explicitly state that messages are sent as binary (e.g., “binary message” / “application/octet-stream”), which is essential to avoid implementations still treating payloads as UTF-8 text.

[Technical] The CR removes the JSON “message type” and subtype structure (facial/joint/landmark/audio/video) but does not replace it with any in-band or out-of-band mechanism to identify the animation sample type/stream, risking ambiguity when multiple ARF sample kinds exist or when multiple animation streams are used concurrently.

[Technical] “Each message contains exactly one ARF animation sample” is underspecified without defining framing rules relative to ARF (TS 26.565 clause 8): if an ARF sample can exceed SCTP message size/MTU, fragmentation/reassembly behavior and any maximum message size constraints should be specified to ensure interoperability.

[Technical] The reliability guidance is inconsistent/weakly normative (“should be reliable by default” + “may negotiate partial reliability”); the spec should clearly state default ordered/reliability parameters and the required behavior when endpoints do not support partial reliability, otherwise different defaults will break interop.

[Technical] The SDP example uses a=dcmap with ordered max-time=150 but the CR does not specify the full required dcmap parameter set (e.g., whether ordered is mandatory, whether max-time/max-retr are mutually exclusive, and what to do if both are offered), leaving negotiation behavior unclear.

[Technical] The statement that the animation channel “shall only carry avatar animation samples” conflicts with the retained “stopped/resumed” control messages remaining on the metadata channel; if control needs tight synchronization with samples, the CR should justify why control is not on the same channel or define correlation rules across channels.

[Technical] The CR introduces a new subprotocol identifier but does not address backward compatibility/interworking with Rel-19 implementations that followed the previous JSON/base64 approach; at minimum, it should specify how an endpoint detects peer support and what fallback behavior is permitted/forbidden.

[Technical] The new channel purpose references “ARF avatar animation samples (clause 8 of TS 26.565)” but does not normatively constrain codec/profile/versioning of ARF samples or how version mismatches are handled, which was previously partially handled via typed JSON structures.

[Technical] Removing the JSON payload object also removes any explicit timestamping/sequence metadata that may have been present or implied; the CR should confirm whether timing/ordering is entirely derived from ARF sample contents and what happens if ARF does not carry sufficient timing for playout.

[Technical] The CR says “No compression scheme defined for animation samples” but does not clarify whether ARF samples may already be compressed or whether additional compression is prohibited; this can lead to incompatible assumptions about payload processing.

[Editorial] Clause references are potentially inconsistent: the CR claims changes in “Clause 6.3.2” and deletion of “Table 6.3-1” while retaining “Table 6.3-2/6.3-3”; ensure numbering and cross-references in TS 26.264 remain correct after deletions/additions.

[Editorial] The wording “metadata data channel … shall not be used to transport ARF avatar animation samples” should be aligned with existing 3GPP normative language and scope (e.g., “AR-MTSI client shall not…”), otherwise it may read as a general prohibition beyond the spec’s intended applicability.

[Editorial] The CR summary asserts the metadata channel is “defined as text-only UTF-8 JSON”; if TS 26.264 currently defines it that strictly, cite the exact normative text being corrected—otherwise the CR should adjust the rationale to match the actual spec wording to avoid overstating the error.