One additional comment, because of the extension model allowed by the
tombstone, it would also be possible for a publisher to include the
complete atom:entry as a child of the at:deleted-entry to address the
scenarios that Bob has brought up... e.g.
<at:deleted-entry>
...
<atom:entry>
...
</atom:entry>
...
</at:deleted-entry>
- James
On Mon, May 24, 2010 at 3:51 PM, James Snell <[email protected]> wrote:
> 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]
>
--
- James Snell
http://www.snellspace.com
[email protected]
