ГОСТ Р 56455—2015
11.1.3 Совместное использование метаданных и контента
Существующие спецификации не обеспечивают связывание метаданных и контента.
При хранении контента необходимо хранить связанные с ним метаданные для того, чтобы обе
спечить возможность идентификации контента в более позднее время. Это необходимо, потому что во
многих случаях метаданные вещательного контента не будут постоянно доступными в базе данных
вещателя. Это справедливо для случаев, когда данные поставлены через вещательную передачу, так
как объем передаваемых данных ограничен пропускной способностью. Это также справедливо для он
лайновых служб из-за возможного чрезвычайно большого объема передаваемых данных.
Существуют проблемы с хранением метаданных. Например, метаданные могут изменяться (на
пример. в аннотации сделаны исправления или добавлены метаданные, такие как информация о сег
ментации). Другой проблемой является динамичный характер группирующейся информации — элемен
ты групп изменятся на интервале длительного времени. Таким образом, сохраненные метаданные не
будут отражать текущее состояние. Например, конкретный эпизод в длительном сериале будет иденти
фицирован как элемент вещательной передачи, но через несколько месяцев в будущем он может быть не
перечислен.
Для того, чтобы обеспечить прямую связь метаданных с контентом, предпочтительно использо
вать форматы, такие какAAF или MXF. Эти форматы обеспечивают встраивание метаданных в контент
и в случае MXF в состоянии отобразить модель данных TV-Anytime как свою собственную, а также для
встраивания XML непосредственно. Это особенно важно, если контент будет экспортироваться в дру
гую среду, например, при записи на DVD.
Если контент создается в процессе редактирования или транскодирования исходной части кон
тента другого источника, то элемент «DerivedFrom» может использоваться, чтобы указать на исходный
контент и использование нового CRID.
11.2 Удаленное программирование
Одним из ключевых вопросов удаленного программирования ([12]) через электронную почту яв
ляется гарантия обработки только действительных электронных писем. При отсутствии защиты третья
сторона могла бы удаленно управлять PDR (атака «отказ в обслуживании»),
PDR может быть сконфигурирован со списком допустимых источников и полем «From:» в заго
ловке электронной почты. Это обеспечит базовый, но явно недостаточный уровень проверки. Было бы
надежнее, если бы тело электронной почты могло бы быть подписано и/или каким-либо образом
зашифровано.
Следует учитывать, что при обмене метаданными между друзьями безопасность будет понижаться.
40