David Powell wrote: >[snip] > The abandonment of extension constructs in favour of undefined markup > by this draft, and other draft-*-atompub-* drafts would be an > interoperability concern if these drafts were deployed. If you want to > extend Atom, use Extension Elements. >
I'm most certainly not abandoning the extension constructs. One of the motivations for walking these extension specs through the I-D and eventually standards-track process is so that they get their own RFC number. Implementations that choose to support the extension can point to RFC4287 *and* RFCwhatever and say, "I support both". If an implementation only says "I support RFC4287" and doesn't say anything about RFCwhatever, it's pretty clear what the result would be. The most an RFC4287 implementation should be expected to do is adhere to the defined extension model. If that implementation also chooses to support other RFC's that go beyond that extension model, so be it. That said, the critical parts of the Feed Thread draft (the in-reply-to element and the replies link rel) follow the guidelines of the Atom extension model. That is, any RFC4287 implementation *should* be able to do something with those elements (even if it's just preserving them). The optional parts of the extension (thr:count an thr:when) fall outside of the Atom extension model. That's ok. Implementations can choose to ignore those things, even completely drop them. As for the other extension drafts I put out, keep in mind that most should be considered strictly experimental at this time. That said, there is really only one that really falls outside the extension model.. the Link Extensions draft [1]... which, by definition cannot adhere to the extension model given the fact that Atom link elements are actually not extensible. [1] http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-02.txt - James
