There is a corollary: If a future revision of .onion labels exceeds 63/256 boundary conditions, then it will change behaviour when presented in the DNS. In the current situation, it will earn an NXDOMAIN and 'dtrt' in as much as the return says 'this label is not in the DNS'
in future, if it exceeds the (1980s, we were all younger and wiser then) proscribed field semantics for DNS, it will return FORMERR and other replies which may tickle other behaviour than you (we?) expect.
I know I keep harping on about the DNS, and your main goal is to NOT BE in the DNS. But we also realize the reality that these labels will be presented to dns gethostbyname() and other packages (getDNS api?) -So the s/w behaviours of systems have to be considered. A couple of postings in the thread(s) of this discussion make it clear we all understand, the labels are going to be seen in the DNS system/ecology, irrespective of if we wish it or not.
I don't actually think any language has to change. You might just want to document in TOR paperwork, that changes to the syntax of xxx.onion has to be assessed against its behaviours in other name-lookup systems.
-G
PS
$ dig @8.8.8.8 123456789012345678901234567890123456789012345678901234567890123.x.dashnxdomain.net. in a
; <<>> DiG 9.10.2-P3 <<>> @8.8.8.8 123456789012345678901234567890123456789012345678901234567890123.x.dashnxdomain.net. in a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 50749
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;; AUTHORITY SECTION:
;; Query time: 496 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Aug 13 12:54:03 UYT 2015
;; MSG SIZE rcvd: 166
$ dig @8.8.8.8 1234567890123456789012345678901234567890123456789012345678901234.x.dashnxdomain.net. in a
dig: '1234567890123456789012345678901234567890123456789012345678901234.x.dashnxdomain.net.' is not a legal name (label too long)
$
On Thu, Aug 13, 2015 at 11:17 AM, Nick Mathewson <nickm@xxxxxxxxxxxx> wrote:
On Wed, Aug 12, 2015 at 4:49 PM, Alec Muffett <alecm@xxxxxx> wrote:
>
> On Aug 12, 2015, at 1:16 PM, Ted Hardie <ted.ietf@xxxxxxxxx> wrote:
>
>
> If you're willing to put a statement like it in the draft, that works for
> me; it would need to include a slightly broader commitment (not to step on
> other syntax bits, like the IDNA prefix etc), but I think the broader
> statement would go to exactly the same goal.
>
>
> Given that this is about Onion Registration rather than about Tor Project,
> some wording like
>
> “Onion addresses are [blah description blah] and which are consistent with
> DNS syntax limitations of 63 character labels..."
>
> …which I think would impose a constraint whilst being aimed at the
> supposedly correct target.
>
> I’ll copy Nick on this to be doubly certain.
I think that's (broadly) a good solution.
The important thing here AFAIU is not to nail down the exact semantics
of current .onion addresses or post-revision .onion addresses or
25-years-from-now .onion addresses... but rather to carve out enough
space for this and future revisions.
So it's IMO fine to say ".onion addresses are case-insensitive and
will comply with existing DNS limitations for label lengths (63) and
maximum fqdn lengths (253ish)".
But it it would be problematic to say something like ".onion addresses
are are exactly N characters long" or ".onion addresses have the
following structure" or ".onion addresses have exactly two labels" or
anything like that. So let's avoid those.
cordially,
--
Nick