guidspace.arpa or similar seems like a good potential solution to any of the usecases around such "magic" negotiated systems where the user isn't going to need to type in or see the actual name. By generating a guid, any system could easily generate unique names without any registration.
But it doesn't do anything for usecases that want nice names for users to directly see or enter. Anything with a guid is unlikely to ever be considered a "nice" name. Is this a usecase that also needs to be solved, or are nice names even more into the territory where the system should be registering a name first? On Tue, Nov 17, 2020 at 1:57 AM Brian Dickson <[email protected]> wrote: > Comments made in the chat, about the private-use presentation/draft: > Me: > One potential approach is to say (in the RFC) that one of the two-letter > reserved codes should avoid name collision by putting a collision-resistant > second-level label, below .zz and above the private use usage (and use that > particular two-letter code in that manner exclusively). > > E.g. whatever-i-want.guid-as-label-to-prevent-collisions.zz rather than > whatever-i-want.zz > > Warren: > @Brian: Yes, but as you know (being a registrar), people really want > semantically meaningful names... People have seen using www.corp, not > www.dfads3e4r34324rwefe.corp.. > > Me: > Correct, and I think possibly providing guidance that this private use > SHOULD be generally limited to "magic" things like automation or > automated/negotiated systems. The UI can/should hide the GUID component and > possibly also the zz TLD > > Ben: > That could be $guid.guidspace.arpa, no need for .zz > "guidspace.arpa" is not a thing. I'm just suggesting an adjustment to > Brian's proposal. > Me: > That's a good idea, can be pursued independently of the private-use TLDs > like .zz > (possibly addressing different use cases?) > > Brian > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
