On 07/01/2008, at 11:46 AM, Bill de hOra wrote:
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.
As I think I said before, it's not a big deal either way; I just don't
want people to walk away thinking that *no* extension can be in the
atom namespace. Whether or not Tombstones in particular belong in the
Atom namespace is mostly a question of how common we think they'll be
once deployed, across a variety of use cases.
Personally, I think that there's potential for them to be widely
deployed across a number of use cases. In a way, both tombstones and
feed history feel like 'missing' parts of atom (but I realise that
from some perspectives, that can be said of almost any extension).
Cheers,
--
Mark Nottingham http://www.mnot.net/
