RFC 5988 | Веб-ссылка

Аннотация

Этот документ определяет типы отношений для веб-ссылок и определяет реестр для них. Он также определяет использование таких ссылок в заголовках HTTP с полем заголовка Link.

Скачать оригинальный документ на английском языке RFC 5988 PDF

 

Оглавление

1. Введение
2. Условные обозначения
3. Ссылки
4. Типы отношений ссылок
4.1. Типы зарегистрированных отношений
4.2. Типы отношений расширения
5. Поле заголовка ссылки
5.1. Целевой IRI
5.2. Контекстный IRI
5.3. Тип отношений
5.4. Целевые атрибуты
5.5. Примеры
6. Соображения IANA
6.1. Ссылка HTTP Заголовок Регистрация
6.2. Реестр типов отношений ссылок
6.2.1. Регистрация новых типов отношений ссылок
6.2.2. Начальное содержимое реестра
6.3. Реестр данных приложений связи ссылок
7. Вопросы безопасности
8. Вопросы интернационализации
9. Ссылки
9.1. Нормативные ссылки
9.2. Информационные ссылки
Приложение A. Примечания по использованию заголовка ссылки в формате HTML4
Приложение B. Примечания по использованию заголовка ссылки в формате Atom
Приложение C. Благодарности

 

Статус этой заметки

Это документ по отслеживанию стандартов Интернета.

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественную рецензию и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о Интернет-стандартах доступна в Разделе 2 RFC 5741.

Информацию о текущем состоянии этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу http://www.rfc-editor.org/info/rfc5988.

 

Уведомление об авторских правах

Copyright (c) 2010 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

На данный документ распространяется действие ППГ 78 и Правовые положения IETF Trust, касающиеся документов IETF (http://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны содержать текст Упрощенной лицензии BSD, как описано в Разделе 4.e Правил доверия, и предоставляются без гарантии, как описано в Упрощенной лицензии BSD.

Этот документ может содержать материалы из Документов IETF или Вкладов IETF, опубликованных или обнародованных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из этих материалов, возможно, не предоставили Трасту IETF право разрешать модификации таких материалов. вне процесса стандартизации IETF. Без получения адекватной лицензии от лица (лиц), контролирующего авторские права на такие материалы, этот документ не может быть изменен вне процесса стандартизации IETF, и его производные работы не могут быть созданы вне процесса стандартизации IETF, за исключением того, что он форматируется для публикация в качестве RFC или перевод на другие языки, кроме английского.

 

1. Введение

Средство указания взаимосвязей между ресурсами в Интернете, а также указание типа этих взаимосвязей было доступно в течение некоторого времени в HTML [W3C.REC-html401-19991224], а позднее в Atom [RFC4287]. Эти механизмы, хотя концептуально схожи, указаны отдельно. Тем не менее, ссылки между ресурсами не должны быть специфичными для формата; может быть полезно иметь типизированные ссылки, которые не зависят от их сериализации, особенно когда ресурс имеет представления в нескольких форматах.

С этой целью этот документ определяет структуру для типизированных ссылок, которая не является специфичной для конкретной сериализации или приложения. Это делается путем переопределения реестра связей ссылок, созданного Atom, для расширения домена, и добавления к нему отношений, определенных в HTML.

Кроме того, поле заголовка HTTP для передачи типизированных ссылок было определено в Разделе 19.6.2.4 [RFC2068], но удалено из [RFC2616] из-за отсутствия опыта реализации. С тех пор он был реализован в некоторых пользовательских агентах (например, для таблиц стилей), и всплыло несколько дополнительных вариантов использования.

Поскольку он был удален, состояние заголовка Link неясно, что побуждает некоторых задуматься о создании новых заголовков HTTP для конкретных приложений, а не о его повторном использовании. Этот документ решает эту проблему путем повторного указания заголовка Link как одной из таких сериализаций с обновленным, но обратно совместимым синтаксисом.

 

2. Условные обозначения

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119].

Этот документ использует расширенную нотацию Бэкуса-Наура (ABNF) [RFC2616] и явно включает в себя следующие правила: кавычка-строка, токен, SP (пробел), LOALPHA, DIGIT.

Кроме того, из [RFC3986] включены следующие правила: URI и URI-Reference; из [RFC4288]: имя-типа и имя-подтипа; из [W3C.REC-html401-19991224]: MediaDesc; из [RFC5646]: Language-Tag; и из [RFC5987], ext-value и parmname.

 

3. Ссылки

В этой спецификации ссылка представляет собой типизированное соединение между двумя ресурсами, которые идентифицируются интернационализированными идентификаторами ресурсов (IRI) [RFC3987], и состоит из:

• контекст IRI,
• тип отношения ссылки (раздел 4),
• целевой IRI, и
• необязательно, целевые атрибуты.

Ссылку можно рассматривать как оператор в форме «{context IRI — контекст IRI} имеет ресурс {relation type — тип отношения} в {target IRI — цель IRI}, который имеет {target attributes — атрибуты цели}».

Обратите внимание, что в общем случае IRI контекста также будет URI [RFC3986], поскольку многие протоколы (например, HTTP) не поддерживают разыменование IRI. Аналогично, целевой IRI будет преобразован в URI (см. [RFC3987], раздел 3.1) в сериализациях, которые не поддерживают IRI (например, заголовок Link).

Данная спецификация не накладывает ограничений на количество ссылок; может быть несколько ссылок на конкретный IRI и от него, а также несколько ссылок разных типов между двумя заданными IRI. Аналогично, относительное упорядочение ссылок в любой конкретной сериализации или между сериализациями (например, заголовок ссылки и ссылки в контенте) не определено или не имеет существенного значения в этой спецификации; приложения, которые желают считать заказ существенным, могут сделать это.

Атрибуты цели — это набор пар ключ / значение, которые описывают ссылку или ее цель; например, подсказка типа носителя. Эта спецификация не пытается координировать их имена или использование, но предоставляет общие целевые атрибуты для использования в заголовке HTTP ссылки.

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

 

4. Типы отношений ссылок

В простейшем случае тип отношения ссылки определяет семантику ссылки. Например, ссылка с типом отношения «авторское право» указывает, что ресурс, идентифицированный целевым IRI, является заявлением условий авторского права, применяемых к текущему контекстному IRI.

Типы связей могут также использоваться для указания того, что целевой ресурс имеет определенные атрибуты или демонстрирует определенные поведения; например, ссылка «сервис» подразумевает, что идентифицированный ресурс является частью определенного протокола (в данном случае, описания сервиса).

Типы отношений не следует путать с типами носителей [RFC4288]; они не определяют формат представления, которое получается, когда ссылка разыменовывается. Скорее, они только описывают, как текущий контекст связан с другим ресурсом.

Типы отношений НЕ ДОЛЖНЫ выводить какую-либо дополнительную семантику, основанную на наличии или отсутствии другого типа отношения ссылки или его собственной мощности возникновения. Исключением является комбинация зарегистрированных типов отношений «альтернативный» и «таблица стилей», которая по историческим причинам имеет особое значение в HTML4.

Существует два вида типов отношений: зарегистрированные и добавочные.

 

4.1. Типы зарегистрированных отношений

Четко определенные типы отношений могут быть зарегистрированы в качестве токенов для удобства и / или содействия повторному использованию другими приложениями. Данная спецификация устанавливает реестр IANA таких типов отношений; см. раздел 6.2.

Имена зарегистрированных типов отношений ДОЛЖНЫ соответствовать правилу reg-rel-type и ДОЛЖНЫ сравниваться посимвольно без учета регистра. Они ДОЛЖНЫ соответствовать специфике типа отношений; то есть, если семантика очень специфична для конкретного приложения, имя должно отражать это, так что более общие имена доступны для менее специфического использования.

Зарегистрированные типы отношений НЕ ДОЛЖНЫ ограничивать тип мультимедиа контекста IRI и НЕ ДОЛЖНЫ ограничивать доступные типы мультимедиа представления целевого IRI. Однако они могут указывать поведение и свойства целевого ресурса (например, допустимые методы HTTP, типы медиа запросов и ответов, которые должны поддерживаться).

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

Для этого данные приложения для каждой записи могут быть добавлены в реестр типов отношений связей, зарегистрировав их в реестре данных приложений отношений связей (раздел 6.3).

 

4.2. Типы отношений расширения

Приложения, которые не желают регистрировать тип отношения, могут использовать тип отношения расширения, который является URI [RFC3986], который уникально идентифицирует тип отношения. Хотя URI может указывать на ресурс, который содержит определение семантики типа отношения, клиенты НЕ ДОЛЖНЫ автоматически получать доступ к этому ресурсу, чтобы избежать перегрузки своего сервера.

Когда сравниваются типы отношений расширения, они ДОЛЖНЫ сравниваться как строки (после преобразования в URI, если они сериализованы в другом формате, таком как Curie [W3C.CR-curie-20090116]), с учетом регистра символов, символ за символом. Из-за этого все нижеуказанные URI ДОЛЖНЫ использоваться для отношений расширения.

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

 

5. Поле заголовка ссылки

Поле заголовка объекта ссылки обеспечивает возможность сериализации одной или нескольких ссылок в заголовках HTTP. Он семантически эквивалентен элементу <LINK> в HTML, а также элементу уровня atom: link в Atom [RFC4287].

 

5.1. Целевой IRI

Каждое значение ссылки передает один целевой IRI в качестве URI-ссылки (после преобразования в один, если необходимо, см. [RFC3987], раздел 3.1) внутри угловых скобок («<>»). Если URI-ссылка является относительной, синтаксические анализаторы ДОЛЖНЫ разрешить ее в соответствии с [RFC3986], раздел 5. Обратите внимание, что любой базовый IRI из содержимого сообщения не применяется.

 

5.2. Контекстный IRI

По умолчанию контекст ссылки, передаваемой в поле заголовка ссылки, является IRI запрашиваемого ресурса.

Если параметр привязки присутствует, он переопределяет его с помощью другого URI, например фрагмента этого ресурса, или третьего ресурса (т. е. Когда значение привязки является абсолютным URI). Если значение параметра привязки является относительным URI, синтаксические анализаторы ДОЛЖНЫ разрешить его в соответствии с [RFC3986], раздел 5. Обратите внимание, что любой базовый URI из содержимого тела не применяется.

Потребляющие реализации могут игнорировать ссылки с параметром привязки. Например, используемое приложение может не позволить назначить контекстную IRI другому ресурсу. В таких случаях вся ссылка должна игнорироваться; реализации-исполнители НЕ ДОЛЖНЫ обрабатывать ссылку без применения привязки.

Обратите внимание, что в зависимости от кода состояния HTTP и заголовков ответа IRI контекста может быть «анонимным» (то есть IRI контекста недоступен). Например, это относится к ответу 404 на запрос GET.

 

5.3. Тип отношений

Тип отношения ссылки передается в значении параметра «rel». Параметр «rel» НЕ ДОЛЖЕН появляться более одного раза в данном значении ссылки; вхождения после первого ДОЛЖНЫ игнорироваться парсерами.

Параметр «rev» использовался в прошлом, чтобы указать, что семантика отношения находится в обратном направлении. То есть ссылка от А к В с REL = «X» выражает то же отношение, что и ссылка от В к А с REV = «X». «rev» не рекомендуется в данной спецификации, потому что он часто смущает авторов и читателей; в большинстве случаев использование отдельного типа отношения является предпочтительным.

Обратите внимание, что типы отношений расширения ОБЯЗАНЫ быть абсолютными URI в заголовках ссылок и ДОЛЖНЫ быть заключены в кавычки, если они содержат точку с запятой («;») или запятую («,») (поскольку эти символы используются в качестве разделителей в самом заголовке).

 

5.4. Целевые атрибуты

«Hreflang», «media», «title», «title *», «type» и любые параметры ссылки linkextension считаются целевыми атрибутами для ссылки.

Параметр «hreflang», если он присутствует, является подсказкой, указывающей, каким должен быть язык результата разыменования ссылки. Обратите внимание, что это только подсказка; например, он не переопределяет заголовок Content-Language HTTP-ответа, полученного путем фактического перехода по ссылке. Несколько параметров «hreflang» в одном значении ссылки указывают, что из указанного ресурса доступно несколько языков.

Параметр «media», если он присутствует, используется для указания намеченного целевого носителя или носителя для информации о стиле (см. [W3C.REC-html401-19991224], раздел 6.13). Обратите внимание, что это может быть обновлено в [W3C.CR-css3-mediaqueries-20090915]). Его значение ДОЛЖНО быть заключено в кавычки, если оно содержит точку с запятой («;») или запятую («,»), и НЕ ДОЛЖНО быть более одного параметра «media» в значении ссылки.

Параметр «title», если он присутствует, используется для обозначения места назначения ссылки, так что его можно использовать в качестве удобочитаемого идентификатора (например, пункта меню) на языке, указанном в заголовке Content-Language (если имеется). ). Параметр title не должен появляться более одного раза в данном значении ссылки; вхождения после первого ДОЛЖНЫ игнорироваться парсерами.

Параметр «title *» может быть использован для кодирования этой метки в другом наборе символов и / или содержать информацию о языке согласно [RFC5987]. Параметр «title *» НЕ ДОЛЖЕН появляться более одного раза в данном значении ссылки; вхождения после первого ДОЛЖНЫ игнорироваться парсерами. Если параметр не содержит информацию о языке, его язык указывается в заголовке Content-Language (если имеется).

Если оба параметра «title» и «title *» появляются в значении ссылки, процессоры ДОЛЖНЫ использовать значение параметра «title *».

Параметр «type», если он присутствует, является подсказкой, указывающей, каким должен быть тип носителя в результате разыменования ссылки. Обратите внимание, что это только подсказка; например, он не переопределяет заголовок Content-Type HTTP-ответа, полученного путем фактического перехода по ссылке. НЕ ДОЛЖНО быть более одного параметра типа в значении ссылки.

 

5.5. Примеры

Например:

Link: <http://example.com/TheBook/chapter2>; rel=»previous»; title=»previous chapter»

указывает, что «chapter2» предшествует этому ресурсу в логическом пути навигации.

Так же,

Link: </>; rel=»http://example.net/foo»

указывает, что корневой ресурс («/») связан с этим ресурсом с типом отношения расширения «http://example.net/foo».

В приведенном ниже примере показан пример заголовка Link, кодирующего несколько ссылок, а также использование кодирования RFC 2231 для кодирования как символов не-ASCII, так и информации о языке.

Link: </TheBook/chapter2>; rel=»previous»; title*=UTF-8’de’letztes%20Kapitel, </TheBook/chapter4>; rel=»next»; title*=UTF-8’de’n%c3%a4chstes%20Kapitel

Здесь обе ссылки имеют заголовки, закодированные в UTF-8, используют немецкий язык («de»), а вторая ссылка содержит кодовую точку Unicode U + 00E4 («LATIN SMALL LETTER A WITH DIAERESIS»).

Обратите внимание, что значения ссылок могут передавать несколько ссылок между одним и тем же целевым и контекстным IRI; например:

Link: <http://example.org/>; rel=»start http://example.net/relation/other»

Здесь ссылка на «http://example.org/» имеет зарегистрированный тип отношения «start» и тип отношения расширения «http://example.net/relation/other».

 

6. Соображения IANA

6.1. Ссылка HTTP Заголовок Регистрация

Эта спецификация обновляет запись реестра «Заголовок сообщения» для «Link» в HTTP [RFC3864] для ссылки на этот документ.

Поле заголовка: Link
Применимый протокол: http
Статус: стандарт
Автор / контролер изменений: IETF (iesg@ietf.org) Целевая группа по инженерным разработкам в Интернете
Спецификационный документ (ы): [RFC5988]

6.2. Реестр типов отношений ссылок

Эта спецификация устанавливает реестр типов отношений ссылок и обновляет Atom [RFC4287], чтобы ссылаться на него вместо «Реестра отношений ссылок».

Базовые данные реестра (например, файл XML) должны включать текст упрощенной лицензии BSD, как описано в Разделе 4.e Правового положения о доверительном управлении (<http://trustee.ietf.org/license-info>).

6.2.1. Регистрация новых типов отношений ссылок

Типы отношений регистрируются по рекомендации назначенного эксперта (назначенного IESG или его делегатом) с требуемой спецификацией (с использованием терминологии из [RFC5226]).

Требования к зарегистрированным типам отношений описаны в разделе 4.1.

Запросы на регистрацию состоят из заполненного шаблона регистрации, приведенного ниже, обычно публикуемого в RFC или в открытом стандарте (в смысле, описанном в [RFC2026], раздел 7). Однако, чтобы разрешить распределение значений до публикации, назначенный эксперт может одобрить регистрацию, как только они убедятся, что спецификация будет опубликована.

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

Шаблон регистрации:

• Имя отношения:
• Описание:
• Ссылка:
• Примечания: [необязательно]
• Данные приложения: [необязательно]

Запросы на регистрацию следует отправлять в список рассылки link-relations@ietf.org, четко помеченный в строке темы (например, «НОВОЕ ОТНОШЕНИЕ — пример» для регистрации «примерного» типа отношений).

В течение максимум 14 дней с момента запроса назначенный эксперт (ы) утвердит или отклонит запрос на регистрацию, сообщив это решение списку проверки и IANA. Отказы должны включать объяснение и, если применимо, предложения относительно того, как сделать запрос успешным.

Решения (или их отсутствие), принятые назначенным экспертом, могут быть сначала обжалованы директорам областей применения (можно связаться по адресу электронной почты app-ads@tools.ietf.org или напрямую, посмотрев их адреса электронной почты на http: //www.iesg. org / website) и, если заявитель не удовлетворен ответом, на полный IESG (используя список рассылки iesg@iesg.org).

IANA должна принимать обновления реестра только от назначенного эксперта (-ов) и направлять все запросы на регистрацию в список рассылки проверки.

 

6.2.2. Начальное содержимое реестра

Первоначальное содержимое реестра Link Relation Type:

o Имя отношения: alternate — альтернативный
o Описание: обозначает замену контекста ссылки.
o Ссылка: [W3C.REC-html401-19991224]

o Имя отношения: appendix — приложение
o Описание: относится к приложению.
o Ссылка: [W3C.REC-html401-19991224]

o Имя отношения: bookmark — закладка
o Описание: относится к закладке или точке входа.
o Ссылка: [W3C.REC-html401-19991224]

o Имя отношения: chapter — глава
o Описание: относится к главе в коллекции ресурсов.
o Ссылка: [W3C.REC-html401-19991224]

o Имя отношения: contents — содержание
o Описание: относится к оглавлению.
o Ссылка: [W3C.REC-html401-19991224]

o Имя отношения: copyright — авторское право
o Описание: относится к заявлению об авторском праве, которое применяется к контексту ссылки.
o Ссылка: [W3C.REC-html401-19991224]

o Имя отношения: current — текущее
o Описание: относится к ресурсу, содержащему самые последние элементы в коллекции ресурсов.
o Ссылка: [RFC5005]

o Имя отношения: describedby — описано
o Описание: относится к ресурсу, предоставляющему информацию о контексте ссылки.
o Документация: <http://www.w3.org/TR/powder-dr/#assoc-linking>

o Имя отношения: edit — изменить
o Описание: относится к ресурсу, который можно использовать для редактирования контекста ссылки.
o Ссылка: [RFC5023]

o Имя отношения: edit-media
o Описание: относится к ресурсу, который можно использовать для редактирования мультимедиа, связанного с контекстом ссылки.
o Ссылка: [RFC5023]

o Имя отношения: enclosure — корпус
o Описание: Идентифицирует связанный ресурс, который потенциально велик и может потребовать специальной обработки.
o Ссылка: [RFC4287]

o Имя отношения: first — первое
o Описание: IRI, который относится к самому дальнему предшествующему ресурсу в ряду ресурсов.
o Ссылка: [RFC5988]
o Примечания: эта регистрация типа отношения не указывает на ссылку. Первоначально запрошено Марком Ноттингемом в декабре 2004 года.

o Отношение Имя: glossary — глоссарий
o Описание: Относится к глоссарию терминов.
o Ссылка: [W3C.REC-html401-19991224]

o Имя отношения: help — помощь
o Описание: относится к ресурсу, предлагающему помощь (дополнительная информация, ссылки на другие источники информации и т. д.)
o Ссылка: [W3C.REC-html401-19991224]

o Имя отношения: hub — хаб
o Описание: относится к концентратору, который позволяет регистрироваться для уведомления об обновлениях контекста.
o Ссылка: <http://pubsubhubbub.googlecode.com/> <http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html>
o Примечания: этот тип отношения был запрошен Бреттом Слаткиным.

o Имя отношения: index — индекс
o Описание: относится к индексу.
o Ссылка: [W3C.REC-html401-19991224]

o Имя отношения: last — последнее
o Описание: IRI, который относится к самому дальнему следующему ресурсу в ряду ресурсов.
o Ссылка: [RFC5988]
o Примечания: эта регистрация типа отношения не указывает на ссылку. Первоначально запрошено Марком Ноттингемом в декабре 2004 года.

o Имя отношения: latest-version — последняя версия
o Описание: указывает на ресурс, содержащий самую последнюю (например, текущую) версию контекста.
o Ссылка: [RFC5829]

o Имя отношения: license — лицензия
o Описание: относится к лицензии, связанной с контекстом ссылки.
o Ссылка: [RFC4946]

o Имя отношения: next — следующее
o Описание: относится к следующему ресурсу в упорядоченной серии ресурсов.
o Ссылка: [W3C.REC-html401-19991224]

o Имя отношения: next-archive — следующий архив
o Описание: относится к непосредственно следующему архивному ресурсу.
o Ссылка: [RFC5005]

o Имя отношения: payment — оплата
o Описание: указывает ресурс, на который принимается оплата.
o Ссылка: [RFC5988]
o Примечания: эта регистрация типа отношения не указывает на ссылку. По просьбе Джошуа Кинберга и Роберта Сайра. Он предназначен в качестве общего способа облегчения платежных действий, и, таким образом, в данной спецификации не делается никаких предположений о типе платежа или протоколе транзакции. Примеры могут включать веб-страницу, где принимаются пожертвования или где товары и услуги доступны для покупки. rel = «payment» не предназначена для запуска автоматической транзакции. В документах Atom элемент ссылки с атрибутом rel = «payment» может существовать на уровне канала / канала и / или уровня элемента / записи. Например, ссылка rel = «payment» на уровне канала / канала может указывать на URI «tip jar», тогда как запись / элемент, содержащий рецензию на книгу, может включать ссылку rel = «payment», которая указывает на местоположение, где Книга может быть куплена через интернет-магазин.

o Имя отношения: prev — предыдущий
o Описание: относится к предыдущему ресурсу в упорядоченной серии ресурсов. Синоним «предыдущий».
o Ссылка: [W3C.REC-html401-19991224]

o Имя отношения: predecessor-version — предшественник-версия
o Описание: указывает на ресурс, содержащий предыдущую версию в истории версий.
o Ссылка: [RFC5829]

o Имя отношения: previous — предыдущая
o Описание: относится к предыдущему ресурсу в упорядоченной серии ресурсов. Синоним слова «пред».
o Ссылка: [W3C.REC-html401-19991224]

o Имя отношения: prev-archive — предыдущий архив
o Описание: относится к непосредственно предшествующему архивному ресурсу.
o Ссылка: [RFC5005]

o Имя отношения: related — связано
o Описание: идентифицирует связанный ресурс.
o Ссылка: [RFC4287]

o Имя отношения: replies — ответы
o Описание: Определяет ресурс, который является ответом на контекст ссылки.
o Ссылка: [RFC4685]

o Имя отношения: section — раздел
o Описание: относится к разделу в наборе ресурсов.
o Ссылка: [W3C.REC-html401-19991224]

o Отношение Имя: self — Я
o Описание: передает идентификатор для контекста ссылки.
o Ссылка: [RFC4287]

o Имя отношения: service — услуга
o Описание: указывает URI, который можно использовать для получения служебного документа.
o Ссылка: [RFC5023]
o Примечания. При использовании в документе Atom этот тип отношения по умолчанию определяет служебные документы протокола публикации Atom. Запрошено Джеймсом Снеллом.

o Имя отношения: start — начало
o Описание: относится к первому ресурсу в наборе ресурсов.
o Ссылка: [W3C.REC-html401-19991224]

o Имя отношения: stylesheet — таблица стилей
o Описание: относится к внешней таблице стилей.
o Ссылка: [W3C.REC-html401-19991224]

o Имя отношения: subsection — подраздел
o Описание: относится к ресурсу, служащему подразделом в наборе ресурсов.
o Ссылка: [W3C.REC-html401-19991224]

o Имя отношения: successor-version — преемник-версия
o Описание: указывает на ресурс, содержащий версию-преемника в истории версий.
o Ссылка: [RFC5829]

o Имя отношения: up — вверх
o Описание: относится к родительскому документу в иерархии документов.
o Ссылка: [RFC5988]
o Примечания: эта регистрация типа отношения не указывает на ссылку. Запрошено Ноем Слейтером.

o Имя отношения: version-history — версия-история
o Описание: указывает на ресурс, содержащий историю версий для контекста.
o Ссылка: [RFC5829]

o Имя отношения: via — через
o Описание: Определяет ресурс, который является источником информации в контексте ссылки.
o Ссылка: [RFC4287]

o Имя отношения: working-copy — рабочая копия
o Описание: указывает на рабочую копию для этого ресурса.
o Ссылка: [RFC5829]

o Имя отношения: working-copy-of — рабочая копия
o Описание: указывает на версионный ресурс, из которого была получена эта рабочая копия.
o Ссылка: [RFC5829]

 

6.3. Реестр данных приложений связи ссылок

Эта спецификация также устанавливает реестр полей Application Relation Link, что позволяет расширять записи в реестре Link Relation Type специфичными для приложения данными (далее «данные приложения»), характерными для всех экземпляров данного типа связи link.

Данные заявки регистрируются по рекомендации назначенного эксперта (назначенного IESG или его делегатом) с требуемой спецификацией (с использованием терминологии из [RFC5226]).

Регистрационные запросы состоят из заполненного регистрационного шаблона ниже:

o Имя приложения:
o Описание:
o Значение по умолчанию:
o Примечания: [необязательно]

Описание ДОЛЖНО идентифицировать пространство значений данных приложения. Значение по умолчанию ДОЛЖНО соответствовать записям, к которым данные приложения не применяются.

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

Запросы на регистрацию следует отправлять в список рассылки link-relations@ietf.org, четко обозначенный в строке темы (например, «Данные приложения« NEW APP DATA — пример »для регистрации» »).

В течение не более 14 дней с момента запроса назначенный эксперт утвердит или отклонит запрос на регистрацию, сообщив это решение списку проверки. Отказы должны включать объяснение и, если применимо, предложения относительно того, как сделать запрос успешным. Запросы на регистрацию, которые не определены в течение периода, превышающего 21 день, могут быть доведены до сведения IESG (с помощью списка рассылки iesg@iesg.org) для разрешения.

Когда запрос на регистрацию будет успешным, назначенный эксперт направит его в IANA для публикации. IANA должна принимать обновления реестра только от назначенного эксперта (-ов) и направлять все запросы на регистрацию в список рассылки проверки.

7. Вопросы безопасности

Содержимое поля заголовка Link не является безопасным, частным или гарантированным целостностью, и при его использовании следует соблюдать осторожность. Использование безопасности транспортного уровня (TLS) с HTTP ([RFC2818] и [RFC2817]) в настоящее время является единственным сквозным способом обеспечения такой защиты.

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

Поле заголовка объекта Link активно использует IRI и URI. См. [RFC3987] для соображений безопасности, касающихся IRI. См. [RFC3986] для соображений безопасности, касающихся URI. См. [RFC2616] для соображений безопасности, касающихся заголовков HTTP.

8. Вопросы интернационализации

Целевые IRI, возможно, придется преобразовать в URI, чтобы выразить их в сериализации, не поддерживающей IRI. Это включает в себя HTTP-заголовок Link.

Точно так же параметр привязки заголовка Link не поддерживает IRI, и поэтому IRI должны быть преобразованы в URI перед их включением.

Типы отношений определяются как URI, а не IRI, чтобы помочь в их сравнении. Не ожидается, что они будут отображаться для конечных пользователей.

9. Ссылки

9.1. Нормативные ссылки

[RFC2026] Bradner, S., «The Internet Standards Process — Revision 3», BCP 9, RFC 2026, October 1996.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, «Hypertext Transfer Protocol — HTTP/1.1», RFC 2616, June 1999.

[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, «Registration Procedures for Message Header Fields», BCP 90, RFC 3864, September 2004.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, January 2005.

[RFC3987] Duerst, M. and M. Suignard, «Internationalized Resource Identifiers (IRIs)», RFC 3987, January 2005.

[RFC4288] Freed, N. and J. Klensin, «Media Type Specifications and Registration Procedures», BCP 13, RFC 4288, December 2005.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[RFC5646] Phillips, A. and M. Davis, «Tags for Identifying Languages», BCP 47, RFC 5646, September 2009.

[RFC5987] Reschke, J., «Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters», RFC 5987, August 2010.

9.2. Информационные ссылки

[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. Berners-Lee, «Hypertext Transfer Protocol — HTTP/1.1», RFC 2068, January 1997.

[RFC2817] Khare, R. and S. Lawrence, «Upgrading to TLS Within HTTP/1.1», RFC 2817, May 2000.

[RFC2818] Rescorla, E., «HTTP Over TLS», RFC 2818, May 2000.

[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., «The Atom Syndication Format», RFC 4287, December 2005.

[RFC4685] Snell, J., «Atom Threading Extensions», RFC 4685, September 2006.

[RFC4946] Snell, J., «Atom License Extension», RFC 4946, July 2007.

[RFC5005] Nottingham, M., «Feed Paging and Archiving», RFC 5005, September 2007.

[RFC5023] Gregorio, J. and B. de hOra, «The Atom Publishing Protocol», RFC 5023, October 2007.

[RFC5829] Brown, A., Clemm, G., and J. Reschke, «Link Relation Types for Simple Version Navigation between Web Resources», RFC 5829, April 2010.

[W3C.CR-css3-mediaqueries-20090915] van Kesteren, A., Glazman, D., Lie, H., and T. Celik, «Media Queries», W3C Candidate Recommendation CR-css3-mediaqueries-20090915, September 2009, <http://www.w3.org/TR/2009/CR-css3-mediaqueries-20090915/>.
Latest version available at <http://www.w3.org/TR/css3-mediaqueries/>.

[W3C.CR-curie-20090116] Birbeck, M. and S. McCarron, «CURIE Syntax 1.0», W3C Candidate Recommendation CR-curie-20090116, January 2009,
<http://www.w3.org/TR/2009/CR-curie-20090116>. Latest version available at <http://www.w3.org/TR/curie>.

[W3C.REC-html401-19991224] Le Hors, A., Raggett, D., and I. Jacobs, «HTML 4.01 Specification», W3C Recommendation REC-html401-19991224, December 1999, <http://www.w3.org/TR/1999/REC-html401-19991224>. Latest version available at <http://www.w3.org/TR/html401>.

[W3C.REC-rdfa-syntax-20081014] Adida, B., Birbeck, M., McCarron, S., and S. Pemberton, «RDFa in XHTML: Syntax and Processing», W3C Recommendation REC-rdfa-syntax-20081014, October 2008, <http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014>.
Latest version available at <http://www.w3.org/TR/rdfa-syntax>.

[W3C.REC-xhtml-basic-20080729] Baker, M., Ishikawa, M., Stark, P., Matsui, S., Wugofski, T., and T. Yamakami, «XHTML[TM] Basic 1.1», W3C Recommendation REC-xhtml-basic-20080729, July 2008, <http://www.w3.org/TR/2008/REC-xhtml-basic-20080729>. Latest version available at <http://www.w3.org/TR/xhtml-basic>.

Приложение A. Примечания по использованию заголовка ссылки в формате HTML4

HTML мотивировал оригинальный синтаксис заголовка Link, и многие решения по дизайну в этом документе основаны на желании оставаться совместимыми с этими видами использования.

В HTML4 элемент link может быть сопоставлен со ссылками, как указано здесь, с помощью атрибута «href» для целевого URI и «rel» для передачи типа отношения, как в заголовке Link. Контекст ссылки — это URI, связанный со всем HTML-документом.

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

• o как абсолютные URI,
• o использование универсального URI-атрибута «profile» для всего документа в качестве префикса для типов отношений или
• o использование соглашения RDFa [W3C.REC-rdfa-syntax-20081014] о сопоставлении префиксов токенов с URI (аналогично пространствам имен XML) (обратите внимание, что RDFa определен только для работы в XHTML [W3C.REC-xhtml- basic-20080729], но иногда используется в HTML4).

Поэтому отдельным приложениям компоновки необходимо будет определить, как их ссылки расширения должны быть сериализованы в HTML4.

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

HTML4 также определяет несколько атрибутов ссылок, которые явно не определены в заголовке ссылки. Эти атрибуты могут быть сериализованы как расширения ссылок для поддержания точности.

Наконец, спецификация HTML4 придает особое значение, когда типы отношений «alternate» и «stylesheet» совпадают в одной и той же ссылке. Такие ссылки должны быть сериализованы в заголовке ссылки с использованием единого списка типов отношений (например, rel = «альтернативная таблица стилей»), чтобы сохранить эту связь.

Приложение B. Примечания по использованию заголовка ссылки в формате Atom

Atom передает ссылки в элементе atom: link с атрибутом «href», указывающим целевой IRI, и атрибутом «rel», содержащим тип отношения. Контекст ссылки является либо IRI канала, либо идентификатором записи, в зависимости от того, где он появляется; Как правило, ссылки на уровне каналов являются очевидными кандидатами на передачу в качестве заголовка ссылки.

При сериализации atom: link в заголовок Link необходимо преобразовать целевые IRI (если они используются) в URI.

Atom определяет типы отношений расширения в терминах IRI. Эта спецификация переопределяет их как URI, чтобы упростить и уменьшить ошибки при их сравнении.

Atom позволяет сериализовать зарегистрированные типы отношений ссылки как абсолютные URI. Такие типы отношений ДОЛЖНЫ быть преобразованы в соответствующую зарегистрированную форму (например, «http://www.iana.org/assignments/relation/self» в «self»), чтобы они не были ошибочно приняты за типы отношений расширения.

Кроме того, типы отношений ссылок Atom всегда сравниваются с учетом регистра; следовательно, зарегистрированные типы отношений ссылки ДОЛЖНЫ быть преобразованы в их зарегистрированную форму (обычно в нижний регистр) при сериализации в документе Atom.

Также обратите внимание, что хотя заголовок Link позволяет сериализовать несколько отношений в одной ссылке, atom: link этого не делает. В этом случае одно значение ссылки может отображаться на несколько элементов atom: link.

Как и в HTML, atom: link определяет некоторые атрибуты, которые явно не отражаются в синтаксисе заголовка Link, но их также можно использовать как расширения ссылок для поддержания точности.

Приложение C. Благодарности

Эта спецификация поднимает идею и определение заголовка Link из RFC 2068; Авторство этого документа полностью принадлежит авторам и авторам. Сами регистрации типа связи ссылок получены из нескольких документов; см. соответствующие ссылки.

Автор хотел бы поблагодарить многих людей, которые прокомментировали, поддержали и дали обратную связь к этой спецификации, особенно включая Фрэнка Эллермана, Роя Филдинга, Эрана Хаммера-Лахава и Джулиана Решке.

Адрес автора

Mark Nottingham
EMail: mnot@mnot.net
URI: http://www.mnot.net/