Berkrley Internet Name Domain. Иногда для этой цели выделяют специальную машину задача
| Вид материала | Задача |
- Поурочне планування курсу "Основи Інтернет – технологій", 88.8kb.
- Работа nat введение, 150.17kb.
- 1. Сервіси Internet, 731.38kb.
- 1. Сервіси Internet, 347.99kb.
- Internet Information Services (iis). Понимание организации сетей, tcp/ip и Domain Name, 17.07kb.
- Что такое Internet? Ресурсы Internet*, 347.7kb.
- Лабораторна робота №19 ”Internet”, 103.46kb.
- Е. Е. Израилевич Практическая грамматика английского языка с упражнениями и ключами, 14711.83kb.
- Математическая логика сквозь школьные предметы, 133.29kb.
- Мифы и реальности Internet известные и скрытые возможности сети Что такое Internet, 306.75kb.
9. Ссылки
| [RFC-822] | Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC-822, UDEL, August 1982. |
| [RFC-2049] | Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996. |
| [RFC-2045] | Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC-2045, November 1996. |
| [RFC-2046] | Borenstein N., and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. |
| [RFC-2048] | Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996. |
IV. Процедуры регистрации
1. Введение
Современные протоколы Интернет с самого начала создавались таким образом, чтобы их было легко расширить или модернизировать. В частности, MIME [RFC-2045] является открытой системой, допускающей введение новых типов объектов, символьных наборов и методов доступа без изменения базового протокола. Однако необходим процесс регистрации, чтобы гарантировать, что набор таких значений соответствует стандарту и может использоваться в общедоступных сетях.
Здесь рассматриваются процедуры регистрации, которые осуществляются через IANA (Internet Assigned Numbers Authority), центральной инстанции для решения этих проблем.
Процесс регистрации для типов среды был первоначально определен в контексте асинхронной почтовой среды Интернет. В этой почтовой среде существует необходимость ограничить число возможных типов среды, чтобы увеличить вероятность успешного взаимодействия с удаленной почтовой системой, когда ее возможности заранее не известны.
2. Регистрация типа среды
Регистрация нового типа среды начинается с формирования регистрационного предложения. Регистрация может произойти в рамках различных регистрационных схем (деревьев), которые предполагают различные требования. Вообще, новое регистрационное предложение оценивается и рассматривается в зависимости от используемой схемы (дерева). Тип среды затем регистрируется, если предложение оказывается приемлемым.
2.1. Деревья регистрации и имена субтипов
Для того чтобы увеличить эффективность и гибкость процесса регистрации различные структуры субтипов имен могут быть зарегистрированы так, чтобы удовлетворить различным естественным требованиям, например, субтип, который будет рекомендованa для широкого использования сообществом Интернет или субтип, который используется для переноса файлов, ассоциированных с некоторой частной программой. Последующие субсекции данного документа определяют регистрационные "деревья", отличающиеся использованием стандартной формы имен (например, имен вида "tree.subtree...type"). Заметим, что некоторые типы среды определены до появления данного документа и их имена не согласуются с данной схемой. Смотри приложение A, где рассматривается эта проблема.
2.1.1. IETF-дерево
Дерево IETF служит для типов, представляющих общий интерес для сообщества Интернет. Регистрация в IETF требует одобрения IESG и публикации данного типа среды в каком-то документе RFC.
Типы среды в IETF-дереве обычно обозначаются именами, которые не оформлены стандартным образом, т.е., не содержат символов точка (".", полный останов).
"Хозяином" регистрации типа среды в рамках дерева IETF предполагается сама группа IETF. Модификации или изменения спецификации требуют той же процедуры, что и регистрация.
2.1.2. Дерево производителя (Vendor Tree)
Дерево производителя используется для типов среды, соответствующих определенным коммерческим продуктам.
Результат регистрации может быть ассоциирован с деревом производителя тем, кто нуждается в замене файлов, сопряженных с определенным программным продуктом. Однако регистрация формально принадлежит производителю или организации, разработавшей программу или формат.
Регистрация в рамках дерева производителя выделяется с помощью префикса имени "vnd.". Далее может следовать имя известного производителя (например, "vnd.lapot"), адрес производителя или место расположения программы, заключительная секция имени может содержать наименование типа среды (например, vnd.bigcompany.funnypictures).
2.1.3. Частное дерево
Регистрация типов среды, созданных с экспериментальными целями, могут быть зарегистрированы в рамках частного дерева. Регистрация такого вида имеет префикс имени "prs.". Хозяином "частной" регистрации и соответствующих спецификаций является человек или объект, осуществивший регистрацию. Публикация частных типов среды не требуется.
2.1.4. Специальное `x.'-дерево
Для удобства и симметрии со схемой регистрации имена типов среды, начинающиеся с "x." могут использоваться для тех же целей, что и имена, начинающиеся с "x-". Эти типы не являются зарегистрированными и могут использоваться партнерами при взаимном согласии.
Однако при упрощенной процедуре регистрации, описанной выше для частных типов и типов среды производителей трудно себе представить ситуацию, когда бы возникла необходимость использования незарегистрированных типов среды.
2.1.5. Дополнительные регистрационные деревья
От случая к случаю как этого требует сообщество, IANA может по согласованию с IESG, создать новое регистрационное дерево верхнего уровня. Предполагается, что такие деревья могут быть созданы для внешней регистрации и управления, например научными сообществами для их внутреннего использования. Вообще, качество рассмотрения спецификаций для этих деревьев регистрации должно быть столь же тщательным, как и в случае IETF. О создании этих новых деревьев уведомляет публикация RFC, одобренная IESG.
2.2. Требования регистрации
Предложения регистрации среды должны соответствовать требованиям изложенным ниже в последующих разделах. Заметим, что требования могут иной раз зависеть от дерева регистрации.
2.2.1. Требования функциональности
Типы среды должны функционировать как настоящий формат среды. Регистрация вещей, которые относятся в большей мере к транспортному кодированию, выбору символьного набора не допускается. Например, хотя существуют приложения, которые осуществляют транспортное декодирование base64 [RFC-2045], base64 не может быть зарегистрировано в качестве типа среды. Это требование не зависит от используемого регистрационного дерева.
2.2.2. Требования к именам
Всем зарегистрированным типам среды должны быть присвоены имена типов и субтипов MIME. Комбинация этих имен служит в дальнейшем для идентификации типа среды и формата субтипа.
При выборе имени типа верхнего уровня должна учитываться природа типа среды. Например, среда, используемая для представления статической картинки должна быть субтипом типа изображение, в то время как среда, способная представлять звуковую информацию должна принадлежать аудио типу. Для получения дополнительной информации смотри RFC-2046.
Новые субтипы типов верхнего уровня должны соответствовать регламентациям этого уровня. Например, все субтипы типа составных данных должны использовать один и тот же синтаксис инкапсуляции.
В некоторых случаях новый субтип среды может не вполне согласовываться с определенным на текущий момент типом содержимого верхнего уровня. Если такое произошло, следует определить новый тип верхнего уровня, который бы согласовывался с данным субтипом. Такое определение должно быть выполнено согласно стандартной процедуре и опубликовано в RFC. Это требование не зависит от используемого регистрационного дерева.
2.2.3. Требования к параметрам
Типы среды могут использовать один или более параметров MIME, некоторые параметры могут оказаться автоматически доступными для типа среды в случае, когда они применимы ко всему семейству субтипов. В любом случае имена, величины и назначение любого параметра должны быть полностью специфицированы при регистрации типа среды в рамках дерева IETF. Они должны быть специфицированы как можно полнее, когда тип среды регистрируется в рамках частного дерева или дерева производителя.
Новые параметры не могут определяться с целью расширения функциональности для типов, зарегистрированных в рамках дерева IETF. Но новые параметры могут быть добавлены для передачи дополнительной информации, которая не изменяет существующую функциональность.
2.2.4. Требования к канонизации и формату
Все зарегистрированные типы среды должны использовать один канонический формат данных вне зависимости от дерева регистрации. Спецификация формата каждого типа среды необходима для всех типов зарегистрированных для дерева IETF, эта информация должна присутствовать и в предложении для регистрации типа среды. Спецификации формата и особенностей обработки могут быть, а могут и не быть общедоступны для типов среды, зарегистрированных для дерева производителя. В предложения регистрации такого вида включаются только спецификации программы и ее версии пригодной для работы с данным типом среды. Включение спецификаций формата или ссылки на них в предложение регистрации желательно, но не обязательно.
Спецификации формата необходимы для регистрации в рамках частного дерева, они могут быть опубликованы в RFC или помещены в депозитарий IANA. Спецификации, помещаемые в депозитарий должны отвечать тем же требованиям, что и регистрируемые.
Некоторые типы среды включают в себя патентованные технологии. Регистрация типа среды, включающего в себя патентованные технологии, также разрешена. Однако устанавливаются ограничения (RFC-1602) на применение патентованных технологий в рамках стандартных протоколов.
2.2.5. Рекомендации по взаимозаменяемости
Типы среды должны быть способны работать с максимально возможным числом систем и приложений. Однако некоторые типы среды неизбежно будут иметь проблемы при работе на некоторых платформах. Могут возникнуть трудности из-за различных версий, порядка байт, специфики работы шлюза и т.д.
Способность работы с любыми типами среды не требуется, но желательно, чтобы были четко описаны границы применимости. Публикация типа среды не предполагает исчерпывающего обзора возможностей работы с различными платформами и приложениями.
2.2.6. Требования к безопасности
Рассмотрение аспектов безопасности необходимо для всех типов, регистрируемых в рамках IETF-дерева. Аналогичный анализ для типов среды регистрируемых в рамках частного дерева или дерева производителя рекомендуется, но не является обязательным. Однако вне зависимости от того что анализ безопасности мог проводиться или нет, все описания соображений по безопасности должны быть выполнены крайне аккуратно вне зависимости от дерева регистрации. В частности, заявление, что "никакие соображения безопасности не сопряжены с этим типом" не следует путать с "безопасность сопряженная с данным типом не анализировалась и не оценивалась".
Не существует требования, чтобы регистрируемые типы среды были безопасны и не несли в себе каких либо рисков. Несмотря на это, все известные риски должны быть идентифицированы при регистрации типа вне зависимости от используемого дерева.
Секция безопасности подлежит дальнейшему развитию. Некоторые аспекты, которые следует учитывать при анализе безопасности типа среды, перечислены ниже.
| (1) | Комплексные типы среды могут включать в себя директивы, которые определяют действия над файлами или другими ресурсами получателя. Во многих случаях для отправителя перечисляются действия, которые могут вызвать разрушительные последствия. Смотри регистрацию типа среды application/postscript в RFC-2046 в качестве примера таких директив. |
| (2) | Сложные типы среды могут включать директивы, определяющие действия, которые сами по себе безвредны для получателя, но могут вызвать раскрытие конфиденциальных данных или упростить последующие атаки или нарушить конфиденциальность для получателя каким-либо способом. Регистрация типа среды application/postscript иллюстрирует, как следует обрабатывать такие директивы. |
| (3) | Тип среды могут быть ориентированы на применения, которые требуют определенного уровня безопасности, но не предоставляют самих механизмов безопасности. Например, тип среды может быть предназначен для запоминания конфиденциальной медицинской информации, которая в свою очередь требует внешней системы обеспечения секретности. |
В асинхронных почтовых системах, где информация о возможностях удаленного почтового агента часто не доступна для отправителя, максимум взаимодействия может быть достигнут путем ограничения числа типов среды, используемых для общих форматов, которые предполагается широко внедрять. Именно эта концепция, принятая в прошлом, явилась причиной ограничения числа возможных типов среды и привела к формированию процесса регистрации типов среды.
Однако необходимость в "общих" типах среды не требует ограничения регистрации новых типов. Если для определенного приложения рекомендуется ограниченный набор типов среды, это должно быть определено отдельным заявлением применимости для приложения или среды реализации.
2.2.7. Требования к публикации
Предложения для типов среды регистрируемых в рамках IETF-дерева должны публиковаться в виде RFC. RFC-публикации типа среды производителя или частного типа среды желательны, но не обязательны. Во всех случаях IANA сохраняет копии всех предложений по типам среды и публикует их как часть самого регистрационного дерева типов среды.
Дерево IETF существует для типов среды, которые действительно требуют серьезного анализа и стандартного процесса одобрения, в то время как деревья производителей и частные деревья такой процедуры не требуют. Ожидается, что заявления о применимости для конкретных приложений будут публиковаться время от времени для типов среды, которые доказали свою эффективность в определенных контекстах.
Как было обсуждено выше, регистрация типа среды верхнего уровня предполагает стандартную процедуру принятия и, следовательно, обязательную RFC-публикацию.
2.2.8. Дополнительная информация
Различные виды опционной информации могут быть включены в спецификацию типа среды, если таковые имеются:
| (1) | Магические числа (длина, значения октетов). Магические числа представляют собой байтовые последовательности, которые всегда имеются и по этой причине могут использоваться для идентификации объектов, принадлежащих данному типу среды. |
| (2) | Расширения имени файлов, используемые на одной или более платформах для индикации того, что файл содержит данный тип среды. |
| (3) | Код типа файла Macintosh (4 октета) используется для маркировки файлов, содержащих данный тип среды. |
Такая информация часто оказывается весьма полезной и, если имеется, то должна предоставляться.
2.3. Процедура регистрации
Следующая процедура была применена IANA для обзора и одобрения новых типов среды. Для регистрации в рамках дерева IETF, нужно следовать обычной процедуре, осуществляя на первом этапе рассылку интернет-проекта. Для регистрации в рамках частного дерева или дерева производителя осуществляется без широкого обсуждения. Проект непосредственно направляется IANA (по адресу iana@iana.org).
2.3.1. Представление типа среды на суд сообщества
Все начинается с посылки предложения регистрации типа среды лист-серверу ietf-types@iana.org. Отклики ожидаются в течение двух недель. Этот подписной лист был учрежден для целей обсуждения предлагаемых типов среды и доступа. Предложенные типы среды, если они формально не зарегистрированы, не могут быть использованы; префикс "x-", специфицированный в RFC-2045, может применяться до тех пор, пока процесс регистрации не завершится.
Типы среды, регистрируемые в рамках дерева IETF должны представляться на одобрение IESG.
Получив подтверждение, что тип среды отвечает всем требованиям, автор может послать запрос регистрации IANA, которая зарегистрирует тип среды и сделает его доступным для всего сообщества.
2.4. Комментарии по поводу регистрации типа среды
Комментарии по поводу регистрации типа среды могут быть направлены членам сообщества IANA. Эти комментарии будут переданы "хозяину" типа среды. Комментаторы могут потребовать, чтобы их замечания были присовокуплены к материалам регистрации данного типа среды и, если IANA одобрит это, такая процедура будет произведена.
2.5. Расположение списка зарегистрированных типов среды
Материалы регистрации типа среды доступны через анонимный FTP сервер ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/, а все зарегистрированные типы среды будут перечислены в периодически обновляемом документе "Assigned Numbers" RFC [в настоящее время STD-2, RFC-1700]. Описания типа среды и другие материалы могут быть также опубликованы в виде информационных RFC путем посылки документа по адресу "rfc-editor@isi.edu" [RFC-1543].
2.6. Процедура регистрации типа среды в IANA
IANA регистрирует типы среды, принадлежащие дереву IETF. Частные типы и типы среды производителя регистрируются IANA автоматически и без формального обсуждения, если выполнены следующие условия:
| (1) | Типы среды должен функционировать как истинный формат среды. В частности, символьный набор или транспортное кодирование не могут быть зарегистрированы в качестве типа среды. |
| (2) | Все типы среды должны иметь корректно сформированные имена типа и субтипов. Все имена типов должны быть определены стандартным образом. Все имена субтипов должны быть уникальными, должны соответствовать грамматике MIME и содержать корректный префикс дера |
| (3) | Типы, регистрируемые в рамках частного дерева, должны быть снабжены спецификацией формата, или указателем на такую спецификацию. |
| (4) | Любые соображения по безопасности должны отражать объективную ситуацию и быть корректными. IANA не проводит экспертизу, но откровенно некомпетентные материалы отбрасываются. |
2.7. Управление изменением
Раз тип среды опубликован IANA, автор может потребовать изменения его описания. Запрос изменения оформляется также как и сама регистрация:
| (1) | Рассылка пересмотренной заявки регистрации через подписной лист ietftypes. |
| (2) | Ожидание в течение двух недель комментариев. |
| (3) | Публикация после формального обсуждения IANA, если это необходимо. |
Изменения следует делать лишь при обнаружении серьезных упущений или ошибок в опубликованной спецификации.
Владелец типа содержимого может передать ответственность за него другому лицу или организации, проинформировав об этом IANA и список рассылки ietf-типов. Это может быть сделано без обсуждения.
IESG может переадресовать ответственность за определенный тип среды. Наиболее общим случаем является разрешение изменений в описании типа среды в ситуации, когда автор исходного документа умер, эмигрировал или стал недоступен и не может внести изменения крайне важные для сообщества пользователей.
Регистрации типа среды не могут быть аннулированы. Типы среды, которые не используются более, объявляются устаревшими (OBSOLETE) путем изменения их поля "intended use" (область применения). Такие типы среды будет помечены соответствующим образом и в списках, публикуемых IANA.
2.8. Регистрационный шаблон
To: ietf-types@iana.org
Subject: Registration of MIME media type XXX/YYY(Регистрация типа среды MIME)
| MIME media type name: | (Имя типа среды MIME) |
| MIME subtype name: | (Имя субтипа среды MIME) |
| Required parameters: | (Необходимые параметры) |
| Optional parameters: | (Опционные параметры) |
| Encoding considerations: | (Соображения по кодированию) |
| Security considerations: | (Соображения безопасности) |
| Interoperability considerations: | (Соображения совместимости) |
| Published specification: | (Опубликованная спецификация) |
| Applications which use this media type: | (Приложения, использующие данный тип среды) |
| Additional information: | (Дополнительная информация) |
| Magic number(s): | (Магические числа) |
| File extension(s): | (Расширение имени файла) |
| Macintosh File Type Code(s): | (Код типа файла Macintosh) |
| Person & email address to contact for further information: | (Контактный адрес) |
| Intended usage: (Одно из COMMON, LIMITED USE или OBSOLETE) | (Возможное применение) |
| Author/Change controller: | (Автор/ответственный) Сюда может быть добавлена любая другая информация на усмотрение автора. |