Subject: Re: SASLPrep vs Full Stop code points

From: Ienup Sung <[email-masked]>
Date: Mon, 03 Nov 2003 11:51:56 -0800 (PST)

I agree that the SASLprep is more suitable and applicable for simple
user names and passwords and if the additional mappings such as the full
stops are needed, they are more suitable and correct to be done at
the outside of any Stringprep/Stringprep profiles and most preferrably before
the application of the Stringprep profile(s). <-- These are also my points
all along.

The reasons are like the following that the U+002E (full stop and dot/decimal
point) isn't the same or equivalent to the ideographic/Asian full stops
all the time; if they were, the Unicode itself would define them as
equivalent forms/characters and show canonical/compatiblity decomposition(s)
at each characters so that the Unicode normalizations would normalize
those characters into a (normalized) character.

Also, if everyone would agree on the fact that the ideopgraphic/Asian
full stops are not equivalent to the U+002E and yet we still need to support
the mappings described in the IDNA for the compatibility/interoperability on
the Internet domain style names (only), then, I'm also thinking that everyone
would agree this conditional mappings should be done outside of the Stringprep
and any of the Stringprep profiles (since the Stringprep itself doesn't
really allow conditional mappings at the mapping step as of today even though
a profile *possibly and maybe* could define such conditional mappings).

Re user provided strings, I have the following example that shouldn't match
as the same thing:

	3.14
	３。１４
	3。14

The first one is the pi, three point one four, in ASCII and the second is
three, ideographic full-stop, and fourteen in Asian full-width digit characters
and with ideographic full stop in UTF-8. (The third one is a variation of the
second one, three, ideographic full-stop, and fourteen in ASCII digits and
with ideographic full stop in UTF-8; and the second and the third can be
seen as equivalent.)

With regards,

Ienup

] Date: Fri, 31 Oct 2003 20:52:15 -0800
] From: "Kurt D. Zeilenga" <[email-masked]>
] Subject: Re: SASLPrep vs Full Stop code points
] X-Sender: [email-masked]
] To: Ienup Sung <[email-masked]>
] Cc: [email-masked], [email-masked]
] MIME-version: 1.0
] 
] At 05:42 PM 10/31/2003, Ienup Sung wrote:
] >Regarding the full stops, while I do understand the point of display vs.
] >storage/query string in my opinion, I think the issue boils down onto
] >the followign two things in my view:
] >1. Should/can we treat ideographic/Asian full stops as equivalent characters
] >   of the ASCII full stop (U+002E) in 100% of the possible cases/usages?
] 
] SASLprep is only applicable to two use cases: simple user names and password.
] 
] >   The answer is no since the U+002E is not only a full stop character but
] >   it is also a period and dot/decimal point character; CJK speakers do not 
use
] >   the ideographic/Asian full stops as the dot/decimal point character and
] >   hence some use of the ideographic/Asian full stops rather be preserved as
] >   they are to be distingushed. And in that cases, can we distinguish what to
] >   preserve and what not to preserve and map?
] 
] SASLprep scope is limited to preparation of user input strings for matching.
] Issues such as how to preserving the (unprepared) user input is simply beyond
] our scope as matching and hence SASLprep.
] 
] >2. Should/can we keep the compatiblity with the IDNA's additional and
] >   pre-processing on the label separators, i.e., mappings of all full stops 
to
] >   the U+002E, for the domain style (IDN) names before they are used?
] >   I think the answer should be yes.
] 
] SASLprep can define one preparation algorithm for simple user names and
] passwords.  Simple here implies the input has no structure.  That is,
] names have no particular style in respect to the algorithm.
] 
] It is possible that specification using SASLprep could apply additional
] transformations be done.  However, such transforms are beyond the scope
] of SASLprep.
] 
] >I know the above two sound conflicting and the example shown at the argument
] >#1 could be considered as a case that may not need to be really supported.
] >But I thought presenting them might be a valuable thing to do.
] 
] I would be interested in hearing whether you think the additional suggested
] mapping is appropriate or not for matching of simple user names or passwords,
] and why.
] 
] I think this issue boils down to whether the user provided strings:
]         <STRING1><U+002E><STRING2>
]         <STRING1><U+3003><STRING2>
]         <STRING1><U+FF0E><STRING2>
]         <STRING1><U+FF61><STRING2>
] 
] should match or not.  Because user names are often constructed from domain
] names, and IDNA says these stops are to be treated as equivalent, I believe
] they should match.
] 
] Kurt 
]

---

From: Sam Hartman <[email-masked]>
Date: Thu, 06 Nov 2003 16:35:13 -0500

>>>>> "Ienup" == Ienup Sung <[email-masked]> writes:

    Ienup> I agree that the SASLprep is more suitable and applicable
    Ienup> for simple user names and passwords and if the additional
    Ienup> mappings such as the full stops are needed, they are more
    Ienup> suitable and correct to be done at the outside of any
    Ienup> Stringprep/Stringprep profiles and most preferrably before
    Ienup> the application of the Stringprep profile(s). <-- These are
    Ienup> also my points all along.

I think Kurt's point was that since saslprep was for usernames and
passwords, it is more appropriate to do full-stop mappings there than
in some more general context.  Do we expect people to need decimal
points in their usernames?  Do we think it a problem if someone uses a
decimal point in a password, but can later use one of the other
full-stop characters and have it work?

--Sam

---

From: Lyndon Nerenberg <[email-masked]>
Date: Thu, 06 Nov 2003 15:37:32 -0700

> points in their usernames?

firstname.lastname is a very common scheme for forming identifiers, so yes 
we do need to support decimal points (and their equivalent mappings) in 
usernames.

--lyndon

---

From: Sam Hartman <[email-masked]>
Date: Thu, 06 Nov 2003 17:56:57 -0500

>>>>> "Lyndon" == Lyndon Nerenberg <[email-masked]> writes:

    Lyndon> firstname.lastname is a very common scheme for forming
    Lyndon> identifiers, so yes we do need to support decimal points
    Lyndon> (and their equivalent mappings) in usernames.
But it seems like in this case mapping all the full stops together
would be desirable.