База ГОСТовallgosts.ru » 33. ТЕЛЕКОММУНИКАЦИИ.АУДИО-И ВИДЕОТЕХНИКА » 33.170. Теле- и радиовещание

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

Обозначение: ГОСТ Р 57874-2017
Наименование: Телевидение вещательное цифровое. Система TV-Anytime. Процесс поиска контента по ссылке. Основные параметры
Статус: Принят

Дата введения: 08/01/2018
Дата отмены: -
Заменен на: -
Код ОКС: 33.170
Скачать PDF: ГОСТ Р 57874-2017 Телевидение вещательное цифровое. Система TV-Anytime. Процесс поиска контента по ссылке. Основные параметры.pdf
Скачать Word:ГОСТ Р 57874-2017 Телевидение вещательное цифровое. Система TV-Anytime. Процесс поиска контента по ссылке. Основные параметры.doc


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



ФЕДЕРАЛЬНОЕ АГЕНТСТВО

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

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

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

ГОСТР 57874— 2017

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

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

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

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

Москва

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

2017

ГОСТ Р 57874—2017

Предисловие

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

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

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

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

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

€> Стандартинформ. 2017

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

и

ГОСТ Р 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

ГОСТ Р 57874—2017

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

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

СИСТЕМА 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    Нормативные ссылки

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

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

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

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

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

1

ГОСТ Р 57874—2017

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): Организация, создающая CRIO.

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    8 настоящем стандарте приняты следующие сокращения:

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    8 настоящем стандарте приняты следующие соглашения к требованиям к синтаксису:

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

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

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

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

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

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

2

ГОСТ Р 57874—2017

Пс»ск»«!«я>

■«тент

ПспребгтемыЯ

кжтнг

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

•    выбор времени доставки:

•    выбор до начала реализации:

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

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

•    выбор на основе согласованных прав:

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

3

ГОСТ Р 57874—2017

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

•    форма данных идентификации контента:

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

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

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

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

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

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

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

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

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

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

<DNS name>

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

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

;

ISP.net;

.

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

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

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

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

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

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

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

CRID://<authorlty>/<data>

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

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

4

ГОСТ Р 57874—2017

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

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

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

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

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

CRIO

Описание

С Rl D://company.oom/Yoobar

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

chdJ/broadcaster.co.jpfrvibble

CRID создан органом " broadcaster.oo.jp*. фрагмент данных из "Wibble*

cid7/broadcaster.co.jp/%E3%82%A8%E3%82

%A4%E3%82%AC

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

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

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

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

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

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

•    ID службы;

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

•    ID события.

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

«transport mechanlsm>:«transport system specific»

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

5

ГОСТ Р 57874—2017

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

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

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

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

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

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

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

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

•    продолжительность доступности контента (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).

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

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

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

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

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

ГОСТ Р 57874—2017

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

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

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

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

imi:[<name>/]<data>

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

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

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

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

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

Описание

imircom pany.com/Toobar

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

imi:broadcaster.co.jp/broodjeham

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

imimeaning

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

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

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

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

CRiO

Позиция

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

end У/example .net/abc 123

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

imi:det.com/1

imi:def.com/2

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

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

CRiO

Позиция

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

cridJ/example .net/abc 123

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

imi:def.com/1

123.mov

imi:def.com/2

7

ГОСТ Р 57874—2017

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

соответствовать записи "imi: example.net/Г.

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

GRID | Позиция

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

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

imi: 1

rtp://exampie.net/mirrof/def123mov

imi:2

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

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

CRID

Позиция

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

При* мече мне

crid://exampte.net/abc123

dvb-'7123.5эс. 100;1е4а@2001-12-07Т15:00:00.00 *01 Р02:10

imi:1

1

imi:2

crid://example.net/je98

dvb://123.6ef.200;5e23@2002-01-31Т14:20:00.00+01 Р00:30

imi:mdprov.com/01

2

dvbi/123.6ef .200:1с24@2002-02-14Т14;20:00.00+01РО0:30

imi:mdprov.comf02

crid://exampte.net/)a90

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

imi:mdprov.com/01

3

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

imi:mdprov.com/02

crid://broadcaster.co.uk/0203

dvb7/c01 .ad3.400;003c@2002-02-14T1»mi: 18:00:00.00+01 Р01:00

imi:1

4

imi:mdprov.conV01

Примечания

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

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

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

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

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

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

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

8

ГОСТ Р 57874—2017

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

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

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

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

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

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

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

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

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

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

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

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

6 таблице 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

9

ГОСТ Р 57874—2017

Окончание таблицы 10.1

Иыя поля

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

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

autnam.com

URL

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

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

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

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

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

Оваьесяслрмв «егаданш: или еактомоАупратем* гфмижегфврвпенка юнгвктж

Сшаь е амстнэ* системой упишут у laiiiM ww с ЯМКШНИИИ ЩГТ—Ч ДОшиияйСЯШ

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

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

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

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

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

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

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

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

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

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

10

ГОСТ Р 57874—2017

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

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

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

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

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

Или реализация PDR будет использовать местного обработчика в случае, если контент, к которому обращается 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 <ххх>" («разрешен после даты») — CR1D разрешен после даты <ххх>

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

Acquisition directive

{•Директива

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

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

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

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

AlistofCRIDs or a list of Locators) {«Список CRID или список позиций»)

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

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

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

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

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

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

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

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

11

ГОСТ Р 57874—2017

Окончание таблицы 11.1

Поле

Описание

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

Date

Дата и время, на которые или после которых POR должен попытаться повторно раз-

(«Дата»)

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

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

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

Описание

Acquisition directive

Resolution complete

All

No

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

(«все»)

(«нет»)

элементов

All

Yes

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

(«все»)

(«да»)

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

Any

No

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

(«любой»)

(«нет»)

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

Any

Yes

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

(«любой»)

(«да»)

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

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

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

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

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

Acquisition directive

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

CRID к

All

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

нескольким CRID

(«все»)

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

CRID к

Any

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

нескольким CRID

(«любой»)

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

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

All

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

положениям

(«все»)

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

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

Any

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

зициям

(«любой»)

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

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

12

ГОСТ Р 57874—2017

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

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

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

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

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

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

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

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

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

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

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

ГЪпммт»    Г^оамяутем*    УЬалонный оорор

FOR)    ОрИр    РСЧМШФНМ пмции

Процесс

помок

WWUIW

гпгмра

PH***"""

ГММрМ

/

Запрос MMMOi органе СЙР

Ади* дашмиого мрмрг

V

/

<см>

Прокис

РЧНШМ—1

пюции

ЛоягчрыилиСДО

"ft

Аг.шрЧ1Пчнмемтвдчмо

(огщяомшыю)

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

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

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

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

1)    SubmittedCRID;

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

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

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

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

Описание

0

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

13

ГОСТ Р 57874—2017

Окончание таблицы 11.4

Значение фпа>а SubmittedCRID

Описание

1

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

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

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

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

Значение фпэ>а Result

Описание

0

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

1

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

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

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

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

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

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

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

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

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

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

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

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

-    GroupInformationTable:

-    ProgramlnformationTable;

• ProgramLocationTable;

-    ContentReferencingTable.

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

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

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

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

14

ГОСТ Р 57874—2017

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

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

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

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

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

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

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

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

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

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

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

Пвпеемпль    Автчмтмпм*    Уйаломный мрир

{TOR)    еерирсМ    рецмшения пиицм

ага» дошив яах

/

эелрм «ини «ртне

Ч

тщ«иеов помов

Имя *оещ доиминогв

> 8ЯМ-

даеммного

оеревре

ргреммем

пмемм

^ Иняжхлшигалммт IP «к*е няииммг» оячиев

J

1 Стсрфтиы*

У seriwe ммеин жите Г дл*Р«др*ее

ч

/

<см>

Процесс

лоатрм или

пссшцмм

V

^&гцёон»75^~"",“*

1

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

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

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

15

ГОСТ Р 57874—2017

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

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

_Service._Protocol.Name

Например, запрос для сервера HTTP example.com будет выглядеть как: '_http._tcp.example.com”. Сервер ONS ответит именем хоста и номером порта, соответствующим расположению сети, в которой может быть найдена запрашиваемая служба. 8 приведенном выше примере может быть возвращено сообщение: ”webserver2.example.c©m порт 80’.

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

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

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

_lres. tcp.<CRID authority»

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

Другой пример приведен с учетом CRIO "CRID:// example.co.uk/9afc2”. строка запроса будет "Jres._ 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=va!ue" повторяется по мере необходимости.

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

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

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

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

Ключ

Описание

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

CR1D

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/

16

ГОСТ Р 57874—2017

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

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

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

redirect.example.com/tva/lr.

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

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

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

kaas.example.com/scripts/resolution.cgi

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

•    http7/computer2.example.com:1234/?CRlD=*crid://example.com/abc123";

•    http7/broadcaster.com/?CRID="crid://broadcaster.com/abc123"&CRID=’crid7/broadcaster,com/ def456";

•    http7/kaas.example.com/scripts/resolution?CRID="crid7/exampte.com/abc123’& Result^;

•    http7/redirected.example.com/tva/tr?CRID=*crid://example.com/abc123"& SubmittedCRID=1.

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

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

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

text/xml.

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

Accep:text/xml.

Для обеспечения безопасной передачи запросов разрешения от PDR до сервера разрешения позиции и получения защищенных результатов сервера разрешения позиции POR и сервер разрешения позиции могут согласовать применение безопасного протокола 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

ГОСТ Р 57874—2017

Тип 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: .

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

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

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

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

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

Примеры

Content-Type: text/xml.

Content-Encoding: x-zip

18

ГОСТ Р 57874—2017

Приложение А (обязательное)

Схема XML процесса поиска контента по ссылке

А.1 Определение схемы

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

А.1.1 Схема разрешения позиции

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

<?xml vefsion="1.0" encoding="UTF-8*?>

<schema targetNarr>espace="urn:fva:Con/en/Re/erencing;20W.itm/ns.mefadafa='bnrj./V3V7>e/ada/a:20£W xmlns='W(p^W>vw.w3.o<p/l20O1/XMLScfiefn3“xmlns:CRa"um:tva:ContenlRefefencing:2OO4H>

«element name="ConlenlRefereoangTabh"type-“CR:ConlentReferer>dngTableType’>

«annotation»

«documentation>A document conforming to the TV Anybme content referencing specification «/documentation»

«/annotation»

«/element»

«complexType nan\e=“ContentReferencingTableType">

«sequence»

«element nan\e=“Resolt'' type=“CR:ResuitType" mrnOccurs=“0" maxOccucs="unbounded~/>

«/sequence»

«attribute narrm="version" type="fioet~use=~reqwf8d"/>

«/complexType»

«simpleType names~AcquisiUonD>recbveType~>

«restriction base='!s/nog'»

«enumeration vaiue='*a//"/>

«enumeration values'’any"/>

«/restriction»

«/simpleType»

«simpleType names7?eso/utfonS/e/usrype>

«restriction base='is/rirjg'»

«enumeration vaiue="resoJved"/>

«enumeration vaiue=“discarri CRID"/>

«enumeration value="cannof yet resolve"/>

«enumeration value="una6ie to resolve"/»

«/restriction»

«/simpleType»

«complexType names*Resuft7ype'»

«choice»

«sequence»

«element name=“CRIDR6Sutt"type-'CR:CRtDResultType"minOccurs="0"max-Occurs=“unbounded"/> «/sequence»

«sequence»

«element nan\e=1.ocaUonsResuir type="CR:L.ocaUonsResoltType" minOccurs-"0" max-Occurss"bnbounded“ />

«/sequence»

«/choice»

«attribute rtame=“CRID"type="metadata:CRIDType"use-"require<)“/>

«attribute name="complete"types"boolean~use-“/eqwred"/>

«attribute names"acqwre'*fype='CR:AcquisifJior7£WrecfiveTxpe" use="requirecr/»

«attribute name=”s/a/us" type=XtR:ResolutionStatusType“ usa=~reqwred~ f>

«attribute na me="reresoiveDate " type="da (e Time " uses"optk>nal"/>

Рисунок A.1. лист t — Схема разрешения позиции

19

ГОСТ Р 57874—2017

</complexType>

«comptexType name="CRIDResult Type ">

«sequence»

«etement name="Crki''type="metadata:CRIDType"maxOcctjrss'unbounded'’/>

«/sequence»

«/comptexType»

«comptexType narr\e="LocatorType~>

«simpleContent»

«extension bases"anyURI">

«attribute name=~instanceMetadatald~lypes‘'metadata:tnstanc6MetadataldType"use='’optionar/> «/extension»

«/simpleContent»

«/oomplexType»

«comptexType nan\e=’TimeAndURLType'>

«simpleContent»

«extens»on bases"anyURI">

«attribute name= "start" type="date Time " use-'required"/>

«attribute name="dorat/on" types~duration“ use=~optionar/>

«attribute name=”eotf“/ype="da/e77me" use-"optk>naV'/>

«attribute names‘1nslanceMetadatald“types‘7netadata:ln5tanceMetadataldType“ use-"optionaT/> «/extension»

«/simpleContent»

«/oomplexType»

«comptexType names’tocalk>nsResuHType">

«sequence maxOccurs="unbounded'^

«choice»

«element nan\e="Locator"type-''CR:LocatorType''/>

«element name="DecomposedLocator"type=''CR:TimeAndURLType“/>

«/choice»

«/sequence»

«/oomplexType»

«/schema»

Рисунок A.1. лисг 2

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

Имя элемента схемы

Описание

ContentReferencingTable

Элемент высокого уровня, в границах которого конкретизируются все результаты поиска контента по ссылке

ContentReferencingTableType

Определение синтаксиса для элемента ContentReferencingTable

Result

Информация о процессе поиска контента по ссылке для каждого разрешенного CR1D содержится в границах этого элемента

Version

Версия синтаксиса для этой XML-схемы.Для экземпляров, соответствующих схеме, определенной в настоящем стандарте, это поле должно содержать значение 1.0

ResuItType

Этот тип обеспечивает контейнер для всех возможных разрешений CRID

CR1D

Разрешенный CRID

Complete

«Истинно», если разрешение этого CRID завершено.

Если «ложь», то в будущем CRID может разрешить другие CRID или location

Acquire

Тип групгмроеакия для списка CR1D или локаторов. Эго поле значимо только тогда, когда статус соответствует разрешенному

20

ГОСТ Р 57874—2017

Продолжение таблицы А. 1.1

Иыя элемента схемы

Описание

status

Статус разрешенного CRID

reresotveDate

Если состояние эквивалентно «еще не может разрешить» или окончательное состояние эквивалентно «ложь*, то эго поле содержит дату и время выполнения перераэрешения. Эта дата и время должны быть однозначными относительно часового пояса

CRIDResult

Элемент для отображения результата разрешения CRID в одном или в нескольких CR1D

LocationsResutt

Элемент для создания экземпляра результата, представляющего разрешения CRID в одном или нескольких Locations

CRIDResuItType

Когда CRID разрешается в один или несколько CRID. должен быть использован экземпляр в CRIDResuItType

Crid

Один из «выходных» CRID

LocalionType

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

instance MetadatalD

Атрибут Location. обеспеч1вающий обязательную ссылку на метаданные описания экземпляра, раздел 10 «Идентификаторы метаданных экземпляра»

TimeAndURLType

Это расширение типа uriReference содержит URL. указывающий на контент. и имеет атрибуты, которые содержат информацию о времени приобретения

start

Для запланированного контента указывается дата и время запуска контента. Для контента «по требованию» это время и дата

Duration

Для запланированного контента указывается продолжительность контента. Этот элемент не должен быть использован для контента «по требованию»

End

Для запланированного контента этот атрибут не должен использоваться. Для контента «по требованию* этот атрибут содержит время и дату, когда контент более недоступен

LocationsResuItType

Когда CRID разрешает одну или несколько позиций, то должен использоваться экземпляр LocationsResuItType

Locator

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

tnstanceMetadatal D

Атрибут Locator, обеспечивающий обязательную ссылку на метаданные описания экземпляра (см. раздел 10)

DecomposedLocator

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

AcquisitionDirectiveType

Когда CRID разрешает список CRID или локаторов, то тип AcqutsibonO*ecbveType описывает, какие группы этот список представляют

Ail

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

21

ГОСТ Р 57874—2017

Продолжение таблицы А. 1.1

Имя элемента схемы

Описание

Алу

Должен быть получен один из элементов списка. Все элементы 8 списке равнозначны

ResolutionSlatusType

Тип. указывающий результат запроса разрешения

resolved

CRIO был успешно разрешен

discard CR1D

CRJD должен быть уничтожен

cannot yet resolve

CRIO не может быть разрешен и будет разрешен еще раз в более поздний срок

unable to resolve

CRIO не может быть разрешен

А. 1.2 Схема записи органа разрешения

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

Таблица А.1.2

Имя элемента схемы

Описание

ResolvingAuthorityRecordTabte

Элемент высокого уровня, в пределах которого создан экземпляр RAR

ResolvingAuthorityRecord

Элемент высокого уровня, в пределах которого создан экземпляр информации RAR

Resolution Provider

Строка, содержащая имя провайдер разрешения

AuthorityMame

Строка, содержащая имя органа CRIO, которые разрешаются этой службой разрешения

Class

Класс этой службы разрешения (первичный или вторичный)

URL

Позиция, в которой доступно разрешение информации

FirstValidDate

Первое время и дата, с которых RAR становится действительной

LastValidOat

Первое время и дата, с которых RAR становится недействительной

Weighting

Коэффициент значимости этой записи RAR по отношению к другой записи RAR. предусмотренный этим органом разрешения для данного органа CRID

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

«?xml увгеюп="/.£>"елсо<йлд=*иГР-8"?>

«schema targetNamespace^bm.fra.’Resoto'DgAutfKOTfy.ZOOl" xmlnss*ht1p://" xmlns:RAR='bm.1va:Reso/wxjAuf/Kyrty.2004'’ etement-FormDe-faidt="qua/rfred">

«element name='ResotvingAuthor<tyRecofdTabfe" type="RAR:ResofvingAuthor(tyRecordTableType"> «annotation»

«documentation>A document conforming to the TV Anytime content referencing specification «/documentation»

«/annotation»

«/element»

«complexType name= "ResolvingAuthorityRecordTэЬ/е Type ">

«sequence»

«element name= "ResotvingAuthorrtyRecorxi" (ype~~RAR:ResolvingAuthontyRecordType"mmOc-curs=,'1" maxOccors~bnbounde<r/>

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

22

ГОСТ Р 57874—2017

«/sequence»

«/compiexType»

«simpleType names~ProviderClassType“>

«restriction base='!sfnng'»

«enumeration vaiue~"primary”/>

«enumeration vaiues"secondary"/>

«/restriction»

</simp!eType>

«complexType name-“ResotvingAuthorityRecordType”> «sequence»

«element name=“ResolutionPmvider“type=~string“/> «element name^AulhorityName" typesetting”/>

«element name=“Class” type-'RAR.ProviderClass Type”/> «element names"VersionNumber” type=”unsignedLong“/> «element name=*L/RL" 1уре='1элу1/ЯГ f>

«element name=“FirstValidDate‘'typeS^atQTime“/> «element name=“LastValidDate “ fype®'Waf e Tone" f> «element nan\e=“Wetghting” type-integer”/*

«/sequence»

«/compiexType»

«/schema»

Рисунок A.1.2. лист 2

A.2 Пример экземпляра документов

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

«?xmt version="f. О" encodmg-‘V TF-8”?>

«ContentReferencingTable version® “1.0“ xmlnss “um:tva:ContentReterenang:2004“>

<!•• Example of a CRID resolving to other CRIDs —>

«Result CR\0=“crid://broadcaster.co.uk/akdsjdlkjdrstatus=''resolved''complete=‘1rue”acqoire=”aa"> «CRIDResult»

<Crid»CRID://example.com/greatstuff«/Crid»

<Crid»CRID://nextcrid.com/lkjkj«/Crid>

«/CRIDResult»

«/Result»

<!— Example of a CRID that is no longer valid —>

«Result CRlD-“crid://isp.net/B68457549845r‘statuss‘(jiscard CRID”complete=Jroe“ acquire-'air/> <!•• Example of a CRID resolving to other CRIDs and is incomplete ->

«Result CRiO=,'crid://example.co.ukAvibbie’status=”r8solved''compl6te='false'' acqutre-“eir> «CRIDResult»

<Crid»CRID://example.oom/stuff«/Crid>

«Crid»CRID://nextcrid.com/broodje«/Crid»

«/CRIDResult»

«/Result»

<!— Example of a CRID resolving to locators —>

«Result CR\D="crid://broadcaster.com/a/cnd''status-yesotved'' complete-lnje" acquire=”ati"> «LocationsResult»

«Locator instance Metadatatd®"imi:1”»dvb://1.4ee2.3f4;4f5@2001-03- 27T18:00:00.00+01:00 «/Locator»

«Decomposed Locator instanceMetadatald=,VrTw.vr>efada/aPTovcom/7,'start=“2001-03-29T18:00:00.00*» ftp7/myserver.example.com/directory12/hello.mp3«/DecomposedLocator> «DecomposedLocator start®“2001-03-29T18:00:00.00“ end=*2001-Q4-03T18:00:00.00*»ftp^/mysecver.example.oom/direclory12- backup/hello.mp3 «/DecomposedLocator»

«/LocationsResult»

«/Result»

«/ContentReferencingTable»

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

23

ГОСТ Р 57874—2017

<?xmt version encoding-"V TF-8" 7>

«ResolvingAulhorityRecordTabte xrT\\r\&=~um:tva:ResotvingAutt\ority:2004"> <ResolvmgAuthorityRecord>

<ResolutionProv>der>autnam.com</ResolutionProvider>

<AuthorityName>autnam.com</AuthorityName>

<Class>primary</Class>

<VersionNumber>1000<yVersionNumber>

<URL>http:/fvvww.autnafn.comflr/<AJRL>

<FirstValidDate>2O0O-O9-O6TO9:3O:OOZ</FirstVaNdDale>

<LastVai*dDate>2000-09-28T18:00:OOZ</LastVaiidDate>

<We*ghting>K/Weighling>

</ResolvingAuthorityRecord>

<ResolvingAuthorityRecord>

<ResoJutionProvider>tva.resprov.com</ResoiutionProvider>

<AuthontyName>autnam.com</AuthorityName>

<Class>secondary</Class>

<VersionNumber>1000</Vers»onNomber>

<URL>http7i\wvw.resprov.com/1r/autnam</URL>

<FirstValidDate>2002-09-26T09:30:OOZ</FirstVaiidDate>

<LastVal*dDate>2002-10-28T18:00:00Z</LaslValidDate>

<We*ghting>3</Weighting>

</ResolvingAuthorityReoord>

</ResolvingAuthorityRecordTable>

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

24

ГОСТ Р 57874—2017

Приложение Б (рекомендуемое)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

25

ГОСТ Р 57874—2017

УДК621.397:681.327.8:006.354    ОКС 33.170

Ключевые слова: телевидение вещательное цифровое, стандарты кодирования

ОКП 657400

26

БЗ 10—2017/72

Редактор А.А. Кабанов Технический редактор И.Е. Черепкова Корректор Е.Р. Ароян Компьютерная верстка Ю.В. Поповой

Сдано в набор 07.11.2017 Подписано в печать 29.11.2017. Формат 60*84*/^. Гарнитура Ариал Уел. печ. п. 3.72. Уч.-иэд. л. 2.34 Тираж 21 эм. За*. 2474.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

ИД «Юриспруденции». 115419. Москва, ул Орджоникидзе, 11

Издано и отпечатано оо ФГУП «СТАНДАРТИНФОРМ». 123001, Москва. Гранатный пер., 4.