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

[James Snell <jasnell@gmail.com>]

Hello Olaf,

Thanks for taking a look at the spec. Comments below.


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

At the most basic level, a Web service client needs to know three
pieces of information in order to contact with a service endpoint: a)
The URL of the service, b) the protocol binding to use (HTTP, etc),
and c) the QName of the WSDL defined portType implemented by the
service.  The portType tells clients what message exchanges the
service is capable of supporting.  Some portType QNames will be well
known, others will not.  In the case that a portType is well known, a
redirection to a WSDL document is entirely optional and is only needed
if additional policy and binding information is required to enable the
interaction.

Further, we are specifically targeting DNS-EPD towards use with
relatively static infrastructure level Web services whose descriptions
remain fairly stable over time.  More dynamic business level services
are better served by high level discovery mechanisms such as UDDI, or
possibly LDAP or SLP.  For example, if a company deploys UDDI services
within their Intranet environment to support some business critical
processes, the WSDL description of that service is going to remain
static over 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 :-) ).
> 

:-) I quite expected folks to be uncomfortable with this, it will
definitely be something that we need to have further discussion about.
 I will prepare a separate note with specific discussion about the XML
RR and why it is needed and post that a bit later today.

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

Yeah, I thought of this after rereading the published draft and
already had it marked in my notes as a potential change.  This
encoding would be more natural from a DNS standpoint and would save a
byte of information.  The original {uri}localname syntax was selected
mostly as a default because it is the syntax used by the standard Java
implementation of the QName datatype.  (No language bias here ;-)
.....).   I'll make the change.

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

The _ws separater was selected specifically to allow DNS-EPD records
to be segregated and organized by distinct, unambiguous domains.  We
expect various name fragments to become somewhat well known in the
industry, such as inquire.uddi._ws and publish.uddi._ws, in much the
same way www has become ubiquitous.  A service with the label
inquire._ws in the domain uddi.example.com may be significantly
different than a service with the label inquire.uddi._ws in the domain
example.com.  Exactly as you point out, elimating the _ws tag would
make this too ambiguous.

Another advantage of the _ws tag is that it allows DNS-EPD records to
be split out completely and delegated as a set to a different DNS
server so that they may be managed separately.  In some of our use
case models, for instance, Dynamic DNS Update is used to update EPR
resource records.  If I understand current DNS management best
practices correctly, it is ideal is isolate such records to a
dedicated DNS server that separates them from more mission critical
static records.  The _ws label allows us to delegate all DNS-EPD
records as a whole.  Now, I'll be the first to admit that I am not a
DNS management expert and may be completely off base here so if I'm
wrong about this, please correct me, but be gentle ;-) ;-)

> 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).

Ok, I had suspected that this might be a problem.  I will deal with
this in my separate email focusing specifically on the XML resource
record.
> 
> 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> )
> 

Thanks, I'll make the change.

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