[Cbor] Re: dCBOR: Normalization of Strings

[Wolf McNally <[e-mail]>]

Carsten,

In a constrained environment where you must sacrifice full dCBOR compliance, you could of course use some other heuristic to support a limited set of NFC-compliant strings and yet support wider range of characters than Latin-1. You can advance this strategy until the number of false negatives falls below some arbitrary threshold.

Or you might want to reconsider your use cases for dCBOR in such extremely constrained environments.

~ Wolf

> On Jul 29, 2024, at 4:14 PM, Carsten Bormann <[e-mail]> wrote:
> 
> On 30. Jul 2024, at 00:19, Joe Hildebrand <[e-mail]> wrote:
>> 
>>> Latin-1
> 
> Latin-1 became bed-ridden in 1990 (iron curtain gone, so we now really needed all these Czech, Polish, Hungarian, … characters) and its corpse was completely shredded in 1999 (introduction of the Euro, the symbol for which is not in Latin-1).
> I wouldn’t build any strategy on Latin-1 or the stopgap Windows-1252 (Windows 95, with € finally added in Windows XP).
> 
> Latin-1 of course is an encoding scheme (which could be called UCS-1) as well as a character repertoire (which is identical the Unicode range of U+0000 .. U+00FF).  Instead of the latter, a larger set of Latin characters might still be useful for memoizing much of NFC normalization and validation.
> 
> Grüße, Carsten
>