Paul Vixie wrote: >you can't have it both ways. either you're trying to represent dns data >using the <qname,qtype,qclass> tuple, or you're trying to represent >the query itself. I recognise what Paul describes as the layering violation, but I don't think that it is sufficient to require that the <hostport> syntax should go. Information from two different layers is being presented together, but the two layers are adjacent, so they can be treated as a single layer when looking from the outside. We have similar features in other deployed URL types. (By the way, I see the RD bit, and other things Paul has mentioned, as being at a third layer, below the authority layer. We can sensibly have authority location data without giving details of the DNS query.) What *is* a concern is that some URI schemes have much worse layering issues, such as the overloading of the authority component in the http URL scheme (the authority is used for both location and naming). It is arguable that having the <hostport> syntax in URI schemes encourages the development of this kind of misfeature, and that this mixing of location and naming data should be avoided for this reason. This touches on an issue that I've been wondering about. I'm not entirely clear on what the <dnsqueryelement> extension mechanism is for. What kind of information might it represent? If the URI scheme is intended purely to represent a <name,type,class> tuple then there is no possible use for the extension mechanism -- no additional information that one would ever want to add to the tuple. In considering reasonable usage scenarios I came up with only one additional element that one might want to use: a flag meaning "insist on the data being cryptographically authenticated". On reflection, I think such a flag belongs in the authority section: it's the same layer, and if we are going to include information at both layers then I'd like to keep them syntactically separate. Certainly this flag should exist in the syntax iff the authority section exists. Outside the context of any specific query elements, it seems that the primary purpose (though, if there is an authority section, not the sole purpose) of the URI scheme is to represent a <name,type,class> tuple -- a location in abstract domain name space -- and, that being a closed coordinate system, there is no additional element that can usefully be added to that part of the URI. I'd like to see a syntax (either this URI scheme or a syntactically distinct part of it) to express a pure <name,class,type> tuple, with no general extensibility. If the URI scheme needs an extension mechanism, it should be separate from the <name,class,type> syntax. I have more opinions about how a distinct <name,class,type> tuple syntax should look, which I'll save for a separate message, since this one is dealing more with philosophical issues than concrete syntax. Yet another protocol matter that hasn't been addressed so far: how are domain name labels other than character labels (e.g., binary labels) to be represented in the URI syntax? Most applications that need to represent these kinds of labels in character strings use the master file format defined in the RFCs, but draft-josefsson-dns-url is quite clear that it doesn't use that syntax. It offers no syntax for binary labels, and no extension mechanism for future label types. -zefram -- Andrew Main (Zefram) <zefram@fysh.org>