The primary goal is to achieve consistency across the API, as well as across all specifications. Consistency makes it easier for developers, editors, reviewers, and users of the documentation to understand and modify it. While each organization and specification may and should have its own look and feel, it is considered appropriate to establish a style guide convention. As an example, the Style Guide of the OpenXR Documentation has been branched from the Vulkan documentation and is hence considered a broadly adopted and established convention. In addition, 3GPP uses OpenAPI for the API definition towards the network. Hence, it is proposed to align with the following style guide and documentation conventions:

1. Develop APIs for the relevant reference points in an Internet-accessible source code repository (e.g. 3GPP Forge) and only port agreements or full specifications to 3GPP specifications. The development of the formal APIs is also done in an Internet-accessible source code repository.
2. For device-internal API definitions, align with the OpenXR style guide [20] as follows:
   1. Use Asciidoc [21] to the extent possible to define formal APIs.
   2. For API naming conventions, it is proposed that the rules defined in https://registry.khronos.org/OpenXR/specs/1.0/styleguide.html#naming apply with the following adaptation:
      • Each MSE is assigned a prefix (for example MSE). In similar way as XR is used in the OpenXR specification, an equivalent usage of MSE or an equivalent prefix is expected for an MSE specification. Prefixes are used in the API to denote specific semantic meaning of MSE names, or as a label to avoid name clashes as follows:
        MSE/Mse/mse
      • All types, commands, enumerates and C macro definitions in the specification are prefixed with these characters, according to the rules defined above.
   3. For the mark-up style, it is proposed that the ETSI/3GPP documentation rules as well as the rules defined in section 4 of [20] apply. In particular, section 5.7 of [20] on writing reference pages is expected to apply.
   4. Provide reference pages for the MSE according to the OpenXR principle https://registry.khronos.org/OpenXR/specs/1.0/man/html/openxr.html
3. For the network-based APIs and reference points, define RESTful APIs using OpenAPI YAML according to the rules and conventions defined by 3GPP in TS 29.501.
4. For regular User Plane data communication reference existing protocols and formats.

The media service enabler concepts may be applied to existing functions or to future ones. Existing functions that may be converted and updated to MSE:

• MBMS Client as defined in TS 26.346 and TS 26.347. The MBMS client already uses most of the MSE principles in the way it is defined in TS 26.347.
• MBS Client as defined in TS 26.502.
• Media Session Handler as defined in TS 26.512. This is a candidate for MSE, but not consistently as it is not explicitly serving application but is more considered a background service. Certain aspects of MSE may be applied, but not all.

Other potential MSE candidates:

• Split Rendering functionality
• AI/ML functions

The Technical Report introduces and defines the concept of Media Service Enablers. In recent studies and specification work, it was identified that 5G Media functions and 5G System functions need to be made attractive for third-party applications, in particular those that include media delivery. Hence, it is important that these functions are accessible to third-party applications independent of a 3GPP service. For this purpose, it is considered to introduce normative specifications in 3GPP SA4 that are

• more than just a core functionality, e.g. a codec, without any connection to a service or application
• less than a full service that includes all aspects of session establishment, delivery, codecs, rendering and a full user experience

Such new specifications are referred to 5G "Media Service Enablers". This document includes, among others:

• Definition of the principal properties of Media Service Enablers.
• Examples for similar concepts in 3GPP and external specifications
• Considerations on an appropriate Media Service Enabler Framework
• Definition of a specification template for Media Service Enablers.
• Identification of possibly relevant stage-2 and stage-3 work for Media Service Enablers.
• Collection of a set of initially relevant Media Service Enablers for normative work

The technical report is supported by appropriate tools and style guides to write good MSE specifications. It is recommended that device centric media-related functions defined in 3GPP follow the specification principles defined in

• Clause 6 MSE Specification Framework
• Clause 7 Writing MSE Specifications: Style Guides and Tools

Initial candidates for MSE Specifications are provided in clause 8.

A software management tool is expected to be used. Details are for further study.