| > Of course you can store first names in a last name field. Nope. > You can even choose to invert the label-semantic relationship between the two fields in your code. In which case you aren't storing first names in the last name field, you simply are using an uncommon label for the first name field. Whether something is the first name field is not defined by its label, but by the declaration of its purpose, either explicitly in a specification or implicitly in your code. Having a descriptive, non-misleading label is simply helpful for maintainability, but not relevant to the discussion at hand. > If "Bob" is stored in last_name, the data does not semantically become something it is not just because someone mislabeled it. I am assuming you mean a field that is actually declared to contain last names (as opposed to a field that is declared to contain first names, but labeled "last_name"), as that was the premise in my previous arguments: Are you saying that your software will not produce letters saying "Dear Mr. Bob" if it finds "Bob" in that last name field? > "8.8.8.8" is not a DNS FQDN. Well, yes it is. Saying '"8.8.8.8" is not a DNS FQDN' is like saying '"Martin" is not a last name'. Just because you will likely categorize "Martin" as referring to a first name without further context, does not mean it is not a last name. > Of course it could be, but it is not, in current practice. Except it isn't current practice. > If you think of it as a DNS FQDN, you cannot assume it to have any relationship to IP address 8.8.8.8, Well, yeah, that's my point!? > which in all resolver libraries, it does. No, not all resolver libraries, and none of the resolver libraries relevant to this discussion. Take a pure DNS library, feed in 8.8.8.8 as the DNS domain name, and get back NXDOMAIN (or possibly something else in an alternate root). What Unix host name resolver APIs do is irrelevant as that is not the convention referenced by the RFC, the RFC references DNS hostnames. > So it is not a DNS FQDN, and in fact is not even looked up when supplied. Just because Unix hostname resolution APIs happen to be unable to resolve the DNS FQDN 8.8.8.8, does not make it not a DNS FQDN. Are you telling me next that _service-name.example.com is not a DNS FQDN because underscores are not allowed in internet hostnames? That format is used for SRV and ACME lookups precisely because it is not an internet hostname, but still a DNS FQDN, so it cannot collide with hostnames, but still can be looked up in the DNS. > It is very precisely only ever used as a textual representation of an IP address, in dotted quad format. So ... four-number OIDs don't exist? > The direct representation of an IP address could not even be posted here. Which doesn't change that not every representation that takes the form "1.2.3.4" is a representation of an IP address, just as not every representation that takes the form "Martin" is a representation of a first name. The fact that you can not post Martin (the human being) here, does not change the fact that the string "Martin" can be a reference to Ms. Jane Martin. > So it is as close and most familiar as we can get to an IP address. And yet, if you find that string in the SNI hostname field, it does not represent an IP address. > And I was always careful to qualify my comments that it was a textual representation of an IP address. Because I know the difference! But syntax alone does not define semantics, context matters. The mere fact that some string can be read as a textual representation of an IP address does not actually make it a textual representation of an IP address. > You also know that it is possible for "snitest" (or, more precisely, "snitest.") to be a DNS FQDN. But it almost never is. Which is irrelevant to the semantics of the SNI hostname field. > In practice, it is going to be a nodename, and it might not even be looked up in DNS. As above: Feed it into a DNS resolver library and find that it can indeed look up the TLD "snitest". That "Martin" is used in practice as a first name is irrelevant when the field in a form that someone wrote in the string "Martin" is labeled "last name". > The SNI spec does not get to redefine "IP address (textual representation of)" and "nodename" outside of its own context. It doesn't. It explicitly references DNS hostnames. It never says anything about "nodenames". And it even explicitly states that literal IP addresses are forbidden (and mind you that "literal" here does not mean "four bytes", but dotted quad or hex-colon notation, which are commonly refered to as "IP literals" in RFCs). Also, the RFC even explicitly says 'It is RECOMMENDED that clients include an extension of type "server_name" in the client hello whenever they locate a server by a supported name type.'. The spec in no way redefines anything, it simply says "if you happen to have located the server using a DNS hostname, you may put it here, if you used anything else, you cannot use this extension". > You could have been correct if you said, at the beginning, that while it might be a nodename or an IP address (text representation) in all ordinary contexts, the SNI spec defines anything that results in a valid mapping to an IP address as a "DNS FQDN". It doesn't, and thus that would have been incorrect, which is why I didn't say that. > But instead you accused me of not having read the spec, and you proclaimed that SNI only works with turtles. Well, at least you haven't understood the spec? > Security exploits work. Yep. But does a server that crashes when the security exploit works work? > There is no deep epistemological problem created by the fact that the word is given meaning by its context. Except that that is not the problem. The problem is that you are equivocating semantically different instances of "work". "I have a car with a broken transmission that I live in. It works fine for keeping me warm. So, the car works. I want to sell the car. As the car works, people should pay me the price for a working car." You see the flaw in that reasoning, right? That's the fallacy in your reasoning. Saying "the car works for keeping me warm" is perfectly fine, but it does not imply "the car works", because that would imply "... for doing whatever is commonly understood to be the primary purpose of cars". Noone is denying that you can specify and implement a protocol where you can specify IP addresses for the selection of the TLS certificate to use. If you do so, that works. But that protocol is not SNI. So, if you ask whether that is a working SNI implementation: No, it's not. > Nodenames work in SNI. If you mean by that unqualified hostnames: No, they don't. You only can agree between clients and servers that are controlled by you on a method of encoding nodenames as DNS hostnames, and then use SNI with those. > And textual representations of IP addresses work in SNI. No, they don't. You can not express IP addresses in SNI. |