Кратко

  • RFC 1295 — январский документ Informational 1992 года North American Directory Forum, а не Internet Standard. Для записей и включений в Public Directory он перечислил семь прав: не быть включённым; получить уведомление при создании записи; изучить её; исправить неточные сведения; удалить определённые сведения; ожидать соблюдения применимого законодательства США или Канады о конфиденциальности либо доступе к информации; и ожидать своевременного исполнения.
  • Этот текст не устанавливает протокол удаления и не обещает безопасность. Он различает публичные и частные части справочника и допускает публичное, частное или смешанное включение по выбору пользователя либо его агента. RFC 1417, выпущенный в 1993 году, затем описал конкурирующих поставщиков, публичное пространство имён и отдельно управляемые частные пространства.

Исторический вопрос RFC 1295, User Bill of Rights for entries and listings in the Public Directory не сводился к тому, способен ли справочник в духе X.500 хранить атрибуты. Он спрашивал, превращает ли способность сохранить атрибут, проиндексировать его и вернуть в ответ на запрос в право показать этот атрибут публике. North American Directory Forum предложил не настройку доступа, а порядок: до технической видимости остаётся положение человека, который может отказаться от включения.

Этот порядок важен потому, что публичная обнаружимость меняет последствия одних и тех же данных. Телефонный номер, электронный адрес или принадлежность к организации могут быть обычной рабочей информацией в ограниченном отношении, но в открытом индексе становятся ориентиром для любого ищущего. RFC говорит, что пользователь или его агент может выбрать размещение информации в Public Directory, в частном справочнике или в сочетании двух вариантов. Пример намеренно скромен: телефон или почтовый адрес могут быть публичными, а другая информация — оставлена для определённого частного использования.

Речь не о вечной метке «безопасно» или «опасно» на поле. Речь о выборе аудитории.

Не быть включённым — не то же самое, что потом удалить запись

Первое право легко прочитать как более раннюю форму запроса на удаление. Но оно сильнее по времени. Удаление начинается после того, как запись уже существует. Неразмещение задаёт иной вопрос: должна ли публичная запись создаваться вообще? Первое касается изменения уже допущенного в публичное пространство объекта; второе — решения о допуске.

Следующее право, уведомление при создании записи, тоже нельзя превращать в согласие. Уведомление может доказать лишь то, что оператор отправил сообщение о действии, которое уже совершил. Оно не доказывает, что субъект разрешил создание, прочёл сообщение, понял масштаб публикации или получил действенную возможность возразить. Но уведомление делает создание отслеживаемым событием. Вместо безмолвного появления записи есть действие, предполагаемый адресат, момент и объект, который можно проверить.

Поэтому семь прав не стоит сжимать в одно общее обещание конфиденциальности. Получение указания не включать не доказывает, что публичной записи не создали. Наличие записи не доказывает согласия. Отправленное уведомление не доказывает согласия. Возможность посмотреть запись не доказывает её точности. Заявление об исправлении не доказывает изменения видимой версии. Обновлённая у поставщика копия не доказывает исчезновения остальных копий. У каждого утверждения свой исполнитель, время, версия и доказательство; соседний шаг не может молча служить его заменой.

Исправление и удаление отдельного сведения — разная работа

RFC 1295 отдельно называет просмотр, исправление неточной информации и удаление конкретной информации. Это точнее, чем общий ярлык «редактирование профиля». Просмотр отвечает на вопрос, что именно утверждает запись. Исправление относится к точности утверждения: неверному адресу, устаревшей принадлежности, ошибочно приписанному человеку факту. Удаление конкретного сведения отвечает на другую ситуацию: факт может быть верным, но его не следует продолжать показывать этой аудитории.

И доказательства здесь различаются. Для исправления требуется назвать неточное утверждение и версию, которая его заменяет. Для выборочного удаления нужно указать атрибут, аудиторию и инструкцию больше не показывать его, не делая вид, будто вся личность, все связи и все сервисы вокруг записи автоматически исчезли. RFC не определяет распределённую операцию стирания и не даёт способа проверять состояние реплик. Его вклад скромнее и важнее: точность и раскрытие — это разные поверхности управления.

Седьмое ожидание, своевременное исполнение, превращает права в обязанность поставщика услуг. Наличие формы, страницы политики или общего сообщения о закрытии не делает запрос выполненным. Вместе с тем RFC не задаёт глобальный срок и не разрешает конкретный спор. Он описывает операционное отношение: запрос должны принять, сопоставить с объектом, рассмотреть, при необходимости изменить и сопровождать ответом. Публичная запись — не просто набор сохранённых полей.

Публичное пространство имён не владело частными записями

RFC 1295 помещает обсуждение в планируемую североамериканскую кооперативную службу электронных справочников, ориентированную на стандарты CCITT X.500. Directory описан как совокупность электронных справочников, которыми управляют поставщики услуг и частные операторы. Сведения в записи могут быть доступны, если ограничения безопасности и конфиденциальности не препятствуют этому; часть, предназначенная для публичного распространения, образует Public Directory, а другие части могут не предназначаться для общего доступа.

Технический словарь легко создаёт впечатление, будто иерархия имён, маршрут запроса или отношение репликации уже отвечают на вопрос о власти. Они отвечают лишь на вопрос, как клиент может дойти до ответа. Они не решают, кто выбрал аудиторию, точны ли данные, уполномочен ли агент, дошло ли уведомление или исполнена ли просьба. Видимость — свойство наблюдаемой поверхности. Полномочие на публикацию — отношение, которое требует отдельного подтверждения.

RFC 1417, NADF Standing Documents: A Brief Overview, опубликованный в 1993 году и делающий RFC 1295 obsolete, раскрывает институциональную причину такого различия. Он говорит о конкурирующих поставщиках, пытавшихся совместно предоставить Public Directory Service, о публичном пространстве имён рядом с отдельно управляемыми частными пространствами и о регистрации, происходящей вне Directory. Субъект мог выбрать включение там, где другие, вероятно, будут искать. Общее пространство было картой обнаружения, а не титулом собственности на каждую частную запись за этой картой.

RFC 1417 также отмечает, что X.500(88) не имел процедур knowledge maintenance и что конкуренция поставщиков делала исключительное управление публичным пространством невозможным. Описанное направление — кооперативные ссылки из публичного пространства в частные пространства с малой полезной нагрузкой самих ссылок. Это не доказывает поведение каждой реализации и не доказывает, что конкретное удаление устранило все дубликаты. Но это показывает, почему общий маршрут нуждался в границах ответственности: ни один поставщик не мог честно говорить от имени всех частных записей.

Памятка задаёт границу, а не механизм принуждения

Статус текста не позволяет приписывать ему больше, чем он говорит. RFC 1295 имеет статус Informational, а не Internet Standard, и называет себя почти дословной копией NADF-265. В разделе Security Considerations прямо сказано, что вопросы безопасности не обсуждаются. Следовательно, из него нельзя вывести шифрование каждого запроса, аутентификацию каждого агента, предотвращение копирования, гарантированное удаление или всемирно обязательное правовое правило.

Упоминание применимых законов США или Канады о конфиденциальности и доступе к информации также не доказывает современное соблюдение права. Оно не даёт актуального правового теста, не решает вопрос другой юрисдикции и не превращает ответ справочника в юридическое удостоверение. Однако оно не позволяет оператору представить себя нейтральным проводником между полями и поиском: публичное включение создаёт отношение доступа с процедурной ответственностью.

Потому видимый результат поиска не доказывает ни согласия, ни правового соответствия, ни операционного результата. Отсутствие результата не доказывает, что записи никогда не было, что нет реплики или что удаление завершилось везде. Подтверждение получения не доказывает исправления. Текущая копия у поставщика не доказывает, что все последующие читатели увидят именно её. RFC даёт лексику для аккуратного вопроса, но не пропускает недостающие звенья доказательств.

Источники и пределы доказательств

Источники — RFC 1295 и RFC 1417. Вместе они подтверждают статус Informational января 1992 года, почти дословную связь с NADF-265, кооперативный контекст X.500, семь прав, различие публичного и частного справочника, а также последующее описание конкурирующих поставщиков и связанных пространств имён. Они не подтверждают нынешний справочник, индивидуальный запрос, фактическое получение уведомления, конкретное исправление, исчезновение копии, состояние репликации, соблюдение права или гарантию безопасности.