Hi Peter,
On 07/03/2014 18:02, Peter Saint-Andre wrote:
As promised at IETF 89, I have compared the username definitions from
draft-oiwa-precis-httpauthprep-00 and
draft-ietf-precis-saslprepbis-06, with the purpose of perhaps
harmonizing the two approaches so that we can avoid multiplying PRECIS
profiles beyond necessity.
(I am writing this email on the flight home, and I neglected to load
up the meeting minutes before leaving, so I might not address all of
the relevant points in this message.)
First, let's look at the syntax definitions.
draft-ietf-precis-saslprepbis-06 states that a username can (a)
consist of one of more userparts, or (b) can be of the form
userpart@domainpart. The ABNF definition is:
username = userpart [1*(1*SP userpart)]
/ userpart ’@’ domainpart
userpart = 1*(idpoint)
domainpart = IP-literal / IPv4address / ifqdn
ifqdn = 1*1023(domainpoint)
Where:
* an "idpoint" is a UTF-8 encoded Unicode code point that conforms to
the PRECIS "IdentifierClass"
* an "IPv4address" is as defined in RFC 3986
* an "IP-literal" is as defined in RFC 3986
* a "domainpoint" is a UTF-8 encoded Unicode code point that conforms
to RFC 5890
By contrast, draft-oiwa-precis-httpauthprep states that a username
consists of one or more UTF-8 encoded Unicode code points that conform
to the PRECIS "IdentifierClass". The ABNF definition is:
userpart = 1*(idpoint)
We quickly see that an http-auth username is a legal PRECIS username,
since 1*(idpoint) is simply a userpart as defined in
draft-ietf-precis-saslprepbis-06, and a PRECIS username can consist of
only one userpart. Therefore, in this respect, I think the
httpauthprep text (whether it appears in a standalone document or
elsewhere) can simply state that for purposes of HTTP authentication a
username is a userpart as defined in draft-ietf-precis-saslprepbis.
Agreed.
Second, let's look at the string preparation method.
Here, too, draft-oiwa-precis-httpauthprep-00 is a subset of
draft-ietf-precis-saslprepbis-06. The preparation method in
draft-ietf-precis-saslprepbis-06 is:
1. The base string class is the "IdentifierClass" specified in
[I-D.ietf-precis-framework].
2. Fullwidth and halfwidth characters MUST be mapped to their
decomposition equivalents.
3. So-called additional mappings MAY be applied, such as those
defined in [I-D.ietf-precis-mappings].
4. Uppercase and titlecase characters might be mapped to their
lowercase equivalents (see Section 4.2.1 below).
5. Unicode Normalization Form C (NFC) MUST be applied to all
characters.
By contrast, the preparation method in
draft-oiwa-precis-httpauthprep-00 is:
1. Fullwidth and halfwidth characters MUST be mapped to their
decomposition equivalents.
2. Additional mappings SHOULD NOT be applied, such as those defined
in [I-D.ietf-precis-mappings], unless there are implementation-
dependent reasons to do so, or these are exceptionally required
by specific authentication schemes.
3. Case mapping is not applied.
4. Unicode Normalization Form C (NFC) MUST be applied to all
characters.o
These two defnitions agree on the width mapping and normalization
rules described in the PRECIS framework. They appear to differ
slightly with regard to the additional mapping and case mapping rules.
However, draft-oiwa-precis-httpauthprep-00 is merely a bit more
restrictive with regard to matters that are purely optional according
to draft-ietf-precis-saslprepbis-06. For example, the option of saying
that "case mapping is not applied" is allowed by the text "uppercase
and titlecase characters might be mapped to their lowercase equivalents".
To make this clearer, I suggest that we modify the advice in
draft-oiwa-precis-httpauthprep-00 so that it no longer defines its own
PRECIS profile. Instead, I suggest that we phrase the httpauthprep
text in terms of the username profile in
draft-ietf-precis-saslprepbis-06. To my mind, something like this
would work:
###
For the purposes of HTTP authentication, a username conforms to the
syntax definition and preparation methods specified in
[I.D-draft-ietf-precis-saslprepbis], with the following limitations:
* a username conforms to the "userpart" construction from
[I-D.draft-ietf-precis-saslprepbis]
* case mapping is not applied
* delimiter mappings, special mappings, and other so-called additional
mappings [I-D.draft-ietf-precis-mappings] are not applied
###
I agree with your proposal.
As far as I can see, this simplifies the httpautheprep text quite a bit.
(By the way, draft-oiwa-precis-httpauthprep-00 also seems to copy the
password profile verbatim from draft-ietf-precis-saslprepbis. I think
this text can be removed entirely, so that the httpauthprep text can
simply reference draft-ietf-precis-saslprepbis.)
I agree. I don't see there is a reason to have a separate profile for
HTTP passwords.
Yutaka and Alexey (and others), let me know what you think about what
I have written here.
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
