Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-10.txt

[Julian Reschke <[e-mail]>]

On 2015-01-10 20:45, Rifaat Shekh-Yusef wrote:
> Hi,
>
> We think that with version -10 we have addressed all the comments we
> received so far.
> Please, take a look and let us know if we missed anything or if you have
> any further comments.
>
> Thanks,
>   Rifaat
> ...

I had a quick glance at the I18N related stuff, and it still doesn't work.

Section 3.1:

    Some or all of the parameters used in the various headers fields used
    by this document can be sent using the [RFC5987] encoding.

That's not really helpful. You really need to state which.

Section 3.9.2:


    The following example assumes that an access protected document is
    being requested from the server via a GET request.  The URI for the
    request is "http://api.example.org/doe.json".  Both client and server
    know the userhash of the username, support the UTF-8 character
    encoding scheme, and use the SHA-512-256 algorithm.  The username for
    the request is "Jaesoen Doe" and the password is "Secret, or not?".
    The following example assumes that an access protected document is
    being requested from the server via a GET request.  The URI for the
    request is "http://api.example.org/doe.json".  Both client and server
    know the userhash of the username, support the UTF-8 character
    encoding scheme, and use the SHA-512-256 algorithm.  The username for
    the request is "Jaesoen Doe" and the password is "Secret, or not?".

The intent was to use a user name containing non-ASCII characters, but 
that was helpfully (:-) converted away by xml2rfc. Non-ASCII examples in 
IETF docs are currently hard. See 
<http://greenbytes.de/tech/webdav/draft-ietf-httpauth-basicauth-update-latest.html#charset> 
for an example how to workaround that limitation.


Section 4:

    The only allowed value is "UTF-8", to be matched case-insensitively
    (see [RFC2978], Section 2.3).  It indicates that the server expects
    user name and password to be converted to Unicode Normalization Form
    C ("NFC", see Section 3 of [RFC5198]) and to be encoded into octets
    using the UTF-8 character encoding scheme ([RFC3629]), ), and percent
    escaped in extended notation ([RFC5987]).

I don't believe RFC 5987 applies here at all; but maybe I'm missing 
something.


Best regards, Julian