According to the Online Etymology Dictionary, the verb collide is derived from the Latin verb collidere, which means, literally, “to strike together”: com- “together” + lædere “to strike, injure by striking.”
Combined instead with loquium, or “speaking,” the com- prefix produces the Latin-derived noun colloquy: “a speaking together.”
Researchers and practitioners know well the benefits of the colloquium, the technical conference, a gathering of those speaking together on a topic.
So consider WPNC 14 – the upcoming namecollisions.net workshop – a colloquium on collisions: speaking together to keep name spaces from striking together.
Many years ago on my first trip to London, I encountered for the first time signs that warned pedestrians that vehicles might be approaching in a different direction than they were accustomed to in their home countries, given the left-versus-right-side driving patterns around the world. (I wrote a while back about one notable change from left-to-right, the Swedish “H Day,” as a comment on the IPv6 transition.)
If you’re not sure on which side to expect the vehicles, it’s better to look both ways — and look again — if you want to reduce the risk of a collision.
We recently hosted Dr. Ralph Merkle as a guest speaker for the Verisign Labs Distinguished Speaker Series. His talk, “Quantum Computers and Public-Key Cryptosystems,” was a great presentation on how molecular nanotechnology — the ability to economically manufacture most arrangements of atoms permitted by physical law — could fundamentally alter the world as we know it. Ralph’s and many others’ research on this topic has been groundbreaking and we are grateful he took the time to come and share his knowledge.
ICANN’s second-level domain (SLD) blocking proposal includes a provision that a party may demonstrate that an SLD not in the initial sample set could cause “severe harm,” and that SLD can potentially be blocked for a certain period of time. The extent to which that provision would need to be exercised remains to be determined. However, given the concerns outlined in Part 2 and Part 3 of this series, it seems likely that there could be many additions (and deletions!) from the blocked list given the lack of correlation between the DITL data and actual at-risk queries.