[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 4403

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


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/