Comments inline. These are all from the perspective of interoperability.
James M Snell wrote on 7/5/2006, 1:51 PM:
> == Proposal ==
>
> {{{
> 12. Security Considerations
>
> 12.1 Authentication
>
> Implementors are advised to use client authentication mechanisms to
> prevent posting or editing by unknown or unauthorized sources. The type
> of authentication used is a local decision made by the server.
> Accordingly, clients are likely to face authentication schemes that vary
> across implementations.
+1 to the wording above. In addition, I'd really like to see a
reference to RFC 2617 (HTTP Authentication[1]) which defines a standard
framework for authentication negotiation as well as the specific scheme
mentioned below.
Reasoning: At least one Atom client in the wild today doesn't follow
RFC 2617 even to the extent of understanding an 401 Unauthorized
response. The GData protocol doesn't use RFC 2617's WWW-Authenticate:
header (AFAIK). There's a feed client out there using standard HTTP and
RSS/Atom that can't respond to a 401 response at all -- username and
password must be specified in a preferences setting. All of these lead
to problems with interoperability.
A specific pointer in the protocol spec, and a reminder that there are
multiple and extensible authentication schemes even within RFC2617, will
help developers who want to be maximally interoperable while not
interfering with other developers who want to write specialized clients
or servers.
>
> It is suggested but not required that servers utilizing authentication
> mechanisms involving the clear-text transmission of a password (e.g.
> HTTP Basic Authentication) secure the connection using, for example, a
> Transport Layer Security (TLS) connection.
+1 This is a good paragraph to have, not because server developers
necessarily need this information, but because client developers should
be warned about this.
>
> Because this protocol uses HTTP response status codes as the primary
> means of reporting the result of a request, servers are advised to
> respond to unauthorized or unauthenticated requests using an appropriate
> 4xx HTTP response code (e.g. 401 "Unauthorized" or 403 "Forbidden").
This wording is okay but this would be a perfect place to refer to RFC
2617 -- is there some reason not to do so? The examples of specific
response codes are good to have in either case.
[1] http://rfc.net/rfc2617.html
-John
