What more does Habari need to complete its AtomPub implementation?

The Habari developers have done a great job getting AtomPub implemented early on. The AtomPub implementation is now error free, according to the APE, but there are still warnings and it is still partially incomplete. As I see things, these are the outstanding issues that I know about, in no particular order. Each of these should probably be entered as a separate issue in the tracker. As I'm not super familiar with the spec, I've probably missed bits that Habari doesn't support. If any of this is wrong, or it's incomplete, or you think my solution is off, please let me know. [I've posted a similar message to habari-dev.]

Atom and AtomPub share a URL

While this works okay, because Habari uses the presence of authentication details to tell the difference between a request for a feed and a request for an AtomPub service document, it relies on the client sending a correct username and password with the initial request. If the client wants a service document and they don't send authentication, they'll get a feed instead of a 401 authentication challenge.
Solution: Provide a separate URL for the service document, probably /atom/service.

PHP as a CGI

When PHP is running as a CGI the HTTP Authorization header is not passed on to the script. Currently this means that authorisation will fail.
Solution: There is a simply (but ugly) workaround that uses mod_rewrite to write variables that the script can read. I have a patch ready for this, but haven't submitted it yet.

Support WSSE authentication

Habari currently supports only HTTP Basic Authentication. Some clients and devices only implement WSSE Authentication, such as the Nokia N73.
Solution: As a proof of concept in the past, I implemented WSSE in WordPress. One slight catch, and the reason it didn't work in WordPress, is that WSSE requires plain text passwords to be retrievable on the server. Are they available in Habari? If so, it should be trivial for me to write a patch.

AtomPub categories support

Atom entries can contain category elements. While Habari doesn't support categories, it does support tags, so categories supplied in an Atom entry should be written as tags on the post.
Solution: I've submitted a patch to do this.

AtomPub draft support

Habari does not currently support the AtomPub protocol provision for a client to send a request for an Atom entry to be considered a draft.
Solution: Detect the app:control element in Atom entries and honour the app:draft setting, where a value of 'yes' means the entry is a draft.

Atom media collection support

Habari does not currently support the upload of media collections.
Solution: This is contingent upon Habari implementing file uploads, and will be slightly more complex than publishing of simple Atom entries because there's a level of indirection between uploaded resources and their Atom entries.

AtomPub summary support

I'm not sure I've got a handle on this one completely. In the section entitled Media Link Entries, the AtomPub spec says, "[RFC4287] specifies that Atom Entries MUST contain an atom:summary element" but the Atom spec clearly says in both the (normative) text and (non-normative) RelaxNG fragments that atom:summary is optional. The Atom spec says, "It is advisable that each atom:entry element contain ... a non-empty atom:summary element when the entry contains no atom:content element." So, given an uploaded media entry, Habari may create a summary element for the media link entry associated with the media entry.
Solution: I don't really see any way of producing a summary automatically. I think the only thing we can do is to support summary elements provided by the client. As file uploads has not yet been implemented, it's trivial to add a summary column when it is.

Support foreign markup delivered by AtomPub

I'm a bit hazy on this one too. The Ape produces a warning when Habari drops a subject element that is a child of the entry element. The relevant section seems to be section 6 of the Atom spec, but it doesn't specifically say that foreign markup should be preserved. Section 6.2 of the AtomPub spec says, "Unrecognized markup in an Atom Publishing Protocol document is considered "foreign markup" [...] Clients SHOULD preserve foreign markup when transmitting such documents." While this isn't talking about servers, it implies foreign markup in legal locations should be preserved. I might be missing a reference here, but it seems to me the spec isn't clear on this point.
Solution: Explore the issue more.

Decouple app:edited and atom:updated

Atom entries can have a client provided atom:updated element. The purpose of this element is to signify that a significant change has been made to the entry. AtomPub provides the app:edited element, which is a server provided timestamp representing the last time that the entry was changed in any way. An AtomPub server can override the atom:updated value and use its own, which Habari currently does. Habari's Post class's updated column is written on all edits and is used to fill app:edited elements.

Solution

: Create an edited column for the Post class, and use this to populate app:edited, and use the client provided atom:updated value (or a timestamp if it isn't provided) to fill the updated column. This would have the side effect that with a small UI change in admin, users could mark things as minor edits, such as fixing typos or adding tags. However, changing Post would also have far-reaching consequences. We could also sort the Atom feed by atom:updated, as this makes semantic sense and order is not mandated in the Atom spec, and still have AtomPub sending in app:edited order.

get_collection and get_entry violate DRY