| draft-nottingham-http-link-header-08.txt |  | draft-nottingham-http-link-header-09.txt |
--- | --- | --- | --- | ---
| Network Working Group M. Nottingham |  | Network Working Group M. Nottingham |
| Updates: 4287 (if approved) |  | Updates: 4287 (if approved) |
| Intended status: Standards Track |  | Intended status: Standards Track |
| Expires: September 2, 2010 |  | Expires: October 4, 2010 |
| Web Linking |  | Web Linking |
| draft-nottingham-http-link-header-08 |  | draft-nottingham-http-link-header-09 |
| Abstract |  | Abstract |
| This document specifies relation types for Web links, and defines a |  | This document specifies relation types for Web links, and defines a |
| registry for them. It also defines the use of such links in HTTP |  | registry for them. It also defines the use of such links in HTTP |
| headers with the Link header-field. |  | headers with the Link header-field. |
| Status of this Memo |  | Status of this Memo |
| This Internet-Draft is submitted to IETF in full conformance with the |  | This Internet-Draft is submitted in full conformance with the |
| provisions of BCP 78 and BCP 79. |  | provisions of BCP 78 and BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF), its areas, and its working groups. Note that |  | Task Force (IETF). Note that other groups may also distribute |
| other groups may also distribute working documents as Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts. |  | Drafts is at http://datatracker.ietf.org/drafts/current/. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| The list of current Internet-Drafts can be accessed at |  | This Internet-Draft will expire on October 4, 2010. |
| http://www.ietf.org/ietf/1id-abstracts.txt. |  |  |
| The list of Internet-Draft Shadow Directories can be accessed at |  |  |
| http://www.ietf.org/shadow.html. |  |  |
| This Internet-Draft will expire on September 2, 2010. |  |  |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2010 IETF Trust and the persons identified as the |  | Copyright (c) 2010 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| carefully, as they describe your rights and restrictions with respect |  | carefully, as they describe your rights and restrictions with respect |
| to this document. Code Components extracted from this document must |  | to this document. Code Components extracted from this document must |
| include Simplified BSD License text as described in Section 4.e of |  | include Simplified BSD License text as described in Section 4.e of |
| the Trust Legal Provisions and are provided without warranty as |  | the Trust Legal Provisions and are provided without warranty as |
| described in the BSD License. |  | described in the Simplified BSD License. |
| This document may contain material from IETF Documents or IETF |  | This document may contain material from IETF Documents or IETF |
| Contributions published or made publicly available before November |  | Contributions published or made publicly available before November |
| 10, 2008. The person(s) controlling the copyright in some of this |  | 10, 2008. The person(s) controlling the copyright in some of this |
| material may not have granted the IETF Trust the right to allow |  | material may not have granted the IETF Trust the right to allow |
| modifications of such material outside the IETF Standards Process. |  | modifications of such material outside the IETF Standards Process. |
| Without obtaining an adequate license from the person(s) controlling |  | Without obtaining an adequate license from the person(s) controlling |
| the copyright in such materials, this document may not be modified |  | the copyright in such materials, this document may not be modified |
| outside the IETF Standards Process, and derivative works of it may |  | outside the IETF Standards Process, and derivative works of it may |
| not be created outside the IETF Standards Process, except to format |  | not be created outside the IETF Standards Process, except to format |
| skipping to change at page 4, line 48 |  | skipping to change at page 3, line 48 |
| document are to be interpreted as described in BCP 14, [RFC2119], as |  | document are to be interpreted as described in BCP 14, [RFC2119], as |
| scoped to those conformance targets. |  | scoped to those conformance targets. |
| This document uses the Augmented Backus-Naur Form (ABNF) notation of |  | This document uses the Augmented Backus-Naur Form (ABNF) notation of |
| [RFC2616], and explicitly includes the following rules from it: |  | [RFC2616], and explicitly includes the following rules from it: |
| quoted-string, token, SP (space), LOALPHA, DIGIT. |  | quoted-string, token, SP (space), LOALPHA, DIGIT. |
| Additionally, the following rules are included from [RFC3986]: URI |  | Additionally, the following rules are included from [RFC3986]: URI |
| and URI-Reference; from [RFC4288]: type-name and subtype-name; from |  | and URI-Reference; from [RFC4288]: type-name and subtype-name; from |
| [W3C.REC-html401-19991224]: MediaDesc; from [RFC5646]: Language-Tag; |  | [W3C.REC-html401-19991224]: MediaDesc; from [RFC5646]: Language-Tag; |
| and from [I-D.reschke-rfc2231-in-http], ext-value. |  | and from [I-D.reschke-rfc2231-in-http], ext-value and parmname. |
| 3. Links |  | 3. Links |
| In this specification, a link is a typed connection between two |  | In this specification, a link is a typed connection between two |
| resources that are identified by IRIs [RFC3987], and is comprised of: |  | resources that are identified by IRIs [RFC3987], and is comprised of: |
| o A context IRI, and |  | o A context IRI, and |
| o a link relation type (Section 4), and |  | o a link relation type (Section 4), and |
| o a target IRI, and |  | o a target IRI, and |
| o optionally, target attributes. |  | o optionally, target attributes. |
| skipping to change at page 6, line 37 |  | skipping to change at page 5, line 37 |
| Registered relation type names MUST conform to the reg-relation-type |  | Registered relation type names MUST conform to the reg-relation-type |
| rule, and MUST be compared character-by-character in a case- |  | rule, and MUST be compared character-by-character in a case- |
| insensitive fashion. They SHOULD be appropriate to the specificity |  | insensitive fashion. They SHOULD be appropriate to the specificity |
| of the relation type; i.e., if the semantics are highly specific to a |  | of the relation type; i.e., if the semantics are highly specific to a |
| particular application, the name should reflect that, so that more |  | particular application, the name should reflect that, so that more |
| general names are available for less specific use. |  | general names are available for less specific use. |
| Registered relation types MUST NOT constrain the media type of the |  | Registered relation types MUST NOT constrain the media type of the |
| context IRI, and MUST NOT constrain the available representation |  | context IRI, and MUST NOT constrain the available representation |
| media types of the target IRI. However, they MAY specify the |  | media types of the target IRI. However, they can specify the |
| behaviours and properties of the target resource (e.g., allowable |  | behaviours and properties of the target resource (e.g., allowable |
| HTTP methods, request and response media types which must be |  | HTTP methods, request and response media types which must be |
| supported). |  | supported). |
| Additionally, specific applications of linking may require additional |  | Additionally, specific applications of linking may require additional |
| data to be included in the registry. For example, Web browsers might |  | data to be included in the registry. For example, Web browsers might |
| want to know what kinds of links should be downloaded when they |  | want to know what kinds of links should be downloaded when they |
| archive a Web page; if this application-specific information is in |  | archive a Web page; if this application-specific information is in |
| the registry, new link relation types can control this behaviour |  | the registry, new link relation types can control this behaviour |
| without unnecessary coordination. |  | without unnecessary coordination. |
| To accommodate this, per-entry application data MAY be added to the |  | To accommodate this, per-entry application data can be added to the |
| Link Relation Type Registry, by registering it in the Link Relation |  | Link Relation Type Registry, by registering it in the Link Relation |
| Application Data Registry (Section 6.3). |  | Application Data Registry (Section 6.3). |
| 4.2. Extension Relation Types |  | 4.2. Extension Relation Types |
| Applications that don't wish to register a relation type may use an |  | Applications that don't wish to register a relation type can use an |
| extension relation type, which is a URI [RFC3986] that uniquely |  | extension relation type, which is a URI [RFC3986] that uniquely |
| identifies the relation type. Although the URI can point to a |  | identifies the relation type. Although the URI can point to a |
| resource that contains a definition of the semantics of the relation |  | resource that contains a definition of the semantics of the relation |
| type, clients SHOULD NOT automatically access that resource to avoid |  | type, clients SHOULD NOT automatically access that resource to avoid |
| overburdening its server. |  | overburdening its server. |
| When extension relation types are compared, they MUST be compared as |  | When extension relation types are compared, they MUST be compared as |
| strings (after converting to URIs if serialised in a different |  | strings (after converting to URIs if serialised in a different |
| format, such as a Curie [W3C.CR-curie-20090116]) in a case- |  | format, such as a Curie [W3C.CR-curie-20090116]) in a case- |
| insensitive fashion, character-by-character. Because of this, all- |  | insensitive fashion, character-by-character. Because of this, all- |
| skipping to change at page 8, line 16 |  | skipping to change at page 7, line 16 |
| link-value = "<" URI-Reference ">" *( ";" link-param ) |  | link-value = "<" URI-Reference ">" *( ";" link-param ) |
| link-param = ( ( "rel" "=" relation-types ) |  | link-param = ( ( "rel" "=" relation-types ) |
| | ( "anchor" "=" <"> URI-Reference <"> ) |  | | ( "anchor" "=" <"> URI-Reference <"> ) |
| | ( "rev" "=" relation-types ) |  | | ( "rev" "=" relation-types ) |
| | ( "hreflang" "=" Language-Tag ) |  | | ( "hreflang" "=" Language-Tag ) |
| | ( "media" "=" ( MediaDesc | <"> MediaDesc <"> ) ) |  | | ( "media" "=" ( MediaDesc | <"> MediaDesc <"> ) ) |
| | ( "title" "=" quoted-string ) |  | | ( "title" "=" quoted-string ) |
| | ( "title*" "=" ext-value ) |  | | ( "title*" "=" ext-value ) |
| | ( "type" "=" ( media-type | quoted-media-type ) ) |  | | ( "type" "=" ( media-type | quoted-media-type ) ) |
| | ( link-extension ) ) |  | | ( link-extension ) ) |
| link-extension = ( token [ "=" ( ptoken | quoted-string ) ] ) |  | link-extension = ( parmname [ "=" ( ptoken | quoted-string ) ] ) |
| | ( ext-name-star "=" ext-value ) |  | | ( ext-name-star "=" ext-value ) |
| ext-name-star = token "*" ; reserved for RFC2231-profiled |  | ext-name-star = parmname "*" ; reserved for RFC2231-profiled |
| ; extensions. Whitespace NOT |  | ; extensions. Whitespace NOT |
| ; allowed in between. |  | ; allowed in between. |
| ptoken = "!" | "#" | "$" | "%" | "&" | "'" | "(" |  | ptoken = 1*ptokenchar |
|  |  | ptokenchar = "!" | "#" | "$" | "%" | "&" | "'" | "(" |
| | ")" | "*" | "+" | "-" | "." | "/" | DIGIT |  | | ")" | "*" | "+" | "-" | "." | "/" | DIGIT |
| | ":" | "<" | "=" | ">" | "?" | "@" | ALPHA |  | | ":" | "<" | "=" | ">" | "?" | "@" | ALPHA |
| | "[" | "\" | "]" | "^" | "_" | "`" | "{" |  | | "[" | "]" | "^" | "_" | "`" | "{" | "|" |
| | "|" | "}" | "~" |  | | "}" | "~" |
| media-type = type-name "/" subtype-name |  | media-type = type-name "/" subtype-name |
| quoted-media-type = <"> media-type <"> |  | quoted-media-type = <"> media-type <"> |
| relation-types = relation-type | |  | relation-types = relation-type | |
| <"> relation-type *( 1*SP relation-type ) <"> |  | <"> relation-type *( 1*SP relation-type ) <"> |
| relation-type = reg-relation-type | ext-relation-type |  | relation-type = reg-relation-type | ext-relation-type |
| reg-relation-type = LOALPHA *( LOALPHA | DIGIT | "." | "-" ) |  | reg-relation-type = LOALPHA *( LOALPHA | DIGIT | "." | "-" ) |
| ext-relation-type = URI |  | ext-relation-type = URI |
| 5.1. Target IRI |  | 5.1. Target IRI |
| skipping to change at page 9, line 5 |  | skipping to change at page 8, line 6 |
| By default, the context of a link conveyed in the Link header field |  | By default, the context of a link conveyed in the Link header field |
| is the IRI of the requested resource. |  | is the IRI of the requested resource. |
| When present, the anchor parameter overrides this with another URI, |  | When present, the anchor parameter overrides this with another URI, |
| such as a fragment of this resource, or a third resource (i.e., when |  | such as a fragment of this resource, or a third resource (i.e., when |
| the anchor value is an absolute URI). If the anchor parameter's |  | the anchor value is an absolute URI). If the anchor parameter's |
| value is a relative URI, parsers MUST resolve it as per [RFC3986], |  | value is a relative URI, parsers MUST resolve it as per [RFC3986], |
| Section 5. Note that any base URI from the body's content is not |  | Section 5. Note that any base URI from the body's content is not |
| applied. |  | applied. |
| Consuming implementations may choose to ignore links with an anchor |  | Consuming implementations can choose to ignore links with an anchor |
| parameter. For example, the application in use may not allow the |  | parameter. For example, the application in use may not allow the |
| context IRI to be assigned to a different resource. In such cases, |  | context IRI to be assigned to a different resource. In such cases, |
| the entire link is to be ignored; consuming implementations MUST NOT |  | the entire link is to be ignored; consuming implementations MUST NOT |
| process the link without applying the anchor. |  | process the link without applying the anchor. |
| Note that depending on HTTP status code and response headers, the |  | Note that depending on HTTP status code and response headers, the |
| context IRI might be "anonymous" (i.e., no context IRI is available). |  | context IRI might be "anonymous" (i.e., no context IRI is available). |
| For instance, this is the case on a 404 response to a GET request. |  | For instance, this is the case on a 404 response to a GET request. |
| 5.3. Relation Type |  | 5.3. Relation Type |
| skipping to change at page 10, line 7 |  | skipping to change at page 9, line 9 |
| The "media" parameter, when present, is used to indicate intended |  | The "media" parameter, when present, is used to indicate intended |
| destination medium or media for style information (see |  | destination medium or media for style information (see |
| [W3C.REC-html401-19991224], Section 6.13). Note that this may be |  | [W3C.REC-html401-19991224], Section 6.13). Note that this may be |
| updated by [W3C.CR-css3-mediaqueries-20090915]). Its value MUST be |  | updated by [W3C.CR-css3-mediaqueries-20090915]). Its value MUST be |
| quoted if it contains a semicolon (";") or comma (","), and there |  | quoted if it contains a semicolon (";") or comma (","), and there |
| MUST NOT be more than one media parameter in a link-value. |  | MUST NOT be more than one media parameter in a link-value. |
| The "title" parameter, when present, is used to label the destination |  | The "title" parameter, when present, is used to label the destination |
| of a link such that it can be used as a human-readable identifier |  | of a link such that it can be used as a human-readable identifier |
| (e.g. a menu entry). The "title" parameter MUST NOT appear more than |  | (e.g. a menu entry) in the language indicated by the Content-Language |
|  |  | header (if present). The "title" parameter MUST NOT appear more than |
| once in a given link-value; occurrences after the first MUST be |  | once in a given link-value; occurrences after the first MUST be |
| ignored by parsers. |  | ignored by parsers. |
| The "title*" parameter MAY be used to encode this label in a |  | The "title*" parameter can be used to encode this label in a |
| different character set, and/or contain language information as per |  | different character set, and/or contain language information as per |
| [I-D.reschke-rfc2231-in-http]. The "title*" parameter MAY appear |  | [I-D.reschke-rfc2231-in-http]. The "title*" parameter MUST NOT |
| more than once in a given link-value, but each occurrence MUST |  | appear more than once in a given link-value; occurrences after the |
| indicate a different language; occurrences after the first for a |  | first MUST be ignored by parsers. If the parameter does not contain |
| given language MUST be ignored by parsers. |  | language information, its language is indicated by the Content- |
|  |  | Language header (when present). |
| When presenting links to users, agents SHOULD use the most |  | If both the "title" and "title*" parameters appear in a link-value, |
| appropriate "title*" value, according to user preferences. If an |  | processors SHOULD use the "title*" parameter's value. |
| appropriate "title*" value cannot be found, the "title" parameter's |  |  |
| value, if available, can be used. |  |  |
| The "type" parameter, when present, is a hint indicating what the |  | The "type" parameter, when present, is a hint indicating what the |
| media type of the result of dereferencing the link should be. Note |  | media type of the result of dereferencing the link should be. Note |
| that this is only a hint; for example, it does not override the |  | that this is only a hint; for example, it does not override the |
| Content-Type header of a HTTP response obtained by actually following |  | Content-Type header of a HTTP response obtained by actually following |
| the link. There MUST NOT be more than one type parameter in a link- |  | the link. There MUST NOT be more than one type parameter in a link- |
| value. |  | value. |
| 5.5. Examples |  | 5.5. Examples |
| skipping to change at page 11, line 14 |  | skipping to change at page 10, line 14 |
| Link: </TheBook/chapter2>; |  | Link: </TheBook/chapter2>; |
| rel="previous"; title*=UTF-8'de'letztes%20Kapitel, |  | rel="previous"; title*=UTF-8'de'letztes%20Kapitel, |
| </TheBook/chapter4>; |  | </TheBook/chapter4>; |
| rel="next"; title*=UTF-8'de'n%c3%a4chstes%20Kapitel |  | rel="next"; title*=UTF-8'de'n%c3%a4chstes%20Kapitel |
| Here, both links have titles encoded in UTF-8, use the German |  | Here, both links have titles encoded in UTF-8, use the German |
| language ("de"), and the second link contains the Unicode code point |  | language ("de"), and the second link contains the Unicode code point |
| U+00E4 ("LATIN SMALL LETTER A WITH DIAERESIS"). |  | U+00E4 ("LATIN SMALL LETTER A WITH DIAERESIS"). |
| Note that link-values may convey multiple links between the same |  | Note that link-values can convey multiple links between the same |
| target and context IRIs; for example: |  | target and context IRIs; for example: |
| Link: <http://example.org/>; |  | Link: <http://example.org/>; |
| rel="start http://example.net/relation/other" |  | rel="start http://example.net/relation/other" |
| Here, the link to "http://example.org/" has the registered relation |  | Here, the link to "http://example.org/" has the registered relation |
| type "start" and the extension relation type |  | type "start" and the extension relation type |
| "http://example.net/relation/other". |  | "http://example.net/relation/other". |
| 6. IANA Considerations |  | 6. IANA Considerations |
| skipping to change at page 12, line 48 |  | skipping to change at page 11, line 48 |
| either approve or deny the registration request, communicating this |  | either approve or deny the registration request, communicating this |
| decision to the review list. Denials should include an explanation |  | decision to the review list. Denials should include an explanation |
| and, if applicable, suggestions as to how to make the request |  | and, if applicable, suggestions as to how to make the request |
| successful. Registration requests that are undetermined for a period |  | successful. Registration requests that are undetermined for a period |
| longer than 21 days can be brought to the IESG's attention (using the |  | longer than 21 days can be brought to the IESG's attention (using the |
| iesg@iesg.org mailing list) for resolution. |  | iesg@iesg.org mailing list) for resolution. |
| When a registration request is successful, the Designated Expert(s) |  | When a registration request is successful, the Designated Expert(s) |
| will update the registry XML file (using the format described in |  | will update the registry XML file (using the format described in |
| Appendix A including the MIT license) and send it to the [TBD-2]@ |  | Appendix A including the MIT license) and send it to the [TBD-2]@ |
| ietf.org mailing list (which SHOULD NOT be centrally archived, and |  | ietf.org mailing list (which SHOULD NOT be centrally archived, so as |
| only accept posts from the Designated Expert(s)), so that |  | to avoid load issues from automated agents, and only accept posts |
| implementers interested in receiving a machine-readable registry can |  | from the Designated Expert(s)), so that implementers interested in |
| do so. Simultaneously, they will send a text (not XML) version of |  | receiving a machine-readable registry can do so. Simultaneously, |
| the registry to IANA for publication. |  | they will send a text (not XML) version of the registry to IANA for |
|  |  | publication. |
| IANA should only accept registry updates from the Designated |  | IANA should only accept registry updates from the Designated |
| Expert(s), and should direct all requests for registration to the |  | Expert(s), and should direct all requests for registration to the |
| review mailing list. |  | review mailing list. |
| 6.2.2. Initial Registry Contents |  | 6.2.2. Initial Registry Contents |
| The Link Relation Type registry's initial contents are: |  | The Link Relation Type registry's initial contents are: |
| o Relation Name: alternate |  | o Relation Name: alternate |
| skipping to change at page 18, line 16 |  | skipping to change at page 17, line 16 |
| possible). |  | possible). |
| Registration requests should be sent to the [TBD]@ietf.org mailing |  | Registration requests should be sent to the [TBD]@ietf.org mailing |
| list, marked clearly in the subject line (e.g,. "NEW APP DATA"). |  | list, marked clearly in the subject line (e.g,. "NEW APP DATA"). |
| Within at most 14 days of the request, the Designated Expert will |  | Within at most 14 days of the request, the Designated Expert will |
| either approve or deny the registration request, communicating this |  | either approve or deny the registration request, communicating this |
| decision to the review list. Denials should include an explanation |  | decision to the review list. Denials should include an explanation |
| and, if applicable, suggestions as to how to make the request |  | and, if applicable, suggestions as to how to make the request |
| successful. Registration requests that are undetermined for a period |  | successful. Registration requests that are undetermined for a period |
| longer than 21 days MAY be brought to the IESG's attention (using the |  | longer than 21 days can be brought to the IESG's attention (using the |
| iesg@iesg.org mailing list) for resolution. |  | iesg@iesg.org mailing list) for resolution. |
| When a registration request is successful, the Designated Expert will |  | When a registration request is successful, the Designated Expert will |
| forward it to IANA for publication. IANA should only accept registry |  | forward it to IANA for publication. IANA should only accept registry |
| updates from the Designated Expert(s), and should direct all requests |  | updates from the Designated Expert(s), and should direct all requests |
| for registration to the review mailing list. |  | for registration to the review mailing list. |
| 7. Security Considerations |  | 7. Security Considerations |
| The content of the Link header-field is not secure, private or |  | The content of the Link header-field is not secure, private or |
| skipping to change at page 19, line 12 |  | skipping to change at page 18, line 12 |
| comparison. It is not expected that they will be displayed to end |  | comparison. It is not expected that they will be displayed to end |
| users. |  | users. |
| 9. References |  | 9. References |
| 9.1. Normative References |  | 9.1. Normative References |
| [I-D.reschke-rfc2231-in-http] |  | [I-D.reschke-rfc2231-in-http] |
| Reschke, J., "Application of RFC 2231 Encoding to |  | Reschke, J., "Application of RFC 2231 Encoding to |
| Hypertext Transfer Protocol (HTTP) Header Fields", |  | Hypertext Transfer Protocol (HTTP) Header Fields", |
| draft-reschke-rfc2231-in-http-09 (work in progress), |  | draft-reschke-rfc2231-in-http-11 (work in progress), |
| February 2010. |  | March 2010. |
| [RFC2026] Bradner, S., "The Internet Standards Process -- Revision |  | [RFC2026] Bradner, S., "The Internet Standards Process -- Revision |
| 3", BCP 9, RFC 2026, October 1996. |  | 3", BCP 9, RFC 2026, October 1996. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |  | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
| Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |  | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
| skipping to change at page 24, line 21 |  | skipping to change at page 23, line 21 |
| Furthermore, Atom link relation types are always compared in a case- |  | Furthermore, Atom link relation types are always compared in a case- |
| sensitive fashion; therefore, registered link relation types SHOULD |  | sensitive fashion; therefore, registered link relation types SHOULD |
| be converted to their registered form (usually, lower case) when |  | be converted to their registered form (usually, lower case) when |
| serialised in an Atom document. |  | serialised in an Atom document. |
| Note also that while the Link header allows multiple relations to be |  | Note also that while the Link header allows multiple relations to be |
| serialised in a single link, atom:link does not. In this case, a |  | serialised in a single link, atom:link does not. In this case, a |
| single link-value may map to several atom:link elements. |  | single link-value may map to several atom:link elements. |
| As with HTML, atom:link defines some attributes that are not |  | As with HTML, atom:link defines some attributes that are not |
| explicitly mirrored in the Link header syntax, but they may also be |  | explicitly mirrored in the Link header syntax, but they can also be |
| used as link-extensions to maintain fidelity. |  | used as link-extensions to maintain fidelity. |
| Appendix D. Acknowledgements |  | Appendix D. Acknowledgements |
| This specification lifts the idea and definition for the Link header |  | This specification lifts the idea and definition for the Link header |
| from RFC2068; credit for it belongs entirely to the authors of and |  | from RFC2068; credit for it belongs entirely to the authors of and |
| contributors to that document. The link relation type registrations |  | contributors to that document. The link relation type registrations |
| themselves are sourced from several documents; see the applicable |  | themselves are sourced from several documents; see the applicable |
| references. |  | references. |
| The author would like to thank the many people who commented upon, |  | The author would like to thank the many people who commented upon, |
| encouraged and gave feedback to this specification, especially |  | encouraged and gave feedback to this specification, especially |
| including Frank Ellermann, Roy Fielding, Eran Hammer-Lahav, and |  | including Frank Ellermann, Roy Fielding, Eran Hammer-Lahav, and |
| Julian Reschke. |  | Julian Reschke. |
| Appendix E. Document history |  | Appendix E. Document history |
| [[ to be removed by the RFC editor before publication as an RFC. ]] |  | [[ to be removed by the RFC editor before publication as an RFC. ]] |
|  |  | -09 |
|  |  | o Corrected ptoken / ptokenchar BNF. |
|  |  | o Disallow multiple title* parameters. |
|  |  | o Prefer title* over title when available. |
|  |  | o Remove "\" from ptokenchar. |
|  |  | o Explain why mailing list isn't archived. |
|  |  | o Define default language for title and title*, based on Content- |
|  |  | Language (when present). |
|  |  | o Adjust MAY requirements. |
| -08 |  | -08 |
| o Licensed machine-readable data under MIT. |  | o Licensed machine-readable data under MIT. |
| o Clarified URI comparison for extension relation types. |  | o Clarified URI comparison for extension relation types. |
| o Various editorial tweaks (thanks, Julian!). |  | o Various editorial tweaks (thanks, Julian!). |
| o Changed "fields" to "appdata" to avoid confusion, and add example |  | o Changed "fields" to "appdata" to avoid confusion, and add example |
| to clarify. |  | to clarify. |
| o Defined REV according to HTML2, deprecated. |  | o Defined REV according to HTML2, deprecated. |
| o Clarified allowable characters in link-extensions. |  | o Clarified allowable characters in link-extensions. |
| o Changed RFC2231 reference to draft-reschke-rfc2231-in-http. |  | o Changed RFC2231 reference to draft-reschke-rfc2231-in-http. |
| o Added hub, latest-version, predecessor-version, successor-version, |  | o Added hub, latest-version, predecessor-version, successor-version, |
| version-history, working-copy and working-copy-of relation types |  | version-history, working-copy and working-copy-of relation types |
| to initial registry. |  | to initial registry. |
|  |  | o Adjusted text regarding when anchor parameter is appropriate. |
| -07 |  | -07 |
| o Allowed multiple spaces between relation types. |  | o Allowed multiple spaces between relation types. |
| o Relaxed requirements for registered relations. |  | o Relaxed requirements for registered relations. |
| o Removed Defining New Link Serialisations appendix. |  | o Removed Defining New Link Serialisations appendix. |
| o Added Field registry. |  | o Added Field registry. |
| o Added registry XML format. |  | o Added registry XML format. |
| o Changed registration procedure to use mailing list(s), giving the |  | o Changed registration procedure to use mailing list(s), giving the |
| Designated Experts more responsibility for the smooth running of |  | Designated Experts more responsibility for the smooth running of |
End of changes. 27 change blocks.
| 45 lines changed or deleted |  | 53 lines changed or added |
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/