Network Working Group November 14, 2005 Internet-Draft Expires: May 18, 2006 Trackback draft-trackback.xml Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at 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 May 18, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This specification defines a transitional form of the Atom 1.0 Entry Document. Expires May 18, 2006 [Page 1] Internet-Draft Trackback November 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. The TrackBack Protocol . . . . . . . . . . . . . . . . . . . . 3 2.1. TrackBack Requests . . . . . . . . . . . . . . . . . . . . 3 2.2. TrackBack Responses . . . . . . . . . . . . . . . . . . . 4 3. TrackBack Auto-discovery . . . . . . . . . . . . . . . . . . . 5 3.1. TrackBack Link . . . . . . . . . . . . . . . . . . . . . . 5 3.2. TrackBack RDF Documents . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Expires May 18, 2006 [Page 2] Internet-Draft Trackback November 2005 1. Introduction This document describes the TrackBack protocol -- a framework for peer-to-peer communication and notification between web sites. The central artifact of the TrackBack protocol is an HTTP request called a "Ping" that is used to essentially communicate that "resource A is related to or linked to by resource B". 1.1. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119]. 1.2. Terminology o TrackBack Ping URL - The HTTP URI to which TrackBack Ping requests are POSTed. o Ping - An HTTP POST request send from a client to a server for the purpose of establishing an explicit relationship between Web resources. o Client - The entity sending a Ping. o Server - The entity receiving the Ping. o Target Resource - The Web resource to which a Ping is directed for the purpose of establishing a relationship between it and an Originating Resource. o Originating Resource - A Web resource containing a reference or link to the Target Resource. 2. The TrackBack Protocol TrackBack is an application layer protocol utilizing HTTP POST requests to establish relationships between Web resources. For instance, given two domains A and B, when a resource is created on domain A that relates to or references a resource located within domain B, domain A sends an HTTP POST request to domain B using a TrackBack Ping URL provided by domain B to notify domain B of the existence of the new resource. 2.1. TrackBack Requests The entity payload of TrackBack Ping requests consist of a collection of properties expressed as name=value pairs encoded in accordance to the rules of the application/x-www-form-urlencoded media type as defined by [W3C.REC-html401-19991224]. The Content-Type header of the HTTP POST request MUST be 'application/x-www-form-urlencoded'. Expires May 18, 2006 [Page 3] Internet-Draft Trackback November 2005 Clients SHOULD transmit the character encoding of the entity payload using the charset parameter of the Content-Type header. This specification defines the following TrackBack Ping properties: o title - A human readable title for the Originating Resource. o excerpt - A human readable excerpt of text from the Originating Resource. o url - The URL of the Originating Resource. o blog_name - A human readable name for the entity to which the Originating Resource belongs. o id - A permanent and universally unique Internationalized Resource Identifier, (IRI) [RFC3987] identifying the Originating Resource. o source - The URL of a resource containing the Originating Resource. Of these properties, only "url" is required. Clients MAY choose to include name=value pairs in addition to those described above. Servers SHOULD ignore any such properties that it does not understand. Example TrackBack Ping Request POST /trackback-url HTTP/1.1 Host: example.org Content-Type: application/x-www-form-urlencoded; charset=utf-8 Content-Length: nnnn title=My+Resource&url=http://example.org/a&excerpt=Hello+World \ &blog_name=My+Blog&id=tag:example.org,2005:/resources/a 2.2. TrackBack Responses Upon successful receipt and processing of a TrackBack Ping Requests, the Server SHOULD respond with an HTTP status code of 200. Whether the Ping was successfully processed or not, the entity payload of the HTTP response MUST include a TrackBack response document as specified below. The Content-Type header for such document MUST be either 'text/xml' or 'application/xml' and SHOULD specify the character encoding of the response entity using the charset parameter. trackbackResponse = element response { ( trackbackError?, & trackbackMessage? ) } trackbackError = element error { 1 | 0 } Expires May 18, 2006 [Page 4] Internet-Draft Trackback November 2005 trackbackMessage = element message { text } If the Ping request was successfully processed, the 'response' element MUST either omit the 'error' error or set the content value of the 'error' element to '0'. If the Ping request was not successfully processed, the 'response' element MUST contain an 'error' element with a content value of '1' and SHOULD contain a 'message' element whose content value conveys a human-readable explanation of error. Example Successful TrackBack Response HTTP/1.1 200 OK Date: Mon, 14 Nov 2005 12:12:12 GMT Content-Length: nnnn Content-Type: application/xml; charset=utf-8 0 Example Failed TrackBack Response HTTP/1.1 401 Unauthorized Date: Mon, 14 Nov 2005 12:12:12 GMT WWW-Authenticate: Basic realm="example.org" Content-Length: nnnn Content-Type: application/xml; charset=utf-8 1 Authentication is required 3. TrackBack Auto-discovery Before a Client can send a TrackBack Ping to a Server, it must first identify the TrackBack Ping URL to which it send the HTTP POST request. To facilitate the discovery of the TrackBack Ping URL, Servers MAY use either of the two mechanisms described below. 3.1. TrackBack Link Individual Web resources represented by HTML [W3C.REC-html401- 19991224], XHTML [W3C.REC-xhtml1-20020801], or Atom Syndication Format [I-D.ietf-atompub-format] documents MAY contain a link element with a 'rel' attribute value of 'trackback', a 'type' attribute value Expires May 18, 2006 [Page 5] Internet-Draft Trackback November 2005 of 'application/x-www-form-urlencoded', and an 'href' attribute specifying the Trackback Ping URL for the resource. Example HTML TrackBack Link Example Atom TrackBack Link ... ... 3.2. TrackBack RDF Documents Web resources that represent multiple potential Target Resources MAY provide a single TrackBack RDF Document for each individual pingable resource. These documents are typically embedded within HTML or XHTML documents and are typically not intended to be dislayed within a Web browser. In order to prevent browsers from displaying these documents, they may be embedded within Comment markup. Expires May 18, 2006 [Page 6] Internet-Draft Trackback November 2005 4. Security Considerations As an application protocol based on HTTP, the TrackBack Protocol is subject to the same security considerations discussed in [RFC2616]. The nature of the TrackBack Protocol makes it possible for malicious clients to send undesirable Pings to a Target Resource for the purpose of establishing illegitimate links between resources in order, in part, to boost the Originating Resources search engine rankings. Such undesirable pings are known as "TrackBack Spam". The TrackBack Protocol does not specify any normative countermeasures for preventing TrackBack Spam but a number of preventative practices have emerged through the implementation of the protocol. For instance, some Servers have adopted the practice of scanning Originating Resources for legitimate links to the Target Resource. As many forms of TrackBack Spam omit such links, such practice has been demonstrated to be an effective defense. Another defensive practice that has proven effective is active moderation of the received TrackBack pings. With this approach, TrackBacks Pings are held in a temporary queue until an administrator either approves or denies the Ping. This practice effectively ensures that undesirable Pings will be filtered out during the administrative review process. Additional methods of defending against TrackBack Spam could include blocking TrackBack Pings originating from the IP addresses of known TrackBack Spammers, automatic throttling of TrackBack Pings, or the use of HTTP Authentication mechanisms. 5. IANA Considerations This specification specifies the following new value for the Atom Syndication Format's Registry of Link Relations: Attribute Value: trackback Description: A URI that refers to a Trackback Ping URL Expected Display Characteristics: Not defined Security Considerations: See the "Security Considerations" section of this draft. Expires May 18, 2006 [Page 7] Internet-Draft Trackback November 2005 6. References [I-D.ietf-atompub-format] Sayre, R. and M. Nottingham, "The Atom Syndication Format", draft-ietf-atompub-format-11 (work in progress), August 2005. [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. [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005. [W3C.REC-html401-19991224] Hors, A., Jacobs, I., and D. Raggett, "HTML 4.01 Specification", W3C REC REC-html401-19991224, December 1999. [W3C.REC-xhtml1-20020801] Pemberton, S., "XHTML[TM] 1.0 The Extensible HyperText Markup Language (Second Edition)", W3C REC REC-xhtml1- 20020801, August 2002. Expires May 18, 2006 [Page 8] Internet-Draft Trackback November 2005 Author's Address Phone: Email: URI: Expires May 18, 2006 [Page 9] Internet-Draft Trackback November 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Expires May 18, 2006 [Page 10]