- From: Chris Needham via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Oct 2018 14:16:30 +0000
- To: public-webscreens@w3.org
@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](https://github.com/webscreens/openscreenprotocol/blob/gh-pages/schemes.md#scheme-based-filtering). 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](https://www.hbbtv.org/wp-content/uploads/2018/02/HbbTV_v202_specification_2018_02_16.pdf) and section 5.4.4.3 in [ETSI TS 102 809 v1.3.1](https://www.etsi.org/deliver/etsi_ts/102800_102899/102809/01.03.01_60/ts_102809v010301p.pdf). DVB maintains a registry of `orgId` values. -- GitHub Notification of comment by chrisn Please view or discuss this issue at https://github.com/webscreens/openscreenprotocol/issues/94#issuecomment-428589379 using your GitHub account
Received on Wednesday, 10 October 2018 14:16:37 UTC