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(_at_)fysh(_dot_)org>