8 受信機仕様
8.1 受信機仕様（ ARIB フェーズ０運用仕様）
8.1.4 アプリケーションエンジン
本節では、受信機に搭載するハイブリッドキャストアプリケーション実行環境であるアプリケー ションエンジンについて記載する。
8.1.4.1 通信プロトコル仕様 8.1.4.1.1 HTTP/HTTPS 8.1.4.1.1.1 通信スタック
アプリケーションエンジンは通信手段として、IPTVFJ STD-0010 「8.1アプリケーションの伝送」
の規定に基づき、以下の通信手段を実装する必要がある。
・ HTTP/1.1をサポートし、RFC 2616に準拠し実装しなければならない。加えてHTTP/1.0
の実装もサポートし、RFC 1945に準拠し実装すること。
メソッドは、GETおよびPOSTを必須とし、その他のメソッドの実装は、本運用規定では 規定しない。
・ SSL3.0/TLS1.0をサポートし、RFC 2246に準拠する。
上記に加えて、httpsを実現するためにRFC 2818に従い手順を実装すること。
以下に、実装にあたり制約事項を述べるが、ストリーミング再生にHTTPを用いる場合には、
その通信で定められた制約に従うこと。
8.1.4.1.1.2 HTTPヘッダフォーマット
特に指定がない場合は、RFC 2616に記述の動作を行うこととするが、以下の制約を設ける。
・日付/時刻フォーマット
HTTPヘッダ内に記載する日付の形式は、RFC 1123で規定された形式とし、タイムゾーンは GMTとする。他の形式で記述された場合の処理は本運用規定では規定しない。
8.1.4.1.1.3 内容コーディング
内容コーディングは、identityのみ運用する。content-codingヘッダにてgzipなど他の値を受け 取った場合、処理できるかどうかは本運用規定では規定しない。
8.1.4.1.1.4 転送エンコーディング
転送エンコーディングは、chunk形式を運用する。受信機はchunk転送をサポートしなければ ならない。
8.1.4.1.1.5 Cache-Controlヘッダ
アプリケーションエンジンが生成するリクエストメッセージには、cache-controlヘッダの値を
no-cacheとして付与することが望ましい。
一方、レスポンスヘッダにおけるcache-controlの値が、no-cacheもしくはno-storeの場合は、
RFC 2616の記述に従い処理されなければならない。その他の動作は、本運用規定では規定しない。
8.1.4.1.1.6 HTTPアクセス認証
アクセス認証方式として、RFC 2617に記載されたBasic認証およびDigest認証をサポートする
こと。また、必要に応じて、ユーザー名およびパスワードを入力する手段をユーザーに提供しな ければならない。
8.1.4.1.1.7 Cookie
アプリケーションエンジンは、RFC 6265に規定されるCookieによるHTTP状態管理機構を実 装しなければならない。
ただし、以下の制約を設ける。
・Cookieの保持
放送マネージドアプリから使用できるCookieとして、少なくとも以下のサイズ、個数を保 持することが望ましい。また、Cookieはユーザーの操作により、無効化および削除する手段 を実装することが望ましい。
＊ Cookieの総数は、300以上保持できること。
＊ １つのCookieの最大長は、RFC 6265に基づき、4096byteとする。
＊ 1サイトあたりのCookie 数は20 個以上保持できること。
8.1.4.1.1.8 User-Agentヘッダ
アプリケーションエンジンは、User-Agentヘッダを以下の書式に合わせてHTTPリクエストの ヘッダに含めて送信しなければならない。
User-Agent: <others> <SystemName>/1.0 (<Capability>;<MakerId>;<ModelId>;<MajorVer>;<MinorVer>;
<reserved>) <others>
<SystemName> : Hybridcast
<Capability> : 受信機の能力を表す。現状では空文字列とする。
<MakerId>:製造メーカーの識別を示す。
MakerId は6 桁の文字列で、IEEE 規定の24bit のカンパニーID(OUI)をbase16 の文字列で 表したものとする。メーカーに対してOUIは複数存在する可能性があるが、そのうち特定の
１種類をMakerIdとして使用すること。
< ModelId >:機種を示すコードであり、10文字までの文字列である。運用は各メーカーに任さ
れる。
<MajorVer><MinorVer>: 端末のバージョン情報を示し、共に8文字までの文字列とする。
ModelIdが同一で、動作が異なる端末には、異なるバージョンを付する。運用は各メーカー
に任される。
<reserved>:将来の拡張のための領域
<others>: メーカーが自由に使える領域。ただし、本規定の識別子と区別するため、
<SystemName>で文字列が始まらない必要がある。
なお、使用する文字列はRFC 2616 に従うものとする。
8.1.4.1.2 WebSocket
アプリケーション伝送プロトコルおよびアプリケーションとサーバー間のデータ伝送プロトコ
ルとしてWebSocketを実装するかは本運用規定では規定しない。実装する場合は、IPTVFJ
STD-0010「8.2.1.2.WebSocket」の規定に基づき、RFC 6455に従い実装しなければならない。
8.1.4.2 HTMLコンテンツレンダラ仕様 8.1.4.2.1 HTML要素
アプリケーションエンジンにおけるHTML要素の対応については、別途、運用ルールにて規定す る。運用ルールについての詳細は、IPTVフォーラムに問い合わせること。
8.1.4.2.2 ハイブリッドキャストアプリケーション対応に必要なHTML要素・属性
8.1.4.2.2.1 HTML要素
アプリケーションエンジンにおけるHTML要素の対応については、別途、運用ルールにて規定す る。運用ルールについての詳細は、IPTVフォーラムに問い合わせること。
8.1.4.2.2.2 グローバル属性
別途、運用ルールにて規定する。運用ルールについての詳細は、IPTVフォーラムに問い合わせる こと。
8.1.4.2.2.3 個々のHTML要素に対する属性
別途、運用ルールにて規定する。運用ルールについての詳細は、IPTVフォーラムに問い合わせ ること。
8.1.4.2.2.4 HTML4.01 対応
別途、運用ルールにて規定する。運用ルールについての詳細は、IPTVフォーラムに問い合わせ ること。
8.1.4.2.2.5 meta要素
別途、運用ルールにて規定する。運用ルールについての詳細は、IPTVフォーラムに問い合わせ ること。
8.1.4.2.2.6 input要素
別途、運用ルールにて規定する。運用ルールについての詳細は、IPTVフォーラムに問い合わせ ること。
8.1.4.2.2.7 a (anchor)要素
別途、運用ルールにて規定する。運用ルールについての詳細は、IPTVフォーラムに問い合わせる こと。
8.1.4.2.2.8 object要素
別途、運用ルールにて規定する。運用ルールについての詳細は、IPTVフォーラムに問い合わせる こと。
8.1.4.2.3 CSS
別途、運用ルールにて規定する。運用ルールについての詳細は、IPTVフォーラムに問い合わせ ること。
8.1.4.2.4 文字符号化方式
アプリケーションエンジンは、6.1.9節に定める文字符号レパートリおよび文字符号化方式を扱え なければならない。
その他の文字符号化の扱いについては本運用規定では規定しないが、ShiftJIS、EUC-JPを扱える ことが望ましい。
8.1.4.2.4.1 文字符号化方式および文字集合 6.1.9.1、6.1.9.2節に準拠する。
8.1.4.2.4.2 他の文字符号化方式との変換
EUC-JPとUCSの変換は6.1.9.3節の規定に従う。他の文字符号化方式とUCSの変換が必要な場
合は、ARIB STD-B24 第一編 第2 部 「付録規定E UCS と8 単位符号、EUC-JP、シフトJIS の 変換ならびに拡張文字・DRCS との対応」に準拠しなければならない
8.1.4.2.5 DOCTYPEの扱い
別途、運用ルールにて規定する。運用ルールについての詳細は、IPTVフォーラムに問い合わせる こと。
8.1.4.2.6 コンテンツにおける文字符号化の指定
別途、運用ルールにて規定する。運用ルールについての詳細は、IPTVフォーラムに問い合わせる こと。
8.1.4.2.7 フォント
別途、運用ルールにて規定する。運用ルールについての詳細は、IPTVフォーラムに問い合わせる こと。
8.1.4.2.8 JavaScript
別途、運用ルールにて規定する。運用ルールについての詳細は、IPTVフォーラムに問い合わせる こと。
8.1.4.2.9 DOMインタフェース
別途、運用ルールにて規定する。運用ルールについての詳細は、IPTVフォーラムに問い合わせる こと。
8.1.4.2.10 HTML5固有のオブジェクト・メソッド
別途、運用ルールにて規定する。運用ルールについての詳細は、IPTVフォーラムに問い合わせる こと。
8.1.4.2.11 ブラウザ機能API
別途、運用ルールにて規定する。運用ルールについての詳細は、IPTVフォーラムに問い合わせ ること。
8.1.4.2.12 XML Http Request
別途、運用ルールにて規定する。運用ルールについての詳細は、IPTVフォーラムに問い合わせる こと。
8.1.4.2.13 WebSocket API
別途、運用ルールにて規定する。運用ルールについての詳細は、IPTVフォーラムに問い合わせる こと。
8.1.4.2.14 Cross Document Messaging
別途、運用ルールにて規定する。運用ルールについての詳細は、IPTVフォーラムに問い合わせる こと。
8.1.4.2.15 Web Storage
別途、運用ルールにて規定する。運用ルールについての詳細は、IPTVフォーラムに問い合わせる こと。
8.1.4.2.16 WebGL
別途、運用ルールにて規定する。運用ルールについての詳細は、IPTVフォーラムに問い合わせる こと。
8.1.4.2.17 拡張API
本節では、IPTVFJ STD-0011「3章 拡張技術仕様」に記述されたAPIについて述べる。IPTVFJ
STD-0011では、WebIDLによりインタフェース定義を行っているが、JavaScriptにバインドした
形式で実装する必要がある。各オブジェクト・メソッド・プロパティ・定数の意味に関しては特 記なき場合は参照先に従うものとする。
これらのAPIは、放送マネージドアプリケーションからのみ呼び出すことが可能である。（パ ーミッションにより禁止される場合もあり得る）
なお、本節で定義するオブジェクト・メソッド・プロパティ・定数は、特記なき場合は必須とし、
アプリケーション文書で使用可能である。
8.1.4.2.17.1 パーミッション
アプリケーションバウンダリでは、permission bitmapによりバウンダリ領域ごとに拡張APIの 実行許可を制御可能である。本バージョンではpermission bitmapの具体的な割り当ては行わず、
0x1fffもしくは0の２値で運用する。表8-3 permission bitmapとAPI対応表にpermission bitmap の値とAPIもしくは機能の使用許可の対応を示す。なお、「permission bitmapの値」欄の「○」
は使用可能、「×」は使用不可を表す。
表8-2 permission bitmapとAPI対応表 APIもしくは機能 permission bitmapの値
0x1fff 0 (0x1fff以外が指定された場合を含 む)
getOwnerApplication() ○ ○
launchDataBroadcastingBrowser() ○ ×
replaceApplication() ○ ×
destroyApplication() ○ ○
exitFromManagedState() ○ ×
keySet. setValue() ○ ×
hasCapability() ○ ○
getDeviceIdentifier() ○ ×
tuneTo() ○ ×
getCurrentEventInformation() ○ ×
isCommonEvent() ○ ×
getSystemInformation() ○ ×
setURLForCompanionDevice() ○ ×
clearURLForCompanionDevice() ○ ×
sendTextToCompanionDevice() ○ ×
getCompanionDeviceList() ○ ×
addCompanionDeviceTextMessageListener() removeCompanionDeviceTextMessageListener()
○ ×
sourceIs() ○ ×
addGeneralEventMessageListener() removeGeneralEventMessageListener()
○ ×
addEventIDUpdateListener() removeEventIDUpdateListener()
○ ×
writePersistentArray() ○ ×
readPersistentArray() ○ ×
Gregへのアクセス ○ ×