Товары в корзине: 0 шт Оформить заказ
Стр. 1 

30 страниц

623.00 ₽

Купить ГОСТ Р 57874-2017 — бумажный документ с голограммой и синими печатями. подробнее

Распространяем нормативную документацию с 1999 года. Пробиваем чеки, платим налоги, принимаем к оплате все законные формы платежей без дополнительных процентов. Наши клиенты защищены Законом. ООО "ЦНТИ Нормоконтроль"

Наши цены ниже, чем в других местах, потому что мы работаем напрямую с поставщиками документов.

Способы доставки

  • Срочная курьерская доставка (1-3 дня)
  • Курьерская доставка (7 дней)
  • Самовывоз из московского офиса
  • Почта РФ

Предназначен для применения в системе вещания ТВ-Anytime, работающей в однонаправленных и двунаправленных средах. Стандарт устанавливает параметры процесса поиска контента по ссылке. Реализация этих параметров дает возможность пользователю системы ТV-Anytime доступ к конкретному экземпляру конкретного элемента контента, повышает доступность пользователей системы ТV-Anytime к фондам видео- и аудиоматериалов в существующем медиапространстве. Реализация параметров процесса поиска контента по ссылке, установленных в стандарте, позволит повысить экономическую эффективность системы TV-Anytime.

 Скачать PDF

Оглавление

1 Область применения

2 Нормативные ссылки

3 Термины, определения, сокращения и соглашения к требованиям к синтаксису

4 Основные понятия и особенности

5 Процесс разрешения позиции

6 Параметры полномочного органа, создающего CRID

7 Идентификатор ссылки контента (CRID)

8 Форматы локаторов

9 Идентификаторы метаданных экземпляра

10 Запись разрешения органа

     10.1 Содержание записи разрешения органа

11 Протоколы разрешения позиции

     11.1 Типичные функции и интерфейсы

     11.2 Процесс разрешения позиции в однонаправленных сетях

     11.3 Процесс разрешения позиции по двунаправленным сетям

Приложение А (обязательное) Схема XML процесса поиска контента по ссылке

Приложение Б (рекомендуемое) Пример описания процесса обмена данными между PDR и удаленным сервером разрешения позиции

 
Дата введения01.08.2018
Добавлен в базу01.01.2019
Актуализация01.01.2021

Этот ГОСТ находится в:

Организации:

31.10.2017УтвержденФедеральное агентство по техническому регулированию и метрологии1588-ст
РазработанАНО НТЦИ
ИзданСтандартинформ2017 г.

Digital video broadcasting. TV-Anytime system. The process of searching for content by reference. Basic parameters

Стр. 1
стр. 1
Стр. 2
стр. 2
Стр. 3
стр. 3
Стр. 4
стр. 4
Стр. 5
стр. 5
Стр. 6
стр. 6
Стр. 7
стр. 7
Стр. 8
стр. 8
Стр. 9
стр. 9
Стр. 10
стр. 10
Стр. 11
стр. 11
Стр. 12
стр. 12
Стр. 13
стр. 13
Стр. 14
стр. 14
Стр. 15
стр. 15
Стр. 16
стр. 16
Стр. 17
стр. 17
Стр. 18
стр. 18
Стр. 19
стр. 19
Стр. 20
стр. 20
Стр. 21
стр. 21
Стр. 22
стр. 22
Стр. 23
стр. 23
Стр. 24
стр. 24
Стр. 25
стр. 25
Стр. 26
стр. 26
Стр. 27
стр. 27
Стр. 28
стр. 28
Стр. 29
стр. 29
Стр. 30
стр. 30

ГОСТР

57874—

2017

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

ТЕЛЕВИДЕНИЕ ВЕЩАТЕЛЬНОЕ ЦИФРОВОЕ. СИСТЕМА TV-ANYTIME. ПРОЦЕСС ПОИСКА КОНТЕНТА ПО ССЫЛКЕ

Основные параметры

[ETSI TS 102 822-4 VI.1.2 (2004-10), NEQ]

Издание официальное

Москва

Стандартинформ

2017

Предисловие

1    РАЗРАБОТАН Автономной некоммерческой организацией «Научно-технический центр информатики» (АНО «НТЦИ»)

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 480 «Связь»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 31 октября 2017 г. № 1588-ст

4    Настоящий стандарт разработан с учетом основных нормативных положений стандарта Европейского института по стандартизации в области телекоммуникаций (ETSI) ЕТСИ ТС 102 822-4 VI.1.2 (2004-10) «Широковещательные и онлайновые службы: поиск, выбор и законное использование контента в персональных системах хранения («TV-Anytime Phase 1»), Часть 4. Ссылки на контент» [ETSI TS 102 822-4 VI.1.2 (2004-10) «Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems («TV-Anytime Phase 1»); Part 4: Content referencing», NEQ]

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомления и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ, 2017

Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Федерального агентства по техническому регулированию и метрологии

В примере, представленном в таблице 9.4, часть имени была исключена из идентификатора метаданных экземпляра, так как оно имеет имя органа CRID. В этом примере идентификатор «imi: 1» будет соответствовать записи "imi: example.net/1".

Таблица 9.4 — Пример идентификатора метаданных экземпляра с исключенной частью имени

CRID

Позиция

Идентификатор

crid://example. net/abcl 23

dvb://123.5ac. 100; 1 е4а@2001-12-07Т15:00:00.00+01 Р02:10

imi: 1

ftp://example. net/mirror/defl 23. mov

imi:2

В таблице 9.5 показан набор допустимых комбинаций CRID и идентификатора метаданных экземпляра.

Таблица 9.5 — Набор допустимых комбинаций CRID и идентификатора метаданных экземпляра

CRID

Позиция

Идентификатор метаданных экземпляра

При

мечание

crid://example. net/abcl 23

dvb://123.5ас. 100; 1 е4а@2001 -12-07Т15:00:00.00 +01Р02:10

imi: 1

i

ftp://example. net/mirror/defl 23. mov

imi:2

crid://example. net/je98

dvb://123.6ef.200;5e23@2002-01-31T14:20: 00.00+01P00:30

imi:mdprov.com/01

2

dvb://123.6ef.200; 1 c24@2002-02-14T14:20: 00.00+01P00:30

imi:mdprov.com/02

crid://example. net/ja90

dvb://2a3.faa.100;8ee9@2002-01-29T01:20: 00.00+01P01:30

imi:mdprov.com/01

3

dvb://c01 ,ad3.400;003c@2002-02-14T18:00: 00.00+01P01:00

imi:mdprov.com/02

crid://broadcaster.co.uk/0203

dvb://c01 ,ad3.400;003c@2002-02-14T1 imi: 18:00:00.00+01P01:00

imi: 1

4

imi:mdprov.com/01

Примечания

1    Разрешение на CRID "CRID: //example.net/abc123" с двумя идентификаторами метаданных экземпляра. Идентификатор метаданных экземпляра без имени не предусмотрен, поэтому используется орган CRID "example.net".

2    Разрешение на CRID "CRID: //example.net/je98" с двумя идентификаторами метаданных экземпляра. В этом примере был указан идентификатор метаданных экземпляра провайдера "mdprov.com".

3    Также как и в предыдущих двух примерах, показывающих разрешение на CRID к двум позициями со связанными идентификаторами метаданных экземпляра. Следует отметить, что этот пример использует те же идентификаторы, что и в предыдущем примере. Идентификаторы метаданных экземпляра снимают неоднозначность CRID.

4    Этот пример показывает, что два различных идентификатора метаданных экземпляра назначаются на тот же CRID и позицию. Это разрешено только потому, что применяются идентификаторы от разных идентификаторов провайдеров.

10 Запись разрешения органа

Запись разрешения органа (Resolving Authority Record, RAR) содержит информацию, необходимую для получения данных разрешения позиции для данного органа в однонаправленных и двунаправленных сетях.

В PDR должно быть не менее одной записи разрешения каждого органа. Каждая запись разрешения органа в PDR должна размещаться в транспортном контейнере, который информирует PDR о наличии записи разрешения органа.

ГОСТ P 57874—2017

При наличии нескольких записей одного и того же органа для каждого разрешения позиции PDR для обработки может использовать любую из записей.

10.1 Содержание записи разрешения органа

Настоящий стандарт определяет информацию, которая должна содержаться в кодированной записи разрешения органа (RAR) и не определяет формат передачи RAR в однонаправленных сетях. Формат передачи RAR для двунаправленного процесса передачи ссылки контента по протоколу TCP/IP указан в 11.3.

RAR, совместимая cTV-Anytime, должна содержать следующие элементы информации:

Resolution Provider (провайдер разрешения): название структуры, которая обеспечивает разрешение позиции. Допускается обеспечивать разрешение позиции различным структурам для одного органа, например, для создателя контента. Эти провайдеры разрешения позиции должны идентифицироваться для обновления их записей разрешения. Имя провайдера разрешения позиции выполняется по правилам, приведенным в разделе 7;

Authority name (имя органа): имя органа CRID системы TV-Anytime должно быть в соответствии с разделом 6;

Class (класс): определяет уровень органа разрешения CRID, если RAR содержит разрешения для всех CRID, то этот орган относится к первом классу, а если RAR определяет разрешения только для некоторых CRID, то этот орган относится ко второму классу;

Version number (номер версии): число, которое увеличивается при обновлении провайдером разрешения своих записей для данного имени органа. Записи органа, которые должен обновлять PDR, содержат сочетания имени органа и провайдера разрешения. При получении провайдером разрешения нового номера версии для органа все старые записи разрешения органа для этого имени органа в комбинации с провайдером разрешения PDR должен отбросить. После того как номер версии достигнет значения 232-1, следующим номером версии должен быть нуль. Таблицы считаются эквивалентными, если они имеют одинаковые значения провайдера разрешения, имени органа, номера версии и URL;

URL (унифицированное расположение ресурса): URL может указывать на поток вещания, или на сервер в Интернете, или на любое другое место, где может быть найдена информация о разрешении позиции. Синтаксис URL должен быть в соответствии с разделом 8;

First valid date (первая допустимая дата): означает дату, начиная с которой может использоваться разрешение органа;

Last valid date (последняя допустимая дата): означает дату, когда разрешение органа уже не может использоваться. Формы представления полей First valid date и Last valid date должны однозначно определять временную зону. Обоснованием целесообразности представления дат начала и окончания разрешения является необходимость обеспечения возможности провайдерам разрешения контроля перемещения своих URL разрешений и необходимость контроля за переключением всех PDR на новый URL после окончания последней допустимой даты старой записи разрешения;

Weighting (значимость): используется для стимулирования выполнения PDR проверки множественных записей органа одного и того же провайдера разрешения путем предоставления наибольшего значимого значения URL, которое должно быть использовано в первую очередь. Поле «значимость» используется только для упорядочения записей провайдера разрешения для одного и того же сочетания провайдера разрешения и имени органа.

В таблице 10.1 представлен пример записи разрешения органа.

Таблица 10.1 — Пример записи разрешения органа

Имя поля

Содержание поля

Class (класс)

Второй класс

Weighting (значимость)

1

First valid date (первая допустимая дата)

9:30 26 Сентября 2000

Last valid date (последняя допустимая дата)

6:00 26 Ноября 2000

Resolution Provider (провайдер разрешения)

tva.resprov.com

Имя поля

Содержание поля

Authority name (имя органа)

autnam.com

URL

http://www.resprov.com/lr/autnam

11 Протоколы разрешения позиции

11.1 Типичные функции и интерфейсы

В данном подразделе определяются характеристики функций, обеспечивающих разрешение позиции при использовании однонаправленных или двунаправленных сетей.

В среде системы TV-Anytime служба поиска контента по ссылке может быть предоставлена через такие системы доставки, как сети IP или вещательное телевидение.

На рисунке 11.1 показана архитектура модульной системы разрешения CRID, включающая нескольких обработчиков разрешения, отвечающих требованиям конкретных транспортных механизмов разрешения позиции.

Рисунок 11.1 —Архитектура модульной системы разрешения CRID

Представленная архитектура обеспечивает выполнение разрешения несколькими обработчиками разрешения при условии прозрачности сетей, предоставляющими разрешение, зависимое от сети и от протокола разрешения CRID. Например, один метод решения разрешения CRID для разрешения позиции контента на местном уровне сотрудничает с системой управления местного хранения, хранящегося на местном уровне. Другой метод разрешения выполняет разрешения CRID через внешние системы обработки имени, используя обратный канал или подключение к сети Интернет. В третьем методе система может ссылаться на таблицы системной информации (SI), которые содержат таблицы отображения соответствия CRID и локаторов и транспортируются в цифровом потоке вещания.

Ниже описаны этапы процесса поиска контента по ссылке:

1)    CRID поступает в систему разрешения для определения обработчиков, которые должны быть активизированы для разрешения этого CRID;

2)    запрос разрешения направляется на соответствующие обработчики;

3)    каждый обработчик пытается разрешить или позицию CRID, или набор других CRID. Процесс разрешения определяется реализацией конкретного обработчика. В процессе разрешения обработчик должен связаться с внешней системой.

Ниже приведены примеры процессов, происходящих между обработчиком и внешней системой:

-    разрешение CRID выполняется использованием таблицы отображения, расположенной в PDR. Этот метод пригоден для контента, записанного на местном уровне, или для информации, кэшированной из сетей IP или вещательной передачи;

-    разрешение CRID выполняется использованием потока вещания;

-    разрешение CRID выполняется через Интернет или обратный канал.

ГОСТ P 57874—2017

11.2 Процесс разрешения позиции в однонаправленных сетях

В этом подразделе определены общие функции обработчиков, работающих с однонаправленными сетями. Каждый обработчик, использующий однонаправленную сеть, выполняет операции, описанные ниже.

Первым шагом в процессе разрешения позиции для PDR в однонаправленной сети является определение информации о разрешении позиции. Эта позиция предоставляется записью органа разрешения, которая передается к PDR в процессе вещания. Сбой в процессе поиска записей органа приведет к отказу разрешения CRID. При обнаружении записи разрешения органа PDR получает информацию о способе прослушивания информации о позиции данных органа CRID (при использовании поля URL записи соответствующего органа).

PDR должен будет выбрать обработчика, способного работать с протоколами, переносящими информацию о разрешении позиции.

Например, PDR выберет обработчика DVB, если запись разрешения сообщает, что информация о разрешении отправляется в транспортном потоке DVB.

Или реализация PDR будет использовать местного обработчика в случае, если контент, к которому обращается CRID, доступен уже на местном уровне.

Информация, передаваемая в однонаправленном потоке разрешения позиции, должна иметь форму таблицы, которая включает CRID с отображениями сообщений. Каждый входящий CRID приведет к выводу сообщения, которое должно содержать поле статуса. Если поле статуса содержит значение, указывающее, что ввод CRID действителен, то сообщение должно содержать не менее одного CRID или не менее одной позиции.

Сообщение


CRID


Однонаправленный поток разрешений позиции должен содержать поток соответствующих пар, приведенный на рисунке 11.2.

Рисунок 11.2 — Поток соответствующих пар

Каждое сообщение в указанной паре должно содержать информацию разрешения позиции в однонаправленной системе, в формате, представленном в таблице 11.1.

Таблица 11.1 —Формат информации сообщения разрешения позиции в однонаправленной системе

Поле

Описание

Status

(«Статус»)

Три состояния поля:

-    "CRID is resolved" («CRID разрешен») — следует список разрешений;

-    "discard CRID" («игнорируйте CRID») — например, CRID больше не действителен;

-    "resolve after date <ххх>" («разрешен после даты») — CRID разрешен после даты <ххх>

Поле "Status" соответствует "CRID is resolved"

Acquisition directive

(«Директива

приобретения»)

Два состояния поля:

-    "АН" («все») — должны быть получены все элементы следующего списка;

-    "Any" («любой») — может быть получен любой элемент следующего списка, поскольку элементы списка являются альтернативными позициями для одного и того же контента

A list of CRIDs or a list of Locator(s) («Список CRID или список позиций»)

CRID будут соответствовать синтаксису, данному в разделе 7.

Позиции будут соответствовать синтаксису в соответствии с разделом 8. Опционально каждая позиция может иметь ассоциированный идентификатор метаданных экземпляра

Resolution complete («Разрешение полное»)

Два состояния поля:

-    "Yes" («да») — список заполнен, CRID полностью разрешен, например, это последний эпизод в серии;

-    "No" («нет») — список не заполнен, CRID может разрешить другие элементы позднее

Re-resolution date («Дата повторного разрешения (перераз решения)»)

Дата, после которой PDR следует пытаться повторно разрешить CRID. Это поле имеет смысл, только если флаг поля «Разрешение полное» установлен на «нет». Эта дата должна быть однозначной по отношению к часовому поясу

11

Поле

Описание

Поле "Status" соответствует "resolve after date <ххх>"

Date

(«Дата»)

Дата и время, на которые или после которых PDR должен попытаться повторно разрешить CRID. Это поле должно быть однозначным относительно часового пояса

Таблица 11.2 содержит интерпретацию состояния флагов, выполняемую PDR.

Таблица 11.2 — Интерпретация состояния флагов, выполняемая PDR

Состояние флагов для полей

Описание

Acquisition directive

Resolution complete

All

No

Приобретение всех элементов в списке и ожидание новых

(«все»)

(«нет»)

элементов

All

Yes

Приобретение всех элементов контента, после чего при-

(«все»)

(«да»)

обретение для этого CRID завершается

Any

No

Выбор любого элемента из текущего списка (после этого

(«любой»)

(«нет»)

приобретение завершено) или ждать дополнения в список

Any

Yes

Выбор любого элемента списка, после этого приобрете-

(«любой»)

(«да»)

ние завершается

11.2.1 Руководство по использованию флагов состояния разрешения

При наличии разрешения, определенного директивой приобретения "АП", CRID преобразуется в один или несколько CRID. При флаге полного разрешения, установленного в "No", контент может группироваться, если он изменяется в течение длительного времени, например, на интервале сериала. CRID такой группы может оставаться действительным в течение длительного времени, если у сериала отсутствует запланированное окончание. PDR может позволить пользователю просматривать контент, который PDR получил для CRID неполной группы.

CRID, разрешающий одну или несколько позиций, не должен использоваться для непрерывно продолжающейся группы (такой как сериал), так как PDR предположит, что, если директива получения устанавливается в "АП", то ему необходимо получить все части контента, определенные списком позиций прежде, чем этот контент будет полностью получен для просмотра пользователем. В таблице 11.3 показаны варианты поведения PDR в ответ на директиву приобретения.

Таблица 11.3 — Варианты поведения PDR в ответ на директиву приобретения

Тип разрешения

Acquisition directive

Описание поведения PDR

CRID к

All

Должны быть приобретены все CRID. Каждый из этих

нескольким CRID

(«все»)

CRID можно рассматривать или как CRID элемента контента, или как CRID части группы

CRID к

Any

Могут быть приобретены любые результирующие CRID,

нескольким CRID

(«любой»)

так как они равноценны CRID, созданному органом

CRID к нескольким рас-

All

Все элементы должны быть приобретены до окончания

положениям

(«все»)

контента. Это зависит от реализации PDR: будет ли PDR разрешать просмотр неполного контента

CRID к нескольким по-

Any

Допускается выбор любой позиции, так как они равноцен-

зициям

(«любой»)

ны CRID, созданному органом

Этот вариант поведения PDR реализуется опционально в том случае, когда PDR для разрешения позиции будет работать не только с однонаправленным потоком, но и с местным механизмом кэширования. Этот механизм может кэшировать разрешенные CRID или в необходимых случаях кэшировать однонаправленный поток. Кэшированная информация может быть использована обработчиком

ГОСТ P 57874—2017

однонаправленного потока или другим обработчиком, который использует местные кэшированные данные.

11.3 Процесс разрешения позиции по двунаправленным сетям

Для того чтобы PDR мог использовать службы разрешения позиции, в двунаправленных сетях определяется протокол, позволяющий PDR инициировать соединение и выполнение обмена со службой разрешения, размещенной на удаленном сервере.

В данном подразделе описывается способ, с помощью которого PDR может обнаружить местонахождение такого сервера в двунаправленной сети и протокола TV-Anytime для достижения соответствующей передачи данных TV-Anytime по такой сети.

В этом подразделе не определяются правила извлечения контента из двунаправленной сети.

11.3.1 Поиск сервера разрешения в двунаправленной сети. Общие вопросы

Параметры данного этапа поиска не обязательны для всех реализаций сети.

Первым шагом процесса разрешения CRID является поиск сервера, который может разрешить этот CRID. Процесс обнаружения сервера основан на использовании имени органа CRID.

Предполагается, что PDR впервые выполняет операцию разрешения CRID от органа и что у PDR нет предварительных сведений о способе получения разрешения этого CRID.

В конкретной реализации PDR может быть выполнено кэширование предыдущих открытий сервера, но точные характеристики этого кэширования зависят от реализации PDR.

На рисунке 11.3 показан пример процесса обнаружения удаленного сервера разрешения позиции.

Пользователь    Промежуточный    Удаленный сервер

(PDR)    сервер    разрешения    позиции

Процесс

поиска

/

Запрос имени органа CRID

удаленного

сервера

разрешения

позиции

Адрес удаленного сервера разрешения позиции

к

/

<CRID>

Процесс

разрешения

позиции

Локаторы или CRID

к

Ассоциированные метаданные (опционально)

Рисунок 11.3 — Пример процесса обнаружения удаленного сервера разрешения позиции

11.3.2 Запрос сервера разрешения в двунаправленной сети

После обнаружения сервера разрешения следующим шагом процесса является установление связи с этим сервером. Данные, передаваемые на вход сервера, должны содержать список CRID для разрешения и флаги для указания способа формирования ответа.

В TV-Anytime определены следующие флаги:

1)    SubmittedCRID;

2)    Result (Результат).

В таблицах 11.4 и 11.5 представлена семантика флагов SubmittedCRID и Result.

Таблица 11.4 — Семантика флага SubmittedCRID

Значение флага SubmittedCRID

Описание

0

Представляемые метаданные по CRID, не относящиеся к описательным метаданным, не должны возвращаться с информацией о разрешении

13

Значение флага SubmittedCRID

Описание

1

Экземпляры схем таблиц Programlnformation или Grouplnformation, которые описывают представляемые CRID, должны быть возвращены, если у сервера разрешения Location эта информация есть

Все другие значения

Зарезервированы

Таблица 11.5 — Семантика флага Result

Значение флага Result

Описание

0

Представляемые метаданные по CRID, не относящиеся к описательным метаданным, не должны возвращаться с информацией о разрешении

1

Если представленный CRID разрешает дополнительные CRID, то экземпляры схем ProgramlnformationTable или GroupInformationTable должны быть возвращены для каждого разрешенного CRID, если сервер разрешения позиции имеет эту информацию.

Если представленный CRID разрешает позицию, то экземпляры схемы ProgramLocationTable должны быть возвращены для каждой пзиции, если сервер разрешения позиции имеет эту информацию

Все другие значения

Зарезервированы

Если флаги отсутствуют, то принимается значение флага Result, равное нулю.

11.3.3    Ответ сервера разрешения по двунаправленной сети

Сервер разрешения отреагирует на запрос одним из трех возможных видов информации:

1)    результат разрешения CRID. Ответ будет содержать не менее одного экземпляра схем XML, определенных в ГОСТ Р 56476 и в приложении А к настоящему стандарту;

2)    запись разрешения органа. PDR должен сохранить эту RAR при использовании правил, приведенных в описании однонаправленной модели, и затем связаться с сервером в соответствии с полем URL в RAR;

3)    перенаправление. Сервер разрешения возвращает сообщение, содержащее адрес другого сервера разрешения позиции.

В случаях 1) и 3), когда PDR не получает RAR, он должен исходить из того, что сервер разрешения позиции относится к серверу основного класса и что необходимо следовать соответствующим правилам, данными в настоящем стандарте для сервера разрешения основного класса.

Допустимыми экземплярами элементов схем XML, определенных в приложении А к настоящему стандарту, являются:

-    GroupInformationTable;

-    ProgramlnformationTable;

-    ProgramLocationTable;

-    ContentReferencingTable.

Когда экземпляр документа XML возвращается сервером разрешения позиции, экземпляр ContentReferencingTable, который содержат CRIDResult или LocationsResult для каждого представленного CRID, должен быть возвращен. Когда индицируются флаги SubmittedCRID и Result, экземпляры GroupInformationTable, ProgramlnformationTable и ProgramLocationTable также могут быть возвращены.

Результаты могут возвращаться сервером в любом порядке, определенном сервером разрешения позиции.

11.3.4    Динамика поведений PDR и сервера разрешения позиции

Перегрузки сервера разрешения позиции могут быть вызваны попытками установления связи одновременно несколькими PDR. Поэтому при формировании ответа сервера о разрешении CRID в более позднее время желательно не передавать всем клиентам, запрашивающим этот CRID, одинаковую информацию о времени и дате, для того чтобы они не начали одновременно попытки установления связи с сервером.

14

ГОСТ P 57874—2017

С целью уменьшения возможной перегрузки сервера PDR должен уменьшать перегрузку сервера разрешения позиции частыми попытками повторного доступа к одному и тому же серверу.

11.3.4.1 Требования к режиму работы PDR

1)    После получения даты и времени повторного запроса разрешения PDR должен устанавливать контакт с сервером разрешения позиции через интервал времени случайной продолжительности. Это позволит уменьшить вероятность возникновения конфликтов при запросах сервера разрешения позиции несколькими PDR.

2)    Если сервер разрешения позиции возвратит время и дату повторного запроса разрешения в прошедшем времени, то PDR должен выждать интервал времени случайной продолжительности, прежде чем начинать связываться с сервером разрешения позиции.

3)    Если сервер разрешения позиции недоступен, то PDR должен отложить ответ разрешения для CRID на более поздний срок. Дата и время повторного разрешения определяются по текущей дате и времени плюс интервал времени случайной продолжительности.

4)    Если сервер разрешения позиции второго класса возвращает информацию и указывает, что CRID неизвестен, то повторный запрос PDR этому серверу должен повториться через интервал времени случайной продолжительности.

5)    Когда сервер разрешения позиции первого класса возвращает информацию и указывает, что CRID неизвестен, то PDR должен прекратить попытки разрешения этого CRID как неразрешаемые.

6)    Генераторы случайного интервала времени в PDR конкретного производителя не должны формировать одинаковые случайные последовательности временного интервала. Тестирование соответствия этому требованию настоящим стандартом не предусматривается.

7)    Стандартное отклонение временного интервала генератора этого интервала должно быть не менее 10 минут. Проверки соответствия этому требованию настоящим стандартом не предусматриваются.

11.3.5 Обнаружение сервера разрешения в сети с протоколами TCP/IP

<DNS пате> как часть имени органа является зарегистрированным доменным именем в Интернете, механизмы поиска имени DNS могут использоваться как часть этапа обнаружения сервера. На рисунке 11.4 представлен пример процесса обнаружения сервера разрешения позиции в сети с протоколами TCP/IP.

Пользователь    Авторитетный    Удаленный    сервер

(PDR)    сервер    DNS    разрешения    позиции

для домена хххх

/

Запрос имени органа

Т

Процесс

поиска

Имя хоста удаленного

[■ SRVr

удаленного

сервера

разрешения

позиции

Имя хоста удаленного

J

1 Стандартный у запрос имени хоста [ для IP-адреса

IP-адрес удаленного сервера

к

/

<CRID>

Процесс

разрешения

Локаторы или

позиции

к

Ассоциированные метаданные (опционально) 1

Рисунок 11.4 — Пример процесса обнаружения сервера разрешения позиции в сети с протоколами TCP/IP

11.3.5.1 Служба запроса открытия DNS через Интернет

Расширенный запрос открытия DNS выполняется методом распределения нагрузки (RR DNS) использованием избыточного количества серверов с помощью управления ответами сервера DNS в соответствии со статистической моделью.

15

Устройства, подключенные к сети Интернет, используются для поиска почтовых серверов. В дополнение к возможности поиска записей почтового обмена (Mail exchange, MX) обеспечивается возможность поиска службы записи (Search forseRVice, SRV).

Запрос, совместимый с методом RR DNS, состоит из нескольких частей, а именно:

_Service._Protocol.Name

Например, запрос для сервера HTTP example.com будет выглядеть как: "_http._tcp.example.com". Сервер DNS ответит именем хоста и номером порта, соответствующим расположению сети, в которой может быть найдена запрашиваемая служба. В приведенном выше примере может быть возвращено сообщение: "webserver2.example.com порт 80".

11.3.5.2 Запрос службы разрешения позиции в системе TV-Anytime

Имя службы разрешения позиции в системе TV-Anytime — "Ires", является аббревиатурой "location resolution". Использование аббревиатуры в качестве имени принято в связи с тем, что ответ DNS в некоторых реализациях клиентских DNS ограничен 512 символами.

Полное название запроса будет выглядеть так:

_lres. tcp.cCRID authority>

Например, с учетом CRID "CRID://europe.example.com/9afc2" строка запроса будет "_lres._tcp. europe.example.com", которая будет направлена на сервер DNS, который обеспечивает просмотр для "europe.example.com".

Другой пример приведен с учетом CRID "CRID://example.co.uk/9afc2", строка запроса будет "_lres._ tcp.example.co.uk", которая будет направлена на сервер DNS, что обеспечивает поиск для "example. co.uk".

11.3.6 Запрос к серверу разрешения на основе протоколов TCP/IP

Протокол запроса сервера разрешения позиции основан на протоколе HTTP. Формат строки запроса должен создаваться представлением формы HTML, используя запрос GET:

http://<Path_to_server_script>?[key=value]&[key=value],

где пара "key=value" повторяется по мере необходимости.

Ключ (key) чувствителен к регистру и должен быть представлен с использованием точного регистра для каждого ключа, как указано в данном разделе.

Спецификация кодирования пар "key=value" в URL HTTP для провайдера служб разрешения позиции является опциональной, предназначенной для реализации этой службы, с возможностью использования любой технологии на стороне сервера (сценарии CGI, сервлеты Java и т. п.).

Описания ключей и их допустимые значения для кодирования URL должны быть в соответствии с представленными в таблице 11.6.

Таблица 11.6 — Описания ключей и их допустимые значения для кодирования URL HTTP

Ключ

Описание

Допустимое значение

CRID

CRID для разрешения

"CRID"

SubmittedCRID

Используется для определения необходимости разрешения метаданных на CRID

См. таблицу 11.4

Result

Указывает на необходимость метаданных для каждого результата разрешения этого CRID

См. таблицу 11.5

Эта спецификация допускает разрешение нескольких CRID в одном запросе HTTP с помощью нескольких ключей "CRID" в URL, однако ключи "SubmittedCRID" и "Result" в запросе могут быть указаны только один раз.

Первое подключение сервера разрешения позиции после фазы определения позиции на основе сервера DNS <path to server> определяется именем хоста, символом двоеточия, текстовым представлением номера порта, косой чертой. Если номер порта 80, то двоеточие и номер порта могут быть опущены.

Например, если бы сервер DNS возвратил имя хоста "computer2.example.com" на порт 1234, то <path to server> («путь к серверу») был бы:

computer2.example.com: 1234/

ГОСТ P 57874—2017

Когда сервер разрешения позиции обеспечивает перенаправление, используя перенаправление HTTP, то <path to server> («путь к серверу») указывает URL, возвращенный заголовком "Location" («позиция») для ответа перенаправления HTTP.

Например, если ответ HTTP был:

location http://redirect.example.com/tva/lr, то <path to server> (путь к серверу) был бы:

redirect.example.com/tva/lr.

Когда сервер разрешения позиции обеспечивает перенаправление, используя RAR, то <path to server> («путь к серверу») отображается полем URL от RAR.

Например, если поле URL RAR содержало значение:

http://kaas.example.nl/scripts/resolution.cgi, то <path to server> («путь к серверу») был бы:

kaas.example.com/scripts/resolution.cgi

Примеры правильных полных адресов URL:

-    http://computer2.example.com:1234/?CRID="crid://example.com/abc123";

-    http://broadcaster.com/?CRID="crid://broadcaster.com/abc123"&CRID="crid://broadcaster.com/ def456";

-    http://kaas.example.com/scripts/resolution?CRID="crid://example.com/abc123"& Result=1;

-    http://redirected.example.com/tva/lr?CRID="crid://example.com/abc123"& SubmittedCRID=1.

11.3.6.1    Дополнительные требования к PDR

PDR должен использовать спецификацию HTTP версии 1.0 для направления запроса GET к серверу. В дополнение к требованиям HTTP версии 1.0 PDR отправляет заголовок HTTP версии 1.1 "host" и заголовок HTTP версии 1.0 "user-agent".

Клиент HTTP в PDR должен поддерживать тип MIME:

text/xml.

Пример — Клиенту HTTP необходимо отправить команду приема следующего компонента:

Accep:text/xml.

Для обеспечения безопасной передачи запросов разрешения от PDR до сервера разрешения позиции и получения защищенных результатов сервера разрешения позиции PDR и сервер разрешения позиции могут согласовать применение безопасного протокола HTTP. Потокол HTTPS является расширением протокола HTTP. Для повышения безопасности он дополняет протокол HTTP криптографическими протоколами SSL или TLS. При согласовании протокола HTTPS PDR и сервер разрешения позиции должны согласовывать тип крипографического протокола: SSL или TLS.

Если PDR будет поддерживать декодирование закодированного ответа от сервера разрешения (например, распаковывающий компрессированный ответ), то PDR должен указать на это, отправляя заголовок HTTP "Accept-Encoding".

11.3.7 Ответ от сервера разрешения по протоколу TCP/IP

Ответ от сервера разрешения позиции основан на спецификации HTTP версии 1.0 и может быть выполнен в одном из трех вариантов:

1)    Результат разрешения CRID передан на сервер.

2)    Перенаправление HTTP, позволяющее распределение служб среди множества машин.

3)    Стандартная запись разрешения органа (RAR) для облегчения кэширования PDR, балансировка загрузки сервера, динамичное администрирование сервера и возможности межплатформенной поддержки.

Применение типа MIME в заголовке HTTP "Content-Type" позволяет указать, какой из двух возможных ответов сервера (тип 1 или тип 3) должен возвращаться.

11.3.7.1    Случай 1: Возвращение результата разрешения нескольких CRID

Если ответом от сервера разрешения позиции будет результат разрешения нескольких CRID, которые затребовал PDR, то должны быть возвращены экземпляры контента, ссылающиеся на схему XML.

17

ГОСТ P 57874—2017

Содержание

1    Область применения..................................................................1

2    Нормативные ссылки..................................................................1

3    Термины, определения, сокращения и соглашения к требованиям к синтаксису.................2

4    Основные понятия и особенности.......................................................2

5    Процесс разрешения позиции..........................................................4

6    Параметры полномочного органа, создающего CRID........................................4

7    Идентификатор ссылки контента (CRID)..................................................4

8    Форматы локаторов...................................................................5

9    Идентификаторы метаданных экземпляра................................................6

10    Запись разрешения органа............................................................8

10.1    Содержание записи разрешения органа.............................................9

11    Протоколы разрешения позиции......................................................10

11.1    Типичные функции и интерфейсы..................................................10

11.2    Процесс разрешения позиции в однонаправленных сетях..............................11

11.3    Процесс разрешения позиции по двунаправленным сетям.............................13

Приложение А (обязательное) Схема XML процесса поиска контента по ссылке.................19

Приложение Б (рекомендуемое) Пример описания процесса обмена данными между PDR

и удаленным сервером разрешения    позиции..................................25

Тип MIME, возвращаемый сервером разрешения позиции, должен быть text/XML.

Пример — Одна из строк ответа от сервера HTTP будет:

Content-Type: text/xml.

11.3.7.2    Случай 2: Возвращение перенаправления HTTP

Команды перенаправления HTTP (коды ошибки HTTP 300—399) могут использоваться сервером разрешения позиции, чтобы указать, что PDR должен с ним разъединиться и соединиться с другим сервером разрешения позиции. Необходимость обеспечения этой функции заключается в том, чтобы провайдер разрешения позиции мог перенаправить запросы разрешения на разрешение CRID не только на имя органа, которое может быть повторно направлено на этапе поиска DNS разрешения CRID.

Заголовок ответа "location" («позиция») должен использоваться для указания адресата, с которым PDR должен связаться.

Пример —Location: http://www.example.com/tvaresolve.

Если PDR был перенаправлен от своего первоначального сервера разрешения позиции, то он должен обеспечить заголовок "referer" HTTP версии 1.0, содержащий расположение сервера, от которого он был перенаправлен на новый сервер.

11.3.7.3    Случай 3: Возвращение разрешения записи органа

В случае возврата записи разрешения органа тип MIME должен быть text/xml и ответ должен состоять из экземпляра ResolvingAuthorityRecordTable, соответствующего синтаксису, определенному в А.1.2.

11.3.7.4    Кодирование ответа сервера

Ответ от сервера допускается кодировать компрессированием или шифрованием документа экземпляра XML. Заголовок ответа "Content-Type" не изменяется, а поле "Content-Encoding" определяет форму кодирования данных. Точная форма применяемого кодирования в настоящем стандарте не определена, согласование систем кодирования является обязанностью клиента и сервера HTTP.

Примеры

Content-Type: text/xml.

Content-Encoding: x-zip

18

ГОСТ Р 57874-2017

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ТЕЛЕВИДЕНИЕ ВЕЩАТЕЛЬНОЕ ЦИФРОВОЕ.

СИСТЕМА TV-ANYTIME.

ПРОЦЕСС ПОИСКА КОНТЕНТА ПО ССЫЛКЕ

Основные параметры

Digital video broadcasting. TV-Anytime system.

The process of searching for content by reference. Basic parameters

Дата введения — 2018—08—01

1    Область применения

Настоящий стандарт предназначен для применения в системе вещания TV-Anytime, работающей в однонаправленных и двунаправленных средах. Настоящий стандарт устанавливает параметры процесса поиска контента по ссылке. Реализация этих параметров дает возможность пользователю системы TV-Anytime доступа к конкретному экземпляру конкретного элемента контента, повышает доступность пользователей системы TV-Anytime к фондам видео- и аудиоматериалов в существующем медиапространстве.

Реализация параметров процесса поиска контента по ссылке, установленных в настоящем стандарте, позволит повысить экономическую эффективность системы TV-Anytime.

2    Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ Р 52210 Телевидение вещательное цифровое. Термины и определения

ГОСТ Р 56476 Телевидение вещательное цифровое. Система TV-Anytime. Схемы метаданных. Основные параметры

Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.

Издание официальное

3    Термины, определения, сокращения и соглашения к требованиям к синтаксису

3.1    В настоящем стандарте применены термины по ГОСТ Р 52210, а также следующие термины с соответствующими определениями:

3.1.1    агрегатор (aggregator): Объект (организация), собирающий и обрабатывающий информацию о контенте, службах и их провайдерах.

3.1.2    контент (content): Видео- и аудиофайлы (фильмы, игры, ТВ-программы, радиопрограммы, видеоклипы, аудиотреки), к которым клиент хотел бы получать доступ и которые могут быть сохранены на персональном цифровом рекордере (PDR).

3.1.3    идентификатор метаданных экземпляра (instance metadata identifier): Идентификатор, ассоциированный с локатором и связанный с метаданными описания экземпляра.

3.1.4    локатор (locator): Время и место, где может быть получен элемент контента.

3.1.5    метаданные (metadata): Данные о контенте (заголовок, жанр и резюме телевизионной программы, а также профиль потребителя и данные предыстории).

3.1.6    обработчик разрешения (resolution handler): Функциональный блок, который обеспечивает выполнение разрешения позиции на конкретном механизме транспортировки.

3.1.7    орган (организация) (authority): Организация, создающая CRID.

3.1.8    расположение (позиция) (location): Адрес расположения экземпляра контента (место и время), по которому экземпляр контента может быть найден.

3.1.9    провайдер контента (content provider): Объект, который предоставляет контент или услуги PDR.

3.1.10    провайдер служб (service provider): Агрегатор и поставщик контента, который может выполнять функции управления и шлюза.

3.1.11    разрешение расположения (позиции) (location resolution): Процесс установления адреса (места и времени) конкретного экземпляра контента по его CRID.

3.1.12    сервлет Java (Java servlet): Java-программа, программа на сервере.

3.1.13    ссылка на контент (content reference): Ссылка (указатель) на конкретный элемент контента.

3.1.14    сценарий CGI (Common Gateway Interface script): Внешнее приложение, выполняемое сервером HTTP на запрос пользователя, например, веб-браузера.

3.1.15    хост (host): Конечный узел отправителя и получателя информации в сети передачи данных.

3.2    В настоящем стандарте приняты следующие сокращения:

CRID (Content Reference IDentifier) — идентификатор ссылки (адреса) контента;

GET — запрос GET, используется для запроса содержимого указанного ресурса по протоколу HTTP;

HTTP (HyperText Transfer Protocol) — протокол передачи гипертекста;

HTTPS (Hypertext Transfer Protocol Secure) — расширение протокола HTTP;

MIME (Multipurpose Internet Mail Extensions) — многоцелевые расширения интернет-почты;

PDR (Personal Digital Recorder) — персональное цифровое записывающее устройство;

RAR (Resolving Authority Record) — запись разрешения органа;

SSL (Secure Sockets Layer) — уровень защищенных сокетов;

TLS (Transport Layer Security) — защищенный транспортный уровень;

URI (Uniform Resource Identifier) — унифицированный идентификатор ресурса;

URL (Uniform Resource Locator) — унифицированный локатор ресурса.

3.3    В настоящем стандарте приняты следующие соглашения к требованиям к синтаксису:

3.3.1    синтаксис определяется для различных текстовых элементов;

3.3.2    элементы, выделенные полужирным шрифтом: текстовые символы, которые должны использоваться в точности с определением;

3.3.3    элементы, выделенные <угловыми скобками и курсивом> заменяются соответствующим значением, которое определено рядом с определением синтаксиса;

3.3.4    элемент в квадратных скобках ("[" и "]") является необязательным элементом. Все определения синтаксиса в границах квадратных скобок могут быть опущены при условии соблюдения правил, указанных в настоящем стандарте.

4    Основные понятия и особенности

Процесс поиска контента по ссылке начинается после того, как потребителем был выбран элемент контента. На рисунке 4.1 показано содержание процесса поиска контента по ссылке. Некоторые части, не входящие в состав процесса поиска контента по ссылке, показаны на рисунке 4.1 для того, чтобы придать этому процессу глобальный контекст.

2

ГОСТ P 57874—2017

Поиск и отбор контента

Потребляемый

контент

Рисунок 4.1 —Содержание процесса поиска контента по ссылке

Процесс поиска контекта по ссылке включает в себя три нижеперечисленные процедуры:

-    отбор необходимого контента с последующим получением ссылки идентификатора контента (CRID);

-    поиск службы разрешения на получение позиции контента, которая позволит найти одну или несколько позиций экземпляров контента или идентификаторов ссылки контента;

-    поиск контента в найденных позициях для последующего приобретения контента.

В процессе отбора должен быть определен CRID. CRID идентифицирует конкретный элемент контента (но не указывает его позицию). Детализированные характеристики контента, такие как цена, качество, присутствие рекламы и прочие, до создания CRID неизвестны.

CRID может относиться к нескольким экземплярам элемента контента (например, программа вещания может повторяться, веб-сайт может быть зеркальным, элементы контента могут предлагаться различными провайдерами контента, в различных сетях и т. д.).

Элемент контента, имеющий CRID, может содержать группу других элементов контента. Например, CRID может ссылаться на серию программ.

Ключевым понятием процесса поиска контента по ссылке является разделение ссылки на CRID элемента контента и на сведения, относящиеся к процессу его получения.

Разделение, предоставляемое CRID, обеспечивает сопоставление ссылок контента и позиций конечных результатов.

Служба TV-Anytime определяет вид контента, который будет предоставлен после определения положения. Экземпляром контента может быть любой компонент, полученный пользователем в соответствующей позиции.

Провайдер служб разрешения позиции системы TV-Anytime декларирует элементы контента (например, программы, сериалы и т. д.).

Процесс поиска контента по ссылке при использовании приложений и дополнительных метаданных позволяет получать необходимый результат с первого раза, но может потребовать выполнения нескольких дополнительных шагов, обеспечивающих возможность системе предоставить следующие функции:

-    выбор между альтернативами;

-    выбор субэлементов;

-    выбор между близкими объектами;

-    выбор времени доставки;

-    выбор до начала реализации;

-    выбор качества кодирования;

-    выбор стоимости доставки;

-    выбор на основе согласованных прав;

-    ссылка для элемента контента и соответствующих метаданных.

3

В процессе поиска контента по ссылке устанавливаются:

-    форма данных идентификации контента;

-    спецификация набора правил для разрешения позиции этих данных в местах расположения контента, из которых этот контент может быть получен.

Процесс поиска контента по ссылке не включает в себя процессы выбора или извлечения контента и процесс определения метаданных, используемых в запросе.

5    Процесс разрешения позиции

В процессе разрешения позиции выполняется преобразование CRID в другие CRID или локаторы. Разрешение позиции отображает CRID в кординатах времени (например, запланированное время передачи в системе вещания) и в пространстве доступных способов доставки (например, телеканал или 1Р-адрес).

Процесс разрешения позиции может выполняться в среде PDR (например, в системе вещания) или с помощью удаленного сервера (например, сервера в сети Интернет).

6    Параметры полномочного органа, создающего CRID

Полномочный орган (далее орган) создает уникальный CRID и обеспечивает возможность отображения CRID в локатор или в другие CRID.

CRID должен быть разрешен или непосредственно органом CRID, или другой стороной. Другая сторона, называемая в дальнейшем провайдер разрешения, может предоставить разрешение при условии получения от органа потока необходимой информации. Эта информация позволит провайдеру разрешения связать свое разрешение с CRID.

В большинстве случаев PDR будет работать с несколькими органами, поэтому он должен уметь их различать. Для того чтобы PDR мог различать органы, каждому органу присваивается уникальное имя. Настоящий стандарт предусматривает присвоение уникальных имен для каждого органа системы TV-Anytime использованием системы имен домена (DNS).

Ниже представлен синтаксис имени органа:

<DNS name>

<DNS Name> является зарегистрированным доменным именем в сети Интернет. <DNS Name> нечувствительно к регистру и должно быть полным именем.

Примерами некоторых имен органа являются:

www.broadcaster.com;

ISP.net;

www.commerce.com.

7    Идентификатор ссылки контента (CRID)

CRID является идентификатором части контента. Он используется в процессе поиска и отбора контента. Несколько CRID могут относиться к одной и той же части контента.

CRID может передавать разрешения одному или нескольким CRID. Передача разрешения от CRID к другим CRID используется для двух целей:

-    CRID разрешает несколько CRID для группы элементов контента (серия программ);

-    CRID разрешает одному или нескольким CRID одного органа ссылаться на CRID другого органа.

На рисунке 7.1 показан пример древовидной структуры CRID.

Ниже представлен синтакис CRID:

CRID://<authority>/<data>

<authority> — используются правила наименования органа TV-Anytime, гарантирующие уникальность, приведенные в разделе 6;

<data> — является свободной строкой формата, совместимой с универсальным идентификатором ресурса (Uniform Resource Identifier, URI), и имеет значение в сочетании с именем органа, приведенным в поле <authority>.

ГОСТ P 57874—2017

Рисунок 7.1 — Пример древовидной структуры CRID

В целом CRID соответствует URI. Как спецификации соответствия URI часть синтаксиса CRID:// не чувствительна к регистру.

Для обеспечения гарантированной функциональной совместимости рекомендуется, чтобы символы, которые используются вне диапазона символов, разрешенных в URI, были закодированы в UTF8 и включены в URI как последовательность исключенных байтов.

Примеры правильных (в смысле синтаксиса) CRID показаны в таблице 7.1.

Таблица 7.1 — Примеры правильных (в смысле синтаксиса) CRID

CRID

Описание

CRID://company.com/foobar

CRID создан органом "company.com", фрагмент данных из "foobar"

crid://broadcaster. co.jp/wibble

CRID создан органом " broadcaster.co.jp", фрагмент данных из "wibble"

cid://broadcaster. co.jp/%E3%82%A8%E3%82 % A4 % E 3 % 82 % AC

CRID создан органом "broadcaster.co.jp", фрагмент данных "Е" "1" "GA" представляется в виде СИМВОЛОВ KATAKANA (японские иероглифы), имеющих значение "movie"

8 Форматы локаторов

Экземпляры контента могут предоставляться различными способами: местным запоминающим устройством, потоком вещания, потоком вещания данных, файлом данных в Интернете и потоком данных, передаваемых через сеть Интернет.

Локатор определяет адрес, показывающий, где и когда может быть получен элемент контента. Необходимость обработки множества форматов локаторов обусловлена множеством способов предоставления контента PDR. PDR анализирует достаточное количество форматов локаторов, гарантирующее для PDR возможность принятия решения о допустимости использования соответствующего способа передачи.

Локатор анализируется и используется способами, зависимыми от формата медиаконтента, используя мультимедийные средства или конкретный транспортный протокол. Например, локатор DVB будет содержать параметры позиции потока DVB:

-    ID транспортного потока;

-    ID службы;

-    ID настольного ПК;

-    ID события.

Ниже представлен синтаксис формата локатора:

transport mechanism>:<transport system specifio

Строка transport mechanism> должна быть уникальной для каждого транспортного потока. Строка "CRID" не должна использоваться в качестве имени transport mechanism>.

5

Строка transport system specifio определяет формирователя transport mechanism>.

В целом локатор по спецификации совместим с URI.

Для каждой строки transport mechanism> будет применяться только один формат синтаксиса строки transport system specifio.

Строка transport system specifio должна предоставлять следующую информацию:

-    позиция (location) — обеспечивает представление позиции (места и времени), в которой возможно приобретение контента. Допускается прием устройством PDR контента от различных провайдеров, использующих один и тот же transport mechanism>. Эта причина определяет требование однозначности формата «позиция» системы TV-Anytime при использовании несколькими провайдерами одинаковых transport mechanism>;

-    тип доступности (type of availability) — предполагается, что некоторые схемы будут использоваться для получения контента «по расписанию» и «по требованию». Контент, который доступен в определенное время в определенном месте (например, вещательная телевизионная программа, вебвещание), приобретается «по расписанию». Контент, основанный на расписании, должен быть получен в то время, которое предоставлено позицией. Контент, который можно получить в любое время между двумя граничными значениями (например, контент, который находится на сервере в течение одного месяца), обрабатывается в формате «по требованию». Контент, основанный на механизме «по требованию», может быть получен в любое доступное время.

Для контента, поставляемого на основе расписания, устанавливаются следующие условия:

-    время старта (Start time) — предоставляется информация о планируемом времени начала вещания контента. Необходимо, чтобы время старта было однозначным в отношении местного часового пояса, так как PDR может иметь возможность получать контент из разных часовых поясов;

-    продолжительность доступности контента (Duration of content) соответствует продолжительности контента во времени.

Для контента «по требованию» устанавливаются следующие условия:

-    начало доступности (Duration of content) — поле определяет первый момент времени, когда контент становится доступным. Необходимо обеспечивать однозначность начала доступности в отношении местного часового пояса, так как PDR может иметь возможность получать контент из разных часовых поясов;

-    окончание доступности (End of availability) — поле определяет первый момент времени, когда контент станет недоступным.

В определении синтаксиса для строки локатора transport system specifio, связанного с transport mechanism>, есть предположение о среде, в которой работает PDR. Для каждого transport mechanisno PDR необходима конкретная информация для получения контента от этой системы. Эта информация может быть предоставлена транспортным механизмом или любым другим способом, соответствующим задаче PDR.

Например, в среде PAL Западной Европы позиция может указывать сеть и идентификатор канала в рамках его синтаксиса. Отображение сети вещания и идентификатора канала в физическом канале использует информацию, которая переносится на интервале вертикального обратного хода луча.

Транспортный механизм обеспечивает более точную синхронизацию, чем время начала, которую PDR может использовать для захвата контента (например, информацию об управлении программой доставки (Programme Delivery Control, PDC или ID событий DVB).

9 Идентификаторы метаданных экземпляра

CRID в системе TV-Anytime создан для выбора позиции, которая не зависит от контента, однако возможны случаи, когда пользователь может использовать выбор позиции зависимого от версии контента.

Для обеспечения такого сценария идентификатор может присваиваться опционально каждой позиции и может сигнализировать в метаданных описания экземпляра. При изменении позиции контента идентификатор метаданных экземпляра не изменяется.

Идентификатор метаданных экземпляра будет уникальным только в границах CRID, к которому он был назначен. Допускается присвоение этого идентификатора в границах различных CRID.

PDR может использовать идентификатор метаданных экземпляра для отслеживания изменений в позиции экземпляра части контента. Для этого PDR должен использовать и CRID, и идентификатор, при этом идентификатор будет гарантированно уникальным только для данного CRID.

6

ГОСТ P 57874—2017

Идентификатор может связывать описания метаданных экземпляра с информацией, полученной в процессе разрешения позиции.

При условии уникальности идентификатора метаданных экземпляра в рамках данного CRID каждый идентификатор метаданных экземпляра должен начинаться уникальным доменным именем сети Интернет. Часть имени идентификатора метаданных экземпляра определяется органом, создавшим идентификатор метаданных экземпляра.

При создании идентификатора метаданных экземпляра следует учитывать, что каждой паре идентификаторов «CRID — позиция» должен соответствовать только идентификатор метаданных экземпляра.

Синтаксис идентификатора метаданных экземпляра:

imi:[<name>/]<data>

Поле <name> содержит зарегистрированное доменное имя сети Интернет. Поле <пате> не чувствительно к регистру и должно быть полным именем. Если поле <пате> как часть идентификатора метаданных экземпляра совпадает с именем органа CRID, то <пате> и «/» могут быть опущены.

Поле <data> является свободной строкой формата (за исключением того, что применение символа «наклонная черта вправо» запрещено) и является унифицированным идентификатором ресурса (URI), имеет значение органа, указанного в поле <пате>. Поле <data> является частью идентификатора метаданных экземпляра без учета регистра.

Примеры синтаксически допустимых идентификаторов метаданных экземпляра представлены в таблице 9.1.

Таблица 9.1 — Примеры синтаксически допустимых идентификаторов метаданных экземпляра

Идентификатор метаданных экземпляра

Описание

imi:company.com/foobar

Идентификатор метаданных экземпляра создается "company.com" с частью данных "foobar"

imi: broadcaster, co.jp/broodjeham

Идентификатор метаданных экземпляра создается "broadcaster.co.jp" с частью данных "broodjeham"

imi:meaning

Идентификатор метаданных экземпляра создан органом CRID (часть <name> идентификатора метаданных экземпляра опущена, поэтому используется орган CRID) с частью данных "meaning"

Условие включения в информацию разрешения позиции идентификаторов метаданных экземпляра является опциональным. Поэтому PDR не должен предполагать, что эти идентификаторы всегда доступны в его процедурах приобретения.

Пример использования идентификатора метаданных экземпляра для отслеживания изменения позиции части контента представлен в таблицах 9.2 и 9.3.

Таблица 9.2 — Пример разрешенного CRID

CRID

Позиция

Идентификатор

crid://example. net/abcl 23

dvb://123.5ac.3be;3e45@2001-12-07T12:00:00.00+01P02:10

imi:def.com/1

ftp://example.net/mirror/def123.mov

imi:def.com/2

В таблице 9.3 показан пример CRID, разрешенного в таблице 9.2, после изменения позиции, идентифицированной "imi:def.com/1".

Таблица 9.3 — Пример CRID, разрешенного в таблице 9.2, после изменения в позиции, идентифицированной "mi:def.com/1"

CRID

Позиция

Идентификатор

crid://example. net/abcl 23

dvb://123.5ac. 100; 1 e4a@2001 -12-07T15:00:00.00+01 P02:10

imi:def.com/1

ftp://example.net/mirror/def123.mov

imi:def.com/2