Новые RFC и комментарии к ним
Продолжаем знакомить вас с суперновыми технологиями Интернет посредством описания (краткого и не очень) свежеопубликованных документов RFC. И пусть вас не смущает, что некоторые из них датированы февралем 2000 года: спецификаций публикуется не очень много, и в контексте стандартизации февральские документы - совсем еще юные создания;)
Немного поменялся подход к описанию RFC. На сей раз я решила не перечислять все вышедшие документы, а обращать внимание лишь на наиболее, на мой взгляд, примечательные либо с точки зрения полезности, либо как "чистое искусство". Однако уверена, часть аудитории может не разделять моего сугубо личного и весьма субъективного мнения. Может быть, в этом обзоре упущено что-то исключительно важное, возможно, даже эпохальное? Почему бы об этом не написать именно ВАМ?;)
2772 6Bone Backbone Routing Guidelines. R. Rockell, R. Fink. February 2000. (Format: TXT=28565 bytes) (Obsoletes RFC2564) (Status: INFORMATIONAL)
Как вы, наверное, догадались, в документе идет речь о маршрутизации в рамках так называемой 6Bone. Отвлекаясь от содержимого RFC, расскажу вам вкратце про 6Bone, чтобы вы решили, есть смысл читать дальше или нет;)
Итак, 6Bone - это полигон для тестирования IPv6, международный неформальный совместный проект в рамках инициативы IETF IPng. 6Bone начала свою работу как виртуальная сеть, использующая инкапсуляцию/туннелирование IPv6 по существующим сетям IPv4 с задачей постепенной миграции на "родной", чистый IPv6. На данный момент из наших соседей работа с 6Bone налажена в России, Польше, Литве, Эстонии и Украине. О поползновениях присоединиться к инициативе кого-то из Беларуси сведений нет. Исчерпывающая информация - на http://www.6bone.net/.
Теперь вернемся к спецификации. RFC 2772 заменяет и дополняет устаревший RFC2564 6Bone Routing Practice и дает четкие инструкции для сетевых операторов, обеспечивающих маршрутизацию в 6Bone.
В первой части документа вы найдете основные правила маршрутизации в 6Bone, как то, например, локальные префиксы сайтов и линков, префиксы для группового вещания (multicast), префиксы, совместимые с IPv4, маршруты по умолчанию, а также рекомендации по обмену маршрутной информацией. Документ постоянно ссылается на мультипротокольное расширение BGP-4, используемое в маршрутизации IPv6.
Далее речь идет о политиках маршрутизации в рамках 6Bone, и затем до конца документа - административные вопросы, почти полностью дублирующие информацию с официального сайта 6Bone о том, как присоединиться к сети, понятие pNLA и pTLA (что по уму следовало бы отнести в начало документа, поскольку незнание этого затрудняет понимание первой части документа) и требования к оным. Для справки: TLA (Top Level Aggregator) - это провайдер IPv6 самого верхнего уровня, а NLA (Next Level Aggregator), соответственно, второго (следующего) уровня. В рамках 6Bone конкретные провайдеры (точки доступа) называются pTLA (pseudo TLA) или sub-TLA (в зависимости от префикса). Аналогично с pNLA.
В общем, документ занятный и, кстати, небольшой - глаз и ум не устают при прочтении от корки до корки;). И, может быть, кто-нибудь поддержит инициативу в РБ, дабы не отставать от соседей? Подумайте...;)
2774 An HTTP Extension Framework. H. Nielsen, P. Leach, S. Lawrence. February 2000. (Format: TXT=39719 bytes) (Status: EXPERIMENTAL)
Итак, очередная попытка приведения в порядок ситуации с расширениями HTTP. Перед тем, как вкратце изложить суть спецификации, имеет смысл описать реакцию на документ влиятельных господ из IETF. Они сообщают нам, что данная спецификация изначально была заявлена для публикации в качестве Proposed Standard, но в силу того, что мировая общественность, обсуждая документ, не пришла к консенсусу, было решено опубликовать спецификацию под маркой экспериментальной. Впрочем, тут же следует оговорка, что это не обязательно указывает на "сырость" спецификации и технические неточности в ней. Обращается внимание на то, что следует рассматривать возможность применения других вариантов расширения HTTP как дополнительно, так и вместо того, что описано в документе. Вот так. Облажали, как всегда;) Кстати, для справки: если в начале документа RFC вы видите раздел "IESG Note", ничего жизнеутверждающего в нем не будет, факт.
Однако вернемся к технологии.
Предлагаемая схема предназначена для стирания противоречий между частными соглашениями и официальной спецификацией. Возможные частные случаи расширений по данному методу лежат в области расширения конкретного сообщения HTTP, введения новых кодировок и новых протоколов, базирующихся на HTTP, переключения на протоколы, которые, будучи однажды инициализированы, работают независимо от породившего их стека протоколов.
В общем виде схема работает следующим образом:
‰ Некто разрабатывает и описывает расширение, затем назначает ему уникальный URI и создает одно или несколько представлений расширения, доступного по данному адресу. Представления могут быть следующих типов: удобное для восприятие человеком (human-readable) описание семантики расширения, загружаемый код, реализующий данную семантику, формальное описание интерфейса, представляемого расширением и машинно-читаемое (machine-readable) описание семантики.
‰ HTTP-клиент или сервер, поддерживающие описываемый механизм расширений, декларируют использование конкретного расширения ссылкой на его (расширения) URI в HTTP-сообщении.
‰ Приложение HTTP, для которого декларировано данное расширение, может сделать вывод о том, как правильно интерпретировать расширенное сообщение, базируясь на декларации расширения.
Не будем вдаваться в детали предложенной схемы, поскольку вдаваться в них будет иметь смысл только тогда, когда в "верхах" или хотя бы в относительно массовых "низах" придут-таки к консенсусу, использовать это чудо инженерной мысли или нет. А пока ограничимся примером расширенных HTTP-сообщений:
HTTP/1.1 200 OK
Content-Length: 421
Opt: "http://www.digest.org/Digest"; ns=15
15-digest: "snfksjgor2tsajkt52"
M-GET / HTTP/1.1
Host: some.host
C-Man: "http://www.digest.org/ProxyAuth"; ns=14
14-Credentials="g5gj262jdw@4df"
Connection: C-Man, 14-Credentials
Понимаю, что по этим примерам можно не уразуметь, как же это все работает, но порешим на том: если вы теоретик-разработчик, вы-таки внимательно ознакомитесь со спецификацией и всеми сопутствующими документами, а если вы практик - дождетесь первых реализаций и уже на практике разберетесь с этой технологией.
2778 A Model for Presence and Instant Messaging. M. Day, J. Rosenberg, H. Sugano. February 2000. (Format: TXT=35153 bytes) (Status: INFORMATIONAL)
2779 Instant Messaging / Presence Protocol Requirements. M. Day, S. Aggarwal, G. Mohr, J. Vincent. February 2000. (Format: TXT= 47420 bytes) (Status: INFORMATIONAL)
Поскольку два этих документа столь тесно связаны друг с другом по тематике, более того - в RFC 2779 активно используется информация из 2778, я решила объединить их в одном обзоре. Проблема, освещаемая в этих работах, сегодня чрезвычайно актуальна для сетевого сообщества. На данный момент существует огромное количество систем моментального обмена сообщениями и Presence Service (Instant Messaging и Presence Services соответственно), которые предлагают разнообразные сервисы, работают в основном по закрытым фирменным протоколам (либо полуоткрытым, либо откровенно кривым;) и практически не взаимодействуют друг с другом. Пожалуй, только клиент Odigo несколько продвинулся в деле интероперабельности, предложив функцию сопряжения с ICQ, которая при всей своей кривости бесплатностью и массовостью вознеслась в ранг "почти стандарта" де факто.
И вот в начале прошлого года IETF решает положить конец этому безобразию и создает рабочую группу Instant Messaging and Presence Protocol (IMPP), под эгидой которой и создавались рассматриваемые мной документы RFC. Для справки: в написании документов участвовали сотрудники компаний Lotus, Microsoft, Dynamicsoft, Fujitsu, Activerse, Into Networks. Какой в том тайный смысл, сказать пока не могу, но что-то в этой компании есть такое... подозрительное;)
RFC 2778 описывает общую структуру сервисов и дает терминологию, которая потом по идее будет использоваться как в работе над унифицированным протоколом (if any), так и для взаимопонимания разработчиков подобного рода систем. Перечислю основные понятия, данные в спецификации (но без расшифровки;): PRESENCE SERVICE, PRESENTITY, WATCHER, FETCHER, POLLER, SUBSCRIBER, INSTANT MESSAGE SERVICE, INSTANT INBOX, SENDER, INSTANT MESSAGE, INSTANT MESSAGE PROTOCOL, STATUS, PRINCIPAL и много чего другого. В принципе, любой из вас, кто когда-нибудь работал с подобными системами (а лучше всего с ICQ - в ней уж точно все это есть), взглянув на диаграммы и определения в документе, без труда опознает все эти понятия, объекты и субъекты. А вот перевести это все на русский язык... Мне и два фундаментальных термина тяжело дались;)
RFC 2779 в самом своем начале дает ссылку на определения основных понятий и общую модель, описанную в 2778, добавляет новые понятия и их определения и делает еще один шаг навстречу стандартизации - дает минимальные требования интероперабельности, из которых по идее постепенно будет вырисовываться новый протокол, который скорее всего получит гордое имя IMPP.
Что мы имеем в этом плане на сегодня? Описаны основные требования к именованию и администрированию систем присутствия и обмена сообщениями (пока нет официальной русской терминологии, придется использовать такой вот "криволапый" вариант), вопросы масштабируемости, контроля доступа, сетевой топологии (в том числе и вопросы файерволлинга), шифрования и аутентификации. Далее следует попытка "выведения" универсального формата сообщений присутствия (presence format), рассмотрены вопросы унификации оповещения и поиска, кеширования и репликации информации присутствия. Для подсистемы обмена сообщениями дана рекомендация по универсальному формату сообщений, надежности соединения, производительности систем. В конце достаточно объемный раздел по безопасности.
Конечно, это только первый шаг к стандартизации. И беглого взгляда на документ достаточно, чтобы осознать этот факт: даже в разделе "Формат сообщений" мы видим лишь общие фразы, как и в других главах. Однако радует, что подвижка в этом направлении все же есть, и я надеюсь, что годика через три минимум мы увидим в разделе Internet Standards гордое слово IMPP, которое станет столь же привычным, как ICMP, IGMP, IP, и т. д. По крайней мере поддержка разработок в этой области такими столпами индустрии, как MS, Lotus, Fujutsu, дает надежду, что дело не заглохнет на полпути.
2782 A DNS RR for specifying the location of services (DNS SRV). A. Gulbrandsen, P. Vixie, L. Esibov. February 2000. (Format: TXT=24013 bytes) (Obsoletes RFC2052) (Status: PROPOSED STANDARD)
Вот забавная спецификация, доложу я вам! Всем, кому небезынтересна проблема DNS, настоятельно рекомендую ознакомиться. Поскольку лично мне эта тематика очень близка и понятна, не могу удержаться от краткого пересказа технологии;) Итак, предлагается ввести новый тип ресурсной записи DNS (RR type) - SRV, которая будет обозначать местонахождение в домене сервера, обеспечивающего определенный сервис по определенному протоколу. Например, нужно клиенту добраться до LDAP сервера, поддерживающего работу по TCP в неком домене. Делает он запрос SRV с содержимым плана _ldap._tcp.somedomain.com и получает список серверов LDAP с указанием приоритета и так называемого "веса" (weight). Клиент обязан самостоятельно отсортировать сервера по приоритетам и обращаться в первую очередь к серверам с более низким значением приоритета. Если имеется несколько серверов с одинаковым приоритетом, наилучший (по мнению администратора домена) вариант находится по полю "вес". Спецификация дает описание алгоритма вычисления распределения нагрузки на сервера в зависимости от указанных значений веса. Вообще, переводя weight, следовало бы сказать "удельный вес", поскольку это лучше отражает общий смысл назначения поля, действительно указывая на удельный вес трафика этого сервера в общем трафике серверов, работающих с данным сервисом, но мы не будем мудрить;)
В общем виде новая запись будет иметь следующий формат:
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
Но лучше всего прочувствовать суть нововведения позволяет следующий небольшой пример, взятый прямо из документа:
Итого имеем: 4 сервера, предоставляющих некий гипотетический сервис foobar по протоколу TCP по порту 9. Сначала предлагается выбрать из двух основных, причем больше обращений предполагается к new-fast-box (ну название обязывает - новая-быстрая-машина;). Если оба основных сервера вдруг уйдут дружно в даун, придется клиенту обслуживаться на личном компьютере сисадмина либо на головном сервере, причем вероятность попасть на туда или сюда - 50х50. После того, как клиент выбрал, куда ему направиться, он посылает стандартный адресный запрос (A) и, собственно, туда идет. Последние две строки указывают на то, что больше сервисов, для которых поддерживается работа с SRV, нет. IMHO очень интересная и главное - основанная на привычной и стандартной технологии DNS стратегия распределения нагрузки.
2784 Generic Routing Encapsulation (GRE). D. Farinacci, T. Li, S.
Hanks, D. Meyer, P. Traina. March 2000. (Format: TXT=16627 bytes)
(Status: PROPOSED STANDARD)
2790 Host Resources MIB. S. Waldbusser, P. Grillo. March 2000.
(Format: TXT=95807 bytes) (Obsoletes RFC1514) (Status: DRAFT
STANDARD)
2806 URLs for Telephone Calls. A. Vaha-Sipila. April 2000. (Format:
TXT=50647 bytes) (Status: PROPOSED STANDARD)
Последние годы наблюдается следующая тенденция: остается все меньше документов RFC, которые сами по себе представляют некое законченное "произведение искусства", то бишь без ссылок на другие спецификации от начала и до конца описывают некую технологию. Теперь RFC публикуются очень часто и в большинстве своем являются своеобразными вехами в неком глобальном исследовательском процессе и посему, будучи вырванными из контекста, так сказать, в отдельно взятом виде, осмыслению не подлежат. Это я к чему сие лирическое отступление тут привожу? Дело в том, что RFC 2806 сам по себе вызывает ощущение курьеза. Чуть ниже объясню, почему;)
Спецификация, разработанная специалистом из компании NOKIA, предлагает три новые схемы URL'ов, определяющих местонахождение терминала в телефонной сети и тип соединения с ним. Вот эти схемы:
1. tel. Определяет соединение с терминалом, поддерживающим нормальные "войсовые" звонки, в том числе на системы голосовой почты, автоответа и прочие сервисы, использующие тоны DTMF. Приводить формат схемы в общем виде я тут не буду, поскольку места газетного на это безобразие не хватит, а примеры дам:
tel:+358-555-1234567;postd=pp22
tel:+1234567890;phone-context=+1234;vnd.company.option=foo
2. fax. Как нетрудно догадаться, эта схема URL предназначена для соединения с терминалом, выполняющим передачу факсимильных сообщений. Пример:
fax:+358.555.1234567
3. modem. Соответственно тут мы имеем дело с терминалами, поддерживающими входящие вызовы для передачи данных. В документе уточняется, что термин "модем" указывает на устройство, осуществляющее преобразование цифры в аналоговый сигнал и наоборот, но справедлив в данном случае и для чисто цифровых соединений. Пример:
modem:+3585551234567;type=v32b?7e1;type=v110
Далее даются лаконичные рекомендации по использованию этих типов URL в HTML-документах. Все. На сим полномочия данного документа заканчиваются. А зачем это надо, в каких приложениях применяется, думайте, господа хорошие, сами. Вот в этом-то и заключается вышеозначенный курьез;)
Немного поменялся подход к описанию RFC. На сей раз я решила не перечислять все вышедшие документы, а обращать внимание лишь на наиболее, на мой взгляд, примечательные либо с точки зрения полезности, либо как "чистое искусство". Однако уверена, часть аудитории может не разделять моего сугубо личного и весьма субъективного мнения. Может быть, в этом обзоре упущено что-то исключительно важное, возможно, даже эпохальное? Почему бы об этом не написать именно ВАМ?;)
2772 6Bone Backbone Routing Guidelines. R. Rockell, R. Fink. February 2000. (Format: TXT=28565 bytes) (Obsoletes RFC2564) (Status: INFORMATIONAL)
Как вы, наверное, догадались, в документе идет речь о маршрутизации в рамках так называемой 6Bone. Отвлекаясь от содержимого RFC, расскажу вам вкратце про 6Bone, чтобы вы решили, есть смысл читать дальше или нет;)
Итак, 6Bone - это полигон для тестирования IPv6, международный неформальный совместный проект в рамках инициативы IETF IPng. 6Bone начала свою работу как виртуальная сеть, использующая инкапсуляцию/туннелирование IPv6 по существующим сетям IPv4 с задачей постепенной миграции на "родной", чистый IPv6. На данный момент из наших соседей работа с 6Bone налажена в России, Польше, Литве, Эстонии и Украине. О поползновениях присоединиться к инициативе кого-то из Беларуси сведений нет. Исчерпывающая информация - на http://www.6bone.net/.
Теперь вернемся к спецификации. RFC 2772 заменяет и дополняет устаревший RFC2564 6Bone Routing Practice и дает четкие инструкции для сетевых операторов, обеспечивающих маршрутизацию в 6Bone.
В первой части документа вы найдете основные правила маршрутизации в 6Bone, как то, например, локальные префиксы сайтов и линков, префиксы для группового вещания (multicast), префиксы, совместимые с IPv4, маршруты по умолчанию, а также рекомендации по обмену маршрутной информацией. Документ постоянно ссылается на мультипротокольное расширение BGP-4, используемое в маршрутизации IPv6.
Далее речь идет о политиках маршрутизации в рамках 6Bone, и затем до конца документа - административные вопросы, почти полностью дублирующие информацию с официального сайта 6Bone о том, как присоединиться к сети, понятие pNLA и pTLA (что по уму следовало бы отнести в начало документа, поскольку незнание этого затрудняет понимание первой части документа) и требования к оным. Для справки: TLA (Top Level Aggregator) - это провайдер IPv6 самого верхнего уровня, а NLA (Next Level Aggregator), соответственно, второго (следующего) уровня. В рамках 6Bone конкретные провайдеры (точки доступа) называются pTLA (pseudo TLA) или sub-TLA (в зависимости от префикса). Аналогично с pNLA.
В общем, документ занятный и, кстати, небольшой - глаз и ум не устают при прочтении от корки до корки;). И, может быть, кто-нибудь поддержит инициативу в РБ, дабы не отставать от соседей? Подумайте...;)
2774 An HTTP Extension Framework. H. Nielsen, P. Leach, S. Lawrence. February 2000. (Format: TXT=39719 bytes) (Status: EXPERIMENTAL)
Итак, очередная попытка приведения в порядок ситуации с расширениями HTTP. Перед тем, как вкратце изложить суть спецификации, имеет смысл описать реакцию на документ влиятельных господ из IETF. Они сообщают нам, что данная спецификация изначально была заявлена для публикации в качестве Proposed Standard, но в силу того, что мировая общественность, обсуждая документ, не пришла к консенсусу, было решено опубликовать спецификацию под маркой экспериментальной. Впрочем, тут же следует оговорка, что это не обязательно указывает на "сырость" спецификации и технические неточности в ней. Обращается внимание на то, что следует рассматривать возможность применения других вариантов расширения HTTP как дополнительно, так и вместо того, что описано в документе. Вот так. Облажали, как всегда;) Кстати, для справки: если в начале документа RFC вы видите раздел "IESG Note", ничего жизнеутверждающего в нем не будет, факт.
Однако вернемся к технологии.
Предлагаемая схема предназначена для стирания противоречий между частными соглашениями и официальной спецификацией. Возможные частные случаи расширений по данному методу лежат в области расширения конкретного сообщения HTTP, введения новых кодировок и новых протоколов, базирующихся на HTTP, переключения на протоколы, которые, будучи однажды инициализированы, работают независимо от породившего их стека протоколов.
В общем виде схема работает следующим образом:
‰ Некто разрабатывает и описывает расширение, затем назначает ему уникальный URI и создает одно или несколько представлений расширения, доступного по данному адресу. Представления могут быть следующих типов: удобное для восприятие человеком (human-readable) описание семантики расширения, загружаемый код, реализующий данную семантику, формальное описание интерфейса, представляемого расширением и машинно-читаемое (machine-readable) описание семантики.
‰ HTTP-клиент или сервер, поддерживающие описываемый механизм расширений, декларируют использование конкретного расширения ссылкой на его (расширения) URI в HTTP-сообщении.
‰ Приложение HTTP, для которого декларировано данное расширение, может сделать вывод о том, как правильно интерпретировать расширенное сообщение, базируясь на декларации расширения.
Не будем вдаваться в детали предложенной схемы, поскольку вдаваться в них будет иметь смысл только тогда, когда в "верхах" или хотя бы в относительно массовых "низах" придут-таки к консенсусу, использовать это чудо инженерной мысли или нет. А пока ограничимся примером расширенных HTTP-сообщений:
HTTP/1.1 200 OK
Content-Length: 421
Opt: "http://www.digest.org/Digest"; ns=15
15-digest: "snfksjgor2tsajkt52"
M-GET / HTTP/1.1
Host: some.host
C-Man: "http://www.digest.org/ProxyAuth"; ns=14
14-Credentials="g5gj262jdw@4df"
Connection: C-Man, 14-Credentials
Понимаю, что по этим примерам можно не уразуметь, как же это все работает, но порешим на том: если вы теоретик-разработчик, вы-таки внимательно ознакомитесь со спецификацией и всеми сопутствующими документами, а если вы практик - дождетесь первых реализаций и уже на практике разберетесь с этой технологией.
2778 A Model for Presence and Instant Messaging. M. Day, J. Rosenberg, H. Sugano. February 2000. (Format: TXT=35153 bytes) (Status: INFORMATIONAL)
2779 Instant Messaging / Presence Protocol Requirements. M. Day, S. Aggarwal, G. Mohr, J. Vincent. February 2000. (Format: TXT= 47420 bytes) (Status: INFORMATIONAL)
Поскольку два этих документа столь тесно связаны друг с другом по тематике, более того - в RFC 2779 активно используется информация из 2778, я решила объединить их в одном обзоре. Проблема, освещаемая в этих работах, сегодня чрезвычайно актуальна для сетевого сообщества. На данный момент существует огромное количество систем моментального обмена сообщениями и Presence Service (Instant Messaging и Presence Services соответственно), которые предлагают разнообразные сервисы, работают в основном по закрытым фирменным протоколам (либо полуоткрытым, либо откровенно кривым;) и практически не взаимодействуют друг с другом. Пожалуй, только клиент Odigo несколько продвинулся в деле интероперабельности, предложив функцию сопряжения с ICQ, которая при всей своей кривости бесплатностью и массовостью вознеслась в ранг "почти стандарта" де факто.
И вот в начале прошлого года IETF решает положить конец этому безобразию и создает рабочую группу Instant Messaging and Presence Protocol (IMPP), под эгидой которой и создавались рассматриваемые мной документы RFC. Для справки: в написании документов участвовали сотрудники компаний Lotus, Microsoft, Dynamicsoft, Fujitsu, Activerse, Into Networks. Какой в том тайный смысл, сказать пока не могу, но что-то в этой компании есть такое... подозрительное;)
RFC 2778 описывает общую структуру сервисов и дает терминологию, которая потом по идее будет использоваться как в работе над унифицированным протоколом (if any), так и для взаимопонимания разработчиков подобного рода систем. Перечислю основные понятия, данные в спецификации (но без расшифровки;): PRESENCE SERVICE, PRESENTITY, WATCHER, FETCHER, POLLER, SUBSCRIBER, INSTANT MESSAGE SERVICE, INSTANT INBOX, SENDER, INSTANT MESSAGE, INSTANT MESSAGE PROTOCOL, STATUS, PRINCIPAL и много чего другого. В принципе, любой из вас, кто когда-нибудь работал с подобными системами (а лучше всего с ICQ - в ней уж точно все это есть), взглянув на диаграммы и определения в документе, без труда опознает все эти понятия, объекты и субъекты. А вот перевести это все на русский язык... Мне и два фундаментальных термина тяжело дались;)
RFC 2779 в самом своем начале дает ссылку на определения основных понятий и общую модель, описанную в 2778, добавляет новые понятия и их определения и делает еще один шаг навстречу стандартизации - дает минимальные требования интероперабельности, из которых по идее постепенно будет вырисовываться новый протокол, который скорее всего получит гордое имя IMPP.
Что мы имеем в этом плане на сегодня? Описаны основные требования к именованию и администрированию систем присутствия и обмена сообщениями (пока нет официальной русской терминологии, придется использовать такой вот "криволапый" вариант), вопросы масштабируемости, контроля доступа, сетевой топологии (в том числе и вопросы файерволлинга), шифрования и аутентификации. Далее следует попытка "выведения" универсального формата сообщений присутствия (presence format), рассмотрены вопросы унификации оповещения и поиска, кеширования и репликации информации присутствия. Для подсистемы обмена сообщениями дана рекомендация по универсальному формату сообщений, надежности соединения, производительности систем. В конце достаточно объемный раздел по безопасности.
Конечно, это только первый шаг к стандартизации. И беглого взгляда на документ достаточно, чтобы осознать этот факт: даже в разделе "Формат сообщений" мы видим лишь общие фразы, как и в других главах. Однако радует, что подвижка в этом направлении все же есть, и я надеюсь, что годика через три минимум мы увидим в разделе Internet Standards гордое слово IMPP, которое станет столь же привычным, как ICMP, IGMP, IP, и т. д. По крайней мере поддержка разработок в этой области такими столпами индустрии, как MS, Lotus, Fujutsu, дает надежду, что дело не заглохнет на полпути.
2782 A DNS RR for specifying the location of services (DNS SRV). A. Gulbrandsen, P. Vixie, L. Esibov. February 2000. (Format: TXT=24013 bytes) (Obsoletes RFC2052) (Status: PROPOSED STANDARD)
Вот забавная спецификация, доложу я вам! Всем, кому небезынтересна проблема DNS, настоятельно рекомендую ознакомиться. Поскольку лично мне эта тематика очень близка и понятна, не могу удержаться от краткого пересказа технологии;) Итак, предлагается ввести новый тип ресурсной записи DNS (RR type) - SRV, которая будет обозначать местонахождение в домене сервера, обеспечивающего определенный сервис по определенному протоколу. Например, нужно клиенту добраться до LDAP сервера, поддерживающего работу по TCP в неком домене. Делает он запрос SRV с содержимым плана _ldap._tcp.somedomain.com и получает список серверов LDAP с указанием приоритета и так называемого "веса" (weight). Клиент обязан самостоятельно отсортировать сервера по приоритетам и обращаться в первую очередь к серверам с более низким значением приоритета. Если имеется несколько серверов с одинаковым приоритетом, наилучший (по мнению администратора домена) вариант находится по полю "вес". Спецификация дает описание алгоритма вычисления распределения нагрузки на сервера в зависимости от указанных значений веса. Вообще, переводя weight, следовало бы сказать "удельный вес", поскольку это лучше отражает общий смысл назначения поля, действительно указывая на удельный вес трафика этого сервера в общем трафике серверов, работающих с данным сервисом, но мы не будем мудрить;)
В общем виде новая запись будет иметь следующий формат:
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
Но лучше всего прочувствовать суть нововведения позволяет следующий небольшой пример, взятый прямо из документа:
Итого имеем: 4 сервера, предоставляющих некий гипотетический сервис foobar по протоколу TCP по порту 9. Сначала предлагается выбрать из двух основных, причем больше обращений предполагается к new-fast-box (ну название обязывает - новая-быстрая-машина;). Если оба основных сервера вдруг уйдут дружно в даун, придется клиенту обслуживаться на личном компьютере сисадмина либо на головном сервере, причем вероятность попасть на туда или сюда - 50х50. После того, как клиент выбрал, куда ему направиться, он посылает стандартный адресный запрос (A) и, собственно, туда идет. Последние две строки указывают на то, что больше сервисов, для которых поддерживается работа с SRV, нет. IMHO очень интересная и главное - основанная на привычной и стандартной технологии DNS стратегия распределения нагрузки.
2784 Generic Routing Encapsulation (GRE). D. Farinacci, T. Li, S.
Hanks, D. Meyer, P. Traina. March 2000. (Format: TXT=16627 bytes)
(Status: PROPOSED STANDARD)
2790 Host Resources MIB. S. Waldbusser, P. Grillo. March 2000.
(Format: TXT=95807 bytes) (Obsoletes RFC1514) (Status: DRAFT
STANDARD)
2806 URLs for Telephone Calls. A. Vaha-Sipila. April 2000. (Format:
TXT=50647 bytes) (Status: PROPOSED STANDARD)
Последние годы наблюдается следующая тенденция: остается все меньше документов RFC, которые сами по себе представляют некое законченное "произведение искусства", то бишь без ссылок на другие спецификации от начала и до конца описывают некую технологию. Теперь RFC публикуются очень часто и в большинстве своем являются своеобразными вехами в неком глобальном исследовательском процессе и посему, будучи вырванными из контекста, так сказать, в отдельно взятом виде, осмыслению не подлежат. Это я к чему сие лирическое отступление тут привожу? Дело в том, что RFC 2806 сам по себе вызывает ощущение курьеза. Чуть ниже объясню, почему;)
Спецификация, разработанная специалистом из компании NOKIA, предлагает три новые схемы URL'ов, определяющих местонахождение терминала в телефонной сети и тип соединения с ним. Вот эти схемы:
1. tel. Определяет соединение с терминалом, поддерживающим нормальные "войсовые" звонки, в том числе на системы голосовой почты, автоответа и прочие сервисы, использующие тоны DTMF. Приводить формат схемы в общем виде я тут не буду, поскольку места газетного на это безобразие не хватит, а примеры дам:
tel:+358-555-1234567;postd=pp22
tel:+1234567890;phone-context=+1234;vnd.company.option=foo
2. fax. Как нетрудно догадаться, эта схема URL предназначена для соединения с терминалом, выполняющим передачу факсимильных сообщений. Пример:
fax:+358.555.1234567
3. modem. Соответственно тут мы имеем дело с терминалами, поддерживающими входящие вызовы для передачи данных. В документе уточняется, что термин "модем" указывает на устройство, осуществляющее преобразование цифры в аналоговый сигнал и наоборот, но справедлив в данном случае и для чисто цифровых соединений. Пример:
modem:+3585551234567;type=v32b?7e1;type=v110
Далее даются лаконичные рекомендации по использованию этих типов URL в HTML-документах. Все. На сим полномочия данного документа заканчиваются. А зачем это надо, в каких приложениях применяется, думайте, господа хорошие, сами. Вот в этом-то и заключается вышеозначенный курьез;)
Рубрику ведет Alice D. Saemon alice@nestor.minsk.by
Сетевые решения. Статья была опубликована в номере 06 за 2000 год в рубрике RFC
