The Next Generation of TrackBack: A Proposal

In taking all of the recent discussion and experimentation with TrackBack and related interfaces, I thought it would be helpful to draft some suggestions for consideration for the next generation (NG) of the interface. This document and forum (more on that later) is meant to be a starting point to begin a productive discussion and further the constructive and valuable work being done thus far.

Since its introduction in June 2002 by Ben and Mena Trott, TrackBack has been gaining momentum as a means for creating distributed forms of communication, intertwinularity, manufactured serendipity and other social networks. In recent weeks experimentation and discussion of the interface has been catching on. With this, some of the shortcomings and limitations of the current specification (v1.1) have begun to come into focus.

The specification document need more clarification and refinement particularly as to where the specification ends and specific implementations begin. Additionally the specification would benefit by better addressing issues of extensibility and the reasonable expansion of its scope. These are some of the more specific proposal I have collected.

Make TrackBack even more RESTful. The original intention of the interface is to comply with the REST style of architecture. Version 1.0 did not fully comply with this stated goal and necessitated the release of version 1.1 (with the help of Paul Prescod) that brought it closer, but not completely, into compliance. The next version should continue down this road towards complete compliance. To that end:

• TrackBack should utilize standard HTTP messages for all replies (201 Created, 200 Success etc.) and depreciate the proprietary messaging scheme currently implemented.
• Content negotiation (conneg) should be supported in addition to the query string switch currently in use. The query string switch would take precedence.
• In addition to the application/x-www-form-urlencoded MIME-type, TrackBack should alternately accept an RSS item fragment with a text/xml type, in the body of a POST.

Forge even closer ties with RSS. TrackBack already share a very close relationship, but more can be done them even closer together. I've already disclosed as one in the previous section. Other considerations include:

• Implement RSS field names and depreciate existing field name. excerpt would become descriptpion. url would become link. blog_name would become dc:source.
• Establish required fields for POSTs that coincide with the RSS 0.91 specification, the most widely deployed version of the format. In other words title, link, and description.

Refine and expand auto-discovery options. Works fine though criticisms around that this is a hack and break standards compliance. The current practice isn't terribly efficient or plausible for more sophisticated uses. this area requires further discussion. Here are some cursory ideas.

• Use RSS structure instead of RDF. If TrackBack where to adopt closer ties with the RSS format as I have suggested this only seems to make sense. I'll just stop there with this one.
• Similar to RSS auto-discovery, TrackBack should make use of the link tag to assist TrackBack client in discovering the URI associated to a web page. (Assuming HTTP messages are adopted, the 201 Created message returned to a successful ping should also return an RSS item fragment with all the pertinent meta data usually recovered extracted from the existing method. An alternate take would use the link tag to point to an external file containing the RSS Item fragment. Yet another would be a hybrid of the two where Dublin Core tags are embedded in the HTML.
• Specify the discovery and function of an optional TrackBack information service. The main purpose of this service is to make auto-discovery more efficient and scalable then grabbing an HTML page and scraping it. (Obviously there isn't enough detail here yet.)

A couple of other facets that should be addressed include:

• Multiple Pings per web page. Outlawed? Permitted, but not advisable? Just fine?
• TrackBack Ping ID guidance. There seems to be some confusion here and could use further clarification and refinement.
• FOAF and digital signatures. Should the concept be worked into the specification?

I've also created a forum to more directly discussing these proposals and share ideas. This is a bit of a first in more ways then one. I've been using TrackBack here since almost day one, but have never used comments to experiment with them. (I've begun subtly tinkering with how MT's comments work to do something different then how they are commonly used.) Alas, I did not get around to following my own advice and implement comments AS TrackBack. Soon I promise.

Another place to discuss this and similar topics is the ucapi-discuss (Universal Canvas API) mailing list hosted by Yahoo. All encourage you to join, ask questions and participate in the discussions.

This is a list of resources and posts on the topic of TrackBack that I've collected recently. Its by no means a complete one. (Please don't be offended if I missed you.) In no particular order:

• TrackBack Technical Specification
• The TrackBack Development Weblog
• Cohesion (Sam Ruby)
• The universal canvas and RSS apps (DJ Adams)
• Trackback in the saddle again - a list of various TrackBack variants and implementations. (Ben Hammersley)
• XML::TrackBack
• Comments via TrackBack (Rael Dornfest)
• Mark Paschel's TBPY -- a standalone TrackBack CGI written in Python.
• TrackBack for Notifications (Scott Andrew)
• Whitepaper: Pingback vs TrackBack 1.1 (Ian Hickson)
• RESTLog Comments API (Joe Gregorio)
• Ridiculously Easy Group Forming
• Centralized TrackBack Aggregation for News and Links (PopDex)