Yes, I wanted to be careful about dictating any kind of behavior if the keys ended up being different because there are legitimate reasons why they would be (e.g. if an editor deletes an entry created be a different author). Applications just need to be aware of the potential risks involved. Ironically, the greater risk is deletion with a compromised key.
On Mon, May 24, 2010 at 3:43 PM, John Panzer <[email protected]> wrote: > 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" 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] >> > > -- - James Snell http://www.snellspace.com [email protected]
