Subject: Updated Tombstones Draft

From: James M Snell <[email-masked]>
Date: Wed, 02 Jan 2008 18:15:48 -0800

Reviving the Tombstones draft. Consider this a work in progress.

http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-03.txt

There are two significant changes:

 1. deleted-entry is now part of the Atom namespace
 2. a "trash" link relation is registered to point
    to trash feeds.

The trash feed approach and deleted-entry element approaches are
definitely compatible with one another.  They can be used together or
independently.

- James

---

From: "MURATA Makoto (FAMILY Given)" <[email-masked]>
Date: Thu, 03 Jan 2008 12:16:20 +0900

>  1. deleted-entry is now part of the Atom namespace

I am concerned about this change, since I care about validation 
of atom feeds containing extensions.

It appears that extensions (both standard and proprietrary ones) 
are being designed without creating full schemas.  I fear that 
lack of schemas eventually hampers evolution of atom.

To me,  a different namespace for deleted-entry makes much more 
sense, since the use of NVDL for atom validation becomes more 
natural.

Cheers,

-- 
MURATA Makoto (FAMILY Given) <[email-masked]>

---

From: James M Snell <[email-masked]>
Date: Wed, 02 Jan 2008 19:31:36 -0800

Noted. FWIW, I'm happy either way.

- James

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Jan 2008 15:13:55 +1100

This looks good, except I'm having trouble with the trash feed; is a  
client who wishes to implement this spec required to look both for  
deleted-entry and link/@rel="trash", polling that if present? If so,  
it seems overly cumbersome to implement two mechanisms.

BTW, "trash" is culturally specific; how about "garbage"? <1/2 wink>

Cheers,

--
Mark Nottingham     http://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Jan 2008 15:08:15 +1100

> sense, since the use of NVDL for atom validation becomes more

My .02 -- I think the concern of namespace proliferation outweighs  
this; schema validation isn't evident on the wire, isn't required for  
conformance to the spec, and reflects problems in the XML world more  
than it does issues that will affect developers day-to-day.

That having been said, I'm not strongly against using a different  
namespace; after all, we're using XML...

Cheers,

---

From: Bill de hOra <[email-masked]>
Date: Thu, 03 Jan 2008 04:33:47 +0000

>  1. deleted-entry is now part of the Atom namespace

"The Atom namespace is reserved for future forward-compatible 
revisions of Atom." RFC4287, 6.2.

The rfc-editor should have picked this up.

>  2. a "trash" link relation is registered to point

Aside from what we talked about recently, the document only talks about 
deletion in the past tense; there's no deletion mechanism specified.

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Wed, 02 Jan 2008 20:58:22 -0800

Bill de hOra wrote:
> "The Atom namespace is reserved for future forward-compatible revisions
> of Atom." RFC4287, 6.2.
> 

Picked what up?  The rfc-editor is not involved in the publishing of
I-D's.  If this I-D is published as a Standards Track RFC, it would
specifically indicate that it is an update to RFC 4287 and would qualify
as a "forward-compatible revision of Atom".  I believe that it's up to
the Area Director to determine whether or not to allow individual
submissions such as this to proceed along that route or whether a WG is
required.

> deletion in the past tense; there's no deletion mechanism specified.

There's no need to specify a deletion mechanism.  A deleted-entry
element indicates that an entry has been removed from the feed and the
trash link relation points to a resource listing the entries that have
been removed.  The mechanism used to remove those items is orthogonal to
both.

- James

---

From: James M Snell <[email-masked]>
Date: Wed, 02 Jan 2008 20:52:37 -0800

Mark Nottingham wrote:
> deleted-entry and link/@rel="trash", polling that if present? If so, it
> seems overly cumbersome to implement two mechanisms.
> 

The client can look for either.  Essentially, the deleted-entry element
tells you only that the entry was removed from this particular feed.  It
does not tell you if the entry exists in some other location.  The trash
feed is orthogonal to deleted-entry and provides a location where things
like soft-deleted items can be collected.  For instance, suppose we have
an Atompub collection managed by multiple authors, Bob and Joe.  Bob
deletes an entry. Joe discovers that that the entry has been deleted
when he sees the deleted-entry element.  If Joe wishes to recover the
deleted entry, he can go to the trash feed and look for it there.  A
client could poll the trash feed to discover deleted items if it wishes
to do so, but looking for the deleted-entry items would likely be more
efficient.

- James

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Jan 2008 15:57:41 +1100

Hmm. It seems like you need to say something to this; otherwise people  
may get the feeling they can use them separately.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Jan 2008 15:58:48 +1100

> revisions of Atom." RFC4287, 6.2.

... which begs the question: does this qualify as such?

Cheers,

---

From: James M Snell <[email-masked]>
Date: Wed, 02 Jan 2008 20:59:28 -0800

+1. I was already thinking that some text was needed describing the
relationship between these.

- James

---

From: Peter Keane <[email-masked]>
Date: Thu, 3 Jan 2008 00:13:40 -0600 (CST)

The trash feed is primarily for recovering a soft-deleted item correct? 
The OS analogy is a bit strained since the OS "trash" is the means by 
which you get rid of stuff and only secondarily provides a means to 
retrieve things.  Something like "removed" or "archived" or some such 
might be more descriptive.

This "trash/removed/archived" feed is optional, correct?  I.e., it'll be 
used by server implementations optimized for soft-deletes (and wouldn't 
likely be used for comment spam, for instance)?

Also, since deleted-entry has an atom:id I can happily keep thinking of it 
as a kind of entry (quacks like a duck... ;-)), so I'll rescind my 
previous compliants.

All-in-all this looks like it covers the cases described in OAI-PMH (which 
from my POV is a very good thing).

thanks!
peter keane

---

From: James M Snell <[email-masked]>
Date: Wed, 02 Jan 2008 22:25:42 -0800

> might be more descriptive.

Yeah, I'll be working on the descriptive test around that a bit.  It's
not just for soft-delete.  The entry could have been permanently removed
from the underlying data store and added to a statically generated trash
file, primarily for the purpose of keeping it around so it could be
recreated later as a new entry.

> likely be used for comment spam, for instance)?

Right. The trash feed is primarily intended to be used by the server to
provide the client a means of recovering deleted entries.  For things
like comment spam, the trash feed is not going to be needed.

> Also, since deleted-entry has an atom:id I can happily keep thinking of
> it as a kind of entry (quacks like a duck... ;-)), so I'll rescind my
> previous compliants.

:-). quacks like a duck with significantly fewer feathers.

> 
> All-in-all this looks like it covers the cases described in OAI-PMH
> (which from my POV is a very good thing).
> 

Good to hear. FWIW, after reading through the links you provided, I had
come to the same conclusion.

- James

---

From: "MURATA Makoto (FAMILY Given)" <[email-masked]>
Date: Thu, 03 Jan 2008 16:56:13 +0900

First, if the Tombstone extension is not a must for every atom
implementation, it should not use the atom namespace.  Second, 
although I agree that validation is not all mighty,  I do believe 
that it solves some problems.  (I will report one interesting 
example soon.)  There is no point in making validation difficult 
when there are no gains.

Cheers,

---

From: "James Holderness" <[email-masked]>
Date: Thu, 3 Jan 2008 10:13:46 -0000

> Reviving the Tombstones draft. Consider this a work in progress.

Out of curiostiy, are there any server developers here that are planning (or 
even just considering) adding tombstone support for something like 
comment-spam or erasing erroneous posts from a blog? Basically any use-case 
that might benefit a typical feed reader?

Also, for the record, I should express again my preference for using 
attributes rather than elements for at least the primary fields. If you need 
justification:

1. It's a more compact representation, which helps counter the arguments of 
people that think tombstones shouldn't be clogging up a regular feed or 
should require clients to issue special headers requesting them.
2. It requires less state information to parse (other client developers may 
disagree, but this makes a significant difference to me).
3. I suspect people are a lot more likely to get your field names wrong when 
using elements rather than attributes (using "author" instead of "by", 
"updated" instead of "when"), especially now that you're proposing putting 
this in the Atom namespace.

Then again, if nobody here is planning to use this in a way that would be 
relevant to me, it doesn't really matter what form it takes.

Regards
James

---

From: James M Snell <[email-masked]>
Date: Thu, 03 Jan 2008 08:07:02 -0800

James Holderness wrote:
> Out of curiostiy, are there any server developers here that are planning
> (or even just considering) adding tombstone support for something like
> comment-spam or erasing erroneous posts from a blog? Basically any
> use-case that might benefit a typical feed reader?
> 

I will be implementing support for it in an upcoming version of IBM's
internal blogs and will likely add support to, at the very least, the
Lotus Connections blog component -- assuming we get some traction around
this approach.

> attributes rather than elements for at least the primary fields. If you
> need justification:
> 
> 1. It's a more compact representation, which helps counter the arguments
> of people that think tombstones shouldn't be clogging up a regular feed
> or should require clients to issue special headers requesting them.
> 2. It requires less state information to parse (other client developers
> may disagree, but this makes a significant difference to me).
> 3. I suspect people are a lot more likely to get your field names wrong
> when using elements rather than attributes (using "author" instead of
> "by", "updated" instead of "when"), especially now that you're proposing
> putting this in the Atom namespace.
> 

Noted.  FWIW, I'm happy with it either way.

  <deleted-entry id="..." when="..." by="..." comment="..." />

Works for me.

- James

> Then again, if nobody here is planning to use this in a way that would
> be relevant to me, it doesn't really matter what form it takes.
> 
> Regards
> James
> 
>

---

From: Bill de hOra <[email-masked]>
Date: Thu, 03 Jan 2008 18:02:16 +0000

> ... which begs the question: does this qualify as such?

Not if the word "revision" means what I think it does.

cheers
Bill

---

From: Bill de hOra <[email-masked]>
Date: Thu, 03 Jan 2008 18:17:25 +0000

> submissions such as this to proceed along that route or whether a WG is

You seem to be assuming this won't get implemented before it gets to 
standards track. Until that time, I suggest you revert the namespace. Or 
make it clear that you intend to use this to create a forward compatible 
revision of Atom.

> been removed.  The mechanism used to remove those items is orthogonal to

Without a mechanism (for delete, sync, undelete, etc), how are we 
supposed to know whether this metadata is useful or well-designed 
outside whatever private application originally needed it? Or how it 
interacts with Atompub operations, or some other protocol? Or what 
happens when there are multiple trash feeds? Or further extended 
metadata? Or where 95% of comments are spam? Or how it interacts with 
DELETE/POST? Or whether it can be used for dead letter queuing?

In other posts you've suggested you need something just like this, so 
let me suggest if you have a mechanism or a technical reason, at least 
document it as an example.

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Thu, 03 Jan 2008 10:29:42 -0800

Hmmm... while your opinion is definitely noted, what you personally
think it means doesn't really matter in this case.  I could be
misreading things, but per BCP92, it's actually up to the AD and IESG to
decide whether or not it is appropriate for an individual submission to
update Atom in this way, especially given that RFC 4287 does not define
what a "forwards compatible revision" is or how such revisions are defined.

It would likely be good to defer to Lisa's judgement on this point.

- James

---

From: James M Snell <[email-masked]>
Date: Thu, 03 Jan 2008 10:50:52 -0800

> make it clear that you intend to use this to create a forward compatible

Until (and if) it gets to the standards track, the deleted-entry element
is no different than any other unknown extension element an application
may add to a feed; conformant implementations are required to ignore it
and validators will be right to point it out as a validation error.

I will update the draft to make it clearer that the intent is to update
RFC 4287.

> document it as an example.

I may just be being a bit too obtuse here but I'm really not following
this at all.  The tombstone is nothing more than a flag that indicates
that an entry has been removed from a feed.  Why or how it has been
removed is inconsequential.  The element identifies which entry was
removed and optionally specifies who removed it, when it was removed,
and provides the ability to specify a comment explaining the deletion.

If we're talking about an Atompub collection, whenever an item is
deleted, a tombstone may be added to the feed and/or the item may be
moved to a trash feed.  I'm not sure what else there is to say about it.

I cannot imagine a case where a feed will have multiple trash feeds but
I cannot rule it out either.  For now, it would likely be best to simply
leave that bit undefined until it actually becomes an issue.

The deleted-entry element is designed to be extensible so if additional
metadata is required, it can be easily added.  The elements that are
there currently represent what my research has indicated to be a lowest
common denominator across applications.

There could be many ways tombstones are used.  For instance, if a paged
feed as a high rate of deletions, rather than letting tombstones
accumulate ad infinitum, the implementation may decide to only list the
most recent deletions in the first ("current") page.  Clients that only
periodically check the feed may miss a few tombstones now and then but
they're also just as likely to have missed the entry that had been deleted.

- James

---

From: Peter Keane <[email-masked]>
Date: Thu, 3 Jan 2008 13:26:52 -0600 (CST)

On Thu, 3 Jan 2008, James M Snell wrote:
[snip]
> leave that bit undefined until it actually becomes an issue.

I suspect there are lots of potential use cases for multiple 
"trash/removed/storage" feeds in the digital library/archives space, so I 
think it'd be best to address that issue. (Either prohibit multiple or 
make them 'type-able').

> most recent deletions in the first ("current") page.  Clients that only

Something like a "time-to-live" mechanism for tombstones could be 
warranted, perhaps.  OAI-PMH defines that per "feed" (a repository has a 
deletion policy), but you could easily do it per tombstone as well. Hmmm 
-- come to think of it, maybe tombstone ttl policy *should* be defined at 
the feed level.

---

From: Bill de hOra <[email-masked]>
Date: Thu, 03 Jan 2008 20:35:40 +0000

> and validators will be right to point it out as a validation error.

[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 
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

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.

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Thu, 03 Jan 2008 13:37:15 -0800

> 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.

> 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

---

From: Peter Keane <[email-masked]>
Date: Thu, 3 Jan 2008 16:10:14 -0600 (CST)

>   broad and growing number of extension namespaces.

I don't mean to kick a sleeping dog, but it seems like the ideal way to 
keep delete capability (agreed that it's broadly applicable) in the Atom 
namespace is for tombstones to be atom:entry and "marked-for-deletion" to 
be an atom:category.

--peter keane

---

From: Eric Scheid <[email-masked]>
Date: Fri, 04 Jan 2008 13:53:50 +1100

> moved to a trash feed.  I'm not sure what else there is to say about it.

why not a separate feed of tombstones, with each tombstone linking to the
respective edit resource?

I can see that might be useful: if you don't want to clutter your normal
feed with tombstones, and you don't want to reveal the *content* (even just
the title/author) of deleted entries (except to those that have appropriate
access privileges), but you do want to make available a list of which
entries should be deleted.

So .. for minimal tombstone elements alone, would they support a <link
rel="edit" /> child element?

e.

---

From: Eric Scheid <[email-masked]>
Date: Fri, 04 Jan 2008 13:56:23 +1100

> think it'd be best to address that issue. (Either prohibit multiple or

speaking of "removed" ... while possible, is it intended that tombstones
would be used for the use case of moving an entry *out* of one feed, and
placing it into a different feed? (eg. if miscategorised)

e.

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 4 Jan 2008 13:25:06 -0800

>>>>> The rfc-editor should have picked this up.

Since it's just an Internet-Draft, neither IANA nor the RFC Editor  
have had a chance to review the proposed namespace.  I'm not involved  
officially either because I haven't been asked to sponsor this, nor  
is it a work item of a WG I advise.

>> and validators will be right to point it out as a validation error.

I still read the list, though often a few days behind.  My  
(individual hat on) guess at interpreting the phrase "future forward- 
compatible revisions" is that the authors preferred to limit the core  
namespace to core features and not to optional extensions; otherwise  
there would be text about use by standards-track vs. Informational or  
Experimental extensions (or even non-IETF extensions).

I am not on call here to make a final decision as the document's  
still a draft.  But if it fell to me to decide due to lack of a WG,  
I'd check the intent with the authors and see if consensus could be  
gauged on this mailing list.  Lack of clear consensus or somebody  
responsible to gauge consensus (a WG chair) might well stall  
documents like this one over any open issue.

BTW, Informational RFCs extending Atom can get published through the  
RFC Editor as Independent submissions without IETF review (and the  
disclaimer indicates these are not IETF documents), again because  
there's no WG for the independent work to conflict with.  Such  
independent submissions could not update or revise the Atom RFC and  
thus I'm fairly confident those documents could not use the Atom core  
namespace.

Lisa

[.] As an even more pedantic digression, the word "updates", as in  
"this draft updates RFC4287", has been the cause of Talmudic debate  
in the IESG and elsewhere.  It's used sometimes to indicate that a  
draft describes an extension to a previous document, even when the  
extension is completely optional.  Other extensions omit the  
"updates" marker on the logic that if an extension is purely  
optional, then it doesn't have to be read in order to implement the  
older spec, and marking the older spec as "udpated by" the newer spec  
merely adds confusion.  I believe there's solid agreement that when a  
new spec makes changes in the behavior of the older spec, then it has  
to use either "updates" or "obsoletes".   Note that RFC2616 is not  
updated by RFC2617, while it is updated by RFC2817, and I haven't  
looked whether there's really solid logic behind that difference in  
treatement.

---

From: "MURATA Makoto (FAMILY Given)" <[email-masked]>
Date: Sat, 05 Jan 2008 11:26:43 +0900

> this in the Atom namespace.

I would argue that attributes block internationalization (e.g., ruby, 
gaiji, and bidi), since attribute values cannot contain subordinate
elements or attributes.

Cheers,

---

From: Bill de hOra <[email-masked]>
Date: Sat, 05 Jan 2008 03:01:44 +0000

>    application cases. That is, it is not application or implementation

That's quite an assertion; I'll assume you can back it up.

>    broad and growing number of extension namespaces.

What issues are those? Seriously, I'd like to know.

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Fri, 04 Jan 2008 21:06:38 -0800

I'm not going to bother. For now, I've updated the draft so that 
deleted-entry is in it's own namespace again and will leave it that way. 
  If/when we can get an Atom Extensions WG going we can revisit the 
issue of how and when it is appropriate to add new elements/attributes 
to the Atom namespace.

- James

---

From: Bill de hOra <[email-masked]>
Date: Sat, 05 Jan 2008 17:33:01 +0000

Sorry to hear you're not going to bother; irregardless of my opinion on 
this particular extension, it could matter a lot, as supporting 
extension namespaces gets to the heart of how Atom was designed. 
Particularly I wanted to know if it was physically due to having 
multiple namespaces*, inconsistency in extension semantics, or both.

cheers
Bill

* for example, I've seen one issue with the XHTML namespace and how 
firefox renders an Atom document.

James M Snell wrote:
>  If/when we can get an Atom Extensions WG going we can revisit the issue 
> of how and when it is appropriate to add new elements/attributes to the 
> Atom namespace.
> 
> - James
> 
> Bill de hOra wrote:
>>
>> James M Snell wrote:
>>> Bill de hOra wrote:
>>>> [snip]
>>>>
>>>> [cc'd to the AD]
>>>>

---

From: James M Snell <[email-masked]>
Date: Sat, 05 Jan 2008 10:46:23 -0800

Don't get me wrong, I *want* to get these issues resolved, I just don't 
think we'll have much hope of coming to a reasonable consensus of many 
of these issues until we can get a WG going.

- James

Bill de hOra wrote:
>> deleted-entry is in it's own namespace again and will leave it that 
>> way.  If/when we can get an Atom Extensions WG going we can revisit 
>> the issue of how and when it is appropriate to add new 
>> elements/attributes to the Atom namespace.
>>
>> - James
>>
>> Bill de hOra wrote:
>>>
>>> James M Snell wrote:
>>>> Bill de hOra wrote:
>>>>> [snip]
>>>>>
>>>>> [cc'd to the AD]
>>>>>

---

From: "MURATA Makoto (FAMILY Given)" <[email-masked]>
Date: Sun, 06 Jan 2008 07:51:35 +0900

> of these issues until we can get a WG going.

Then, is the new WG expected to establish guidelines for atom extensions ?
I believe that such guidelines would be very useful.

Cheers,

---

From: James M Snell <[email-masked]>
Date: Sat, 05 Jan 2008 16:47:15 -0800

Best Practices, perhaps. I'm not so sure about guidelines.  At the very 
least, a new WG will need to clarify exactly how, when and why new 
elements are added to the Atom NS vs. created in their own namespace.

- James

---

From: Peter Keane <[email-masked]>
Date: Sat, 5 Jan 2008 20:15:02 -0600 (CST)

Is there some expectation that the proposed WG would estabish a new "Atom 
Extensions" namespace? Or simply that extension would get a thumbs up or 
thumbs down to be in the Atom namespace?

--peter keane

On Sat, 5 Jan 2008, James M Snell wrote:

> least, a new WG will need to clarify exactly how, when and why new elements 
> are added to the Atom NS vs. created in their own namespace.
>
> - James
>
>>> think we'll have much hope of coming to a reasonable consensus of many of 
>>> these issues until we can get a WG going.
>>

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 7 Jan 2008 11:21:29 +1100

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.

---

From: Bill de hOra <[email-masked]>
Date: Mon, 07 Jan 2008 00:46:59 +0000

Mark Nottingham wrote:
>> 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
> 1) Future RFCs that completely replace RFC4287 are the only ones allowed 
> to add new elements and attributes.
> 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).
> 
> do is to copy RFC4287, add a section on tombstones, and push it through 
> the process. That seems pointlessly tortured, to say the least.
> 

If there's a good technical or social reason to put tombstones into the 
atom namespace, let's hear it.

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Sun, 06 Jan 2008 16:56:54 -0800

Let's forget about the tombstone draft for a minute. If there are good 
technical and social reasons to add any elements or attributes to the 
Atom namespace, what would they be?

- James

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 7 Jan 2008 12:11:08 +1100

On 07/01/2008, at 11:46 AM, Bill de hOra wrote:

>> 2) Future RFCs that update RFC4287 are allowed to add new elements  
>> and attributes.
>> 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  
>> 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,

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 7 Jan 2008 10:42:22 +0100

What really can pollute a namespace are implementations of drafts  
that never made it to RFC. If atom namespace is used for experimental  
extensions, we are in danger of ending up with implementations "out  
there" that misinterpret what the final RFC will say. *)

So, I think it is wise to publish all extensions in an own namespace  
and switch that to atom (if desired) when the RFC gets final. James  
proposal of a WG (or this mailing list for all practical purposes),  
should then decide what to migrate to atom namespace and what not, so  
that the terminology inside atom remains consistent and good to  
understand.

//Stefan

*) Given the time periods necessary for pushing a spec to RFC, this  
is more likely than not. If you really need a feature in your  
product, you will ship implementations based on pre-drafts. And later  
on you need to talk to these implementations...

(Just catching up on mail after vacation, so please excuse if I have  
overreaad something.)

Am 07.01.2008 um 02:11 schrieb Mark Nottingham:

>>>> revisions of Atom. Future versions of this specification could  
>>>> add new elements and attributes to the Atom markup vocabulary
>>> 2) Future RFCs that update RFC4287 are allowed to add new  
>>> elements and attributes.
>>> 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  
>> 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.
>
> 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,
>
>
>
> --

--
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782

---

From: James M Snell <[email-masked]>
Date: Mon, 07 Jan 2008 07:09:24 -0800

So long as the process for how an extension becomes part of the core 
namespace is clear and unambiguous, this is perfectly fine.

- James

Stefan Eissing wrote:
> [snip]
> So, I think it is wise to publish all extensions in an own namespace and 
> switch that to atom (if desired) when the RFC gets final. James proposal 
> of a WG (or this mailing list for all practical purposes), should then 
> decide what to migrate to atom namespace and what not, so that the 
> terminology inside atom remains consistent and good to understand.
> 
> //Stefan
> [snip]

---

From: Bill de hOra <[email-masked]>
Date: Mon, 07 Jan 2008 15:46:09 +0000

They would be whatever the IETF agreed them to be. But I'm not sure this 
is fruitful - trying to predict criteria to add markup to the Atom 
namespace in advance of the markup existing isn't the same as evaluating 
specific markup. I can imagine a situation where no new markup needs to 
be added to the Atom ns, exactly because of Atom's extension model 
doesn't require any processor to understand it. That's not the same as 
saying it's entirely arbitrary, nor is it arguing that nothing should 
ever be added to the ns.

cheers
Bill

---

From: Bill de hOra <[email-masked]>
Date: Mon, 07 Jan 2008 15:32:55 +0000

Mark Nottingham wrote:
> want people to walk away thinking that *no* extension can be in the atom 
> namespace. 

Completely understand; that's not my intention. Btw, there's a 3rd way 
to read the extensibility text - any RFC that adds names to the Atom 
namespace automatically updates RFC4287.

cheers
Bill