The Atom Publishing Protocol
draft-ietf-atompub-protocol-17

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.

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?

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.)