"ГОСТ Р 57874-2017. Национальный стандарт Российской Федерации. Телевидение вещательное цифровое. Система TV-ANYTIME. Процесс поиска контента по ссылке. Основные параметры"
(утв. и введен в действие Приказом Росстандарта от 31.10.2017 N 1588-ст)

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

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

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

4 Настоящий стандарт разработан с учетом основных нормативных положений стандарта Европейского института по стандартизации в области телекоммуникаций (ETSI) ЕТСИ ТС 102 822-4 V1.1.2 (2004-10) "Широковещательные и онлайновые службы: поиск, выбор и законное использование контента в персональных системах хранения ("TV-Anytime Phase 1"). Часть 4. Ссылки на контент" [ETSI TS 102 822-4 V1.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 ВВЕДЕН ВПЕРВЫЕ

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

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

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

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

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

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

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.1 показано содержание процесса поиска контента по ссылке. Некоторые части, не входящие в состав процесса поиска контента по ссылке, показаны на рисунке 4.1 для того, чтобы придать этому процессу глобальный контекст.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

www.broadcaster.com;

ISP.net;

www.commerce.com.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- ID службы;

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

- ID события.

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

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

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

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

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

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

- позиция (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 specific>, связанного с <transport mechanism>, есть предположение о среде, в которой работает PDR. Для каждого <transport mechanism> PDR необходима конкретная информация для получения контента от этой системы. Эта информация может быть предоставлена транспортным механизмом или любым другим способом, соответствующим задаче PDR.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RAR, совместимая с TV-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 представлен пример записи разрешения органа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1) SubmittedCRID;

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

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

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

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

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

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

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

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

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

- GroupInformationTable;

- ProgramInformationTable;

- ProgramLocationTable;

- ContentReferencingTable.

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

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

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

С целью уменьшения возможной перегрузки сервера 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 минут. Проверки соответствия этому требованию настоящим стандартом не предусматриваются.

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

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

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

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

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

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

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

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

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

Например, с учетом 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".

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

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

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

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

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

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

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

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

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

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

то <path to server> (путь к серверу) был бы:

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

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

то <path to server> ("путь к серверу") был бы:

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

- /template/go.php?url=https://computer2.example.com:1234/?CRID="crid://example.com/abc123";

- /template/go.php?url=https://broadcaster.com/?CRID="crid://broadcaster.com/abc123"&CRID="crid://broadcaster.com/def456";

- /template/go.php?url=https://kaas.example.com/scripts/resolution?CRID="crid://example.com/abc123"& Result=1;

- /template/go.php?url=https://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:

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

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

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

Ответ от сервера разрешения позиции основан на спецификации 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.

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

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

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

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

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

Пример - Location: /template/go.php?url=https://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.

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

Схема разрешения позиции представлена на рисунке А.1.1.

Описание элементов схемы разрешения позиции представлено в таблице А.1.1.

Описание элементов схемы записи органа разрешения представлены в таблице А.1.2.

Схема записи органа разрешения представлена на рисунке А.1.2.

На рисунке А.2.1 приведен пример экземпляра документа, соответствующий схеме XML разрешения позиции.

На рисунке А.2.2 приведен пример экземпляра документа, соответствующий схеме RAR XML.

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

Если на запрос PDR позиции от сервера получен ответ "разрешить после указанной даты и времени":

1) Если дата и/или время находятся в будущем: ожидайте наступления этой даты и этого времени.

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

Если в результате связи с сервером получен ответ "разрешить после данной даты и времени", то необходимо удвоить длительность интервала времени случайной продолжительности.

Если длительность интервала случайной задержки >= 1 дня:

а) PDR может повторять попытки установления связи каждый день;

б) PDR может удваивать интервал случайной задержки до значения >= одной недели, после чего задержка должна оставаться фиксированной в течение одной недели.

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

Если длительность интервала случайной задержки >= 1 дня:

а) PDR может повторять попытки установления связи каждый день;

б) PDR может удваивать интервал случайной задержки до значения >= одной недели, после чего задержка должна оставаться фиксированной в течение одной недели.

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

Если длительность интервала случайной задержки >= 1 дня:

а) PDR может повторять попытки установления связи каждый день;

б) PDR может удваивать интервал случайной задержки до значения >= одной недели.

В случае, если от сервера получен ответ "CRID неизвестен" и тип сервера "первый класс", то возможны два варианта:

а) делают заключение, что CRID недопустим (в предположении, что удаленный сервер возвращает сообщение "CRID = недопустим");

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