Subject: Re: concerning draft-josefsson-dns-url-08.txt

From: Zefram <[email-masked]>
Date: Tue, 1 Jul 2003 09:58:57 +0100

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) <[email-masked]>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 03 Jul 2003 04:30:04 +0200

--On lørdag, juni 28, 2003 00:47:26 +0000 Paul Vixie <[email-masked]> 
wrote:

> dns is a distributed, autonomous, coherent, reliable database.  a syntax
> that allows entity A and entity B to speak incoherently about a given
> <qname, qtype,qclass> would violate the coherency of the design.  the
> only exception would be if you intended to be able to represent all
> attributes of a dns query, which i think would be useless, but would
> allow hostport but require RD, buffer size, and other EDNS OPT options to
> be invented later.

just because I feel like fiddling around with definitions...

using the definitions of RFC 3254, "Definitions for talking about 
directories" (ok, I'm quoting myself again :-), I'd say:

- the global DNS service is a global, cooperative repository - "there can 
be only one", and the pieces pass stuff around between each other.

- there exist local repositories that use the DNS protocol for access, but 
that are not the global repository (split horizon installations and 
"alternate root" stuff, for instance).

Hostport may or may not be useful for identifiying access to those 
services; as the IRC community has learned, and the WWW folks may be 
learning, identifying the place where a service is available is not a 
functional replacement for naming the service, but that doesn't prevent 
people from using it as if it was.

("hostport" does seem a bit recursive, though; in what DNS service is the 
"host" part of the "hostport" to be looked up?..... RFC 2396 is silent on 
the issue....)

                   Harald