RFC 4403
Lightweight Directory Access Protocol (LDAP) Schema for Universal Description, Discovery, and Integration version 3 (UDDIv3)
RFC 4403: Lightweight Directory Access Protocol (LDAP) Schema for Universal Description, Discovery, and Integration version 3 (UDDIv3) 🎀
Okay bestie, this one is an Informational RFC, so it's sharing info with the Internet community and it's not a binding standard 🌸 It came out in February 2006 from the Network Working Group. The authors are B. Bergeson and K. Boogert from Novell, Inc., plus V. Nanjundaswamy from Oracle India Pvt. Ltd. 💜 It doesn't list anything it obsoletes or updates, so it's its own little world ✨
Status of This Memo
This memo gives info to the Internet community. It doesn't specify an Internet standard of any kind, and distribution of it is unlimited 🦋
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Okay so this doc defines the Lightweight Directory Access Protocol (LDAPv3) schema for storing Universal Description, Discovery, and Integration (UDDI) data types in an LDAP directory 🧚 It sets up the LDAP object classes, attributes, and containment rules to model the UDDI entities from the UDDI version 3 information model, so they fit in an LDAPv3-compliant directory. It's giving organization, honestly 💅
Table of Contents
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Representation of UDDI Data Structures ..........................2
4. Attribute Type Definitions ......................................6
5. Object Class Definitions .......................................28
6. Name Forms .....................................................32
7. DIT Structure Rules ............................................35
8. Security Considerations ........................................37
9. IANA Considerations ............................................37
10. Normative References ..........................................401. Introduction 🌈
So this doc defines the Lightweight Directory Access Protocol [LDAPv3] schema elements that hold the core data structures from the Universal Description, Discovery, and Integration version 3 [UDDIv3] information model. That covers a businessEntity, a businessService, a bindingTemplate, a tModel, a publisherAssertion, and a Subscription. Some parts of [UDDIv3] get repeated here so everything is easier to follow ✨
2. Conventions Used in This Document 🫶
Bestie, the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc get read the way RFC 2119 [RFC2119] describes ⭐
All the schema definitions come in [RFC2252] descriptions, and they're only line-wrapped so they're easier to read 🍓
3. Representation of UDDI Data Structures 💖
Okay the info that makes up a registration in a UDDI registry is split into these data structure types. Splitting it up by information type makes it way faster to find and understand the different bits of a registration 🧚
The instance data a UDDI registry manages is super sensitive to the parent/child relationships in the schema. A businessEntity object holds one or more unique businessService objects. Each businessService object holds specific instances of bindingTemplate, and each bindingTemplate has pointers to specific instances of tModel objects 🎀
Here's the key thing: no single instance of a core schema type is ever "contained" by more than one parent instance. So only one specific businessEntity (found by its unique key value) will ever contain a given businessService instance, or be used to express info about it (which is identified by its own unique key value). Main character rule, one parent only 👑
3.1. businessEntity 🌸
The businessEntity object represents all the known info about a business or entity that publishes descriptive info about itself and the services it offers. It's the top-level container for holding that descriptive info. Service descriptions and technical info get expressed inside a businessEntity through a containment relationship 💜
3.1.1. Representation in the Directory
A businessEntity shows up in the directory through these attributes: uddiBusinessKey, uddiAuthorizedName, uddiOperator, uddiDiscoveryURLs, uddiName, uddiDescription, uddiIdentifierBag, uddiCategoryBag, and uddiv3DigitalSignature. It also has the matching v3 key, uddiv3BusinessKey, all defined in Section 4. A businessEntity may hold zero or more uddiContact and uddiBusinessService instances ✨
uddiBusinessKey is the mandatory attribute, and it holds the unique identifier for a given businessEntity instance 🔑
The businessEntity definition lives in Section 5 🦋
3.2. businessService 🫧
The businessService instances stand for a logical business service. Every businessService object is the logical child of exactly one businessEntity object. Each businessService has descriptive info, written in business terms, that outlines the type of technical services inside that businessService instance 💅
Sometimes businesses want to share or reuse services, like when a big enterprise publishes separate businessEntity structures. To do that, a businessService instance can act as a projection of a businessService that's already published 🧚
3.2.1. Representation in the Directory
A businessService shows up in the directory through these attributes: uddiBusinessKey, uddiServiceKey, uddiName, uddiDescription, uddiCategoryBag, uddiIsProjection, and uddiv3DigitalSignature. It also has the v3 keys uddiv3BusinessKey and uddiv3ServiceKey, all defined in Section 4. A businessService may hold zero or more uddiBindingTemplate instances 🌈
uddiServiceKey is the mandatory attribute, and it holds the unique identifier for a given businessService instance 💖
The businessService definition is in Section 5 ✨
3.3. bindingTemplate 🎀
Technical descriptions of Web services live in individual contained bindingTemplate objects. These instances help figure out a technical entry point, and they can optionally support remotely hosted services. They also give you a lightweight way to describe the unique technical traits of a given implementation. Technology- and application-specific parameters and settings files are supported too 🍓
UDDI's main job is to enable description and discovery of Web service info, so the bindingTemplate is honestly the most interesting part for technical data. With UDDIv3, bindingTemplates can also have categorization info 🔥
Each bindingTemplate instance has one logical businessService parent, and that businessService has one logical businessEntity parent 👑
3.3.1. Representation in the Directory
A bindingTemplate shows up in the directory through these attributes: uddiBindingKey, uddiServiceKey, uddiDescription, uddiAccessPoint, uddiHostingRedirector, uddiCategoryBag, and uddiv3DigitalSignature. It also has the v3 keys uddiv3ServiceKey and uddiv3BindingKey, all defined in Section 4. A bindingTemplate may hold zero or more uddiTModelInstanceDetails instances 🦋
uddiBindingKey is the mandatory attribute, and it holds the unique identifier for a given bindingTemplate instance 🫶
The bindingTemplate definition is in Section 5 💜
3.4. tModel 🧚
The tModel object is basically keyed metadata, which means data about data. Generally speaking, a tModel's job in the UDDI registry is to be a reference system built on abstraction. So the kind of data a tModel represents is pretty nebulous. In other words, a tModel registration can define just about anything, but in the current revision two conventions are used for tModels: as sources for working out compatibility, and as keyed namespace references 🌸
A tModel is actually pretty simple. It has a key, a name, an optional description, and a Uniform Resource Locator [URL] that points somewhere. That somewhere is presumably where the curious can go to learn more about the actual concept the tModel's metadata represents 💖
3.4.1. Representation in the Directory
A tModel shows up in the directory through these attributes: uddiTModelKey, uddiAuthorizedName, uddiOperator, uddiName, uddiDescription, uddiOverviewDescription, uddiOverviewURL, uddiIdentifierBag, uddiCategoryBag, uddiIsHidden, and uddiv3DigitalSignature. It also has the v3 key uddiv3tModelKey, all defined in Section 4. A tModel may also hold a uddiHidden to logically delete it 🙈
uddiTModelKey is the mandatory attribute, and it holds the unique identifier for a given tModel instance 🔑
The tModel definition is in Section 5 ✨
3.5. publisherAssertion 🌈
Lots of businesses, like big enterprises or marketplaces, aren't effectively represented by a single businessEntity, since how they get described and discovered is pretty diverse. So several businessEntity instances can be published, representing the individual subsidiaries of a big enterprise or the individual participants of a marketplace. Even so, they're still a more or less coupled community, and they'd like to make some of their relationships visible in their UDDI registrations 🫶
3.5.1. Representation in the Directory
A publisherAssertion shows up in the directory through the attributes uddiFromKey, uddiToKey, uddiKeyedReference, and uddiUUID, plus uddiv3DigitalSignature, all defined in Section 5 🧚
uddiUUID is the mandatory attribute, and it holds the unique identifier for a given publisherAssertion instance 💅
The publisherAssertion definition is in Section 5 🦋
3.6. Operational Information 🌸
With UDDIv3, the operational info tied to the core UDDI data structures is kept in a separate OperationalInfo structure. That way the digital signature the publisher set stays valid 💜
The operationalInfo structure carries the operational info for the UDDIv3 core data structures, which are the businessEntity, businessService, bindingTemplate, and tModel structures. UDDIv3 OperationalInfo has 5 elements: created, Modified, modifiedIncludingChildren, nodeId, and authorizedName 🔥
Depending on which UDDIv3 core data structure you're looking at, the operationalInformation shows up in the directory as a mix of implicit LDAP Standard Operational attributes, createTimestamp and modifyTimestamp, and these explicit attributes: uddiAuthorizedName, uddiv3EntityCreationTime, uddiv3EntityModificationTime, and uddiv3NodeId 🎀
4. Attribute Type Definitions 👑
The OIDs for the attribute types in this document have been registered by the IANA 🧚
Part 2 is where the attribute definitions really start, so stay tuned 💖🦋
4.1. uddiBusinessKey 🔑
okay so this one shows up in both uddiBusinessEntity and uddiBusinessService 💖 It's the unique ID card for one specific uddiBusinessEntity 🪪✨ For a businessService, it's optional as long as it's sitting inside a fully expressed parent that already has a businessKey value. Lowkey iconic, right? 💅
If the businessService gets rendered into the Extensible Markup Language [XML] and has no containing parent with a businessKey in its data, then the businessKey of the businessService's parent is required to be provided. This is what lets you browse the parent-child relationships starting from any of the core elements 🧚 And the businessKey can be different from the publishing businessEntity's businessKey, which is how service projections work 🦋
( 1.3.6.1.1.10.4.1 NAME 'uddiBusinessKey'
DESC 'businessEntity unique identifier'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)4.2. uddiAuthorizedName 🖋️
The uddiAuthorizedName is the recorded name of the person who published the uddiBusinessEntity or uddiTModel data 💜 The controlling operator generates this one, so it should not be supplied within save_business operations. Hands off, bestie 🙈
With UDDIv3, this attribute is part of the "operationalInformation" metadata that comes with the core data structures ✨
( 1.3.6.1.1.10.4.2 NAME 'uddiAuthorizedName'
DESC 'businessEntity publisher name'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE
)4.3. uddiOperator 🏢
The uddiOperator is the certified name of the UDDI registry site operator that manages the master copy of the uddiBusinessEntity or uddiTModel. The controlling operator records this when the data gets saved, so it's generated and should not be supplied within save_business or save_tModel operations 🙅♀️
With UDDIv3, this field isn't used anymore. It got replaced by the nodeId (uddiv3NodeId) attribute, which is part of the "operationalInformation" metadata 🌸
( 1.3.6.1.1.10.4.3 NAME 'uddiOperator'
DESC 'registry site operator of businessEntitys master copy'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)4.4. uddiName 📛
This one gets used in uddiBusinessEntity, uddiBusinessService, and uddiTModel 💅
These are the human-readable names for a uddiBusinessEntity, uddiBusinessService, or uddiTModel. Each one comes with a unique xml:lang value that says what language it's written in 🌈 Name search works through find_business, find_service, or find_tModel calls.
Publishing more than one name is allowed, for example for romanization. To tell the languages apart, each name carries its own unique xml:lang value. Not more than one name element may leave out its language. Any name passed in that way gets the default language code of the registering party. That default is set up when publishing credentials are created with an individual Operator Site. If no default language is set at sign-up, the operator can pick a suitable default language code 🧚
With UDDIv3, multiple values with the same language code are allowed ✨
( 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 comes before the name value, with # as the separator 🎀
4.5. uddiDescription 📝
The uddiDescription is an optional, repeating element holding one or more descriptions. You get one description per national language code you supply 🌍 With UDDIv3, there's no limit on how many descriptions you can have, and no restriction on which xml:lang values they use 🦋
( 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 comes before the description, with # as the separator 💖
4.6. uddiDiscoveryURLs 🔗
This is a list of Uniform Resource Locators (URLs) that point to alternate, file-based service discovery mechanisms 🗺️ Every recorded uddiBusinessEntity automatically gets a URL that returns that individual uddiBusinessEntity structure. You can search by URL through a find_business call.
The uddiDiscoveryURLs attribute holds pointers to URL-addressable discovery documents. To retrieve URLs referenced in this structure, the expected method is the Hypertext Transfer Protocol [HTTP] HTTP-GET operation 🌐 The return document isn't defined. Instead, there's a framework for setting up conventions, and two of them are defined within UDDI behaviors. The hope is that other conventions show up and use this structure to support other ways of discovering things 🌸 With UDDIv3, there's a new convention where useType is "homepage" 🏡 Also, a UDDIv3 server doesn't need to generate or add a discoveryURL on its own, because doing that can break the digital signature on a Business Entity that publishers already signed and saved 🔏 That would be a major "not me…" moment 💀
( 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 comes before the URL, with # as the separator ✨
4.7. uddiUseType 🏷️
The uddiUseType describes the type of contact or address, written as freeform text 💬 Some suggested contact examples are "technical questions", "technical contact", "establish account", and "sales contact". For addresses, you could use "headquarters", "sales office", or "billing department" 🏢
( 1.3.6.1.1.10.4.7 NAME 'uddiUseType'
DESC 'name of convention the referenced document follows'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)4.8. uddiPersonName 🧑💼
The uddiPersonName should list the name of the person, or the job role, that's going to be available behind the contact 📞 Good examples of roles are "administrator" and "webmaster" 💅
( 1.3.6.1.1.10.4.8 NAME 'uddiPersonName'
DESC 'name of person or job role available for contact'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)With UDDIv3, uddiPersonName becomes multi-valued, and each name can have an xml:lang attribute 🌈 The xml:lang value comes before the name, with # as the separator.
4.9. uddiPhone ☎️
This holds telephone numbers for the contact 📱 The element can have an optional uddiUseType attribute to describe it. If you save more than one phone element, every one of them requires a uddiUseType attribute 🙈
( 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 comes before the telephone number, split by a # (for example, Work Number#123 456-7890) 🍓
4.10. uddiEMail 💌
This holds email addresses for the contact 💜 The element can have an optional uddiUseType attribute for description. If you save more than one email element, every one of them requires a uddiUseType attribute 💅
( 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 comes before the email address, split by a # (for example, President of the United States #president@whitehouse.gov) 🇺🇸✨
4.11. uddiSortCode 🔢
The uddiSortCode drives how external display mechanisms sort addresses 🗂️ Suggested values include numeric ordering values (like 1, 2, 3), alphabetic ordering values (like a, b, c), or the first n positions of relevant data within the address 🧚
( 1.3.6.1.1.10.4.11 NAME 'uddiSortCode'
DESC 'specifies an external display mechanism'
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)With UDDIv3, the sortCode attribute is deprecated, because the document Order is now guaranteed to be preserved 🥀
4.12. uddiTModelKey 🔐
The uddiTModelKey is the unique identifier for a given instance of a uddiTModel 🪪
It also shows up in a KeyedReference and in Address structures 💫 When it's used with a keyed reference, it's the unique key that identifies a value set. It also means that the keyName keyValue pair in a uddiIdentifier or uddiCategory Bag should be read using the value set that the tModelKey references.
When it's used with Addressline elements, it means that the keyName keyValue pairs given by the following uddiAddressLine elements should be read using the address structure linked to the referenced tModel 🏠
( 1.3.6.1.1.10.4.12 NAME 'uddiTModelKey'
DESC 'tModel unique identifier'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)4.13. uddiAddressLine 📬
The uddiAddressLine holds the actual address as freeform text 🏡 If the address element has a uddiTModelKey, each uddiAddressLine element gets an optional keyName keyValue attribute pair. Together with the uddiTModelKey, the keyName and keyValue say what the uddiAddressLine means 🧩
Each uddiAddressLine holds string data with a line length limit of 80 character positions 📏 Each one can have two optional descriptive attributes, keyName and keyValue. If the address structure has a uddiTModelKey, then both attributes must be present on every address line. Doing this turns the otherwise arbitrary use of address lines into something structured ✨ Together, the address' uddiTModelKey, keyName, and keyValue build a uddiKeyedReference that qualifies the address line, based on the referenced uddiTModel 💖
If the address structure has no uddiTModelKey, the keyName and keyValue attributes can be used freely, for example to describe each uddiAddressLine using the keyName attribute 🌸 Since both keyName and keyValue are optional, address line order matters, and the UDDI-compliant registry will always return lines in the order they were originally given during a save_business call 📚
( 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 #, like "#"<keyName>"#"<keyValue>"#"<addressData>. The addressData is the only required part of the attribute 🎀
4.14. uddiIdentifierBag ✨
okay so the uddiIdentifierBag element lets uddiBusinessEntity or uddiTModel structures carry common forms of identification, like D-U-N-S_ numbers, tax identifiers, etc. 🆔 This data can be used to signify the identity of the uddiBusinessEntity, or it can be used to signify the identity of the publishing party. Including it is optional, but when you do, it seriously levels up the search behaviors exposed via the find_xx messages defined in the UDDI Version 2.0 API Specification [UDDIapi] 💅 For the full tea on the structures involved in establishing an identity, check UDDI Version 2.0 Data Structure Specification - Appendix A: Using Identifiers [UDDIdsr] 📚
( 1.3.6.1.1.10.4.14 NAME 'uddiIdentifierBag'
DESC 'identification information'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)The tModel, keyName, and keyValue of this attribute are separated by "#" (e.g., <tModel>"#"<keyName>"#"<keyValue>). The keyValue is the only required portion of the attribute. 🎀
4.15. uddiCategoryBag 🌈
the uddiCategoryBag element lets uddiBusinessEntity, uddiBusinessService, and uddiTModel structures get categorized using any of several taxonomy-based classification schemes. 🗂️ Operator Sites automatically provide validated categorization support for three taxonomies: industry codes (via NAICS), product and service classifications (via UNSPC), and geography (via ISO 3166). Including this is optional, but when you use it, it greatly boosts the search behaviors exposed by the find_xx messages defined in the UDDI Version 2.0 API Specification [UDDIapi] 🔥 For a full description of the structures involved in establishing categorization information, see UDDI Version 2.03 Data Structure Specification--Appendix B: Using Categorization [UDDIdsr] 🧚
( 1.3.6.1.1.10.4.15 NAME 'uddiCategoryBag'
DESC 'categorization information'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)The tModel, keyName, and keyValue of this attribute are separated by "#" (e.g., <tModel>"#"<keyName>"#"<keyValue>). The keyValue is the only required portion of the attribute. 🫶
With UDDIv3, uddiBindingTemplates also supports the uddiCategoryBag element, so they can be categorized according to any of several taxonomy-based classification schemes too. 👑
4.16. uddiKeyedReference 🦋
the uddiKeyedReference is a general-purpose attribute for a name-value pair, with an additional reference to a tModel. it's giving versatile 🌸
( 1.3.6.1.1.10.4.16 NAME 'uddiKeyedReference'
DESC 'categorization information'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)The tModel, keyName, and keyValue of this attribute are separated by "#" (e.g., <tModel>"#"<keyName>"#"<keyValue>). The keyValue is the only required portion of the attribute. With UDDIv3, the tModelKey also becomes a mandatory part of the attribute. 💜
Also, UDDIv3 defines KeyedReferenceGroups for CategoryBags. A keyedReferenceGroup contains a tModelKey and a simple list of KeyedReference structures. The uddiKeyedReference attribute will support KeyedReferenceGroups by suffixing the tModelKey for the KeyedReferenceGroup to each of the keyedReference values associated with the group. 🍓
For example, to represent a keyedReference group containing a list of 2 keyed references, the attribute will hold the following 2 strings as its values:
tModelKey1#KeyName1#KeyValue1#KeyedReferenceGroup1_tModelKey
tModelKey2#KeyName2#KeyValue2#KeyedReferenceGroup1_tModelKey4.17. uddiServiceKey 🔑
This is the unique key for a given uddiBusinessService. When saving a new uddiBusinessService structure, pass an empty uddiServiceKey value. This signifies that a UUID value is to be generated. To update an existing uddiBusinessService structure, pass the UUID value that corresponds to the existing service. If a uddiServiceKey is received via an inquiry operation, the key values may not be blank. When saving a new or updated service projection, pass the uddiServiceKey of the referenced uddiBusinessService structure. 🎀
This attribute is optional when the uddiBindingTemplate data is contained within a fully expressed parent that already contains a uddiServiceKey value. If the uddiBindingTemplate data is rendered into XML and has no containing parent that has within its data a uddiServiceKey, the value of the uddiServiceKey that is the ultimate containing parent of the uddiBindingTemplate is required to be provided. This behavior supports the ability to browse through the parent-child relationships given any of the core elements as a starting point. 🧭
( 1.3.6.1.1.10.4.17 NAME 'uddiServiceKey'
DESC 'businessService unique identifier'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)4.18. uddiBindingKey 🗝️
This is the unique key for a given uddiBindingTemplate. When saving a new uddiBindingTemplate structure, pass an empty uddiBindingKey value. This signifies that a UUID value is to be generated. To update an existing uddiBindingTemplate, pass the UUID value that corresponds to the existing uddiBindingTemplate instance. If a uddiBindingKey is received via an inquiry operation, the key values may not be blank. 🌷
( 1.3.6.1.1.10.4.18 NAME 'uddiBindingKey'
DESC 'bindingTemplate unique identifier'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)4.19. uddiAccessPoint 📍
The uddiAccessPoint element is an attribute-qualified pointer to a service entry point. The notion of service at the metadata level is fairly abstract here, so many types of entry points are accommodated. 🌍 A single attribute is provided, named URLType.
Required attribute-qualified element8: This element is a text field used to convey the entry point address suitable for calling a particular Web service. This may be a URL, an electronic mail address, or even a telephone number. No assumptions about the type of data in this field can be made without first understanding the technical requirements associated with the Web service. 🙈
( 1.3.6.1.1.10.4.19 NAME 'uddiAccessPoint'
DESC 'entry point address to call a web service'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)The URLType value precedes the accessPoint value by a separating '#'. 🦋
With UDDIv3, the "URLType" attribute is replaced by a "UseType" attribute. Using this UseType attribute, the accessPoint attribute can model a hostingRedirector or support indirection, to indicate that the accesspoint is specified within a remotely hosted WSDL document. 🧚
For a UDDIv3 registry that needs to support UDDIv2 clients, the attribute must allow the representation of URLType and UseType values independently. 💅
The UDDIv3 spec specifies the following logic for mapping values between URLType and UseType: If an entity is saved with the v3 namespace and a v2 inquiry is made, the URLType will be returned as "other". When a v3 inquiry is made on an entity published with the v2 namespace, the v3 useType attribute will be returned as "endPoint". 🔄
For implementations that need to explicitly model both forms, the recommended format is as follows: v2URLType#v3UseType#Address ✨
4.20. uddiHostingRedirector 🪄
The uddiHostingRedirector element is used to designate that a uddiBindingTemplate entry is a pointer to a different uddiBindingTemplate entry. The payoff of this facility shows up when a business or entity wants to expose a service description (e.g., advertise that it has a service available that suits a specific purpose) that is actually a service described in a separate uddiBindingTemplate record. This might happen when a service is remotely hosted (hence the name of this element), or when many service descriptions could benefit from a single service description. 🫧
The uddiHostingRedirector element has a single attribute and no element content. The attribute is a uddiBindingKey value that is suitable within the same UDDI registry instance for querying and obtaining the uddiBindingDetail data that is to be used. 🎀
More on the uddiHostingRedirector can be found in the appendices for the UDDI Version 2.0 API Specification [UDDIapi] 📖
Required element if uddiAccessPoint is not provided: This element is adorned with a uddiBindingKey attribute, giving the redirected reference to a different uddiBindingTemplate. If you query a uddiBindingTemplate and find a uddiHostingRedirector value, you should retrieve that uddiBindingTemplate and use it in place of the one containing the uddiHostingRedirector data. 👀
( 1.3.6.1.1.10.4.20 NAME 'uddiHostingRedirector'
DESC 'designates a pointer to another bindingTemplate'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)With UDDIv3, the hostingRedirector is a deprecated element, since its functionality is now covered by the accessPoint. For backward-compatibility, it can still be used, but it is not recommended. 🥀
4.21. uddiInstanceDescription 🌼
This is an optional repeating element. It's one or more language-qualified text descriptions that designate what role a uddiTModel reference plays in the overall service description. 🗣️
( 1.3.6.1.1.10.4.21 NAME 'uddiInstanceDescription'
DESC 'instance details description'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)The xml:lang value precedes the name value, with the "#" character used as the separator. 🌈
4.22. uddiInstanceParms ⚙️
The uddiInstanceParms is an optional element of the uddiInstance. It's used to contain settings parameters, or a URL reference to a file that contains settings or parameters required to use a specific facet of a uddiBindingTemplate description. If used to house the parameters themselves, the suggested content is a namespace-qualified XML string using a namespace outside of the UDDI schema. If used to house a URL pointer to a file, the suggested format is a URL that is suitable for retrieving the settings or parameters via HTTP-GET. 🧁
( 1.3.6.1.1.10.4.22 NAME 'uddiInstanceParms'
DESC 'URL reference to required settings'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)4.23. uddiOverviewDescription 📝
This is an optional repeating element. This language-qualified string is intended to hold a short descriptive overview of how a particular uddiTModel is to be used. 💖
( 1.3.6.1.1.10.4.23 NAME 'uddiOverviewDescription'
DESC 'outlines tModel usage'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)The xml:lang value precedes the name value, with the "#" character used as the separator. 🫶
4.24. uddiOverviewURL 🔗
okay so this one is optional 🫶 no pressure! it's a string that holds a URL pointing to a long-form overview doc, the big explainer for how a particular uddiTModel reference fits into a whole Web service description ✨. the recommended format is a URI you can grab with an HTTP-GET, so literally just open it in a web browser and it pops right up 💖
( 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 🦋 so one InstanceDetail element can hold multiple OverviewDocs. it's giving growth arc 🌈
Modeling multiple OverviewDocs within an InstanceDetail element:
okay this part is the main character moment 👑. in UDDIv3, the InstanceDetails element in TmodelInstanceInfo can have multiple OverviewDoc's. in UDDIv2, we could only have 1 OverviewDoc 💀. to keep the grouping between a set of overviewDescriptions and overviewURL, we make both OverviewDoc and OverviewURL multi-valued, and each value gets a "group ID" prefix (that's how we know which descriptions and URLs belong together 🧚).
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#overviewDescription1so reading that 🎀: OverviewDoc1 has 3 overview descriptions and an overviewURL. OverviewDoc2 has only an overviewURL. OverviewDoc3 has only 2 overviewDescriptions. OverviewDoc4 has 1 overview description and an overviewURL too. the prefixes do all the work, bestie 🙌
4.25. uddiFromKey 💜
the uddiFromKey is a required element. this is the unique key reference to the first uddiBusinessEntity the assertion is made for 💅.
( 1.3.6.1.1.10.4.25 NAME 'uddiFromKey'
DESC 'unique businessEntity key reference'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)4.26. uddiToKey 🍓
the uddiToKey is a required element too 🫶. this is the unique key reference to the second uddiBusinessEntity the assertion is made for. it's the other half of the pair, so iconic 👯♀️
( 1.3.6.1.1.10.4.26 NAME 'uddiToKey'
DESC 'unique businessEntity key reference'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)4.27. uddiUUID 🌸
the uddiUUID is a required element, and its whole job is making sure uddiContact, uddiAddress, and uddiPublisherAssertion objects each get unique identification 🔥.
( 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 also gets used for unique identification of Subscription-feature-related entities ✨
4.28. uddiIsHidden 🙈
this one is used for the delete_tModel operation 🗑️. logical deletion hides the deleted tModels from find_tModel result sets, but it does NOT physically delete them. so they're gone from view, but still there, like an ex's photos in your camera roll 💀
( 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 UDDIv3, this attribute represents the "deleted" attribute value 🎀.
4.29. uddiIsProjection 🧚
this is used to identify a Business Service that has a Service Projection. it's like a little flag that says "hey, I'm a projection" 🦋.
( 1.3.6.1.1.10.4.29 NAME 'uddiIsProjection'
DESC 'isServiceProjection attribute'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE
)4.30. uddiLang 🌈
this is used to model the xml:lang value for the Address structure in UDDIv3 💖.
( 1.3.6.1.1.10.4.30 NAME 'uddiLang'
DESC 'xml:lang value in v3 Address structure'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)okay so the next bunch of attribute definitions are the new elements and fields UDDIv3 added to the information model 🍓. they all carry the "uddiv3" prefix, which is how you know they're UDDIv3-only and not the v2 vibes 👑.
4.31. uddiv3BusinessKey 🔑
this is the unique UDDIv3 identifier for a given instance of uddiBusinessEntity. it's used in uddiBusinessEntity and uddiBusinessService 💅.
a uddiBusinessEntity will include the uddiBusinessKey (the v2 form) so UDDIv2 clients can uniquely identify it 🫶. the uddiBusinessKey (36-char) is also the LDAP naming attribute for the uddiBusinessEntity. the uddiBusinessEntity entry MAY also include the uddiv3BusinessKey, the explicit v3 form key, which can be 255 characters long ✨.
( 1.3.6.1.1.10.4.31 NAME 'uddiv3BusinessKey'
DESC 'UDDIv3 businessEntity unique identifier'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)4.32. uddiv3ServiceKey 🛠️
this is the unique UDDIv3 identifier for a given instance of uddiBusinessService. it's used in uddiBusinessService and uddiBindingTemplate 🎀.
a uddiBusinessService will include the uddiServiceKey (the v2 form) for unique identification by UDDIv2 clients. the uddiServiceKey (36-char) is also the LDAP naming attribute for the uddiBusinessService entry. the uddiBusinessService entry MAY also include the uddiv3ServiceKey, the explicit v3 form key, which can be 255 characters long 🌸.
( 1.3.6.1.1.10.4.32 NAME 'uddiv3ServiceKey'
DESC 'UDDIv3 businessService unique identifier'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)4.33. uddiv3BindingKey 🦋
this is the unique UDDIv3 identifier for a given instance of uddiBindingTemplate 💖.
a uddiBindingTemplate will include the uddiBindingKey (the v2 form) for unique identification by UDDIv2 clients. the uddiBindingKey (36-char) is also the LDAP naming attribute for the uddiBindingTemplate entry. the uddiBindingTemplate entry MAY also include the uddiv3BindingKey, the explicit v3 form key, which can be 255 characters long 🧚.
( 1.3.6.1.1.10.4.33 NAME 'uddiv3BindingKey'
DESC 'UDDIv3 BindingTemplate unique identifier'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)4.34. uddiv3TModelKey 🧩
this is the unique UDDIv3 identifier for a given instance of a uddiTModel 🌈.
a uddiTModel will include the uddiTModelKey (the v2 form) for unique identification by UDDIv2 clients. the uddiTModelKey (41-char) is also the LDAP naming attribute for the uddiTModel entry. the uddiTModel entry MAY also include the uddiv3TModelKey, the explicit v3 form key, which can be 255 characters long 👑.
( 1.3.6.1.1.10.4.34 NAME 'uddiv3TModelKey'
DESC 'UDDIv3 TModel unique identifier'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)the tModelKey also shows up in a KeyedReference and in Address structures 🙌. wherever a tModelKey is used as a reference to a tModel, the v3 form (aka uddiv3TModelKey) is the one that gets used. why? because using the v2 form means the UDDI Server has to translate it to the v3 key, and that can invalidate the digital signature of the entity 😭. so the v3 form is the move 💅.
4.35. uddiv3DigitalSignature ✍️
the UDDIv3 v3 schema supports signing the following UDDI elements using "XML-Signature Syntax and Processing" (see http://www.w3.org/TR/xmldsig-core/) 🔐:
..businessEntity
..businessService
..bindingTemplate
..tModel
..publisherAssertionthis uddiv3DigitalSignature attribute holds the digital signature for the corresponding UDDI entity 🎀.
( 1.3.6.1.1.10.4.35 NAME 'uddiv3DigitalSignature'
DESC 'UDDIv3 entity digital signature'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)a Signature element SHOULD be generated according to the required steps of "Core Generation" in XML-Signature Syntax and Processing 💫. the signature should be calculated on the top-level element that the registry will store as a result of the Publication API call. this element is the "data object" in the XML-Signature and Syntax specification. it's the businessEntity element for save_business API calls, the businessService element for save_service API calls, the bindingTemplate for save_binding API calls, the tModel for save_tModel API calls, and the publisherAssertion for set_publisherAssertions and add_publisherAssertion API calls 🧾.
the signature should be generated on the elements before they get 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 signature unless they're first excluded by a transform 🌸. because service projections are contained as businessService elements inside a businessEntity element, changing the projected service will make the signature of the businessEntity containing the projection invalid 😭, unless a businessService element representing a service projection is excluded using a transform. so yes, be careful 🙈.
due to where the sequence of Signature elements sits inside the element being signed, the signature is "enveloped" 🫧. because of that enveloping, it's necessary to apply at least one transformation on the signed entity to exclude the signature or signatures. the transformation is chosen by a publisher or the XML-Signature tool, and it's specified in a Transform element inside the Signature element 🔥.
4.36. uddiv3NodeId 🪪
this attribute contains the Node Identity for a UDDIv3 node 💜.
( 1.3.6.1.1.10.4.36 NAME 'uddiv3NodeId'
DESC 'UDDIv3 Node Identifier'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)4.37. uddiv3EntityModificationTime ⏰
this attribute keeps track of the last modification time for a UDDI entity 🕰️. it's needed for maintaining the modifiedIncludingChildren element. here's the tea ☕: when a child entity (like a uddiBindingTemplate) gets updated, the parent entity's (like a uddiBusinessService) LDAP timestamp also gets updated. so the uddiv3EntityModificationTime attribute saves the last modification time of the parent entity (uddiBusinessService in this case) 🫶.
( 1.3.6.1.1.10.4.37 NAME 'uddiv3EntityModificationTime'
DESC 'UDDIv3 Last Modified Time for Entity'
EQUALITY generalizedTimeMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE
)the next attribute definitions model UDDIv3 subscription-related entities in the LDAP directory 🔔. subscription gives clients, known as subscribers, a way to register their interest in getting info about changes made in a UDDI registry 👀. those changes can be scoped based on preferences sent with the request. the uddiv3Subscription object class is used to model registered UDDIv3 subscriptions 🦋.
4.38. uddiv3SubscriptionKey ✨
okay so this one is the unique UDDIv3 ID for each individual uddiv3Subscription entity 🔑 every subscription gets its own key, bestie, no sharing 💅
( 1.3.6.1.1.10.4.38 NAME 'uddiv3SubscriptionKey'
DESC 'UDDIv3 Subscription unique identifier'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)4.39. uddiv3SubscriptionFilter 🧚
this attribute holds the UDDIv3 Subscription Filter, which gets set up as part of the save_subscription API 🎀 so basically it's the Inquiry API used as the filtering criteria for a registered subscription. the filter limits the scope of a subscription to a subset of registry records, so you're only getting the tea you actually asked for ☕ the get_xx and find_xx APIs are all valid picks for a subscriptionFilter, but only ONE of them can be chosen per subscription, so pick wisely bestie 🫶
( 1.3.6.1.1.10.4.39 NAME 'uddiv3SubscriptionFilter'
DESC 'UDDIv3 Subscription Filter'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)4.40. uddiv3NotificationInterval ⏰
this one stores the Notification Interval string 🕰️ it's an xsd:duration, and it says how often the Asynchronous change notifications get sent over to a subscriber. so it's basically the "how often do you ping me" setting, iykyk 🔔
( 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. uddiv3MaxEntities 🍓
this attribute is the maximum number of entities that can come back in a subscription notification 📦 it's an integer, and it caps how many entities show up in a notification sent to a subscription listener. no overstuffing the group chat 😭
( 1.3.6.1.1.10.4.41 NAME 'uddiv3MaxEntities'
DESC 'UDDIv3 Subscription maxEntities field'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)4.42. uddiv3ExpiresAfter ⌛
this one specifies the Expiry Time for a subscription 💀 it's the XML Schema type xsd:dateTime, so the subscription has a real end date, no ghosting allowed 🌙
( 1.3.6.1.1.10.4.42 NAME 'uddiv3ExpiresAfter'
DESC 'UDDIv3 Subscription ExpiresAfter field'
EQUALITY generalizedTimeMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE
)4.43. uddiv3BriefResponse 🌸
this is a Boolean flag for Brief Response on a subscription entity 🎚️ it controls how much detail the subscription listener gets back. the default is "false" when it's omitted. when it's set to "true", the subscription results come back to the subscriber as a keyBag, which lists every entity that matched the subscriptionFilter. short and sweet, like your replies 💅
( 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. uddiv3EntityKey 🪦
this is the unique UDDIv3 ID for a core UDDI data structure that gets logged as an Obituary entry (uddiv3EntityObituary) 🕊️ so when a core UDDIv3 Entity gets deleted and there's still an active subscription registered against it, an Obituary entry is made, and the v3 key of the deleted entry gets logged as part of the uddiv3EntityKey attribute. rest in peace, little entity 🥀
( 1.3.6.1.1.10.4.44 NAME 'uddiv3EntityKey'
DESC 'UDDIv3 Entity unique identifier'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)4.45. uddiv3EntityCreationTime 🕰️
this attribute logs the original Creation Time for a UDDI Entity that gets deleted, and it's stored in the uddiv3EntityObituary entry 📝
it also shows up in uddiBusinessService and uddiBindingTemplate 🔁 here's the lowkey tricky part: a Move BS operation has to delete and recreate the BT sub-tree, because a lot of LDAPv3 servers don't support moving a sub-tree 🙃 so this attribute is how the original creation time of the BT gets saved during a Move BS. it's giving "keep your receipts" energy ✨
( 1.3.6.1.1.10.4.45 NAME 'uddiv3EntityCreationTime'
DESC 'UDDIv3 Entity Creation Time'
EQUALITY generalizedTimeMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE
)4.46. uddiv3EntityDeletionTime 🥀
this one logs the entity deletion time for a UDDI Entity that's been deleted, and it lives in the uddiv3EntityObituary entry ⚰️ the exact moment it got yeeted, recorded for history 📅
( 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
)5. Object Class Definitions 👑
the OIDs for the object classes in this document have been registered by the IANA 📋 so they're official, bestie 🫶
5.1. uddiBusinessEntity 🏢
this structural object class represents a businessEntity 💼
( 1.3.6.1.1.10.6.1 NAME 'uddiBusinessEntity'
SUP top
STRUCTURAL
MUST ( uddiBusinessKey $
uddiName)
MAY ( uddiAuthorizedName $
uddiOperator $
uddiDiscoveryURLs $
uddiDescription $
uddiIdentifierBag $
uddiCategoryBag $
uddiv3BusinessKey $
uddiv3DigitalSignature $
uddiv3EntityModificationTime $
uddiv3NodeId)
)5.2. uddiContact 📇
this structural object class represents a contact, and it gets contained by a uddiBusinessEntity 🤙
( 1.3.6.1.1.10.6.2 NAME 'uddiContact'
SUP top
STRUCTURAL
MUST ( uddiPersonName $
uddiUUID )
MAY ( uddiUseType $
uddiDescription $
uddiPhone $
uddiEMail )
)5.3. uddiAddress 📍
this structural object class represents an address, and it's contained by a uddiContact 🏡
( 1.3.6.1.1.10.6.3 NAME 'uddiAddress'
SUP top
STRUCTURAL
MUST ( uddiUUID )
MAY ( uddiUseType $
uddiSortCode $
uddiTModelKey $
uddiv3TmodelKey $
uddiAddressLine $
uddiLang)
)5.4. uddiBusinessService 🛎️
this structural object class represents a businessService ✨
( 1.3.6.1.1.10.6.4 NAME 'uddiBusinessService'
SUP top
STRUCTURAL
MUST ( uddiServiceKey )
MAY ( uddiName $
uddiBusinessKey $
uddiDescription $
uddiCategoryBag $
uddiIsProjection $
uddiv3ServiceKey $
uddiv3BusinessKey $
uddiv3DigitalSignature $
uddiv3EntityCreationTime $
uddiv3EntityModificationTime $
uddiv3NodeId)
)5.5. uddiBindingTemplate 🔗
this structural object class represents a bindingTemplate 💅
( 1.3.6.1.1.10.6.5 NAME 'uddiBindingTemplate'
SUP top
STRUCTURAL
MUST ( uddiBindingKey )
MAY ( uddiServiceKey $
uddiDescription $
uddiAccessPoint $
uddiHostingRedirector
uddiCategoryBag $
uddiv3BindingKey $
uddiv3ServiceKey $
uddiv3DigitalSignature $
uddiv3EntityCreationTime $
uddiv3NodeId)
)5.6. uddiTModelInstanceInfo 🧩
this structural object class represents a tModelInstanceInfo, and it's contained by a uddiBindingTemplate 🎁
( 1.3.6.1.1.10.6.6 NAME 'uddiTModelInstanceInfo'
SUP top
STRUCTURAL
MUST ( uddiTModelKey )
MAY ( uddiDescription $
uddiInstanceDescription $
uddiInstanceParms $
uddiOverviewDescription $
uddiOverviewURL $
uddiv3TmodelKey)
)5.7. uddiTModel 🎨
this structural object class represents a tModel 🌈
( 1.3.6.1.1.10.6.7 NAME 'uddiTModel'
SUP top
STRUCTURAL
MUST ( uddiTModelKey $
uddiName )
MAY ( uddiAuthorizedName $
uddiOperator $
uddiDescription $
uddiOverviewDescription $
uddiOverviewURL $
uddiIdentifierBag $
uddiCategoryBag $
uddiIsHidden
uddiv3TModelKey $
uddiv3DigitalSignature $
uddiv3NodeId)
)5.8. uddiPublisherAssertion 🤝
this structural object class represents a publisherAssertion 💌
( 1.3.6.1.1.10.6.8 NAME 'uddiPublisherAssertion'
SUP top
STRUCTURAL
MUST ( uddiFromKey $
uddiToKey $
uddiKeyedReference $
uddiUUID )
MAY ( uddiv3DigitalSignature $
uddiv3NodeId)
)The following are object class definitions that model new data structures needed to implement the UDDIv3 information model 🧠 these object class definitions have the "uddiv3" prefix, which signals that these attributes are UDDI information model elements unique to UDDIv3 🦋
5.9. uddiv3Subscription 🔔
this structural object class represents a Subscription entity 📬
( 1.3.6.1.1.10.6.9 NAME 'uddiv3Subscription'
SUP top
STRUCTURAL
MUST ( uddiv3SubscriptionFilter $
uddiUUID)
MAY ( uddiAuthorizedName $
uddiv3SubscriptionKey $
uddiv3BindingKey $
uddiv3NotificationInterval $
uddiv3MaxEntities $
uddiv3ExpiresAfter $
uddiv3BriefResponse $
uddiv3NodeId)
)5.10. uddiv3EntityObituary 🕯️
this structural object class represents an Obituary entry, and it stores obituary information for deleted UDDIv3 entities that's needed for handling subscriptions 🪦 it's the memorial wall for entities that have left the building 🫡
( 1.3.6.1.1.10.6.10 NAME 'uddiv3EntityObituary'
SUP top
STRUCTURAL
MUST ( uddiv3EntityKey $
uddiUUID)
MAY ( uddiAuthorizedName $
uddiv3EntityCreationTime $
uddiv3EntityDeletionTime $
uddiv3NodeId)
)6. Name Forms 🎀
this section defines the required hierarchical structure rules and naming attributes for the object classes defined in Section 6 🌳
the OIDs for the structure rules in this document have been registered by the IANA 📋
6.1. uddiBusinessEntityNameForm 🏷️
this name form defines the naming attribute for a businessEntity 💼
( 1.3.6.1.1.10.15.1 NAME 'uddiBusinessEntityNameForm'
OC uddiBusinessEntity
MUST ( uddiBusinessKey )
)6.2. uddiContactNameForm 📇
this name form defines the naming attribute for a contact 🤙
( 1.3.6.1.1.10.15.2 NAME 'uddiContactNameForm'
OC uddiContact
MUST ( uddiUUID )
)6.3. uddiAddressNameForm 📍
this name form defines the naming attribute for an address 🏡
( 1.3.6.1.1.10.15.3 NAME 'uddiAddressNameForm'
OC uddiAddress
MUST ( uddiUUID )
)6.4. uddiBusinessServiceNameForm 🛎️
this name form defines the naming attribute for a businessService ✨
( 1.3.6.1.1.10.15.4 NAME 'uddiBusinessServiceNameForm'
OC uddiBusinessService
MUST ( uddiServiceKey )
)6.5. uddiBindingTemplateNameForm 🔗
this name form defines the naming attribute for a bindingTemplate 💅
( 1.3.6.1.1.10.15.5 NAME 'uddiBindingTemplateNameForm'
OC uddiBindingTemplate
MUST ( uddiBindingKey )
)6.6. uddiTModelInstanceInfoNameForm 🧩
this name form defines the naming attribute for a tModelInstanceInfo 🎁
( 1.3.6.1.1.10.15.6 NAME 'uddiTModelInstanceInfoNameForm'
OC uddiTModelInstanceInfo
MUST ( uddiTModelKey )
)6.7. uddiTModelNameForm 🎨
this name form defines the naming attribute for a tModel 🌈
( 1.3.6.1.1.10.15.7 NAME 'uddiTModelNameForm'
OC uddiTModel
MUST ( uddiTModelKey )
)6.8. uddiPublisherAssertionNameForm ✨
okay so this name form is the naming attribute for a publisherAssertion 🦋 it's literally the naming rule that says how these entries get their name, and it's giving very specific energy:
( 1.3.6.1.1.10.15.8 NAME 'uddiPublisherAssertionNameForm'
OC uddiPublisherAssertion
MUST ( uddiUUID )
)6.9. uddiv3SubscriptionNameForm 🔥
this one is the naming attribute for a Subscription, so it's the naming rule for subscriptions. same vibe as the last one, just a different main character 💅
( 1.3.6.1.1.10.15.9 NAME 'uddiv3SubscriptionNameForm'
OC uddiv3Subscription
MUST ( uddiUUID )
)6.10. uddiv3EntityObituaryNameForm 💀
and last but definitely not least, the naming attribute for an Entity Obituary. yes it's a whole thing, and yes it's named like this 😭
( 1.3.6.1.1.10.15.10 NAME 'uddiv3EntityObituaryNameForm'
OC uddiv3EntityObituary
MUST ( uddiUUID )
)7. DIT Structure Rules 🧚
okay this section is all about the required hierarchical structure rules for the object classes we just met in Section 6 🌸 the rule identifiers here show how the structure rules relate to each other. you can use different identifiers in your own implementation, but it has to follow the same hierarchy model 🫶
7.1. uddiBusinessEntityStructureRule 🍓
the root of the whole family tree, no notes needed 👑
( 1
NAME 'uddiBusinessEntityStructureRule'
FORM uddiBusinessEntityNameForm
)7.2. uddiContactStructureRule 💜
this one defines the object class containment for a contact. it sits under rule 1, so it's a total child of the business entity 🥰
( 2
NAME 'uddiContactStructureRule'
FORM uddiContactNameForm
SUP ( 1 )
)7.3. uddiAddressStructureRule 🎀
this is the containment rule for an address, and it sits under the contact rule (rule 2) ✨
( 3
NAME 'uddiAddressStructureRule'
FORM uddiAddressNameForm
SUP ( 2 )
)7.4. uddiBusinessServiceStructureRule 🌈
this defines the object class containment for a businessService, and it's a direct child of rule 1 🫶
( 4
NAME 'uddiBusinessServiceStructureRule'
FORM uddiBusinessServiceNameForm
SUP ( 1 )
)7.5. uddiBindingTemplateStructureRule 🦋
the containment rule for a bindingTemplate, which sits under the businessService rule (rule 4) 💅
( 5
NAME 'uddiBindingTemplateStructureRule'
FORM uddiBindingTemplateNameForm
SUP ( 4 )
)7.6. uddiTModelInstanceInfoStructureRule 🧚
this defines the object class containment for a tModelInstanceInfo, which sits under the bindingTemplate rule (rule 5) 🌸
( 6
NAME 'uddiTModelInstanceInfoStructureRule'
FORM uddiTModelInstanceInfoNameForm
SUP ( 5 )
)7.7. uddiTModelStructureRule 👑
this one is its own thing and doesn't have a SUP line. it's the rule for a tModel, and it's ranked as rule 7 ✨
( 7
NAME 'uddiTModelStructureRule'
FORM uddiTModelNameForm
)7.8. uddiPublisherAssertion 🍓
this one's heading in the original is just "uddiPublisherAssertion", but the rule itself is named uddiPublisherAssertionStructureRule, so don't get confused, bestie 🙈 it's rule 8 and it doesn't have a SUP line either
( 8
NAME 'uddiPublisherAssertionStructureRule'
FORM uddiPublisherAssertionNameForm
)7.9. uddiv3SubscriptionStructureRule 💜
rule 9 is the structure rule for subscriptions, and it uses the subscription name form we met back in 6.9 🔥
( 9
NAME 'uddiv3SubscriptionStructureRule'
FORM uddiv3SubscriptionNameForm
)7.10. uddiv3EntityObituaryStructureRule 🥀
last rule, rule 10 🎀 this is the structure rule for entity obituaries, and it uses the obituary name form from 6.10 💀
( 10
NAME 'uddiv3EntityObituaryStructureRule'
FORM uddiv3EntityObituaryNameForm
)8. Security Considerations 🔐
okay bestie, this part is SERIOUS, so read it carefully 😭 storing UDDI data in the directory means that data can be looked at and used outside the environment it was originally made in. the directory entry holding the UDDI data could be read and changed too, but only within the limits of the directory's access control mechanisms 🛡️ with UDDIv3 [UDDIv3], publishers can digitally sign UDDI Entities, and that lets registry clients check that entries they read from the UDDIv3 registry haven't been tampered with by verifying the digital signature ✨
every UDDI Entity has a uddiAuthorizedName attribute, and it holds an LDAP DN that identifies the publisher or owner 🫶 the LDAP object it points to can give a registry client the signer's public key, so the client can check that the UDDI Entity is intact 🔑
other general LDAP [LDAPv3] security considerations still apply, so don't skip those 🙈 some UDDI attributes, like AccessPoints for services, might hold sensitive information. so strong authentication mechanisms and data integrity/confidentiality services [RFC2829][RFC2830] are advised. no cap, this is the kind of thing you don't want to ignore 🔥
9. IANA Considerations 🌸
for this one, just refer to RFC 3383, "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)" [RFC3383] 🦋
9.1. Object Identifier Registration 🧚
IANA has registered an LDAP Object Identifier for this technical specification. the request went in using the following template 💅
Subject: Request for LDAP OID Registration
Person & email address to contact for further information:
Bruce Bergeson (bruce.bergeson@novell.com)
Specification: RFC 4403
Author/Change Controller: IESG
Comments:
The assigned OID (10) will be used as a base for identifying
a number of UDDI schema elements defined in this document.9.2. Object Identifier Descriptors 👑
IANA has also registered the LDAP Descriptors used in this technical specification. the request template looks like this 🥰
Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see table
Object Identifier: see table
Person & email address to contact for further information:
Bruce Bergeson (bruce.bergeson@novell.com)
Usage: see table
Specification: RFC 4403
Author/Change Controller: IESG
Table:the following descriptors have been added. the table is wild, so here it is in full ✨
NAME Type OID
-------------- ---- ------------
uddiBusinessKey A 1.3.6.1.1.10.4.1
uddiAuthorizedName A 1.3.6.1.1.10.4.2
uddiOperator A 1.3.6.1.1.10.4.3
uddiName A 1.3.6.1.1.10.4.4
uddiDescription A 1.3.6.1.1.10.4.5
uddiDiscoveryURLs A 1.3.6.1.1.10.4.6
uddiUseType A 1.3.6.1.1.10.4.7
uddiPersonName A 1.3.6.1.1.10.4.8
uddiPhone A 1.3.6.1.1.10.4.9
uddiEMail A 1.3.6.1.1.10.4.10
uddiSortCode A 1.3.6.1.1.10.4.11
uddiTModelKey A 1.3.6.1.1.10.4.12
uddiAddressLine A 1.3.6.1.1.10.4.13
NAME Type OID
-------------- ---- ------------
uddiIdentifierBag A 1.3.6.1.1.10.4.14
uddiCategoryBag A 1.3.6.1.1.10.4.15
uddiKeyedReference A 1.3.6.1.1.10.4.16
uddiServiceKey A 1.3.6.1.1.10.4.17
uddiBindingKey A 1.3.6.1.1.10.4.18
uddiAccessPoint A 1.3.6.1.1.10.4.19
uddiHostingRedirector A 1.3.6.1.1.10.4.20
uddiInstanceDescription A 1.3.6.1.1.10.4.21
uddiInstanceParms A 1.3.6.1.1.10.4.22
uddiOverviewDescription A 1.3.6.1.1.10.4.23
uddiOverviewURL A 1.3.6.1.1.10.4.24
uddiFromKey A 1.3.6.1.1.10.4.25
uddiToKey A 1.3.6.1.1.10.4.26
uddiUUID A 1.3.6.1.1.10.4.27
uddiIsHidden A 1.3.6.1.1.10.4.28
uddiIsProjection A 1.3.6.1.1.10.4.29
uddiLang A 1.3.6.1.1.10.4.30
uddiv3BusinessKey A 1.3.6.1.1.10.4.31
uddiv3ServiceKey A 1.3.6.1.1.10.4.32
uddiv3BindingKey A 1.3.6.1.1.10.4.33
uddiv3TmodelKey A 1.3.6.1.1.10.4.34
uddiv3DigitalSignature A 1.3.6.1.1.10.4.35
uddiv3NodeId A 1.3.6.1.1.10.4.36
uddiv3EntityModificationTime A 1.3.6.1.1.10.4.37
uddiv3SubscriptionKey A 1.3.6.1.1.10.4.38
uddiv3SubscriptionFilter A 1.3.6.1.1.10.4.39
uddiv3NotificationInterval A 1.3.6.1.1.10.4.40
uddiv3MaxEntities A 1.3.6.1.1.10.4.41
uddiv3ExpiresAfter A 1.3.6.1.1.10.4.42
uddiv3BriefResponse A 1.3.6.1.1.10.4.43
uddiv3EntityKey A 1.3.6.1.1.10.4.44
uddiv3EntityCreationTime A 1.3.6.1.1.10.4.45
uddiv3EntityDeletionTime A 1.3.6.1.1.10.4.46
uddiBusinessEntity O 1.3.6.1.1.10.6.1
uddiContact O 1.3.6.1.1.10.6.2
uddiAddress O 1.3.6.1.1.10.6.3
uddiBusinessService O 1.3.6.1.1.10.6.4
uddiBindingTemplate O 1.3.6.1.1.10.6.5
uddiTModelInstanceInfo O 1.3.6.1.1.10.6.6
uddiTModel O 1.3.6.1.1.10.6.7
uddiPublisherAssertion O 1.3.6.1.1.10.6.8
uddiv3Subscription O 1.3.6.1.1.10.6.9
uddiv3EntityObituary O 1.3.6.1.1.10.6.10
uddiBusinessEntityNameForm N 1.3.6.1.1.10.15.1
uddiContactNameForm N 1.3.6.1.1.10.15.2
uddiAddressNameForm N 1.3.6.1.1.10.15.3
NAME Type OID
-------------- ---- ------------
uddiBusinessServiceNameForm N 1.3.6.1.1.10.15.4
uddiBindingTemplateNameForm N 1.3.6.1.1.10.15.5
uddiTModelInstanceInfoNameForm N 1.3.6.1.1.10.15.6
uddiTModelNameForm N 1.3.6.1.1.10.15.7
uddiPublisherAssertionNameForm N 1.3.6.1.1.10.15.8
uddiv3SubscriptionNameForm N 1.3.6.1.1.10.15.9
uddiv3EntityObituaryNameForm N 1.3.6.1.1.10.15.10here's the key for the table: Type A is Attribute, Type O is ObjectClass, and Type N is NameForm 🎀
these assignments have been recorded in the registry at http://www.iana.org/assignments/ldap-parameters 🌈
10. Normative References 📚
these are the references the spec leans on, so here's the full list, no skipping 💖
- [LDAPv3] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
- [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
- [UDDIdsr] UDDI.ORG, "UDDI version 2.03 Data Structure Reference,"
http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm - [UDDIapi] "UDDI Version 2.04 API Specification",
http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm - [UDDIv3] UDDI Version 3.0, Published Specification, 19 July 2002
http://uddi.org/pubs/uddi-v3.00-published-20020719.htm - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan, "Authentication Methods for LDAP", RFC 2829, May 2000.
- [RFC2830] Hodges, J., Morgan, R., and M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000.
- [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
- [XML] Extensible Markup Language (XML) 1.0 (Second Edition) W3C Recommendation 6 October 2000
http://www.w3.org/TR/REC-xml - [URL] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
- [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
Authors' Addresses ✨
okay bestie, the authors are three legends who wrote this whole thing 💅 here's where to find them:
Bruce Bergeson
Novell, Inc.
1800 S Novell Place
Provo, UT 84606
Phone: +1 801 861 3854
EMail: bruce.bergeson@novell.com
Kent Boogert
Novell, Inc.
1800 S Novell Place
Provo, UT 84606
Phone: +1 801 861 3212
EMail: kent.boogert@novell.com
Vijay Nanjundaswamy
Oracle India Pvt. Ltd.
Lexington Towers, Prestige St. John's Woods
#18, 2nd Cross Road,
Chikka Audugodi,
Bangalore 560029
India
Phone: +11 9180 4108 5000
EMail: vijay.nanjundaswamy@oracle.comFull Copyright Statement 🎀
ngl this part is the legal stuff, but it's giving important 🙈 the Internet Society holds the copyright on this document (2006), and it's covered by the rights, licenses and restrictions in BCP 78. Past that, the authors keep all their own rights 💜
The document and everything in it is provided on an "AS IS" basis. THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🦋
the IETF doesn't take a side on whether any IPR claims over this tech are valid or how far they reach, and it doesn't claim to have done its own digging to find any of them 🫣 if you want the rules on rights in RFCs, look in BCP 78 and BCP 79 🔥
copies of IPR disclosures that were sent to the IETF Secretariat live in the IETF online IPR repository, along with any licence assurances, or the results of trying to get a general licence or permission for implementers and users to use those proprietary rights. you can find it at http://www.ietf.org/ipr 🌸
and the IETF invites anyone to flag copyrights, patents, patent applications, or other proprietary rights that could cover tech needed to implement this standard. send that info to ietf-ipr@ietf.org 💌
Acknowledgement 🫶
funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). thank you to the people keeping the lights on ✨
📦 where this page comes from
- ietf: rfc4403 2006-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms