phil ringnalda

One nice little thing that the Atom format provides is an element that lets you identify a particular feed as being the same thing, even if the URL for the feed moves around over time. From the draft spec:

The “atom:id” element’s content conveys a permanent, globally unique identifier for the feed. It MUST NOT change over time, even if the feed is relocated. atom:feed elements MAY contain an atom:id element, but MUST NOT contain more than one. The content of this element, when present, MUST be a URI.

So, you may but don’t have to have one and only one, inside the <feed> element, and once you have one it has to stay the same forever. It has to be a URI, but since when people see a URL they expect to retrieve it and get something, you may not want to use one: given that my feed is (mostly) a continuation of my old Blogger Tech blog, I could use something based on http://bloggertech.blogspot.com, but that URL is currently rather confusing, since at some point after I published a redirect and renamed it “Never publish bloggertech” Blogger published it anyway.

It looks like the current best practice is to use a tag URI (nevermind that it’s not actually a formal published URI scheme just yet). Tag URIs are fairly simple: pick a domain or email address that you controlled at a particular time, then a date on which you controlled it, then a name for this particular tag. As of today, I control (somewhat) bloggertech.blogspot.com, so tag:bloggertech.blogspot.com,2004-02-15:weblog.1 would be a valid tag URI. Even if tomorrow I give up that subdomain, and someone else picks it up, they wouldn’t do any tags that include 2004-02-15, only 2004-02-16 and later. Since I controlled it for all of January, and all of 2003, I could also use either 2004-01 or 2003.

However, for it to be a valid atom:id, I can’t ever change it, unless I want to say that the feed has stopped, and something different has started. That’s where the current Movable Type Atom template had a bad IDea: it builds an atom:id dynamically, based on the current domain, current year, current relative URL, and current blog ID number, every single one of which can change over time (though changing the blog ID requires that it not be 1, and that you do an export/import, it’s still quite possible to have it change). If I decide tomorrow to move my blog to /weblog/, then next October decide to move to philringnalda.org, and change hosts (requiring an export/import, and probably moving this blog from whatever it is now, 8 I think, to 1), then by next January every single part of my atom:id will have changed, when absolutely nothing should have changed.

Doing a valid atom:id that’s a valid tag URI’s simple as can be: just replace the dynamic tags in your template with a hardcoded yourdomain.tld,2004-02-15:somename, but because Movable Type doesn’t have any way to extract that data automatically once and then never change it, it MUST NOT include an atom:id in the default template. It’s not required, leaving it out won’t hurt a thing, but having it there and wrong will hurt things. A reasonable Atom aggregator, when it gets an HTTP 301 permanent redirect for the URL it uses for a feed, would retrieve the feed from the new Location:, and if the atom:id is the same, would just silently start using the new URL, but if the atom:id was different, would alert the user that something odd had occurred: “We’ve been redirected from one of our feeds to some different feed. Do you want to start a new subscription to this new feed?”.