Any reason to use octet and byte? consistency?

[fxlb]

$ 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

[guyharris]

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 83a26b05e2f3384e2aeaeceeb38b9ca62de18deb

[fxlb]

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

[guyharris]

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 efeca01485ef19744d923495f2cbd7c943005bcf.

Others are just cases where "byte" means "octet"; I've changed those in efeca01485ef19744d923495f2cbd7c943005bcf.

[guyharris]

draft-ietf-opsawg-pcapng.md

A mix of "byte order" and other text using "byte" I've changed the latter in c2a09853c130058499c15349fea865ca5f6956f8. (This includes "byte-stuffed"; RFC 1662 uses "octet-stuffed", so, now, so do we.)

[guyharris]

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. :-)