The Atom "deleted-entry" Element
RFC 6721

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

(Barry Leiba; former steering group member) Yes

Yes ( for -15)
No email
send info

(Pete Resnick; former steering group member) (was Discuss) Yes

Yes ( for -17)
No email
send info

(Peter Saint-Andre; former steering group member) Yes

Yes ( for -)
No email
send info

(Robert Sparks; former steering group member) (was Discuss) Yes

Yes ( for -15)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection (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.

(Benoît Claise; former steering group member) (was Discuss, No Objection) No Objection

No Objection (2012-06-20 for -15)
No email
send info

(Brian Haberman; former steering group member) No Objection

No Objection ( for -15)
No email
send info

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -14)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -14)
No email
send info

(Martin Stiemerling; former steering group member) No Objection

No Objection ( for -15)
No email
send info

(Ralph Droms; former steering group member) No Objection

No Objection ( for -15)
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ( for -14)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ( for -14)
No email
send info

(Sean Turner; former steering group member) No Objection

No Objection (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.

(Stephen Farrell; former steering group member) No Objection

No Objection (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.

(Stewart Bryant; former steering group member) No Objection

No Objection ( for -14)
No email
send info

(Wesley Eddy; former steering group member) No Objection

No Objection ( for -15)
No email
send info