Use of url format for ContentHostingConfiguration.entryPointPath at M1 can disallow relative paths

[davidjwbbc]

Description

In TS 26.512 v17.3.0 Annex C.3.5 the OpenAPI YAML uses the TS26512_CommonData.yaml#/components/schemas/Url type for the ContentHostingConfiguration.entryPointPath which is a type: string with format: uri.

OpenAPI 3.0 uses the JSON Schema to specify the type and format combinations available. For the string type the uri format is specified as being the URI from RFC 3986. However this statement is ambiguous as it does not specify whether it is referring to URI as the thing specified by RFC 3986 or to the URI BNF element specified within RFC 3986. Some JSON Schema parsers and OpenAPI processors have chosen the latter, limiting the strings to URIs which follow scheme ":" hier-part [ "?" query ] [ "#" fragment ]. Since this format mandates the scheme, a simple relative path is not permitted.

My understanding is that the ContentHostingConfiguration.entryPointPath property is supposed to hold a relative path, but cannot if the uri format is used in the strict sense by an OpenAPI processor (such an example tool is the openapi-generator).

The JSON Schema (Draft 6 and above) also contains a uri-reference format which explicitly uses the URI-Reference BNF node from RFC 3986. This format represents either a full URI or a relative path.

Suggested solution

Change the entryPointPath data type from:

entryPointPath:
    $ref: TS26512_CommonData.yaml#/components/schemas/Url

to

entryPointPath:
    type: string
    format: uri-reference

This removes the ambiguity and will allow relative paths in this field in all OpenAPI processors.

[rjb1000]

Problem description seems reasonable, @davidjwbbc, but I think a better solution would be to update TS26512_CommonData.yaml as follows:

1. Define a new RelativeUrl common data type for relative URLs, based on the newer uri-reference JSON Schema type and conforming to relative-ref production in RFC 3986. (Both query and fragment suffixes are permitted.)
2. Clarifying that the base URLs are absolute by introducing a new AbsoluteUrl common data type (based on the disambiguated uri JSON Schema type and conforming to the absolute-URI production in RFC 3986. (Query string is permitted but not fragment identifier.)
3. The original Url common data type can remain in TS26512_CommonData.yaml, but is redefined to be the JSON Schema type uri-reference with a description indicating conformance with the URI-reference production in RFC 3986 which encompasses either a URI or a relative-URI (for reasons of backwards compatibility).

TS26512_M1_ContentHostingProvisioning.yaml is updated to use the new common data types.

Prototypes here:

• TS26512_CommonData.yaml
• TS26512_M1_ContentHostingProvisioning.yaml

[davidjwbbc]

The TS26512_CommonData.yaml linked above is missing the last part of the file, I've replaced it in the version I've used by grabbing the extra component/schemas from the v17.2.0 version.

[rjb1000]

Contributions to 3GPP SA4#122 addressing this issue:

• TS 26.512:
  • Rel-16: CR0031 in S4-230041.
  • Rel-17: CR0032 in S4-230042.

[rjb1000]

Contributions revised and approved at 3GPP SA4#122 Closing Plenary:

• TS 26.512:
  • Rel-16: CR0031r1 in S4-230266.
  • Rel-17: CR0032r1 in S4-230267.

[rjb1000]

CR pack SP-250253 approved at SA#99 Plenary meeting in Rotterdam.

[rjb1000]

New specifications published by 3GPP MCC:

• TS 26.512:
  • V16.9.0.
  • V17.4.0.

(Transcription into equivalent ETSI Technical Specifications to follow in due course.)