Mark Nottingham wrote:
The sentence afterwards is a bit more revealing;
The Atom namespace is reserved for future forward-compatible revisions
of Atom. Future versions of this specification could add new elements
and attributes to the Atom markup vocabulary
There are two ways to read this;
1) Future RFCs that completely replace RFC4287 are the only ones allowed
to add new elements and attributes.
2) Future RFCs that update RFC4287 are allowed to add new elements and
attributes.
Given that we allow pretty much anybody to rock up and add a link
relation with IESG approval, it doesn't seem like a far stretch to me to
say that #2 is the right reading, given that the only real difference
between the two is regarding document structure (i.e., the whole doc +
extension, or just extension).
In other words, by the logic of #1, the only thing James would have to
do is to copy RFC4287, add a section on tombstones, and push it through
the process. That seems pointlessly tortured, to say the least.
I think the most you could say is that #2 needs IESG approval via a
standards-track RFC (again, notice the parity with the link relation
registry), but that's already assumed in the discussions I've seen here.
But that's just my .02.
If there's a good technical or social reason to put tombstones into the
atom namespace, let's hear it.
cheers
Bill
