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

[James Snell <jasnell@gmail.com>]

Regarding the XML Resource Record that we have included in this spec,
I too have my reservations about it.  Yes, as currently defined it
does suffer from a lot of the same ambiguity problems as the TXT
record with the one exception that the XML data is at least self
describing.

The reasons for having the XML RR in the first place are fairly simple:

1. Many very important Web service descriptors are going to be in
various XML formats (WS-Policy, WS-Addressing, etc), some of which
will be digitally signed.  The goal is to allow clients to query for
this information in one location, preferrably with the XML in tact. 
Redirection is possible, but we'd rather avoid redirecting for
everything. The EPR record will be adequate for the majority of cases,
but we need to be able to support the edge cases as well.

2. The XML descriptors are continuing to evolve and more may emerge
over time.  This is an area that is much more fluid and dynamic than
what DNS typically handles therefore it is important to have a record
type that is some what malleable to avoid having to change an RR or
come up with a new one every time a new WS spec comes out.

That said, however, there are definitely some things we can do to
limit the scope of the record, thereby reducing the potential for
abuse:

First, we can limit the use of the XML record strictly to Web service
related information.  Initially this limit would cover things like
WS-Policy and WS-Addressing.

Second, we can limit the amount of data that goes into the record.  

Regarding the encoding field in the XML RR, thanks for the tip.  I was
unclear as to what extent DNS implementations were allowed to muck
around with things based on the content of the RDATA.  Changing the
various MUSTs to SHOULDs should not be a problem.

On Wed, 3 Nov 2004 15:04:49 +0100, Olaf M. Kolkman <olaf@ripe.net> wrote:
> 
> 
> Hello James and Andrew,
> 
> I have been reading your draft. Having very little experience with the
> web-services architecture there are a few things that I cannot get my
> finger behind.
> 
> The first question I have is on EPR. It is triggered by having
> possible redirection ( WDSL URL or an XML RR), why not simply always
> redirect to a WSDL document describing the service?  It may make life
> much easier if the web service descriptions are dynamic in nature. You
> will not need to bother with caching and other DNS data propagation
> effects such as secondary DNS servers not updating in time.
> 
> I do not feel comfortable with the XML RR. It has more or less the
> same properties as the TXT RR. It has no limitations and may cause
> people to put all kinds of things in the XML RR, such as
> internet-draft XML source (interesting idea :-) ).
> 
> If there is a possibility for redirection I do not understand why the
> XML RR would be needed, what is the perceived benefit?
> 
> I also have a more detailed questions and remarks about the RRs.
> 
> 1.  I think that some of the EPR RDATA elements can be split into
>     their functional parts. For instance the PortType QNAME (confusing
>     name for a data element in the context of DNS :-) ) could be
>     encoded as:
> 
>     |length|namespace-uri|length|localpart
> 
> 2. It is not clear to me why the separator "_ws" is needed in the
>    proposed owner names of EPR records {name}._ws.{domain}. Both
>    client and server will know which part of the name is intended to
>    be the domain part and which part will be the name part.
> 
>    Dropping _ws could introduce an ambiguity (If there exists both a
>    "inquire.uddi" and a "inquire" service and the "inquire.uddi"
>    service has been implemented for the "example.com" domain and the
>    "inquire" service has been implemented for the "uddi.example.com"
>    domain.) But that ambiguity one could solve by adding a simple
>    counter in the RDATA that tells us at which label the split between
>    name and domain occurs. The DNSSIG RR uses a similar mechanism to
>    indicate to indicate which part of a domain name has been
>    synthesized.
> 
> 3. Section 2.3.1.
> 
>   "DNS implementations MUST send the XML data using the encoding
>   specified by the encoding byte flag".
> 
>    DNS implementations will send binary RDATA, they will never look at
>    the content of the RDATA before putting information on the
>    wire. The encoding flag can only be used as an indicator to the
>    client interpreting the RDATA on what the binary RDATA is
>    representing.
> 
>    Most of the MUSTs in this paragraphs are not enforcable and
>    probably should be SHOULDs. (most of them relate to language that
>    enforces implementers to strip the XML cruft before putting it into the
>    RDATA).
> 
> 4. Editing nit: most of your example RRs span multiple lines, you
>    should use brackets to indicate this
> 
>    mystock._ws.example.com XML 0 <EndpointReference (
>                                  xmlns="..."
>                                  ....
>                                  </EndpointReference> )
> 
> Olaf Kolkman
> 
> namedropper (no hats)
> 


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