Кратко

  • RFC8141 исключает необязательные компоненты r, q и f из сравнения имён URN. Это не общее разрешение удалять их при обработке любых обращений к службам.
  • q предназначен для именованного ресурса или системы, предоставляющей услугу. Служба разрешения не вправе требовать эти сведения для собственной обработки. В описанном случае возврата URI-локатора q переносится в его строку запроса; при уже существующей строке обязательного способа объединения нет, а стратегию рекомендуется документировать.
  • RFC8141 резервирует синтаксис r, оставляя семантику будущей стандартизации. Корректная форма не доказывает наличие работающего протокола. Равенство имени, действительность присвоения, выбор представления и разрешение доступа требуют разных оснований.

Один ключ не отвечает на все вопросы

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

Это гипотетическая ситуация проектирования, а не обнаруженный в данной работе сбой конкретного продукта. Она показывает, как удобная абстракция может получить полномочия, которых не даёт исходное правило. RFC8141, опубликованный в апреле 2017 года, описывает синтаксис и сравнение Uniform Resource Name в системе URI. Необязательные компоненты позволяют сопровождать имя дополнительными сведениями. Такие сведения могут не участвовать в установлении имени и всё же иметь адресата на следующем этапе.

Основная процедура сравнения достаточно точна. Регистр urn и идентификатора пространства имён NID приводится к единому виду. Шестнадцатеричные буквы A–F в группах процентного кодирования строки NSS, специфичной для пространства, записываются в верхнем регистре. Это не команда переводить всю NSS в нижний регистр. Не является она и указанием декодировать процентные группы перед сравнением. Универсальная очистка текста может изменить больше, чем разрешает данная процедура.

r, q и f в этом сравнении не учитываются. Указателю не нужно создавать новое имя для каждой опции обращения или позиции внутри представления. Однако вычислить отдельный ключ и необратимо переписать входной запрос — разные действия. Реализация может сохранить исходное обращение и использовать ключ только там, где нужен именно результат сравнения имён. Общий термин «нормализация» не делает назначения этих двух объектов одинаковыми.

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

Разделение важно не только для программиста. Указатель решает, как организовать имена. Служба разрешения действует в пределах своего контракта. Ресурс интерпретирует предназначенные ему сведения. Клиент при необходимости работает с частью полученного представления. Если первая ступень заранее удаляет входные данные остальных, она меняет не только расход памяти, но и доступный им материал для решений. Простой опыт, вернувший тот же текст, может этого не показать.

q может пройти через посредника без полной интерпретации

Компонент q начинается с ?= и предназначен для именованного ресурса или системы, оказывающей услугу. Его конкретный эффект определяется контекстом. Разные значения могут привести к одному представлению, а могут участвовать в другом выборе. Статья не утверждает ни универсального различия ответов, ни их универсального совпадения. Ограниченный вывод состоит в том, что равенство имени само по себе не доказывает ненужность этих сведений для любого запроса.

RFC8141 запрещает службе разрешения требовать информацию q для собственной обработки. Именно к этому относится MUST NOT. Службе не нужно становиться обязательным знатоком всех прикладных условий каждого ресурса, чтобы разрешить имя. Но отсутствие такой зависимости не превращает её в орган, который решает, что информация не нужна никому. Посредник способен передать сведения надлежащему получателю, не управляя их полной семантикой.

В описанном случае получения URI-локатора q копируется в часть запроса найденного локатора. Компонент, исключённый из сравнения имени, получает функцию в другой операции. Здесь необходимо сохранить предел применимости: не всякий возможный результат разрешения представляет собой один такой адрес. Без указания на покрываемый случай точная норма превращается в недоказанное обобщение обо всех службах.

Найденный адрес уже может содержать запрос

Перенос в пустую часть адреса — не самый сложный случай. Сложность появляется, если у возвращаемого локатора уже есть строка запроса. Тогда встречаются сведения из найденного адреса и сведения q из исходного URN. Можно вообразить соединение, замещение или разные приоритеты, но RFC8141 не устанавливает обязательное поведение для этой ситуации. Вместо этого он рекомендует службе разрешения документировать выбранную стратегию.

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

В контролируемой среде можно было бы разрешить URN с q в адрес с существующим запросом, сначала записать результат сравнения, затем построенный URI и только после этого получить представление. Здесь такие опыты не проводились. Это предложение о способе проверки, не отчёт о поведении нынешнего поставщика. Раздельные наблюдения не требуют считать, что любая текстовая разница должна обязательно изменить содержимое.

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

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

Синтаксическое место не доказывает работоспособность

r начинается с ?+ и предназначен для сведений, направленных службе разрешения. RFC8141 определяет синтаксис, а семантику оставляет будущей стандартизации. До стандартизации семантики компонент рекомендуется не применять. Способность анализатора принять символы ещё не доказывает наличие команды с совместимым смыслом, которую служба умеет исполнять. Формальное распознавание и действующий контракт — разные факты.

Этот вывод ограничен данной спецификацией. Исследование не доказывает, что ни один последующий документ нигде не определил r. Оно также не проверяло поддержку у нынешнего поставщика. Нельзя лишь представлять резерв в RFC8141 как уже завершённый эксплуатационный протокол без дополнительного основания. Если появится релевантная позднейшая спецификация, её содержание и область применения следует рассмотреть отдельно.

f, расположенный после #, указывает положение или область, с которыми работает клиент. В описанном случае получения представления смысл фрагмента определяется медиатипом этого представления. Это не единая семантика для всех возможных результатов разрешения и не обязанность посредника понимать любой формат. Исключить f из сравнения имени и сохранить для правильного адресата — согласованные, а не противоречивые действия.

Словосочетание «необязательные суффиксы» не передаёт всю архитектуру. У r, q и f различаются получатели, функциональные ограничения и состояние определения смысла. Ни один компонент не создаёт разрешение доступа самим своим присутствием. Ни один не становится повсеместно лишним из-за отсутствия в базовом сравнении. Распределение ролей точнее, чем общее указание либо всё удалять, либо всё толковать в одном центре.

ISSN показывает разные требования разных этапов

Реестр IANA и сохранённые документы пространств ISBN и ISSN напоминают о действительности имени. Она зависит от зарегистрированного пространства и правил присвоения. Синтаксически правдоподобная строка не доказывает корректное назначение идентификатора. В свою очередь, равенство имён не доказывает право лица выполнить операцию над ресурсом. У этих утверждений должны быть отдельные доказательства.

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

RFC8254 в 2017 году перевёл регистрации ISBN и ISSN на новую основу и заменил RFC3044 и RFC3187. Практика идентификаторов по стандартам ISO может развиваться без повторения той же формальной процедуры одобрения регистрационного шаблона при каждом изменении. Но сохранённый исторический документ не становится полным отчётом о самой новой практике ISO или поведении работающего сегодня сервиса. История регистрации и эксплуатационные наблюдения остаются разными видами свидетельств.

Кэш ответов использует другой объект сравнения

Если после разрешения происходит получение по HTTP, на этой поздней ступени применимы соответствующие правила кэширования. По RFC9111 ключ кэша состоит как минимум из метода запроса и целевого URI. Vary участвует в выборе сохранённого ответа с учётом соответствующих полей запроса. Равенство исходных имён URN не заменяет эти критерии.

Это рассуждение об этапе HTTP, а не о каждом разрешателе URN и не о любой форме хранения. Разные URI также не обязаны давать разное содержимое. Главное — индекс имён и кэш ответов упорядочивают разные объекты. Возможность технически представить их ключи строками не делает одинаковыми условия повторного использования. Узнать ресурс ещё не значит выбрать ответ на конкретное обращение.

RFC3401 о DDDS даёт исторический контекст разрешения, но не предписывает каждой службе URN одну и ту же последовательность действий. Пространство example в RFC6963 служит иллюстрациям. Оно не доказывает, что определённый идентификатор связан с развёрнутой инфраструктурой. Архитектурный пример помогает объяснить возможность, а эксплуатационное свидетельство должно подтвердить наличие этой возможности в конкретной среде.

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

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

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

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

Источники