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

[Michael Sweet <[e-mail]>]

Julian,

> On Dec 3, 2014, at 11:24 AM, Julian Reschke <[e-mail]> wrote:
> 
> 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.

OK, I was under the impression that one of the motivations for updating RFC 2617 was to address I18N issues.

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

Typically MAY is used in conjunction with OPTIONAL; from RFC 2119:

   5. MAY  This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

Since the purpose is to indicate that servers will include the "charset" parameter to tell the client about the expected character encoding, something that is present specifically for interoperability with Unicode user IDs and passwords, I think that "MAY" is the right word to use here instead of its non-conformance synonym "can".

Alternately just drop "can" with no replacement, e.g.:

   In challenges, servers use the "charset" authentication parameter
   to indicate the character encoding scheme they expect the user agent
   to use when generating "user-pass" (a sequence of octets).  This
   information is purely advisory.

That avoids the whole consistency issues and makes it clear that the "charset" parameter is the one and only way of specifying the character encoding of the userid and password.

(I realize I'm being anal about this, but having spent the better part of 20 years writing/editing/reviewing technical documents and standards, I have seen a number of truly shocking misinterpretations of otherwise clear text...  "Weasel words" like "can" are often problematic...)

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

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair