Request for Comments: 4403 K. Boogert
Category: Informational Novell, Inc.
V. Nanjundaswamy
Oracle India Pvt. Ltd.
February 2006
Lightweight Directory Access Protocol (LDAP) Schema for
Universal Description, Discovery, and Integration version 3 (UDDIv3)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines the Lightweight Directory Access Protocol
(LDAPv3) schema for representing Universal Description, Discovery,
and Integration (UDDI) data types in an LDAP directory. It defines
the LDAP object class and attribute definitions and containment rules
to model UDDI entities, defined in the UDDI version 3 information
model, in an LDAPv3-compliant directory.
Table of Contents
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Representation of UDDI Data Structures ..........................2
4. Attribute Type Definitions ......................................6
5. Object Class Definitions .......................................28
6. Name Forms .....................................................32
7. DIT Structure Rules ............................................35
8. Security Considerations ........................................37
9. IANA Considerations ............................................37
10. Normative References ..........................................40
1. Introduction
This document defines the Lightweight Directory Access Protocol
[LDAPv3] schema elements to represent the core data structures
identified in the Universal Description, Discovery, and Integration
version 3 [UDDIv3] information model. This includes a
businessEntity, a businessService, a bindingTemplate, a tModel, a
publisherAssertion, and a Subscription. Portions of [UDDIv3] are
repeated here for clarity.
2. Conventions Used in This Document
The keywords "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 [RFC2119].
All schema definitions are provided using [RFC2252] descriptions, and
are line-wrapped for readability only.
3. Representation of UDDI Data Structures
The information that makes up a registration in a UDDI registry
consists of these data structure types. This division by information
type provides simple partitions to assist in the rapid location and
understanding of the different information that makes up a
registration.
The individual instance data managed by a UDDI registry is sensitive
to the parent/child relationships found in the schema. A
businessEntity object contains one or more unique businessService
objects. Similarly, individual businessService objects contain
specific instances of bindingTemplate, which in turn contains
information that includes pointers to specific instances of tModel
objects.
It is important to note that no single instance of a core schema type
is ever "contained" by more than one parent instance. This means
that only one specific businessEntity object (identified by its
unique key value) will ever contain or be used to express information
about a specific instance of a businessService object (also
identified by its own unique key value).
3.1. businessEntity
The businessEntity object represents all known information about a
business or entity that publishes descriptive information about the
entity as well as the services that it offers. The businessEntity is
the top-level container that accommodates holding descriptive
information about a business or entity. Service descriptions and
technical information are expressed within a businessEntity by a
containment relationship.
3.1.1. Representation in the Directory
A businessEntity is represented in the directory by the attributes
uddiBusinessKey, uddiAuthorizedName, uddiOperator, uddiDiscoveryURLs,
uddiName, uddiDescription, uddiIdentifierBag, uddiCategoryBag, and
uddiv3DigitalSignature, along with corresponding v3 keys viz.
uddiv3BusinessKey, as defined in Section 4. A businessEntity may
contain zero or more instances of uddiContact and
uddiBusinessService.
A mandatory attribute, uddiBusinessKey, contains the unique
identifier for a given instance of a businessEntity.
businessEntity’s definition is given in Section 5.
3.2. businessService
The businessService instances represent a logical business service.
Each businessService object is the logical child of a single
businessEntity object. Each businessService element contains
descriptive information in business terms outlining the type of
technical services found within each businessService instance.
In some cases, businesses would like to share or reuse services,
e.g., when a large enterprise publishes separate businessEntity
structures. This can be established by using the businessService
instance as a projection to an already published businessService.
3.2.1. Representation in the Directory
A businessService is represented in the directory by the attributes
uddiBusinessKey, uddiServiceKey, uddiName, uddiDescription,
uddiCategoryBag, uddiIsProjection, and uddiv3DigitalSignature, along
with corresponding v3 keys viz. uddiv3BusinessKey, and
uddiv3ServiceKey, as defined in Section 4. A businessService may
contain zero or more instances of uddiBindingTemplate.
The mandatory attribute, uddiServiceKey, contains the unique
identifier for a given instance of a businessService.
businessService’s definition is given in Section 5.
3.3. bindingTemplate
Technical descriptions of Web services are accommodated via
individual contained instances of bindingTemplate objects. These
instances provide support for determining a technical entry point or
optionally support remotely hosted services, as well as a lightweight
facility for describing unique technical characteristics of a given
implementation. Support for technology and application specific
parameters and settings files are also supported.
Since UDDI’s main purpose is to enable description and discovery of
Web service information, it is the bindingTemplate that provides the
most interesting technical data. With UDDIv3, bindingTemplates also
can have categorization information.
Each bindingTemplate instance has a single logical businessService
parent, which in turn has a single logical businessEntity parent.
3.3.1. Representation in the Directory
A bindingTemplate is represented in the directory by the attributes
uddiBindingKey, uddiServiceKey, uddiDescription, uddiAccessPoint,
uddiHostingRedirector, uddiCategoryBag, and uddiv3DigitalSignature,
along with corresponding v3 keys viz. uddiv3ServiceKey and
uddiv3BindingKey, as defined in Section 4. A bindingTemplate may
contain zero or more instances of uddiTModelInstanceDetails.
The mandatory attribute, uddiBindingKey, contains the unique
identifier for a given instance of a bindingTemplate.
BindingTemplate’s definition is given in Section 5.
3.4. tModel
The tModel object takes the form of keyed metadata (data about data).
In a general sense, the purpose of a tModel within the UDDI registry
is to provide a reference system based on abstraction. Thus, the
kind of data that a tModel represents is pretty nebulous. In other
words, a tModel registration can define just about anything, but in
the current revision, two conventions have been applied for using
tModels: as sources for determining compatibility and as keyed
namespace references.
The information that makes up a tModel is quite simple. There are a
key, a name, an optional description, and a Uniform Resource Locator
[URL] that points somewhere--presumably somewhere where the curious
can go to find out more about the actual concept represented by the
metadata in the tModel itself.
3.4.1. Representation in the Directory
A tModel is represented in the directory by the attributes
uddiTModelKey, uddiAuthorizedName, uddiOperator, uddiName,
uddiDescription, uddiOverviewDescription, uddiOverviewURL,
uddiIdentifierBag, uddiCategoryBag, uddiIsHidden, and
uddiv3DigitalSignature, along with the corresponding v3 key viz.
uddiv3tModelKey, as defined in Section 4. A tModel may also contain
a uddiHidden to logically delete a tModel.
A mandatory attribute, uddiTModelKey, contains the unique identifier
for a given instance of a tModel.
tModel’s definition is given in Section 5.
3.5. publisherAssertion
Many businesses, such as large enterprises or marketplaces, are not
effectively represented by a single businessEntity, since their
description and discovery are likely to be diverse. As a
consequence, several businessEntity instances can be published,
representing individual subsidiaries of a large enterprise or
individual participants of a marketplace. Nevertheless, they still
represent a more or less coupled community and would like to make
some of their relationships visible in their UDDI registrations.
3.5.1. Representation in the Directory
A publisherAssertion is represented in the directory by the
attributes uddiFromKey, uddiToKey, uddiKeyedReference, and uddiUUID,
and uddiv3DigitalSignature, as defined in Section 5.
A mandatory attribute, uddiUUID, contains the unique identifier for a
given instance of a publisherAssertion.
publisherAssertion’s definition is given in Section 5.
3.6. Operational Information:
With UDDIv3, the operational information associated with the core
UDDI data structures is maintained in a separate OperationalInfo
structure, so that the digital signature specified by the publisher
remains valid.
The operationalInfo structure is used to convey the operational
information for the UDDIv3 core data structures, that is, the
businessEntity, businessService, bindingTemplate, and tModel
structures. UDDIv3 OperationalInfo consists of 5 elements: created,
Modified, modifiedIncludingChildren, nodeId, and authorizedName.
Depending on the specific UDDIv3 core data structure, the
operationalInformation is represented in the directory as a
combination of implicit LDAP Standard Operational attributes:
createTimestamp and modifyTimestamp, and the following explicit
attributes: uddiAuthorizedName, uddiv3EntityCreationTime,
uddiv3EntityModificationTime, and uddiv3NodeId.
4. Attribute Type Definitions
The OIDs for the attribute types in this document have been
registered by the IANA.
4.1. uddiBusinessKey
This is used in uddiBusinessEntity and uddiBusinessService.
The uddiBusinessKey is the unique identifier for a given instance of
a uddiBusinessEntity. The attribute is optional for businessService
instances contained within a fully expressed parent that already
contains a businessKey value.
If the businessService instance is rendered into the Extensible
Markup Language [XML] and has no containing parent that has within
its data a businessKey, the value of the businessKey that is the
parent of the businessService is required to be provided. This
behavior supports the ability to browse through the parent-child
relationships given any of the core elements as a starting point.
The businessKey may differ from the publishing businessEntity’s
businessKey to allow service projections.
( 1.3.6.1.1.10.4.1 NAME ’uddiBusinessKey’
DESC ’businessEntity unique identifier’
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
4.2. uddiAuthorizedName
The uddiAuthorizedName is the recorded name of the individual who
published the uddiBusinessEntity or uddiTModel data. This data is
generated by the controlling operator and should not be supplied
within save_business operations.
With UDDIv3, this attribute is part of the "operationalInformation"
metadata associated with core data structures.
( 1.3.6.1.1.10.4.2 NAME ’uddiAuthorizedName’
DESC ’businessEntity publisher name’
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE
)
4.3. uddiOperator
The uddiOperator is the certified name of the UDDI registry site
operator that manages the master copy of the uddiBusinessEntity or
uddiTModel. The controlling operator records this data at the time
data is saved. This data is generated and should not be supplied
within save_business or save_tModel operations.
With UDDIv3, this field is no longer used -- it is replaced by the
nodeId (uddiv3NodeId) attribute that is part of the
"operationalInformation" metadata.
( 1.3.6.1.1.10.4.3 NAME ’uddiOperator’
DESC ’registry site operator of businessEntitys master copy’
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
4.4. uddiName
This is used in uddiBusinessEntity, uddiBusinessService, and
uddiTModel.
These are the human-readable names recorded for the
uddiBusinessEntity, uddiBusinessService, or uddiTModel, adorned with
a unique xml:lang value to signify the language that they are
expressed in. Name search is provided via find_business,
find_service, or find_tModel calls.
The publishing of several names, e.g., for romanization purposes, is
supported. In order to signify the language that the names are
expressed in, they carry unique xml:lang values. Not more than one
name element may omit specifying its language. Names passed in this
way will be assigned the default language code of the registering
party. This default language code is established at the time that
publishing credentials are established with an individual Operator
Site. If no default language is provisioned at the time a publisher
signs up, the operator can adopt an appropriate default language
code.
With UDDIv3, multiple values with the same language code are
permitted.
( 1.3.6.1.1.10.4.4 NAME ’uddiName’
DESC ’human readable name’
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
The xml:lang value precedes the name value, with the "#" character
used as the separator.
4.5. uddiDescription
The uddiDescription is an optional repeating element of one or more
descriptions. One description is allowed per national language code
supplied. With UDDIv3, there is no restriction on the number of
descriptions or on what xml:lang value that they may have.
( 1.3.6.1.1.10.4.5 NAME ’uddiDescription’
DESC ’short description’
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
The xml:lang value precedes the name value, with the "#" character
used as the separator.
4.6. uddiDiscoveryURLs
This is a list of Uniform Resource Locators (URLs) that point to
alternate, file-based service discovery mechanisms. Each recorded
uddiBusinessEntity structure is automatically assigned a URL that
returns the individual uddiBusinessEntity structure. A URL search is
provided via find_business call.
The uddiDiscoveryURLs attribute is used to hold pointers to URL-
addressable discovery documents. The expected retrieval mechanism
for URLs referenced in the data within this structure is via the
Hypertext Transfer Protocol [HTTP] HTTP-GET operation. The expected
return document is not defined. Rather, a framework for establishing
conventions is provided, and two such conventions are defined within
UDDI behaviors. It is hoped that other conventions come about and
use this structure to accommodate alternate means of discovery. With
UDDIv3, a new convention is defined with useType as "homepage".
Further, a UDDIv3 server need not generate/add a discoveryURL itself,
since this can invalidate the digital signature of signed the
Business Entity saved by publishers.
( 1.3.6.1.1.10.4.6 NAME ’uddiDiscoveryURLs’
DESC ’URL to retrieve a businessEntity instance’
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
The useType value precedes the URL value, with the "#" character used
as the separator.
4.7. uddiUseType
The uddiUseType is used to describe the type of contact or address in
freeform text. Suggested examples for contact include "technical
questions", "technical contact", "establish account", "sales
contact", etc. Suggested examples for address include
"headquarters", "sales office", "billing department", etc.
( 1.3.6.1.1.10.4.7 NAME ’uddiUseType’
DESC ’name of convention the referenced document follows’
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
4.8. uddiPersonName
The uddiPersonName should list the name of the person or name of the
job role that will be available behind the contact. Examples of
roles include "administrator" or "webmaster".
( 1.3.6.1.1.10.4.8 NAME ’uddiPersonName’
DESC ’name of person or job role available for contact’
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
With UDDIv3, uddiPersonName becomes multi-valued and each name can
have an xml:lang attribute. The xml:lang value precedes the name
value with the "#" character used as the separator.
4.9. uddiPhone
This is used to hold telephone numbers for the contact. This element
can be adorned with an optional uddiUseType attribute for descriptive
purposes. If more than one phone element is saved, uddiUseType
attributes are required on each.
( 1.3.6.1.1.10.4.9 NAME ’uddiPhone’
DESC ’telephone number for contact’
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
The useType precedes the telephone number by a separating ’#’ (e.g.,
"Work Number#123 456-7890") .
4.10. uddiEMail
This is used to hold email addresses for the contact. This element
can be adorned with an optional uddiUseType attribute for descriptive
purposes. If more than one email element is saved, uddiUseType
attributes are required on each.
( 1.3.6.1.1.10.4.10 NAME ’uddiEMail’
DESC ’e-mail address for contact’
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
The useType precedes the email address by a separating ’#’ (e.g.,
"President of the United States #president@whitehouse.gov").
4.11. uddiSortCode
The uddiSortCode is used to drive the behavior of external display
mechanisms that sort addresses. The suggested values for
uddiSortCode include numeric ordering values (e.g., 1, 2, 3),
alphabetic character ordering values (e.g., a, b, c), or the first n
positions of relevant data within the address.
( 1.3.6.1.1.10.4.11 NAME ’uddiSortCode’
DESC ’specifies an external display mechanism’
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
With UDDIv3, the sortCode attribute is deprecated because of the
guarantee of preserving the document Order.
4.12. uddiTModelKey
The uddiTModelKey is the unique identifier for a given instance of an
uddiTModel.
It is also used in a KeyedReference and in Address structures. When
used with a keyed reference, this is the unique key to identify a
value set and implies that the keyName keyValue pair in a
uddiIdentifier or uddiCategory Bag are to be interpreted by the value
set referenced by the tModelKey.
When used with Addressline elements, it implies that the keyName
keyValue pair given by subsequent uddiAddressLine elements are to be
interpreted by the address structure associated with the tModel that
is referenced.
( 1.3.6.1.1.10.4.12 NAME ’uddiTModelKey’
DESC ’tModel unique identifier’
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
4.13. uddiAddressLine
The uddiAddressLine contains the actual address in freeform text. If
the address element contains a uddiTModelKey, these uddiAddressLine
elements are to be adorned, each with an optional keyName keyValue
attribute pair. Together with the uddiTModelKey, keyName and
keyValue qualify the uddiAddressLine in order to describe its
meaning.
The uddiAddressLine elements contain string data with a line length
limit of 80 character positions. Each uddiAddressLine element can be
adorned with two optional descriptive attributes, keyName and
keyValue. Both attributes must be present in each address line if a
uddiTModelKey is assigned to the address structure. By doing this,
the otherwise arbitrary use of address lines becomes structured.
Together with the address’ uddiTModelKey, keyName and keyValue
virtually build a uddiKeyedReference that represents an address line
qualifier, given by the referenced uddiTModel.
When no uddiTModelKey is provided for the address structure, the
keyName and keyValue attributes can be used without restrictions, for
example, to provide descriptive information for each uddiAddressLine
by using the keyName attribute. Since both the keyName and the
keyValue attributes are optional, address line order is significant
and will always be returned by the UDDI-compliant registry in the
order originally provided during a call to save_business.
( 1.3.6.1.1.10.4.13 NAME ’uddiAddressLine’
DESC ’address’
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
The keyName, keyValue, and addressData of this attribute are
separated by "#" (e.g., "#"<keyName>"#"<keyValue>"#"<addressData>).
The addressData is the only required portion of the attribute.
4.14. uddiIdentifierBag
The uddiIdentifierBag element allows uddiBusinessEntity or uddiTModel
structures to include information about common forms of
identification such as D-U-N-S_ numbers, tax identifiers, etc. This
data can be used to signify the identity of the uddiBusinessEntity or
can be used to signify the identity of the publishing party.
Including data of this sort is optional, but when used greatly
enhances the search behaviors exposed via the find_xx messages
defined in the UDDI Version 2.0 API Specification [UDDIapi]. For a
full description of the structures involved in establishing an
identity, see UDDI Version 2.0 Data Structure Specification -
Appendix A: Using Identifiers [UDDIdsr].
( 1.3.6.1.1.10.4.14 NAME ’uddiIdentifierBag’
DESC ’identification information’
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
The tModel, keyName, and keyValue of this attribute are separated by
"#" (e.g., <tModel>"#"<keyName>"#"<keyValue>). The keyValue is the
only required portion of the attribute.
4.15. uddiCategoryBag
The uddiCategoryBag element allows uddiBusinessEntity,
uddiBusinessService, and uddiTModel structures to be categorized
according to any of several available taxonomy-based classification
schemes. Operator Sites automatically provide validated
categorization support for three taxonomies that cover industry codes
(via NAICS), product and service classifications (via UNSPC), and
geography (via ISO 3166). Including data of this sort is optional,
but when used, it greatly enhances the search behaviors exposed by
the find_xx messages defined in the UDDI Version 2.0 API
Specification [UDDIapi]. For a full description of structures
involved in establishing categorization information, see UDDI Version
2.03 Data Structure Specification--Appendix B: Using Categorization
[UDDIdsr].
( 1.3.6.1.1.10.4.15 NAME ’uddiCategoryBag’
DESC ’categorization information’
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
The tModel, keyName, and keyValue of this attribute are separated by
"#" (e.g., <tModel>"#"<keyName>"#"<keyValue>). The keyValue is the
only required portion of the attribute.
With UDDIv3, uddiBindingTemplates also supports the uddiCategoryBag
element and they can also be categorized according to any of several
available taxonomy-based classification schemes.