- From: Boris Zbarsky via GitHub <sysbot+gh@w3.org>
- Date: Tue, 17 Oct 2017 05:06:24 +0000
- To: public-webauthn@w3.org
> but a benign implementer is going to reach for "utf-8 encode" Would they? Or would they just bitwise-and each 16-bit integer with 255 and call it a day? I've certainly seen plenty of people do the latter when faced with this sort of situation before. (I should also point out that "utf-8 encode" takes a code point stream as input, but a DOMString doesn't represent a "code point stream", though it could be forced to do so by making some assumptions about what the numbers in it mean...) > We're likely to end up with some ordering inconsistencies in the more complex conversions I don't think it's just ordering inconsistencies... For the second thing I linked to above, for example, ES primitive values may or may not be valid input. > but HTML4 wasn't "useless" It really was, for achieving interoperability.... What interoperability emerged was the result of heroic reverse-engineering efforts. I'm really hoping we have actually learned something about not writing specifications like that, since then. Anyway, we're arguing in circles, and I'm not going to spend any more time arguing this point; it's not my job, and I've already spent far too much of my personal time on this issue. Either the spec will get fixed, or it won't and then it won't be possible to write tests that would demonstrate interop. I obviously reserve the right to raise formal objections if the spec tries to go to CR or later with these sorts of issues, and without a test suite that would catch them. -- GitHub Notification of comment by bzbarsky Please view or discuss this issue at https://github.com/w3c/webauthn/issues/626#issuecomment-337118928 using your GitHub account
Received on Tuesday, 17 October 2017 05:06:26 UTC