Zefram <zefram@fysh.org> writes: > 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". The intention was to make sure future extensions aren't disallowed by the syntax. It could be used to indicate, e.g., that the RD flag should be set or cleared, if someone do find it useful in the future, and document it, and there is consensus for it. > 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. 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. Thanks, Simon