The 'Basic' HTTP Authentication Scheme
draft-ietf-httpauth-basicauth-update-07

2: I'd at least like to hear an explanation about why this is unreasonable (if it is):

OLD
   Furthermore, a user-id containing a colon character is invalid, as
   recipients will split the user-pass at the first occurrence of a
   colon character.  Note that many user agents however will accept a
   colon in user-id, thereby producing a user-pass string that
   recipients will likely treat in a way not intended by the user.
NEW
   Furthermore, a user-id MUST NOT contain a colon character, as
   recipients will split the user-pass at the first occurrence of a
   colon character.  Many user agents will accept a colon in user-id,
   but this produces a user-pass string that recipients will likely
   treat in a way not intended by the user.
END

MUST NOT means that not using a colon is required for interoperation. Which is true. So I don't see why you don't come out and say that.

The current text on the use of TLS is an OK start, but I would prefer if it were refactored so that the recommendation against Basic were general to HTTP and HTTPS.  Suggested:

"Because Basic authentication involves the cleartext transmission of passwords it SHOULD NOT be used except over a secure channel such as HTTPS [RFC2818]. Likewise, due to the risk of compromise, Basic authentication SHOULD NOT be used to protect sensitive or valuable information."

Likewise, it would be good to comment in the Security Considerations on the risk of leakage caused by sending an Authorization or Proxy-Authorization preemptively.  Something like:

"As discussed in Section [TODO] above, it is possible for a client to preemptively send a Basic authentication value in an Authorization or Proxy-Authorization header without first having received a challenge.  In such cases, the client does not know whether the resource to which it is sending the Basic authentication value is part of the realm that should receive that value, or even whether the resource requires authentication at all.  This mismatch can cause leakage of client passwords to unauthorized parties, so it is RECOMMENDED that preemptive transmission of Basic authentication values be disabled by default."

Nice job on a specification that is better than the technology it describes (echoing Stephen's ballot)!

I support Pete's No Objection, and have found the responses unconvincing.   I would support this being raised as a DISCUSS rather than a comment, but I'll leave that to Pete.