Кратко

  • RFC 822, опубликованный в августе 1982 года, разделил официально публикуемые расширения почтовых сообщений и поля, придуманные пользователями. Первым запрещалось начинаться с X-; вторым оставили защищённый набор имён.
  • Защита потребовала поддержки псевдонимов. RFC 2068, январь 1997 года, просил приложения HTTP ради совместимости считать x-gzip и x-compress эквивалентами gzip и compress. RFC 5064, декабрь 2007 года, стандартизировал Archived-At, но также описал и зарегистрировал прежнее X-Archived-At.
  • RFC 6648, июнь 2012 года, отменил обычай давать префикс новым текстовым параметрам прикладных протоколов. Программы не должны определять официальный статус или безопасность поля по его написанию; для этого нужны реестры и ясные правила регистрации.

Отдельная полка для местных опытов

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

Такую схему закрепил RFC 822 в августе 1982 года. Он отличал поля расширений, определённые в официальных публикациях, от полей, которые могли придумать пользователи. Названия первых никогда не должны были начинаться с X-. Вторым доставалась защищённая зона. Внутри организации можно было передавать дополнительные сведения, не дожидаясь общего стандарта.

Для человека X- означало положение идеи: сейчас она частная. Для программы эти символы были частью точного идентификатора. Код, который ищет X-Example, не начинает понимать Example только потому, что позднее комитет одобрил имя без префикса. Организационный статус меняется в документе, а буквы уже лежат в сохранённых сообщениях и в правилах работающих программ.

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

HTTP заплатил за два имени ещё в 1997 году

Короткая фраза в RFC 2068, опубликованном в январе 1997 года, показывает платёж. Для совместимости с предыдущими реализациями HTTP приложениям предлагалось считать x-gzip эквивалентом gzip, а x-compresscompress. Авторы стандарта не могли выбрать одно аккуратное название и забыть другое. Старые написания уже встречались в той среде, с которой документ должен был взаимодействовать.

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

В почте изменилось и само разделение. RFC 2822, апрель 2001 года, заменил RFC 822 и описал необязательные поля без прежнего грамматического деления на официальное расширение и пользовательское поле. Удалить границу из новой спецификации можно; переписать старые письма и программы таким способом нельзя.

Затем RFC 5064 в декабре 2007 года определил Archived-At, поле со ссылкой на архивную копию письма. Ради обратной совместимости документу пришлось описать предшественника X-Archived-At. Старое поле разрешалось разбирать, но его не рекомендовали создавать заново. Оно было зарегистрировано как устаревшее рядом с новым. Официальное признание функции оставило в справочнике сразу две записи.

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

Префикс лишился права присваивать статус

RFC 6648, опубликованный в июне 2012 года как действующая практика IETF, описал повторяющийся сбой. Неофициальный параметр может получить широкое распространение. Когда его стандартизируют под новым именем, старые реализации знают только вариант с префиксом, а новые могут знать лишь официальный. Ради совместимости приходится сохранять старую форму надолго. Пространство для опытов становится фактическим стандартом, который стандарт письменный вынужден обслуживать.

Для вновь определяемых текстовых параметров прикладных протоколов документ советовал отказаться от X-. Удалять все существующие поля он не требовал: решение остаётся за их ответственными. Частные эксперименты не запрещались, особые правила отдельных протоколов не отменялись автоматически. Отвергли идею, что текущую институциональную оценку следует навсегда записывать в передаваемое имя.

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

Взамен разработчикам протоколов рекомендовали реестры с достаточным пространством и простым порядком записи, при необходимости с предварительной и постоянной регистрацией. Имена с X- тоже могут регистрироваться. Их статус должен быть указан в записи, а не угадан по двум первым символам. Тогда по мере взросления проекта запись может измениться без обязательного появления второго имени в сетевых сообщениях.

Есть и риск при механическом переименовании. Стандартизация иногда меняет смысл или требования безопасности экспериментального поля. Если программа просто срежет X- и объявит обе версии одинаковыми, она может внести новую ошибку. Указание RFC 2068 об эквивалентности x-gzip относится к этим конкретным кодированиям. Это не универсальное правило переписывания любых полей.

Успешный эксперимент оставляет имя в наследство

Разделение 1982 года давало свободу пробовать. Решение 2012 года признало следствие удачи: программы читают имя, архивы его сохраняют, другие системы на него опираются. К моменту официального переименования у прежнего варианта уже есть участники, которых нельзя обновить одним голосованием.

В первичных документах счёт виден: стандарт HTTP 1997 года связал два названия кодирования, а почтовый стандарт 2007 года зарегистрировал устаревшего предшественника вместе с преемником. Число установленных программ для каждого года потребовало бы отдельных свидетельств. Но распределение власти уже ясно. Организация может изменить реестр; работающие программы и хранимые письма определяют, сколько стоит перестать понимать прежнее имя.

RFC 6648 не очистил старый ящик. Он попросил новых разработчиков не строить следующий. Положение эксперимента можно указать в реестре и обновить позже; сетевое имя не обязано меняться вместе с решением комитета.