[HbbTV] Semantics of hbbtv: URLs

[markafoltz]

schemes.md proposes a format for hbbtv: URLs, but there is no reference for how the user agent should process these URLs or what the query parameters mean.

A link to the HbbTV spec where these are defined would help explain the content of query parameters more fully.

Although, if hbbtv: can be supported on the plain Open Screen Protocol without any modifications, this may not be necessary - the controlling UA can just pass it like a https: URL to the presentation screen.

[louaybassbouss]

Thx @mfoltzgoogle I will provide requested details ASAP

[chrisn]

@louaybassbouss and I discussed this issue today.

We're thinking that the controlling user agent would not need to process the URLs, other than to inspect what scheme they use. The scheme can be used as a mechanism to filter compatible receiver devices during discovery, as described here.

We do not envisage the Presentation API being used on top of the existing HbbTV companion screen protocols, so protocol-level backwards compatibility with those isn't a requirement for the Open Screen Protocol. We believe that the controlling user agent can just pass the URI like a https: URL to the presentation screen.

The specific values we plan to encode in the URI are:

• appId, an application identifier allocated by the organization registered with the organization identifier who decides the policy for allocation within the organization.
• orgId, a globally unique organization identifier that identifies the organization that is responsible for the application.

See section 14.6 in HbbTV Specification v2.0.2 and section 5.4.4.3 in ETSI TS 102 809 v1.3.1. DVB maintains a registry of orgId values.

[louaybassbouss]

Thanks @chrisn . One comment from my side considering 'The specific values we plan to encode in the URI ' : appId and orgId are not the only two parameters there are other parameters like the URL of the application to launch (See XML example in section 14.6.2 in HbbTV Specification v2.0.2).

[markafoltz]

It's been a while since I looked at HbbTV but a few thoughts:

• OSP is agnostic to the types of URLs passed through it, it is not specfiic to https: or any other scheme, so if OSP is useful with hbbtv: as a scheme I don't see any issues as long as it parses as a URL.
• If there are specific messages to add to OSP when controlling an HbbTV application or device, the extension mechanism provides a way for HbbTV to define how those would work: https://w3c.github.io/openscreenprotocol/#protocol-extensions