Re: [http-auth] Working Group Last Call for draft-ietf-httpauth-basicauth-update-03.txt

[Julian Reschke <[e-mail]>]

On 2014-12-03 17:14, Michael Sweet wrote:
> My comments:
>
> - Section 2 makes the "charset" parameter OPTIONAL. I'm wondering if this should be RECOMMENDED in order to encourage adoption of UTF-8 usernames and passwords since that solves common deployment and interop issues.

This being an optional feature has been the intention since we started.

If a server has a use for non-ASCII characters, it has sufficient 
motivation to use it. In the other case, no amount of spec language will 
affect what it does.

> - Section 2.1 uses "can" (servers can use the "charset" authentication parameter...) If "charset" is OPTIONAL in section 2, I think this should be "MAY" (servers MAY use ...), and if RECOMMENDED this should be "SHOULD" (servers SHOULD use ...), although then you'd want to clarify that it is a SHOULD when using UTF-8...

How is "MAY" better than "can"? This is a statement of fact, not an 
interoperability requirement.

> - Section 4 doesn't talk about using TLS/HTTPS, which is a common method for providing some level of protection for the cleartext password in transit.  It might be sufficient to simply expand on "enhancements", e.g.:
>
>     Because Basic authentication involves the cleartext transmission of
>     passwords it SHOULD NOT be used (without enhancements such as HTTPS [RFC2818])
>     to protect sensitive or valuable information.
>
>    with a corresponding informative reference to RFC 2818 in section 7.2.  That at least provides a pointer without endorsing Basic + HTTPS as a "secure" combination...
>

That sounds like a good addition.

Best regards, Julian