One document matched: draft-snell-dnsepd-01.txt
Differences from draft-snell-dnsepd-00.txt
Internet-Draft J. Snell
draft-snell-dnsepd-01.txt A. Donoho
Expires: May 23, 2005 IBM
November 2004
DNS Endpoint Discovery (DNS-EPD)
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
This document may not be modified, and derivative works of it may
not be created, except to publish it as an RFC and to translate it
into languages other than English.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 23, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This memo introduces two new DNS Resource Record types for the
DNS-based discovery of Web service endpoints.
Snell & Donoho Expires: May 23, 2005 [Page 1]
Internet-Draft DNS-EPD November 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Bootstrapping Web service infrastructure . . . . . . . . . 3
1.2 Mapping Web service artifacts into the domain name
space . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. DNS-EPD Resource records . . . . . . . . . . . . . . . . . . . 5
2.1 Establishment of DNS names for Web services . . . . . . . 6
2.2 Endpoint Reference (EPR) Resource record . . . . . . . . . 6
2.2.1 EPR RDATA format . . . . . . . . . . . . . . . . . . . 7
2.2.2 EPR Presentation format . . . . . . . . . . . . . . . 10
2.3 Endpoint Extension (EPX) Resource record . . . . . . . . . 11
2.3.1 EPX RDATA format . . . . . . . . . . . . . . . . . . . 11
2.3.2 EPX Presentation format . . . . . . . . . . . . . . . 13
2.3.3 EPX RR semantics . . . . . . . . . . . . . . . . . . . 14
2.4 Enumerating EPR records . . . . . . . . . . . . . . . . . 15
3. Performance considerations . . . . . . . . . . . . . . . . . . 15
4. Security considerations . . . . . . . . . . . . . . . . . . . 15
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1 Endpoint reference with A TARGET and EPX records . . . . . 17
6.2 Endpoint reference with SRV TARGET and EPX XML Encoded
record . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.3 Endpoint reference with A TARGET and EPX Redirect
Encoded Record . . . . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 18
7.2 Informational References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 20
Snell & Donoho Expires: May 23, 2005 [Page 2]
Internet-Draft DNS-EPD November 2004
1. Introduction
This document introduces mechanisms for DNS-based discovery of Web
service endpoints. Introduced are two new DNS resource record types
and the conventions for their use. A fundamental understanding of
the DNS protocol and the core DNS resource record types as described
in RFCs 1034 [2], 1035 [3] and 2782 [7] is assumed.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
1.1 Bootstrapping Web service infrastructure
The Web services architecture defines an abstract model for the
publication and discovery of Web services. Upon deploying a Web
service instance, the service provider advertises the services
existence in a registry capable of allowing potential consumers to
locate the information necessary to bind to and consume the service.
The minimal amount of information necessary to allow a client to
consume the service is the network location at which the service has
been deployed and the identity of the so-called "PortType"
implemented by the service. The "PortType" is a description of all
the input and output messages supported by the Web service as
described in a WSDL document. This PortType is identified by an XML
namespace plus simple name pair known as a Qualified Name or QName.
Knowing the PortType implemented by a Web services allows one to know
exactly which types of messages to send to a service endpoint and
which types of messages to expect that service to return. PortTypes
and their QNames are defined within Web Service Description Language
(WSDL) documents [8].
In a Service Oriented Architecture, there are several classifications
of services available for an application to consume. Some are
business-level services whose Port Types are specific to given
applications. Others are infrastructure-level services whose Port
Types are well known and consistent across multiple types of
applications. An example of a business-level service would include a
service a company may deploy to accept purchase orders from
customers. An example of a well-known common infrastructure-level
service is the Universal Description, Discovery and Integration
(UDDI) service as defined by [9].
An application's choice to use specific business-level services may
be based on a variety of complex criteria including service level
agreements, geographic location, contractual obligations, etc and
therefore potentially requires complex discovery mechanisms beyond
Snell & Donoho Expires: May 23, 2005 [Page 3]
Internet-Draft DNS-EPD November 2004
simple resolution of endpoint location and Port Type QName.
Infrastructure level services, however ‚Çô particularly those
deployed within a protected or private domain such as an intranet ‚Çô
are generally selected based simply on their availability within a
given domain. For example, if one wishes to use UDDI services to
locate business services within an intranet, one would simply look
for any and all UDDI services available within that intranet domain.
In such cases, it is sufficient to resolve nothing more than the
location and PortType QName of the service in question.
DNS-EPD introduces a process for resolving the location of common
services that is similar in nature to using the telephone white pages
directory. As opposed to the telephone yellow pages, which organize
numbers into a complex taxonomy organized by service category, the
white pages provide nothing more than a simple name-to-number
mapping. That is, if I wanted to find a phone number for any French
restaurant in New York City, I would use the yellow pages to browse
all available French restaurants and select one that suits my needs.
If, however, I wanted to find the phone number for a specific French
restaurant in New York City, I would use the white pages to look up
the name of that specific restaurant and find its phone number. With
DNS-EPD, if a client wishes to locate a specific instance of a Web
service, it would go to DNS and resolve the current location of that
service by name.
A second key issue is that once a Web service's location has been
resolved, how can one automatically detect changes that may occur in
the configuration and deployment of those services? While
administrators can hard code references to Web services into every
deployed Web services component, doing so makes the infrastructure
inherently brittle and difficult to manage. In a world of
dynamically, and intelligently managed infrastructure, administrators
need systems capable of automatically responding to changes in their
networked environment. DNS-EPD's approach is to assign names to
services and to allow components a means of using those names to
dynamically resolve ‚Çô at run-time ‚Çô the metadata necessary to
access those resources, allowing applications to intelligently
respond to changes and promoting loose coupling between applications
and the supporting infrastructure.
1.2 Mapping Web service artifacts into the domain name space
Outside of DNS, the primary means of referencing Web service
endpoints is the Web Service Addressing [10] Endpoint Reference
(EPR). An EPR is a relatively simple XML structure that, at a
minimum, specifies the network location of the service endpoint and
the QName of the PortType implemented by the service. Additional
pieces of information may be included, such as a digital signature
Snell & Donoho Expires: May 23, 2005 [Page 4]
Internet-Draft DNS-EPD November 2004
verifying the authenticity of the endpoint reference and a policy
detailing various constraints and requirements that must be met in
order to consume the service. An example WS-Addressing Endpoint
Reference is below.
<EndpointReference
xmlns="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns:abc="urn:MyStockQuotes">
<Address>http://example.com/services/mystocks</Address>
<PortType>abc:MyStockQuotes</PortType>
</EndpointReference>
A key design goal of DNS-EPD is to not introduce yet another set of
artifacts usable to reference and identify Web service endpoints;
rather, the DNS-EPD conventions define a means of mapping
WS-Addressing Endpoint References into the Domain Name Space.
The Endpoint Reference Resource Record described in section four is
the semantic equivalent to the basic WS-Addressing Endpoint Reference
illustrated above.
mystocks._ws.example.com EPR 10 0 0 example.com (
/services/mystocks
urn:MyStockQuotes
MyStockQuotes )
For the DNS-EPD mechanisms to be successful, however, there must be a
means of incorporating the more extensive descriptions supported by
WS-Addressing Endpoint References with the information contained in
DNS. DNS-EPD does so by introducing an Endpoint Extension or EPX
record that may be optionally used to provide additional information
either by reference or direct containment.
This information may include artifacts such as the complete
WS-Addressing Endpoint Reference for a service, or a Web Service
Policy document associated with the service, or even a WSDL document
that describes the PortType implemented by the service.
The combination of the EPR and EPX resource records allows one to
fully and naturally map existing Web service artifacts into the
domain name space.
2. DNS-EPD Resource records
This section introduces the Endpoint Reference (EPR) and Endpoint
Extension (EPX) resource record types and a means of browsing the
domain name space for EPR resource records.
Snell & Donoho Expires: May 23, 2005 [Page 5]
Internet-Draft DNS-EPD November 2004
2.1 Establishment of DNS names for Web services
DNS names associated with DNS-EPD resource records MUST follow the
{name}._ws.{domain} pattern, where {name} is an arbitrary set of one
or more DNS labels relevant to the type of service being advertised,
_ws is a special DNS label indicating that the DNS name refers to a
Web service, and {domain} is the DNS domain within which the Web
service has been deployed.
Examples of such names follow:
inquire.uddi._ws.example.com
mystocks._ws.example.com
wsnbroker._ws.example.com
The {name} portion in these examples ("inquire.uddi", "mystocks", and
"wsnbroker" respectively) are assigned by DNS administrators or
industry specific standards bodies and SHOULD be selected in a manner
that would allow a human reading the name to be able to identify the
type of Web service being described. It is expected that best
practice naming conventions will evolve through the consistent
application of the DNS-EPD specifications much in the same way that
the "www" naming convention has been adopted for the naming of Web
servers. It is also foreseeable that names for various common Web
service types will be codified within specifications that define the
service type. The bottom line is that the method such conventions
are defined is considered out of scope for this document.
It must be pointed out, however, that to be effective and to avoid
confusion, names identifying service types should be unique, even
across domains. For example, the name prefix inquire.uddi._ws.
should identify UDDI Inquire services regardless of the domain in
which the services are being advertised. The only way to achieve
global uniqueness of such names is to codify the name and meaning in
a standards specification. To this end, the _ws label works more as
a tool to avoid naming collisions between services of different
types; that is, the name inquire.uddi._ws running within the
example.com domain is different than the name inquire._ws running
within the uddi.example.com domain, omiting the _ws label would make
it difficult to differentiate between the two service references.
2.2 Endpoint Reference (EPR) Resource record
Web Service Endpoint References are represented in DNS using the EPR
resource record. The format of the EPR RR is given below. The DNS
type code for the EPR RR is TBD.
Snell & Donoho Expires: May 23, 2005 [Page 6]
Internet-Draft DNS-EPD November 2004
2.2.1 EPR RDATA format
The RDATA of the EPR record consists of seven required fields.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|FLAGS| P| W| TARGET /
+-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| LENGTH | PATH (Variable Length) /
+-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| LENGTH | QNAME_URI (Variable Length) /
+-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| LENGTH | QNAME_LP (Variable Length) /
+-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2.2.1.1 Flags
An 8-bit unsigned byte field specifying option flags for the EPR
record. The bit field consists of three defined bits and five
reserved bits.
The first bit (least-significant, 0x01) is an "information bit" that
indicates whether or not EPX records have been provided. By default
this bit should be unset.
Bits 2 and 3 are mutually exclusive "target bits" that indicate
whether or not the EPR resource record's TARGET field references an
A/AAAA record or an SRV record.
Bit 2 (0x02), if set, indicates that the TARGET field references an
A/AAAA resource record. This bit will be referred to as the A TARGET
BIT. This is the default.
Bit 3 (0x04), if set, indicates that the TARGET field references a
SRV resource record. This bit will be referred to as the SRV TARGET
BIT. By default this bit is unset.
The A and SRV target bits are mutually exclusive. At most one of the
bits MUST be set. If both are set, the most significant bit (the SRV
TARGET BIT) set takes precedence. One of the bits MUST be set.
The remaining five bits are reserved for future use and MUST remain
unset.
For example, the flags field for an EPR specifying no additional
information and a reference to an A/AAAA record would equal 00000010.
Snell & Donoho Expires: May 23, 2005 [Page 7]
Internet-Draft DNS-EPD November 2004
An EPR specifying additional EPX records and a reference to an SRV
record would be 00000101.
SRV TARGET BIT
|
|A TARGET BIT
||
00000101
|___| |
| |
| |
| INFORMATION BIT
Reserved bits
2.2.1.2 Priority
An 8-bit unsigned byte field (range 0-255) specifying a numeric
priority for this endpoint reference record relative to other
endpoint reference records associated with the same name. A client
MUST attempt to use the endpoint reference with the lowest-numbered
priority it can reach. Endpoint references with the same priority
SHOULD be tried in an order determined by the value of the WEIGHT
field described below.
2.2.1.3 Weight
An 8-bit unsigned byte field (range 0-255) specifying a relative
weight for endpoint references with the same PRIORITY. Endpoint
references specifying larger weight values SHOULD be given a
proportionally higher probability of being selected for use. A
Weight of 0 should be assigned when no endpoint reference selection
should be performed (e.g. when there is only a single Endpoint
Reference or when multiple endpoint references should be selected at
random with an equal probability of selection).
Ordering of Endpoint Reference records of the same PRIORITY should be
performed according to the following algorithm, starting with the
EPR's with the lowest PRIORITY value.
o Order all EPRs in ascending order according to WEIGHT
o Compute the sum of the WEIGHTs for each EPR, associating the
running sum of the weights with each EPR in order.
o Choose a uniform random number between 0 and the computed sum of
weights.
o Select the first EPR whose associated running sum value is equal
to or greater than the random number selected.
Snell & Donoho Expires: May 23, 2005 [Page 8]
Internet-Draft DNS-EPD November 2004
o Remove the selected EPR from the collection and add it to a second
list of ordered EPRs.
o Repeat the process until each of the EPRs in the original list has
been selected and added to the list of ordered EPRs.
o Repeat the process for each PRIORITY level.
Once all EPRs have been ordered in this fashion, a client will select
each EPR in the list, using the first that it is capable of using to
bind to and invoke the service.
2.2.1.4 Target
A DNS domain name that will be associated with either A/AAAA resource
record(s) if the FLAGS field A TARGET BIT is set or SRV resource
record(s) if the FLAGS field SRV TARGET BIT is set. The TARGET field
is used to specify the network location where the Web service has
been deployed and the network application protocol used to invoke the
service. If referencing A/AAAA records, the network application
protocol is assumed to be HTTP using the default TCP port 80. If
referencing SRV records, the network application protocol will be
specified by the referenced SRV record. Further, if the TARGET field
references multiple SRV records, those SRV records are to be ordered
and selected as specified in [7]. If the TARGET field references
multiple A records, those A records are to be ordered and selected in
any manner the requester deems appropriate.
2.2.1.5 Path
A UTF-8 encoded <character-string> specifying the additional URI path
information for the Web service endpoint including appropriate query
string parameters and fragment identifiers. For instance, if a Web
service is deployed at the HTTP URL
http://www.example.com/services/inquire, PATH will equal /services/
inquire. As the value of PATH is intended to be used in a URI,
characters in the path MUST be properly escaped as defined in [6].
In the RDATA encoding, PATH MUST be preceded by a 2-byte unsigned
integer in network byte order (big-endian) specifying the total
length in octets of the field data. The value of the PATH field MAY
be an empty string in which case the specified length in octets MUST
be 0.
2.2.1.6 PortType QName Namespace URI
A UTF-8 encoded <character-string> specifying the Namespace URI of
the WSDL defined PortType QName implemented by the Web service
described by the EPR record. In the RDATA encoding, QNAME_URI MUST
be preceded by a 2-byte unsigned integer in network byte order
specifying the total length in octets of the field data. The value
Snell & Donoho Expires: May 23, 2005 [Page 9]
Internet-Draft DNS-EPD November 2004
of the URI MAY be an empty string.
2.2.1.7 PortType QName Namespace Local part
A UTF-8 encoded <character-string> specifying the Local part of the
WSDL defined PortType QName implemented by the Web service described
by the EPR record. In the RDATA encoding, QNAME_LP MUST be preceded
by a 2-byte unsigned integer in network byte order specifying the
total length in octets of the field data. The value of the Local
part MUST NOT be an empty string.
2.2.2 EPR Presentation format
The presentation format for EPR records is as illustrated below.
FLAGS PRIORITY WEIGHT TARGET PATH QNAME_URI QNAME_LP
MyStockQuotes._stockquotes._ws.example.com EPR (
10 0 0 services.example.com
/services/stockquotes
urn:mystocks
MyStockQuotes )
In this format, the FLAGS field is represented as a two digit numeric
value with the first digit (from the left) representing the target
bits and the second digit representing the information bit. A target
bit (first digit) value of 1 indicates that the A TARGET BIT is set.
A target bit value of 2 indicates that the SRV TARGET BIT is set. An
information bit value of 1 indicates that the INFORMATION BIT is set
and EPX records are available. An information bit value of 0
indicates that the INFORMATION BIT is not set and EPX records are not
available. For example, an EPR referencing an A/AAAA target and no
additional information would specify 10 for the flags field in the
presentation format. An EPR referencing an SRV target and EPX
records would specify 21 for the flags field in the presentation
format. All of the available permutations are illustrated below.
10 - A/AAAA Target, no EPX records available
11 - A/AAAA Target, EPX records available
20 - SRV Target, no EPX records available
21 - SRV Target, EPX records available
The PRIORITY and WEIGHT fields are each represented as unsigned
integer values in the range 0-255.
The PATH, QNAME_URI and QNAME_LP fields MUST be present. PATH and
QNAME_URI MAY be empty strings.
Snell & Donoho Expires: May 23, 2005 [Page 10]
Internet-Draft DNS-EPD November 2004
2.3 Endpoint Extension (EPX) Resource record
One of the key goals of this specification is to provide the means of
querying DNS to locate and resolve complete information about a Web
service endpoint. The collection of Web services related
specifications/standards define a number of XML formats useful for
describing various characteristics of Web service endpoints. This
specification provides for two means of querying this information by
allowing an EPR resource record to specify that such information may
either be accessed directly from DNS or via a redirect to a given
URL.
The Endpoint Extension (EPX) resource record is a flexible record
that is capable of either directly containing XML describing various
aspects of the Web services endpoint or a URL redirection to a
network location where such information can be retrieved. The format
of the EPX record varies depending on how it is being used.
The DNS type code for the EPX RR is TBD.
2.3.1 EPX RDATA format
There are two possible RDATA formats for the EPX record, both
variants are shown below. The first is called the EPX Redirect
Encoding and is used when using the EPX record to specify a
redirection to a URL. The second is called the EPX XML Encoding and
is used to directly contain XML document fragments that describe the
Web service endpoint.
Redirect Encoding:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|TYPE |SIZE | URL (Variable Length) /
+-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|SIZE | MEDIA_TYPE (Variable Length) /
+-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--/
|SIZE | DIGEST (Variable Length) /
+-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--/
|SIZE | DIGEST_ALG (Variable Length) /
+-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--/
XML Encoding
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-----+----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|TYPE |ENC | XML /
+-----+----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Snell & Donoho Expires: May 23, 2005 [Page 11]
Internet-Draft DNS-EPD November 2004
In either option, the initial TYPE unsigned byte flag is used to
identify the specific encoding used. A byte value of 0x00 indicates
Redirect Encoding, a byte value of 0x01 indicates XML Encoding.
2.3.1.1 Redirect Encoding
The Redirect Encoding consists of four variable length fields, each
preceded by a two byte unsigned integeter value (in network byte
order) specifying the length in octets of the field.
2.3.1.1.1 URL
The URI field is a UTF-8 encoded <character-string> specifying a
fully qualified URL referencing an XML document that describes some
aspect of the Web service endpoint. The URL MUST be resolvable into
a single well-formed XML document. The URL field MUST NOT be an
empty string.
2.3.1.1.2 MEDIA_TYPE
The MEDIA_TYPE field is a UTF-8 encoded <character-string> specifying
the MIME Media Type of the document identified by the URL field.
This field MAY be an empty string.
2.3.1.1.3 DIGEST
The DIGEST field is a series of bytes representing a digest of the
XML document referenced by the URL field. This field is optional and
may be zero length.
2.3.1.1.4 DIGEST_ALG
The DIGEST_ALG (digest algorithm) field is a UTF-8 encoding
<character-string> containing a URI identifying the algorithm used to
generate the value of the DIGEST field. If DIGEST is not zero
length, a digest algorithm MUST be specified, otherwise DIGEST_ALG
MUST be an empty string.
2.3.1.2 XML Encoding
In the XML Encoding, the EPX record consists of two fields, the first
of which is a byte flag indicating the specific encoding used for the
XML data contained in the second field.
The encoding byte flag specifies an unsigned integer value (range
0-255) that indicates how the XML contained in the RDATA has been
encoded. The default value of 0x00 indicates that the remaining
RDATA is a UTF-8 encoded character-string containing XML 1.0.
Snell & Donoho Expires: May 23, 2005 [Page 12]
Internet-Draft DNS-EPD November 2004
Additional values for the encoding byte flag MUST be defined by a
specification and registered with IANA. If the encoding specified is
not understood by the party requesting the EPX record, the record
MUST be ignored.
It has to be pointed out that there is no way for DNS to enforce that
the actual encoding of the XML data matches that specified by the
encoding byte flag. Therefore, clients MUST be prepared to properly
handle potential mismatches. EPX records in which the encoding of
the data does not match the value of the encoding byte flag SHOULD be
ignored.
The XML contained in the EPX record MUST NOT contain a prolog, a
document type declaration, processing instructions, or unnecessary
whitespace such as that typically used for formatting and indenting
XML documents. See the next section for a discussion of the use of
formatting whitespace in the presentation format.
The XML contained in the XML Information record SHOULD NOT use
relative URI's. If relative URI's are used within the document, The
xml:base attribute MUST be used to specify a base for those URIs.
2.3.2 EPX Presentation format
As with the RDATA encoding, the presentation format for the EPX
record differs depending on whether the Redirect or XML encoding
is used.
For Redirect Encoding, the RDATA consists of a single unsigned
integer representing the TYPE field followed by four
<character-string>s representing each of the four redirect encoding
fields. The value of the DIGEST field is represented as zero or more
words of hexidecimal data encoding the value of the digest. Empty
strings are represented using a single period (.) character. The
value of the TYPE field must equal 0 to identify that Redirect
encoding is being used.
The example below shows a redirect to a WSDL document using a
fictional application/wsdl+xml Mime media type with no digest or
digest algorithm specified.
mystocks._ws.example.com EPX 0 (
http://example.com/services/mystocks.wsdl
application/wsdl+xml . .
)
For XML encoding the RDATA for the presentation format consists of a
single unsigned integer for the TYPE field followed by a single
Snell & Donoho Expires: May 23, 2005 [Page 13]
Internet-Draft DNS-EPD November 2004
unsigned integer (range 0-255) specifying the encoding byte flag and
zero or more words of hexidecimal data encoding the XML document.
The value of the type field MUST equal 1 to identify that XML
Encoding is being used.
mystocks._ws.example.com EPX 1 0 (
3c456e64706f696e745265666572656e636520786d6c
6e733d222e2e2e2220786d6c3a626173653d22687474
703a2f2f6578616d706c652e636f6d223e3c41646472
6573733e2f73657276696365732f73746f636b733c2f
416464726573733e3c2f456e64706f696e7452656665
72656e63653e )
2.3.3 EPX RR semantics
EPX records are used solely as a means of allowing DNS administrators
to publish "additional information" about a Web service endpoint
being advertised in DNS. It is up to the client to interpret the
meaning of the XML contained within the record and determine whether
or not the additional information is useful and relevant. Upon
querying for EPR resource records, a client would determine whether
or not additional information is provided by checking the information
bit in the flags portion of the EPR RDATA. If information bit is
set, the client MAY choose to submit a query for any EPX records
associated with the same DNS name as the EPR resource record. If
such a query is submitted, the DNS server would respond with all
associated EPX records. The client would receive these records,
parse their RDATA and then determine the utility of the information
returned.
A DNS client MUST NOT submit any queries for EPX resource records
unless the EPR resource record's information bit is set. EPX records
MUST NOT be used for any other purpose than in association with an
EPR record.
It should be noted that much existing deployed DNS infrastructure
places strict practical limits on the size of DNS request and reply
messages. To work best within these constraints, limits should be
placed on the size and complexity of the XML stored within DNS using
the XML encoding of EPX records. In general, the size of the XML
fragments contained in DNS should be small enough to fit within a
single UDP datagram that is short enough not to require IP
fragmentation. If the XML is not small enough to fit within this
size constraint, then the Redirect encoding should be used and the
XML stored in a location external to the DNS system.
Snell & Donoho Expires: May 23, 2005 [Page 14]
Internet-Draft DNS-EPD November 2004
2.4 Enumerating EPR records
DNS Administrators may allow clients to enumerate all services
advertised within a given DNS domain by associating PTR resource
records with the special _services._ws.{domain} name, where {domain}
is the DNS domain within which Web services have been advertised.
The RDATA of the PTR records associated MUST specify the names of EPR
resource records advertised within the domain.
For example:
> nslookup ‚Çôq=PTR _services._ws.example.com
_services._ws.example.com PTR mystocks._ws.example.com
PTR inquire.uddi._ws.example.com
PTR publish.uddi._ws.example.com
3. Performance considerations
The DNS-EPD resource records have been designed to maximize the
efficiency of queries, allowing clients to request only the bits of
information they absolutely require.
EPR and EPX records are cacheable but the TTL values will be variable
based on the types of Web services they are referring to.
Infrastructure level services (e.g. UDDI services) should have
fairly stable endpoint references that do not change frequently and
thus can have long TTL values.
XML fragments stored in DNS are of significant concern given their
arbitrary nature and potential size. Great care must be taken in
their use and appropriate consideration needs to be given to their
cacheability and the decision to store them in DNS at all (as opposed
to using the Redirect encoding option and storing the XML outside of
DNS).
4. Security considerations
DNS-EPD resource records are subject to the same security concerns as
other existing DNS resource record types. These concerns include
spoofing, cache poisoning, and other known types of attacks.
Addressing how to secure DNS-EPD records from such attacks is
considered out of scope for this document. DNS administrators should
defer to other specifications or methodologies for securing their DNS
environments to ensure that such attacks are dealt with
appropriately.
Specifically, in the absence of DNS-native security measures,
Snell & Donoho Expires: May 23, 2005 [Page 15]
Internet-Draft DNS-EPD November 2004
information requested from DNS would need to be authenticated and
cryptographically verified for integrity and/or confidentiality using
mechanisms external to the DNS protocol. For DNS-WSD, this could
include the use of specifications such as OASIS WSS to authenticate
the endpoints advertised in the DNS registry following discovery but
prior to service invocation, or integrity and/or confidently
protecting the DNS-WSD artifacts stored in the DNS.
DNS-EPD introduces no new security concerns to either DNS or the Web
services architecture as the existing Web services architecture is
already dependent on the existing security (or lack thereof) of DNS
architecture.
Further, DNS Administrators should segregate mission critical
statically managed DNS services from DNS services that allow dynamic,
and possibly arbitrary, zone updates and properly delegate the
administration of zones containing Web service advertisements.
Other existing DNS administration best practices should continue to
be followed.
5. IANA considerations
This specification would require IANA to allocate RR type codes for
the EPR and XML resource records.
The registration of new encoding byte flag values for the EPX
resource record would need to be allocated by IANA and described by a
specification document. Submission documents detailing new encoding
byte flag values MUST specify, at a minimum, whether or not the value
identifies a character or binary encoding and MUST specify the
version of XML used.
6. Examples
Snell & Donoho Expires: May 23, 2005 [Page 16]
Internet-Draft DNS-EPD November 2004
6.1 Endpoint reference with A TARGET and EPX records
mystocks._ws.example.com EPR 10 0 0 (
services.example.com
/services/stockquotes
urn:mystocks
MyStockQuotes
)
Equivalent WS-Addressing EndpointReference
<EndpointReference>
<Address>
http://services.example.com:80/services/stockquotes
</Address>
<PortType xmlns:ns="urn:mystocks">ns:MyStockQuotes</PortType>
</EndpointReference>
6.2 Endpoint reference with SRV TARGET and EPX XML Encoded record
mystocks._ws.example.com EPR 21 0 0 (
_http._tcp.example.com
/services/stockquotes
urn:mystocks
MyStockQuotes
)
mystocks._ws.example.com XML 1 0 (
3c456e64706f696e745265666572656e63653e3c
416464726573733e687474703a2f2f2e2e2e3c2f
416464726573733e3c5265666572656e63655072
6f706572746965733e3c6120786d6c6e733de280
9975726e3a666f6fe280993e6162633c2f613e3c
2f5265666572656e636550726f70657274696573
3e3c2f456e64706f696e745265666572656e6365
3e )
_http._tcp.example.com SRV 0 0 80 services.example.com
Snell & Donoho Expires: May 23, 2005 [Page 17]
Internet-Draft DNS-EPD November 2004
6.3 Endpoint reference with A TARGET and EPX Redirect Encoded Record
mystocks._ws.example.com EPR 11 0 0 (
services.example.com
/services/stockquotes
urn:mystocks
MyStockQuotes
)
mystocks._ws.example.com EPX 0 (
http://example.com/services.wsdl
application/wsdl+xml . .
)
7. References
7.1 Normative References
[1] Lottor, M., "Domain administrators operations guide", RFC 1033,
November 1987.
[2] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[3] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[7] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[8] Christensen, E., Curbera, F., Meredith, G. and S. Weerawarana,
"Web Services Description Language (WSDL) 1.1", W3C NOTE
NOTE-wsdl-20010315, March 2001.
7.2 Informational References
[9] Bryan, D., Vadim, V., Ehnebuske, D., Glover, T., Hately, A.,
Snell & Donoho Expires: May 23, 2005 [Page 18]
Internet-Draft DNS-EPD November 2004
Husband, YL., Karp, A., Kibakura, K., Kury, C., Lancelle, J.,
Lee, S., MacRoibeaird, S., Thomas Manes, A., McKee, B., Munter,
J., Nordan, T., Reeves, C., Rogers, D., Tomlinson, C., Tosun,
C., von Riegen, C. and P. Yendluri, "Universal Description,
Discovery and Integration".
[10] Box, D., Christensen, E., Curbera, F., Ferguson, D., Frey, J.,
Hadley, M., Kaler, C., Langworthy, D., Leymann, F., Lovering,
B., Lucco, S., Millet, S., Mukhi, N., Nottingham, M., Orchard,
D., Shewchuk, J., Sindambiwe, E., Storey, T., Weerawarana, S.
and S. Winkler, "Web Services Addressing (WS-Addressing)", 08
2004.
Authors' Addresses
James M Snell
IBM
3039 Cornwallis Rd., P.O. Box 12195
Research Triangle Park, NC 27709
US
Phone: +1 877 511 5082
EMail: jasnell@us.ibm.com
URI: http://www.ibm.com
Andrew W Donoho
IBM
11501 Burnet Road
Austin, TX 78758
US
Phone: +1 877 220 0659
EMail: awd@us.ibm.com
URI: http://www.ibm.com
Appendix A. Acknowledgements
The authors gratefully acknowledge the contributions of: Anthony
Nadalin, Arnaud Le Hors, Brian Carpenter, Heather Kreger, Jim Colson,
Stewart Cheshire, Thomas Narten, and Tony Storey
Snell & Donoho Expires: May 23, 2005 [Page 19]
Internet-Draft DNS-EPD November 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Snell & Donoho Expires: May 23, 2005 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-24 04:12:46 |