TDoc: S4-260127

[Technical] The contribution asserts that “request/download of the application list” and “request/download of a selected application” are “already well-defined in TS 23.228”, but TS 23.228 explicitly says the details of providing/using the application list are not defined; you need to distinguish clearly between (a) transport anchoring and URL rewriting behavior vs (b) application-layer semantics (HTTP resources, formats, selection procedure), which are not fully specified.

[Technical] The “root URL replacement” description is oversimplified: TS 26.114 states the application is accessible at HTTP root “/” and that the authority/Host are ignored by the DCMTSI client, but the contribution doesn’t explain how MF should rewrite absolute URLs, relative paths, query strings, fragments, or non-GET methods—without this, “replacement URL” handling is ambiguous and may break real HTTP interactions.

[Technical] The document claims MF replaces the root URL “with the replacement URL received in step 8”, but in the earlier flow you describe DCSF providing it in steps 3–6 and IMS AS forwarding it in Nmf_MRM_Create; the step numbering and ownership of the URL parameter are inconsistent and could mislead normative behavior (which interface carries what, and when).

[Technical] Reuse for AIML_IMS-MED is proposed without checking applicability constraints from TS 26.114 (e.g., bootstrap DC uses HTTP subprotocol, stream ID < 1000, Host header handling); if AIML_IMS-MED needs different subprotocols, larger stream IDs, or non-HTTP payloads, the “reuse as-is” claim is not technically justified.

[Technical] The proposal “capability exchange negotiation between UE and MF should happen after selection and download of a DC application” conflicts with the stated DCSF policy/capability-based provisioning (“based on capabilities and choices”); if capability affects which application list entries are offered, it may need to occur before or during application list retrieval, not strictly after.

[Technical] The contribution treats “application list offered via MDC1 interface” as a single replacement URL per stream, but doesn’t address multi-stream bootstrap cases or multiple application lists (e.g., per service, per media component); the mapping between streamId and replacement URL needs to be explicit to avoid cross-stream confusion.

[Technical] Security and authorization implications of URL rewriting are not discussed: if MF rewrites requests to DCSF endpoints, the contribution should at least acknowledge how TLS/DTLS termination, origin policy, and access control are preserved (otherwise “reuse” may introduce new trust assumptions for AIML content delivery).

[Technical] The statement “Either UE may select applications from local or remote DCSF (subject to DCSF policy)” is presented as part of the “already specified” flow, but no concrete normative reference or condition is given; this is a potentially significant behavioral claim that should be backed by exact clause text or removed.

[Editorial] Several interface names/operations are used without consistent capitalization or exact naming (e.g., Nimsas_SessionEventControl_Notify, Nimsas_MediaControl_MediaInstruction, Nmf_MRM_Create); for a standards contribution, cite the exact service operation names and clause numbers to avoid misquoting.

[Editorial] The contribution mixes “MDC1 media endpoint address”, “DCSF media endpoint”, and “MDC1 interface” loosely; tighten terminology to match TS 23.228/29.176 data types (e.g., remoteMdc1Endpoint, Mdc1Info) so it’s clear whether you mean IP:port, an HTTP URL, or an NF service endpoint.

[Editorial] The “Discussion” section claims “transport mechanism and URL replacement procedures are fully defined” but earlier you quote that details are not defined; rephrase to avoid overclaiming and explicitly scope what is defined (signalling parameters and MF forwarding behavior) vs what remains unspecified (content format, selection logic, HTTP resource structure).

[Editorial] The document reads like a consolidation note but ends with a “Proposal” that would require normative changes for AIML_IMS-MED; it should state explicitly whether you are requesting spec changes, a work item alignment, or merely recording that existing mechanisms could be reused.