> > >>> * §2.2 Specifies that UTF-8 MUST be used as the encoding; do we really > >>> want to limit this to UTF-8 only? Is this for comparison purposes? > >>> Then again, 99.99% of the time UTF-8 is what you should be using > >>> anyways, so I'm not sure that it matters. > >> > >> UTF-8 is your friend, and everything in PRECIS is UTF-8. > > > > PRECIS is mostly encoding agnostic; implementations might favor a > > specific encoding, but I don't think anything in the spec specifically > > *needs* UTF-8. That being said, there are so few reasons to use > > anything other than UTF-8 that I don't think it really matters, it was > > just curious to me that some of the PRECIS related specs called out > > UTF-8 and some didn't. > > I thought they all did, but will double-check.
This actually became a bigger issue when attempting to implement PRECIS prepare in JavaScript for the browser. JavaScript doesn't have native UTF-8 support, so this meant the extra bloat of bringing in a UTF-8 library. It didn't make a lot of sense to me either, since all the encoding affects is how you go from string to code points, and vice versa. It had no effect on the rest of my implementation. I could absolutely be missing something, but compared to how focused the rest of the spec is, the UTF-8 requirement seemed like an afterthought. Can anyone explain which parts of PRECIS are actually predicated on the original string being encoded in UTF-8? On 5 September 2016 at 04:54, Peter Saint-Andre <[email protected]> wrote: > > > > On Sep 4, 2016, at 8:28 AM, Sam Whited <[email protected]> wrote: > > > > On Sat, Sep 3, 2016 at 4:21 PM, Peter Saint-Andre <[email protected]> > wrote: > >>> * §2.1: "May any instances of non-ASCII space be mapped…" sounds odd, > >>> should this just say "Instances of non-ASCII space should be mapped…" > >> > >> Typo: s/May/Map/ > > > > That makes the document read: "Map any instances of non-ASCII space be > > mapped to ASCII space"; the "be mapped" still needs to be removed in > > the current draft. > > Oops. Easy enough to fix, though! > > > >>> * §2.2 Specifies that UTF-8 MUST be used as the encoding; do we really > >>> want to limit this to UTF-8 only? Is this for comparison purposes? > >>> Then again, 99.99% of the time UTF-8 is what you should be using > >>> anyways, so I'm not sure that it matters. > >> > >> UTF-8 is your friend, and everything in PRECIS is UTF-8. > > > > PRECIS is mostly encoding agnostic; implementations might favor a > > specific encoding, but I don't think anything in the spec specifically > > *needs* UTF-8. That being said, there are so few reasons to use > > anything other than UTF-8 that I don't think it really matters, it was > > just curious to me that some of the PRECIS related specs called out > > UTF-8 and some didn't. > > I thought they all did, but will double-check. > > Thanks! > > Peter > _______________________________________________ > precis mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/precis >
_______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
