view Side-By-Side changes
Individual Submission B.Bergeson,Bergeson K. Boogert Internet Draft Novell, Inc. Document:draft-bergeson-uddi-ldap-schema-00.txt February,draft-bergeson-uddi-ldap-schema-01.txt May, 2002 Category: InformationalLdapExpires Nov, 2002 LDAP Schema for UDDI 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 ofRFC2026 [1].RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Editorial comments may be sent to bruce.bergeson@novell.com. General discussion may be directed to the LDAPEXT WG List. 2. Abstract This document defines the schema for representing Universal Description Discovery & Integration (referred to here as UDDI) data types [UDDI] in an LDAP directory [LDAPV3]. It defines schema elements to represent a businessEntity, a businessService, a bindingTemplate, a tModel, and a publisherAssertion. 3. Conventions used in this document The imperatives from [RFC2119] used in this document are to be interpreted as described there. 4. Representation of UDDI Data Structures This document defines schema elements to represent the five UDDI data structure types: a businessEntity, a businessService, a bindingTemplate, a tModel, and a publisherAssertion. Portions of [UDDI] are repeated here for clarity. Bergeson and Boogert Internet-Draft 1 LDAP Schema for UDDI May 2002 The information that makes up a registration in UDDI consists of these five data structure types. This division by information type provides simple partitions to assist in the rapid location andBergeson and Boogert Internet-Draft 1 LDAP Schema for UDDI Feb 2002understanding of the different information that makes up a registration. The individual instance data managed by a UDDI registry are sensitive to the parent/child relationships found in the schema. A businessEntity object contains one or more unique businessService objects. Similarly, individual businessService objects contain specific instances of bindingTemplate, which in turn contains information that includes pointers to specific instances of tModel objects. It is important to note that no single instance of a core schema type is everææcontainedÆÆ"contained" by more than one parent instance. This means that only one specific businessEntity object (identified by its unique key value) will ever contain or be used to express information about a specific instance of a businessService object (also identified by its own unique key value). 4.1 businessEntity The businessEntity object represents all known information about a business or entity that publishes descriptive information about the entity as well as the services that it offers. The businessEntity is the top-level container that accommodates holding descriptive information about a business or entity. Service descriptions and technical information are expressed within a businessEntity by a containment relationship. 4.1.1 Representation in the Directory A businessEntity is represented in the directory by the attributes uddiBusinessKey, uddiAuthorizedName, uddiOperator, uddiDiscoveryURLs, uddiName, uddiDescription, uddiIdentifierBag, and uddiCategoryBag, as defined in section 5. A businessEntity may contain zero or more instances of uddiContact and uddiBusinessService. The mandatory attribute, uddiBusinessKey, contains the unique identifier for a given instance of a businessEntity.businessEntityÆsbusinessEntity's definition is given in Section 6. 4.2 businessService The businessService instances each represent a logical service classification. Each businessService object is the logical child of a single businessEntity object. Each businessService element contains descriptive information in business terms outlining the type of technical services found within each businessService instance. Bergeson & Boogert Internet-Draft 2 LDAP Schema for UDDI May 2002 In some cases, businesses would like to share or reuse services, e.g. when a large enterprise publishes separate businessEntityBergeson & Boogert Internet-Draft 2 LDAP Schema for UDDI Feb 2002structures. This can be established by using the businessService instance as a projection to an already published businessService. 4.2.1 Representation in the Directory A businessService is represented in the directory by the attributes uddiBusinessKey, uddiServiceKey, uddiName, uddiDescription, and uddiCategoryBag, as defined in section 5. A businessService may contain zero or more instances of uddiBindingTemplate. The mandatory attribute, uddiServiceKey, contains the unique identifier for a given instance of a businessService.businessServiceÆsbusinessService's definition is given in Section 6. 4.3 bindingTemplate Technical descriptions of Web services are accommodated via individual contained instances of bindingTemplate objects. These instances provide support for determining a technical entry point or optionally support remotely hosted services, as well as a lightweight facility for describing unique technical characteristics of a given implementation. Support for technology and application specific parameters and settings files are also supported. SinceUDDIÆsUDDI's main purpose is to enable description and discovery of Web Service information, it is the bindingTemplate that provides the most interesting technical data. Each bindingTemplate instance has a single logical businessService parent, which in turn has a single logical businessEntity parent. 4.3.1 Representation in the Directory A bindingTemplate is represented in the directory by the attributes uddiBindingKey, uddiServcieKey, uddiDesctiption, uddiAccessPoint, and uddiHostingRedirector, as defined in section 5. A bindingTemplate may contain zero or more instances of uddiTModelInstanceDetails. The mandatory attribute, uddiBindingKey, contains the unique identifier for a given instance of a bindingTemplate.BindingTemplateÆsBindingTemplate's definition is given in Section 6. 4.4 tModel The tModel object takes the form of keyed metadata (data about data). In a general sense, the purpose of a tModel within the UDDI registry is to provide a reference system based on abstraction. Thus, the kind of data that a tModel represents is pretty nebulous. In other words, a tModel registration can define just about anything, but in the current revision, two conventions have been Bergeson & Boogert Internet-Draft 3 LDAP Schema for UDDI May 2002 applied for using tModels: as sources for determining compatibility and as keyed namespace references.Bergeson & Boogert Internet-Draft 3 LDAP Schema for UDDI Feb 2002The information that makes up a tModel is quite simple.ThereÆsThere's a key, a name, an optional description, and then a URL that pointssomewhere-- - -presumablysomewhere--presumably somewhere where the curious can go to find out more about the actual concept represented by the metadata in the tModel itself. 4.4.1 Representation in the Directory A tModel is represented in the directory by the attributes uddiTModelKey, uddiAuthorizedName, uddiOperator, uddiName, uddiDescription, uddiOverviewDescription, uddiOverviewURL, uddiIdentifeierBag, and uddiCategoryBag, as defined in section 5. A tModel may also contain a uddiHidden to logically delete a tModel. The mandatory attribute, uddiTModelKey, contains the unique identifier for a given instance of a tModel.tModelÆstModel's definition is given in Section 6. 4.5 publisherAssertion Many businesses, like large enterprises or marketplaces, are not effectively represented by a single businessEntity, since their description and discovery are likely to be diverse. As a consequence, several businessEntity instances can be published, representing individual subsidiaries of a large enterprise or individual participants of a marketplace. Nevertheless, they still represent a more or less coupled community and would like to make some of their relationships visible in their UDDI registrations. 4.5.1 Representation in the Directory A publisherAssertion is represented in the directory by the attributes uddiFromKey, uddiToKey, uddiKeyedReference, and uddiUUID, as defined in section 5. The mandatory attribute, uddiUUID, contains the unique identifier for a given instance of a publisherAssertion.publisherAssertionÆspublisherAssertion's definition is given in Section 6. 5. Attribute Type Definitions The following attribute types are defined in this document: uddiBusinessKey uddiAuthorizedName uddiOperator uddiName uddiDescription uddiDiscoveryURLs uddiUseTypeuddiPersonName uddiPhoneBergeson & Boogert Internet-Draft 4 LDAP Schema for UDDIFebMay 2002 uddiPersonName uddiPhone uddiEMail uddiSortCode uddiTModelKey uddiAddressLineuddiKeyName uddiKeyValueuddiIdentifierBag uddiCategoryBag uddiKeyedReference uddiServiceKey uddiBindingKey uddiAccessPointuddiURLTypeuddiHostingRedirector uddiInstanceDescription uddiInstanceParms uddiOverviewDescription uddiOverviewURL uddiFromKey uddiToKey uddiUUID uddiIsHidden Note that OIDs for the attribute types in this document have not been assigned. All OIDs are in brackets, <OID-TBD>, as a placeholder until real OIDs are assigned. 5.1 uddiBusinessKey Used in uddiBusinessEntity and uddiBusinessService. The uddiBusinessKey is the unique identifier for a given instance of an uddiBusinessEntity. However the attribute is optional for businessService instances contained within a fully expressed parent that already contains a businessKey value. If the businessService instance is rendered into XML and has no containing parent that has within its data a businessKey, the value of the businessKey that is the parent of the businessService is required to be provided. This behavior supports the ability to browse through the parent-child relationships given any of the core elements as a starting point. The businessKey may differ from the publishingbusinessEntityÆsbusinessEntity's businessKey to allow service projections. (2.16.840.1.113719.1.302.4.1.1<OID-TBD> NAME 'uddiBusinessKey' DESC 'businessEntity unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) 5.2 uddiAuthorizedName Bergeson & Boogert Internet-Draft 5 LDAP Schema for UDDI May 2002 The uddiAuthorizedName is the recorded name of the individual that published the uddiBusinessEntity data. This data is generated byBergeson & Boogert Internet-Draft 5 LDAP Schema for UDDI Feb 2002the controlling operator and should not be supplied within save_business operations. (2.16.840.1.113719.1.302.4.2.1<OID-TBD> NAME 'uddiAuthorizedName' DESC 'businessEntity publisher name' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) 5.3 uddiOperator The uddiOperator is the certified name of the UDDI registry site operator that manages the master copy of the uddiBusinessEntity. The controlling operator records this data at the time data is saved. This data is generated and should not be supplied within save_business operations. (2.16.840.1.113719.1.302.4.3.1<OID-TBD> NAME 'uddiOperator' DESC 'registry site operator of businessEntitys master copy' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) 5.4 uddiName Used in uddiBusinessEntity and uddiBusinessService. These are the human readable names recorded for the uddiBusinessEntity or uddiBusinessService, adorned with a unique xml:lang value to signify the language that they are expressed in. Name search is provided via find_business or find_service calls. Names may not be blank. The publishing of several names, e.g. for romanization purposes, is supported. In order to signify the language that the names are expressed in, they carry unique xml:lang values. Not more than one name element may omit specifying its language. Names passed in this way will be assigned the default language code of the registering party. This default language code is established at the time that publishing credentials are established with an individual Operator Site. If no default language is provisioned at the time a publisher signs up, the operator can adopt an appropriate default language code. (2.16.840.1.113719.1.302.4.4.1<OID-TBD> NAME 'uddiName' Bergeson & Boogert Internet-Draft 6 LDAP Schema for UDDI May 2002 DESC 'human readable name' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) The xml:lang valueææ#ÆÆ"#" precedes the name value.Bergeson & Boogert Internet-Draft 6 LDAP Schema for UDDI Feb 20025.5 uddiDescription The uddiDescription is an optional repeating element of one or more descriptions. One description is allowed per national language code supplied. (2.16.840.1.113719.1.302.4.5.1<OID-TBD> NAME 'uddiDescription' DESC 'short description' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) The xml:lang valueææ#ÆÆ"#" precedes the description value. 5.6 uddiDiscoveryURLs This is a list of Uniform Resource Locators (URL) that point to alternate, file based service discovery mechanisms. Each recorded uddiBusinessEntity structure is automatically assigned a URL that returns the individual uddiBusinessEntity structure. URL search is provided via find_business call. The uddiDiscoveryURLs attribute is used to hold pointers to URL addressable discovery documents. The expected retrieval mechanism for URLs referenced in the data within this structure is HTTP-GET. The expected return document is not defined. Rather, a framework for establishing convention is provided, and two such conventions are defined within UDDI behaviors. It is hoped that other conventions come about and use this structure to accommodate alternate means of discovery. (2.16.840.1.113719.1.302.4.6.1<OID-TBD> NAME 'uddiDiscoveryURLs' DESC 'URL to retrieve a businessEntity instance' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) The useType value "#" precedes the URL value. 5.7 uddiUseType Bergeson & Boogert Internet-Draft 7 LDAP Schema for UDDI May 2002 The uddiUseTypedesignates the name of the convention that the referenced document follows. Two reserved convention values are ææbusinessEntityÆÆ and ææbusinessEntityExtÆÆ. URLs qualified with these values should pointis used toXML documents ofdescribe thesametypeas the uddiUseType value.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. (2.16.840.1.113719.1.302.4.7.1<OID-TBD> NAME 'uddiUseType' DESC 'name of convention the referenced document follows' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )Bergeson & Boogert Internet-Draft 7 LDAP Schema for UDDI Feb 20025.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ÆÆ"administrator" orææwebmasterÆÆ."webmaster". (2.16.840.1.113719.1.302.4.8.1<OID-TBD> NAME 'uddiPersonName' DESC 'name of person or job role available for contact' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) 5.9 uddiPhone Used to hold telephone numbers for the contact. This element can be adorned with an optional uddiUseType attribute for descriptive purposes. If more than one phone element is saved, uddiUseType attributes are required on each.The uddiUseType is appended to the telephone number by a separating æ#Æ. For example: ææ123 456-7890#Work NumberÆÆ(2.16.840.1.113719.1.302.4.9.1<OID-TBD> NAME 'uddiPhone' DESC 'telephone number for contact' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) The useType precedes the telephone number by a separating '#' (e.g. "Work Number#123 456-7890") 5.10 uddiEMail Used to hold email addresses for the contact. This element can be adorned with an optional uddiUseType attribute for descriptive purposes. If more than one email element is saved, uddiUseType attributes are required on each.The uddiUseType is appended to the email address by a separating æ#Æ. For example: ææpresident@whitehouse.gov#President of the United StatesÆÆ(2.16.840.1.113719.1.302.4.10.1<OID-TBD> Bergeson & Boogert Internet-Draft 8 LDAP Schema for UDDI May 2002 NAME 'uddiEMail' DESC 'e-mail address for contact' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )5.11 uddiSortCodeTheuddiSortCode is used to driveuseType precedes thebehavior ofemail address by a separating '#' (e.g. "President of the United States#president@whitehouse.gov"). 5.11 uddiSortCode The uddiSortCode is used to drive the behavior of external display mechanisms that sort addresses. The suggested values for uddiSortCode include numeric ordering values (e.g. 1, 2, 3), alphabetic character ordering values (e.g. a, b, c) or the first n positions of relevant data within the address. (2.16.840.1.113719.1.302.4.11.1<OID-TBD> NAME 'uddiSortCode'Bergeson & Boogert Internet-Draft 8 LDAP Schema for UDDI Feb 2002DESC 'specifies an external disply mechanism' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) 5.12 uddiTModelKey This is the unique key reference that implies that theuddiKeyName uddiKeyValuekeyName keyValue pairs given by subsequent uddiAddressLine elements are to be interpreted by the taxonomy associated with the uddiTModel that is referenced. (2.16.840.1.113719.1.302.4.12.1<OID-TBD> NAME 'uddiTModelKey' DESC 'tModel unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) 5.13 uddiAddressLine The uddiAddressLine contains the actual address in freeform text. If the address element contains a uddiTModelKey, these uddiAddressLine elements are to be adorned each with an optionaluddiKeyName uddiKeyValuekeyName keyValue attribute pair. Together with the uddiTModelKey,uddiKeyNamekeyName anduddiKeyValuekeyValue 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,uddiKeyNamekeyName anduddiKeyValue.keyValue. Both attributes must be present in each address line if a Bergeson & Boogert Internet-Draft 9 LDAP Schema for UDDI May 2002 uddiTModelKey is assigned to the address structure. By doing this, the otherwise arbitrary use of address lines becomes structured. Together with theaddressÆaddress' uddiTModelKey,uddiKeyNamekeyName anduddiKeyValuekeyValue virtually build a uddiKeyedReference that represents an address line qualifier, given by the referenced uddiTModel. When no uddiTModelKey is provided for the address structure, theuddiKeyNamekeyName anduddiKeyValuekeyValue attributes can be used without restrictions, for example, to provide descriptive information for each uddiAddressLine by using theuddiKeyNamekeyName attribute. Since both theuddiKeyNamekeyName and theuddiKeyValuekeyValue 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. (2.16.840.1.113719.1.302.4.13.1<OID-TBD> NAME 'uddiAddressLine' DESC 'address' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )Bergeson & Boogert Internet-Draft 9 LDAP Schema for UDDI Feb 2002 5.14 uddiKeyNameTheuddiKeyName is an optional element, but may only be specified if uddiKeyValue is also specified. See uddiAddressLine for more information. ( 2.16.840.1.113719.1.302.4.14.1 NAME 'uddiKeyName' DESC 'key name' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 5.15 uddiKeyValuetModel, keyName, and keyValue of this attribute are separated by "#", (e.g. <tModel>"#"<keyName>"#"<keyValue>). TheuddiKeyValuekeyValue isan optional element, but maythe onlybe specified if uddiKeyName is also specified. See uddiAddressLine for more information. ( 2.16.840.1.113719.1.302.4.15.1 NAME 'uddiKeyValue' DESC 'key value' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 5.16required portion of the attribute. 5.14 uddiIdentifierBag The uddiIdentifierBag element allows uddiBusinessEntity or uddiTModel structures to include information about common forms of identification such as D-U-N-S_ numbers, tax identifiers, etc. This data can be used to signify the identity of the uddiBusinessEntity, or can be used to signify the identity of the publishing party. Including data of this sort is optional, but when used greatly enhances the search behaviors exposed via the find_xx messages defined in the UDDI Version 2.0 API Specification. For a full description of the structures involved in establishing an identity, see UDDI Version 2.0 Data Structure Specification - Appendix A: Using Identifiers. (2.16.840.1.113719.1.302.4.16.1<OID-TBD> NAME 'uddiIdentifierBag' DESC 'identification information' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )5.17The tModel, keyName, and keyValue of this attribute are separated by "#", (e.g. <tModel>"#"<keyName>"#"<keyValue>). The keyValue is the only required portion of the attribute. 5.15 uddiCategoryBag Bergeson & Boogert Internet-Draft 10 LDAP Schema for UDDI May 2002 The uddiCategoryBag element allows uddiBusinessEntity, uddiBusinessService and uddiTModel structures to be categorized according to any of several available taxonomy based classification schemes. Operator Sites automatically provide validated categorization support for three taxonomies that cover industry codes (via NAICS), product and service classifications (via UNSPC)Bergeson & Boogert Internet-Draft 10 LDAP Schema for UDDI Feb 2002and geography (via ISO 3166). Including data of this sort is optional, but when used greatly enhances the search behaviors exposed by the find_xx messages defined in the UDDI Version 2.0 API Specification. For a full description of structures involved in establishing categorization information, see UDDI Version 2.0 Data Structure Specification - Appendix B: Using categorization. (2.16.840.1.113719.1.302.4.17.1<OID-TBD> NAME 'uddiCategoryBag' DESC 'categorization information' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )5.18The tModel, keyName, and keyValue of this attribute are separated by "#", (e.g. <tModel>"#"<keyName>"#"<keyValue>). The keyValue is the only required portion of the attribute. 5.16 uddiKeyedReference The uddiKeyedReference is a general-purpose attribute for a name- value pair, with an additional reference to a tModel. ( <OID-TBD> NAME 'uddiKeyedReference' DESC 'categorization information' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) The tModel, keyName, and keyValueorof this attribute are separated byææ#ÆÆ, e.g. <tModel>ÆÆ#ÆÆ<keyName>ÆÆ#ÆÆ<keyValue>."#", (e.g. <tModel>"#"<keyName>"#"<keyValue>). The keyValue is the only required portion of the attribute.( 2.16.840.1.113719.1.302.4.18.1 NAME 'uddiKeyedReference' DESC 'categorization information' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 5.195.17 uddiServiceKey This is the unique key for a given uddiBusinessService. When saving a new uddiBusinessService structure, pass an empty uddiServiceKey value. This signifies that a UUID value is to be generated. To update an existing uddiBusinessService structure, pass the UUID value that corresponds to the existing service. If this data is received via an inquiry operation, the uddiServiceKey values may not be blank. When saving a new or updated service projection, pass the uddiServiceKey of the referenced uddiBusinessService structure. This attribute is optional when the uddiBindingTemplate data is contained within a fully expressed parent that already contains a Bergeson & Boogert Internet-Draft 11 LDAP Schema for UDDI May 2002 uddiServiceKey value. If the uddiBindingTemplate data is rendered into XML and has no containing parent that has within its data a uddiServiceKey, the value of the uddiServiceKey that is the ultimate containing parent of the uddiBindingTemplate is required to be provided. This behavior supports the ability to browse through the parent-child relationships given any of the core elements as a starting point. (2.16.840.1.113719.1.302.4.19.1<OID-TBD> NAME 'uddiServiceKey' DESC 'businessService unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUEBergeson & Boogert Internet-Draft 11 LDAP Schema for UDDI Feb 2002)5.205.18 uddiBindingKey This is the unique key for a given uddiBindingTemplate. When saving a new uddiBindingTemplate structure, pass an empty uddiBindingKey value. This signifies that a UUID value is to be generated. To update an existing uddiBindingTemplate, pass the UUID value that corresponds to the existing uddiBindingTemplate instance. If this data is received via an inquiry operation, the uddiBindingKey values may not be blank. (2.16.840.1.113719.1.302.4.20.1<OID-TBD> NAME 'uddiBindingKey' DESC 'bindingTemplate unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )5.215.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 nameduddiURLType.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. (2.16.840.1.113719.1.302.4.21.1<OID-TBD> NAME 'uddiAccessPoint' DESC 'entry point address to call a web service' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 Bergeson & Boogert Internet-Draft 12 LDAP Schema for UDDI May 2002 SINGLE-VALUE )5.22The URLType value "#" precedes the accessPoint value. 5.20 uddiHostingRedirector The uddiHostingRedirector element is used to designate that a uddiBindingTemplate entry is a pointer to a different uddiBindingTemplate entry. The value in providing this facility is seen when a business or entity wants to expose a service description (e.g. advertise that they have a service available that suits a specific purpose) that is actually a service that is described in a separate uddiBindingTemplate record. This might occur when a service is remotely hosted (hence the name of this element), or when many service descriptions could benefit from a single service description.Bergeson & Boogert Internet-Draft 12 LDAP Schema for UDDI Feb 2002The uddiHostingRedirector element has a single attribute and no element content. The attribute is a uddiBindingKey value that is suitable within the same UDDI registry instance for querying and obtaining the uddiBindingDetail data that is to be used. More on the uddiHostingRedirector can be found in the appendices for the UDDI Version 2.0 API Specification. Required element if uddiAccessPoint not provided. This element is adorned with a uddiBindingKey attribute, giving the redirected reference to a different uddiBindingTemplate. If you query a uddiBindingTemplate and find a uddiHostingRedirector value, you should retrieve that uddiBindingTemplate and use it in place of the one containing the uddiHostingRedirector data. (2.16.840.1.113719.1.302.4.22.1<OID-TBD> NAME 'uddiHostingRedirector' DESC 'designates a pointer to another bindingTemplate' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )5.235.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. (2.16.840.1.113719.1.302.4.23.1<OID-TBD> NAME 'uddiInstanceDescription' DESC 'instance details description' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) Bergeson & Boogert Internet-Draft 13 LDAP Schema for UDDI May 2002 The xml:lang valueææ#ÆÆ"#" precedes the description value.5.245.22 uddiInstanceParms The uddiInstance Parms is an Optional element of the uddiInstance. Used to contain settings parameters or a URL reference to a file that contains settings or parameters required to use a specific facet of a uddiBindingTemplate description. If used to house the parameters themselves, the suggested content is a namespace qualified XML string - - using a namespace outside of the UDDI schema. If used to house a URL pointer to a file, the suggested format is URL that is suitable for retrieving the settings or parameters via HTTP-GET. (2.16.840.1.113719.1.302.4.24.1<OID-TBD> NAME 'uddiInstanceParms' DESC 'URL reference to required settings' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )Bergeson & Boogert Internet-Draft 13 LDAP Schema for UDDI Feb 2002 5.255.23 uddiOverviewDescription This is optional repeating element. This language-qualified string is intended to hold a short descriptive overview of how a particular uddiTModel is to be used. (2.16.840.1.113719.1.302.4.25.1<OID-TBD> NAME 'uddiOverviewDescription' DESC 'outlines tModel usage' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) The xml:lang valueææ#ÆÆ"#" precedes the description value.5.265.24 uddiOverviewURL This is an optional element. This string data element is to be used to hold a URL reference to a long form of an overview document that covers the way a particular uddiTModel specific reference is used as a component of an overall web service description. The suggested format is a URL that is suitable for retrieving an HTML based description via a web browser or HTTP-GET operation. (2.16.840.1.113719.1.302.4.26.1<OID-TBD> NAME 'uddiOverviewURL' DESC 'URL reference to overview document' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )5.27Bergeson & Boogert Internet-Draft 14 LDAP Schema for UDDI May 2002 5.25 uddiFromKey The uddiFromKey is a required element. This is the unique key reference to the first uddiBusinessEntity the assertion is made for. (2.16.840.1.113719.1.302.4.27.1<OID-TBD> NAME 'uddiFromKey' DESC 'unique businessEntity key reference' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )5.285.26 uddiToKey The uddiToKey is a required element. This is the unique key reference to the second uddiBusinessEntity the assertion is made for. (2.16.840.1.113719.1.302.4.28.1<OID-TBD> NAME 'uddiToKey' DESC 'unique businessEntity key reference' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15Bergeson & Boogert Internet-Draft 14 LDAP Schema for UDDI Feb 2002SINGLE-VALUE )5.295.27 uddiUUID The uddiUUID is a required element. This is to insure unique identification ofdatauddiContact, uddiAddress, and uddiPublisherAssertion objects. (2.16.840.1.113719.1.302.4.29.1<OID-TBD> NAME 'uddiUUID' DESC 'unique attribute' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )5.305.28 uddiIsHidden Used to provide functionality for the delete_tModel operation. Logical deletion hides the deleted tModels from find_tModel result sets but does not physically delete it. (2.16.840.1.113719.1.302.4.30.1<OID-TBD> NAME 'uddiIsHidden' DESC 'isHidden attribute' EQUALITY booleanMatch SYNTAX1.3.6.1.4.1.1466.115.121.1.151.3.6.1.4.1.1466.115.121.1.7 Bergeson & Boogert Internet-Draft 15 LDAP Schema for UDDI May 2002 SINGLE-VALUE ) 6. Object Class Definitions The following object classes are defined in this document: uddiBusinessEntity uddiContact uddiAddress uddiBusinessService uddiBindingTemplate uddiTModelInstanceInfo uddiTModel uddiPublisherAssertion Note that OIDs for the object classes in this document have not been assigned. All OIDs are in brackets, <OID-TBD>, as a placeholder until real OIDs are assigned. 6.1 uddiBusinessEntity This structural object class represents a businessEntity. (2.16.840.1.113719.1.302.6.1.1<OID-TBD> NAME 'uddiBusinessEntity' SUP'top'top STRUCTURAL MUST ( uddiBusinessKey $ uddiName) MAY ( uddiAuthorizedName $ uddiOperator $ uddiDiscoveryURLs $ uddiDescription $ uddiIdentifierBag $Bergeson & Boogert Internet-Draft 15 LDAP Schema for UDDI Feb 2002uddiCategoryBag )X-NDS_NAMING ('uddiBusinessKey' 'uddiName') X-NDS_CONTAINMENT ( 'country' 'locality' 'organization' 'organizationalUnit' 'domain' )) 6.2 uddiContact This structural object class represents a contact. It is contained by an uddiBusinessEntity. (2.16.840.1.113719.1.302.6.2.1<OID-TBD> NAME 'uddiContact' SUP'top'top STRUCTURAL MUST ( uddiPersonName $ uddiUUID ) MAY ( uddiUseType $ uddiDescription $ uddiPhone $ Bergeson & Boogert Internet-Draft 16 LDAP Schema for UDDI May 2002 uddiEMail )X-NDS_NAMING ( 'uddiUUID' ) X-NDS_CONTAINMENT ( 'uddiBusinessEntity' )) 6.3 uddiAddress This structural object class represents an address. It is contained by an uddiContact. (2.16.840.1.113719.1.302.6.3.1<OID-TBD> NAME 'uddiAddress' SUP'top'top STRUCTURAL MUST ( uddiUUID ) MAY ( uddiUseType $ uddiSortCode $ uddiTModelKey $uddiAddressLine) X-NDS_NAMING ( 'uddiUUID' ) X-NDS_CONTAINMENT ( 'uddiContact'uddiAddressLine ) ) 6.4 uddiBusinessService This structural object class represents a businessService. (2.16.840.1.113719.1.302.6.4.1<OID-TBD> NAME 'uddiBusinessService' SUP'top' Bergeson & Boogert Internet-Draft 16 LDAP Schema for UDDI Feb 2002top STRUCTURAL MUST ( uddiServiceKey $ uddiName ) MAY ( uddiBusinessKey $ uddiDescription $ uddiCategoryBag )X-NDS_NAMING ( 'uddiServiceKey' ) X-NDS_CONTAINMENT ( 'uddiBusinessEntity' )) 6.5 uddiBindingTemplate This structural object class represents a bindingTemplate. (2.16.840.1.113719.1.302.6.5.1<OID-TBD> NAME 'uddiBindingTemplate' SUP'top'top STRUCTURAL MUST ( uddiBindingKey ) MAY ( uddiServiceKey $ uddiDescription $ uddiAccessPoint $ uddiHostingRedirector )X-NDS_NAMING ( 'uddiBindingKey' ) X-NDS_CONTAINMENT ( 'uddiBusinessService' )) 6.6 uddiTModelInstanceInfo This structural object class represents a tModelInstanceInfo. It is contained by an uddiBindingTemplate. Bergeson & Boogert Internet-Draft 17 LDAP Schema for UDDI May 2002 (2.16.840.1.113719.1.302.6.6.1<OID-TBD> NAME 'uddiTModelInstanceInfo' SUP'top'top STRUCTURAL MUST ( uddiTModelKey ) MAY ( uddiDescription $ uddiInstanceDescription $ uddiInstanceParms $ uddiOverviewDescription $ uddiOverviewURL )X-NDS_NAMING ( 'uddiTModelKey' ) X-NDS_CONTAINMENT ( 'uddiBindingTemplate' )) 6.7 uddiTModel This structural object class represents a tModel. (2.16.840.1.113719.1.302.6.7.1<OID-TBD> NAME 'uddiTModel' SUP'top' Bergeson & Boogert Internet-Draft 17 LDAP Schema for UDDI Feb 2002top STRUCTURAL MUST ( uddiTModelKey $ UddiName ) MAY ( uddiAuthorizedName $ uddiOperator $ uddiDescription $ uddiOverviewDescription $ uddiOverviewURL $ uddiIdentifierBag $ uddiCategoryBag $ uddiIsHidden )X-NDS_NAMING ( 'uddiTModelKey' ) X-NDS_CONTAINMENT ( 'country' 'locality' 'organization' 'organizationalUnit' 'domain' )) 6.8 uddiPublisherAssertion This structural object class represents a publisherAssertion. (2.16.840.1.113719.1.302.6.8.1<OID-TBD> NAME 'uddiPublisherAssertion' SUP'top'top STRUCTURAL MUST ( uddiFromKey $ uddiToKey $ uddiKeyedReference $ uddiUUID )X-NDS_NAMING ( 'uddiUUID' ) X-NDS_CONTAINMENT ( 'country' 'locality' 'organization' 'organizationalUnit' 'domain' )) 7.Security Considerations Storing UDDI data into the directory enablesName Forms This section defines thedata to be examinedrequired hierarchical structure rules andused outsidenaming attributes for theenvironmentobject classess defined inwhich it was originally created.section 6. Thedirectory entry containing the UDDI data could be read and modified within the constraints imposed by the access control mechanisms of the directory. 8. Referencesfollowing name forms are defined in this document: Bergeson & Boogert Internet-Draft 18 LDAP Schema for UDDIFebMay 2002 uddiBusinessEntityNameForm uddiContactNameForm uddiAddressNameForm uddiBusinessServiceNameForm uddiBindingTemplateNameForm uddiTModelInstanceInfoNameForm uddiTModelNameForm uddiPublisherAssertionNameForm Note that OIDs for the structure rules in this document have not been assigned. All OIDs are in brackets, <OID-TBD>, as a placeholder until real OIDs are assigned. 7.1 uddiBusinessEntityNameForm This name form defines the naming attribute for a businessEntity. ( <OID-TBD> NAME 'uddiBusinessEntityNameForm' OC uddiBusinessEntity MUST ( uddiBusinessKey $ uddiName ) ) 7.2 uddiContactNameForm This name form defines the naming attribute for a contact. ( <OID-TBD> NAME 'uddiContactNameForm' OC uddiContact MUST ( uddiUUID ) ) 7.3 uddiAddressNameForm This name form defines the naming attribute for an address. ( <OID-TBD> NAME 'uddiAddressNameForm' OC uddiAddress MUST ( uddiUUID ) ) 7.4 uddiBusinessServiceNameForm This name form defines the naming attribute for a businessService. ( <OID-TBD> NAME 'uddiBusinessServiceNameForm' OC uddiBusinessService MUST ( uddiServiceKey ) ) Bergeson & Boogert Internet-Draft 19 LDAP Schema for UDDI May 2002 7.5 uddiBindingTemplateNameForm This name form defines the naming attribute for a bindingTemplate. ( <OID-TBD> NAME 'uddiBindingTemplateNameForm' OC uddiBindingTemplate MUST ( uddiBindingKey ) ) 7.6 uddiTModelInstanceInfoNameForm This name form defines the naming attribute for a tModelInstanceInfo. ( <OID-TBD> NAME 'uddiTModelInstanceInfoNameForm' OC uddiTModelInstanceInfo MUST ( uddiTModelKey ) ) 7.7 uddiTModelNameForm This name form defines the naming attribute for a tModel. ( <OID-TBD> NAME 'uddiTModelNameForm' OC uddiTModel MUST ( uddiTModelKey ) ) 7.8 uddiPublisherAssertionNameForm This name form defines the naming attribute for a publisherAssertion. ( <OID-TBD> NAME 'uddiPublisherAssertionNameForm' OC uddiPublisherAssertion MUST ( uddiUUID ) ) 8. DIT Structure Rules This section defines the required hierarchical structure rules for the object classess defined in section 6. The following structure rules are defined in this document: uddiBusinessEntityStructureRule uddiContactStrucureRule Bergeson & Boogert Internet-Draft 20 LDAP Schema for UDDI May 2002 uddiAddressStructureRule uddiBusinessServiceStructureRule uddiBindingTemplateStructureRule uddiTModelInstanceInfoStructureRule Note that rule identifiers defined here show the relationship between structure rules. Implementations may use different identifiers but must follow the same hierarchical model. 8.1 uddiBusinessEntityStructureRule ( 1Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.NAME 'uddiBusinessEntityStructureRule' FORM uddiBusinessEntityNameForm ) 8.2 uddiContactStrucureRule This structure rule defines the object class containment for a contact. ( 2 NAME 'uddiContactStrucureRule' FORM uddiContactNameForm SUP ( 1 ) ) 8.3 uddiAddressStructureRule This structure rule defines the object class containment for a address. ( 3 NAME 'uddiAddressStructureRule' FORM uddiAddressNameForm SUP ( 2 ) ) 8.4 uddiBusinessServiceStructureRule This structure rule defines the object class containment for a businessService. ( 4 NAME 'uddiBusinessServiceStructureRule' FORM uddiBusinessServiceNameForm SUP ( 1 ) ) 8.5 uddiBindingTemplateStructureRule This structure rule defines the object class containment for a bindingTemplate. Bergeson & Boogert Internet-Draft 21 LDAP Schema for UDDI May 2002 ( 5 NAME 'uddiBindingTemplateStructureRule' FORM uddiBindingTemplateNameForm SUP ( 4 ) ) 8.6 uddiTModelInstanceInfoStructureRule This structure rule defines the object class containment for a tModelInstanceInfo. ( 6 NAME 'uddiTModelInstanceInfoStructureRule' FORM uddiTModelInstanceInfoNameForm SUP ( 5 ) ) 9. Security Considerations Storing UDDI data into the directory enables the data to be examined and used outside the environment in which it was originally created. The directory entry containing the UDDI data could be read and modified within the constraints imposed by the access control mechanisms of the directory. 10. References [LDAPv3] M. Wahl, s. Kille and T. Howes,ææLightweight"Lightweight Directory Access Protocol(v3)ÆÆ,(v3)", Internet Standard, December, 1997. Available as RFC2251 [UDDI] UDDI.ORG,ææUDDI"UDDI version 2.0 Data StructureReference,ÆÆReference," http://www.uddi.org [RFC2119] S. Bradner,ææKey"Key Words for use in RFCs to Indicate RequirementLevels,ÆÆLevels," Internet Standard, December, 1997. Available as RFC225310.11. Author's Addresses Bruce Bergeson Novell, Inc. Mail Stop PRV-H411 1800 S Novell Place Provo, UT 84606 Phone: +1 801 861 3854 Email: bruce.bergeson@novell.com Bergeson & Boogert Internet-Draft 22 LDAP Schema for UDDI May 2002 Kent Boogert Novell, Inc. 1800 S Novell Place Provo, UT 84606 Phone: +1 801 861 3212 Email: kent.boogert@novell.com Bergeson & Boogert Internet-Draft1923 ----