> They're obviously different things. The what that is working is not necessarily the what that the spec writers intended or imagined.

But the what is all that matters. Without a what to ask the question "does it work?" about, there is no question to ask.

For any specification, you can create a derived but incompatible specification, either implicitly or explicitly, and an implementation of that derived specification certainly works. But it works as an implementation of that derived specification, not as an implementation of the original specification, and a component implementing the derived specification won't work in the general case when interoperating with a component implementing the original specification.

Also, for any given implementation it is possible to write a spec that it conforms to, so it's trivially true that any piece of software works in the sense that it conforms to some (potential) specification.

The point of specifications is not to declare what is the only possible way to do things, but to create a convention that allows interoperability. Stuff that doesn't work according to spec fails that goal, so it only works in the sense that anything that does something does something, and possibly something useful.

> I work in network and application security. A lot of what "works" flies in the face of your definition, and I don't find your definition useful outside of meeting rooms.

Nope, especially with regards to security, anything that "works in practice", but doesn't work according to spec, has a pretty decent chance of being a vulnerability.

> I never claimed that. I claimed that you could specify the textual representation of an IP address, of which dotted quad is the most common and the only form I've tested. You have agreed with this, so I won't repeat myself.

No, you can't. You can put a string into the SNI hostname field that is an element of the "dotted quad IPv4 address representation" language. But that is by definition not the textual representation of an IP address, but the textual representation of a hostname consisting of just digits and dots. The fact that you could potentially type-pun the representation into a context where it would be interpreted as an IP address does not change that it is not in fact representing an IP address. What a (formal) language means is defined by the specification of the language, not by the specification of any language that happens to contain a given string as an element.

When a database table has a field "first name", you can not store last names in it. It's irrelevant that you can use the field to store strings in it that could be parsed as last names--the fact that they are stored in the first name field makes them first names by definition.

When a database table has a field "phone number", you can not store ZIP codes in it. It's irrelevant that you can use the field to store strings in it that could be parsed as ZIP codes--the fact that they are stored in the phone number field makes them phone numbers by definition.

When a protocol message has a field "DNS hostname", you can not store IP addresses in it. It's irrelevant that you can use the field to store strings in it that could be parsed as IP addresses--the fact that they are stored in the DNS hostname field makes them DNS hostnames by definition.

Being confused about this is the root of multiple classes of vulnerabilities (language injections (SQL injection, XSS, shell injection, header injection), string termination vulnerabilities).

> At the very outset, my point was that the definitions of these words are very context-sensitive. A nodename, a hostname, a domain name, a fully-qualified domain name, a text representation of an IP address. They have overlapping common meanings,

Yes.

> but all are functional, working names for use in SNI, as understood by standard tools of internet technology.

No. Or, if they are, those tools are vulnerable.

> Your argument seems to be that any name that works in SNI is by definition a DNS FQDN, because the SNI spec says that only DNS FQDNs work.

You are having it all backwards. This is not about "what works", but about what it is defined to be. The definition of the protocol says that whatever you find in that field of the protocol message is defined to be a DNS FQDN. It doesn't matter what the sender secretly intended--the definition of SNI says that it is a DNS FQDN. If the sender intended the content of the field to be interpreted differently, they weren't implementing SNI.

> "snitest" in /etc/hosts (or NIS etc!) is not a DNS FQDN.

As I already explained, it is, in that the SNI spec doesn't care about the data source. You could trivially create a DNS root that had a TLD "snitest.", and under that DNS root, "snitest" would be a valid DNS FQDN.

> "8.8.8.8" is not a DNS FQDN.

Yes, it is. Just don't confuse it with the IP address "8.8.8.8". In the global DNS root, the TLD "8." does not exist, therefore, it doesn't exist, but it is a valid DNS hostname in the SNI hostname field.

> Both work as names in SNI.

Yes, of course they do. But IP addresses don't.