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

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 3 Nov 2004 15:04:49 +0100

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: James Snell <[email-masked]>
Date: Wed, 3 Nov 2004 08:13:14 -0800

Hello Olaf,

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

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

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

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

>    indicate to indicate which part of a domain name has been

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

>    enforces implementers to strip the XML cruft before putting it into the

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.
>    mystock._ws.example.com XML 0 <EndpointReference (

Thanks, I'll make the change.

-- 
- James Snell
  IBM, Emerging Technologies
  [email-masked]

---

From: James Snell <[email-masked]>
Date: Mon, 8 Nov 2004 08:46:36 -0500

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.

---

From: James Snell <[email-masked]>
Date: Mon, 15 Nov 2004 13:01:11 -0800

Coming out of the face-to-face in Washington, the two most significant
issues was the current design of DNS-EPD's XML Resource Record and the
potential of using NAPTR records as opposed to introducing our own new
record types.

Regarding the latter, after looking through the NAPTR spec again and
going through a number of exercises with it, I'm not convinced that it
can do everything that we need without introducing a significant
amount of unwarranted complexity.  I remain open to being convinced
otherwise, but at this point I'd like to rule out use of NAPTR
records.

Regarding the XML RR, I would like to propose the following updates:

1. Rename the XML RR to EPX or "Endpoint Extension" RR.
2. Redefine EPX in such a way as to allow it to contain one of two
types of information... XML or a Redirection
3. Limit EPX to only specific types of Web services related information
4. Move the WSDL Reference currently in our EPD RR to an EPX record

The new EPR record format would look like:

myservice._ws.example.com EPD FLAGS TARGET PATH QNAME_NSURI QNAME_LOCALPART

* FLAGS: a single byte field with two meaningful bits and six reserved ones
          Bit 0x01: Indicates whether TARGET references an A/AAAA
record or SRV record (no change from previous)
          Bit 0x02: Indicates whether or not EPX records are provided
for the record
          All remaining bits are reserved

* TARGET: Unchanged from current spec
* PATH: Unchanged from current spec
* QNAME_NSURI: In the current spec, a single QNAME field contains both
the NSURI and LOCALPART, it is better to split these into separate
fields
* QNAME_LOCALPART : "

The WSDL Reference Bit and WSDL_REFERENCE fieds are dropped from the
EPD in the next version.

The EPX (formerly XML) RR format would be:

myservice._ws.example.com EPX TYPE_FLAG [XML|REDIRECT]

* XML: ENCODING_FLAG CONTENT
* REDIRECT:  URL MEDIA_TYPE DIGEST DIGEST_ALGORITHM

The EPX record will contain two types of information depending on the
value of the TYPE_FLAG byte field.  If the TYPE_FLAG is unset, the
record will contain a redirection.  If the TYPE_FLAG is set, the
record will contain XML data directly.

An EPX Redirect contains four fields in addition to the TYPE_FLAG:

* URL: The fully qualified URL that should be used to get the data. 
MUST NOT be an empty string
* MEDIA_TYPE: The MIME Media Type of the referenced data (e.g.
application/wsdl+xml .... currently doesn't exist but could be
defined).  MAY be an empty string
* DIGEST: A digest of the referenced content. MAY be an empty string
* DIGEST_ALGORITHM : A URI identifying the algorithm used to generate
the digest. MUST be specified if DIGEST is not an empty string. MUST
be an empty string if DIGEST is an empty string

An EPX containing XML specifies two fields in addition to the TYPE_FLAG:

* ENCODING_FLAG : A single byte value specifying the encoding used for the XML
* XML : A well-formed XML document with restrictions, e.g. no
processing instructions, no formatting whitespace, etc.. all of the
restrictions are discussed in the current spec.

An example of each version of EPX:

; This one is a redirect
myservice._ws.example.com EPX 0
http://example.com/services/myservice.wsdl application/wsdl+xml
1234567890 http://my.digest.algorithm

; This one contains XML directly. The 0 indicates UTF-8 character encoding
myservice._ws.example.com EPX 1 0 <EndpointReference
xmlns="...">...</EndpointReference>

Now, I know that the RDATA of the EPX record is not enforceable by the
DNS infrastructure, so it will be up to the client to validate that
the data contained in the RDATA is appropriate according to what is
specified by the TYPE_FLAG.  Inappropriately formatted EPX records
would be discarded and ignored by the client.

Thoughts?

---

From: Ben Laurie <[email-masked]>
Date: Mon, 22 Nov 2004 10:29:44 +0000

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

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.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Paul Vixie <[email-masked]>
Date: Mon, 22 Nov 2004 16:04:05 +0000

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

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

---

From: James Snell <[email-masked]>
Date: Mon, 22 Nov 2004 11:21:25 -0800

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

> think of, both at the server end and the client end.  xml over dns makes

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.

---

From: James Snell <[email-masked]>
Date: Tue, 23 Nov 2004 12:56:31 -0800

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

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

-- 
- James Snell
  [email-masked]