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

[James Snell <jasnell@gmail.com>]

FYI... the -01 version of the DNS-EPD specification has been posted.  

http://www.ietf.org/internet-drafts/draft-snell-dnsepd-01.txt


On Mon, 22 Nov 2004 11:21:25 -0800, James Snell <jasnell@gmail.com> wrote:
> 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
> 


-- 
- James Snell
  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/>