Приложение А (справочное). Принципы создания и ведения тегов идентификации программного обеспечения

Приложение А
(справочное)

Принципы создания и ведения тегов идентификации программного обеспечения

А.1 Введение

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

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

А.2 Жизненный цикл тега идентификации программного обеспечения

А.2.1 Обзор

Данные, содержащиеся в теге идентификации программного обеспечения, создаются и/или изменяются в четырех основных точках жизненного цикла тега идентификации программного обеспечения, как это показано на следующем рисунке Рис. А.1

Рисунок А.1 - Жизненный цикл тега идентификации программного обеспечения

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

А.2.2 Процесс создания

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

1. abstract

2. component_of

3. complex_of

4. data_source

5. dependency

6. elements_owner

7. entitlement_required_indicator

8. license_linkage

9. package_footprint

10. product_category

11. product_identifier

12. product_title

13. product_version

14. release_date

15. sku

16. software_creator

17. software_creator_alias

18. software_licensor

19. software_licensor_alias

20. software_id

21. supported_languages

22. tag_creator

23. tag_creator_alias

24. tag_creator_copyright

25. upgrade_for

26. usage_identifier

27. validation

В общем случае эти элементы должны быть относительно статичны для определенного программного продукта и должны быть включены в установочную эталонную копию.

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

А.2.3 Процесс упаковки программного обеспечения

Некоторое программное обеспечение подвергается процессу упаковки, который может выполняться третьей стороной. Упаковываться могут OEM-продукты, интегрируемые в комплексное программное решение. Упаковку могут выполнять лицензированные упаковщики, объединяющие несколько продуктов в набор.

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

Упаковщик программного обеспечения, например, может создавать собственный тег идентификации программного обеспечения взамен существующего, или, как вариант, создавать тег пакета, в котором в качестве компонента будет присутствовать ссылка на существующий тег и программное обеспечение. Еще одним вариантом может быть внесение изменений и/или добавлений в элементы тега идентификации программного обеспечения. Если тег просто внедряется в соответствующий продукт без изменения элементов, владельцами которых являются создатель программного обеспечения (элемент software_creator) или лицензиар программного обеспечения (элемент software_licensor), то к элементам, которые могут изменяться или добавляться, относятся следующие (ни один из них не является обязательным):

1. component_of

2. complex_of

3. data_source

4. dependency

5. elements_owner

6. license_linkage

7. packager

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

А.2.4 Процесс выпуска релиза

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

1. elements_owner

2. packager

3. release_id

4. release_package

5. release_rollout

6. release_verification

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

А.2.5 Процесс установки

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

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

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

1. installation_details

2. serial_number

3. validation

А.3 Уникальное определение идентификатора software_id

Уникальный идентификатор software_id соответствует уникальному продукту на двоичном уровне для целей распространения и/или обновления. Уникальность гарантируется сочетанием уникального имени создателя тега (элемент tag_creator_regid) и заведенного создателем тега (tag_creator) идентификатора unique_id.

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

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

А.4 Спецификация имени файла

А.4.1 Обзор

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

А.4.2 Дистрибуционное имя файла

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

А.4.3 Установочное имя файла

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

Кроме того, настоятельно рекомендуется, чтобы программы установки тегов идентификации программного обеспечения следовали рекомендациям, определенным в 6.1.7, оговаривающим включение в установочное имя файла уникальной информации о машине. Это позволит специалистам-практикам по использованию процессов SAM (и другим лицам) идентифицировать машину, использованную для установки программного обеспечения на съемный или используемый совместно (сетевой) носитель.

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

А.5 Каталоги для установки тегов

Тег идентификации программного обеспечения может устанавливаться на вычислительное устройство в два места. Первое место - общий системный каталог (см. 6.1 и А.6.3); второе место - каталог верхнего уровня установочного каталога программного пакета.

А.6 Принципы работы без привлечения регистрирующих органов

А.6.1 Общие положения

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

a) информацию о всех платформах, их соответствующих владельцах, информацию о том, в каких местах платформы должны храниться теги идентификации программного обеспечения;

b) уникальные имена и идентификаторы создателя программного обеспечения;

c) уникальные идентификаторы программного обеспечения.

А.6.2 Уникальные ссылки на идентифицированных создателей и лицензиаров

С целью упрощения работы без привлечения регистрирующего органа в данную часть настоящего стандарта включены следующие принципы:

a) каждый из элементов elements tag_creator, software_creator и software_licensor должен использовать специальный регистрационный идентификатор (regid), являющийся гарантированно уникальным в пределах организации, и который можно использовать для идентификации организации. Идентификатор regid создается на базе определения, разработанного для стандарта iSCSI, как это определено в стандарте IETF RFC 3720;

b) идентификатор regid включает в себя доменное имя создателя (в соответствии с определением стандарта IETF RFC 1034, 3.5 и стандарта IETF RFC 1123, 2.1). Использование в данной части настоящего стандарта идентификатора regid (и, в расширительном смысле, компонентов домена организации) позволяет указывать уникальный ID, не требующий привлечения независимого регистрирующего органа и снабдить заинтересованных лиц дополнительной информацией для обратного отслеживания программного обеспечения вплоть до создателя первоначального тега;

c) создатель тега несет ответственность за предоставление элементов unique_id по всем данным, создаваемым для идентификатора regid создателя тега;

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

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

А.6.3 Данные о каталогах хранения платформы

Единственной информацией, которая не содержится в самом теге, или по встроенной в него ссылке, являются данные о том, в каком месте данной платформы (например, Windows, UNIX или Linux ^тм) будут храниться теги идентификации программного обеспечения. Количество платформ сравнительно невелико, и требования к этой информации должны обрабатываться примерно одинаковыми способами, а именно:

а) каждый провайдер платформы вправе указать, в каком месте его платформы будет храниться данная информация. Провайдер платформы должен иметь возможность сообщать данные сведения любым выбранным им способом, например, через свой веб-сайт. Данная часть настоящего стандарта рекомендует, чтобы провайдеры платформы, как минимум, публиковали данную информацию в подкаталоге с именем "19770" на странице с основным адресом доменного имени;

b) общие системные каталоги, которые должны использоваться для хранения тегов на различных платформах, были определены в 6.1;

c) технические отчеты могут публиковаться по адресу: http://standards.iso.org/iso/19770/-2/ и содержать сводную информацию об известных платформах и правилах оформления значений данных, наиболее часто используемых при работе с тегами идентификации программного обеспечения.

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