On 5/4/16 4:26 PM, Sam Whited wrote:
On Wed, May 4, 2016 at 3:46 PM, Peter Saint-Andre <[email protected]> wrote:
There's also the question of whether preparation / pre-processing is all
that useful. We added it so that constrained clients (e.g., clients that
can't realistically perform normalization) could avoid most of the problems
associated with having their strings rejected by a more powerful server that
actually does enforcement and comparison. Whether we really need to consider
such applications is another story.
I'd be curious to know a "real world" use case for the preparation
step optimization where enforcement is prohibitively expensive and
comparison is not necessary (since comparison necessitates
enforcement)?
The original suggestion (some years ago now) was browser-based clients
that could not easily download the entire Unicode character database
from a web server to the browser in order to do enforcement or
comparison, but which could do something simpler like allow a user to
create a username using a restricted repertoire of characters such as
ASCII or "extended Latin".
Another example might be IoT clients running on microcontrollers with
very limited memory and processor speed.
However, I have not seen benchmarks for such applications with respect
to handling of internationalized strings.
While benchmarking the implementation I did for Go I
decided that it wasn't necessary to include a preparation step. Even
on a heavily resource constrained server
Right, we've always figured that servers have more horsepower.
Peter
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
