> Just finished reading serverid-04.txt and I consider it a good > document. But one nagging question remains, as it does not specify a new > mechanism, but only lays down the requirements. Are there any plans to > create a followup draft which actually specifies a new mechanism?
i'm planning to submit a draft recommending that "id" be bidirectional (so, both clientid and serverid) with the client's id being the solicitation of the server's id. this doesn't require rev'ing the EDNS version number or anything hard like that. i will propose a registry of attributes so that the client can, if it wants to, offer an opaque universal identifier, a nat-opaque transport address, current latitude and longitude, preferred human language, and other things to be defined later. this is primarily for mobility support, since i'm not confused into thinking that the internet is the web or vice versa. but since we've not succeeded in keeping dns server operators from producing policy-based rather than fact-based answers, i think it's time that we fully support non-universal dns. obviously this will require that caching be disabled in policy-based responses. and it's a loophole that the alternate-roots crowd will just love. but it's time to answer the community's needs in this regard. to that end, i don't think that the current draft goes nearly far enough. -- Paul Vixie . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
