Proposal: deletion requests

[Ka-Ping Yee]

We have had a few concerns and suggestions about privacy and deletion of data.  I'd like to suggest two additional fields:

1. A "deleted" flag, which is a request to delete the record on receipt.

2. An "expiry_date", which is a request to delete the record automatically at the given date.

Both these fields would persist after deletion so they can propagate to other repositories.

These are merely requests—deletion can't be enforced.  But it is useful to be able to express these requests, so that conforming implementations can honour them.

Any thoughts on this?

—Ping
Google Crisis Response

[Peter Kaminski]

On 10/21/10 08:40 AM, Ka-Ping Yee wrote:

> 1. A "deleted" flag, which is a request to delete the record on receipt.
> 2. An "expiry_date", which is a request to delete the record
> automatically at the given date.

Just brainstorming, without specific examples of use cases:

How about a "delete_if_found" flag?

And given some of the concerns we've seen about deletion, I understand
the need for expunging records. But I wonder if there might be
additional use for a similar but different request: to supersede a
fully-detailed record with a minimal record, perhaps containing just
name and "found" field?

Pete

[Steve Hakusa]

Hi Ping,

A few questions about this proposal.  If "expiry_date" is set, and the time is now after that "expiry_date" then it is implied that "deleted" is also set?  Or, if "deleted" is set, would "expiry_date" be required so that it's possible to know when the record was marked deleted?

I wonder if it would be clearer to have a single "deleted_date" field that could be set to the future if necessary to indicate future expiry.  I was also looking at the at:deleted-entry element in the atom tombstones spec, and thought that might be good to include in the atom feed representations.

http://ietfreport.isoc.org/all-ids/draft-snell-atompub-tombstones-11.txt

Steve

[Ka-Ping Yee]

On Thu, Oct 21, 2010 at 10:35, Steve Hakusa <sha...@google.com> wrote:

A few questions about this proposal.  If "expiry_date" is set, and the time is now after that "expiry_date" then it is implied that "deleted" is also set?  Or, if "deleted" is set, would "expiry_date" be required so that it's possible to know when the record was marked deleted?

I wonder if it would be clearer to have a single "deleted_date" field that could be set to the future if necessary to indicate future expiry.

I like this.  This nicely unifies both of the fields.

Maybe the name "deletion_date" would be better since it can be in the future?

I was also looking at the at:deleted-entry element in the atom tombstones spec, and thought that might be good to include in the atom feed representations.

That sounds reasonable.  Should it be optional or required?

—Ping

[Steve Hakusa]

On Thu, Oct 21, 2010 at 1:56 PM, Ka-Ping Yee <k...@google.com> wrote:

On Thu, Oct 21, 2010 at 10:35, Steve Hakusa <sha...@google.com> wrote:

A few questions about this proposal.  If "expiry_date" is set, and the time is now after that "expiry_date" then it is implied that "deleted" is also set?  Or, if "deleted" is set, would "expiry_date" be required so that it's possible to know when the record was marked deleted?

I wonder if it would be clearer to have a single "deleted_date" field that could be set to the future if necessary to indicate future expiry.

I like this.  This nicely unifies both of the fields.

Maybe the name "deletion_date" would be better since it can be in the future?

Sounds good to me.

 

I was also looking at the at:deleted-entry element in the atom tombstones spec, and thought that might be good to include in the atom feed representations.

That sounds reasonable.  Should it be optional or required?

Hmm.  How painful is it to make it required?  If it's optional, then in the majority case if you wanted to know if  a record was really deleted, you'd have to parse the pfif record in the content element.

 

—Ping

[Ka-Ping Yee]

I was also looking at the at:deleted-entry element in the atom tombstones spec, and thought that might be good to include in the atom feed representations.

That sounds reasonable.  Should it be optional or required?

Hmm.  How painful is it to make it required?  If it's optional, then in the majority case if you wanted to know if  a record was really deleted, you'd have to parse the pfif record in the content element.

I think it's only a small amount of additional work for implementors.  Any implementors want to chime in?

The <at:deleted-entry> element is a separate top-level element, not part of an entry.  (Seems odd to me.)  So if it's required, we just have to carefully specify which tombstones you are required to send.

http://ietfreport.isoc.org/all-ids/draft-snell-atompub-tombstones-11.txt

The semantics of <at:deleted-entry> look different from what you're suggesting for <deletion_date>.  The tombstones spec doesn't say anything about dates in the future, but it does say <at:deleted-entry> "represents an Atom Entry that has been removed" (past tense) rather than scheduled for deletion.

How about "you must include an <at:deleted-entry> element corresponding to each <deletion_date> element that is in the past"?

—Ping

Google Crisis Response

[Steve Hakusa]

That sounds right to me.

 

—Ping

Google Crisis Response