TDoc: S4-260181

[Technical] The contribution introduces a “transport-protocol-independent” container while simultaneously mapping each negotiation message to HTTP GET/POST/RESPONSE in Table A4.2-1; the spec needs a clear normative statement on whether HTTP is mandatory, optional, or merely an example, otherwise implementers will diverge.

[Technical] Several metadata fields are not operationally well-defined for interoperability (e.g., minimumTaskInferenceAccuracy, taskAccuracy, outputAccuracy, energyEstimation): there is no mandated metric definition, dataset/benchmark reference, confidence interval, or measurement conditions, so endpoints cannot compare values consistently.

[Technical] The static/dynamic capability split is sensible, but the document does not define update triggers, validity timers, or how dynamic values (e.g., currentComputeLoad, acceleratorAvailability, batteryLevel) are refreshed and correlated to a specific decision point, risking stale negotiation decisions.

[Technical] Units and ranges are inconsistent or missing across key parameters (e.g., flopsProcessingCapabilities, macOpProcessingCapabilities, availableMemorySize, currentComputeLoad); without explicit units (GFLOPS vs FLOPS, bytes vs MB, load as % vs normalized), negotiation logic is ambiguous.

[Technical] The proposal returns “application binary data” and “model binary data” in responses but does not specify integrity/authenticity mechanisms (hash, signature), versioning, or licensing/authorization checks; this is a major gap given executable/model distribution security requirements.

[Technical] URN-based identifiers (applicationIdentifier, modelIdentifier, task identifiers) are introduced without defining the URN namespace, registration/ownership model, and collision handling; interoperability across vendors depends on a normative identifier scheme.

[Technical] The message type list in A.4.4 includes CANDIDATE_MODELS_REQUEST/RESPONSE, while the summary table uses CANDIDATE_MODELS_LIST_REQUEST/RESPONSE; this naming mismatch will cause implementers to treat them as different procedures unless aligned.

[Technical] The call-flow alignment claim (“agreed call flow from S4aR260014”) is not backed by explicit sequencing rules (e.g., whether discovery is mandatory before application request, whether model selection can be repeated, error handling); the procedure needs normative state machine/ordering constraints.

[Technical] sessionId is described as “multimedia session identifier” but the document does not specify which 3GPP identifier it maps to (IMS dialog identifiers, SDP session, MSRP/RTC data channel association, etc.), making correlation across signaling planes unclear.

[Technical] sendingAtTime uses “wall clock timestamp” without defining format (e.g., RFC 3339), time base, and clock synchronization assumptions; if used for ordering/latency, it will be unreliable across endpoints.

[Technical] The endpoint capability fields overlap and may be contradictory (accelerationSupported boolean vs supportedEngines including NPU/GPU, plus acceleratorAvailability dynamic); rules are needed to resolve inconsistencies and define what “acceleration” precisely means.

[Technical] Model I/O descriptors (inputType, inputShape, outputType, outputShape) lack a normative schema (tensor layout, channel order, sample rate for audio, language tags for ASR/TTS/translation), so two endpoints may “match” a model but still be incompatible.

[Editorial] The document mixes “AIML_IMS-MED”, “AI/ML-based media services”, and “local inferencing call flows” terminology without a stable definition section; consistent naming and abbreviations are needed to avoid scope confusion.

[Editorial] Several parameter names are verbose or inconsistent in style (maximumTaskInferenceLatency vs targetInferenceLatency, modelDataType values like Uint8 vs typical uint8), and the JSON examples should be aligned to a single naming convention and enumerated value casing.