Subject: RE: an example of why flag bits are bad things

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 21 May 2003 15:58:33 -0700

> > http://www.ietf.org/internet-drafts/draft-josefsson-dns-url-08.txt
> > 
> > This is a draft that is defining an URI based on dns.  For example:
> > 
> >     dns:www.example.org?class=IN;type=A
> > 
> > as the encoding for QNAME, QCLASS, and QTYPE.
> > 
> > This scheme won't be able to convey DS-ok or DNSSEC-ok, and perhaps 
> > that's not desired, as it wouldn't be up to the application to care 
> > (or will it want to know if DNSSEC was 'done'?).

Why not define the appropriate flags? And why not use the HTTP
query syntax rather than defining a new separator? 

dns:www.example.org?class=IN&type=A&DNSSEC=1

Although I am not sure this is necessary to encode in the URL, you don't
encode content-type into a URL request, it is a logical link. The DNSSEC
issue would be a logical property of the client making the request not the
link.

		Phill

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Thu, 22 May 2003 08:25:42 -0400

At 8:30 +1000 5/22/03, [email-masked] wrote:
>	This was written well after EDNS was put onto standards
>	track.  Failure to allow for flags is a error in this draft
>	not in DNS.

On the one hand, yes, Simon's draft can be extended to cover these 
'omissions.'  But consider that:

1) The additions 'ruin' the sweet simplicity of the idea
2) Future flags will mean as yet unknown additions

Moral 1 is that the DNS, being at the center of the universe, has to 
remain as bland as possible to be stable.  The more functionality, 
the more negotiated options you throw in, the more you have to diddle 
with lines of code and version interactions.  As tempting as one more 
feature is, beware the call of the Sirens.

Moral 2 is that we must think of what will happen to future 
engineering of the DNS.  Hacking on something to solve today's 
problem might endanger a greater feature down the road.  Often times 
we are so concerned about interoperability with elements that exist 
today we fail to consider interoperability with the future.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Your office is *not* a reality-based sit-com TV show.

---

From: [email-masked]
Date: Fri, 23 May 2003 08:15:28 +1000

> 2) Future flags will mean as yet unknown additions

	Future types will mean as yet unknown additions or are you
	going to treat all future types as unknown?

	Developments happen.  You design the protocol to allow for them.

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Fri, 23 May 2003 08:21:49 -0400

>	going to treat all future types as unknown?

We already know the format of the name of the future types - a 
number.  We don't always know the format of the flags.  E.g., was 
EDNS0 forseeable from RFC 1035?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: [email-masked]
Date: Sat, 24 May 2003 08:29:21 +1000

> EDNS0 forseeable from RFC 1035?

	Ed what are you smoking?

	You really expect humans to remember numbers instead of
	mnenonics.  They don't do that today with dig or nslookup.
	What makes you think they will with any new types.

	Or are you seeing this as purely for machine consumption.  If
	so we may as well just encode the dns messages directly and
	be done with it.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 23 May 2003 18:44:14 -0400

>	Ed what are you smoking?

Hey - the last RIPE meeting *wasn't* in Amsterdam.

>	so we may as well just encode the dns messages directly and

Yeah...but the point is that by sticking to just a few query 
parameters (The Q's), it's easier to extend.