Any reason to use octet and byte? consistency?
Opened this issue · 5 comments
$ git grep -c octet '*.md'
draft-ietf-opsawg-pcap.md:13
draft-ietf-opsawg-pcaplinktype.md:4
draft-ietf-opsawg-pcapng.md:70
draft-richardson-opsawg-pcapng-extras.md:5
$ git grep -c byte '*.md'
draft-ietf-opsawg-pcap.md:2
draft-ietf-opsawg-pcaplinktype.md:11
draft-ietf-opsawg-pcapng.md:9
draft-ietf-opsawg-pcap.md:2
One is in the phrase "byte order"; that's a sufficiently commonly-used phrase that using it rather than "octet order" might be justified.
The other is in the phrase "magic bytes", referring to the magic number at the beginning of the file. That should probably just refer, as is done elsewhere, to the Magic Number field in the File Header; fixed in 83a26b0
One is in the phrase "byte order"; that's a sufficiently commonly-used phrase that using it rather than "octet order" might be justified.
In RFCs there are 1597 byte order and 32 octet order. Less use indeed but not unused. Thus why not change to octet order?
... Magic Number ...
+1
draft-ietf-opsawg-pcapng.md:9
Many of those are in the phrase "byte order" or the field name "Byte-Order Magic"; the suggestion made for "byte order" in the pcap format applies here as well. (I hyphenated one case where that field was referred to as the "Byte Order Magic" field rather than the "Byte-Order Magic" field.)
One other is in the phrase "magic bytes"; for pcapng files, that refers to the Block Type and Byte-Order Magic fields in the Section Header Block at the beginning of the file, so I've updated that in the pcapng spec, in a fashion similar to the way I updated the similar text in the pcap format I-D, in efeca01.
Others are just cases where "byte" means "octet"; I've changed those in efeca01.
In RFCs there are 1597 byte order and 32 octet order. Less use indeed but not unused. Thus why not change to octet order?
And then there's https://developers.google.com/nearby/fast-pair/specifications/introduction#OctetOrder, which says
Octet order
Wherever a field consists of multiple bytes, the byte ordering is big-endian, that is, network byte order (most-significant octet to least-significant octet).
Note that while this is standard for bytes transferred over networks, it is different from the byte ordering for multi-byte fields in Bluetooth SIG specifications (for example, a service UUID in an advertisement is little-endian).
so Google can't make up their mind. :-)