Кратко

  • RFC 2987 дал charset и language одинаковое сравнение, но первый признак обычно обозначал возможность устройства, а второй — предпочтение человека.
  • Основные имена наборов символов и сравнение полного языкового токена снижали неоднозначность, не доказывая декодирование, отображение, качество речи или понимание.
  • Вес q упорядочивал предикаты для локального решения; он не подтверждал наличие варианта, удовлетворённость пользователя или успех услуги.

Две регистрации рядом

RFC 2987 вышел в ноябре 2000 года как Proposed Standard. Это небольшой документ, почти полностью состоящий из двух регистрационных форм по процедуре RFC 2506. charset получил OID 1.3.6.1.8.1.31, а language1.3.6.1.8.1.32. В действующем реестре IANA они по-прежнему занимают позиции 31 и 32 в дереве признаков IETF.

Общий реестр позволял разным протоколам описывать возможности и предпочтения представления, не изобретая несовместимые словари. RFC 2533 задавал синтаксис для объединения предикатов и добавления значений качества. Согласованные имена переносили вопрос между независимыми реализациями.

Формально записи были почти зеркальными. Значения — зарегистрированные токены. Разрешено только равенство. Регистр букв не учитывается. Примеры объединяют варианты оператором OR и назначают им веса q.

Но RFC 2987 не позволил форме определить смысл.

Для большинства устройств charset обычно является возможностью: текст в неизвестном наборе символов устройство, как правило, не может осмысленно обработать. language обычно является предпочтением, а не требованием. Под «отображением» языка документ часто подразумевал синтезированную речь, но граница шире: желание человека получить один язык не означает технической неспособности машины представить другой.

Один механизм выражал два разных вида ограничения.

Набор символов задаёт исполнимую границу

В примере utf-8, iso-8859-1 и utf-16 получают 1,0, 0,9 и 0,5. Но веса не превращают отсутствующий декодер в доступную альтернативу.

Совпадение charset=utf-8 не доказывает, что пришедшие байты действительно UTF-8. Декодера может не быть, либо он может ошибаться. После корректного преобразования шрифт может не содержать нужных глифов. Правильно нарисованный текст может остаться непонятным читателю. Каждый переход требует отдельного свидетельства.

RFC 2913 зарегистрировал type как самостоятельный признак. Устройство может поддерживать text/plain, не поддерживая все способы кодирования простого текста. Тип представления и правило преобразования байтов в символы связаны, но не тождественны.

Имена тоже создавали риск. RFC 2978 допускал несколько имён одного набора символов, но требовал одно основное имя и однозначность каждого имени. RFC 2987 советовал не использовать псевдонимы в выражениях, поскольку инструменты могли преобразовать их в основное имя при обработке.

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

Документ также требовал указывать charset вместе с любой возможностью обработки текстовых данных. Слово «текст» не объясняет, по какому правилу байты станут символами.

Язык упорядочивает человеческий выбор

В языковом примере перечислены no-nynorsk, no-bokmaal и i-sami-no. Оператор равенства тот же, но несовпадение не обязательно означает невозможность.

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

RFC 2987 сохранил правило: сравнивать целый токен без учёта регистра и не использовать подтеги для сравнения. Из структуры строки нельзя выводить полномочия говорить от имени человеческого понимания.

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

Если сделать каждое предпочтение жёстким запретом, система отбросит полезный контент. Если всегда игнорировать предпочтение, из выбора исчезает пользователь. Стандарт сделал входные данные сопоставимыми, но не создал глобального арбитра.

Значение качества не измеряет качество результата

В RFC 2533 значение качества уточняет предикат и по умолчанию равно 1. Универсальной формулы объединения всех предпочтений документ не определяет. У разных приложений разные кандидаты и разная цена ошибки.

Поэтому q=1.0 показывает только высокий ранг предиката в конкретном профиле. Он не подтверждает свежесть профиля, наличие контента, разборчивость речи, соответствие метки байтам или достижение цели пользователем.

Для charset граница жёстче, но вес всё равно не устанавливает декодер, не доказывает сохранность байтов и не подтверждает отображение.

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

Реестр называет, код решает

Сохранение записей IANA показывает ценность минимальной координации. Независимые реализации используют одинаковые имена и сравнения. Но из реестра не возникает центральный оценщик.

Создатель профиля определяет заявление. Поставщик определяет доступные варианты. Получатель определяет нормализацию, ранжирование и откат. Пользователь испытывает последствия. Вся цепочка никому одному не принадлежит.

Идея минимальной начальной спецификации Lu Heng помогает провести границу: общий слой фиксирует только необходимые для совместимости имена, области значений и сравнения. Последующие решения остаются локальными.

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

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

Слои реальности — регистрация, выражение, нормализация, оценка, выбор, возможность, выполнение, восприятие и результат. Истинность раннего слоя не даёт ему права свидетельствовать за последующие.

Ограниченное предупреждение о безопасности

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

Предупреждение всё же показывает, что профиль возможностей — операционные данные. Он направляет выбор и может раскрывать поверхность атаки. Следует раскрывать только необходимое и не считать «принимается» синонимом «безопасно».

Историческое достижение RFC 2987 не в том, что метки стали одинаковыми. Документ позволил им использовать общий механизм, сохранив разную силу утверждений.

Одна метка обычно отвечала: может ли машина? Другая: чего хочет человек? Равенство и веса координировали ответы, но не делали их равноправными доказательствами.

Источники