--On Tuesday, September 09, 2014 19:18 -0600 Peter Saint-Andre
<[email protected]> wrote:
>...
> As far as I can see, the only alternative to the compromise
> we've brokered here is (my understanding of) what John
> suggests: lock down the base string classes, effectively
> disallow profiles, and tell existing applications to conform
> to the new rules. If they want exceptions, then they don't
> have to use PRECIS.
I've suggested several slightly different things in the hope of
finding a solution that would be acceptable to everyone (or at
least "many"). I don't think the above is one of them, but it
is possible. I am really no more interested than anyone else
sensible in invalidating applications that work now. My goals
are to keep the user experience predictable and to minimize
maintenance responsibilities and costs. What I have suggested
would be a slight variation on the above, replacing "tell
existing applications to conform" and "don't have to use" with
an explicit section of the PRECIS standard that would say, more
or less,
"While it is recommended for predictability that
applications conform narrowly to the base strings
classes and rules, applications may need to make
exceptions to allow or disallow particular characters
for historical or other reasons. Such applications are
still conformant to PRECIS if they their protocol
specifications precisely identify the characters
affected."
I assume that we would than either add a per-application list of
exceptions or put in language passing on that responsibility to
the applications. I also assume that any applications that
intended to expand their lists in the future (i.e., not simply
have exceptions as a legacy matter) would create IANA registries
for their exceptions lists (not complete tables) and that text
about exception for those applications would point to the
registries.
> In my opinion, that would be slightly at odds with the spirit
> of how the PRECIS WG was formed, since all of the Stringprep
> "customers" in the room at the NewPrep BoF had existing
> profiles and wanted to figure out how to use modern versions
> of Unicode while supporting as many of their existing
> strings/identifiers as possible. If we now tell those
> customers that we can't meet their needs, I don't think they
> will be particularly happy.
I agree with that goal and have all along. But, again, I'd
like to move as much as possible toward a minimum number of
definitions/ tables/ profiles with exception lists as needed.
The latter are not ideal -- there is no way to get to ideal
while preserving backward compatibility -- but, if they are
treated as necessary exceptions and about edge cases (which they
mostly are), then I think we will be ok.
> But, as John also says, this is
> about pleasing (or at least minimizing confusion for) end
> users.
FWIW, I do see the goal of minimizing user confusion to be
diametrically opposite to the notion that we should have many
profiles and the potential for variations on each that I believe
Dan has suggested. Either that or I still don't understand his
suggestion/ request.
john
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
