Кто такое RFC?

Вашему вниманию предлагается рубрика, в которой планируется обсуждение различных вопросов, связанных со стандартизацией Интернет. В ближайших номерах будут освещены такие темы, как общие концепции принятия стандартов, организации стандартизации и управления в Интернет. Также планируется рассмотрение ситуаций, когда текущее положение дел (de facto) в некой технологии не соответствует стандарту (de jure), либо наоборот - некоторые полезные возможности, заложенные в спецификацию, на практике не находят применения по причине незнания либо предубеждения. Редакция охотно рассмотрит ваши предложения, замечания относительно необходимости и содержания такой рубрики, а также постарается ответить в рамках газеты на ваши вопросы по данной проблеме.

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

Применительно к интернет технологиям -- это серия документов RFC (Request For Comments), над подготовкой которых работает плеяда, не побоюсь сказать, лучших умов современного сетевого сообщества - представители университетский и корпоративной науки, энтузиасты-одиночки, а также сотрудники разного сорта стандартизующих организаций и комитетов.

После написания каждый документ проходит жизненный цикл, который называется Internet Standards Track. Очень кратко перечислим основные вехи в жизни каждого потенциального стандарта:

I-D (Internet Draft).Черновик. Эта первая стадия жизни, на которой документ публикуется в специальной рубрике черновиков для ознакомления, внесения дополнений. Одновременно может быть подан запрос на публикацию документа как RFC, для чего черновик должен получить одобрение уважаемой организации IESG (см. След. Номер).

Experimental или Informational.При попадании в гордые ряды RFC документ получает один из этих статусов - на выбор. Экспериментальный статус означает, что документ является частью некого научного исследования или разработки и публикуется скорее как некая архивная запись эирго процесса. Информационный статус предполагает, что документ публикуется для информирования сетевого сообщества и не подразумевает под собой одобренности либо достижения консенсуса со стороны интернет-сообщества.

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

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

Internet Standard.Высшая ступень развития документа RFC. Спецификации, получившие широкое применение и успешно показавшие себя на практике могут быть переведены в раздел Интернет Стандартов. Технологии, описанные в данных документах, отличаются высоким техническим уровнем и признаются Интернет-сообществом как исключительно успешные и полезные для повсеместного распространения.

Конечной инстанцией выступает так называемый RFC Editor (редактор), который приводит все это хозяйство в законченный, структурированный вид и публикует на своем веб-сервере, откуда документы рассасываются по бесчисленным зеркалам - коллекциям RFC, с удобными интерфейсами, классификаторами и возможностью полнотекстового поиска. Я, например, предпочитаю www.faqs.org/rfcs.

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

2703 Protocol-independent Content Negotiation Framework
Сентябрь 1999. Статус: INFORMATIONAL

2704 The KeyNote Trust-Management System Version 2.
Сентябрь 1999. Статус: INFORMATIONAL

2705 Media Gateway Control Protocol (MGCP) Version 1.0.
Октябрь 1999. Статус: INFORMATIONAL

2706 ECML v1: Field Names for E-Commerce.
Октябрь 1999. Статус: INFORMATIONAL

2709 Security Model with Tunnel-mode IPsec for NAT Domains
Октябрь 1999. Статус: INFORMATIONAL

2710 Multicast Listener Discovery (MLD) for IPv6.
Октябрь 1999. Статус: PROPOSED STANDARD

2711 IPv6 Router Alert Option.
Октябрь 1999. Статус: PROPOSED STANDARD

2712 Addition of Kerberos Cipher Suites to Transport Layer Security (TLS).
Октябрь 1999. Статус: PROPOSED STANDARD

2713 Schema for Representing Java(tm) Objects in an LDAP Directory.
Октябрь 1999. Статус: INFORMATIONAL

2714 Schema for Representing CORBA Object References in an LDAP Directory.
Октябрь 1999. Статус: INFORMATIONAL

2715 Interoperability Rules for Multicast Routing Protocols.
Октябрь 1999. Статус: INFORMATIONAL

2716 PPP EAP TLS Authentication Protocol.
Октябрь 1999. Статус: EXPERIMENTAL

2717 (BCP35) Registration Procedures for URL Scheme Names.
Ноябрь 1999. Статус: BEST CURRENT PRACTICE

2718 Guidelines for new URL Schemes
Ноябрь 1999. Статус: INFORMATIONAL

2719 Framework Architecture for Signaling Transport.

Октябрь 1999. Статус: INFORMATIONAL

2720 Traffic Flow Measurement:
Октябрь 1999. Заменяет устаревший RFC2064 Статус: PROPOSED STANDARD

2721 RTFM: Applicability Statement
Октябрь 1999. Статус: INFORMATIONAL

2722 Traffic Flow Measurement: Architecture
Октябрь 1999. Статус: INFORMATIONAL

2723 SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups.
October 1999. Статус: INFORMATIONAL

2724 RTFM: New Attributes for Traffic Flow Measurement
Октябрь 1999. Статус: EXPERIMENTAL

2728 The Transmission of IP Over the Vertical Blanking Interval of a Television Signal.
Ноябрь 1999. Статус: PROPOSED STANDARD


Сетевые решения. Статья была опубликована в номере 13 за 2000 год в рубрике RFC

©1999-2024 Сетевые решения