Новые RFC и комментарии к ним

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

2860 Memorandum of Understanding Concerning the Technical Work of the

Internet Assigned Numbers Authority. B. Carpenter, F. Baker, M.

Roberts. June 2000. (Format: TXT=12361 bytes) (Status: INFORMATIONAL)

Совершенно IMHO идиотический документ: соглашение между ICANN и IETF напредмет того, кому рулить ранее независимой организацией IANA. В первых номерах “СР” мы достаточно подробно рассматривали вопросы, касаемые деятельности этих замечательных структур, поэтому повторяться, пожалуй, не будем. Но еще в те незапамятные времена я оговорилась в своем материале, что вся эта замечательная компания ну никак не может друг с другом договориться и поделить сферы влияния и ответственности. И вот еще одна чахлая попытка – RFC 2860. Вдумчиво прочитав это чудо раз эдак 5 я пришла к выводу: совковые бюрократические традиции “отдыхают” перед лицом бюрократов из ICANN ;). Вот смотрите какой замечательный абзац:

“IANAбудет назначать и регистрировать параметры протокола интернет только как предписывается криетриями и процедурами, специфицированными в RFC, включая предложенные, черновые и полные интернет-стандарты и документы BCP (Best Current Practice); а также в любых других RFC, запрашивающих назначение (assignment) у IANA. Если они (критерии и требования, надо понимать – прим ред.) не специфицированы таки образом или в случае неоднозначностей и неопределенностей, IANA продолжает назначать и регистрировать параметры протокола интернет, которые традиционно регистрировались IANA, руководствуясь для таких назначений бывшими и текущими методами, если другое не предписываетсяIESG.”

И все в таком духе %-( В общем, особо извращенным любителям канцелярита советую непременно ознакомиться с вышеозначенным меморандумом.

2861 TCP Congestion Window Validation. M. Handley, J. Padhye, S.

Floyd. June 2000. (Format: TXT=26993 bytes) (Status: EXPERIMENTAL)

В TCP окно перегрузки (Congestion Window, cwnd) контролирует количество пакетов, которые могут путешествовать в сети в каждый момент времени. Оно предназначено для управления потоком данных со стороны отправителя, блокируя возможные перегрузки и потери данных. However, длинные периоды когда отправитель простаивает или объем отправляемых данных ограничен уровнем приложения (application-limited), могут привести к недостоверности окна перегрузки, то есть значение cwnd в таких случаях уже не отражает текущей информации о состоянии сети. Данная (пока – экспериментальная) спецификация описывает простой метод модификации алгоритма изменения размера окна перегрузки. Суть в следующем:

После достаточно большого времени простоя отправителя “старое” окно перегрузки разрушается, при этом значение порога медленного старта (ssthresh) используется для сохранения информации о предыдущем (“старом”) значенииcwnd.

Авторы спецификации указывают на такую проблему: неверное значение окна перегрузки является также результатом увеличения cwnd в моменты простоя, когда и предыдущее значение cwnd нив коем разе не может быть полностью утилизировано. Таки образом предлагается заствать модуль TCP “пасти” ситуацию напредмет сотояний простоя и при обнаружении оных принимать следующие меры: при возобновление передачи после периода простоя снизить значение cwnd наполовину, установить размер ssthresh максимум в ¾ старого значения cwnd и затем осуществлять “быстрый медленный старт”, возвращаясь к исходному значению окна перегрузки.

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

2862 RTP Payload Format for Real-Time Pointers. M. Civanlar, G. Cash.

June 2000. (Format: TXT=12031 bytes) (Status: PROPOSED STANDARD)

2863 The Interfaces Group MIB. K. McCloghrie, F. Kastenholz. June

2000. (Format: TXT=155014 bytes) (Obsoletes RFC2233) (Status: DRAFT

STANDARD)

2864 The Inverted Stack Table Extension to the Interfaces Group MIB.

K. McCloghrie, G. Hanson. June 2000. (Format: TXT=21445 bytes)

(Status: PROPOSED STANDARD)

2865 Remote Authentication Dial In User Service (RADIUS). C. Rigney,

S. Willens, A. Rubens, W. Simpson. June 2000. (Format: TXT=146456

bytes) (Obsoletes RFC2138) (Updated by RFC2868) (Status: DRAFT

STANDARD)

2866 RADIUS Accounting. C. Rigney. June 2000. (Format: TXT=51135

bytes) (Obsoletes RFC2139) (Updated by RFC2867) (Status:

INFORMATIONAL)

2867 RADIUS Accounting Modifications for Tunnel Protocol Support. G.

Zorn, B. Aboba, D. Mitton. June 2000. (Format: TXT=51135 bytes)

(Updates RFC2866) (Status: INFORMATIONAL)

2868 RADIUS Attributes for Tunnel Protocol Support. G. Zorn, D.

Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goyret. June 2000.

(Format: TXT=42609 bytes) (Updates RFC2865) (Status: INFORMATIONAL)

2869 RADIUS Extensions. C. Rigney, W. Willats, P. Calhoun. June 2000.

(Format: TXT=96854 bytes) (Status: INFORMATIONAL)

Опубликована целая куча разнообразных спецификаций на тему RADIUS – от Черновых Стандартов до Информационных документов. Вообще-то ААА в целом – тематика, заслуживающая уж не меньше чем пары публикаций в рубрике “расставим точки над i”, а не краткого упоминания в обзоре RFC. Так и сделаем... А там и о RADIUS’е поговорим, и о DIAMETER’е (есть и такое ;)

 2871 A Framework for Telephony Routing over IP. J. Rosenberg, H.

Schulzrinne. June 2000. (Format: TXT=60664 bytes) (Status:

INFORMATIONAL)

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

Описывается в общем виде структура маршрутизации в IP-телефонии. Значительная часть документа отведена под связянную с проблемой терминологию, а также разъяснение самой проблемы и мотивации, побудившей к разработкам в области TRIP (правда, красивая аббревиатура? ;)

Несколько курьезной показалось мне глава, уверяющая нас, что TRIP – это в некотором роде двоюродный брат BGP, но несмотря на общность концепций у них есть некоторые отличия, и по пунктам – 7 совершенно “отвязанных” посылок напредмет кардинальнейших отличий TRIP и BGP. Ну господа хорошие, вы ж за кого нас держите? ;) Даже в самом начале документа становится понятно, что ваш TRIP работает на значительно более высоком уровне OSI нежели BGP, зачем огород-то городить? ;)

Дальше следуют несколько блоков, описывающих типичные примеры использования TRIP, так сказать типичные TRIP-приложения. С очень красивыми, прошу заметить, ASCII-рисунками. Затем собственно идет описание архитектуры TRIP и основных ее элементов, куда входят административные домены IT (читай – IP-телефонии), шлюзы, конечные пользователи и так называемые location servers (LS) -- сервера, которые “знают” определенное количество шлюзов и помогают конечному пользователю определиться в выборе оных, а также могут обмениваться информацией об известных им шлюзах друг с другом. В общем, последние есть ключевая фигура архитектуры TRIP. Затем мы узнаем, каким образом могут взаимодействовать элементы друг с другом и в каких так сказать комбинациях: шлюз-LS, LS-LS. О том, как конечный пользователь может взаимодействовать с системой – в главе “Интерфейсная часть” (The Front End). Оказывается в качестве “интерфейсных” протоколов нам придлагается следующее: Service Location Protocol (SLP), Open Settlements Protocol (OSP), Lightweight Directory Access Protocol (LDAP), веб-интерфейс и... собственно сам TRIP. Как остроумно написано в абзаце про приемлемость TRIP в качестве фронт-энда, “Все протоколы, обсуждавшиеся выше, относятся к типу “запрос-ответ”. Нет никакой причины по которой доступ к LS должен осуществляться именно по такой схеме. Абсолютно допустим вариант, при котором при обращении к LS будет осуществляться полная синхронизация базы данных шлюзов, то бишь объект, доступающися к базе данных сервера (LS) может становиться счастливым обладателем ее полной копии. Если вас устраивает такой подход, сам TRIP является подходящим механизмом. Этот подход имеет очевидные недостатки, но по большому счету ничто не препятствует вам сделать именно так”. ;) Во как, очень и очень демократично %-)

Кстати весь документ написан в таком вот “разухабистом” стиле и очень приятен в освоении. И если в нашей стране вдруг грянет бум массовой IP-телефлнизации, я с удовольствием представлю на страницах газеты эту спецификацию в более развернутом виде. Конечно если за это время мировое сообщество не выдаст на гора какой-нибудь стандарт на эту тему. Anyway, господа –have a nice TRIP ;))

 

2872 Application and Sub Application Identity Policy Element for Use

with RSVP. Y. Bernet, R. Pabbati. June 2000. (Format: TXT=10933

bytes) (Status: PROPOSED STANDARD)

2873 TCP Processing of the IPv4 Precedence Field. X. Xiao, A. Hannan,

V. Paxson, E. Crabbe. June 2000. (Format: TXT=15565 bytes) (Status:

PROPOSED STANDARD)

2874 DNS Extensions to Support IPv6 Address Aggregation and

Renumbering. M. Crawford, C. Huitema, S. Thomson. July 2000. (Format:

TXT=44204 bytes) (Status: PROPOSED STANDARD)

Курьез... Прочитала ваша покорная слуга этот документ: сверху вниз, снизу вверх, по диагонали. Один, два, три раза. И все бестолку. Либо спецификация слишком трансглобальна и недоступна для восприятия среднестатистическим умом, либо написана слишком нехорошо, либо просто бестолкова и надуманна. Поэтому собственно обозреть всилу вышеозначенного я ее никак не могу, просто прицитирую раздел Abstract – главная идея, резюме. Идея такова:

“Этот документ определяет изменения в DNS для поддержкиперенумеровываемойи аггрегируемой IP-адресации. Изменения включают введение нового типа ресурсных записей (RR, Resource Record) – A6 – для хранения адресов IPv6 способом, ускоряющим перенумерацию сети, а также обновленные определения некоторых существующих типов запросов. Для реверсных запросов этот документ определяет новую структуру реверсной зоны (IP6.ARPA). Предполагается полная замена настоящей техникой спецификацииRFC 1886(о типе ресурсной записи АААА), с переводом последней в разрядHistorical...”

Мда... У господина C. Huitema, соавтора как предыдущей (АААА), так и описываемой (А6) спецификаций на эту тему, явно что-то сделалось с мышлением после перехода на работу в Microsoft Corporation. В АААА тот же автор показывал полную ясность мысли и письменной речи. А теперь...

На самом деле, настоятельно рекомендую ознакомиться с данным RFC, потому как все-таки Предложенный Стандарт, не этот... Internet-Draft ;)) И скоро вам, уважаемые DNS-администраторы, вести зоны ответственности, подобные вот этой (фрагмент):

$ORIGIN X.EXAMPLE.

N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6

SUBNET-1.IP6 A6 48 0:0:0:1:: IP6

IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.

IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.

SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET.

SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET.

SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET.

A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG.

A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG.

B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG.

C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0::

D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0::

E.NET.ALPHA-TLA.ORG. A6 0 2345:000E::

или вот этой (фрагмент):

$ORIGIN EXAMPLE. ; first option

X NS NS1.X

NS NS2.X

NS1.X A6 64 ::1:11:111:1111 SUBNET-1.IP6.X

NS2.X A6 64 ::2:22:222:2222 SUBNET-2.IP6.X

SUBNET-1.IP6.X A6 48 0:0:0:1:: IP6.X

SUBNET-2.IP6.X A6 48 0:0:0:2:: IP6.X

IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.

IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.

$ORIGIN EXAMPLE. ; second option

X NS NS1.X

NS NS2.X

NS1.X A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.A.NET.

A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.B.NET.

NS2.X A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.A.NET.

A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.B.NET.

$ORIGIN EXAMPLE. ; third option

X NS NS1.X

NS NS2.X

NS1.X A6 0 2345:00C1:CA11:1:1:11:111:1111

A6 0 2345:00D2:DA11:1:1:11:111:1111

A6 0 2345:000E:EB22:1:1:11:111:1111

NS2.X A6 0 2345:00C1:CA11:2:2:22:222:2222

A6 0 2345:00D2:DA11:2:2:22:222:2222

A6 0 2345:000E:EB22:2:2:22:222:2222

Успехов ;)

Да, кстати, если у кого-нибудь из наших уважаемых читателей, возникнет светлая идея перевести спецификацию на более эээ.... более человеческий язык – милости просим, переведите! Может быть и вправду документ интересный и полезный – пусть тогда все со страниц “СР” об этом и узнают! :)

2875 Diffie-Hellman Proof-of-Possession Algorithms. H. Prafullchandra,

J. Schaad. July 2000. (Format: TXT=45231 bytes) (Status: PROPOSED

STANDARD)

2876 Use of the KEA and SKIPJACK Algorithms in CMS. J. Pawling. July

2000. (Format: TXT=29265 bytes) (Status: INFORMATIONAL)

2877 5250 Telnet Enhancements. T. Murphy, Jr., P. Rieth, J. Stevens.

July 2000. (Format: TXT=83369 bytes) (Updates RFC1205) (Status:

INFORMATIONAL)

2878 PPP Bridging Control Protocol (BCP). M. Higashiyama, F. Baker.

July 2000. (Format: TXT=79527 bytes) (Obsoletes RFC1638) (Status:

PROPOSED STANDARD)

Как известно, протокол PPP включает в себя такие основные элементы, как LCP (Link Control Protocol) и целое семейство так называемых NCP (Network Control Protocol), обеспечивающих конфигурацию и “подымание” различных протоколов сетевого уровня по PPP-каналам. Данный документ как раз и определяет один из таких NCP – Протокол Управления Бриджингом.

Первая часть документа являет собой введение в основы бриджинга и дает определение основным его типам.

Собственно спецификация протокола описывает следующие моменты:

По сути BCP совершенно идентичен LCP, однако есть следующие исключения:

• только один BCP-пакет может быть инкапсулирован в информационное поле PPP, где поле протокола PPP равно8031 (BCP)
• Используются только коды с 1 по 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack and Code-Reject).Все остальные коды должны восприниматься как неопознанные
• Обмен BCP-пакетами не может быть начат пока PPP не достигнет фазы конфигурации протоколов сетевого уровня
• BCPимеет свой набор конфигурационных опций, которые подробно описаны в спецификации

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

 2881 Network Access Server Requirements Next Generation (NASREQNG) NAS

Model. D. Mitton, M. Beadles. July 2000. (Format: TXT=45029 bytes)

(Status: INFORMATIONAL)

2882 Network Access Servers Requirements: Extended RADIUS Practices.

D. Mitton. July 2000. (Format: TXT=31426 bytes) (Status:

INFORMATIONAL)

2898 PKCS #5: Password-Based Cryptography Specification Version 2.0.

B. Kaliski. September 2000. (Format: TXT=68692 bytes) (Status:

INFORMATIONAL)

2901 Guide to Administrative Procedures of the Internet

Infrastructure. Z. Wenzel, J. Klensin, R. Bush, S. Huter. August

2000. (Format: TXT=63680 bytes) (Also FYI0037) (Status:

INFORMATIONAL)

Легкое, но при этом программное чтение для администраторов IP-сетей, особенно корпоративно-провайдерского масштаба. Несмотря на то, что очень многие из рассматриваемых в документе вопросов уже звучали на страницах “СР”, я все больше склоняюсь к мысли опубликовать этот замечательный RFC в полном объеме. А сейчас ограничусь лишь очень кратким пересказом.

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

• запрос и регистрация адресного пространства от провайдера высшего уровня или непосредственно у “раздаточной организации”. Документ настоятельно рекомендует прежде всего обратиться к вашему провайдеру, и уже после выяснения полной невозможности получить у него адреса, предлагается обращаться к RIR (RIPE, ARIN, APNIC). Подробно описывается вся процедура регистрации адресных пространств во всех трех регистрирующих конторах, а также такие сопутствующие вопросы, какCIDR.
• автономные системы. Дается описание понятия AS, рекомендации по целесообразности назначения AS – “а вам это надо?”, ну и конечно дается руководство к действию (если вам это реально надо ;)
• маршрутизация и точки обмена интернет-трафиком (IX). Самый, пожалуй, неудачный раздел документа. Очень поверхностно и туманно дается понятие IX, динамической маршрутизации, а также необходимости и того и другого для вашего конкретного случая.
• получение доменного имени. Вообще странный раздел... Пара слов про “что такое DNS”, потом варианты (не)возможности получения ccTLD, и предложение получить таки домен второго уровня в вашем ccTLD. Написали бы хоть, как его, драгоценного, обнаружить ;)
• делегирование доменов IN-ADDR.ARPA. Кратеноко о том, зачем нужен реверс, нужен ли он вам и в каком виде ну и, естественно, как его получить.

 2902 Overview of the 1998 IAB Routing Workshop. S. Deering, S. Hares,

C. Perkins, R. Perlman. August 2000. (Format: TXT=32773 bytes)

(Status: INFORMATIONAL)

2903 Generic AAA Architecture. C. de Laat, G. Gross, L. Gommans, J.

Vollbrecht, D. Spence. August 2000. (Format: TXT=60627 bytes)

(Status: EXPERIMENTAL)

2904 AAA Authorization Framework. J. Vollbrecht, P. Calhoun, S.

Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege,

D. Spence. August 2000. (Format: TXT=78098 bytes) (Status:

INFORMATIONAL)

2905 AAA Authorization Application Examples. J. Vollbrecht, P.

Calhoun, S. Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat,

M. Holdrege, D. Spence. August 2000. (Format: TXT=118645 bytes)

(Status: INFORMATIONAL)

2906 AAA Authorization Requirements. S. Farrell, J. Vollbrecht, P.

Calhoun, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege,

D. Spence. August 2000. (Format: TXT=48618 bytes) (Status:

INFORMATIONAL)

Целая плеяда замечательных документов на тему ААА -- Authentication, Authorization, Accounting. Здесь есть о чем поговорить, есть чего почитать. Однако, дабы не скакать галопом по Европам, планирую подробно рассмотреть эту проблему в следующих номерах “СР”. Вместе с новыми спецификациями ;)

2907 MADCAP Multicast Scope Nesting State Option. R. Kermode.

September 2000. (Format: TXT=27572 bytes) (Status: PROPOSED STANDARD)

2908 The Internet Multicast Address Allocation Architecture. D.

Thaler, M. Handley, D. Estrin. September 2000. (Format: TXT=30515

bytes) (Status: INFORMATIONAL)

2909 The Multicast Address-Set Claim (MASC) Protocol. P. Radoslavov,

D. Estrin, R. Govindan, M. Handley, S. Kumar, D. Thaler. September

2000. (Format: TXT=127278 bytes) (Status: EXPERIMENTAL)

2912 Indicating Media Features for MIME Content. G. Klyne. September

2000. (Format: TXT=20618 bytes) (Status: PROPOSED STANDARD)

2913 MIME Content Types in Media Feature Expressions. G. Klyne.

September 2000. (Format: TXT=16095 bytes) (Status: PROPOSED STANDARD)

2914 Congestion Control Principles. S. Floyd. September 2000. (Format:

TXT=43823 bytes) (Also BCP0041) (Status: BEST CURRENT PRACTICE)

2917 A Core MPLS IP VPN Architecture. K. Muthukrishnan, A. Malis.

September 2000. (Format: TXT=35352 bytes) (Status: INFORMATIONAL)

2918 Route Refresh Capability for BGP-4. E. Chen. September 2000.

(Format: TXT=7354 bytes) (Status: PROPOSED STANDARD)

2920 SMTP Service Extension for Command Pipelining. N. Freed.

September 2000. (Format: TXT=17065 bytes) (Obsoletes RFC2197) (Also

STD0060) (Status: STANDARD)

Ура, новый стандарт! Так-так, что у нас тут... ;)

Ага, суть расширения в следующем: поддерживающий данный стандарт SMTP-демон может принимать множество SMTP-команд от клиента в течении одной операции send (TCP). Для оповещения клиента о поддержке данного расширения вводится тип отклика сервера на команду EHLO – PIPELINING. Клиент расширяется таким образом: команды серверу формируются в группы и одним махом (без ожидания ответа на каждую команду) запускаются на сервер. Соответсвенно, сервер, поддерживающий Pipelining, в таком же режиме на команды отвечает. Естественно, для ради предотвращения путаницы и маразма, в комплектации групп есть определенные правила, а именно: команды RSET, MAIL FROM, SEND FROM, SOML FROM, SAML FROM, и RCPT TO могут размещаться произвольно в любом месте группы, а вот EHLO, DATA, VRFY, EXPN, TURN, QUIT и NOOP – только последней командой в группе (что естественно и в комментариях не нуждается). В своем “групповом” ответе сервер должен придерживаться той же последовательности, в какой команды располагались в группе, посланной клиентом. А теперь, для пущей ясности, посмотрите на прекрасные примеры, данные в спецификации:

1.Это – диалог между “нерасширенными” клиентом и сервером:

S: <wait for open connection>

C: <open connection to server>

S: 220 Innosoft.com SMTP service ready

C: HELO dbc.mtview.ca.us

S: 250 Innosoft.com

C: MAIL FROM:<mrose@dbc.mtview.ca.us>

S: 250 sender <mrose@dbc.mtview.ca.us> OK

C: RCPT TO:<ned@innosoft.com>

S: 250 recipient <ned@innosoft.com> OK

C: RCPT TO:<dan@innosoft.com>

S: 250 recipient <dan@innosoft.com> OK

C: RCPT TO:<kvc@innosoft.com>

S: 250 recipient <kvc@innosoft.com> OK

C: DATA S: 354 enter mail, end with line containing only "." ...

C: .

S: 250 message sent

C: QUIT

S: 221 goodbye

В этом простом примере клиент 9 раз ждет ответа от сервера! А вот смотрите как теперь классно будет:

S: <wait for open connection>

C: <open connection to server>

S: 220 innosoft.com SMTP service ready

C: EHLO dbc.mtview.ca.us

S: 250-innosoft.com

S: 250 PIPELINING

C: MAIL FROM:<mrose@dbc.mtview.ca.us>

C: RCPT TO:<ned@innosoft.com>

C: RCPT TO:<dan@innosoft.com>

C: RCPT TO:<kvc@innosoft.com>

C: DATA

S: 250 sender <mrose@dbc.mtview.ca.us> OK

S: 250 recipient <ned@innosoft.com> OK

S: 250 recipient <dan@innosoft.com> OK

S: 250 recipient <kvc@innosoft.com> OK

S: 354 enter mail, end with line containing only "." ...

C: .

C: QUIT

S: 250 message sent

S: 221 goodbye

Видите, всего 4 раза клиент ждет ответа от сервера! Это же как увеличится скорость рассылки спама, подумать только! ;) А следующий пример показывает, что будет, если все адреса получателей окажутся отклоненными сервером как недопустимые:

S: <wait for open connection>

C: <open connection to server>

S: 220 innosoft.com SMTP service ready

C: EHLO dbc.mtview.ca.us

S: 250-innosoft.com

S: 250 PIPELINING

C: MAIL FROM:<mrose@dbc.mtview.ca.us>

C: RCPT TO:<nsb@thumper.bellcore.com>

C: RCPT TO:<galvin@tis.com>

C: DATA

S: 250 sender <mrose@dbc.mtview.ca.us> OK

S: 550 remote mail to <nsb@thumper.bellore.com> not allowed

S: 550 remote mail to <galvin@tis.com> not allowed

S: 554 no valid recipients given

C: QUIT

S: 221 goodbye

Вот так вот... Обломитесь иgoodbye.

Замечательный стандарт. Ждем тотальной реализации.

2921 6BONE pTLA and pNLA Formats (pTLA). B. Fink. September 2000.

(Format: TXT=14218 bytes) (Status: INFORMATIONAL)

2923 TCP Problems with Path MTU Discovery. K. Lahey. September 2000.

(Format: TXT=30976 bytes) (Status: INFORMATIONAL)

2927 MIME Directory Profile for LDAP Schema. M. Wahl. September 2000.

(Format: TXT=16122 bytes) (Status: INFORMATIONAL)

2929 Domain Name System (DNS) IANA Considerations. D. Eastlake 3rd, E.

Brunner-Williams, B. Manning. September 2000. (Format: TXT=22454

bytes) (Also BCP0042) (Status: BEST CURRENT PRACTICE)

Ну вот, после июньского разбора полетов (RFC 2860), IANA как не в себя начала заниматься всякими полезными и не очень делами ;) Вот в частности, было собрано в кучу и зачем-то опубликованно отдельным RFC все, что касается назначения стандартных номеров всему, связанному с DNS. Здесь все: и поля заголовков DNS-запроса/ответа, и обсуждение того, куда девать бесхозный бит Z этого заголовка, коды операций, коды ответов сервера, информация о типах, классах и именах ресурсных записей. Часть материала идет в виде ссылок на другие RFC, где можно найти соответсвующие списки и таблицы. По большому счету все это доступно наhttp://www.isi.edu/in-notes/iana/assignments/dns-parameters, да и обновляется оно там регулярно... В общем, трудно сказать, зачем писался этот RFC и кому оно надо...

2930 Secret Key Establishment for DNS (TKEY RR). D. Eastlake 3rd.

September 2000. (Format: TXT=34894 bytes) (Status: PROPOSED STANDARD)

2931 DNS Request and Transaction Signatures ( SIG(0)s). D. Eastlake

3rd. September 2000. (Format: TXT=19073 bytes) (Updates RFC2535)

(Status: PROPOSED STANDARD)

2935Internet Open Trading Protocol (IOTP) HTTP Supplement. D. Eastlake, C. Smith. September 2000. (Format:TXT=16168 bytes) (Status: PROPOSED STANDARD)

2936HTTP MIME Type Handler Detection. D. Eastlake, C. Smith, D. Soroka. September 2000. (Format:TXT=25238 bytes) (Status: INFORMATIONAL)

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

В документе обсуждаются различные варианты выуживания из клиента сведений о поддержиемых им MIME-типах. Это:

• ЗаголовокHTTP “Accept”
• JavaScript
• ActiveXиWindows Registry
• ECML (The Electronic Commerce Modeling Language)
• Смешанные техники на основе вышеозначенного

Даны примеры кода, а также преимущества и недостатки данных техник. Хоть документ отличается некоторой лаконичностью и поверхностностью, он все же дает “направляющую нить” для дальнейших самостоятельных экспериментов.

Рубрику ведет Alice D. Saemon,alice@nestor.minsk.by