> On 22. Aug 2022, at 20:47, Paul Vixie <[email protected]> wrote: > > > > Schanzenbach, Martin wrote on 2022-08-22 11:24: >>> On 22. Aug 2022, at 20:15, Paul Vixie <[email protected]> >>> wrote: >>> ... >>> noting: by describing this as a reserved name subspace, we implicitly >>> expect that the presentation form of any namespace thus enabled will be >>> "compatible enough" with DNS presentation form to allow the reservation >>> keyword (.ALT) to be entered or displayed, and detected. we can in the >>> specification for the subspace reservation even state that implication. >>> however, if someone wants to go rogue on that, we shouldn't try to stop >>> them. (as if we could.) >> But I also think that if it is expected that name systems may "go rogue" >> e.g. use a new innovative new string encoding, then the registry might have >> trouble listing/registering the 2LD "byte string" chosen by the name system? > > that's not our problem. we're reserving part of the namespace, and that's > all. if someone wants to use it in a way that fails, that's totally their > affair. > >> So maybe Unicode provides sensible guide lines for acceptable strings under >> .alt _for the registry_? > just... no. if somebody wants to put binary gibberish "under" .ALT, in a way > that browser plugins never get to see because it's not valid unicode, that is > _their problem_. we can state implications, nothing more.
I agree. It is just unclear to me how the registry itself would support this. I am no IANA registry expert. But if any byte string is theoretically allowed as a 2LD, then how would this look like? I mean, https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml looks ok because "URN Namespace" is well-defined as a readable string with a specific encoding. But if the registry must support 花 as well as 0x32 0x34 0x23 (no the strings, the byte sequence) I wonder how that will look like? Or are we always going to register byte sequences instead of readable strings? Again, not really my problem and will only become a problem with an odd encoding, so likely never*. BR > > -- > P Vixie >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
