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

[Julian Reschke <[e-mail]>]

On 2014-12-03 18:12, Michael Sweet wrote:
> 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.

It is. But we can't make new normative requirements that will break 
existing implementations.

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

I disagree.

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

But that makes it sound as if servers have to use the parameter, which 
is not true.

> ...

Best regards, Julian