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

["Olaf M. Kolkman" <olaf@ripe.net>]

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)

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