обозрение свежих RFC, апрель 2005

Итак, настал месяц апрель. Пришло время сезонных обострений у военкоматов и призывников, натужного празднования 1 апреля и связанных с этим плоских шуток.

IETF не чужд шутке юмора. Посему каждый год среди сурьезных технических документов мы находим первоапрельские хохмы от Internet Society.

4041

Итак, N4041, от A. Farrel из Old Dog Consulting. "Требования к Моральным Разделам для черновых стандартов". Помечен как докладная записка. Начало зловещее: "Часто случается, что мораль не обсуждается должным образом в архитектуре и спецификации протоколов. Это ведет к упадку моральных ценностей в Интернете и попыткам подогнать подходящие моральные нормы к уже реализованным и внедренным протоколам, что является малоэффективным". Документ требует ввести раздел "Morality Considerations" (моральные соображения) во все вновь разрабатываемые стандарты. RFC4041 поэтичен и назидателен. "Молодежь под угрозой возрастающей порочности в обществе, и большинство обвинений в этом направлены в сторону Интернета. Если вы не чувствуете себя в безопастности на улицах ночью, то почему вы думаете что так же должно быть на Информационной Супермагистрали?"
Если секция Morality Consideration присутвует в тексте стандарта, то ее содержимое целиком самоочевидно для любого здравомыслящего человека. Если же вы сомневаетесь, то запросите помощь у полиции нравов, богов-хранителей, или любого представителя IMM (Internet Moral Majority - морального большинства Интернета). Понятия, предполагаемые к освещению:
- возможность неиспользования больными и порочными людьми;
- возможность неиспользования транснациональными корпорациями;
- функционал надзора и контроля (запретить шифрацию и анонимизацию - нравственно чистым людям нечего скрывать);
- мы должны позволять пользоваться другими моральными движками и доверять праву людей на другие системы веры;
- заботится о почтовых голубях. Утка тоже чья-то мать.
Так же RFC утверждает, что правильный порядок байт - слева направо, запрещает сегрегацию пакетов и требует включения морали в QoS. При написании этого RFC ни один голубь не пострадал.

4042

"UTF-9 и UTF-18. Эффективные переходные форматы юникода", RFC4042. Некоторые Интернет-сайты используют аппаратные платформы, которые не базируются на традиционном 8-битовом байте или октете (octet). Одна из таких платформ - PDP-10 с 36-битным машинным словом. На таких платформах использование октетов влечет потерю 4 битов на каждом слове и более логичным является использование 9-битных нонетов (nonet). Далее стандарт вяло рассказывает, как же втискивать ISO10646 в UTF9, UTF18. Несмешная шутка. Аффтар, выпей йаду.

4039

Немного сойдя с ума, корифеи IETF, начиная со второго апреля, вернулись к традиционному стилю рыцаря печального клавиатурного образа, чему будут наглядным примером остальные RFC апрельского обзора.
№4039, "Опция Rapid Commit для DHCPv4". Описывает упрощенный формат обмена конфигурационной информацией между сервером DHCP и клиентом. Отличие - передача всего 2 сообщений, вместо стандартных четырех. Предлагается для сетевых окружений, характеризующихся высокой мобильностью. Авторы постулируют, что безопасность и избыточность, характерные для модели на 4 сообщения - излишни и лишь замедляют автоконфигурирование сетевых устройств в условиях наличия только 1 сервера в сети и частых включений/выключений устройств.
Вкратце о схеме работы. Клиент, который посылает DHCPDISCOVER с включеной опцией Rapid Commit, обрабатывает ответ по традиционной схеме (RFC2131). Однако, если в ответ прилетает DHCPPACK с включенным Rapid Commit - клиент обязан обработать его немедленно, пропустив ожидание дополнительных DHCPOFFER и DHCPPACK, и используя принесенную им информацию. Сервер отвечает DHCPPACK с включенным Rapid Commit только в ответ на DHCPDISCOVER с аналогичной опцией. Жесткое ограничение - наличие только 1 DHCP-сервера в сети.
Итого, сей коллективный опус CISCO и Samsung краток, четок и информативен.

4048

№4048, Забавный документ, переводящий RFC1888 в устаревшие. Опять про IPV6, на этот раз про старые протухшие прототипы оного, образца 1996 года.
4051

Additional XML Security Uniform Resource Identifiers (URIs), №4051. Перевести нормально название не смог. Определяет некоторое количество URI, предназначенных для работы с цифровыми подписями XML и шифрования оного. Достаточно банально - перечисление алгоритмов шифрования и создания подписей, и как сие втиснуть в прокрустово ложе XML и URI. Сертификаты, MD5, shaXXX, RSA, psec-kem и др. - пересказ их описаний. Обнаружена опечатка в оглавлении, номера страниц не совпадают с фактическими. Авторы спешили попасть в историю.

4050

№4050, "Использование алгоритма элиптических кривых (ECDSA) для цифровых подписей XML". Коллектив из 4 авторов мужественно рожал сей 19- страничный документ. Утверждается, что подписи, сделанные ECDSA, меньше чем RSA-сигнатуры той же криптостойкости и на многих платформах вычисляются быстрее. В остальном - идет спецификация, "как использовать ECDSA в XML", то есть DTD, XML-схемы и описание полей ключа. Количество авторов (4 персоны) слишком велико для этой отнюдь не эпохальной работы.

4049

"Двоичная дата. Альтернативный способ представления данных и времени в ASN.1", №4049. Если говорить коротко - Unix Time Resurrection :). Или "Время в секундах с начала эпохи" снова оседлало интернет. Данный стандарт, помеченный как экспериментальный, предлагает использовать вместо строковых представлений времени - целые числа INTEGER (0..MAX) в ASN.1. Автор резонно отмечает, что:
- такой формат гораздо короче, чем популярные UTCTime или GeneralizedTime;
- на многих платформах не требует вычислений вообще (см man 2 time в Unix-подобных системах);
- сравнение двух дат превращается в тривиальную задачу.
Однако мир не без добрых подводных камней. Первый кирпич в бинарный формат - надо как то учитывать случаи, когда требуется точность менее секунды. Второй кирпич - порядок расположения байт в машинном слове, то есть пресловутые Большие Индейцы и Маленькие Индейцы (big-endian и little-endian) и связанные с этим прискорбным фактом затраты на вычисление некоего "сетевого представления числа".



mend0za.


Сетевые решения. Статья была опубликована в номере 04 за 2005 год в рубрике технологии

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