Where the ReSTful AtomPub spec is more stringent than AtomPub, we need to be explict about why.

There are a few examples where we've turned a MAY requirement into a SHOULD or otherwise in the ReSTful AtomPub binding. When this happens we should explicitly call it out and identify why it was done. Here are those I'm aware of - and I specifically filed CMIS-263 about the Auth one.

From 2.5,
CMIS server implementations SHOULD support E-Tags.

From 4.1, bullet #6,
A feed SHOULD contain the element app:collection element

Section 4.1
bullet #5 Link with relation self MUST be generated to return the URI of the feed

Section 4.2
5 (a) i The src attribute SHOULD be used to point to the content
5 (a) ii The repository SHOULD populate the summary tag with text that at best efforts represents the documents.

Section 5 has many MUST requirements.

Section 6.
These are the collections that must be defined in a CMIS-compliant service document. – We should choose another word or use MUST.

7.3.2
CMIS repositories MUST be compliant with RFC5023 for POSTing new entries into a collection.

The repository MUST follow HTTP specification and return the following HTTP codes:

8.7.1
It is RECOMMENDED that HTTP Range requests are supported on this resource. It is RECOMMENDED that HTTP compression is also supported.