The Atom Publishing Protocol
Note: This ballot was opened for revision 17 and is now closed.
(Lisa Dusseault) Yes
(Jari Arkko) No Objection
Comment (2007-06-07 for -)
Review from Christian Vogt: This I-D specifies a simple, HTTP-based protocol for publishing and editing data on the Web. I did not find any technical nits with this protocol, which is good. Two substantial editorial comments, though: (2) The Terminology section includes circular definitions, which actually makes some definitions completely useless. For instance, a "resource" is defined in terms of "resources" and "member resource". A "member resource, in turn, is a "resource" with special properties... (1) The document has no introduction. (The text in the Introduction section does not suffice in this regard.)
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Lars Eggert) No Objection
(Sam Hartman) (was Discuss) No Objection
(Russ Housley) (was Discuss) No Objection
(Cullen Jennings) (was Discuss, No Objection, Discuss) No Objection
I have no idea how to implement the statement "It is RECOMMENDED that clients be implemented in such a way that new authentication schemes can be deployed". Requiring TLS+Basic is going to make it much harder for some embedded devices to support this protocol. Did the WG include designers of such systems and did they feel that TLS+Basic was better than HTTP Digest for clients?
(Chris Newman) (was Discuss, No Objection) No Objection
While I'm deferring to my co-AD who is more of an expert on HTTP issues than I am, I'm concerned by the fact this protocol runs over port 80 by default. The litmus test in BCP 57 section 3 for reuse of port 80 is murky for this protocol (the first bullet is probably acceptable, but I'm unsure of the second and third bullets). Do organizations that punch a hole in their firewall for port 80 always intend to have atom publishing occurring? Let me explain why I care about this issue. In the email world, a large number of SMTP servers with dubious security properties were widely deployed. As a result, the network security community decided to run application-level firewalls on port 25. Such proxies are the most common cause of interoperability problems with SMTP, especially with respect to options negotiation and in particular they often defeat SMTP-level security features such as STARTTLS. Furthermore, port 25 is now widely used for submission of spam, something that was not considered at the time the protocol was designed. The email community has been trying to separate submission from transfer with port 587 so that separate security policies can be applied to transfer and submission easily. While this has had some success, it is very difficult to introduce a new port later, but it's not difficult to say "MUST try port X first, but feel free to use port 80 as a fallback" when the protocol is first deployed. I'm concerned that the extensive reuse of port 80 could lead to the widespread deployment of disruptive application-level proxies that could negatively impact all protocols on port 80. Hopefully I'm wrong that this is the likely outcome of the present reuse-port-80 trend, but my concern is informed by past experience with port 25.