-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 My thinking is that people are reluctant to engage with the process for experimental or extremely niche applications, for better or for worse. Or simply because it is meant for personal or internal use: if a company initially wants to use it on their own machines alone, they may not want to reserve a public name for it. On the other hand, there’s another reason to provide a separate namespace for this: self-documentation.
My idea is that a new .well-known directory could be set aside for this, which would provide a place to (optionally) self-publish specifications for how to use the namespaced service with standards like SBVC. There’d be a few constraints on doing this unilaterally, of course: you wouldn’t be able to define new service parameters, unless a method of avoiding overlap with the registry were devised. But it would be a considerable improvement on the current state of affairs. Take the following record: > _newservice.example.com._service._tcp.server.example. 86400 IN SRV 0 0 > 1021 target.example. This tells a client that <target.example> offers the service “_newservice.example.com” (“newservice” as defined by the owner of <example.com>) at port tcp/1021 of <server.example>. It also tells a human that relevant documentation may be found at <https://example.com/.well-known/service/newservice>. -----BEGIN PGP SIGNATURE----- iMwEARYKAHQWIQST9JhYTT2FVNyHHwCUsC6j0LZIGwUCYzrdo1YYJ2h0dHBzOi8v b3BlbnBncGtleS5zYWtsYWQ1LmNvbS9maW5nZXJwcmludC9GRERGQzRBNEE2N0Qw NEVGRkVCOEU0MjQ5Q0EyMTQ5NTgzRURCRjg0JwAKCRCUsC6j0LZIGyHfAP9rY/0e Kqw1OcVrla+B4wODAM8xKcSngj0uGlZAmRlMOQD+OCRmILO/tRwgYASjX2074lKW DD6r+WPMatv7KYwWhwo= =NJWR -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
