Regarding Draft protocol-10
Section 10.1 of draft-protocol-10 explains briefly how paging should be supported by Collections. This section seems to have not been widely discussed (at least I couldn't find links to that subject) and I wonder if all the different perspectives have been taken into account.
Alternatively, Mark Nottingham has built an comprehensive proposal on that matter in: http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed-history-07.txt
I believe therefore we ought to consider the replacement of section 10.1 by a pointer to Mark's proposal which hopefully will become an accepted standard soon.
Replace section 10.1 as follow:
10.1 Collection Paging Collections can contain large numbers of resources. A naive client such as a web spider or web browser could be overwhelmed if the response to a GET contained every entry in the Collection, and the server would waste large amounts of bandwidth and processing time on clients unable to handle the response. For this reason, servers MAY return a partial listing of the most recently updated Member Resources. The returned Atom Feed MAY NOT contain entries for all the Members in a Collection. Instead, the Atom Feed document MAY contain link elements with "rel" attribute values of "next", "previous", "first" and "last" that can be used to navigate through the complete set of matching entries as defined in section 3. of RFC####.
You may argue that there is little improvement at first sight but I believe there would be a greater flexibility that way and also a much better definition for Feed paging.
Considering the fcat section 3 of Mark's draft follow the same naming as section 10.1 of APP-10 the impact should be almost none while providing a stronger definition of how to page collections.
This would of course require Mark's draft to be standardized before APP which is a risk to manage.