[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DNS-EPD Updates [was Re: New Internet-Draft: DNS-Endpoint Discovery (http://www.ietf.org/internet-drafts/draft-snell-dnsepd-00.txt)]



On Mon, 22 Nov 2004 16:04:05 +0000, Paul Vixie <paul@vix.com> wrote:
> > > 1. Rename the XML RR to EPX or "Endpoint Extension" RR.
> >
> > Since XML is self-describing, why not leave it as a general XML RR?
> 
> because the rrtype has to not only describe the rdata format, but also
> the use to which it will be put.  there was some thought in early dns
> that the rrtype would describe the rdata and the rrclass would describe
> the use; however, rrclass ended up as a zone qualifier, and so the only
> remaining ways to distinguish use cases is to make a subdomain (as was
> done in the SRV RR) or have more than one rrtype describe the same format
> of rdata but with different uses (MX and RP come to mind here.)  there
> might be any number of later rrtypes whose rdata is self-describing XML,
> but they may be used differently than this one.
> 
> i therefore agree with the proposal to call this EPX rather than XML.
> 

Exactly. In the draft update that I am preparing to submit today,
We've taken the further step of requiring that the EPX records only be
used in conjunction with an associated EPR record.  That is, a client
MUST only query for EPX records if a EPD record says that EPX records
are available.  This will further constrain potential abuse and
ambiguity with other rr types that happen to also contain XML (e.g.
the Server ID stuff from Microsoft).

> > However, I still can't see why any of this data belongs in the DNS.
> > Since one needs to know a domain name to fetch this data, I can't see
> > why you wouldn't allocate a port number and serve the XML over TCP on
> > that port. In the WG meeting you said this was because DNS is a defined
> > protocol, but I can't find that a compelling argument - HTTP would seem
> > a far better protocol for serving this data.
> 
> i don't think there's a connectionless XML bearer in common use.  http/tcp
> is a harsh prescription for some real time or embedded applications i can
> think of, both at the server end and the client end.  xml over dns makes
> perfect sense to me.
> 

Again, this is spot on.  Additionally... we actually already tried the
HTTP GET model with WS-Inspection.  I am actually a fan of that
approach (heck, I helped develop it in the first place) and may
actually be spending some time in the near future working on an update
of that spec that brings it in line with WS-Addressing.  The
challenge, however, is that the approach never achieved any form of
success.  So now we're trying this.

At this point in time, please keep in mind that we are not making any
claims that DNS-EPD is THE absolutely best way to do this stuff. 
We're putting it on the table as A way to do this stuff that leverages
existing infrastructure and has some potentially interesting
qualities. Once we figure out the best way to define the records from
a DNS perspective, we fully intend to engage the Web services
community to see if they feel this qualifies as a "Good Thing" or not.
 Our task right now is simply to make sure we're not causing any
problems for the DNS infrastructure and are leveraging that
infrastructure properly from a technical point of view.

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


-- 
- James Snell
  IBM, Emerging Technologies
  jasnell@gmail.com

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