| TOC |
|
This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.
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.
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 January 15, 2002.
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document describes an application layer client-server protocol for a framework of representing the query and result operations of directory services. Specified in XML, the protocol defines generic directory query and result operations and a mechanism for extending these operations for specific directory service needs.
| TOC |
| TOC |
This document describes the specification for the eXtensible Directory Access Protocol (XDAP), an XML text protocol with the purpose of describing the query types and result types of various directory services. XDAP is specified using the Extensible Markup Language (XML) 1.0 as described in [1], XML Schema notation as described in [3] and [4], and XML Namespaces as described in [2].
It is important to note that XML is case sensitive. XML specifications and examples provided in this document MUST be interpreted in the exact character case presented to develop a conforming implementation.
The use of an electronic directory and its associate parts and components to accomplish a certain task or set of tasks is generally considered a directory application. The knowledge of the structure of names of entities, the sub-components of these entities, and the understanding of the query syntax to find these entities are all applied to execute the tasks. This document calls this knowledge of the directory and how to use it a directory namespace. This directory namespace is identified by the URI, more specifically a URN, used within the XML instances to identify the XML schema formally describing the directory.
A directory service, or a process running on a computer serving directory information, may handle queries and serve results for multiple directory namespaces. Each directory namespace for which a particular directory service serves is a directory instance.
XDAP, and the XML schema formally describing XDAP, does not specify any directory, directory namespace, or knowledge of a particular directory application. XDAP is a specification for a framework with which these directory namespaces can be defined, used, and in some cases interoperate. The framework merely specifies the elements for session management and the elements which must be used to derive query elements and result elements.
This framework allows a directory namespace to define its own structure for naming, entities, queries, etc. through the use XML namespaces and XML schemas (hence, a directory is identified by the same URI that identifies its XML namespace). In order to be useful, a directory namespace must extend from this framework.
The framework does define certain structures that can be common to all directory namespaces, such as entity references, search continuations, authentication types, and more. A directory namespace may declare its own definitions for all of these, or it may mix its derived definitions with the base definitions.
XDAP defines two types of referrals, an entity reference and a search continuation. An entity reference indicates specific knowledge about an individual entity, and a search continuation allows for distributed searches. Both types may span differing directory namespaces and instances. In addition, XDAP specifies requirements for representing entity references as URI's. No assumptions or specifications are made about roots, bases, or meshes of entities.
Finally, the XDAP framework attempts to be transport neutral. There is no default transport specification
| TOC |
XDAP is an application layer protocol that can be layered over multiple transport protocols. Each protocol data unit MUST be one and only one complete and valid XML instance. The XML document MAY contain one request element and MAY contain one response element.
The request element describes elements for a client to authenticate to a server, request session status information, inquire about the available directory data sets, query a directory data set, and close the session.
The response element describes elements for a server to provide to a client session status, available directory data sets, and results from a directory query.
No requirements are made concerning the synchronization of the request and the response in this document. However, a transport mapping of XDAP MAY make such requirements if necessary. Both the request and response elements have optional 'sessionToken' attributes to aid in synchronization. In this specification they are OPTIONAL, however a transport mapping MAY require them.
The definition of a session is dependent on the underlying transport, but is generally understood to be the context in which requests and responses are conducted with respect to authentication.
The following description of the protocol does not describe every detailed aspect necessary for implementation. While reading these following sections, please reference Formal XML Syntax for needed details on the formal XML specification.
The root element of all XDAP instance documents must be <xdap>. This element identifies the start of the XDAP elements, the namespace used as the identifier for the XDAP namespace, and the location of the schema. This element and the associated closing tag MUST be applied to all requests and responses sent by both clients and servers.
<xdap xmlns="urn:iana:xmlns:xdap1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:iana:xmlns:xdap1 xdap.xsd">
</xdap>
The use of the schema location URI in the <xsi:schemaLocation> element is OPTIONAL with respect to its use by this specification, and XDAP implementations MAY resolve it to retrieve the schema or they MAY use a locally cached version of the schema. The presence of this URI is mandatory according to [4]. The URI MUST be a valid URI, and SHOULD resolve if the appropriate network resources are available.
Versioning of the XDAP protocol is accomplished by use of the namespace URI. A change in the URI indicates a change of the underlying schema and therefore a new version of the protocol.
A <request> element holds children representing the different requests that can be made from a client to a server. This element has one attribute, 'sessionToken'. This attribute is a string of generated by the client and SHOULD NOT have any meaning to the server. Its purpose is to provide a mechanism for use by the client to match requests with responses, and it MAY be absent or empty.
Providing a mechanism for authentication, this element may have children of <simpleAuthentication> or derivatives of <complexAuthentication>. The simple case requires <authenticationId> and <authenticationPassword>. The complex case is an abstract element to be defined by in the namespace of directories. Each type MUST contain an attribute of 'directoryNamespace' signifying the target directory namespace to apply this authentication. This value of this and directory namespace of a derived complex authentication element MAY be different.
A client MAY reauthenticate more than once during session using the <authenticate> request. If reauthentication occurs with different credentials, all new requests are to be processed against the new credentials. Outstanding requests are to be processed against the old credentials.
The specification for a directory namespace MAY choose to explicitly deny authentication using <simpleAuthentication>.
The <sessionInquiry> element allows the client to inquire about the current session it has with the server. This element has not content and no attributes. Clients SHOULD start sessions with a session inquiry.
The <serviceInquiry> element enables the client to query for a list of directory namespace identifiers. Authentication MUST not be required for this request.
The <directorySearch> element enables a client to query a directory namespace of a directory service. It may have two element types as children: <lookupEntity> and <query>.
The content of the <lookupEntity> element is the name of an entity within a directory. The 'directoryNamespace' attribute is the namespace identifier for the directory in which the lookup operation is to take place.
The <query> element is abstract and MAY NOT legally appear in an XML instance. It provides the base type to be used by directory namespaces to define derived query types.
The <quit> element signals the clients intent to close the session. If the <request> element containing a <quit> element does not contain a <directorySearch>, <sessionInquiry>, or <serviceInquiry> element, the server MUST immediately close the session, else the server MUST respond with the results and then immediately close the session.
The <response> element holds children of the different response types returned from a server to a client. This element has one attribute, 'sessionToken'. This attribute is a string generated by the client and SHOULD NOT have any meaning to the server. The value of this attribute MUST be identical to the value of the 'sessionToken' attribute of the corresponding <request> element.
The <sessionStatus> element MUST be returned to the client in response to an <authenticate> or <sessionInquiry> request. This element MUST also be returned to the client when authentication is required in response to <directorySearch> requests.
The <sessionStatus> MUST contain one of these child elements:
The <sessionStatus> element MAY contain the <communicationProblem> element. This element signifies the failure to correctly parse the XML of the corresponding request.
The <serviceResult> element is a response to the <serviceInquiry>. A server MAY require authentication before serving this information. If authentication is required and the client is not authenticated, a server MUST return a <sessionStatus> element instead of a <serviceResult> element.
If the client is authenticated, this element MUST contain child elements of <directoryNamespace>. The contents of each child MUST contain one directory namespace identifier. In this state, the <serviceResult> element MUST contain a <directoryNamespace> child element for each directory namespace for which the server allows queries.
A server MAY NOT require separate authentication credentials for this response than for the <directoryResult> response. In other words, if a client is a authenticated to receive <directoryResult> responses, then it MUST also be authenticated to receive these responses.
The <directoryResult> element is a response to a <directorySearch> request. Each child element is a response to a corresponding child element in the <directorySearch> request element, and the order of these children MUST be the same order as their corresponding request elements.
The children MUST be one of the following types:
| TOC |
Because the XDAP schema defines no useful query types, no directory structure, and no result types, it is useless by itself. Extension of XDAP is accomplished through the use a base XDAP schema, as defined in [3] and [4], and extension of it by directories constructed on top of XDAP.
The XML Schema definition of XDAP requires schemas of directory namespaces to derive element types from base types in the XDAP definition. The schema definitions of directory namespaces SHOULD derive elements for definition of typed queries and results.
While the XDAP schema definition does not prohibit the derivation of any elements, directory namespace schemas SHOULD restrict the derivations to the following types:
The namespace identifier for a directory namespace and the XML namespace identifier used by the XML Schema describing the directory MUST be the same. These namespace identifiers MUST be restricted to any valid URN[7].
This is a restriction on XML_NS[2], which specifies a namespace identifier is any valid URI[6].
The names of entities in a directory namespace MUST be of type CDATA defined by [3]. They may not contain XML markup. Their use SHOULD be transcribable.
Names of entities SHOULD be unique within an instance of a directory namespace. Two entities SHOULD NOT have the same name, but a single entity MAY be known by multiple names. In situations where a single name may result in two entities, the directory namespace should make allowances by defining result types that contain entity references to both entities (i.e. "foo.com" can refer to both the domain foo.com and the host foo.com). However, this type of conflict should generally be avoided.
| TOC |
XDAP does not have single URI definition because of the dependencies on a URI by the mapping between XDAP and a transport protocol. However, any valid XDAP URI definition MUST meet the following requirements:
<directory-namespace>/<entity-name>
| TOC |
XDAP is specified in XML Schema notation. The formal syntax presented here is a complete schema representation of XDAP suitable for automated validation of XDAP XML instances.
<?xml version="1.0"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:xdap="urn:iana:xmlns:xdap1"
targetNamespace="urn:iana:xmlns:xdap1"
elementFormDefault="qualified" >
<annotation>
<documentation>
eXtensible Directory Access Protocol (XDAP) Schema v1
</documentation>
</annotation>
<element name="xdap">
<complexType>
<sequence>
<element name="request"
type="xdap:requestType"
minOccurs="0" maxOccurs="1" />
<element name="response"
type="xdap:responseType"
minOccurs="0" maxOccurs="1" />
</sequence>
</complexType>
</element>
<complexType name="requestType">
<sequence>
<element name="authenticate"
type="xdap:authenticateType"
minOccurs="0" maxOccurs="1" />
<element name="sessionInquiry"
type="xdap:sessionInquiryType"
minOccurs="0" maxOccurs="1" />
<element name="serviceInquiry"
type="xdap:serviceInquiryType"
minOccurs="0" maxOccurs="1" />
<element name="directorySearch"
type="xdap:directorySearchType"
minOccurs="0" maxOccurs="unbounded" />
<element name="quit"
type="xdap:quitType"
minOccurs="0" maxOccurs="1" />
</sequence>
<attribute name="sessionToken"
type="string"
use="optional" />
</complexType>
<complexType name="authenticateType">
<choice minOccurs="1" maxOccurs="unbounded">
<element name="simpleAuthentication"
type="xdap:simpleAuthenticationType" />
<element ref="xdap:complexAuthentication" />
</choice>
</complexType>
<complexType name="simpleAuthenticationType">
<sequence>
<element name="authenticationId"
type="string"
minOccurs="1" maxOccurs="1" />
<element name="authenticationPassword"
type="string"
minOccurs="1" maxOccurs="1" />
</sequence>
<attribute name="directoryNamespace"
type="anyURI" use="required" />
</complexType>
<complexType name="complexAuthenticationType">
<attribute name="directoryNamespace"
type="anyURI" use="required" />
</complexType>
<element name="complexAuthentication"
type="xdap:complexAuthenticationType"
abstract="true" />
<complexType name="sessionInquiryType" />
<complexType name="serviceInquiryType" />
<complexType name="directorySearchType" >
<choice>
<element name="lookupEntity"
type="xdap:lookupEntityType" />
<element ref="xdap:query"
minOccurs="1" maxOccurs="unbounded" />
</choice>
</complexType>
<complexType name="queryType"/>
<element name="query"
type="xdap:queryType"
abstract="true" />
<complexType name="lookupEntityType" >
<simpleContent>
<extension base="string">
<attribute name="directoryNamespace"
type="anyURI"
use="required" />
</extension>
</simpleContent>
</complexType>
<complexType name="quitType" />
<complexType name="responseType">
<sequence>
<element name="sessionStatus"
type="xdap:sessionStatusType"
minOccurs="0" maxOccurs="1" />
<element name="serviceResult"
type="xdap:serviceResultType"
minOccurs="0" maxOccurs="1" />
<element name="directoryResult"
type="xdap:directoryResultType"
minOccurs="0" maxOccurs="unbounded" />
</sequence>
<attribute name="sessionToken"
type="string" use="optional" />
</complexType>
<complexType name="sessionStatusType" >
<sequence>
<choice
minOccurs="0" maxOccurs="unbounded" >
<element name="currentlyAuthenticated"
type="xdap:authenticationCodeType" />
<element name="authenticationRequired"
type="xdap:authenticationCodeType" />
<element name="noAuthenticationRequired"
type="xdap:authenticationCodeType" />
</choice>
<element name="communicationProblem"
type="xdap:codeType"
minOccurs="0" maxOccurs="1" />
</sequence>
</complexType>
<complexType name="codeType">
<sequence minOccurs="0" maxOccurs="1">
<element name="explanation" type="string" />
<element name="language" type="language" />
</sequence>
</complexType>
<complexType name="authenticationCodeType">
<sequence minOccurs="0" maxOccurs="1">
<element name="explanation" type="string" />
<element name="language" type="language" />
</sequence>
<attribute name="directoryNamespace"
type="anyURI" use="required" />
</complexType>
<complexType name="serviceResultType" >
<sequence>
<element name="directoryNamespace"
minOccurs="1" maxOccurs="unbounded">
<complexType>
<simpleContent>
<extension base="anyURI">
<attribute name="location" type="anyURI"
use="required" />
</extension>
</simpleContent>
</complexType>
</element>
<!--
<element name="directoryNamespace"
type="anyURI"
minOccurs="1" maxOccurs="unbounded" />
-->
</sequence>
</complexType>
<complexType name="directoryResultType" >
<choice minOccurs="0" maxOccurs="unbounded">
<sequence>
<element ref="xdap:result"
minOccurs="1" maxOccurs="1" />
<element ref="xdap:stylesheet"
minOccurs="0" maxOccurs="1" />
</sequence>
<element name="entityReference"
type="anyURI" />
<element name="searchContinuation"
type="xdap:searchContinuationType" />
<element name="insufficientResources"
type="xdap:codeType" />
<element name="invalidName"
type="xdap:codeType" />
<element name="invalidSearch"
type="xdap:codeType" />
<element name="limitExceeded"
type="xdap:codeType" />
<element name="nameNotFound"
type="xdap:codeType" />
<element name="permissionDenied"
type="xdap:codeType" />
<element name="invalidXML"
type="xdap:codeType" />
<element ref="xdap:genericCode" />
</choice>
</complexType>
<complexType name="resultType" />
<element name="result"
type="xdap:resultType"
abstract="true" />
<complexType name="searchContinuationType">
<sequence>
<element ref="xdap:hostReference"
minOccurs="1" maxOccurs="1" />
<element name="directorySearch"
type="xdap:directorySearchType"
minOccurs="1" maxOccurs="1"/>
</sequence>
</complexType>
<complexType name="hostReferenceType">
<sequence>
<element name="scheme" type="string"
minOccurs="1" maxOccurs="1" />
<element name="host" type="string"
minOccurs="1" maxOccurs="1" />
<element name="port" type="positiveInteger"
minOccurs="1" maxOccurs="1" />
</sequence>
</complexType>
<element name="hostReference"
type="xdap:hostReferenceType" />
<element name="genericCode" type="xdap:codeType"
abstract="true" />
<complexType name="stylesheetType" >
<attribute name="location"
type="anyURI" use="required" />
<attribute name="type"
type="NMTOKEN" use="required" />
</complexType>
<element name="stylesheet"
type="xdap:stylesheetType"
abstract="true" />
</schema>
| TOC |
XDAP is represented in XML, which provides native support for encoding information using the double-byte Unicode character set and its more compact representations including UTF-8. Compliant XML processors are required to understand both UTF-8 and raw Unicode character sets; XML also includes a provision for identifying other character sets through use of an "encoding" attribute in an <?xml?> processing instruction. The complete list of character set encoding identifiers is maintained by IANA and is described in ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets and [8].
| TOC |
XML schemas require a URI for unique identification. Schemas MUST be registered to ensure URI uniqueness, but the IETF does not currently have a recommended repository for the registration of XML schemas. This document uses URNs to describe XML namespaces and XML schemas. IANA SHOULD maintain a registry of XML namespace and schema URI assignments. Per policies described in [9], URI assignment requests SHOULD be reviewed by a designated expert, and values SHOULD be assigned only as a result of standards action taken by the IESG.
| TOC |
XDAP provides only a simple client authentication mechanism. A passive attack is sufficient to recover client identifiers and passwords, allowing trivial session forgery. Protection against most common attacks should be provided by the underlying transport protocol or protocols.
The simple client authentication mechanism uses a variant of the PLAIN SASL mechanism described in [10] to provide a application-layer authentication capability. Where the PLAIN SASL mechanism specifies provision of an authorization identifier, authentication identifier, and password as a single string separated by ASCII NUL characters, XDAP specifies use of a combined authorization and authentication identifier and a password provided as distinct XML elements.
XDAP also allows for the definition of complex authentication mechanisms in directory namespaces which derive their schemas from XDAP. The specification for these complex mechanisms MUST describe all relevant security considerations.
Repeated password guessing attempts can be discouraged by limiting the number of <authenticate> attempts that can be attempted on an open session. A server MUST discontinue a session if three <authenticate> attempts are made with either an invalid client identifier, an invalid password, or both an invalid client identifier and an invalid password.
Referral XDAP directory results may contain entity lookups and search continuations which result in a client query operation against another directory service. The authentication credentials used to obtain the directory results SHOULD NOT be used to conduct a subsequent entity lookup or search continuation.
As specified, XDAP allows a valid XML instance to contain both a <request> and a <response>. Applications and processes acting only as a client for a given session MUST issue an <authenticationRequired> in response to all<authenticate> requests regardless of the authentication identifier and password. Applications and processes MAY act in the role of both a client and server in a session.
| TOC |
| TOC |
| Andrew L. Newton | |
| VeriSign, Inc. | |
| 505 Huntmar Park Drive | |
| Herndon, VA 20170 | |
| USA | |
| Phone: | +1 703 948 3382 |
| EMail: | anewton@verisignlabs.com |
| URI: | http://www.verisignlabs.com/ |
| TOC |
The concept of a base, a specific search or lookup starting point, is not common to the inherent structure of all directories. Therefore XDAP does not explicitly define a one. The problem of expressing a starting point is solved by use of well-known entity references which return a search continuation. An XDAP URI is an entity reference and therefore capable of being the base of a directory.
To illustrate, given the following fictional XDAP URI:
xdap://some.host/urn:iana:xmlns:fooDS/foostart
The client may resolve the URI by issuing a <lookupEntity> request
and the response would be:
<?xml version="1.0"?>
<xdap xmlns="urn:iana:xmlns:xdap1"
xmlns:xdap="urn:iana:xmlns:xdap1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:iana:xmlns:xdap1 xdap.xsd" >
<response>
<directoryResult>
<searchContinuation>
<hostReference>
<scheme>xdap</scheme>
<host>some.host</host>
<port>5555</port>
</hostReference>
<directorySearch>
<foo:listFoos
xmlns:foo="urn:iana:xmlns:fooDS"
xsi:schemaLocation="urn:iana:xmlns:fooDS fooDS.xsd" />
<foo:fooTree>foo1:</foo:fooTree>
<foo:filter hidden="true" system="false" />
</foo:listFoos>
</directorySearch>
</searchContinuation>
</directoryResult>
</response>
</xdap>
This mechanism can be used to define both the base of a directory namespace or a directory instance. When the search continuation contains a host reference to the same host of the directory instance to which the entity lookup was conducted, this can be considered a base of a directory instance. If the host reference is to a different host, this can be considered a base of a directory namespace.
This document makes no specification or assumptions about roots, search bases, or entity meshes.
| TOC |
This specification does not provide a direct mechanism for schema discovery. However, a method is available.
A client may use the schema location URI of the <xsi:schemaLocation> element (the second URI) to retrieve the XML Schema document of an unknown directory namespace (assuming the network resources are available). This document contains valid XML which may be used by the client to determine the structure of the unknown directory namespace. A distinction for the proper use and placement of the elements inside XDAP requests and responses may be obtained by evaluating the base types derived from the XDAP schema. XML schema type libraries should be employed to better facilitate the understanding of common data types.
In addition, a directory namespace may define query and result derivatives especially designed for schema discovery within its area and specific to its needs.
| TOC |
The following is an example of an XDAP directory for part numbers. The XML instances are the exchange between the client and server.
This is the formal XML Schema syntax for a mythical directory application known as urn:iana:xmlns:partno1.
<?xml version="1.0"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:partno="urn:iana:xmlns:partno1"
xmlns:xdap="urn:iana:xmlns:xdap1"
targetNamespace="urn:iana:xmlns:partno1"
elementFormDefault="qualified" >
<annotation>
<documentation>
Part number directory schema conformant to XDAP schema
</documentation>
</annotation>
<complexType name="lookupPartType">
<complexContent>
<extension base="xdap:queryType">
<attribute name="partno"
type="string" use="required" />
</extension>
</complexContent>
</complexType>
<element name="lookupPart" type="partno:lookupPartType"
substitutionGroup="xdap:query" />
<complexType name="listPartsByCategoryType">
<complexContent>
<extension base="xdap:queryType">
<sequence>
<element name="categoryId" type="string"
minOccurs="1" maxOccurs="10" />
</sequence>
</extension>
</complexContent>
</complexType>
<element name="listPartsByCategory"
type="partno:listPartsByCategoryType"
substitutionGroup="xdap:query" />
<element name="listCategories" type="xdap:queryType"
substitutionGroup="xdap:query" />
<complexType name="partType">
<complexContent>
<extension base="xdap:resultType">
<sequence>
<element name="name" type="string" />
<element name="description" type="string" />
<element name="partNumber" type="string" />
<element name="categoryId" type="string" />
</sequence>
</extension>
</complexContent>
</complexType>
<element name="part" type="partno:partType"
substitutionGroup="xdap:result" />
<complexType name="categoryType">
<complexContent>
<extension base="xdap:resultType">
<sequence>
<element name="categoryName" type="string" />
<element name="categoryId" type="string" />
</sequence>
</extension>
</complexContent>
</complexType>
<element name="category" type="partno:categoryType"
substitutionGroup="xdap:result" />
</schema>
This XML instance is a request to authenticate.
<?xml version="1.0"?>
<xdap xmlns="urn:iana:xmlns:xdap1"
xmlns:xdap="urn:iana:xmlns:xdap1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:iana:xmlns:xdap1 xdap.xsd" >
<request>
<authenticate>
<simpleAuthentication
directoryNamespace="urn:iana:xmlns:partno1" >
<authenticationId>
bjansen
</authenticationId>
<authenticationPassword>
fly7crow1
</authenticationPassword>
</simpleAuthentication>
</authenticate>
</request>
</xdap>
This XML instance is a response from 1-login-request.xml.
<?xml version="1.0"?>
<xdap xmlns="urn:iana:xmlns:xdap1"
xmlns:xdap="urn:iana:xmlns:xdap1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:iana:xmlns:xdap1 xdap.xsd" >
<response>
<sessionStatus>
<currentlyAuthenticated
directoryNamespace="urn:iana:xmlns:partno1" />
</sessionStatus>
</response>
</xdap>
This instance is a service inquiry request.
<?xml version="1.0"?>
<xdap xmlns="urn:iana:xmlns:xdap1"
xmlns:xdap="urn:iana:xmlns:xdap1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:iana:xmlns:xdap1 xdap.xsd" >
<request>
<serviceInquiry />
</request>
</xdap>
This XML instance is a response to 2-service-request.xml.
<?xml version="1.0"?>
<xdap xmlns="urn:iana:xmlns:xdap1"
xmlns:xdap="urn:iana:xmlns:xdap1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:iana:xmlns:xdap1 xdap.xsd" >
<response>
<serviceResult>
<directoryNamespace
location="ftp://ftp.isi.edu/iana/urn/xmlns/partno1.xsd">
urn:iana:xmlns:partno1
</directoryNamespace>
<directoryNamespace
location="ftp://ftp.isi.edu/iana/urn/xmlns/foo1.xsd">
urn:iana:xmlns:foo1
</directoryNamespace>
</serviceResult>
</response>
</xdap>
This XML instance demonstrates a directory search request to look up a part number.
<?xml version="1.0"?>
<xdap xmlns="urn:iana:xmlns:xdap1"
xmlns:xdap="urn:iana:xmlns:xdap1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:iana:xmlns:xdap1 xdap.xsd" >
<request>
<directorySearch>
<partno:lookupPart
xmlns:partno="urn:iana:xmlns:partno1"
xsi:schemaLocation="urn:iana:xmlns:partno1 partno.xsd"
partno="5656573-3993A" />
</directorySearch>
</request>
</xdap>
This instance is the response sent in reply to 3-search-request.xml. It demonstrates a simple directory result.
<?xml version="1.0"?>
<xdap xmlns="urn:iana:xmlns:xdap1"
xmlns:xdap="urn:iana:xmlns:xdap1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:iana:xmlns:xdap1 xdap.xsd" >
<response>
<directoryResult>
<partno:part
xmlns:partno="urn:iana:xmlns:partno1"
xsi:schemaLocation="urn:iana:xmlns:partno1 partno.xsd" >
<partno:name>Wacky Widget</partno:name>
<partno:description>
Wonko World's Wonderful Wacky Widget
</partno:description>
<partno:partNumber>5656573-3993A</partno:partNumber>
<partno:categoryId>29</partno:categoryId>
</partno:part>
</directoryResult>
</response>
</xdap>
This instance is a request to list all the part number categories.
<?xml version="1.0"?>
<xdap xmlns="urn:iana:xmlns:xdap1"
xmlns:xdap="urn:iana:xmlns:xdap1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:iana:xmlns:xdap1 xdap.xsd" >
<request>
<directorySearch>
<partno:listCategories
xmlns:partno="urn:iana:xmlns:partno1"
xsi:schemaLocation="urn:iana:xmlns:partno1 partno.xsd" />
</directorySearch>
</request>
</xdap>
This is the response to 4-search-response.xml. It demonstrates a more complex result set consisting of entities in the queried directory, entity references located elsewhere, and search continuations for other directories.
<?xml version="1.0"?>
<xdap xmlns="urn:iana:xmlns:xdap1"
xmlns:xdap="urn:iana:xmlns:xdap1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:iana:xmlns:xdap1 xdap.xsd" >
<response>
<directoryResult>
<partno:category
xmlns:partno="urn:iana:xmlns:partno1"
xsi:schemaLocation="urn:iana:xmlns:partno1 partno.xsd" >
<partno:categoryName>Generic Widgets</partno:categoryName>
<partno:categoryId>29</partno:categoryId>
</partno:category>
<partno:category
xmlns:partno="urn:iana:xmlns:partno1"
xsi:schemaLocation="urn:iana:xmlns:partno1 partno.xsd" >
<partno:categoryName>Wacky Widgets</partno:categoryName>
<partno:categoryId>30</partno:categoryId>
</partno:category>
<partno:category
xmlns:partno="urn:iana:xmlns:partno1"
xsi:schemaLocation="urn:iana:xmlns:partno1 partno.xsd" >
<partno:categoryName>Wild Widgets</partno:categoryName>
<partno:categoryId>31</partno:categoryId>
</partno:category>
<entityReference>
xdap://localhost:8676/urn:iana:xmlns:partno1?/categoryId/32
</entityReference>
<entityReference>
xdap://localhost:8676/urn:iana:xmlns:partno1?/categoryId/33
</entityReference>
<entityReference>
xdap://localhost:8676/urn:iana:xmlns:partno1?/categoryId/34
</entityReference>
<searchContinuation>
<hostReference>
<scheme>xdap</scheme>
<host>localhost</host>
<port>3933</port>
</hostReference>
<directorySearch>
<partno:listCategories
xmlns:partno="urn:iana:xmlns:partno1"
xsi:schemaLocation="urn:iana:xmlns:partno1 partno.xsd" />
</directorySearch>
</searchContinuation>
</directoryResult>
</response>
</xdap>
This instance is an entity lookup request. Notice that it is the logical continuation from one of the entity references in 4-search-response.xml
<?xml version="1.0"?>
<xdap xmlns="urn:iana:xmlns:xdap1"
xmlns:xdap="urn:iana:xmlns:xdap1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:iana:xmlns:xdap1 xdap.xsd" >
<request>
<directorySearch>
<lookupEntity
directoryNamespace="urn:iana:xmlns:partno1"
>/category/32</lookupEntity>
</directorySearch>
</request>
</xdap>
This instance is the response to 5-search-request.xml.
<?xml version="1.0"?>
<xdap xmlns="urn:iana:xmlns:xdap1"
xmlns:xdap="urn:iana:xmlns:xdap1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:iana:xmlns:xdap1 xdap.xsd" >
<response>
<directoryResult>
<searchContinuation>
<hostReference>
<scheme>xdap</scheme>
<host>localhost</host>
<port>5555</port>
</hostReference>
<directorySearch>
<partno:listCategories
xmlns:partno="urn:iana:xmlns:partno1"
xsi:schemaLocation="urn:iana:xmlns:partno1 partno.xsd" />
</directorySearch>
</searchContinuation>
</directoryResult>
</response>
</xdap>
| TOC |
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 RFC2119[11].
| TOC |
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
Funding for the RFC editor function is currently provided by the Internet Society.