doc: Add RFC documents

1 files changed, 2355 insertions, 0 deletions

diff --git a/doc/rfc/rfc4403.txt b/doc/rfc/rfc4403.txt
new file mode 100644
index 0000000..bcf5bfe
--- /dev/null
+++ b/doc/rfc/rfc4403.txt
@@ -0,0 +1,2355 @@
+
+
+
+
+
+
+Network Working Group                                        B. Bergeson
+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
+
+
+
+
+
+
+
+
+
+Bergeson, et al.             Informational                      [Page 1]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+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
+
+
+
+Bergeson, et al.             Informational                      [Page 2]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+   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.
+
+
+
+
+
+
+Bergeson, et al.             Informational                      [Page 3]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+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.
+
+
+
+Bergeson, et al.             Informational                      [Page 4]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+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
+
+
+
+
+Bergeson, et al.             Informational                      [Page 5]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+   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"
+
+
+
+Bergeson, et al.             Informational                      [Page 6]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+   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
+
+
+
+
+
+Bergeson, et al.             Informational                      [Page 7]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+   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
+
+
+
+Bergeson, et al.             Informational                      [Page 8]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+   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.
+
+
+
+
+Bergeson, et al.             Informational                      [Page 9]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+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
+      )
+
+
+
+
+Bergeson, et al.             Informational                     [Page 10]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+   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
+
+
+
+Bergeson, et al.             Informational                     [Page 11]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+   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,
+
+
+
+Bergeson, et al.             Informational                     [Page 12]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+   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.
+
+4.16.  uddiKeyedReference
+
+   The uddiKeyedReference is a general-purpose attribute for a name-
+   value pair, with an additional reference to a tModel.
+
+      ( 1.3.6.1.1.10.4.16 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.  With UDDIv3, the tModelKey
+   also becomes a mandatory part of the attribute.
+
+   Also, UDDIv3 defines KeyedReferenceGroups for CategoryBags.  A
+   keyedReferenceGroup contains a tModelKey and a simple list of
+   KeyedReference structures.  The uddiKeyedReference attribute will
+   support KeyedReferenceGroups by suffixing the tModelKey for
+   KeyedReferenceGroup to each of the keyedReference values associated
+   with the group.
+
+   For example, to represent a keyedReference group containing a list of
+   2 keyed references, the attribute will hold the following 2 strings
+   as its values:
+
+
+
+
+Bergeson, et al.             Informational                     [Page 13]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+      tModelKey1#KeyName1#KeyValue1#KeyedReferenceGroup1_tModelKey
+      tModelKey2#KeyName2#KeyValue2#KeyedReferenceGroup1_tModelKey
+
+4.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 a uddiServiceKey is
+   received via an inquiry operation, the key 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
+   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.
+
+      ( 1.3.6.1.1.10.4.17 NAME 'uddiServiceKey'
+        DESC 'businessService unique identifier'
+        EQUALITY caseIgnoreMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+        SINGLE-VALUE
+      )
+
+4.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 a
+   uddiBindingKey is received via an inquiry operation, the key values
+   may not be blank.
+
+      ( 1.3.6.1.1.10.4.18 NAME 'uddiBindingKey'
+        DESC 'bindingTemplate unique identifier'
+        EQUALITY caseIgnoreMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+        SINGLE-VALUE
+      )
+
+
+
+
+Bergeson, et al.             Informational                     [Page 14]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+4.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.
+
+      ( 1.3.6.1.1.10.4.19 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
+        SINGLE-VALUE
+      )
+
+   The URLType value precedes the accessPoint value by a separating '#'.
+
+   With UDDIv3, the "URLType" attribute is replaced by a "UseType"
+   attribute.  Using this UseType attribute, the accessPoint attribute
+   can model a hostingRedirector or support indirection to indicate that
+   the accesspoint is specified within a remotely hosted WSDL document.
+
+   For a UDDIv3 registry that needs to support UDDIv2 clients, the
+   attribute must allow the representation of URLType and UseType values
+   independently.
+
+   The UDDIv3 spec specifies the following logic for mapping values
+   between URLType and UseType: If an entity is saved with the v3
+   namespace and a v2 inquiry is made, the URLType will be returned as
+   "other".  In the case when a v3 inquiry is made on an entity
+   published with the v2 namespace, the v3 useType attribute will be
+   returned as "endPoint".
+
+   For implementations that need to explicitly model both forms, the
+   recommended format is as follows: v2URLType#v3UseType#Address
+
+4.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
+
+
+
+Bergeson, et al.             Informational                     [Page 15]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+   (e.g., advertise that it has a service available that suits a
+   specific purpose) that is actually a service 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 [UDDIapi].
+
+   Required element if uddiAccessPoint is 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.
+
+      ( 1.3.6.1.1.10.4.20 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
+      )
+
+   With UDDIv3, the hostingRedirector is a deprecated element, since its
+   functionality is now covered by the accessPoint.  For backward-
+   compatibility, it can still be used, but it is not recommended.
+
+4.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.
+
+      ( 1.3.6.1.1.10.4.21 NAME 'uddiInstanceDescription'
+        DESC 'instance details 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.
+
+
+
+
+
+Bergeson, et al.             Informational                     [Page 16]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+4.22.  uddiInstanceParms
+
+   The uddiInstanceParms is an optional element of the uddiInstance.  It
+   is 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 a URL that is
+   suitable for retrieving the settings or parameters via HTTP-GET.
+
+      ( 1.3.6.1.1.10.4.22 NAME 'uddiInstanceParms'
+        DESC 'URL reference to required settings'
+        EQUALITY caseIgnoreMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+        SINGLE-VALUE
+      )
+
+4.23.  uddiOverviewDescription
+
+   This is an optional repeating element.  This language-qualified
+   string is intended to hold a short descriptive overview of how a
+   particular uddiTModel is to be used.
+
+      ( 1.3.6.1.1.10.4.23 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 name value, with the "#" character
+   used as the separator.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al.             Informational                     [Page 17]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+4.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 recommended
+   format for the overviewURL is a URI that is suitable for retrieving
+   the actual overview document with an HTTP-GET operation, for example,
+   via a Web browser.
+
+      ( 1.3.6.1.1.10.4.24 NAME 'uddiOverviewURL'
+        DESC 'URL reference to overview document'
+        EQUALITY caseIgnoreMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+        SINGLE-VALUE
+      )
+
+   With UDDIv3, uddiOverviewURL becomes multi-valued to allow the
+   representation of multiple OverviewDocs within a single
+   InstanceDetail element.
+
+   Modeling multiple OverviewDocs within an InstanceDetail element:
+
+   In UDDIv3, the InstanceDetails element in TmodelInstanceInfo can have
+   multiple OverviewDoc's.  In UDDIv2, we could have only 1 OverviewDoc.
+   To retain the grouping between a set of overviewDescriptions and
+   overviewURL, we can make both OverviewDoc and OverviewURL multi-
+   valued, and have a "group ID" Prefix to each value (to group
+   OverviewDescriptions and OverviewURL).
+
+   An example is shown below:
+
+         Overview Description                            OverviewURL
+         1#xml:lang#overviewDescription1         1#UseType#overviewURL
+         1#xml:lang#overviewDescription2         2#UseType#overviewURL
+         1#xml:lang#overviewDescription3         4#UseType#overviewURL
+         3#xml:lang#overviewDescription1
+         3#xml:lang#overviewDescription2
+         4#xml:lang#overviewDescription1
+
+   This implies that OverviewDoc1 has 3 overview descriptions and an
+   overviewURL.  OverviewDoc2 has only an overviewURL.  OverviewDoc3 has
+   only 2 overviewDescriptions.  OverviewDoc4 also has 1 overview
+   description and an overviewURL.
+
+
+
+
+
+
+
+Bergeson, et al.             Informational                     [Page 18]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+4.25.  uddiFromKey
+
+   The uddiFromKey is a required element.  This is the unique key
+   reference to the first uddiBusinessEntity for which the assertion is
+   made.
+
+      ( 1.3.6.1.1.10.4.25 NAME 'uddiFromKey'
+        DESC 'unique businessEntity key reference'
+        EQUALITY caseIgnoreMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+        SINGLE-VALUE
+      )
+
+4.26.  uddiToKey
+
+   The uddiToKey is a required element.  This is the unique key
+   reference to the second uddiBusinessEntity for which the assertion is
+   made.
+
+      ( 1.3.6.1.1.10.4.26 NAME 'uddiToKey'
+        DESC 'unique businessEntity key reference'
+        EQUALITY caseIgnoreMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+        SINGLE-VALUE
+      )
+
+4.27.  uddiUUID
+
+   The uddiUUID is a required element.  This is to ensure unique
+   identification of uddiContact, uddiAddress, and
+   uddiPublisherAssertion objects.
+
+      ( 1.3.6.1.1.10.4.27 NAME 'uddiUUID'
+        DESC 'unique attribute'
+        EQUALITY caseIgnoreMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+        SINGLE-VALUE
+      )
+
+   With UDDIv3, this attribute will also be used for unique
+   identification of Subscription-feature-related entities.
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al.             Informational                     [Page 19]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+4.28.  uddiIsHidden
+
+   This is 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.
+
+      ( 1.3.6.1.1.10.4.28 NAME 'uddiIsHidden'
+        DESC 'isHidden attribute'
+        EQUALITY booleanMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+        SINGLE-VALUE
+      )
+
+   In case of UDDIv3, this attribute will represent the "deleted"
+   attribute value.
+
+4.29.  uddiIsProjection
+
+   This is used to identify a Business Service that has a Service
+   Projection.
+
+      ( 1.3.6.1.1.10.4.29 NAME 'uddiIsProjection'
+        DESC 'isServiceProjection attribute'
+        EQUALITY booleanMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+        SINGLE-VALUE
+      )
+
+4.30.  uddiLang
+
+   This is used to model the xml:lang value for the Address structure in
+   UDDIv3.
+
+      ( 1.3.6.1.1.10.4.30 NAME 'uddiLang'
+        DESC 'xml:lang value in v3 Address structure'
+        EQUALITY caseIgnoreMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+        SINGLE-VALUE
+      )
+
+   The following are attribute definitions to model new elements/fields
+   in UDDIv3 information model.  These attribute definitions have the
+   "uddiv3" prefix to indicate that these attributes represent UDDI
+   information model elements unique to UDDIv3.
+
+
+
+
+
+
+
+Bergeson, et al.             Informational                     [Page 20]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+4.31.  uddiv3BusinessKey
+
+   This is the unique UDDIv3 identifier for a given instance of
+   uddiBusinessEntity.  It is used in uddiBusinessEntity and
+   uddiBusinessService.
+
+   A uddiBusinessEntity will include the uddiBusinessKey (the v2 form)
+   for unique identification by UDDIv2 clients.  The uddiBusinessKey
+   (36-char) will also be the LDAP naming attribute for the
+   uddiBusinessEntity.  The uddiBusinessEntity entry MAY also include
+   the uddiv3BusinessKey, the explicit v3 form key, which can be 255
+   characters long.
+
+      ( 1.3.6.1.1.10.4.31 NAME 'uddiv3BusinessKey'
+        DESC 'UDDIv3 businessEntity unique identifier'
+        EQUALITY caseIgnoreMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+        SINGLE-VALUE
+      )
+
+4.32.  uddiv3ServiceKey
+
+   This is the unique UDDIv3 identifier for a given instance of
+   uddiBusinessService.  It is used in uddiBusinessService and
+   uddiBindingTemplate.
+
+   A uddiBusinessService will include the uddiServiceKey (the v2 form)
+   for unique identification by UDDIv2 clients.  The uddiServiceKey
+   (36-char) will also be the LDAP naming attribute for the
+   uddiBusinessService entry.  The uddiBusinessService entry MAY also
+   include the uddiv3ServiceKey, the explicit v3 form key, which can be
+   255 characters long.
+
+      ( 1.3.6.1.1.10.4.32 NAME 'uddiv3ServiceKey'
+        DESC 'UDDIv3 businessService unique identifier'
+        EQUALITY caseIgnoreMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+        SINGLE-VALUE
+      )
+
+4.33.  uddiv3BindingKey
+
+   This is the unique UDDIv3 identifier for a given instance of
+   uddiBindingTemplate.
+
+   A uddiBindingTemplate will include the uddiBindingKey (the v2 form)
+   for unique identification by UDDIv2 clients.  The uddiBindingKey
+   (36-char) will also be the LDAP naming attribute for the
+
+
+
+Bergeson, et al.             Informational                     [Page 21]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+   uddiBindingTemplate entry.  The uddiBindingTemplate entry MAY also
+   include the uddiv3BindingKey, the explicit v3 form key, which can be
+   255 characters long.
+
+      ( 1.3.6.1.1.10.4.33 NAME 'uddiv3BindingKey'
+        DESC 'UDDIv3 BindingTemplate unique identifier'
+        EQUALITY caseIgnoreMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+        SINGLE-VALUE
+      )
+
+4.34.  uddiv3TModelKey
+
+   This is the unique UDDIv3 identifier for a given instance of a
+   uddiTModel.
+
+   A uddiTModel will include the uddiTModelKey (the v2 form) for unique
+   identification by UDDIv2 clients.  The uddiTModelKey (41-char) will
+   also be the LDAP naming attribute for the uddiTModel entry.  The
+   uddiTModel entry MAY also include the uddiv3TModelKey, the explicit
+   v3 form key, which can be 255 characters long.
+
+      ( 1.3.6.1.1.10.4.34 NAME 'uddiv3TModelKey'
+        DESC 'UDDIv3 TModel unique identifier'
+        EQUALITY caseIgnoreMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+        SINGLE-VALUE
+      )
+
+   The tModelKey is also used in a KeyedReference and in Address
+   structures.  In all instances where a tModelKey is used as a
+   reference to tModel, the v3 form of the tModel key (viz.
+   uddiv3TModelKey) will be the form used, since using the v2 form key
+   will require translating it to the v3 key by the UDDI Server, which
+   may invalidate the digital signature of the entity.
+
+4.35.  uddiv3DigitalSignature
+
+   The UDDIv3 v3 schema supports the signing of the following UDDI
+   elements using "XML-Signature Syntax and Processing" (see
+   http://www.w3.org/TR/xmldsig-core/).
+
+      ..businessEntity
+      ..businessService
+      ..bindingTemplate
+      ..tModel
+      ..publisherAssertion
+
+
+
+
+Bergeson, et al.             Informational                     [Page 22]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+   This uddiv3DigitalSignature attribute holds the digital signature for
+   the corresponding UDDI entity.
+
+      ( 1.3.6.1.1.10.4.35 NAME 'uddiv3DigitalSignature'
+        DESC 'UDDIv3 entity digital signature'
+        EQUALITY caseExactMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+        )
+
+   A Signature element SHOULD be generated according to the required
+   steps of "Core Generation" in XML-Signature Syntax and Processing.
+   The signature should be calculated on the top-level element that will
+   be stored by the registry as a result of the Publication API call.
+   This element, referred to as the data object in the XML-Signature and
+   Syntax specification, is the businessEntity element for save_business
+   API calls, the businessService element for save_service API calls,
+   the bindingTemplate for save_binding API calls, the tModel for
+   save_tModel API calls, and the publisherAssertion for
+   set_publisherAssertions and add_publisherAssertion API calls.
+
+   The signature should be generated on the elements before they are
+   added to the body of an API call.  Also, according to the signature
+   generation, all children of the element being signed are included in
+   the generation of the signature unless first excluded by application
+   of a transform.  Due to the containment of service projections as
+   businessService elements within a businessEntity element, this also
+   means that changes to the projected service will render a signature
+   of the businessEntity containing the projection invalid, unless a
+   businessService element representing a service projection is excluded
+   using a transform.
+
+   Due to the location of the sequence of Signature elements within an
+   element that is to be signed, the signature is "enveloped".  As a
+   result of the enveloping of the signature, it is necessary to apply
+   at least one transformation on the signed entity to exclude the
+   signature or signature(s).  The transformation selected by a
+   publisher or the XML-Signature tool is specified in a Transform
+   element inside the Signature element.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al.             Informational                     [Page 23]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+4.36.  uddiv3NodeId
+
+   This attribute contains the Node Identity for a UDDIv3 node.
+
+      ( 1.3.6.1.1.10.4.36 NAME 'uddiv3NodeId'
+        DESC 'UDDIv3 Node Identifier'
+        EQUALITY caseIgnoreMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+        SINGLE-VALUE
+      )
+
+4.37.  uddiv3EntityModificationTime
+
+   This attribute is used to maintain the last modification time for a
+   UDDI entity.  It is needed in the context of maintaining the
+   modifiedIncludingChildren element.  When a child entity (e.g.,
+   uddiBindingTemplate) is updated, the parent entity (e.g.,
+   uddiBusinessService) LDAP timestamp also gets updated.  The
+   uddiv3EntityModificationTime attribute saves the last modification
+   time of the parent entity (uddiBusinessService in this case).
+
+      ( 1.3.6.1.1.10.4.37 NAME 'uddiv3EntityModificationTime'
+        DESC 'UDDIv3 Last Modified Time for Entity'
+        EQUALITY generalizedTimeMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+        SINGLE-VALUE
+      )
+
+   The following attribute definitions define attributes related to the
+   modeling of UDDIv3 subscription-related entities in the LDAP
+   directory.
+
+   Subscription provides clients, known as subscribers, with the ability
+   to register their interest in receiving information concerning
+   changes made in a UDDI registry.  These changes can be scoped based
+   on preferences provided with the request.  The uddiv3Subscription
+   object class is used to model registered UDDIv3 subscriptions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al.             Informational                     [Page 24]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+4.38.  uddiv3SubscriptionKey
+
+   This is the unique UDDIv3 identifier for a given instance of a
+   uddiv3Subscription entity.
+
+      ( 1.3.6.1.1.10.4.38 NAME 'uddiv3SubscriptionKey'
+        DESC 'UDDIv3 Subscription unique identifier'
+        EQUALITY caseIgnoreMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+        SINGLE-VALUE
+      )
+
+4.39.  uddiv3SubscriptionFilter
+
+   This attribute contains the UDDIv3 Subscription Filter, specified as
+   part of the save_subscription API, i.e., the Inquiry API specified as
+   filtering criteria with a registered subscription.  The filtering
+   criteria limits the scope of a subscription to a subset of registry
+   records.  The get_xx and find_xx APIs are all valid choices for use
+   as a subscriptionFilter.  Only one of these can be chosen for each
+   subscription.
+
+      ( 1.3.6.1.1.10.4.39 NAME 'uddiv3SubscriptionFilter'
+        DESC 'UDDIv3 Subscription Filter'
+        EQUALITY caseIgnoreMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+        SINGLE-VALUE
+      )
+
+4.40.  uddiv3NotificationInterval
+
+   This attribute contains the Notification Interval string.  It is of
+   the type xsd:duration and specifies how often Asynchronous change
+   notifications are to be provided to a subscriber.
+
+      ( 1.3.6.1.1.10.4.40 NAME 'uddiv3NotificationInterval'
+        DESC 'UDDIv3 Notification Interval'
+        EQUALITY caseIgnoreMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+        SINGLE-VALUE
+      )
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al.             Informational                     [Page 25]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+4.41.  uddiv3MaxEntities
+
+   This attribute contains the maximum number of entities to be returned
+   as part of a subscription notification.  It is an integer and
+   specifies the maximum number of entities in a notification returned
+   to a subscription listener.
+
+      ( 1.3.6.1.1.10.4.41 NAME 'uddiv3MaxEntities'
+        DESC 'UDDIv3 Subscription maxEntities field'
+        EQUALITY integerMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+        SINGLE-VALUE
+      )
+
+4.42.  uddiv3ExpiresAfter
+
+   This attribute specifies the Expiry Time associated with a
+   subscription.  It is of the XML Schema type xsd:dateTime.
+
+      ( 1.3.6.1.1.10.4.42 NAME 'uddiv3ExpiresAfter'
+        DESC 'UDDIv3 Subscription ExpiresAfter field'
+        EQUALITY generalizedTimeMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+        SINGLE-VALUE
+      )
+
+4.43.  uddiv3BriefResponse
+
+   This attribute is a Boolean flag for Brief Response associated with a
+   subscription entity.  It controls the level of detail returned to a
+   subscription listener.  The default is "false" when omitted.  When
+   set to "true", it indicates that the subscription results are to be
+   returned to the subscriber in the form of a keyBag, listing all of
+   the entities that matched the subscriptionFilter.
+
+      ( 1.3.6.1.1.10.4.43 NAME 'uddiv3BriefResponse'
+        DESC 'UDDIv3 Subscription ExpiresAfter field'
+        EQUALITY booleanMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+        SINGLE-VALUE
+      )
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al.             Informational                     [Page 26]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+4.44.  uddiv3EntityKey
+
+   This is the unique UDDIv3 identifier for a given instance of a core
+   UDDI data structure that is to be logged as an Obituary entry
+   uddiv3EntityObituary.  When a core UDDIv3 Entity is deleted and there
+   is an active subscription registered against this UDDI Entity, an
+   Obituary entry is created, in which the v3 key of the deleted entry
+   is logged as part of the uddiv3EntityKey attribute.
+
+      ( 1.3.6.1.1.10.4.44 NAME 'uddiv3EntityKey'
+        DESC 'UDDIv3 Entity unique identifier'
+        EQUALITY caseIgnoreMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+        SINGLE-VALUE
+      )
+
+4.45.  uddiv3EntityCreationTime
+
+   This attribute is used to log the original Creation Time for a UDDI
+   Entity that is deleted in the uddiv3EntityObituary entry.
+
+   It is also used in uddiBusinessService and uddiBindingTemplate.  A
+   Move BS operation needs to delete and recreate BT sub-tree due to
+   lack of support for moving a sub-tree in many LDAPv3 servers.  This
+   attribute is used to save the original creation time of the BT during
+   a Move BS.
+
+      ( 1.3.6.1.1.10.4.45 NAME 'uddiv3EntityCreationTime'
+        DESC 'UDDIv3 Entity Creation Time'
+        EQUALITY generalizedTimeMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+        SINGLE-VALUE
+      )
+
+4.46.  uddiv3EntityDeletionTime
+
+   This attribute is used to log the entity deletion time for a UDDI
+   Entity that is deleted in the uddiv3EntityObituary entry.
+
+      ( 1.3.6.1.1.10.4.46 NAME 'uddiv3EntityDeletionTime'
+        DESC 'UDDIv3 Entity Deletion Time'
+        EQUALITY generalizedTimeMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+        SINGLE-VALUE
+      )
+
+
+
+
+
+
+Bergeson, et al.             Informational                     [Page 27]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+5.  Object Class Definitions
+
+   The OIDs for the object classes in this document have been registered
+   by the IANA.
+
+5.1.  uddiBusinessEntity
+
+   This structural object class represents a businessEntity.
+
+      ( 1.3.6.1.1.10.6.1 NAME 'uddiBusinessEntity'
+        SUP top
+        STRUCTURAL
+        MUST ( uddiBusinessKey $
+               uddiName)
+        MAY ( uddiAuthorizedName $
+              uddiOperator $
+              uddiDiscoveryURLs $
+              uddiDescription $
+              uddiIdentifierBag $
+              uddiCategoryBag $
+              uddiv3BusinessKey $
+              uddiv3DigitalSignature $
+              uddiv3EntityModificationTime $
+              uddiv3NodeId)
+      )
+
+5.2.  uddiContact
+
+   This structural object class represents a contact.  It is contained
+   by a uddiBusinessEntity.
+
+      ( 1.3.6.1.1.10.6.2 NAME 'uddiContact'
+        SUP top
+        STRUCTURAL
+        MUST ( uddiPersonName $
+               uddiUUID )
+        MAY ( uddiUseType $
+              uddiDescription $
+              uddiPhone $
+              uddiEMail )
+      )
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al.             Informational                     [Page 28]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+5.3.  uddiAddress
+
+   This structural object class represents an address.  It is contained
+   by a uddiContact.
+
+      ( 1.3.6.1.1.10.6.3 NAME 'uddiAddress'
+        SUP top
+        STRUCTURAL
+        MUST ( uddiUUID )
+        MAY ( uddiUseType $
+              uddiSortCode $
+              uddiTModelKey $
+              uddiv3TmodelKey $
+              uddiAddressLine $
+              uddiLang)
+      )
+
+5.4.  uddiBusinessService
+
+   This structural object class represents a businessService.
+
+      ( 1.3.6.1.1.10.6.4 NAME 'uddiBusinessService'
+        SUP top
+        STRUCTURAL
+        MUST ( uddiServiceKey )
+        MAY ( uddiName $
+           uddiBusinessKey $
+              uddiDescription $
+              uddiCategoryBag $
+              uddiIsProjection $
+              uddiv3ServiceKey $
+              uddiv3BusinessKey $
+              uddiv3DigitalSignature $
+              uddiv3EntityCreationTime $
+              uddiv3EntityModificationTime $
+              uddiv3NodeId)
+      )
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al.             Informational                     [Page 29]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+5.5.  uddiBindingTemplate
+
+   This structural object class represents a bindingTemplate.
+
+      ( 1.3.6.1.1.10.6.5 NAME 'uddiBindingTemplate'
+        SUP top
+        STRUCTURAL
+        MUST ( uddiBindingKey )
+        MAY ( uddiServiceKey $
+              uddiDescription $
+              uddiAccessPoint $
+              uddiHostingRedirector
+              uddiCategoryBag $
+              uddiv3BindingKey $
+              uddiv3ServiceKey $
+              uddiv3DigitalSignature $
+              uddiv3EntityCreationTime $
+              uddiv3NodeId)
+      )
+
+5.6.  uddiTModelInstanceInfo
+
+   This structural object class represents a tModelInstanceInfo.  It is
+   contained by a uddiBindingTemplate.
+
+      ( 1.3.6.1.1.10.6.6 NAME 'uddiTModelInstanceInfo'
+        SUP top
+        STRUCTURAL
+        MUST ( uddiTModelKey )
+        MAY ( uddiDescription $
+              uddiInstanceDescription $
+              uddiInstanceParms $
+              uddiOverviewDescription $
+              uddiOverviewURL $
+              uddiv3TmodelKey)
+      )
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al.             Informational                     [Page 30]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+5.7.  uddiTModel
+
+   This structural object class represents a tModel.
+
+      ( 1.3.6.1.1.10.6.7 NAME 'uddiTModel'
+        SUP top
+        STRUCTURAL
+        MUST ( uddiTModelKey $
+               uddiName )
+        MAY ( uddiAuthorizedName $
+              uddiOperator $
+              uddiDescription $
+              uddiOverviewDescription $
+              uddiOverviewURL $
+              uddiIdentifierBag $
+              uddiCategoryBag $
+              uddiIsHidden
+              uddiv3TModelKey $
+              uddiv3DigitalSignature $
+              uddiv3NodeId)
+      )
+
+5.8.  uddiPublisherAssertion
+
+   This structural object class represents a publisherAssertion.
+
+      ( 1.3.6.1.1.10.6.8 NAME 'uddiPublisherAssertion'
+        SUP top
+        STRUCTURAL
+        MUST ( uddiFromKey $
+               uddiToKey $
+               uddiKeyedReference $
+               uddiUUID )
+        MAY ( uddiv3DigitalSignature $
+              uddiv3NodeId)
+      )
+
+   The following are object class definitions to model new data
+   structures needed to implement the UDDIv3 information model.  These
+   object class definitions have the "uddiv3" prefix to indicate that
+   these attributes represent UDDI information model elements unique to
+   UDDIv3.
+
+
+
+
+
+
+
+
+
+Bergeson, et al.             Informational                     [Page 31]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+5.9.  uddiv3Subscription
+
+   This structural object class represents a Subscription entity.
+
+      ( 1.3.6.1.1.10.6.9 NAME 'uddiv3Subscription'
+        SUP top
+        STRUCTURAL
+        MUST ( uddiv3SubscriptionFilter $
+               uddiUUID)
+        MAY (  uddiAuthorizedName $
+               uddiv3SubscriptionKey $
+               uddiv3BindingKey $
+               uddiv3NotificationInterval $
+               uddiv3MaxEntities $
+               uddiv3ExpiresAfter $
+               uddiv3BriefResponse $
+               uddiv3NodeId)
+      )
+
+5.10.  uddiv3EntityObituary
+
+   This structural object class represents an Obituary entry for and
+   stores obituary information for deleted UDDIv3 entities needed for
+   handling subscriptions.
+
+      ( 1.3.6.1.1.10.6.10 NAME 'uddiv3EntityObituary'
+        SUP top
+        STRUCTURAL
+        MUST ( uddiv3EntityKey $
+               uddiUUID)
+        MAY (  uddiAuthorizedName $
+               uddiv3EntityCreationTime $
+               uddiv3EntityDeletionTime $
+               uddiv3NodeId)
+      )
+
+6.  Name Forms
+
+   This section defines the required hierarchical structure rules and
+   naming attributes for the object classes defined in Section 6.
+
+   The OIDs for the structure rules in this document have been
+   registered by the IANA.
+
+
+
+
+
+
+
+
+Bergeson, et al.             Informational                     [Page 32]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+6.1.  uddiBusinessEntityNameForm
+
+   This name form defines the naming attribute for a businessEntity.
+
+      ( 1.3.6.1.1.10.15.1 NAME 'uddiBusinessEntityNameForm'
+        OC uddiBusinessEntity
+        MUST ( uddiBusinessKey )
+      )
+
+6.2.  uddiContactNameForm
+
+   This name form defines the naming attribute for a contact.
+
+      ( 1.3.6.1.1.10.15.2 NAME 'uddiContactNameForm'
+        OC uddiContact
+        MUST ( uddiUUID )
+      )
+
+6.3.  uddiAddressNameForm
+
+   This name form defines the naming attribute for an address.
+
+      ( 1.3.6.1.1.10.15.3 NAME 'uddiAddressNameForm'
+        OC uddiAddress
+        MUST ( uddiUUID )
+      )
+
+6.4.  uddiBusinessServiceNameForm
+
+   This name form defines the naming attribute for a businessService.
+
+      ( 1.3.6.1.1.10.15.4  NAME 'uddiBusinessServiceNameForm'
+        OC uddiBusinessService
+        MUST ( uddiServiceKey )
+      )
+
+6.5.  uddiBindingTemplateNameForm
+
+   This name form defines the naming attribute for a bindingTemplate.
+
+      ( 1.3.6.1.1.10.15.5 NAME 'uddiBindingTemplateNameForm'
+        OC uddiBindingTemplate
+        MUST ( uddiBindingKey )
+      )
+
+
+
+
+
+
+
+Bergeson, et al.             Informational                     [Page 33]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+6.6.  uddiTModelInstanceInfoNameForm
+
+   This name form defines the naming attribute for a tModelInstanceInfo.
+
+      ( 1.3.6.1.1.10.15.6 NAME 'uddiTModelInstanceInfoNameForm'
+        OC uddiTModelInstanceInfo
+        MUST ( uddiTModelKey )
+      )
+
+6.7.  uddiTModelNameForm
+
+   This name form defines the naming attribute for a tModel.
+
+      ( 1.3.6.1.1.10.15.7 NAME 'uddiTModelNameForm'
+        OC uddiTModel
+        MUST ( uddiTModelKey )
+      )
+
+6.8.  uddiPublisherAssertionNameForm
+
+   This name form defines the naming attribute for a publisherAssertion.
+
+      ( 1.3.6.1.1.10.15.8 NAME 'uddiPublisherAssertionNameForm'
+        OC uddiPublisherAssertion
+        MUST ( uddiUUID )
+      )
+
+6.9.  uddiv3SubscriptionNameForm
+
+   This name form defines the naming attribute for a Subscription.
+
+      ( 1.3.6.1.1.10.15.9 NAME 'uddiv3SubscriptionNameForm'
+        OC uddiv3Subscription
+        MUST ( uddiUUID )
+      )
+
+6.10.  uddiv3EntityObituaryNameForm
+
+   This name form defines the naming attribute for an Entity Obituary.
+
+      ( 1.3.6.1.1.10.15.10 NAME 'uddiv3EntityObituaryNameForm'
+        OC uddiv3EntityObituary
+        MUST ( uddiUUID )
+      )
+
+
+
+
+
+
+
+Bergeson, et al.             Informational                     [Page 34]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+7.  DIT Structure Rules
+
+   This section defines the required hierarchical structure rules for
+   the object classes defined in Section 6.
+
+   Note that rule identifiers defined here show the relationship between
+   structure rules.  Implementations may use different identifiers but
+   must follow the same hierarchical model.
+
+7.1.  uddiBusinessEntityStructureRule
+
+      ( 1
+        NAME 'uddiBusinessEntityStructureRule'
+        FORM uddiBusinessEntityNameForm
+      )
+
+7.2.  uddiContactStructureRule
+
+   This structure rule defines the object class containment for a
+   contact.
+
+      ( 2
+        NAME 'uddiContactStructureRule'
+        FORM uddiContactNameForm
+        SUP ( 1 )
+      )
+
+7.3.  uddiAddressStructureRule
+
+   This structure rule defines the object class containment for an
+   address.
+
+      ( 3
+        NAME 'uddiAddressStructureRule'
+        FORM uddiAddressNameForm
+        SUP ( 2 )
+      )
+
+7.4.  uddiBusinessServiceStructureRule
+
+   This structure rule defines the object class containment for a
+   businessService.
+
+      ( 4
+        NAME 'uddiBusinessServiceStructureRule'
+        FORM uddiBusinessServiceNameForm
+        SUP ( 1 )
+      )
+
+
+
+Bergeson, et al.             Informational                     [Page 35]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+
+7.5.  uddiBindingTemplateStructureRule
+
+   This structure rule defines the object class containment for a
+   bindingTemplate.
+
+      ( 5
+        NAME 'uddiBindingTemplateStructureRule'
+        FORM uddiBindingTemplateNameForm
+        SUP ( 4 )
+      )
+
+7.6.  uddiTModelInstanceInfoStructureRule
+
+   This structure rule defines the object class containment for a
+   tModelInstanceInfo.
+
+      ( 6
+        NAME 'uddiTModelInstanceInfoStructureRule'
+        FORM uddiTModelInstanceInfoNameForm
+        SUP ( 5 )
+      )
+
+7.7.  uddiTModelStructureRule
+
+      ( 7
+        NAME 'uddiTModelStructureRule'
+        FORM uddiTModelNameForm
+      )
+
+7.8.  uddiPublisherAssertion
+
+      ( 8
+        NAME 'uddiPublisherAssertionStructureRule'
+        FORM uddiPublisherAssertionNameForm
+      )
+
+7.9.  uddiv3SubscriptionStructureRule
+
+      ( 9
+        NAME 'uddiv3SubscriptionStructureRule'
+        FORM uddiv3SubscriptionNameForm
+      )
+
+
+
+
+
+
+
+
+Bergeson, et al.             Informational                     [Page 36]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+7.10.  uddiv3EntityObituaryStructureRule
+
+      ( 10
+        NAME 'uddiv3EntityObituaryStructureRule'
+        FORM uddiv3EntityObituaryNameForm
+      )
+
+8.  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.  With UDDIv3 [UDDIv3], publishers can
+   digitally sign UDDI Entities enabling registry clients to validate
+   the integrity of entries read from the UDDIv3 registry by verifying
+   the digital signature.
+
+   Each UDDI Entity has a uddiAuthorizedName attribute that contains an
+   LDAP DN identifying the publisher/owner.  The referenced LDAP object
+   can provide the public key of the signer to a registry client for
+   integrity validation of the UDDI Entity.
+
+   Other general LDAP [LDAPv3] security considerations apply.  Some of
+   the UDDI attributes such as AccessPoints for services may contain
+   sensitive information.  Use of strong authentication mechanisms and
+   data integrity/confidentiality services [RFC2829][RFC2830] is
+   advised.
+
+9.  IANA Considerations
+
+   Refer to RFC 3383, "Internet Assigned Numbers Authority (IANA)
+   Considerations for the Lightweight Directory Access Protocol (LDAP)"
+   [RFC3383].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al.             Informational                     [Page 37]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+9.1.  Object Identifier Registration
+
+   The IANA has registered an LDAP Object Identifier for use in this
+   technical specification, according to the following template:
+
+   Subject: Request for LDAP OID Registration
+   Person & email address to contact for further information:
+      Bruce Bergeson (bruce.bergeson@novell.com)
+   Specification: RFC 4403
+   Author/Change Controller: IESG
+   Comments:
+      The assigned OID (10) will be used as a base for identifying
+      a number of UDDI schema elements defined in this document.
+
+9.2.  Object Identifier Descriptors
+
+   The IANA has registered the LDAP Descriptors used in this technical
+   specification as detailed in the following template:
+
+   Subject: Request for LDAP Descriptor Registration Update
+   Descriptor (short name): see table
+   Object Identifier: see table
+   Person & email address to contact for further information:
+      Bruce Bergeson (bruce.bergeson@novell.com)
+   Usage: see table
+   Specification: RFC 4403
+   Author/Change Controller: IESG
+   Table:
+
+   The following descriptors have been added:
+
+   NAME                            Type    OID
+   --------------                  ----    ------------
+   uddiBusinessKey                 A       1.3.6.1.1.10.4.1
+   uddiAuthorizedName              A       1.3.6.1.1.10.4.2
+   uddiOperator                    A       1.3.6.1.1.10.4.3
+   uddiName                        A       1.3.6.1.1.10.4.4
+   uddiDescription                 A       1.3.6.1.1.10.4.5
+   uddiDiscoveryURLs               A       1.3.6.1.1.10.4.6
+   uddiUseType                     A       1.3.6.1.1.10.4.7
+   uddiPersonName                  A       1.3.6.1.1.10.4.8
+   uddiPhone                       A       1.3.6.1.1.10.4.9
+   uddiEMail                       A       1.3.6.1.1.10.4.10
+   uddiSortCode                    A       1.3.6.1.1.10.4.11
+   uddiTModelKey                   A       1.3.6.1.1.10.4.12
+   uddiAddressLine                 A       1.3.6.1.1.10.4.13
+
+
+
+
+
+Bergeson, et al.             Informational                     [Page 38]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+   NAME                            Type    OID
+   --------------                  ----    ------------
+   uddiIdentifierBag               A       1.3.6.1.1.10.4.14
+   uddiCategoryBag                 A       1.3.6.1.1.10.4.15
+   uddiKeyedReference              A       1.3.6.1.1.10.4.16
+   uddiServiceKey                  A       1.3.6.1.1.10.4.17
+   uddiBindingKey                  A       1.3.6.1.1.10.4.18
+   uddiAccessPoint                 A       1.3.6.1.1.10.4.19
+   uddiHostingRedirector           A       1.3.6.1.1.10.4.20
+   uddiInstanceDescription         A       1.3.6.1.1.10.4.21
+   uddiInstanceParms               A       1.3.6.1.1.10.4.22
+   uddiOverviewDescription         A       1.3.6.1.1.10.4.23
+   uddiOverviewURL                 A       1.3.6.1.1.10.4.24
+   uddiFromKey                     A       1.3.6.1.1.10.4.25
+   uddiToKey                       A       1.3.6.1.1.10.4.26
+   uddiUUID                        A       1.3.6.1.1.10.4.27
+   uddiIsHidden                    A       1.3.6.1.1.10.4.28
+   uddiIsProjection                A       1.3.6.1.1.10.4.29
+   uddiLang                        A       1.3.6.1.1.10.4.30
+   uddiv3BusinessKey               A       1.3.6.1.1.10.4.31
+   uddiv3ServiceKey                A       1.3.6.1.1.10.4.32
+   uddiv3BindingKey                A       1.3.6.1.1.10.4.33
+   uddiv3TmodelKey                 A       1.3.6.1.1.10.4.34
+   uddiv3DigitalSignature          A       1.3.6.1.1.10.4.35
+   uddiv3NodeId                    A       1.3.6.1.1.10.4.36
+   uddiv3EntityModificationTime    A       1.3.6.1.1.10.4.37
+   uddiv3SubscriptionKey           A       1.3.6.1.1.10.4.38
+   uddiv3SubscriptionFilter        A       1.3.6.1.1.10.4.39
+   uddiv3NotificationInterval      A       1.3.6.1.1.10.4.40
+   uddiv3MaxEntities               A       1.3.6.1.1.10.4.41
+   uddiv3ExpiresAfter              A       1.3.6.1.1.10.4.42
+   uddiv3BriefResponse             A       1.3.6.1.1.10.4.43
+   uddiv3EntityKey                 A       1.3.6.1.1.10.4.44
+   uddiv3EntityCreationTime        A       1.3.6.1.1.10.4.45
+   uddiv3EntityDeletionTime        A       1.3.6.1.1.10.4.46
+   uddiBusinessEntity              O       1.3.6.1.1.10.6.1
+   uddiContact                     O       1.3.6.1.1.10.6.2
+   uddiAddress                     O       1.3.6.1.1.10.6.3
+   uddiBusinessService             O       1.3.6.1.1.10.6.4
+   uddiBindingTemplate             O       1.3.6.1.1.10.6.5
+   uddiTModelInstanceInfo          O       1.3.6.1.1.10.6.6
+   uddiTModel                      O       1.3.6.1.1.10.6.7
+   uddiPublisherAssertion          O       1.3.6.1.1.10.6.8
+   uddiv3Subscription              O       1.3.6.1.1.10.6.9
+   uddiv3EntityObituary            O       1.3.6.1.1.10.6.10
+   uddiBusinessEntityNameForm      N       1.3.6.1.1.10.15.1
+   uddiContactNameForm             N       1.3.6.1.1.10.15.2
+   uddiAddressNameForm             N       1.3.6.1.1.10.15.3
+
+
+
+Bergeson, et al.             Informational                     [Page 39]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+   NAME                            Type    OID
+   --------------                  ----    ------------
+   uddiBusinessServiceNameForm     N       1.3.6.1.1.10.15.4
+   uddiBindingTemplateNameForm     N       1.3.6.1.1.10.15.5
+   uddiTModelInstanceInfoNameForm  N       1.3.6.1.1.10.15.6
+   uddiTModelNameForm              N       1.3.6.1.1.10.15.7
+   uddiPublisherAssertionNameForm  N       1.3.6.1.1.10.15.8
+   uddiv3SubscriptionNameForm      N       1.3.6.1.1.10.15.9
+   uddiv3EntityObituaryNameForm    N       1.3.6.1.1.10.15.10
+
+   where Type A is Attribute, Type O is ObjectClass, Type N is NameForm
+
+   These assignments have been recorded in the following registry:
+
+   http://www.iana.org/assignments/ldap-parameters
+
+10.  Normative References
+
+   [LDAPv3]  Hodges, J. and R. Morgan, "Lightweight Directory Access
+             Protocol (v3): Technical Specification", RFC 3377,
+             September 2002.
+
+   [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
+             "Lightweight Directory Access Protocol (v3): Attribute
+             Syntax Definitions", RFC 2252, December 1997.
+
+   [UDDIdsr] UDDI.ORG, "UDDI version 2.03 Data Structure Reference,"
+             http://uddi.org/pubs/DataStructure-V2.03-Published-
+             20020719.htm
+
+   [UDDIapi] "UDDI Version 2.04 API Specification",
+             http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-
+             20020719.htm
+
+   [UDDIv3]  UDDI Version 3.0, Published Specification, 19 July 2002
+             http://uddi.org/pubs/uddi-v3.00-published-20020719.htm
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
+             "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+   [RFC2830] Hodges, J., Morgan, R., and M. Wahl, "Lightweight Directory
+             Access Protocol (v3): Extension for Transport Layer
+             Security", RFC 2830, May 2000.
+
+
+
+
+
+Bergeson, et al.             Informational                     [Page 40]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+   [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+             Considerations for the Lightweight Directory Access
+             Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+   [XML]     Extensible Markup Language (XML) 1.0 (Second Edition) W3C
+             Recommendation 6 October 2000 http://www.w3.org/TR/REC-xml
+
+   [URL]     Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+             Resource Identifier (URI): Generic Syntax", STD 66, RFC
+             3986, January 2005.
+
+   [HTTP]    Fielding,  R., Gettys, J., Mogul, J., Frystyk, H.,
+             Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+             Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+Authors' Addresses
+
+   Bruce Bergeson
+   Novell, Inc.
+   1800 S Novell Place
+   Provo, UT  84606
+
+   Phone: +1 801 861 3854
+   EMail: bruce.bergeson@novell.com
+
+
+   Kent Boogert
+   Novell, Inc.
+   1800 S Novell Place
+   Provo, UT  84606
+
+   Phone: +1 801 861 3212
+   EMail: kent.boogert@novell.com
+
+
+   Vijay Nanjundaswamy
+   Oracle India Pvt. Ltd.
+   Lexington Towers, Prestige St. John's Woods
+   #18, 2nd Cross Road,
+   Chikka Audugodi,
+   Bangalore 560029
+   India
+
+   Phone: +11 9180 4108 5000
+   EMail: vijay.nanjundaswamy@oracle.com
+
+
+
+
+
+
+Bergeson, et al.             Informational                     [Page 41]
+
+RFC 4403                 LDAP Schema for UDDIv3            February 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Bergeson, et al.             Informational                     [Page 42]
+