Subject: Re: [precis] PRECIS profiles appear underspecified

From: Dan Chiba <[email-masked]>
Date: Mon, 25 Aug 2014 18:31:05 -0700

Hello,

I am Dan Chiba at Oracle. We are interested in PRECIS as a key 
technology for i18n and we have one question that we would like to address.

The question is regarding the way the applications identify a profile 
that has variants in character mappings. In particular, 
UsernameIdentifierClass can be case insensitive or sensitive, or there 
could be various ways to perform character mapping during the 
preparation process. Right now, the drafts (links at the bottom of this 
message) do not seem to define how to specify particular mappings 
applied to the profile. This means that practically the framework 
implementations would have to define the identification scheme on their 
own, and then applications can suffer from inconsistent results for the 
same profile, unless they somehow ensure they get the same expected 
behavior consistently from all profile implementations they are 
depending on.

In other words, the profile name "UsernameIdentifierClass" alone does 
not identify the preparation or comparison rules precisely enough. For 
example, let's consider an identity management service specified the 
value space for the username to conform to "UsernameIdentifierClass" and 
an application that consumes the service and performs preparation using 
the "UsernameIdentifierClass" profile against the username requested by 
the user when creating a new user account and checks whether the 
requested name is available or taken. If the profile implementations 
behaved inconsistently, the application would not be able to produce the 
desired behavior. Say, one of them is case insensitive and the other is 
case sensitive, then the application behavior would be unpredictable 
unless the framework provides a mechanism to make the processing result 
predictable.

A simple way to address this point may be to allow applications to 
identify the complete set of rules with an identifier. If the identifier 
is the same, the output string for a given string should be predictable 
and consistent, no matter what implementation is used to process the 
string. For example, the Unicode default case folding may be commonly 
used and a suffix "uf" may be added to indicate it. Then the complete 
name may look like "UsernameIdentifierClass;uf". Or let 
"UsernameIdentifierClass" imply Unicode default case folding by default.

Collations registered at the IANA Collation Registry use a similar 
scheme to identify the rules. They use their names to fully specify the 
collation rules. All implementations for any of the registered 
collations produce exactly the same results.

May I ask if you folks at the WG considered extending the profile 
identification scheme to describe the rules for case mappings? I 
understand it is quite late to make any change at this point, but the 
users would have to address this question anyway one way or the other, 
so I wanted to hear your thoughts on it.

Best regards,
Dan Chiba
Globalization Engineering
Oracle

[framework draft]
http://tools.ietf.org/html/draft-ietf-precis-framework-17

[saslprepbis draft]
http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-07

[mappings draft]
http://tools.ietf.org/html/draft-ietf-precis-mappings-0

[IANA Collation Registry]
http://www.iana.org/assignments/collation/collation.xhtml

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 25 Aug 2014 19:37:57 -0600

Hi Dan,

Thank you for posting about this issue to the list.

I'll reply in more detail on Thursday about this and other PRECIS 
issues, but for now I have one clarifying question: is your concern 
about the UsenameIdentifierClass specifically, or about PRECIS more 
generally? I ask because we've had quite the lengthy and someone 
contentious discussion about case mapping with regard to usernames, 
which is how we ended up with the compromise you have identified.

Thanks,

Peter

On 8/25/14, 7:31 PM, Dan Chiba wrote:
> _______________________________________________
> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis

---

From: Dan Chiba <[email-masked]>
Date: Mon, 25 Aug 2014 18:52:07 -0700

Hi Peter,

This is essentially generic but I think the degree of impact would vary, 
depending on the profile. UsenameIdentifierClass would be one of those 
severely affected because it is important to evaluate usernames 
correctly and there are various common practices of handing them. 
Sometimes case insensitive, sometimes sensitive, among others.

Regards,
-Dan

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 29 Aug 2014 16:15:24 -0600

> Sometimes case insensitive, sometimes sensitive, among others.

Correct. Which is why it's difficult to formulate one rule for all 
treatments of usernames, and why it took quite a bit of discussion to 
come to consensus on the text in Section 4.2.1 of the SASLprepbis 
specification:

http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-07#section-4.2.1

If I understand your original message correctly, you are looking for a 
way that, say, client software can know in advance how a server will 
treat usernames with regard to case mapping, based on the SASL mechanism 
or application protocol in use. I was looking for that, too. 
Unfortunately, our friends in the KITTEN WG (which works on SASL) were 
insistent - and correct - that there is no deterministic formula here 
because case mapping can even be a matter of deployment or service 
policy and thus not determined by the SASL mechanism or application 
protocol in use. Thus our carefully-crafted text in Section 4.2.1.

I wish I could report happier news.

Peter