В 1992 г. была сформирована Ассоциация Интернета (Internet Society), в которую и вошла IAB. Целью Internet Society является помощь в расширении и обеспечении успешной работы Интернета.
IAB контролировала несколько важных групп: рабочую группу технологии Интернета (Internet Engineering Task Force — IETF), которая разрабатывает и реализует новые протоколы, управляющую группу технологии Интернета (Internet Engineering Steering Group — IESG), которая осуществляет руководство и контроль за деятельностью IETF.
1.6.1 Рабочие группы и разработка протоколов
Членство в IETF является добровольным. Для решения определенной проблемы формируется рабочая группа из технических экспертов. Члены такой группы разрабатывают методологии, объединяющие теоретические исследования с последующей реализацией.
Реально правильность и полнота спецификации протокола проверяются при создании двух независимых версий одного протокола. Далее следует процесс разработка-реализация-эксперимент-пересмотр, позволяющий улучшить и расширить спецификацию протокола, равно как и повысить производительность ее реализации.
На практике при разработке протокола происходит устранение многих недостатков и пересмотр многих первоначальных положений еще до того, как спецификация протокола будет одобрена. В архитектуру протоколов стараются не закладывать слишком большие требования к системным ресурсам или решения, снижающие общую производительность систем.
1.6.2 Другие источники протоколов Интернета
Хотя большинство протоколов TCP/IP разрабатывается и реализуется рабочими группами IETF, существенное участие в этом процессе принимают исследовательские группы из университетов и коммерческих организаций. Чтобы независимые проекты получили одобрение, они должны быть и пригодны, и полезны.
Исходные коды новых протоколов часто помещаются в общедоступные базы данных Интернета. Разработчики могут использовать эти коды как отправную точку в своих собственных реализациях. Такой метод имеет множество преимуществ. Прежде всего, снижается стоимость разработки и время ее проведения. Одинаковые исходные коды позволяют также достичь согласования в работе продуктов от различных разработчиков.
Пользователи могут копировать и устанавливать исходные коды протоколов на свои системы. Разумеется, применение бесплатных программных продуктов не предусматривает технической поддержки и обслуживания, предоставляемых разработчиками для коммерческих реализаций.
1.7 Requests For Comments
Спецификации новых протоколов распространяются в документах, называемых запросами комментариев (Requests For Comments — RFC). Все документы RFC имеют последовательные номера. На сегодняшний день существует уже более тысячи таких документов.
Пользователи могут получить RFC в службе каталогов и баз данных InterNIC. Кроме того, эти документы существуют на множестве общедоступных сайтов по всему миру, поскольку разрешено их свободное копирование между любыми сайтами Интернета посредством пересылки файлов.
Иногда спецификации протоколов подвергаются изменениям, например вследствие исправления обнаруженных ошибок, а также для повышения производительности или добавления новых возможностей. Измененные протоколы публикуются в RFC с новыми номерами.
InterNIC обслуживает индексы для RFC, а для устаревших документов предоставляется номер заменяющего RFC. Например, индекс для RFC 1098 (стандарт SNMP) содержит ссылки на устаревший документ RFC (1067) и пополняющий RFC 1098 документ с номером 1157:
1098 Case, J.D.; Fedor, М.; Schoffstall, M.L.; Davin, С.
Simple Network Management Protocol (SNMP). 1989 April; 34p.
(Format: TXT=71563 bytes) (Obsoletes RFC 1067; Updated by RFC 1157)
He все RFC описывают протоколы. Некоторые из них служат для систематизации и описания сведений, используемых в Интернете. Существует RFC с рекомендациями по выбору имен для компьютеров. Другой RFC содержит руководство по администрированию сетей TCP/IP и реализации в них средств безопасности. Имеются RFC, описывающие стратегии повышения производительности, экспериментальные алгоритмы или обсуждающие этические вопросы Интернета. После пересмотра некоторые RFC получают статус документов Best Current Practices — BCP (описание лучшего текущего способа применения).
1.7.1 Состояние и статус стандартов
IAB периодически публикует информацию о работе над протоколами. Стадии разработки определяют текущее состояние протокола:
■ Experimental (экспериментальный)
■ Proposed (предлагаемый)
■ Draft (черновик)
■ Standard (стандарт)
Некоторые протоколы маркируются как информационные (informational), другие, не использующиеся в настоящее время,— как исторические (historical).
Протоколы классифицируются также по уровню требований. Некоторые протоколы являются стандартами, другие применяются только в специальных целях. Отдельные протоколы утратили свою полезность, и их применение отменено. Формальные требования отражают статус протокола:
■ Required (требуется использовать)
■ Recommended (рекомендован к применению)
■ Elective (необязателен)
■ Limited Use (ограниченное использование)
■ Not recommended (не рекомендован к применению)
Текущий статус и состояние протоколов Интернета описываются в RFC, называемом IAB Official Protocol Standards (официальные стандарты протоколов IAB). Этот документ периодически изменяется, отражая изменение номеров RFC.
1.7.2 Присвоенные номера
Сетевые параметры, специальные сетевые адреса, имена служб и стандартные идентификаторы терминалов либо компьютерных систем перечислены в RFC с именем Assigned Numbers (присвоенные номера).
Присвоенные номера Интернета администрируются организацией авторизации присвоенных номеров (Internet Assigned Numbers Authority — IANA), расположенной в настоящее время в Институте информационных служб университета Южной Калифорнии.
Документ Assigned Numbers содержит почтовые адреса, номера телефонов и адреса электронной почты, которые разработчики протоколов могут использовать для регистрации информации об авторизации.
1.7.3 RFC и стимулирование сетевого взаимодействия продуктов различных производителей
То, что пользователи не должны придерживаться только одной компьютерной архитектуры, стало главной причиной одобрения TCP/IP в качестве коммуникационных стандартов правительственными учреждениями США. Эти организации желали покупать оборудование на рынке с реальной конкуренцией, когда предъявляемым требованиям удовлетворяет продукция различных разработчиков. Принятие и обслуживание стандартов должно было привести к снижению цен и лучшему качеству услуг.
Однако при использовании оборудования различных производителей возникает несколько проблем:
■ Стандарты часто содержат необязательные возможности. При реализации различными производителями это может усложнить взаимодействие.
■ Разработчики иногда не до конца понимают требования стандартов, вследствие чего их продукты работают не вполне корректно.
■ Возможны ошибки в спецификациях стандартов.
■ Некоторые реализации, даже при аккуратном соблюдении системным администратором всех требований, могут не обеспечивать должной гибкости и более точной настройки конфигурационных параметров для повышения производительности.