This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It's not really clear what that means. (Aligning with http://encoding.spec.whatwg.org/#terminology and such would be good here I think.)
I propose: "An octet string is an ordered sequence of zero or more integers, each in the range 0 to 255 inclusive."
https://dvcs.w3.org/hg/webcrypto-api/rev/245fcde1bf6f
Why can't we call this a byte sequence as the Encoding standard recommends? Seems weird to use different terminology here.
(In reply to Anne from comment #3) > Why can't we call this a byte sequence as the Encoding standard recommends? > Seems weird to use different terminology here. I don't see a definition of 'byte sequence' at the link you provided. I see a definition of 'byte' which looks odd to me (I would think a byte is an integer between 0 and 255 inclusive without any implication about how it is 'represented').
Well, you have to represent it somehow in a document.
(In reply to Anne from comment #5) > Well, you have to represent it somehow in a document. What we need in the WebCrypto spec is an abstract type for describing the processing of information within our procedures and in particular passing information to / from cryptographic algorithms described in other specifications. We don't need to define / assume any particular way to represent members of that type, whether in a document, in memory or elsewhere.
If you don't represent it you don't have to worry about that part. The larger point here is that we use byte everywhere, not octet. And "ByteString" already has a particular meaning you're not employing here. So byte sequence would be best.
WebIDL defines both byte and octet, with byte being signed and octet unsigned: http://www.w3.org/TR/WebIDL/#idl-octet. This is itself an odd definition of byte. I'm all for consistency / alignment, it's just not clear who we should be consistent / aligned with ;-)
Fair. I think there's an open bug on IDL.