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
1Authentication 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]