1. Done - There is no example illustrating the creation of a media-resource/media-link-entry pair, and there should be. Editors: please add one.

  2. Done - It was not clear to Lisa that creation of a media resource *always* results in the creation of a media link entry. This should be made clear. Editors: please clarify.

  3. Done - Lisa asked for clarification of division of responsibility. This is a key point; I think that the WG members have internalized the assumption that the server is in control so deeply that we neglected to write it down. The introductory sections of the spec need some language making it clear that in general, this specification imposes very few de jure restrictions on the actions of an APP server, and that servers can be expected to vary wildly in those aspects of the problem that are not explicitly specified in this specification; if it's not here in the APP spec, clients can't count on it. Editors: introductory text, please.

  4. Done- There are several places where Lisa highlights undefined behavior; for example, what happens if you POST to a member URI. The spec would be improved by, in some cases, explicitly calling out the fact that certain cases are left undefined (as we do with posting non-entry docs from the Atom namespace). The spec would also benefit from introductory material making it very clear that since all aspects of APP interaction are in terms of HTTP, RFC 2616 should be consulted for any areas not covered in the APP spec. Editors: Please fill obvious gaps and add some introductory text.

  5. Done - We need an example of updating the bits in a Media Resource, and the related metadata in a Media Link Entry. Editors: example, please.

  6. Done - We should note that the APP currently does not have support for content-negotiation; as in, there's no way to give a server multiple different representations (e.g. a jpg and a png) for the same resource. Editors: please add this.

  7. Lisa asks whether we still need to have the text requiring the Content-Location to be present and identical to the Location, and Snell ( points out that the simplification around PaceMemberOnly means this is probably no longer required. Lisa points out correctly that this is going to bother implementors because they won't know why it's there, nor in what circumstances two different URIs might be provided. Editors: please remove this unless there is squawking very soon. (Thomas Broyer squawked on Nov 26). Because of the squawking I added text that clarifies that this is a slightly tighter interpretation than RFC 2616 seems to allow by default.

  8. Done Lisa asks: Can the client change the atom:id? In previous discussion, the WG has failed to achieve consensus on what language would be appropriate in discussing this issue. My assumption is that nothing has changed, but it is a reasonable question. Editors: no-op, unless someone has a flash of brilliance.

  9. Done Lisa complains, as have others, that the collection paging specification leaves some questions unanswered. I think the WG is unlikely to agree to improved wording on this one. Editors: no-op unless brilliance.

  10. Done - Lisa complains, as have others, that "workspaces" are underdefined, in that implementors will worry that there are semantics there that they're somehow missing. The spec should make it clear that these carry no semantics whatsoever, and are provided only as a way of providing groups of collections with human-readable names. Editors: please enhance language.

  11. Done - Lisa and others (e.g. Nottingham mail-archive/msg07516.html) argue that there is a possible but not necessary distinction between subscription feeds and collection feeds. Nothing further needs be specified (I think the WG is unlikely to achieve consensus on a new link relation) but the spec needs to acknowledge this issue and confirm people's suspicions that they *might* be the same feeds, but need not be. Editors: please add this.

  12. "Collections that indicate the set is open SHOUDL NOT reject otherwise..." I found this a little bit confusing, I think because there's an assumed condition that the element occurs in a collection document, when this section is about category documents. won't fix

  13. Done - - "The app:control element is considered..." Is this a cut and paste error? I.e., should it be app:collection?

  14. Done - Need to add something about not restricting the URI space of the APP. "This RFC does not specify the form of the URIs that are used. The URI space of each server is controlled, as defined by HTTP, by the server alone. What this RFC does specify are the formats of the files that are exchanged and the actions that can be performed on the URIs embedded in those files"

  15. Done - Need to clarify that the spec only covers the entry and media resources and that other resources may be created/updated/deleted as the result of manipulating a collection or its members (i.e. the HTML web pages if this is used to edit a blog).

BillDehora: 20061220