2 ms·

April Fool's RFCs are a bit of a tradition[0]. I'm a fan of the proposal for IPoAC[1]. [0] https://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_Comments

by greggyb 11y ago

April Fool's RFCs are a bit of a tradition[0]. I'm a fan of the proposal for IPoAC[1]. [0] https://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_Comments https://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_C... [1] https://tools.ietf.org/html/rfc1149 https://tools.ietf.org/html/rfc1149

Dylan16807 11y ago
Oh I understand why the RFC exists. But they should have put a bit more effort into it, and joveian should have made clear that it was a low-effort RFC, joke or not. I'll be more clear about my earlier post. I realized the RFC itself was put out as a joke, but I couldn't really tell if the 128 bit math was bad on purpose or out of laziness. Or what the RFC author actually thought about using such a compact representation.
- joveian 11y ago
  I am curious about the background behind it and the author's opinion of the basic idea as well. I think the 128-bit math part was just intended to invent context for a jab at standards that assume recent hardware and not really intended to make sense in context. I admit it was a low effort comment on my part :/. It seems like something along those lines could be a good idea, although in practice I think 22 URL-safe base64 characters with four error correction bits would be better representation. Looking at Wikipedia's nice base64 page, one possibility would be to use '-' and '_' for the two non-alphanumeric characters and allow the longest run of zeros ('A's) to be changed to '~'. Automatic error detection seems like a really good idea whenever humans are forced to interact with 128-bit numbers, but then you can't easily generate subnet masks by hand. In general, I think avoiding interacting with them as much as possible is the most important step. At this point, it would take a while for any alternate representation to be widely supported by software even if there was wide agreement that it was a good idea. OTOH, a general "least bad" compact representation of larger numbers with error detection could potentially be useful for other things (even if it doesn't get used for IPv6), such as ECC public keys.

by greggyb 11y ago

Dylan16807 11y ago

Oh I understand why the RFC exists. But they should have put a bit more effort into it, and joveian should have made clear that it was a low-effort RFC, joke or not. I'll be more clear about my earlier post. I realized the RFC itself was put out as a joke, but I couldn't really tell if the 128 bit math was bad on purpose or out of laziness. Or what the RFC author actually thought about using such a compact representation.

joveian 11y ago
I am curious about the background behind it and the author's opinion of the basic idea as well. I think the 128-bit math part was just intended to invent context for a jab at standards that assume recent hardware and not really intended to make sense in context. I admit it was a low effort comment on my part :/. It seems like something along those lines could be a good idea, although in practice I think 22 URL-safe base64 characters with four error correction bits would be better representation. Looking at Wikipedia's nice base64 page, one possibility would be to use '-' and '_' for the two non-alphanumeric characters and allow the longest run of zeros ('A's) to be changed to '~'. Automatic error detection seems like a really good idea whenever humans are forced to interact with 128-bit numbers, but then you can't easily generate subnet masks by hand. In general, I think avoiding interacting with them as much as possible is the most important step. At this point, it would take a while for any alternate representation to be widely supported by software even if there was wide agreement that it was a good idea. OTOH, a general "least bad" compact representation of larger numbers with error detection could potentially be useful for other things (even if it doesn't get used for IPv6), such as ECC public keys.