On Mon, Jun 09, 2008 at 03:43:29PM +0100, Gervase Markham wrote: > > RFC 3696 explains, I think, most of the reasoning that I would offer > > for why I think this is a bad idea. I urge you and others who are > > planning to ship this kind of feature to go (re)read that RFC. > > Why do you think that the negative consequences explained in that RFC > would apply in this case? Please think carefully about the consequences > of possible failure scenarios.
Because what you are proposing to do adds special meaning to certain labels (and their relative position) and not to others, in exactly the way that previously people had special interpretations of certain labels and their positions in the set of labels. What you're really trying to do here is extract meaning from the domain name, but you can't do that reliably. Previous efforts in that direction have failed in unexpected ways; and given that you seem to have multiple ways you want to use this feature, I don't see any reason to believe you won't have surprising failures too. The plan is both too narrow and too wide. First, it will almost certainly fail to capture 100% of the cases you currently don't want to succeed. Second, it will (as we've been arguing in this thread) not work for new TLDs and other cases. Your counterargument is that the behaviour will then fall back to the current arrangement. This means that different domains behave in different ways, and the user can't rely on any behaviour consistently. > This isn't just about cookies. For example, we would like to group > together related sites (www.mybank.co.uk, accounts.mybank.co.uk) in > history. Grouping together all sites in ".co.uk" does not provide for an > optimum user experience. It seems to me that what you want is metadata about certain domains. Therefore, what you need is a mechanism for publishing metadata, not a magical list of domains about which you'll have hard-coded information. I agree with Ed Lewis's remarks that operators often want such lists. I understand the value of them. I am arguing that coming up with such a list and hard-coding it anywhere is a very bad idea, because users will not get predictable behaviour, particularly in new TLDs and other new areas of the DNS tree. That unpredictability of behaviour means that new services have yet more barriers to surmount before success. I think that's a bad thing. > As I noted in an earlier message, this may solve security problems but > does not solve privacy ones. That seems to be yet more reason to try to fix the cookies specification, rather than trying to impute metadata to the DNS labels. Obviously, it's your code, and you can do what you want with it. But I think this is a very bad idea, and I think it's a shame that it should be adopted anywhere. A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
