The Atom "deleted-entry" Element
RFC 6721

Note: This ballot was opened for revision 14 and is now closed.

(Barry Leiba) Yes

(Pete Resnick) (was Discuss) Yes

(Peter Saint-Andre) Yes

(Robert Sparks) (was Discuss) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) (was Discuss, No Objection) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2012-05-21 for -15)
No email
send info
My Comment raised on -14 persists in -15.

I have no objection to the publicaiton of this document. I think that the Introduction could have been more extensive - a good place for citations and explanations.

(Stephen Farrell) No Objection

Comment (2012-02-24 for -14)
No email
send info
1. I didn't really get what's meant by 

"  When an at:deleted-entry element appears in a Feed document other
than it's source Feed or when an at:deleted-entry element that has a
source Feed document is used in the context of a Deleted Entry
Document, it MUST contain an atom:source element."

But I guess Atom developers probably do so that's ok.

2. Last para of section 6: I guess that if someone did MAC and then
symmetrically encrypt one of these (is that as unlikely as I think?)
then it might be useful to tell them not to use the same key for
both.

3. Digital signatures by themselves do not provide non-repudiation.
Please delete that term.

(Brian Haberman) No Objection

(Russ Housley) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

Comment (2012-05-19 for -15)
No email
send info
Most of s5 and s6 are copied from RFC 4287 can't you just point to RFC 4287 for the text?  In both s5 and s6, it's the last 3 paragraphs.  Was the last paragraph of s6 supposed to be titled signing and encrypting like it was in 4287?

I guess this made sense to the atom folks but those blurbs only talk about the processors of the feed, but where is the requirement for the generator of the feed?  It's great to require that only RSA be supported instead of DSA and that AES-128 CBC be the only choice for the processor, but if the generator uses one of the other allowed W3C allowed algs how do you get interop?

Assuming you import the text from RFC 4287 this is probably moot but ... in the following:

   Section 5.1 of [W3C.REC-xmlenc-core-20021210] requires support of
   TripleDES, AES-128, and AES-256.  Processors that decrypt Deleted
   Entry Documents MUST be able to decrypt with AES-128 in Cipher Block
   Chaining (CBC) mode.

What does the second sentence add?  Was it trying to say that processors only have to support AES 128 CBC because it's the only thing that's going to be used?

Nothing to do on this one: I really hate MACs being characterized as signatures.