Bill de hOra wrote: > [snip] > > [cc'd to the AD] > > I see this as a worst practice, and the rationale above as paper thin. > Frankly, I'm unable to conclude this is treating the spec's versioning > policy as anything other than a loophole. > > Please explain why the tombstone markup has been placed in the Atom
The reasons are simple: 1. This is a generic capability that is applicable to a broad range of application cases. That is, it is not application or implementation specific. 2. Implementors are already starting to face issues with supporting a broad and growing number of extension namespaces. Now whether these are good enough reasons, I'll leave that for Lisa to decide. FWIW, I'm fine with it either way. I made this change based on feedback from others here on this list. > namespace. As I see it, each third party addition of an arbitrary name > into the atom namespace degrades its overall value; Murato makato has > given examples as to why. Please recall we were very careful in > selecting the set of names for Atom. In this case there are no social or > technical gains to be had that I can see. > >> I will update the draft to make it clearer that the intent is to update >> RFC 4287. > > Then surely the way to do that, is to start work on updating RFC4287 > according to an IETF process, not adding arbitrary names via I-Ds and > waiting to be called on it here. > There is a reason I am bringing this to this forum for discussion rather than just writing up some code and deploying it. The process of review for Individual submissions are covered adequately by BCP 92 and I am not interested in just ramming changes to Atom through without adequate review. If it would be better to define tombstones in a separate namespace, then so be it, that's what I'll do; but the decision needs to be made based on general consensus and not on a single, subjective reading of an unclarified restriction in 4287. Lisa: what do you think? - James > cheers > Bill > >
