WDIFF

draft-bergeson-uddi-ldap-schema-06.txt --> rfc4403.txt

Individual Submission

Network Working Group B. Bergeson
Request for Comments: 4403 K. Boogert
Vijay K.Nanjundaswamy
Internet Draft Novell, Inc.
Document: draft-bergeson-uddi-ldap-schema-06.txt February, 2005
Intended
Category: Informational Expires August, 2005

LDAP Novell, Inc.
V. Nanjundaswamy
Oracle India Pvt. Ltd.
February 2006

Lightweight Directory Access Protocol (LDAP) Schema for UDDIv3
Universal Description, Discovery, and Integration version 3 (UDDIv3)

Status of this This Memo

This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.

Internet-Drafts are working documents of memo provides information for 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. community. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list does
not specify an Internet standard of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list any kind. Distribution of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on February 25, 2005. this
memo is unlimited.

Abstract

This document defines the Lightweight Directory Access Protocol
(LDAPv3) schema for representing Universal Description, Discovery & 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 LDAPv3-compliant directory.

Bergeson, Boogert & Nanjundaswamy Internet-Draft 1

LDAP Schema for UDDI February 2005

Discussion Forum

Technical discussion of this document will take place on the IETF
LDAP Extensions mailing list <ldapext@ietf.org>. Please send
editorial comments directly to the authors.

Table of Contents

1. Introduction.........................................................2 Introduction ....................................................2
2. Conventions used Used in this document....................................2 This Document ...............................2
3. Representation of UDDI Data Structures...............................2 Structures ..........................2
4. Attribute Type Definitions...........................................6 Definitions ......................................6
5. Object Class Definitions............................................26 Definitions .......................................28
6. Name Forms..........................................................30 Forms .....................................................32
7. DIT Structure Rules.................................................32 Rules ............................................35
8. Security Considerations.............................................34 Considerations ........................................37
9. IANA Considerations.................................................34 Considerations ............................................37
10. Normative References...............................................37
11. Author's Addresses.................................................39 References ..........................................40

Bergeson, et al. Informational [Page 1]

RFC 4403 LDAP Schema for UDDIv3 February 2006

1. Introduction

This document defines "Lightweight the Lightweight Directory Access Protocol" Protocol
[LDAPv3] schema elements to represent the core data structures
identified in "Universal Description Discovery the Universal Description, Discovery, and Integration" Integration
version 3 [UDDIv3] information model. This includes: includes a
businessEntity, a businessService, a bindingTemplate, a tModel, a
publisherAssertion
publisherAssertion, and a Subscription. Portions of [UDDIv3] are
repeated here for clarity.

2. Conventions used Used in this document 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.

Bergeson,Boogert & Nanjundaswamy Internet-Draft 2

LDAP Schema for UDDI February 2005

The individual instance data managed by a UDDI registry are 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

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

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 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

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.
e.g., when a large enterprise publishes separate businessEntity

Bergeson,Boogert & Nanjundaswamy Internet-Draft 3

LDAP Schema for UDDI February 2005
structures. This can be established by using the businessService
instance as a projection to an already published businessService.

3.2.1

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 & uddiv3BusinessKey, and
uddiv3ServiceKey, as defined in section Section 4. A businessService may
contain zero or more instances of uddiBindingTemplate.

The mandatory attribute, uddiServiceKey, contains the unique
identifier for a given instance of a businessService.

businessService's definition is given in Section 5.

3.3

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 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

3.3.1. Representation in the Directory

A bindingTemplate is represented in the directory by the attributes
uddiBindingKey, uddiServiceKey, uddiDescription, uddiAccessPoint,
uddiHostingRedirector, uddiCategoryBag uddiCategoryBag, and uddiv3DigitalSignature,
along with corresponding v3 keys viz. uddiv3ServiceKey and
uddiv3BindingKey, as defined in section 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.

Bergeson,Boogert & Nanjundaswamy Internet-Draft 4

LDAP Schema for UDDI February 2005

3.4

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's There are a
key, a name, an optional description, and a Uniform Resource Locator
[URL] that points somewhere--presumably somewhere where the curious
can go to find out more about the actual concept represented by the
metadata in the tModel itself.

3.4.1

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 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

3.5. publisherAssertion

Many businesses, like 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

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 Section 5.

Bergeson,Boogert & Nanjundaswamy Internet-Draft 5

LDAP Schema for UDDI February 2005

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

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 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. created,
Modified, modifiedIncludingChildren, nodeId 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
uddiv3EntityModificationTime, and uddiv3NodeId.

4. Attribute Type Definitions

Note that

The 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.

4.1
registered by the IANA.

4.1. uddiBusinessKey

Used

This is used in uddiBusinessEntity and uddiBusinessService.

The uddiBusinessKey is the unique identifier for a given instance of
an
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.

Bergeson,Boogert & Nanjundaswamy Internet-Draft 6

LDAP Schema for UDDI February 2005

( IANA-ASSIGNED-OID.4.1 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

4.2. uddiAuthorizedName

The uddiAuthorizedName is the recorded name of the individual that 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�
meta-data "operationalInformation"

Bergeson, et al. Informational [Page 6]

RFC 4403 LDAP Schema for UDDIv3 February 2006

metadata associated with core data structures.

( IANA-ASSIGNED-OID.4.2 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

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� meta-data.
"operationalInformation" metadata.

( IANA-ASSIGNED-OID.4.3 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

4.4. uddiName

Used

This is used in uddiBusinessEntity, uddiBusinessService uddiBusinessService, and
uddiTModel.

These are the human readable human-readable names recorded for the
uddiBusinessEntity, uddiBusinessService, or uddiTModel, adorned with
a unique xml:lang value to signify the language that they are

Bergeson,Boogert & Nanjundaswamy Internet-Draft 7

LDAP Schema for UDDI February 2005
expressed in. Name search is provided via find_business,
find_service, or find_tModel calls.

The publishing of several names, e.g. 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.

( IANA-ASSIGNED-OID.4.4 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 value, with the "#" character
used as the separator.

4.5

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.

( IANA-ASSIGNED-OID.4.5 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 value, with the "#" character
used as the separator.

4.6

4.6. uddiDiscoveryURLs

This is a list of Uniform Resource Locators (URLs) that point to
alternate, file based file-based service discovery mechanisms. Each recorded
uddiBusinessEntity structure is automatically assigned a URL that

Bergeson,Boogert & Nanjundaswamy Internet-Draft 8

LDAP Schema for UDDI February 2005
returns the individual uddiBusinessEntity structure. A URL search is
provided via find_business call.

The uddiDiscoveryURLs attribute is used to hold pointers to URL 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
convention
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.

( IANA-ASSIGNED-OID.4.6 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 value, with the "#" character used
as the separator.

4.7

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.

( IANA-ASSIGNED-OID.4.7 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

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".

( IANA-ASSIGNED-OID.4.8 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

Bergeson,Boogert & Nanjundaswamy Internet-Draft 9

LDAP Schema for UDDI February 2005
SINGLE-VALUE
)

With UDDIv3, uddiPersonName becomes multi-valued and each name can
have an xml:lang attribute. The xml:lang value precedes the name
value with the "#" character used as the separator.

4.9

Bergeson, et al. Informational [Page 9]

RFC 4403 LDAP Schema for UDDIv3 February 2006

4.9. uddiPhone

Used

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.

( IANA-ASSIGNED-OID.4.9 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. (e.g.,
"Work Number#123 456-7890")

4.10 .

4.10. uddiEMail

Used

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.

( IANA-ASSIGNED-OID.4.10 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. (e.g.,
"President of the United States #president@whitehouse.gov").

4.11

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. (e.g., 1, 2, 3),
alphabetic character ordering values (e.g. (e.g., a, b, c) c), or the first n
positions of relevant data within the address.

( IANA-ASSIGNED-OID.4.11 1.3.6.1.1.10.4.11 NAME 'uddiSortCode'
DESC 'specifies an external disply display mechanism'

Bergeson,Boogert & Nanjundaswamy Internet-Draft 10

LDAP Schema for UDDI February 2005
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

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
value set and implies that the keyName keyValue pair in an a
uddiIdentifier or uddiCategory Bag,are 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.

( IANA-ASSIGNED-OID.4.12 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

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 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.

Bergeson,Boogert & Nanjundaswamy Internet-Draft 11

LDAP Schema for UDDI February 2005

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 UDDI-compliant registry in the
order originally provided during a call to save_business.

( IANA-ASSIGNED-OID.4.13 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. "#" (e.g., "#"<keyName>"#"<keyValue>"#"<addressData>).
The addressData is the only required portion of the attribute.

4.14

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, 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 [UDDI]. [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. Identifiers [UDDIdsr].

( IANA-ASSIGNED-OID.4.14 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.
"#" (e.g., <tModel>"#"<keyName>"#"<keyValue>). The keyValue is the
only required portion of the attribute.

4.15

4.15. uddiCategoryBag

The uddiCategoryBag element allows uddiBusinessEntity,
uddiBusinessService
uddiBusinessService, and uddiTModel structures to be categorized
according to any of several available taxonomy based taxonomy-based classification
schemes. Operator Sites automatically provide validated

Bergeson,Boogert & Nanjundaswamy Internet-Draft 12

LDAP Schema for UDDI February 2005
categorization support for three taxonomies that cover industry codes
(via NAICS), product and service classifications (via UNSPC) 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 used, it greatly enhances the search behaviors exposed by
the find_xx messages defined in the UDDI Version 2.0 API
Specification.
Specification [UDDIapi]. For a full description of structures
involved in establishing categorization information, see UDDI Version 2.0
2.03 Data Structure Specification - Appendix Specification--Appendix B: Using categorization. Categorization
[UDDIdsr].

( IANA-ASSIGNED-OID.4.15 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.
"#" (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 taxonomy-based classification schemes.

4.16

4.16. uddiKeyedReference

The uddiKeyedReference is a general-purpose attribute for a name-
value pair, with an additional reference to a tModel.

( IANA-ASSIGNED-OID.4.16 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.
"#" (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
KeyedReferenceGroup to each of the keyedReference values associated
with the group.
e.g.

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:
tModelKey1#KeyName1#KeyValue1#KeyedReferenceGroup1_tModelKey
tModelKey2#KeyName2#KeyValue2#KeyedReferenceGroup1_tModelKey

Bergeson,Boogert & Nanjundaswamy Internet-Draft 13

Bergeson, et al. Informational [Page 13]

RFC 4403 LDAP Schema for UDDI UDDIv3 February 2005

4.17 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 an 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.

( IANA-ASSIGNED-OID.4.17 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

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 an a
uddiBindingKey is received via an inquiry operation, the key values
may not be blank.

( IANA-ASSIGNED-OID.4.18 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
)

4.19

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

Bergeson,Boogert & Nanjundaswamy Internet-Draft 14

LDAP Schema for UDDI February 2005
seen here is fairly abstract and many types of entry points are
accommodated. A single attribute is provided named URLType.

Required attribute qualified element8. 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.

( IANA-ASSIGNED-OID.4.19 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� UDDIv3, the "URLType" attribute is replaced by a �UseType� "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 representing 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

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
(e.g.

Bergeson, et al. Informational [Page 15]

RFC 4403 LDAP Schema for UDDIv3 February 2006

(e.g., advertise that they have it has 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

Bergeson,Boogert & Nanjundaswamy Internet-Draft 15

LDAP Schema for UDDI February 2005
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. Specification [UDDIapi].

Required element if uddiAccessPoint is not provided. 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.

( IANA-ASSIGNED-OID.4.20 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

4.21. uddiInstanceDescription

This is an optional repeating element. This is one or more language
qualified
language-qualified text descriptions that designate what role a
uddiTModel reference plays in the overall service description.

( IANA-ASSIGNED-OID.4.21 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 value, with the "#" character
used as the separator.

4.22

Bergeson, et al. Informational [Page 16]

RFC 4403 LDAP Schema for UDDIv3 February 2006

4.22. uddiInstanceParms

The uddiInstance Parms uddiInstanceParms is an Optional optional element of the uddiInstance.
Used 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

Bergeson,Boogert & Nanjundaswamy Internet-Draft 16

LDAP Schema for UDDI February 2005
parameters themselves, the suggested content is a namespace
qualified 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.

( IANA-ASSIGNED-OID.4.22 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

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.

( IANA-ASSIGNED-OID.4.23 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 value, with the "#" character
used as the separator.

4.24

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 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 HTTP-GET operation, for example,
via a Web browser.

( IANA-ASSIGNED-OID.4.24 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, multi-valued to allow
representing the
representation of multiple OverviewDocs within a single
InstanceDetail element.

Modeling multiple OverviewDocs within an InstanceDetail element:

Bergeson,Boogert & Nanjundaswamy Internet-Draft 17

LDAP Schema for UDDI February 2005

In UDDIv3, the InstanceDetails element in TmodelInstanceInfo can have
multiple OverviewDoc�s. 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
valued, and have a �group ID� "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.

4.25

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 for.
made.

( IANA-ASSIGNED-OID.4.25 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

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
for.
made.

( IANA-ASSIGNED-OID.4.26 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

4.27. uddiUUID

Bergeson,Boogert & Nanjundaswamy Internet-Draft 18

LDAP Schema for UDDI February 2005

The uddiUUID is a required element. This is to insure ensure unique
identification of uddiContact, uddiAddress, and
uddiPublisherAssertion objects.

( IANA-ASSIGNED-OID.4.27 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 Subscription-feature-related entities.

4.28

Bergeson, et al. Informational [Page 19]

RFC 4403 LDAP Schema for UDDIv3 February 2006

4.28. uddiIsHidden

Used

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.

( IANA-ASSIGNED-OID.4.28 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� "deleted"
attribute value.

4.29

4.29. uddiIsProjection

Used

This is used to identify a Business Service that as has a Service
Projection.

( IANA-ASSIGNED-OID.4.29 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

4.30. uddiLang

Used

This is used to model the xml:lang value for the Address structure in
UDDIv3.

( IANA-ASSIGNED-OID.4.30 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

Bergeson,Boogert & Nanjundaswamy Internet-Draft 19

LDAP Schema for UDDI February 2005
SINGLE-VALUE
)

The following are attribute definitions to model new elements/fields
in UDDIv3 information model. These attribute definitions have the
�uddiv3�
"uddiv3" prefix to indicate that these attributes represent UDDI
information model elements unique to UDDIv3.

4.31

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. Used 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.

( IANA-ASSIGNED-OID.4.31 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

4.32. uddiv3ServiceKey

This is the unique UDDIv3 identifier for a given instance of
uddiBusinessService. Used 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)
(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.

( IANA-ASSIGNED-OID.4.32 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

4.33. uddiv3BindingKey

Bergeson,Boogert & Nanjundaswamy Internet-Draft 20

LDAP Schema for UDDI February 2005

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)
(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.

( IANA-ASSIGNED-OID.4.33 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

4.34. uddiv3TModelKey

This is the unique UDDIv3 identifier for a given instance of an 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.

( IANA-ASSIGNED-OID.4.34 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. At In all places, 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 and this Server, which
may invalidate the digital signature of the entity.

4.35

4.35. uddiv3DigitalSignature

The UDDIv3 v3 schema supports the signing of the following UDDI
elements using �XML-Signature "XML-Signature Syntax and Processing� Processing" (see
http://www.w3.org/TR/xmldsig-core/).

..businessEntity
..businessService
..bindingTemplate

Bergeson,Boogert & Nanjundaswamy Internet-Draft 21
..tModel
..publisherAssertion

Bergeson, et al. Informational [Page 22]

RFC 4403 LDAP Schema for UDDI UDDIv3 February 2005

..tModel
..publisherAssertion 2006

This uddiv3DigitalSignature attribute holds the digital signature for
the corresponding UDDI entity.

( IANA-ASSIGNED-OID.4.35 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 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
XMLSignature 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 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 XML-Signature tool is specified in a Transform
element inside the Signature element.

4.36

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.

( IANA-ASSIGNED-OID.4.36 1.3.6.1.1.10.4.36 NAME 'uddiv3NodeId'
DESC 'UDDIv3 Node Identifier'
EQUALITY caseIgnoreMatch

Bergeson,Boogert & Nanjundaswamy Internet-Draft 22

LDAP Schema for UDDI February 2005
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)

4.37

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. (e.g.,
uddiBindingTemplate) is updated, the parent entity (e.g. (e.g.,
uddiBusinessService) LDAP timestamp also gets updated. The
uddiv3EntityModificationTime attribute saves the last modification
time of the parent entity (uddiBusinessService in this case).

( IANA-ASSIGNED-OID.4.37 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 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.

4.38 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.

( IANA-ASSIGNED-OID.4.38 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

4.39. uddiv3SubscriptionFilter

This attribute contains the UDDIv3 Subscription Filter, specified as
part of the save_subscription API i.e. 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

Bergeson,Boogert & Nanjundaswamy Internet-Draft 23

LDAP Schema for UDDI February 2005
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.

( IANA-ASSIGNED-OID.4.39 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

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.

( IANA-ASSIGNED-OID.4.40 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
)

4.41

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.

( IANA-ASSIGNED-OID.4.41 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

4.42. uddiv3ExpiresAfter

This attribute specifies the Expiry Time associated with a
Subscription.
subscription. It is of the XML Schema type xsd:dateTime.

( IANA-ASSIGNED-OID.4.42 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
)

Bergeson,Boogert & Nanjundaswamy Internet-Draft 24

LDAP Schema for UDDI February 2005

4.43

4.43. uddiv3BriefResponse

This attribute is a Boolean flag for Brief Response associated with a Subscription
subscription entity. It controls the level of detail returned to a
subscription listener. The default is "false" when omitted. When
set to "true," "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.

( IANA-ASSIGNED-OID.4.43 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
)

4.44

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 entry
uddiv3EntityObituary. When a core UDDIv3 entity Entity is deleted and there
is an active subscription registered against this UDDI entity, Entity, an
Obituary entry is created, in which the v3 key of the deleted entry
is logged as part of the uddiv3EntityKey attribute.

( IANA-ASSIGNED-OID.4.44 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

4.45. uddiv3EntityCreationTime

This attribute is used to log the original Creation Time for a UDDI
Entity that is deleted, 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.

( IANA-ASSIGNED-OID.4.45 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
)

Bergeson,Boogert & Nanjundaswamy Internet-Draft 25

LDAP Schema for UDDI February 2005

4.46

4.46. uddiv3EntityDeletionTime

This attribute is used to log the entity deletion time for a UDDI
Entity that is deleted, deleted in the uddiv3EntityObituary entry.

( IANA-ASSIGNED-OID.4.46 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

Note that

The 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.

5.1 registered
by the IANA.

5.1. uddiBusinessEntity

This structural object class represents a businessEntity.

( IANA-ASSIGNED-OID.6.1 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

5.2. uddiContact

This structural object class represents a contact. It is contained
by an a uddiBusinessEntity.

( IANA-ASSIGNED-OID.6.2 1.3.6.1.1.10.6.2 NAME 'uddiContact'
SUP top
STRUCTURAL
MUST ( uddiPersonName $
uddiUUID )

Bergeson,Boogert & Nanjundaswamy Internet-Draft 26

LDAP Schema for UDDI February 2005
MAY ( uddiUseType $
uddiDescription $
uddiPhone $
uddiEMail )
)

5.3

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 an a uddiContact.

( IANA-ASSIGNED-OID.6.3 1.3.6.1.1.10.6.3 NAME 'uddiAddress'
SUP top
STRUCTURAL
MUST ( uddiUUID )
MAY ( uddiUseType $
uddiSortCode $
uddiTModelKey $
uddiv3TmodelKey $
uddiAddressLine $
uddiLang)
)

5.4

5.4. uddiBusinessService

This structural object class represents a businessService.

( IANA-ASSIGNED-OID.6.4 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)
)

5.5

Bergeson, et al. Informational [Page 29]

RFC 4403 LDAP Schema for UDDIv3 February 2006

5.5. uddiBindingTemplate

This structural object class represents a bindingTemplate.

( IANA-ASSIGNED-OID.6.5 1.3.6.1.1.10.6.5 NAME 'uddiBindingTemplate'
SUP top

Bergeson,Boogert & Nanjundaswamy Internet-Draft 27

LDAP Schema for UDDI February 2005
STRUCTURAL
MUST ( uddiBindingKey )
MAY ( uddiServiceKey $
uddiDescription $
uddiAccessPoint $
uddiHostingRedirector
uddiCategoryBag $
uddiv3BindingKey $
uddiv3ServiceKey $
uddiv3DigitalSignature $
uddiv3EntityCreationTime $
uddiv3NodeId)
)

5.6

5.6. uddiTModelInstanceInfo

This structural object class represents a tModelInstanceInfo. It is
contained by an a uddiBindingTemplate.

( IANA-ASSIGNED-OID.6.6 1.3.6.1.1.10.6.6 NAME 'uddiTModelInstanceInfo'
SUP top
STRUCTURAL
MUST ( uddiTModelKey )
MAY ( uddiDescription $
uddiInstanceDescription $
uddiInstanceParms $
uddiOverviewDescription $
uddiOverviewURL $
uddiv3TmodelKey)
)

5.7

Bergeson, et al. Informational [Page 30]

RFC 4403 LDAP Schema for UDDIv3 February 2006

5.7. uddiTModel

This structural object class represents a tModel.

( IANA-ASSIGNED-OID.6.7 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 $

Bergeson,Boogert & Nanjundaswamy Internet-Draft 28

LDAP Schema for UDDI February 2005
uddiv3DigitalSignature $
uddiv3NodeId)
)

5.8

5.8. uddiPublisherAssertion

This structural object class represents a publisherAssertion.

( IANA-ASSIGNED-OID.6.8 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� "uddiv3" prefix to indicate that
these attributes represent UDDI information model elements unique to
UDDIv3.

5.9

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.

( IANA-ASSIGNED-OID.6.9 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

5.10. uddiv3EntityObituary

This structural object class represents an Obituary entry for and
stores obituary information for deleted UDDIv3 entities needed for
handling Subscriptions.

Bergeson,Boogert & Nanjundaswamy Internet-Draft 29

LDAP Schema for UDDI February 2005 subscriptions.

( IANA-ASSIGNED-OID.6.10 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 Section 6.

Note that

The 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.

6.1
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.

( IANA-ASSIGNED-OID.15.1 1.3.6.1.1.10.15.1 NAME 'uddiBusinessEntityNameForm'
OC uddiBusinessEntity
MUST ( uddiBusinessKey )
)

6.2

6.2. uddiContactNameForm

This name form defines the naming attribute for a contact.

( IANA-ASSIGNED-OID.15.2 1.3.6.1.1.10.15.2 NAME 'uddiContactNameForm'
OC uddiContact
MUST ( uddiUUID )
)

6.3

6.3. uddiAddressNameForm

This name form defines the naming attribute for an address.

( IANA-ASSIGNED-OID.15.3 1.3.6.1.1.10.15.3 NAME 'uddiAddressNameForm'
OC uddiAddress
MUST ( uddiUUID )
)

6.4

6.4. uddiBusinessServiceNameForm

Bergeson,Boogert & Nanjundaswamy Internet-Draft 30

LDAP Schema for UDDI February 2005

This name form defines the naming attribute for a businessService.

( IANA-ASSIGNED-OID.15.4 1.3.6.1.1.10.15.4 NAME 'uddiBusinessServiceNameForm'
OC uddiBusinessService
MUST ( uddiServiceKey )
)

6.5

6.5. uddiBindingTemplateNameForm

This name form defines the naming attribute for a bindingTemplate.

( IANA-ASSIGNED-OID.15.5 1.3.6.1.1.10.15.5 NAME 'uddiBindingTemplateNameForm'
OC uddiBindingTemplate
MUST ( uddiBindingKey )
)

6.6

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.

( IANA-ASSIGNED-OID.15.6 1.3.6.1.1.10.15.6 NAME 'uddiTModelInstanceInfoNameForm'
OC uddiTModelInstanceInfo
MUST ( uddiTModelKey )
)

6.7

6.7. uddiTModelNameForm

This name form defines the naming attribute for a tModel.

( IANA-ASSIGNED-OID.15.7 1.3.6.1.1.10.15.7 NAME 'uddiTModelNameForm'
OC uddiTModel
MUST ( uddiTModelKey )
)

6.8

6.8. uddiPublisherAssertionNameForm

This name form defines the naming attribute for a publisherAssertion.

( IANA-ASSIGNED-OID.15.8 1.3.6.1.1.10.15.8 NAME 'uddiPublisherAssertionNameForm'
OC uddiPublisherAssertion
MUST ( uddiUUID )
)

6.9

6.9. uddiv3SubscriptionNameForm

This name form defines the naming attribute for a Subscription.

( IANA-ASSIGNED-OID.15.9 1.3.6.1.1.10.15.9 NAME 'uddiv3SubscriptionNameForm'

Bergeson,Boogert & Nanjundaswamy Internet-Draft 31

LDAP Schema for UDDI February 2005
OC uddiv3Subscription
MUST ( uddiUUID )
)

6.10

6.10. uddiv3EntityObituaryNameForm

This name form defines the naming attribute for an Entity Obituary.

( IANA-ASSIGNED-OID.15.10 1.3.6.1.1.10.15.10 NAME 'uddiv3EntityObituary' '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 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

7.1. uddiBusinessEntityStructureRule

( 1
NAME 'uddiBusinessEntityStructureRule'
FORM uddiBusinessEntityNameForm
)

7.2

7.2. uddiContactStructureRule

This structure rule defines the object class containment for a
contact.

( 2
NAME 'uddiContactStructureRule'
FORM uddiContactNameForm
SUP ( 1 )
)

7.3

7.3. uddiAddressStructureRule

This structure rule defines the object class containment for a an
address.

( 3
NAME 'uddiAddressStructureRule'
FORM uddiAddressNameForm
SUP ( 2 )

Bergeson,Boogert & Nanjundaswamy Internet-Draft 32

LDAP Schema for UDDI February 2005
)

7.4

7.4. uddiBusinessServiceStructureRule

This structure rule defines the object class containment for a
businessService.

( 4
NAME 'uddiBusinessServiceStructureRule'
FORM uddiBusinessServiceNameForm
SUP ( 1 )
)

7.5

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

7.6. uddiTModelInstanceInfoStructureRule

This structure rule defines the object class containment for a
tModelInstanceInfo.

( 6
NAME 'uddiTModelInstanceInfoStructureRule'
FORM uddiTModelInstanceInfoNameForm
SUP ( 5 )
)

7.7

7.7. uddiTModelStructureRule

( 7
NAME 'uddiTModelStructureRule'
FORM uddiTModelNameForm
)

7.8

7.8. uddiPublisherAssertion

( 8
NAME 'uddiPublisherAssertionStructureRule'
FORM uddiPublisherAssertionNameForm
)

7.9

7.9. uddiv3SubscriptionStructureRule

Bergeson,Boogert & Nanjundaswamy Internet-Draft 33

LDAP Schema for UDDI February 2005

( 9
NAME 'uddiv3SubscriptionStructureRule'
FORM uddiv3SubscriptionNameForm
)

7.10

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 an a uddiAuthorizedName attribute which 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 like 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

It is requested that the

The IANA register upon Informational Action has registered an LDAP Object Identifier for use in this
technical specification specification, according to the following template:

Subject: Request for LDAP OID Registration

Bergeson,Boogert & Nanjundaswamy Internet-Draft 34

LDAP Schema for UDDI February 2005
Person & email address to contact for further information:
Bruce Bergeson (bruce.bergeson@novell.com)
Specification: RFC XXXX 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

It is requested that the

The IANA register upon Informational Action 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 XXXX 4403
Author/Change Controller: IESG
Table:

The following descriptors have been added:

NAME Type OID
-------------- ---- ------------
uddiBusinessKey A IANA-ASSIGNED-OID.4.1 1.3.6.1.1.10.4.1
uddiAuthorizedName A IANA-ASSIGNED-OID.4.2 1.3.6.1.1.10.4.2
uddiOperator A IANA-ASSIGNED-OID.4.3 1.3.6.1.1.10.4.3
uddiName A IANA-ASSIGNED-OID.4.4 1.3.6.1.1.10.4.4
uddiDescription A IANA-ASSIGNED-OID.4.5 1.3.6.1.1.10.4.5
uddiDiscoveryURLs A IANA-ASSIGNED-OID.4.6 1.3.6.1.1.10.4.6
uddiUseType A IANA-ASSIGNED-OID.4.7 1.3.6.1.1.10.4.7
uddiPersonName A IANA-ASSIGNED-OID.4.8 1.3.6.1.1.10.4.8
uddiPhone A IANA-ASSIGNED-OID.4.9 1.3.6.1.1.10.4.9
uddiEMail A IANA-ASSIGNED-OID.4.10 1.3.6.1.1.10.4.10
uddiSortCode A IANA-ASSIGNED-OID.4.11 1.3.6.1.1.10.4.11
uddiTModelKey A IANA-ASSIGNED-OID.4.12 1.3.6.1.1.10.4.12
uddiAddressLine A IANA-ASSIGNED-OID.4.13 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 IANA-ASSIGNED-OID.4.14 1.3.6.1.1.10.4.14
uddiCategoryBag A IANA-ASSIGNED-OID.4.15 1.3.6.1.1.10.4.15
uddiKeyedReference A IANA-ASSIGNED-OID.4.16 1.3.6.1.1.10.4.16
uddiServiceKey A IANA-ASSIGNED-OID.4.17 1.3.6.1.1.10.4.17
uddiBindingKey A IANA-ASSIGNED-OID.4.18 1.3.6.1.1.10.4.18
uddiAccessPoint A IANA-ASSIGNED-OID.4.19 1.3.6.1.1.10.4.19
uddiHostingRedirector A IANA-ASSIGNED-OID.4.20 1.3.6.1.1.10.4.20
uddiInstanceDescription A IANA-ASSIGNED-OID.4.21

Bergeson,Boogert & Nanjundaswamy Internet-Draft 35

LDAP Schema for UDDI February 2005

NAME Type OID
-------------- ---- ------------ 1.3.6.1.1.10.4.21
uddiInstanceParms A IANA-ASSIGNED-OID.4.22 1.3.6.1.1.10.4.22
uddiOverviewDescription A IANA-ASSIGNED-OID.4.23 1.3.6.1.1.10.4.23
uddiOverviewURL A IANA-ASSIGNED-OID.4.24 1.3.6.1.1.10.4.24
uddiFromKey A IANA-ASSIGNED-OID.4.25 1.3.6.1.1.10.4.25
uddiToKey A IANA-ASSIGNED-OID.4.26 1.3.6.1.1.10.4.26
uddiUUID A IANA-ASSIGNED-OID.4.27 1.3.6.1.1.10.4.27
uddiIsHidden A IANA-ASSIGNED-OID.4.28 1.3.6.1.1.10.4.28
uddiIsProjection A IANA-ASSIGNED-OID.4.29 1.3.6.1.1.10.4.29
uddiLang A IANA-ASSIGNED-OID.4.30 1.3.6.1.1.10.4.30
uddiv3BusinessKey A IANA-ASSIGNED-OID.4.31 1.3.6.1.1.10.4.31
uddiv3ServiceKey A IANA-ASSIGNED-OID.4.32 1.3.6.1.1.10.4.32
uddiv3BindingKey A IANA-ASSIGNED-OID.4.33 1.3.6.1.1.10.4.33
uddiv3TmodelKey A IANA-ASSIGNED-OID.4.34 1.3.6.1.1.10.4.34
uddiv3DigitalSignature A IANA-ASSIGNED-OID.4.35 1.3.6.1.1.10.4.35
uddiv3NodeId A IANA-ASSIGNED-OID.4.36 1.3.6.1.1.10.4.36
uddiv3EntityModificationTime A IANA-ASSIGNED-OID.4.37 1.3.6.1.1.10.4.37
uddiv3SubscriptionKey A IANA-ASSIGNED-OID.4.38 1.3.6.1.1.10.4.38
uddiv3SubscriptionFilter A IANA-ASSIGNED-OID.4.39 1.3.6.1.1.10.4.39
uddiv3NotificationInterval A IANA-ASSIGNED-OID.4.40 1.3.6.1.1.10.4.40
uddiv3MaxEntities A IANA-ASSIGNED-OID.4.41 1.3.6.1.1.10.4.41
uddiv3ExpiresAfter A IANA-ASSIGNED-OID.4.42 1.3.6.1.1.10.4.42
uddiv3BriefResponse A IANA-ASSIGNED-OID.4.43 1.3.6.1.1.10.4.43
uddiv3EntityKey A IANA-ASSIGNED-OID.4.44 1.3.6.1.1.10.4.44
uddiv3EntityCreationTime A IANA-ASSIGNED-OID.4.45 1.3.6.1.1.10.4.45
uddiv3EntityDeletionTime A IANA-ASSIGNED-OID.4.46 1.3.6.1.1.10.4.46
uddiBusinessEntity O IANA-ASSIGNED-OID.6.1 1.3.6.1.1.10.6.1
uddiContact O IANA-ASSIGNED-OID.6.2 1.3.6.1.1.10.6.2
uddiAddress O IANA-ASSIGNED-OID.6.3 1.3.6.1.1.10.6.3
uddiBusinessService O IANA-ASSIGNED-OID.6.4 1.3.6.1.1.10.6.4
uddiBindingTemplate O IANA-ASSIGNED-OID.6.5 1.3.6.1.1.10.6.5
uddiTModelInstanceInfo O IANA-ASSIGNED-OID.6.6 1.3.6.1.1.10.6.6
uddiTModel O IANA-ASSIGNED-OID.6.7 1.3.6.1.1.10.6.7
uddiPublisherAssertion O IANA-ASSIGNED-OID.6.8 1.3.6.1.1.10.6.8
uddiv3Subscription O IANA-ASSIGNED-OID.6.9 1.3.6.1.1.10.6.9
uddiv3EntityObituary O IANA-ASSIGNED-OID.6.10 1.3.6.1.1.10.6.10
uddiBusinessEntityNameForm N IANA-ASSIGNED-OID.15.1 1.3.6.1.1.10.15.1
uddiContactNameForm N IANA-ASSIGNED-OID.15.2 1.3.6.1.1.10.15.2
uddiAddressNameForm N IANA-ASSIGNED-OID.15.3 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 IANA-ASSIGNED-OID.15.4 1.3.6.1.1.10.15.4
uddiBindingTemplateNameForm N IANA-ASSIGNED-OID.15.5 1.3.6.1.1.10.15.5
uddiTModelInstanceInfoNameForm N IANA-ASSIGNED-OID.15.6 1.3.6.1.1.10.15.6
uddiTModelNameForm N IANA-ASSIGNED-OID.15.7 1.3.6.1.1.10.15.7
uddiPublisherAssertionNameForm N IANA-ASSIGNED-OID.15.8 1.3.6.1.1.10.15.8
uddiv3SubscriptionNameForm N IANA-ASSIGNED-OID.15.9

Bergeson,Boogert & Nanjundaswamy Internet-Draft 36

LDAP Schema for UDDI February 2005 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

Upon Informational Action these

These assignments will be have been recorded in the following registry:

http://www.iana.org/assignments/ldap-parameters

Bergeson,Boogert & Nanjundaswamy Internet-Draft 37

LDAP Schema for UDDI February 2005

10. Normative References

[LDAPv3] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3):Technical (v3): Technical Specification", Internet
Standard, September 2002, Available as RFC 3377

[RFC2251] Wahl, M., Kille, S. and T. Howes, "Lightweight
Directory Access Protocol (v3)", Internet Standard,
December, 1997. 3377,
September 2002.

[RFC2252] Wahl, M., Coulbeck, A., Kille, S. and T. Howes, T., and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", Internet Standard, December, RFC 2252, December 1997.

[UDDI]

[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] S. Bradner, S., "Key Words words for use in RFCs to Indicate
Requirement Levels," Internet Standard, December, Levels", BCP 14, RFC 2119, March 1997.
Available as RFC2253

[RFC2829] Wahl, M., Alvestrand, H., Hodges, J. J., and R. Morgan,
"Authentication Methods for LDAP," Internet Standard, LDAP", RFC 2829, May 2000.

[RFC2830] Hodges, J., Morgan, R. R., and M. Wahl, "Lightweight Directory
Access Protocol (v3): Extension for Transport Layer Security," Internet Standard,
Security", RFC 2830, May 2000 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

[uuid] Paul J. Leach, Rich Salz, "UUIDs and GUIDs", Internet
Draft, February 1998 2002.

[XML] Extensible Markup Language (XML) 1.0 (Second Edition) W3C
Recommendation 6 October 2000 http://www.w3.org/TR/REC-xml

[URL] Uniform Resource Locators as defined in

Bergeson,Boogert & Nanjundaswamy Internet-Draft 38

LDAP Schema for UDDI February 2005

T. Berners-Lee et al., Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers Identifier (URI): Generic Syntax", Internet Standard, August 1998.
Available as STD 66, RFC 2396.
http://www.ietf.org/rfc/rfc2396.txt
3986, January 2005.

[HTTP] R. Fielding et al.,"Hypertext Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", Internet Standard, RFC 2616, June 1999.
http://www.w3.org/Protocols/rfc2616/rfc2616.txt

Bergeson,Boogert & Nanjundaswamy Internet-Draft 39

LDAP Schema for UDDI February 2005

11. Author's

Authors' Addresses

Bruce Bergeson
Novell, Inc.
Mail Stop PRV-H411
1800 S Novell Place
Provo, UT 84606

Phone: +1 801 861 3854
Email:
EMail: bruce.bergeson@novell.com

Kent Boogert
Novell, Inc.
1800 S Novell Place
Provo, UT 84606

Phone: +1 801 861 3212
Email:
EMail: kent.boogert@novell.com

Vijay Nanjundaswamy
Novell Software Development (I) Pvt
Oracle India Pvt. Ltd.
7th Mile, Hosur
Lexington Towers, Prestige St. John's Woods
#18, 2nd Cross Road,
Chikka Audugodi,
Bangalore 560068 560029
India

Phone: +11 9180 573 1858
Email: knvijay@novell.com

Bergeson,Boogert & Nanjundaswamy Internet-Draft 40 4108 5000
EMail: vijay.nanjundaswamy@oracle.com

Bergeson, et al. Informational [Page 41]

RFC 4403 LDAP Schema for UDDI September 2004 UDDIv3 February 2006

Full Copyright Statement

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 Rights

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.

Disclaimer of Validity

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.

Copyright (C) The Internet Society (2004). 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.

Acknowledgment
ietf-ipr@ietf.org.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

Bergeson,Boogert & Nanjundaswamy Internet-Draft 41 IETF
Administrative Support Activity (IASA).

Bergeson, et al. Informational [Page 42]

----