On 4/10/12 2:02 PM, Andrew Sullivan wrote: > On Tue, Apr 10, 2012 at 01:47:35PM -0600, Peter Saint-Andre wrote: >> Do our customers want or need that string class? > > I'm slightly uncomfortable with this question. > > The strongest message we keep getting is, "Aargh. Can't you keep > these internationalization questions away from me?" The _second_ > strongest message we keep getting is, "Aargh. I need that [disallowed > thing]." > > Our answer seems to be, increasingly, "Here is a framework for you to > subclass this giant set of trade-offs." But that wasn't what the > customers wanted. What they wanted was something that was easy and > also totally flexible.
Magic pixie dust, in other words. > We have to deliver a nicely-packaged gumdrop > of, "Can't have that. Here's what you can have." IMHO we have two sets of customers: 1. People who used stringprep. 2. People who are utterly clueless. Folks in the first group knew they had a problem, listened to the sage but somewhat misguided advice of those who had blazed the path ahead of them, and now need something better. Folks in the second group blindly hope that "Just use UTF-8" will solve all internationalization problems. We need to gently disabuse them of that notion, as security folks would gently disabuse people of the notion that "Just use TLS" will solve all security problems. Both security and internationalization are hard problems (although hard in different ways), and it would be irresponsible of us to start handing out gumdrops. > It increasingly seems to me that we need to offer easy and flexible > classes; maybe Name and Free is it. Well, we looked at what our existing customers were using, and defined NameClass based on that. It turned out (or so we thought) that none of our customers needed anything between the warm safety of NameClass and the beautiful chaos of FreeClass. > But I'd like to be able to offer > a SlightlyFree that doesn't present quite so many subclassing > opportunities. The people who want precis don't want to have to > subclass. I think it would be a fine thing for us to define something in between NameClass and FreeClass, although right now I don't have strong intuitions about what it would include. One approach would be to forge ahead with NameClass and FreeClass, then define this InBetweenClass or SafeClass on top of the framework after the framework is done (nothing says all classes need to be defined in the framework). Or we could define the SafeClass now in the framework document so that we provide a proper range of options to our present and future customers right from the start. I hesitate to pursue the latter option because we don't have a clear picture of what the SafeClass would include, but I suppose we can work that out here soon. > Yes, I know this is inconsistent with part of what I was > arguing in Paris, but I thought about it more, and I am even less > settled than I was then. Well, a foolish consistency is the hobgoblin of little minds. :) Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
