Individual Submission B. Bergeson
K. Boogert
Internet Draft Novell, Inc.
Document: draft-bergeson-uddi-ldap-schema-01.txt May, 2002
Category: Informational Expires Nov, 2002
LDAP Schema for UDDI
1. Status of this Memo
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.
Editorial comments may be sent to bruce.bergeson@novell.com. General
discussion may be directed to the LDAPEXT WG List.
2. Abstract
This document defines the schema for representing Universal
Description Discovery & Integration (referred to here as UDDI) data
types [UDDI] in an LDAP directory [LDAPV3]. It defines schema
elements to represent a businessEntity, a businessService, a
bindingTemplate, a tModel, and a publisherAssertion.
3. Conventions used in this document
The imperatives from [RFC2119] used in this document are to be
interpreted as described there.
4. Representation of UDDI Data Structures
This document defines schema elements to represent the five UDDI
data structure types: a businessEntity, a businessService, a
bindingTemplate, a tModel, and a publisherAssertion. Portions of
[UDDI] are repeated here for clarity.
Bergeson and Boogert Internet-Draft 1
LDAP Schema for UDDI May 2002
The information that makes up a registration in UDDI consists of
these five 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 are
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).
4.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.
4.1.1 Representation in the Directory
A businessEntity is represented in the directory by the attributes
uddiBusinessKey, uddiAuthorizedName, uddiOperator,
uddiDiscoveryURLs, uddiName, uddiDescription, uddiIdentifierBag, and
uddiCategoryBag, as defined in section 5. A businessEntity may
contain zero or more instances of uddiContact and
uddiBusinessService. The mandatory attribute, uddiBusinessKey,
contains the unique identifier for a given instance of a
businessEntity.
businessEntity's definition is given in Section 6.
4.2 businessService
The businessService instances each represent a logical service
classification. 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.
Bergeson & Boogert Internet-Draft 2
LDAP Schema for UDDI May 2002
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.
4.2.1 Representation in the Directory
A businessService is represented in the directory by the attributes
uddiBusinessKey, uddiServiceKey, uddiName, uddiDescription, and
uddiCategoryBag, as defined in section 5. 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 6.
4.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.
Each bindingTemplate instance has a single logical businessService
parent, which in turn has a single logical businessEntity parent.
4.3.1 Representation in the Directory
A bindingTemplate is represented in the directory by the attributes
uddiBindingKey, uddiServcieKey, uddiDesctiption, uddiAccessPoint,
and uddiHostingRedirector, as defined in section 5. 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 6.
4.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
Bergeson & Boogert Internet-Draft 3
LDAP Schema for UDDI May 2002
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's a
key, a name, an optional description, and then a 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.
4.4.1 Representation in the Directory
A tModel is represented in the directory by the attributes
uddiTModelKey, uddiAuthorizedName, uddiOperator, uddiName,
uddiDescription, uddiOverviewDescription, uddiOverviewURL,
uddiIdentifeierBag, and uddiCategoryBag, as defined in section 5. A
tModel may also contain a uddiHidden to logically delete a tModel.
The mandatory attribute, uddiTModelKey, contains the unique
identifier for a given instance of a tModel.
tModel's definition is given in Section 6.
4.5 publisherAssertion
Many businesses, like 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.
4.5.1 Representation in the Directory
A publisherAssertion is represented in the directory by the
attributes uddiFromKey, uddiToKey, uddiKeyedReference, and uddiUUID,
as defined in section 5. The mandatory attribute, uddiUUID,
contains the unique identifier for a given instance of a
publisherAssertion.
publisherAssertion's definition is given in Section 6.
5. Attribute Type Definitions
The following attribute types are defined in this document:
uddiBusinessKey
uddiAuthorizedName
uddiOperator
uddiName
uddiDescription
uddiDiscoveryURLs
uddiUseType
Bergeson & Boogert Internet-Draft 4
LDAP Schema for UDDI May 2002
uddiPersonName
uddiPhone
uddiEMail
uddiSortCode
uddiTModelKey
uddiAddressLine
uddiIdentifierBag
uddiCategoryBag
uddiKeyedReference
uddiServiceKey
uddiBindingKey
uddiAccessPoint
uddiHostingRedirector
uddiInstanceDescription
uddiInstanceParms
uddiOverviewDescription
uddiOverviewURL
uddiFromKey
uddiToKey
uddiUUID
uddiIsHidden
Note that OIDs for the attribute types in this document have not
been assigned. All OIDs are in brackets, <OID-TBD>, as a
placeholder until real OIDs are assigned.
5.1 uddiBusinessKey
Used in uddiBusinessEntity and uddiBusinessService.
The uddiBusinessKey is the unique identifier for a given instance of
an uddiBusinessEntity. However 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 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.
( <OID-TBD>
NAME 'uddiBusinessKey'
DESC 'businessEntity unique identifier'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
5.2 uddiAuthorizedName
Bergeson & Boogert Internet-Draft 5
LDAP Schema for UDDI May 2002
The uddiAuthorizedName is the recorded name of the individual that
published the uddiBusinessEntity data. This data is generated by
the controlling operator and should not be supplied within
save_business operations.
( <OID-TBD>
NAME 'uddiAuthorizedName'
DESC 'businessEntity publisher name'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
5.3 uddiOperator
The uddiOperator is the certified name of the UDDI registry site
operator that manages the master copy of the uddiBusinessEntity. The
controlling operator records this data at the time data is saved.
This data is generated and should not be supplied within
save_business operations.
( <OID-TBD>
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
)
5.4 uddiName
Used in uddiBusinessEntity and uddiBusinessService.
These are the human readable names recorded for the
uddiBusinessEntity or uddiBusinessService, adorned with a unique
xml:lang value to signify the language that they are expressed in.
Name search is provided via find_business or find_service calls.
Names may not be blank.
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.
( <OID-TBD>
NAME 'uddiName'
Bergeson & Boogert Internet-Draft 6
LDAP Schema for UDDI May 2002
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.
5.5 uddiDescription
The uddiDescription is an optional repeating element of one or more
descriptions. One description is allowed per national language code
supplied.
( <OID-TBD>
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 description value.
5.6 uddiDiscoveryURLs
This is a list of Uniform Resource Locators (URL) that point to
alternate, file based service discovery mechanisms. Each recorded
uddiBusinessEntity structure is automatically assigned a URL that
returns the individual uddiBusinessEntity structure. 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 HTTP-GET.
The expected return document is not defined. Rather, a framework for
establishing convention 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.
( <OID-TBD>
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.
5.7 uddiUseType
Bergeson & Boogert Internet-Draft 7
LDAP Schema for UDDI May 2002
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.
( <OID-TBD>
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
)
5.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".
( <OID-TBD>
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
)
5.9 uddiPhone
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.
( <OID-TBD>
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")
5.10 uddiEMail
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.
( <OID-TBD>
Bergeson & Boogert Internet-Draft 8
LDAP Schema for UDDI May 2002
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").
5.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.
( <OID-TBD>
NAME 'uddiSortCode'
DESC 'specifies an external disply mechanism'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
5.12 uddiTModelKey
This is the unique key reference that implies that the keyName
keyValue pairs given by subsequent uddiAddressLine elements are to
be interpreted by the taxonomy associated with the uddiTModel that
is referenced.
( <OID-TBD>
NAME 'uddiTModelKey'
DESC 'tModel unique identifier'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
5.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
Bergeson & Boogert Internet-Draft 9
LDAP Schema for UDDI May 2002
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.
( <OID-TBD>
NAME 'uddiAddressLine'
DESC 'address'
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.
5.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. For a full
description of the structures involved in establishing an identity,
see UDDI Version 2.0 Data Structure Specification - Appendix A:
Using Identifiers.
( <OID-TBD>
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.
5.15 uddiCategoryBag
Bergeson & Boogert Internet-Draft 10
LDAP Schema for UDDI May 2002
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 greatly enhances the search behaviors
exposed by the find_xx messages defined in the UDDI Version 2.0 API
Specification. For a full description of structures involved in
establishing categorization information, see UDDI Version 2.0 Data
Structure Specification - Appendix B: Using categorization.
( <OID-TBD>
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.
5.16 uddiKeyedReference
The uddiKeyedReference is a general-purpose attribute for a name-
value pair, with an additional reference to a tModel.
( <OID-TBD>
NAME 'uddiKeyedReference'
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.
5.17 uddiServiceKey
This is the unique key for a given uddiBusinessService. When saving
a new uddiBusinessService structure, pass an empty uddiServiceKey
value. This signifies that a UUID value is to be generated. To
update an existing uddiBusinessService structure, pass the UUID
value that corresponds to the existing service. If this data is
received via an inquiry operation, the uddiServiceKey values may not
be blank. When saving a new or updated service projection, pass the
uddiServiceKey of the referenced uddiBusinessService structure.
This attribute is optional when the uddiBindingTemplate data is
contained within a fully expressed parent that already contains a
Bergeson & Boogert Internet-Draft 11
LDAP Schema for UDDI May 2002
uddiServiceKey value. If the uddiBindingTemplate data is rendered
into XML and has no containing parent that has within its data a
uddiServiceKey, the value of the uddiServiceKey that is the ultimate
containing parent of the uddiBindingTemplate 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.
( <OID-TBD>
NAME 'uddiServiceKey'
DESC 'businessService unique identifier'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
5.18 uddiBindingKey
This is the unique key for a given uddiBindingTemplate. When saving
a new uddiBindingTemplate structure, pass an empty uddiBindingKey
value. This signifies that a UUID value is to be generated. To
update an existing uddiBindingTemplate, pass the UUID value that
corresponds to the existing uddiBindingTemplate instance. If this
data is received via an inquiry operation, the uddiBindingKey values
may not be blank.
( <OID-TBD>
NAME 'uddiBindingKey'
DESC 'bindingTemplate unique identifier'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
5.19 uddiAccessPoint
The uddiAccessPoint element is an attribute-qualified pointer to a
service entry point. The notion of service at the metadata level
seen here is fairly abstract and many types of entry points are
accommodated. A single attribute is provided named URLType.
Required attribute qualified element8. This element is a text field
that is used to convey the entry point address suitable for calling
a particular Web service. This may be a URL, an electronic mail
address, or even a telephone number. No assumptions about the type
of data in this field can be made without first understanding the
technical requirements associated with the Web service.
( <OID-TBD>
NAME 'uddiAccessPoint'
DESC 'entry point address to call a web service'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
Bergeson & Boogert Internet-Draft 12
LDAP Schema for UDDI May 2002
SINGLE-VALUE
)
The URLType value "#" precedes the accessPoint value.
5.20 uddiHostingRedirector
The uddiHostingRedirector element is used to designate that a
uddiBindingTemplate entry is a pointer to a different
uddiBindingTemplate entry. The value in providing this facility is
seen when a business or entity wants to expose a service description
(e.g. advertise that they have a service available that suits a
specific purpose) that is actually a service that is described in a
separate uddiBindingTemplate record. This might occur when a service
is remotely hosted (hence the name of this element), or when many
service descriptions could benefit from a single service
description.
The uddiHostingRedirector element has a single attribute and no
element content. The attribute is a uddiBindingKey value that is
suitable within the same UDDI registry instance for querying and
obtaining the uddiBindingDetail data that is to be used.
More on the uddiHostingRedirector can be found in the appendices for
the UDDI Version 2.0 API Specification.
Required element if uddiAccessPoint not provided. This element is
adorned with a uddiBindingKey attribute, giving the redirected
reference to a different uddiBindingTemplate. If you query a
uddiBindingTemplate and find a uddiHostingRedirector value, you
should retrieve that uddiBindingTemplate and use it in place of the
one containing the uddiHostingRedirector data.
( <OID-TBD>
NAME 'uddiHostingRedirector'
DESC 'designates a pointer to another bindingTemplate'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
5.21 uddiInstanceDescription
This is an optional repeating element. This is one or more language
qualified text descriptions that designate what role a uddiTModel
reference plays in the overall service description.
( <OID-TBD>
NAME 'uddiInstanceDescription'
DESC 'instance details description'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
Bergeson & Boogert Internet-Draft 13
LDAP Schema for UDDI May 2002
The xml:lang value "#" precedes the description value.
5.22 uddiInstanceParms
The uddiInstance Parms is an Optional element of the uddiInstance.
Used to contain settings parameters or a URL reference to a file
that contains settings or parameters required to use a specific
facet of a uddiBindingTemplate description. If used to house the
parameters themselves, the suggested content is a namespace
qualified XML string -
- using a namespace outside of the UDDI schema.
If used to house a URL pointer to a file, the suggested format is
URL that is suitable for retrieving the settings or parameters via
HTTP-GET.
( <OID-TBD>
NAME 'uddiInstanceParms'
DESC 'URL reference to required settings'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
5.23 uddiOverviewDescription
This is optional repeating element. This language-qualified string
is intended to hold a short descriptive overview of how a particular
uddiTModel is to be used.
( <OID-TBD>
NAME 'uddiOverviewDescription'
DESC 'outlines tModel usage'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
The xml:lang value "#" precedes the description value.
5.24 uddiOverviewURL
This is an optional element. This string data element is to be used
to hold a URL reference to a long form of an overview document that
covers the way a particular uddiTModel specific reference is used as
a component of an overall web service description. The suggested
format is a URL that is suitable for retrieving an HTML based
description via a web browser or HTTP-GET operation.
( <OID-TBD>
NAME 'uddiOverviewURL'
DESC 'URL reference to overview document'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
Bergeson & Boogert Internet-Draft 14
LDAP Schema for UDDI May 2002
5.25 uddiFromKey
The uddiFromKey is a required element. This is the unique key
reference to the first uddiBusinessEntity the assertion is made for.
( <OID-TBD>
NAME 'uddiFromKey'
DESC 'unique businessEntity key reference'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
5.26 uddiToKey
The uddiToKey is a required element. This is the unique key
reference to the second uddiBusinessEntity the assertion is made
for.
( <OID-TBD>
NAME 'uddiToKey'
DESC 'unique businessEntity key reference'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
5.27 uddiUUID
The uddiUUID is a required element. This is to insure unique
identification of uddiContact, uddiAddress, and
uddiPublisherAssertion objects.
( <OID-TBD>
NAME 'uddiUUID'
DESC 'unique attribute'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
5.28 uddiIsHidden
Used to provide functionality for the delete_tModel operation.
Logical deletion hides the deleted tModels from find_tModel result
sets but does not physically delete it.
( <OID-TBD>
NAME 'uddiIsHidden'
DESC 'isHidden attribute'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
Bergeson & Boogert Internet-Draft 15
LDAP Schema for UDDI May 2002
SINGLE-VALUE
)
6. Object Class Definitions
The following object classes are defined in this document:
uddiBusinessEntity
uddiContact
uddiAddress
uddiBusinessService
uddiBindingTemplate
uddiTModelInstanceInfo
uddiTModel
uddiPublisherAssertion
Note that OIDs for the object classes in this document have not been
assigned. All OIDs are in brackets, <OID-TBD>, as a placeholder
until real OIDs are assigned.
6.1 uddiBusinessEntity
This structural object class represents a businessEntity.
( <OID-TBD>
NAME 'uddiBusinessEntity'
SUP top
STRUCTURAL
MUST ( uddiBusinessKey $
uddiName)
MAY ( uddiAuthorizedName $
uddiOperator $
uddiDiscoveryURLs $
uddiDescription $
uddiIdentifierBag $
uddiCategoryBag )
)
6.2 uddiContact
This structural object class represents a contact. It is contained
by an uddiBusinessEntity.
( <OID-TBD>
NAME 'uddiContact'
SUP top
STRUCTURAL
MUST ( uddiPersonName $
uddiUUID )
MAY ( uddiUseType $
uddiDescription $
uddiPhone $
Bergeson & Boogert Internet-Draft 16
LDAP Schema for UDDI May 2002
uddiEMail )
)
6.3 uddiAddress
This structural object class represents an address. It is contained
by an uddiContact.
( <OID-TBD>
NAME 'uddiAddress'
SUP top
STRUCTURAL
MUST ( uddiUUID )
MAY ( uddiUseType $
uddiSortCode $
uddiTModelKey $
uddiAddressLine )
)
6.4 uddiBusinessService
This structural object class represents a businessService.
( <OID-TBD>
NAME 'uddiBusinessService'
SUP top
STRUCTURAL
MUST ( uddiServiceKey $
uddiName )
MAY ( uddiBusinessKey $
uddiDescription $
uddiCategoryBag )
)
6.5 uddiBindingTemplate
This structural object class represents a bindingTemplate.
( <OID-TBD>
NAME 'uddiBindingTemplate'
SUP top
STRUCTURAL
MUST ( uddiBindingKey )
MAY ( uddiServiceKey $
uddiDescription $
uddiAccessPoint $
uddiHostingRedirector )
)
6.6 uddiTModelInstanceInfo
This structural object class represents a tModelInstanceInfo. It is
contained by an uddiBindingTemplate.
Bergeson & Boogert Internet-Draft 17
LDAP Schema for UDDI May 2002
( <OID-TBD>
NAME 'uddiTModelInstanceInfo'
SUP top
STRUCTURAL
MUST ( uddiTModelKey )
MAY ( uddiDescription $
uddiInstanceDescription $
uddiInstanceParms $
uddiOverviewDescription $
uddiOverviewURL )
)
6.7 uddiTModel
This structural object class represents a tModel.
( <OID-TBD>
NAME 'uddiTModel'
SUP top
STRUCTURAL
MUST ( uddiTModelKey $
UddiName )
MAY ( uddiAuthorizedName $
uddiOperator $
uddiDescription $
uddiOverviewDescription $
uddiOverviewURL $
uddiIdentifierBag $
uddiCategoryBag $
uddiIsHidden )
)
6.8 uddiPublisherAssertion
This structural object class represents a publisherAssertion.
( <OID-TBD>
NAME 'uddiPublisherAssertion'
SUP top
STRUCTURAL
MUST ( uddiFromKey $
uddiToKey $
uddiKeyedReference $
uddiUUID )
)
7. Name Forms
This section defines the required hierarchical structure rules and
naming attributes for the object classess defined in section 6.
The following name forms are defined in this document:
Bergeson & Boogert Internet-Draft 18
LDAP Schema for UDDI May 2002
uddiBusinessEntityNameForm
uddiContactNameForm
uddiAddressNameForm
uddiBusinessServiceNameForm
uddiBindingTemplateNameForm
uddiTModelInstanceInfoNameForm
uddiTModelNameForm
uddiPublisherAssertionNameForm
Note that OIDs for the structure rules in this document have not
been assigned. All OIDs are in brackets, <OID-TBD>, as a
placeholder until real OIDs are assigned.
7.1 uddiBusinessEntityNameForm
This name form defines the naming attribute for a businessEntity.
( <OID-TBD>
NAME 'uddiBusinessEntityNameForm'
OC uddiBusinessEntity
MUST ( uddiBusinessKey $ uddiName )
)
7.2 uddiContactNameForm
This name form defines the naming attribute for a contact.
( <OID-TBD>
NAME 'uddiContactNameForm'
OC uddiContact
MUST ( uddiUUID )
)
7.3 uddiAddressNameForm
This name form defines the naming attribute for an address.
( <OID-TBD>
NAME 'uddiAddressNameForm'
OC uddiAddress
MUST ( uddiUUID )
)
7.4 uddiBusinessServiceNameForm
This name form defines the naming attribute for a businessService.
( <OID-TBD>
NAME 'uddiBusinessServiceNameForm'
OC uddiBusinessService
MUST ( uddiServiceKey )
)
Bergeson & Boogert Internet-Draft 19
LDAP Schema for UDDI May 2002
7.5 uddiBindingTemplateNameForm
This name form defines the naming attribute for a bindingTemplate.
( <OID-TBD>
NAME 'uddiBindingTemplateNameForm'
OC uddiBindingTemplate
MUST ( uddiBindingKey )
)
7.6 uddiTModelInstanceInfoNameForm
This name form defines the naming attribute for a
tModelInstanceInfo.
( <OID-TBD>
NAME 'uddiTModelInstanceInfoNameForm'
OC uddiTModelInstanceInfo
MUST ( uddiTModelKey )
)
7.7 uddiTModelNameForm
This name form defines the naming attribute for a tModel.
( <OID-TBD>
NAME 'uddiTModelNameForm'
OC uddiTModel
MUST ( uddiTModelKey )
)
7.8 uddiPublisherAssertionNameForm
This name form defines the naming attribute for a
publisherAssertion.
( <OID-TBD>
NAME 'uddiPublisherAssertionNameForm'
OC uddiPublisherAssertion
MUST ( uddiUUID )
)
8. DIT Structure Rules
This section defines the required hierarchical structure rules for
the object classess defined in section 6.
The following structure rules are defined in this document:
uddiBusinessEntityStructureRule
uddiContactStrucureRule
Bergeson & Boogert Internet-Draft 20
LDAP Schema for UDDI May 2002
uddiAddressStructureRule
uddiBusinessServiceStructureRule
uddiBindingTemplateStructureRule
uddiTModelInstanceInfoStructureRule
Note that rule identifiers defined here show the relationship
between structure rules. Implementations may use different
identifiers but must follow the same hierarchical model.
8.1 uddiBusinessEntityStructureRule
( 1
NAME 'uddiBusinessEntityStructureRule'
FORM uddiBusinessEntityNameForm
)
8.2 uddiContactStrucureRule
This structure rule defines the object class containment for a
contact.
( 2
NAME 'uddiContactStrucureRule'
FORM uddiContactNameForm
SUP ( 1 )
)
8.3 uddiAddressStructureRule
This structure rule defines the object class containment for a
address.
( 3
NAME 'uddiAddressStructureRule'
FORM uddiAddressNameForm
SUP ( 2 )
)
8.4 uddiBusinessServiceStructureRule
This structure rule defines the object class containment for a
businessService.
( 4
NAME 'uddiBusinessServiceStructureRule'
FORM uddiBusinessServiceNameForm
SUP ( 1 )
)
8.5 uddiBindingTemplateStructureRule
This structure rule defines the object class containment for a
bindingTemplate.
Bergeson & Boogert Internet-Draft 21
LDAP Schema for UDDI May 2002
( 5
NAME 'uddiBindingTemplateStructureRule'
FORM uddiBindingTemplateNameForm
SUP ( 4 )
)
8.6 uddiTModelInstanceInfoStructureRule
This structure rule defines the object class containment for a
tModelInstanceInfo.
( 6
NAME 'uddiTModelInstanceInfoStructureRule'
FORM uddiTModelInstanceInfoNameForm
SUP ( 5 )
)
9. Security Considerations
Storing UDDI data into the directory enables the data to be examined
and used outside the environment in which it was originally created.
The directory entry containing the UDDI data could be read and
modified within the constraints imposed by the access control
mechanisms of the directory.
10. References
[LDAPv3] M. Wahl, s. Kille and T. Howes, "Lightweight Directory
Access Protocol (v3)", Internet Standard, December,
1997. Available as RFC2251
[UDDI] UDDI.ORG, "UDDI version 2.0 Data Structure Reference,"
http://www.uddi.org
[RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate
Requirement Levels," Internet Standard, December, 1997.
Available as RFC2253
11. Author's Addresses
Bruce Bergeson
Novell, Inc.
Mail Stop PRV-H411
1800 S Novell Place
Provo, UT 84606
Phone: +1 801 861 3854
Email: bruce.bergeson@novell.com
Bergeson & Boogert Internet-Draft 22
LDAP Schema for UDDI May 2002
Kent Boogert
Novell, Inc.
1800 S Novell Place
Provo, UT 84606
Phone: +1 801 861 3212
Email: kent.boogert@novell.com
Bergeson & Boogert Internet-Draft 23
Datatracker
draft-bergeson-uddi-ldap-schema-01
Internet-Draft
