On 4/10/12 1:30 PM, Andrew Sullivan wrote: > Ok, surely we need a class between NameClass (which I grant is too > restrictive for a lot of things) and FreeClass
It all depends on what our customers want. To date, other than our customers for SASL user names (discussed in Paris) and possibly (*) LDAP distinguished names, we haven't seen demand for a string class between NameClass and FreeClass. * I say possibly because we really haven't received any feedback at all from our LDAP customers, which worries me. > (which I guess ought to > be as open as possible, to account for the possibility of > subclassing). Right. If you want something less free than the FreeClass, subclass it. > I know we had many more of these in the past, We had one more: the SecretClass for passwords. However, we decided to merge that into the FreeClass because it seemed to be a distinction without a difference. > and > ditched a lot of the distinctions, but can't we come up with > NonBoneheadClass that restricts us to the set of things that can be > predictably normalised in some sane way? We can't solve the O -> o > and ò -> Ò problem, but surely we could set a class that doesn't > include those cases? Yes, this might entail nasty mappings and > information loss; that would be the point. Do our customers want or need that string class? Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
