Improving the Trackback specification

I just noticed it yesterday, but it seems that Six Apart has begun the process of making the Trackback specification into a proper IETF standard.

I just noticed it yesterday, but it seems that Six Apart has begun the process of making the Trackback specification into a proper IETF standard. A great opportunity to finally solve some of the problems that plagues the current informal specification. I’ve gone over the new draft and over most of the posts on the mailinglist and already noticed some great ideas, most notable using HTTP response codes to indicate whether or not a trackback was accepted.

As the maintainer of the Nucleus trackback plugin I have run into some problems, specifically i18n support, which could be prevented by improving the specification. While the current informal specification was modified to explain how developers could improve interoperability, there are still client implementation that are unable to tell the server which character encoding format is used for the payload. Similarly, there are still server implementations that fail to recognize the character encoding format used by the client.

To solve these problems once and for all, I have written two proposals for inclusion in the standard: PaceRequireCharset and PaceRecommendUTF8. The first requires that clients inform the server of the character encoding format that is used for the payload and the second recommends that clients use the UTF-8 character encoding format.