AAA

RFC 4084 — Терминология для описания услуг по подключению к Internet

Статус документа

В этом документе рассматривается позитивный опыт (Best Current Practices), который может быть полезен сообществу Internet. Документ служит приглашением к дискуссии в целях дальнейшего совершенствования и может распространяться свободно.

Тезисы

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

Оглавление

1. Введение

1.1. Проблема и требования

Различные поставщики услуг доступа в Internet (ISP) и другие провайдеры предлагают широкий спектр продукции и услуг, обозначаемых как "Internet" или "доступ в Internet". Эта продукция характеризуется различным набором функций и, в результате, может оказаться подходящей для одних пользователей и совершенно неприемлемой для других. Например, сервис, который обеспечивает только доступ в Web (в контексте этого документа — часть Internet, доступная по протоколам HTTP и HTTPS), может устроить тех, кто интересуется исключительно Web-серверами и почтовыми системами на базе Web. Однако такой сервис не подойдет тем, кто хочет загружать из сети файлы или использовать электронную почту более интенсивно. Очевидно, что еще меньше такой сервис подойдет тем, кто предоставляет свои серверы для других пользователей или нуждается в каналах VPN (виртуальные частные сети) или иных системах организации защищенного доступа в удаленный офис, а так же тем, кому нужна синхронизация электронной почты для работы с ней без постоянного доступа в сеть (offline).

Недавние и быстротекущие изменения в среде электронной почты Internet привели к дополнительным ограничениям на передачу и получение (retrieving) почты. Эти ограничения, большинство из которых разработаны как часть системы предотвращения спама, могут вводиться независимо от типа сервиса, описанного ниже, и рассматриваются отдельно в главе 3.

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

Термины SHOULD (следует), MUST (должно), и MAY (можно) выделяются в этом документе, как описано в [1].

1.2. Адаптация терминов

Приведенные здесь определения будут иметь мало смысла, если сервис-провайдеры не примут их. Предложенные здесь термины не следует рассматривать как «уничижительные», несмотря на то, что ряд членов сообщества IETF считает некоторые из описанных здесь типов сервиса «забытыми» (broken) или не относящимися к "Internet-сервису» (not really an Internet service). Упоминание того или иного типа сервиса или модели в данном документе не является подтверждением или признанием существования или возможности существования его на реальном рынке. Таким образом, опыт (Best Current Practice), описываемый в этом документе, относится к терминологии, а приведенная информация предназначена для пользователей и не задает типов сервиса, которые следует предлагать.

2. Общая терминология

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

Определения типов обслуживания приводятся в порядке возрастания возможностей вплоть до полнофункционального подключения к Internet.

3. Терминология, относящаяся к фильтрации и безопасности

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

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

Некоторые вопросы фильтрации электронной почты имеют особую важность и рассмотрены ниже:

4. Дополнительные термины

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

Потенциальные заказчики могут использовать эти термины для оценки услуг того или иного провайдера:

5. Вопросы безопасности

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

6. Благодарности

Толчком к созданию этого документа послужила переписка по электронной почте с Верноном Шрайнером (Vernon Schryver), Паулем Викси (Paul Vixie) и Натаниэлем Борнстейном (Nathaniel Bornstein). Разговоры о необходимости разработки таких определений велись уже много лет, упомянутая переписка убедила автора в том, что настало время перейти от слов к делу. Harald Alvestrand, Brian Carpenter, George Michaelson, Vernon Schryver и другие внесли в черновой вариант документа предложения, которые позволили подготовить новый черновой вариант. Stephane Bortzmeyer, Brian Carpenter, Tony Finch, Susan Harris, David Kessens, Pekka Savola и Vernon Schryver внесли много полезных предложений в последующие версии документа. Сьюзан Харрис (Susan Harris) внимательно прочла предпоследнюю версию документа и внесла поправки как редактор (RFC Editor).

7. Литература

  1. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  2. Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
  3. Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.

Адрес автора

John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140 USA
Phone: +1 617 491 5735
EMail: moc.kcj@ftei-nhoj

Перевод на русский язык

Николай Малых, moc.milib@hkylamn