Кратко

  • 29 августа две ссылки без расширения не выдавали протоколы секций AVTCORE и MMUSIC на IETF 84, хотя соответствующие файлы обнаружились в копии материалов, полученной через rsync.
  • Сотрудники IETF добавили в поиск сервера PDF, HTM и другие расширения, реально встречающиеся в старых данных; ограниченная проверка 6 сентября получила HTTP 200 от обоих исходных адресов.
  • Наличие артефакта в хранилище, его доступность из публичной сети, идентичность возвращённого объекта и совпадение его байтов с заявленной версией — четыре самостоятельных состояния.
  • Машиночитаемый манифест должен связывать устойчивый идентификатор материала с точным путём, форматом, размером, хешем, версией, состоянием исправления, преемником и датой последней проверки.
  • Такой манифест не заменяет протокол и не удостоверяет истинность его содержания. Он лишь делает проверяемым выбор, который сервер совершает для исторической ссылки.

Ошибка была на маршруте, а не обязательно в хранилище

29 августа Jörg Ott сообщил, что из материалов IETF 84 не открываются протоколы AVTCORE и MMUSIC, хотя несколько случайно выбранных групп выглядели исправно. В первом сообщении он предложил автоматическую проверку ссылок и отметил ответ Cloudflare 1015, встреченный при разборе проблемы через слабое удалённое мобильное соединение.

Это наблюдение за публичным доступом, а не доказательство удаления или порчи. Carsten Bormann заглянул в другую копию: в синхронизированном через rsync собрании объёмом, по его оценке, 68 ГБ находились файлы обеих секций. Один локальный снимок не подтверждает полноту всех исторических материалов и неизменность байтов во всех репликах. Для двух спорных документов он всё же показывает, что хранение и веб-доступ разошлись.

В следующем письме Ott связал симптом с вариантами расширений PDF и HTM. 2 сентября сотрудники IETF описали точный механизм. Старые страницы заседаний ссылались на имена протоколов без расширений, а веб-сервер перебирал лишь ограниченный набор суффиксов. Этот набор расширили, включив .pdf, .htm и другие варианты из имеющихся данных. Сообщалось, что два указанных случая и несколько похожих теперь должны работать.

Там же говорилось, что ограничение частоты запросов установлено достаточно высоко и при обычном просмотре достигается с трудом; при повторении события предлагалось сообщить Cloudflare Ray ID. Это не опровергает ответ 1015, который видел Ott, и не доказывает общий сбой архива. Ошибка разрешения имени и ограничение доступа должны учитываться раздельно.

Код 200 может сопровождать неверный объект

При редкой контрольной загрузке 6 сентября адрес протокола AVTCORE без расширения вернул PDF размером 242 140 байт со значением Last-Modified из 2012 года. Наблюдавшийся SHA-256: 937e224285a7eae6bf1cbeb9106e5eb0bf4df7b34bf02a10587f6da9ef4e49e1. Адрес протокола MMUSIC отдал HTML, также датированный 2012 годом, с SHA-256 88a6f5fd2d5459bfa1c66dc7d24b54e441a4e05507e009adf99409486c19a214.

Эти значения фиксируют результат в конкретный день, но сами по себе не объявляют вечный канонический объект. Прямые адреса с окончаниями avtcore.html и mmusic.html тоже отвечали успешно, однако содержали другие байты и групповые страницы с датой 2021 года, а не протоколы. Простое добавление привычного .html могло привести к существующему, но неверному документу.

Оглавление IETF 84 предназначено прежде всего для человека. Перебор расширений сохраняет старые переходы при неоднородных исторических именах. Такая удобная ссылка не различает четыре утверждения:

  1. Существование: объект, относящийся к заседанию, есть в каком-либо хранилище или зеркале.
  2. Доступность: публичный запрос сейчас способен что-то получить.
  3. Идентичность: ответ является заявленным протоколом, а не страницей группы или случайным кандидатом.
  4. Целостность: возвращённые байты совпадают с объявленной версией на указанную дату.

Сентябрьская правка непосредственно улучшила доступность. Копия Bormann дала ограниченное свидетельство существования. Тип, длина и хеш позволяют исследовать идентичность и целостность. Ни один из этих признаков не подтверждает полноту или точность протокола и не наделяет его дополнительным статусом IETF.

У протокола больше состояний, чем «есть» и «нет»

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

Действующая инструкция по материалам заседаний называет подачу протоколов обязательной, перечисляет форматы и разделяет периоды подачи и исправления. В напоминании Секретариата об IETF 126 от 13 августа были указаны секции, где протоколы ещё отсутствовали перед сроком 14 августа, а на исправления отводилось время до 8 сентября. По промежуточному списку нельзя судить об окончательной полноте. Он зато показывает разные стадии: не подан, принят, опубликован, исправлен, заменён и доступен сейчас.

Точное описание для гибкого адреса

Минимальный манифест целостности должен называть номер встречи, группу или секцию, вид материала и устойчивый логический идентификатор. Затем он связывает эту сущность с конкретным путём объекта, типом MIME, числом байтов и криптографическим хешем.

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

Исправление должно добавлять новую версию и явную связь замещения. Старый хеш не должен молча начинать означать новые байты. Удобная ссылка может вести читателя к текущей редакции; точные сведения о каждой исторической версии остаются для цитирования и воспроизведения.

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

Публичные проверки следует распределять во времени, чтобы аудит не создавал собственную нагрузку. Зелёный результат означает только то, что в зафиксированный момент заявленный объект был получен и совпал по формату, размеру и хешу. Узость формулировки делает её полезной.

Источники

  1. Сообщение Jörg Ott о недоступных протоколах
  2. Carsten Bormann о копии через rsync
  3. Уточнение о расширениях PDF и HTM
  4. Объяснение и исправление сотрудников IETF
  5. Напоминание о протоколах IETF 126
  6. Руководство IETF по материалам встреч
  7. RFC 2418
  8. Материалы IETF 84
  9. Адрес протокола AVTCORE
  10. Адрес протокола MMUSIC
  11. Lu Heng о приоритете работающего кода