Request for Comments: Pingback NG

I'd like this document to serve as a beginning of a conversation on improving pinging mechanisms in blogware. If you bear with me through this and decide you like the idea, please consider passing this link along so that real change may become possible in the near future.

After spending the last few days implementing Trackback and Pingback clients and servers for SAFARI (which I am presently searching for a new name for), I've come to the conclusion that both systems are woefully annoying to work with and need updating. I've come to the conclusion that Trackback is far easier to work with, but it too is flawed.

Trackback
Trackback is older than Pingback and is dominant primarily because it was advocated by Six Apart (MovableType). Now, with the winds blowing in WordPress' favor (at least from what I can see), I wonder if Trackback will eventually be marginalized, since Pingback is automatic in WordPress, whereas Trackback is not.

The flaws in Trackback, in my opinion, are as follows: (1) the pinging process uses the HTTP POST form data mechanism rather than XML-RPC and (2) there is no notification of what form the link takes on the site initiating the trackback. The first is a flaw that seems to be caused by a desire for simplicity. To send a form via Perl using Trackback, all we need to do is call LWP::UserAgent and feed it the form item names and contents. Easy, but not that much easier than feeding a properly formed XML-RPC document to LWP::UserAgent using the same POST method. This creates a situation where we send information in one format (URI Encoded form data) and receive a response in a different format (XML). The second flaw probably wasn't obvious when the spec was originally created, but is now clear; since I know what entry is being linked to but not the actual URL leading to that entry, my blogware must scan the initiating site's page for every possible format my URL might be in, if I wish to verify that linkage has taken place. Adding another parameter to the trackback spec (it could be optional for backwards compatibility) that contained the form of the link that the initiating blog was asserting it was using, would allow for an easy rectification of this issue.

Pingback
Pingback's problems are bit more annoying than what I have listed above. First, since the only two parameters of the spec are the initiating blog entry's URL and the destination URL (which, does, at least, solve my second complaint concerning Trackback), we are confronted with a big problem on a dynamic web site. The pingback client might tell me that http://site/blog/entry/22 is being linked to, but if I support multiple URL formats to request a given document (either directly via the blogware or indirectly via mod_rewrite), I must perform pattern matching to figure out exactly what http://site/blog/entry/22 links to. This isn't a problem in cases where the pages are static, such as some of those that Pingback seeks to support, but it is the problem in the case of blogware. This is not a problem with Trackback, since the trackback server can be different for each page (thereby identifying which document is being linked to), but it does rear its ugly head with Pingback, since the goal is to have one Pingback server for all documents on the site.

Therefore, I would propose that an additional, optional attribute should be added: Pingback-ID. This would be a text string that could be in any form and could be provided in the HTTP headers, just as X-Pingback supplies the pingback server location. A pingback enabled site could push this additional X-Pingback-ID header just as easily as the primary Pingback header, and it could specify, in the form of the server's own choosing, how to properly identify the page. The form of the string could be the local path to the document, an article ID number or perhaps even something encrypted so that the server could insure that it received an unmodified copy when the string is sent back. Even in the case of pingbacks to static documents, the server could pass along a Pingback-ID to insure that the real file being linked to is easily identifiable, should its actual location be obscured by mod_rewrite, for instance. The format would not need to be specified in the Pingback spec, since only the server needs to understand what the string means. Once the client pulled in this information, the resulting XML-RPC ping could contain this parameter in addition to the standard parameters of the pingback.

The second flaw I see in Pingback is that it does not include any useful information about the initiating site. Optional parameters ought to include title/site name and a text excerpt/description, in the same manner as a Trackback. Without this, the Pingback server must go and attempt to pick out useful substitute information from the initiating site if we want to include pingbacks with trackbacks in the comments section of a blog (as WordPress does and I have also done in SAFARI). While this works, it can produce less useful results than if we are fed the proper information by the author of the source document. By making this optional, we would avoid making the Pingback spec any more specifically tied to blogs than it already is, while greatly enhancing its ability to be a suitable mechanism for blog-to-blog communication.

Conclusion
Pingback's flaws, in my estimation, make it harder to implement in a manner that provides the Trackback-like functionality it is being used for in WordPress and other blogware, and frankly, limits its usefulness even in broader deployments, due to problems such as the aforementioned inability to easily determine what the destination URL links to on a server that uses mod_rewrite or otherwise is non-static.

That said, Pingback is consistent in its usage of XML-RPC, and therefore is preferable, in my estimation, to Trackback in the future. An improved, Next Generation Pingback spec (or “Pingback NG,” for short) could easily remove the most problematic parts of the system, creating a spec that was simple and efficient to implement in blogware, like Trackback, while remaining more flexible than Trackback in where it can be applied.

• Pingback 1.0 Spec
• Trackback 1.1 Spec