default for target value in JSON?

[sftcd]

In -02 we say that the targetName attribute of the RR can be provided by the target element of an endpoints array element with a default of "."

That's fine, but confuses me for cases when the port != 443.

When port != 443 testing (and @davidben advice:-) showed that the hostname of the server and not "." was the targetName value that should be the default, but I don't claim to understand why TBH, it just worked (for chromium based browsers though not yet FF).

I think that may mean that we should say that the default targetName to use is "." iff port == 443 but otherwise the hostname from $ORIGIN if port != 443

[bemasc]

"." and the hostname are interchangeable. It's purely a compact representation at the syntactic level. There is no interaction with the port number.

I think what you're likely seeing is that Chrome hasn't implemented support for non-default port numbers in HTTPS records, and is ignoring records that specify a new port.

[sftcd]

Need to go check again, but chrome does work for port != 443 for me (whereas FF doesn't).

Chromium just now is fine with https://draft-13.esni.defo.ie:8413/stats And:

$ dig +short https _8413._https.draft-13.esni.defo.ie
1 draft-13.esni.defo.ie. ech=AID+DQA88QAgACCtnNgox5qJQpR5jQvWb+ubPv5zBNhvYws+zr6lxJdyRQAEAAEAAQANY292ZXIuZGVmby5pZQAA/g0APA8AIAAg9Y4JG6CigWHr0rQE88m8YYon9Ci9z6SD0HRNIFMwKm0ABAABAAEADWNvdmVyLmRlZm8uaWUAAA==

[bemasc]

Specifically, the line I linked to rejects the HTTPS record if it specifies a port AND that port is different from the one in the URL.

[sftcd]

Right but the port is in the URL in the case above. When I used "." as target for that specific HTTPS RR, chrome did not work. (As in ECH failed or wasn't attempted I forget which;-)

In any case I do think the right default for target when port != 443 is the hostname, but am open to correction and would like to understand why too:-)

[sftcd]

I think we can close this one too - agreed?

[richsalz]

agree to close