twoOctetIPv4Address

Exactly. And now I feel compelled to explain why to the people who don't actually know any language more bare-metal than Java. Your computer has to convert the decimal octets to binary chunks anyway to process the input, and hex is really just a more concise way to represent binary. It's actually surprisingly legible still.

d0 127 0 0 1

0x 7f 00 00 01

But that horrific decimal string is doing a bastardized encoding of those hex chunks into a new base ten number, completely obscuring and defeating the purpose of the clean four octets. It's a total novelty, and course it needs to work for your operating system to run, but actually taking advantage of it for anything legitimate, requiring any amount of manipulation, say, attempting base ten math to determine a subnet mask, enters a realm of psychosis I dare not tread.

I personally find ping 2130706666 easier to remember. I can type it from memory and it always gets a reaction.

Call me a madman but I actually like the hex style better

Mixing it is fairly cursed.

You can do it shorter as well:
ping 0x7f.1

ping 0x7f.0x1

And it actually makes sense, you just need to learn hexadecimal, using decimal is the insane one

I disagree, something like 162.84.199.0/22 is perfectly legal. It's not common practice (largely stemming from big actors like microsoft having mangled network configurations resulting in major headaches for end-users, the common practice ended up being just excluding these addresses from being assigned).

I'd argue it's a sane default to expand assuming the first and last octets are nonzero but it's not strictly illegal for the last octet to be 0. This has been the case since I believe '93 or '94 with the advent of classelss CIDR-style addressing. In fact any prefix smaller than /23 (inclusive) necessarily implies includes addresses ending in a zero octet since all prefixes smaller than /23 have address ranges greater than 255 (/23 being 510 addresses and /22 being 1022)

Expanding to 127.1.0.0 would be legal, albeit unhelpful for most usecases. Arguably rejecting 127.1 as a malformed/ambiguous address is the most correct implementation but that'll ruffle too many feathers. Now the real doozy is trying to expand 127.2.1, that's fully ambiguous and all expansions are dissatisfactory for one or more reasons (the candidates being 0.127.2.1, 127.0.2.1, 127.2.0.1, 127.2.1.0 -- the first of which is obviously the most dissatisfactory/problematic but the rest are somewhat ambiguous in terms of being better or worse assumptions).

Now the first octet should indeed not be 0 unless you're doing something strange as the first octet being 0 would imply we're looking at a wildcard address which is not a valid destination so that assumption is more or less safe and you can deal with the mild inconvenience of typing out the wildcard fully in those cases.

Because network byte order is big endian.

Because network byte order.