Note that Salmon (http://salmon-protocol.org) also needs standalone (signed) deleted entry documents. Its security model allows for changing of keysm -- e.g., if the original was compromised -- as long as both keys are bound to the same author/uri.
On Wed, May 19, 2010 at 8:36 PM, Bob Wyman <[email protected]> wrote: > James Snell <[email protected]> wrote: > > As for standalone deleted entry documents... > > the key question is > > whether they are compelling. > > An example... "Atom over > XMPP<http://xmpp.org/internet-drafts/draft-saintandre-atompub-notify-07.html>" > calls for publishing streams of Atom Entry Documents over XMPP. Because > there was no mechanism defined for deleting in Atom itself, "Atom over XMPP" > ended up defining a "retract" message for that purpose. It would be more > natural to use a tombstone. > > But, the general question is: Atom format permits my application to publish > only Entry Documents. However, if I do that, and if a delete-entry can only > exist as an element of a Feed Document, how do I tell anyone about a > deleted-entry? Would I need to modify my protocol to support Feed Documents > simply as a means to transport deleted-entries? Doesn't seem right. > > bob wyman > > On Wed, May 19, 2010 at 11:17 PM, James Snell <[email protected]> wrote: > >> Heh, Bob... you and I seriously need to get into the same room with a >> whiteboard sometime.. lol.. >> >> Ok, first about your previous comment about atom:source... yes, the >> intention is for it to be identical to the use within atom:entry so I >> will tighten that up in the spec... >> >> As for standalone deleted entry documents... I definitely can think of >> a few generally interesting potential use cases... the key question is >> whether they are compelling. >> >> - James >> >> On Wed, May 19, 2010 at 7:58 PM, Bob Wyman <[email protected]> wrote: >> > In Atom, both Entry Documents and Feed Documents are "top-level" >> objects. An >> > entry may be contained within a Feed Document, but it need not be. This >> is >> > an important characteristic of Atom and one that distinguishes it from >> > previous, legacy syndication formats. This attribute of Atom makes it >> > particularly well suited for use in applications that rely on combining >> > entries from multiple sources as well as applications that provide >> real-time >> > delivery of data. >> > However, the deleted-entry that you define in the tombstone draft is >> defined >> > as only existing within Feed Documents. This represents a significant >> and >> > unfortunate departure from the base Atom RFC. >> > I would strongly encourage you to ensure that deleted-entry is >> symmetrical >> > with atom:entry and that it is available in all contexts (i.e. both >> within >> > and without a Feed Document) that an Atom entry is. Just as we can have >> > Entry Documents, we should be able to have Deleted-entry Documents. >> > bob wyman >> > On Wed, May 19, 2010 at 2:10 AM, James Snell <[email protected]> wrote: >> >> >> >> Another backwards compatible update... explicitly allowing for an >> >> optional atom:source element as a child of at:deleted-entry. >> >> >> >> >> http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-08.txt >> >> >> >> - James >> >> >> > >> > >> >> >> >> -- >> - James Snell >> http://www.snellspace.com >> [email protected] >> > >
