| draft-nottingham-http-link-header-09.txt |  | draft-nottingham-http-link-header-10.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: October 4, 2010 |  | Expires: November 5, 2010 |
| Web Linking |  | Web Linking |
| draft-nottingham-http-link-header-09 |  | draft-nottingham-http-link-header-10 |
| 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 in full conformance with the |  | This Internet-Draft is submitted in full conformance with the |
| skipping to change at page 1, line 33 |  | skipping to change at page 1, line 33 |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF). Note that other groups may also distribute |  | Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | 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." |
| This Internet-Draft will expire on October 4, 2010. |  | This Internet-Draft will expire on November 5, 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 |
| skipping to change at page 2, line 36 |  | skipping to change at page 2, line 36 |
| 5.1. Target IRI . . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 5.1. Target IRI . . . . . . . . . . . . . . . . . . . . . . . . 7 |
| 5.2. Context IRI . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 5.2. Context IRI . . . . . . . . . . . . . . . . . . . . . . . 7 |
| 5.3. Relation Type . . . . . . . . . . . . . . . . . . . . . . 8 |  | 5.3. Relation Type . . . . . . . . . . . . . . . . . . . . . . 8 |
| 5.4. Target Attributes . . . . . . . . . . . . . . . . . . . . 8 |  | 5.4. Target Attributes . . . . . . . . . . . . . . . . . . . . 8 |
| 5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 |  | 5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 |
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 |  | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 |
| 6.1. Link HTTP Header Registration . . . . . . . . . . . . . . 10 |  | 6.1. Link HTTP Header Registration . . . . . . . . . . . . . . 10 |
| 6.2. Link Relation Type Registry . . . . . . . . . . . . . . . 10 |  | 6.2. Link Relation Type Registry . . . . . . . . . . . . . . . 10 |
| 6.3. Link Relation Application Data Registry . . . . . . . . . 16 |  | 6.3. Link Relation Application Data Registry . . . . . . . . . 16 |
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 |  | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 |
| 8. Internationalisation Considerations . . . . . . . . . . . . . 17 |  | 8. Internationalisation Considerations . . . . . . . . . . . . . 18 |
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |  | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |
| 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 |  | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 |
| 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 |  | 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 |
| Appendix A. Link Relation Registry Format . . . . . . . . . . . . 20 |  | Appendix A. Link Relation Registry Format . . . . . . . . . . . . 21 |
| A.1. Relax NG Grammar . . . . . . . . . . . . . . . . . . . . . 20 |  | A.1. Relax NG Grammar . . . . . . . . . . . . . . . . . . . . . 21 |
| A.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 21 |  | A.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 22 |
| Appendix B. Notes on Using the Link Header with the HTML4 |  | Appendix B. Notes on Using the Link Header with the HTML4 |
| Format . . . . . . . . . . . . . . . . . . . . . . . 21 |  |  |
| Appendix C. Notes on Using the Link Header with the Atom |  |  |
| Format . . . . . . . . . . . . . . . . . . . . . . . 22 |  | Format . . . . . . . . . . . . . . . . . . . . . . . 22 |
| Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 23 |  | Appendix C. Notes on Using the Link Header with the Atom |
| Appendix E. Document history . . . . . . . . . . . . . . . . . . 23 |  | Format . . . . . . . . . . . . . . . . . . . . . . . 23 |
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 |  | Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 24 |
|  |  | Appendix E. Document history . . . . . . . . . . . . . . . . . . 24 |
|  |  | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 |
| 1. Introduction |  | 1. Introduction |
| A means of indicating the relationships between resources on the Web, |  | A means of indicating the relationships between resources on the Web, |
| as well as indicating the type of those relationships, has been |  | as well as indicating the type of those relationships, has been |
| available for some time in HTML [W3C.REC-html401-19991224], and more |  | available for some time in HTML [W3C.REC-html401-19991224], and more |
| recently in Atom [RFC4287]. These mechanisms, although conceptually |  | recently in Atom [RFC4287]. These mechanisms, although conceptually |
| similar, are separately specified. However, links between resources |  | similar, are separately specified. However, links between resources |
| need not be format-specific; it can be useful to have typed links |  | need not be format-specific; it can be useful to have typed links |
| that are independent of their serialisation, especially when a |  | that are independent of their serialisation, especially when a |
| skipping to change at page 5, line 28 |  | skipping to change at page 5, line 28 |
| There are two kinds of relation types: registered and extension. |  | There are two kinds of relation types: registered and extension. |
| 4.1. Registered Relation Types |  | 4.1. Registered Relation Types |
| Well-defined relation types can be registered as tokens for |  | Well-defined relation types can be registered as tokens for |
| convenience and/or to promote reuse by other applications. This |  | convenience and/or to promote reuse by other applications. This |
| specification establishes an IANA registry of such relation types; |  | specification establishes an IANA registry of such relation types; |
| see Section 6.2. |  | see Section 6.2. |
| Registered relation type names MUST conform to the reg-relation-type |  | Registered relation type names MUST conform to the reg-rel-type rule, |
| rule, and MUST be compared character-by-character in a case- |  | and MUST be compared character-by-character in a case-insensitive |
| insensitive fashion. They SHOULD be appropriate to the specificity |  | fashion. They SHOULD be appropriate to the specificity of the |
| of the relation type; i.e., if the semantics are highly specific to a |  | 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 can 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). |
| skipping to change at page 7, line 11 |  | skipping to change at page 7, line 11 |
| more links in HTTP headers. It is semantically equivalent to the |  | more links in HTTP headers. It is semantically equivalent to the |
| <LINK> element in HTML, as well as the atom:link feed-level element |  | <LINK> element in HTML, as well as the atom:link feed-level element |
| in Atom [RFC4287]. |  | in Atom [RFC4287]. |
| Link = "Link" ":" #link-value |  | Link = "Link" ":" #link-value |
| 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-mt ) ) |
| | ( link-extension ) ) |  | | ( link-extension ) ) |
| link-extension = ( parmname [ "=" ( ptoken | quoted-string ) ] ) |  | link-extension = ( parmname [ "=" ( ptoken | quoted-string ) ] ) |
| | ( ext-name-star "=" ext-value ) |  | | ( ext-name-star "=" ext-value ) |
| ext-name-star = parmname "*" ; 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 = 1*ptokenchar |  | ptoken = 1*ptokenchar |
| ptokenchar = "!" | "#" | "$" | "%" | "&" | "'" | "(" |  | ptokenchar = "!" | "#" | "$" | "%" | "&" | "'" | "(" |
| | ")" | "*" | "+" | "-" | "." | "/" | DIGIT |  | | ")" | "*" | "+" | "-" | "." | "/" | DIGIT |
| | ":" | "<" | "=" | ">" | "?" | "@" | ALPHA |  | | ":" | "<" | "=" | ">" | "?" | "@" | ALPHA |
| | "[" | "]" | "^" | "_" | "`" | "{" | "|" |  | | "[" | "]" | "^" | "_" | "`" | "{" | "|" |
| | "}" | "~" |  | | "}" | "~" |
| media-type = type-name "/" subtype-name |  | media-type = type-name "/" subtype-name |
| quoted-media-type = <"> media-type <"> |  | quoted-mt = <"> 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-rel-type | ext-rel-type |
| reg-relation-type = LOALPHA *( LOALPHA | DIGIT | "." | "-" ) |  | reg-rel-type = LOALPHA *( LOALPHA | DIGIT | "." | "-" ) |
| ext-relation-type = URI |  | ext-rel-type = URI |
| 5.1. Target IRI |  | 5.1. Target IRI |
| Each link-value conveys one target IRI as a URI-Reference (after |  | Each link-value conveys one target IRI as a URI-Reference (after |
| conversion to one, if necessary; see [RFC3987], Section 3.1) inside |  | conversion to one, if necessary; see [RFC3987], Section 3.1) inside |
| angle brackets ("<>"). If the URI-Reference is relative, parsers |  | angle brackets ("<>"). If the URI-Reference is relative, parsers |
| MUST resolve it as per [RFC3986], Section 5. Note that any base IRI |  | MUST resolve it as per [RFC3986], Section 5. Note that any base IRI |
| from the message's content is not applied. |  | from the message's content is not applied. |
| 5.2. Context IRI |  | 5.2. Context IRI |
| skipping to change at page 11, line 41 |  | skipping to change at page 11, line 41 |
| o Application Data: [optional] |  | o Application Data: [optional] |
| 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 RELATION |  | list, marked clearly in the subject line (e.g,. "NEW RELATION |
| REQUEST"). |  | REQUEST"). |
| Within at most 14 days of the request, the Designated Expert(s) will |  | Within at most 14 days of the request, the Designated Expert(s) 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. |
| longer than 21 days can be brought to the IESG's attention (using the |  |  |
| iesg@iesg.org mailing list) for resolution. |  | Decisions (or lack thereof) made by the Designated Expert can be |
|  |  | first appealed to Application Area Directors (contactable using |
|  |  | app-ads@tools.ietf.org email address or directly by looking up their |
|  |  | email addresses on http://www.iesg.org/ website) and, if the |
|  |  | appellant is not satisfied with the response, to the full IESG (using |
|  |  | the iesg@iesg.org mailing list). |
| 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, so as |  | ietf.org mailing list (which SHOULD NOT be centrally archived, so as |
| to avoid load issues from automated agents, and only accept posts |  | to avoid load issues from automated agents, and only accept posts |
| from the Designated Expert(s)), so that implementers interested in |  | from the Designated Expert(s)), so that implementers interested in |
| receiving a machine-readable registry can do so. Simultaneously, |  | receiving a machine-readable registry can do so. Simultaneously, |
| they will send a text (not XML) version of the registry to IANA for |  | they will send a text (not XML) version of the registry to IANA for |
| publication. |  | publication. |
| skipping to change at page 13, line 38 |  | skipping to change at page 13, line 43 |
| o Reference: [W3C.REC-html401-19991224] |  | o Reference: [W3C.REC-html401-19991224] |
| o Relation Name: help |  | o Relation Name: help |
| o Description: Refers to a resource offering help (more information, |  | o Description: Refers to a resource offering help (more information, |
| links to other sources information, etc.) |  | links to other sources information, etc.) |
| o Reference: [W3C.REC-html401-19991224] |  | o Reference: [W3C.REC-html401-19991224] |
| o Relation Name: hub |  | o Relation Name: hub |
| o Description: Refers to a hub that enables registration for |  | o Description: Refers to a hub that enables registration for |
| notification of updates to the context. |  | notification of updates to the context. |
| o Reference: <http://pubsubhubbub.googlecode.com/> |  | o Reference: <http://pubsubhubbub.googlecode.com/> <http:// |
| o Notes: this relation type was requested by Brett Slakin. |  | pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html> |
|  |  | o Notes: this relation type was requested by Brett Slatkin. |
| o Relation Name: index |  | o Relation Name: index |
| o Description: Refers to an index. |  | o Description: Refers to an index. |
| o Reference: [W3C.REC-html401-19991224] |  | o Reference: [W3C.REC-html401-19991224] |
| o Relation Name: last |  | o Relation Name: last |
| o Description: An IRI that refers to the furthest following resource |  | o Description: An IRI that refers to the furthest following resource |
| in a series of resources. |  | in a series of resources. |
| o Reference: [this document] |  | o Reference: [this document] |
| o Notes: this relation type registration did not indicate a |  | o Notes: this relation type registration did not indicate a |
| reference. Originally requested by Mark Nottingham in December |  | reference. Originally requested by Mark Nottingham in December |
| 2004. |  | 2004. |
| o Relation Name: latest-version |  | o Relation Name: latest-version |
| o Description: Points to a resource containing the latest (e.g., |  | o Description: Points to a resource containing the latest (e.g., |
| skipping to change at page 14, line 28 |  | skipping to change at page 14, line 35 |
| o Reference: [W3C.REC-html401-19991224] |  | o Reference: [W3C.REC-html401-19991224] |
| o Relation Name: next-archive |  | o Relation Name: next-archive |
| o Description: Refers to the immediately following archive resource. |  | o Description: Refers to the immediately following archive resource. |
| o Reference: [RFC5005] |  | o Reference: [RFC5005] |
| o Relation Name: payment |  | o Relation Name: payment |
| o Description: indicates a resource where payment is accepted. |  | o Description: indicates a resource where payment is accepted. |
| o Reference: [this document] |  | o Reference: [this document] |
| o Notes: this relation type registration did not indicate a |  | o Notes: this relation type registration did not indicate a |
| reference. Requested by Joshua Kinberg and Robert Sayre. |  | reference. Requested by Joshua Kinberg and Robert Sayre. It is |
|  |  | meant as a general way to facilitate acts of payment, and thus |
|  |  | this specification makes no assumptions on the type of payment or |
|  |  | transaction protocol. Examples may include a web page where |
|  |  | donations are accepted or where goods and services are available |
|  |  | for purchase. rel="payment" is not intended to initiate an |
|  |  | automated transaction. In Atom documents, a link element with a |
|  |  | rel="payment" attribute may exist at the feed/channel level and/or |
|  |  | the entry/item level. For example, a rel="payment" link at the |
|  |  | feed/channel level may point to a "tip jar" URI, whereas an entry/ |
|  |  | item containing a book review may include a rel="payment" link |
|  |  | that points to the location where the book may be purchased |
|  |  | through an online retailer. |
| o Relation Name: prev |  | o Relation Name: prev |
| o Description: Refers to the previous resource in an ordered series |  | o Description: Refers to the previous resource in an ordered series |
| of resources. Synonym for "previous". |  | of resources. Synonym for "previous". |
| o Reference: [W3C.REC-html401-19991224] |  | o Reference: [W3C.REC-html401-19991224] |
| o Relation Name: predecessor-version |  | o Relation Name: predecessor-version |
| o Description: Points to a resource containing the predecessor |  | o Description: Points to a resource containing the predecessor |
| version in the version history. |  | version in the version history. |
| o Reference: [I-D.brown-versioning-link-relations] |  | o Reference: [I-D.brown-versioning-link-relations] |
| skipping to change at page 17, line 28 |  | skipping to change at page 17, line 48 |
| 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 |
| integrity-guaranteed, and due caution should be exercised when using |  | integrity-guaranteed, and due caution should be exercised when using |
| it. |  | it. Use of TLS with HTTP ([RFC2818] and [RFC2817]) is currently the |
|  |  | only end-to-end way to provide such protection. |
| Applications that take advantage of typed links should consider the |  | Applications that take advantage of typed links should consider the |
| attack vectors opened by automatically following, trusting, or |  | attack vectors opened by automatically following, trusting, or |
| otherwise using links gathered from HTTP headers. In particular, |  | otherwise using links gathered from HTTP headers. In particular, |
| Link headers that use the "anchor" parameter to associate a link's |  | Link headers that use the "anchor" parameter to associate a link's |
| context with another resource should be treated with due caution. |  | context with another resource should be treated with due caution. |
|  |  | The Link entity-header field makes extensive use of IRIs and URIs. |
|  |  | See [RFC3987] for security considerations relating to IRIs. See |
|  |  | [RFC3986] for security considerations relating to URIs. See |
|  |  | [RFC2616] for security considerations relating to HTTP headers. |
| 8. Internationalisation Considerations |  | 8. Internationalisation Considerations |
| Target IRIs may need to be converted to URIs in order to express them |  | Target IRIs may need to be converted to URIs in order to express them |
| in serialisations that do not support IRIs. This includes the Link |  | in serialisations that do not support IRIs. This includes the Link |
| HTTP header. |  | HTTP header. |
| Similarly, the anchor parameter of the Link header does not support |  | Similarly, the anchor parameter of the Link header does not support |
| IRIs, and therefore IRIs must be converted to URIs before inclusion |  | IRIs, and therefore IRIs must be converted to URIs before inclusion |
| there. |  | there. |
| skipping to change at page 19, line 9 |  | skipping to change at page 19, line 35 |
| [I-D.brown-versioning-link-relations] |  | [I-D.brown-versioning-link-relations] |
| Brown, A., Clemm, G., and J. Reschke, "Link Relation Types |  | Brown, A., Clemm, G., and J. Reschke, "Link Relation Types |
| for Simple Version Navigation between Web Resources", |  | for Simple Version Navigation between Web Resources", |
| draft-brown-versioning-link-relations-07 (work in |  | draft-brown-versioning-link-relations-07 (work in |
| progress), January 2010. |  | progress), January 2010. |
| [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. |  | [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. |
| Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", |  | Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", |
| RFC 2068, January 1997. |  | RFC 2068, January 1997. |
| [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication |  | [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within |
| Format", RFC 4287, December 2005. |  | 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, |  | [RFC4685] Snell, J., "Atom Threading Extensions", RFC 4685, |
| September 2006. |  | September 2006. |
| [RFC4946] Snell, J., "Atom License Extension", RFC 4946, July 2007. |  | [RFC4946] Snell, J., "Atom License Extension", RFC 4946, July 2007. |
| [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, |  | [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, |
| September 2007. |  | September 2007. |
| [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing |  | [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing |
| skipping to change at page 23, line 41 |  | skipping to change at page 24, line 41 |
| 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 |  | -10 (result of IESG review) |
|  |  | o Clarified media BNF. |
|  |  | o Added various security considerations. |
|  |  | o Updated registration procedures. |
|  |  | o Added more detail to 'payment' relation. |
|  |  | o Corrected 'hub' relation. |
|  |  | -09 |
| o Corrected ptoken / ptokenchar BNF. |  | o Corrected ptoken / ptokenchar BNF. |
| o Disallow multiple title* parameters. |  | o Disallow multiple title* parameters. |
| o Prefer title* over title when available. |  | o Prefer title* over title when available. |
| o Remove "\" from ptokenchar. |  | o Remove "\" from ptokenchar. |
| o Explain why mailing list isn't archived. |  | o Explain why mailing list isn't archived. |
| o Define default language for title and title*, based on Content- |  | o Define default language for title and title*, based on Content- |
| Language (when present). |  | Language (when present). |
| o Adjust MAY requirements. |  | 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. |
End of changes. 21 change blocks.
| 37 lines changed or deleted |  | 71 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/