[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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?

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