О документе
Идентификатор и границы: RFC2148/part-001, страницы 1–6; SHA-256=783ebd6394ccf10d612faa395bbff548c21eb7b4183b0851295f336758f303f8
Network Working Group H. Alvestrand
Request for Comments: 2148 UNINETT
BCP: 15 P. Jurg
Category: Лучшая современная практика SURFnet
Сентябрь 1997
Развертывание Internet White Pages Service
1. Резюме и рекомендации
Этот документ формулирует следующие рекомендации для организаций
в Интернете:
(1) Организации СЛЕДУЕТ (SHOULD) публиковать открытые адреса
электронной почты и другую открытую адресную информацию о
пользователях Интернета в пределах своей площадки.
(2) В большинстве стран действуют законы, касающиеся публикации
информации о людях. Помимо этих законов организации СЛЕДУЕТ
(SHOULD) соблюдать рекомендации [1].
(3) В настоящее время предпочтительный способ публикации этой
информации — использовать X.500 в качестве её структуры
данных и схемы именования (определённой в [4] и обсуждаемой
в [3], хотя в некоторых странах применяется национальное
уточнение, например [15] для США). Организация МОЖЕТ (MAY)
дополнительно публиковать её с использованием дополнительных
структур данных, таких как whois++.
(4) Организации СЛЕДУЕТ (SHOULD) сделать опубликованную
информацию доступной клиентам LDAP, предоставив серверам LDAP
доступ к своим данным".
(5) Организации НЕ СЛЕДУЕТ (SHOULD NOT) пытаться взимать плату
за простой доступ к данным.
Кроме того, он формулирует следующие рекомендации для различных
прочих сторон:
(1) Поставщикам программного обеспечения электронной почты
СЛЕДУЕТ (SHOULD) включать в свои продукты функцию поиска LDAP
либо как встроенную функцию, либо предоставляя средства
преобразования.
(2) Поставщикам интернет-услуг СЛЕДУЕТ (SHOULD) помогать
небольшим организациям соблюдать эту рекомендацию: либо
предоставляя услуги по размещению их данных, либо помогая им
найти другие стороны, которые сделают это, либо помогая им
ввести в действие собственную службу.
(3) Всем заинтересованным сторонам СЛЕДУЕТ (SHOULD) обеспечить
существование в мире базового пространства имён X.500 и то,
чтобы все имена в этом пространстве имён разрешались.
(Национальные пространства имён могут развивать базовое
пространство имён.)
Остальная часть этого документа содержит обоснование и подробности
этой рекомендации.
Слова "SHOULD", "MUST" и "MAY", написанные В ВЕРХНЕМ РЕГИСТРЕ,
имеют значение, определённое в RFC 2119 [17].
2. Введение
Интернет используется для обмена информацией и связи между его
пользователями. Он может быть эффективен в этом качестве, только
если пользователи способны находить адреса друг друга. Поэтому
Интернету полезна адекватная служба White Pages, то есть служба
каталогов, предоставляющая (интернет-)адресную информацию, связанную
с людьми и организациями.
Этот документ описывает, каким образом Internet White Pages Service
(далее сокращённо IWPS) наилучшим образом используется с опорой на
сегодняшний опыт, сегодняшние протоколы, сегодняшние продукты и
сегодняшние процедуры.
Опыт [2] показал, что служба White Pages, основанная на
самостоятельной регистрации пользователей или на централизованных
серверах, склонна собирать данные бессистемно и, кроме того, собирает
данные, которые быстро устаревают и не поддерживаются в актуальном
состоянии.
Наиболее значимые попытки создать IWPS основаны на моделях с
распределёнными (локальными) базами данных, каждая из которых хранит
управляемую часть информации IWPS. Такая часть преимущественно
состоит из всей относящейся к IWPS информации из конкретной
организации либо от поставщика интернет-услуг и его пользователей.
Над базами данных располагается протокол служб каталогов, который
соединяет их и предоставляет доступ пользователям. Сегодня X.500 —
самый популярный в Интернете протокол служб каталогов, объединяющий
адресную информацию примерно о 1,5 миллиона человек и 3 000
организаций. Вторым по популярности протоколом является Whois++.
X.500 и Whois++ также могут использоваться для взаимного соединения
иной информации, не только информации IWPS, но здесь обсуждаются
лишь возможности IWPS.
Примечание: в Интернете существуют и другие, не соединённые между
собой базы адресов, также весьма популярные для хранения адресной
информации о людях. "Ph" — популярный протокол для использования с
автономной базой данных. В Интернете зарегистрировано более 300 баз
данных Ph. Однако для IWPS настоятельно рекомендуется взаимное
соединение баз данных, поскольку оно обеспечивает возможность найти
данные. Поэтому Ph в его нынешнем виде не считается хорошим
кандидатом для IWPS, но будущие разработки могут изменить эту
ситуацию (см. раздел 12).
В настоящее время в качестве протокола служб каталогов для IWPS
необходимо рекомендовать X.500. Однако будущая технология может
сделать возможным использование также других протоколов или их
использование вместо него.
Поскольку многие считают, что X.500 в Интернете в ближайшем будущем
будет заменён другими протоколами, здесь следует упомянуть, что в
настоящее время LDAP рассматривается как сохраняющийся компонент
сегодняшних реализаций и основной протокол доступа для завтрашних
служб каталогов. Как только станет доступна новая технология,
которая, вероятно, будет использовать LDAP, и эксперименты покажут,
что она работает, этот документ будет обновлён.
Сводку по продуктам X.500 можно найти в [14] (документе, который
будет регулярно обновляться).
Разделы 3–7 ниже содержат рекомендации, относящиеся к публикации
информации в IWPS и не зависящие от протокола служб каталогов.
Разделы 8–11 обсуждают вопросы, специфичные для X.500. В разделе 12
обсуждаются некоторые будущие разработки в той мере, в которой их
можно предвидеть на момент написания этого документа.
3. Кому следует публиковать информацию IWPS и как?
Информация IWPS — это открытая адресная информация о физических
лицах и организациях. Информацию IWPS, касающуюся физического лица,
следует публиковать и поддерживать организации, имеющей с этим лицом
прямую, устойчивую связь, например в следующих случаях:
- Лицо работает в организации, поддерживающей информацию.
- Лицо обучается в университете/школе, поддерживающем данные.
- Лицо является (персональным) абонентом интернет-службы
организации, поддерживающей информацию.
Организация, поддерживающая данные, не обязана хранить данные в
собственной локальной базе данных. Хотя ведение локальной базы
данных в службе X.500 или Whois++ не является слишком сложной
задачей, поставщикам интернет-услуг рекомендуется предоставлять
средства баз данных тем организациям среди своих клиентов, которые
поддерживают лишь небольшую часть информации IWPS или не имеют
достаточных ресурсов системного администрирования. Это побудит такие
организации присоединиться к IWPS. Сбор информации IWPS и поддержание
её актуальности следует всегда оставлять в ведении организации, к
которой относится эта информация.
В рамках текущих (национальных) схем именования X.500 записи о
физических лицах располагаются под организацией. В случае
поставщиков интернет-услуг, хранящих записи о своих абонентах, это
означало бы, что физических лиц можно найти, только если известно
имя поставщика услуг. Проблема этого ограничения могла бы быть
решена использованием более топографического подхода в схеме
именования X.500, но вероятнее будет решена будущей индексной службой
для служб каталогов, которая позволит искать физических лиц без имён
организаций (см. раздел 12).
4. Какую информацию следует публиковать?
В публикуемую информацию о физическом лице следует как минимум
включать:
- Имя физического лица.
- Адрес электронной почты физического лица в формате RFC-822;
при его отсутствии должна быть включена другая контактная
информация.
- Некоторое указание на отношение физического лица к стороне,
поддерживающей информацию.
Если в качестве протокола служб каталогов используется X.500,
последнее требование может быть выполнено использованием атрибута
"organizationalStatus" (см. [3]) или добавлением в локальное
пространство имён X.500 специальной организационной единицы,
отражающей отношение (например, ou=students или ou=employees).
Кроме того, в IWPS может быть включена иная открытая адресная
информация о физических лицах:
- Номер телефона физического лица.
- Номер факса физического лица.
- Почтовый адрес физического лица.
- URL домашней страницы физического лица в Web.
В ближайшем будущем хорошей идеей будет также хранить информацию об
открытом ключе.
Дополнительные сведения о рекомендуемой схеме Internet White Pages
приведены в The Internet White Pages Schema [16].
Организациям следует публиковать в IWPS следующую информацию о себе:
- URL домашней страницы организации в Web.
- Почтовый адрес.
- Номера факсов.
- Интернет-домен.
- Различные наименования и сокращения организации, которые, как
можно ожидать, люди будут искать, например английское
наименование и часто доменное имя организации.
Организации также могут публиковать номера телефонов и представление
о себе.
5. Управление данными
Управление данными, то есть сбор информации IWPS и поддержание её
актуальности, — задача, которую крупным организациям нельзя
недооценивать. В отношении этих вопросов можно сформулировать
следующие рекомендации:
- Организации следует добиться обязательства руководства начать
создание локальной базы данных с информацией IWPS. Это заметно
упростит получение сотрудничества от людей внутри организации,
которые будут участвовать в создании службы каталогов.
- Организации следует определить, какого рода информацию следует
включать в базу данных и как её следует структурировать.
Ей следует соблюдать интернет-рекомендации по структурированию
информации. Помимо критериев предыдущего раздела, при
использовании X.500 в качестве протокола служб каталогов
следует соблюдать [3] и [4].
- Организации следует определить критерии качества данных в
каталоге, такие как своевременность, частота обновления,
корректность и т. д. Эти критерии следует довести до сведения
всей организации, а предоставляющим данные подразделениям
следует принять обязательство соблюдать определённые уровни
качества.
- Существующие базы данных внутри организации следует в
максимально возможной степени использовать для извлечения
информации IWPS и локальной информации. Организации следует
привлечь людей, поддерживающих эти базы данных, и обеспечить
получение от них формального письменного обязательства
использовать их источник данных. Организации следует полагаться
на этих людей, поскольку они имеют опыт управления и контроля
локальных доступных данных.
- Лучшая мотивация организации присоединиться к IWPS состоит в
том, что одновременно у неё появится локальная база данных для
локальных целей. Локальная база данных может содержать больше
информации, не обязательно открытой, и выполнять больше задач,
чем требуется для IWPS. При подключении к IWPS организация
должна "отфильтровать" дополнительную локальную информацию и
службы, не предназначенные для открытой IWPS, с использованием
протокола служб каталогов.
6. Правовые вопросы
В большинстве стран действуют законы о защите приватности,
регулирующие публикацию информации о людях. Они варьируются от
либеральных законов США до требования Великобритании, согласно
которому информация должна быть точной, и до норвежского закона,
гласящего, что публикация невозможна без получения конкретного
разрешения от физического лица. Каждой стороне, поддерживающей
информацию IWPS, следует публиковать данные в соответствии с
национальным законодательством страны, в которой находится локальная
база данных, хранящая эту информацию.
Некоторые из них документированы в [5] и [1].
Стороне, поддерживающей информацию IWPS, следует также соблюдать
некоторые общие правила, даже если они не установлены законом:
- Публикуйте только корректную информацию.
- Предоставляйте людям возможность просматривать хранящуюся о них
информацию и право не предоставлять информацию либо добиваться
её изменения.
- Не публикуйте информацию "просто потому, что она есть".
Публикуйте то, что необходимо и считается полезным, и не более.
Учитывая количество вопросов управления данными и правовых вопросов, связанных с публикацией информации IWPS, качественные консультационные услуги крайне важны для того, чтобы небольшие компании могли быстро и эффективно присоединиться к IWPS. Поставщикам интернет-услуг рекомендуется предоставлять такие услуги.
7. Не взимайте плату за поиск
В текущей IWPS считается, что вследствие современных технологических ограничений взимание платы с пользователей вредит жизнеспособности сервиса. Для этого убеждения существует несколько аргументов:
- Технология микроплатежей в настоящее время недоступна.
- Сервисы по подписке требуют либо того, чтобы клиент подписался на несколько поисковых сервисов, либо того, чтобы сервисы были связаны «за кулисами» всевозможными двусторонними соглашениями; обе структуры имеют неприемлемо высокие накладные расходы и повышают стоимость присоединения к сервису.
- Текущие протоколы служб каталогов не поддерживают аутентификацию на уровне, который представлялся бы подходящим для платного сервиса.
Поэтому настоятельно рекомендуется, чтобы все поисковые запросы пользователей в IWPS были бесплатными. Это, разумеется, никоим образом не ограничивает возможность использовать тот же набор данных IWPS для поддержки других сервисов, в которых взимание платы может быть уместным.
8. Используйте X.500
IWPS, основанная на протоколе X.500, имеет сравнительно широкое распространение. Текущий сервис содержит около 1,5 миллиона записей о физических лицах и 3 000 записей об организациях. Он координируется Dante, поставщиком интернет-услуг в Великобритании, и известен как «NameFLOW-Paradise».
Хотя X.500 иногда критикуют за то, что его функциональность ограничена навязываемой им иерархической структурой именования, он обеспечивает достаточно хорошую функциональность, что было показано в нескольких пилотных проектах организаций [5], [2], [6], [7], которые сейчас эксплуатируют производственную IWPS на основе X.500. Пользовательские интерфейсы также определяют функциональность, предлагаемую IWPS на X.500. Обычно они предлагают поиск в IWPS на основе следующих вводимых пользователем данных:
- Имя человека
- Имя организации, с которой этот человек может быть связан
- Название страны
В результате они предоставят общедоступную информацию о соответствующем человеке. Большинство пользовательских интерфейсов предлагают возможность вывести список организаций в стране и пользователей в организации, чтобы помочь пользователям выбрать вводимые данные. Также может быть возможно использовать в качестве вводимых данных часть имен или приблизительные имена.
Специальные пользовательские интерфейсы могут предоставлять поиск на основе иных вводимых данных, таких как адреса электронной почты людей или почтовые адреса организаций. Однако такие возможности могут нарушать законы о конфиденциальности. В таком случае поставщики служб каталогов могут быть привлечены к ответственности.
Схема именования X.500 предъявляет к взаимосвязанной IWPS требование, чтобы все хранящиеся в ней записи имели уникальные имена («схема именования»). Проще всего это выполняется регистрацией всех записей в «дереве именования» с единым корнем; именно поэтому совокупность информации в IWPS на X.500 иногда называется «деревом информации каталога» (Directory Information Tree), или DIT.
Организациям настоятельно рекомендуется использовать протокол X.500 для присоединения к IWPS. Текущий сервис основан на стандарте X.500 1988 года [8] и некоторых специфичных для Интернета дополнениях к протоколу, соединяющему локальные базы данных [10], и к протоколу доступа [9]. Организациям следует использовать программное обеспечение X.500, основанное на этих спецификациях и дополнительно поддерживающее [11] для передачи протоколов OSI через Интернет.
Организации могут подключаться к инфраструктуре NameFLOW-Paradise с помощью DSA 1988 года, не реализующих [10], но у них не будет автоматической репликации ссылок на знания. Это будет неудобно, но не станет большой проблемой. Стандарт X.500 1993 года включает функциональность из [10], но использует другой протокол. Поэтому организации, подключающиеся к инфраструктуре с помощью DSA 1993 года, также столкнутся с этим недостатком. В разделе 12 «Будущие разработки» объясняется, почему инфраструктура пока не использует стандарт 1993 года.
За рекомендациями о том, какие атрибуты использовать в X.500 и как их использовать (либо для общедоступной информации IWPS, либо для дополнительной локальной информации), читатель отсылается к [3] и [4]. Для специальных непубличных локальных целей также могут быть определены новые атрибуты (и классы объектов). В целом следует рекомендовать как можно шире использовать многозначность атрибутов в X.500, поскольку это значительно улучшит поисковую функциональность сервиса. Например, атрибут organizationalName, содержащий название организации, или атрибут commonName, содержащий имя человека, следует включать все известные псевдонимы организации или человека. В частности, важно добавлять «читаемые» варианты всех атрибутов, по которым, как ожидается, будут выполнять поиск люди, если они содержат национальные символы.
Еще одна возможная рекомендация состоит в использовании репликации данных [10] между локальными базами данных для повышения производительности сервиса. Поскольку репликация всех записей части IWPS из одной локальной базы данных в другую может нарушать местные законы о конфиденциальности, рекомендуется ограничить репликацию записями о странах и организациях, а также ссылками на знания (которые указывают, куда обращаться за какой частью IWPS). Разумеется, законы о конфиденциальности не нарушаются, когда реплицирующей базой данных управляет та же организация, которая является основной для этой информации. Поэтому локальная репликация между двумя базами данных внутри одной организации настоятельно рекомендуется.
В целом репликация в пределах одной страны обычно представляет меньшую юридическую проблему, чем репликация через границы стран.
Рекомендации по эксплуатации базы данных в инфраструктуре X.500 можно найти в [12].
X.500 не рекомендуется использовать для:
- сервиса «Желтые страницы» большого масштаба. См. [5].
- поиска вне перечисленных здесь ограниченных шаблонов, в частности поиска человека без знания того, с какой организацией он может быть связан.
- публикации информации в наборах символов, отличных от ASCII, некоторых европейских письменностей на основе латиницы и японского языка (наборы символов T.61). Хотя поддержка этих наборов символов доступна в переработанных версиях X.500, продукты, поддерживающие эту переработанную версию, пока еще не получили широкого распространения.
9. Используйте глобальное пространство имен
Некоторые люди, например при использовании серверов Novell 4, решили использовать X.500 или X.500-подобные сервисы в качестве внутреннего механизма именования без координации с внешним источником.
Это страдает от многих тех же проблем, что и частные IP-адреса, только в большей степени: после решения открыть свои данные внешнему миру вам может потребоваться значительно реструктурировать их.
Глобально доступный сервис X.500 требует глобально связанного пространства имен X.500. Рекомендации о том, как создать локальную часть глобального пространства имен, см. в [3] и [4].
Хотя стандарт не очень ясен в этом отношении и его последняя версия (93), по-видимому, не поддерживает это, на практике пространство имен X.500 управляемо только при наличии единого корневого контекста, эксплуатируемого по соглашению о сотрудничестве. Однако можно быть уверенным, что за контроль над ним будут вестись территориальные споры.
Если эти территориальные споры не будут урегулированы вне фактически работающего сервиса, последствия для качества сервиса будут разрушительными.
Этот документ призывает всех участников данной области оставить существующую практику без изменений, пока не будет согласована и готова к внедрению лучшая система; в настоящее время корневой контекст эксплуатируется сервисом Dante NameFLOW-Paradise.
10. Используйте LDAP
В настоящее время LDAP, документированный в [9], является протоколом, который предлагает наибольшую функциональность X.500 там, где невозможно реализовать полный стек OSI.
Он реализован на множестве платформ, включая несколько платформ типа PC, и популярен во множестве коммерческих предложений.
Согласованные усилия по обеспечению доступности LDAP являются способом публикации, который обеспечивает наиболее широкий доступ к данным.
Кроме того, DSA X.500 должны реализовывать необходимые связи, чтобы гарантировать их надлежащую интеграцию в дерево именования/ссылок; в большинстве случаев это будет означать, что им следует реализовывать как минимум протокол X.500 DSP.
(В данном контексте несущественен вопрос, выполняется ли шлюзование LDAP в DAP или DAP в LDAP; может быть вполне уместно хранить данные на сервере только с LDAP и предоставлять их миру, использующему DAP/DSP, через шлюз, если все основные пользователи используют LDAP.)
11. Сделайте сервисы доступными
Технические вложения в эксплуатацию сервиса X.500 не являются огромными, см., например, [5].
12. Будущие разработки
Сегодня [октябрь 1996 года] ожидается несколько усовершенствований технологии IWPS.
Наиболее важным из упоминаемых здесь является создание «Common Indexing Protocol», который должен обеспечить интеграцию X.500, Whois++ и протоколов, использующих автономные базы данных. Такой протокол не только обеспечил бы интеграцию, но одновременно предоставил бы возможность исследовать сервисы «Желтые страницы» и расширенный поиск, даже если использовать его только для X.500.
В контексте Common Indexing Protocol следует упомянуть автономные серверы LDAP, о которых объявили несколько разработчиков программного обеспечения. Это автономные адресные базы данных, к которым можно обращаться через LDAP. В настоящее время также доступна версия из public domain от University of Michigan. Также объявлен шлюз LDAP-to-DAP, который может интегрировать автономный сервер LDAP в инфраструктуру X.500.
Другие усовершенствования включают определение общей базовой схемы для нескольких сервисов White Pages, что ведет к возможности доступа к данным в нескольких сервисах через единый протокол доступа.
Версия стандарта X.500 1993 года уже реализована в нескольких продуктах. В нескольких отношениях она является улучшением по сравнению со стандартом 1988 года, но в инфраструктуре NameFLOW-Paradise пока не реализована. Основная причина состоит в том, что стандарт не признает существование единого корневого DSA, а предполагает, что управляющие DSA первого уровня (DSA стран) заключают двусторонние договоры о взаимосоединении. В случае NameFLOW-Paradise такая ситуация была бы неуправляемой. В [13] предложено усовершенствование стандарта 1993 года, позволяющее иметь единый корень. Как только появятся реализации [13], NameFLOW-Paradise будет экспериментировать с DSA 1993 года. Это ожидается в 1997 году.
Когда эти разработки достигнут стабильности, на них могут ссылаться более поздние версии данного документа BCP.
13. Соображения безопасности
Последствий для безопасности от наличия каталога много.
- У людей появится стандартный способ доступа к опубликованной информации.
- Люди смогут собирать части информации для целей, которые вы никогда не предполагали (например, для публикации каталогов, создания поисковых систем, хедхантинга или совершения назойливых телефонных звонков).
- Люди будут пытаться получить доступ к большему объему информации, чем вы намеревались опубликовать, пытаясь взломать функции безопасности или подслушивая разговоры других пользователей с Каталогом.
- Если возможно изменение через Сеть, люди будут пытаться изменять вашу информацию непредусмотренными способами. Иногда пользователи будут изменять данные и по ошибке; не всякое нежелательное изменение является злонамеренным.
Первая защита безопасности каталога состоит в ограничении публикации материалами, с общедоступностью которых вы можете смириться, что бы ни произошло.
Вторая защита предполагает попытку установить контроль доступа. LDAP поддерживает несколько методов контроля доступа, включая использование паролей в открытом тексте. Пароли в открытом тексте не являются безопасным механизмом при наличии подслушивающих; этот документ поощряет использование более сильных механизмов, если возможность изменения предоставляется через открытый Интернет. В противном случае права на изменение следует ограничить локальной интрасетью.
Третья защита предполагает попытку предотвратить «ненадлежащий» доступ к каталогу, например ограничивать число возвращаемых элементов поиска или отказывать в операциях вывода списка там, где они бесполезны для предотвращения «прочесывания». Такие меры защиты редко бывают полностью успешными, поскольку очень трудно установить ограничения, отличающие невинного пользователя, выполняющего расточительный поиск, от злоумышленного сборщика данных, выполняющего тщательно ограниченные поисковые запросы.
Будущие усовершенствования могут включать использование зашифрованных сеансов, входа с использованием открытого ключа и подписанных запросов; такие механизмы сегодня, как правило, недоступны.
14. Благодарности
Авторы хотели бы поблагодарить следующих людей за их конструктивный
вклад в текст этого документа:
Peter Bachman <peterb@suport.psi.com>
David Chadwick <D.W.Chadwick@iti.salford.ac.uk>
William Curtin <curtinw@ncr.disa.mil>
Patrik Faltstrom <paf@swip.net>
Rick Huber <rvh@att.com>
Thomas Lenggenhager <lenggenhager@switch.ch>
Sri Saluteri <sri@qsun.ho.att.com>
Mark Wahl <M.Wahl@critical-angle.com>
15. Глоссарий
DAP Directory Access Protocol; протокол, используемый между DUA и
DSA для доступа к информации каталога. Часть X.500.
DSP Directory System Protocol: протокол, используемый между двумя DSA
DSA Directory System Agent — сущность, предоставляющая DUA и другим
DSA доступ к информации, хранимой в каталоге
LDAP Lightweight Directory Access Protocol — определён в RFC 1777
Дополнительные термины можно найти в RFC 1983.
16. Ссылки
[1] Jeunik, E. and E. Huizer. Directory Services and Privacy
Issues. Proceedings of Joint European Networking Conference
1993, Trondheim,
http://www.surfnet.nl/surfnet/diensten/x500/privacy.html
[2] Jennings, B. Building an X.500 Directory Service in the US,
RFC1943, May 1996.
[3] Barker, P., S. Kille, T. Lenggenhager, Building Naming and
Structuring Guidelines for X.500 Directory Pilots, P. Barker,
S. Kille, T. Lenggenhager, RFC1617
[4] The COSINE and Internet X.500 Schema. P. Barker & S. Kille,
RFC1274
[5] Introducing a Directory Service, SURFnet report 1995 (see
URL:
http://info.nic.surfnet.nl/surfnet/projects/x500/introducing/)
[6] Paradise International Reports, University College London,
April 1991 - April 1994
[7] Naming Guidelines for the AARNet X.500 Directory Service,
Michaelson and Prior, RFC 1562
[8] CCITT Blue Book, Volume VIII - Fascicle VIII.8, November 1988
[9] Lightweight Directory Access Protocol, W. Yeong, T. Howes, S.
Kille, RFC1777
[10] Replication and Distributed Operations extensions to provide
an Internet Directory using X.500, S. Kille, RFC1276
[11] ISO transport services on top of the TCP: Version: 3, M.
Rose, D. Cass, RFC1006
[12] Recommendations for an X.500 Production Directory Service, R.
Wright et al., RFC1803
[13] Managing the X.500 Root Naming Context, D. Chadwick, RFCxxxx
[14] A Revised Catalog of Available X.500 Implementations, A.
Getchell, S. Sataluri, RFC1632
[15] A Naming Scheme for c=US, The North American Directory Forum,
RFC1255
[16] A Common Schema for the Internet White Pages Service, T.
Genovese, B. Jennings, Work In Progress.
[17] Key words for use in RFCs to Indicate Requirement Level, S.
Bradner, RFC 2119,
17. Адреса авторов
Harald Tveit Alvestrand
UNINETT
P.O.Box 6883 Elgeseter
N-7002 TRONDHEIM
NORWAY
+47 73 59 70 94
Harald.T.Alvestrand@uninett.no
Peter Jurg
SURFnet
P.O.Box 19035
NL-3501 DA UTRECHT
THE NETHERLANDS
+31 30 2305305
Peter.Jurg@surfnet.nl