Simon Josefsson wrote: >The intention was to make sure future extensions aren't disallowed by >the syntax. Yes. I'm wondering what kind of extensions might be permitted. I'm concerned, as with several recent protocols, that perhaps an extension mechanism has been added simply because it's very normal for IETF protocols to have an extension mechanism, with no real thought about what class of semantic features might be expressed by extensions. It wouldn't be the first instance of cargo cult protocol design. If the intent of the dns URI type is to express a <name,type,class> tuple, then presumably any extension would be making the URI express something other than such a tuple, in which case I think it would be better to use a new URI scheme rather than overload an existing one. >Can you elaborate? The intention is that, e.g., a binary label with >the ASCII value 0x17 is expressed as dns:%17. There are some text and >examples for this. No, that's a text label containing a single octet with value 0x17. I was referring to RFC2673 bit labels. Consider also what should be done for other EDNS0 extended label types (RFC2671). -zefram -- Anderw Main (Zefram) <zefram@fysh.org>