external/bsd/openldap/dist/doc/rfc/rfc4403.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                        B. Bergeson
   8 Request for Comments: 4403                                    K. Boogert
   9 Category: Informational                                     Novell, Inc.
  10                                                         V. Nanjundaswamy
  11                                                   Oracle India Pvt. Ltd.
  12                                                            February 2006
  13
  14
  15         Lightweight Directory Access Protocol (LDAP) Schema for
  16   Universal Description, Discovery, and Integration version 3 (UDDIv3)
  17
  18 Status of This Memo
  19
  20    This memo provides information for the Internet community.  It does
  21    not specify an Internet standard of any kind.  Distribution of this
  22    memo is unlimited.
  23
  24 Copyright Notice
  25
  26    Copyright (C) The Internet Society (2006).
  27
  28 Abstract
  29
  30    This document defines the Lightweight Directory Access Protocol
  31    (LDAPv3) schema for representing Universal Description, Discovery,
  32    and Integration (UDDI) data types in an LDAP directory.  It defines
  33    the LDAP object class and attribute definitions and containment rules
  34    to model UDDI entities, defined in the UDDI version 3 information
  35    model, in an LDAPv3-compliant directory.
  36
  37 Table of Contents
  38
  39    1. Introduction ....................................................2
  40    2. Conventions Used in This Document ...............................2
  41    3. Representation of UDDI Data Structures ..........................2
  42    4. Attribute Type Definitions ......................................6
  43    5. Object Class Definitions .......................................28
  44    6. Name Forms .....................................................32
  45    7. DIT Structure Rules ............................................35
  46    8. Security Considerations ........................................37
  47    9. IANA Considerations ............................................37
  48    10. Normative References ..........................................40
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58 Bergeson, et al.             Informational                      [Page 1]
  59 \f
  60 RFC 4403                 LDAP Schema for UDDIv3            February 2006
  61
  62
  63 1.  Introduction
  64
  65    This document defines the Lightweight Directory Access Protocol
  66    [LDAPv3] schema elements to represent the core data structures
  67    identified in the Universal Description, Discovery, and Integration
  68    version 3 [UDDIv3] information model.  This includes a
  69    businessEntity, a businessService, a bindingTemplate, a tModel, a
  70    publisherAssertion, and a Subscription.  Portions of [UDDIv3] are
  71    repeated here for clarity.
  72
  73 2.  Conventions Used in This Document
  74
  75    The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  76    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  77    document are to be interpreted as described in RFC 2119 [RFC2119].
  78
  79    All schema definitions are provided using [RFC2252] descriptions, and
  80    are line-wrapped for readability only.
  81
  82 3.  Representation of UDDI Data Structures
  83
  84    The information that makes up a registration in a UDDI registry
  85    consists of these data structure types.  This division by information
  86    type provides simple partitions to assist in the rapid location and
  87    understanding of the different information that makes up a
  88    registration.
  89
  90    The individual instance data managed by a UDDI registry is sensitive
  91    to the parent/child relationships found in the schema.  A
  92    businessEntity object contains one or more unique businessService
  93    objects.  Similarly, individual businessService objects contain
  94    specific instances of bindingTemplate, which in turn contains
  95    information that includes pointers to specific instances of tModel
  96    objects.
  97
  98    It is important to note that no single instance of a core schema type
  99    is ever "contained" by more than one parent instance.  This means
 100    that only one specific businessEntity object (identified by its
 101    unique key value) will ever contain or be used to express information
 102    about a specific instance of a businessService object (also
 103    identified by its own unique key value).
 104
 105 3.1.  businessEntity
 106
 107    The businessEntity object represents all known information about a
 108    business or entity that publishes descriptive information about the
 109    entity as well as the services that it offers.  The businessEntity is
 110    the top-level container that accommodates holding descriptive
 111
 112
 113
 114 Bergeson, et al.             Informational                      [Page 2]
 115 \f
 116 RFC 4403                 LDAP Schema for UDDIv3            February 2006
 117
 118
 119    information about a business or entity.  Service descriptions and
 120    technical information are expressed within a businessEntity by a
 121    containment relationship.
 122
 123 3.1.1.  Representation in the Directory
 124
 125    A businessEntity is represented in the directory by the attributes
 126    uddiBusinessKey, uddiAuthorizedName, uddiOperator, uddiDiscoveryURLs,
 127    uddiName, uddiDescription, uddiIdentifierBag, uddiCategoryBag, and
 128    uddiv3DigitalSignature, along with corresponding v3 keys viz.
 129    uddiv3BusinessKey, as defined in Section 4.  A businessEntity may
 130    contain zero or more instances of uddiContact and
 131    uddiBusinessService.
 132
 133    A mandatory attribute, uddiBusinessKey, contains the unique
 134    identifier for a given instance of a businessEntity.
 135
 136    businessEntity's definition is given in Section 5.
 137
 138 3.2.  businessService
 139
 140    The businessService instances represent a logical business service.
 141    Each businessService object is the logical child of a single
 142    businessEntity object.  Each businessService element contains
 143    descriptive information in business terms outlining the type of
 144    technical services found within each businessService instance.
 145
 146    In some cases, businesses would like to share or reuse services,
 147    e.g., when a large enterprise publishes separate businessEntity
 148    structures.  This can be established by using the businessService
 149    instance as a projection to an already published businessService.
 150
 151 3.2.1.  Representation in the Directory
 152
 153    A businessService is represented in the directory by the attributes
 154    uddiBusinessKey, uddiServiceKey, uddiName, uddiDescription,
 155    uddiCategoryBag, uddiIsProjection, and uddiv3DigitalSignature, along
 156    with corresponding v3 keys viz. uddiv3BusinessKey, and
 157    uddiv3ServiceKey, as defined in Section 4.  A businessService may
 158    contain zero or more instances of uddiBindingTemplate.
 159
 160    The mandatory attribute, uddiServiceKey, contains the unique
 161    identifier for a given instance of a businessService.
 162
 163    businessService's definition is given in Section 5.
 164
 165
 166
 167
 168
 169
 170 Bergeson, et al.             Informational                      [Page 3]
 171 \f
 172 RFC 4403                 LDAP Schema for UDDIv3            February 2006
 173
 174
 175 3.3.  bindingTemplate
 176
 177    Technical descriptions of Web services are accommodated via
 178    individual contained instances of bindingTemplate objects.  These
 179    instances provide support for determining a technical entry point or
 180    optionally support remotely hosted services, as well as a lightweight
 181    facility for describing unique technical characteristics of a given
 182    implementation.  Support for technology and application specific
 183    parameters and settings files are also supported.
 184
 185    Since UDDI's main purpose is to enable description and discovery of
 186    Web service information, it is the bindingTemplate that provides the
 187    most interesting technical data.  With UDDIv3, bindingTemplates also
 188    can have categorization information.
 189
 190    Each bindingTemplate instance has a single logical businessService
 191    parent, which in turn has a single logical businessEntity parent.
 192
 193 3.3.1.  Representation in the Directory
 194
 195    A bindingTemplate is represented in the directory by the attributes
 196    uddiBindingKey, uddiServiceKey, uddiDescription, uddiAccessPoint,
 197    uddiHostingRedirector, uddiCategoryBag, and uddiv3DigitalSignature,
 198    along with corresponding v3 keys viz. uddiv3ServiceKey and
 199    uddiv3BindingKey, as defined in Section 4.  A bindingTemplate may
 200    contain zero or more instances of uddiTModelInstanceDetails.
 201
 202    The mandatory attribute, uddiBindingKey, contains the unique
 203    identifier for a given instance of a bindingTemplate.
 204
 205    BindingTemplate's definition is given in Section 5.
 206
 207 3.4.  tModel
 208
 209    The tModel object takes the form of keyed metadata (data about data).
 210    In a general sense, the purpose of a tModel within the UDDI registry
 211    is to provide a reference system based on abstraction.  Thus, the
 212    kind of data that a tModel represents is pretty nebulous.  In other
 213    words, a tModel registration can define just about anything, but in
 214    the current revision, two conventions have been applied for using
 215    tModels: as sources for determining compatibility and as keyed
 216    namespace references.
 217
 218    The information that makes up a tModel is quite simple.  There are a
 219    key, a name, an optional description, and a Uniform Resource Locator
 220    [URL] that points somewhere--presumably somewhere where the curious
 221    can go to find out more about the actual concept represented by the
 222    metadata in the tModel itself.
 223
 224
 225
 226 Bergeson, et al.             Informational                      [Page 4]
 227 \f
 228 RFC 4403                 LDAP Schema for UDDIv3            February 2006
 229
 230
 231 3.4.1.  Representation in the Directory
 232
 233    A tModel is represented in the directory by the attributes
 234    uddiTModelKey, uddiAuthorizedName, uddiOperator, uddiName,
 235    uddiDescription, uddiOverviewDescription, uddiOverviewURL,
 236    uddiIdentifierBag, uddiCategoryBag, uddiIsHidden, and
 237    uddiv3DigitalSignature, along with the corresponding v3 key viz.
 238    uddiv3tModelKey, as defined in Section 4.  A tModel may also contain
 239    a uddiHidden to logically delete a tModel.
 240
 241    A mandatory attribute, uddiTModelKey, contains the unique identifier
 242    for a given instance of a tModel.
 243
 244    tModel's definition is given in Section 5.
 245
 246 3.5.  publisherAssertion
 247
 248    Many businesses, such as large enterprises or marketplaces, are not
 249    effectively represented by a single businessEntity, since their
 250    description and discovery are likely to be diverse.  As a
 251    consequence, several businessEntity instances can be published,
 252    representing individual subsidiaries of a large enterprise or
 253    individual participants of a marketplace.  Nevertheless, they still
 254    represent a more or less coupled community and would like to make
 255    some of their relationships visible in their UDDI registrations.
 256
 257 3.5.1.  Representation in the Directory
 258
 259    A publisherAssertion is represented in the directory by the
 260    attributes uddiFromKey, uddiToKey, uddiKeyedReference, and uddiUUID,
 261    and uddiv3DigitalSignature, as defined in Section 5.
 262
 263    A mandatory attribute, uddiUUID, contains the unique identifier for a
 264    given instance of a publisherAssertion.
 265
 266    publisherAssertion's definition is given in Section 5.
 267
 268 3.6.  Operational Information:
 269
 270    With UDDIv3, the operational information associated with the core
 271    UDDI data structures is maintained in a separate OperationalInfo
 272    structure, so that the digital signature specified by the publisher
 273    remains valid.
 274
 275    The operationalInfo structure is used to convey the operational
 276    information for the UDDIv3 core data structures, that is, the
 277    businessEntity, businessService, bindingTemplate, and tModel
 278
 279
 280
 281
 282 Bergeson, et al.             Informational                      [Page 5]
 283 \f
 284 RFC 4403                 LDAP Schema for UDDIv3            February 2006
 285
 286
 287    structures.  UDDIv3 OperationalInfo consists of 5 elements: created,
 288    Modified, modifiedIncludingChildren, nodeId, and authorizedName.
 289
 290    Depending on the specific UDDIv3 core data structure, the
 291    operationalInformation is represented in the directory as a
 292    combination of implicit LDAP Standard Operational attributes:
 293    createTimestamp and modifyTimestamp, and the following explicit
 294    attributes: uddiAuthorizedName, uddiv3EntityCreationTime,
 295    uddiv3EntityModificationTime, and uddiv3NodeId.
 296
 297 4.  Attribute Type Definitions
 298
 299    The OIDs for the attribute types in this document have been
 300    registered by the IANA.
 301
 302 4.1.  uddiBusinessKey
 303
 304    This is used in uddiBusinessEntity and uddiBusinessService.
 305
 306    The uddiBusinessKey is the unique identifier for a given instance of
 307    a uddiBusinessEntity.  The attribute is optional for businessService
 308    instances contained within a fully expressed parent that already
 309    contains a businessKey value.
 310
 311    If the businessService instance is rendered into the Extensible
 312    Markup Language [XML] and has no containing parent that has within
 313    its data a businessKey, the value of the businessKey that is the
 314    parent of the businessService is required to be provided.  This
 315    behavior supports the ability to browse through the parent-child
 316    relationships given any of the core elements as a starting point.
 317    The businessKey may differ from the publishing businessEntity's
 318    businessKey to allow service projections.
 319
 320       ( 1.3.6.1.1.10.4.1 NAME 'uddiBusinessKey'
 321         DESC 'businessEntity unique identifier'
 322         EQUALITY caseIgnoreMatch
 323         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 324         SINGLE-VALUE
 325       )
 326
 327 4.2.  uddiAuthorizedName
 328
 329    The uddiAuthorizedName is the recorded name of the individual who
 330    published the uddiBusinessEntity or uddiTModel data.  This data is
 331    generated by the controlling operator and should not be supplied
 332    within save_business operations.
 333
 334    With UDDIv3, this attribute is part of the "operationalInformation"
 335
 336
 337
 338 Bergeson, et al.             Informational                      [Page 6]
 339 \f
 340 RFC 4403                 LDAP Schema for UDDIv3            February 2006
 341
 342
 343    metadata associated with core data structures.
 344
 345       ( 1.3.6.1.1.10.4.2 NAME 'uddiAuthorizedName'
 346         DESC 'businessEntity publisher name'
 347         EQUALITY distinguishedNameMatch
 348         SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
 349         SINGLE-VALUE
 350       )
 351
 352 4.3.  uddiOperator
 353
 354    The uddiOperator is the certified name of the UDDI registry site
 355    operator that manages the master copy of the uddiBusinessEntity or
 356    uddiTModel.  The controlling operator records this data at the time
 357    data is saved.  This data is generated and should not be supplied
 358    within save_business or save_tModel operations.
 359
 360    With UDDIv3, this field is no longer used -- it is replaced by the
 361    nodeId (uddiv3NodeId) attribute that is part of the
 362    "operationalInformation" metadata.
 363
 364       ( 1.3.6.1.1.10.4.3 NAME 'uddiOperator'
 365         DESC 'registry site operator of businessEntitys master copy'
 366         EQUALITY caseIgnoreMatch
 367         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 368         SINGLE-VALUE
 369       )
 370
 371 4.4.  uddiName
 372
 373    This is used in uddiBusinessEntity, uddiBusinessService, and
 374    uddiTModel.
 375
 376    These are the human-readable names recorded for the
 377    uddiBusinessEntity, uddiBusinessService, or uddiTModel, adorned with
 378    a unique xml:lang value to signify the language that they are
 379    expressed in.  Name search is provided via find_business,
 380    find_service, or find_tModel calls.
 381
 382    The publishing of several names, e.g., for romanization purposes, is
 383    supported.  In order to signify the language that the names are
 384    expressed in, they carry unique xml:lang values.  Not more than one
 385    name element may omit specifying its language.  Names passed in this
 386    way will be assigned the default language code of the registering
 387    party.  This default language code is established at the time that
 388    publishing credentials are established with an individual Operator
 389
 390
 391
 392
 393
 394 Bergeson, et al.             Informational                      [Page 7]
 395 \f
 396 RFC 4403                 LDAP Schema for UDDIv3            February 2006
 397
 398
 399    Site.  If no default language is provisioned at the time a publisher
 400    signs up, the operator can adopt an appropriate default language
 401    code.
 402
 403    With UDDIv3, multiple values with the same language code are
 404    permitted.
 405
 406       ( 1.3.6.1.1.10.4.4 NAME 'uddiName'
 407         DESC 'human readable name'
 408         EQUALITY caseIgnoreMatch
 409         ORDERING caseIgnoreOrderingMatch
 410         SUBSTR caseIgnoreSubstringsMatch
 411         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 412       )
 413
 414    The xml:lang value precedes the name value, with the "#" character
 415    used as the separator.
 416
 417 4.5.  uddiDescription
 418
 419    The uddiDescription is an optional repeating element of one or more
 420    descriptions.  One description is allowed per national language code
 421    supplied.  With UDDIv3, there is no restriction on the number of
 422    descriptions or on what xml:lang value that they may have.
 423
 424       ( 1.3.6.1.1.10.4.5 NAME 'uddiDescription'
 425         DESC 'short description'
 426         EQUALITY caseIgnoreMatch
 427         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 428       )
 429
 430    The xml:lang value precedes the name value, with the "#" character
 431    used as the separator.
 432
 433 4.6.  uddiDiscoveryURLs
 434
 435    This is a list of Uniform Resource Locators (URLs) that point to
 436    alternate, file-based service discovery mechanisms.  Each recorded
 437    uddiBusinessEntity structure is automatically assigned a URL that
 438    returns the individual uddiBusinessEntity structure.  A URL search is
 439    provided via find_business call.
 440
 441    The uddiDiscoveryURLs attribute is used to hold pointers to URL-
 442    addressable discovery documents.  The expected retrieval mechanism
 443    for URLs referenced in the data within this structure is via the
 444    Hypertext Transfer Protocol [HTTP] HTTP-GET operation.  The expected
 445    return document is not defined.  Rather, a framework for establishing
 446    conventions is provided, and two such conventions are defined within
 447
 448
 449
 450 Bergeson, et al.             Informational                      [Page 8]
 451 \f
 452 RFC 4403                 LDAP Schema for UDDIv3            February 2006
 453
 454
 455    UDDI behaviors.  It is hoped that other conventions come about and
 456    use this structure to accommodate alternate means of discovery.  With
 457    UDDIv3, a new convention is defined with useType as "homepage".
 458    Further, a UDDIv3 server need not generate/add a discoveryURL itself,
 459    since this can invalidate the digital signature of signed the
 460    Business Entity saved by publishers.
 461
 462       ( 1.3.6.1.1.10.4.6 NAME 'uddiDiscoveryURLs'
 463         DESC 'URL to retrieve a businessEntity instance'
 464         EQUALITY caseIgnoreMatch
 465         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 466       )
 467
 468    The useType value precedes the URL value, with the "#" character used
 469    as the separator.
 470
 471 4.7.  uddiUseType
 472
 473    The uddiUseType is used to describe the type of contact or address in
 474    freeform text.  Suggested examples for contact include "technical
 475    questions", "technical contact", "establish account", "sales
 476    contact", etc.  Suggested examples for address include
 477    "headquarters", "sales office", "billing department", etc.
 478
 479       ( 1.3.6.1.1.10.4.7 NAME 'uddiUseType'
 480         DESC 'name of convention the referenced document follows'
 481         EQUALITY caseIgnoreMatch
 482         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 483         SINGLE-VALUE
 484       )
 485
 486 4.8.  uddiPersonName
 487
 488    The uddiPersonName should list the name of the person or name of the
 489    job role that will be available behind the contact.  Examples of
 490    roles include "administrator" or "webmaster".
 491
 492       ( 1.3.6.1.1.10.4.8 NAME 'uddiPersonName'
 493         DESC 'name of person or job role available for contact'
 494         EQUALITY caseIgnoreMatch
 495         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 496         SINGLE-VALUE
 497       )
 498
 499    With UDDIv3, uddiPersonName becomes multi-valued and each name can
 500    have an xml:lang attribute.  The xml:lang value precedes the name
 501    value with the "#" character used as the separator.
 502
 503
 504
 505
 506 Bergeson, et al.             Informational                      [Page 9]
 507 \f
 508 RFC 4403                 LDAP Schema for UDDIv3            February 2006
 509
 510
 511 4.9.  uddiPhone
 512
 513    This is used to hold telephone numbers for the contact.  This element
 514    can be adorned with an optional uddiUseType attribute for descriptive
 515    purposes.  If more than one phone element is saved, uddiUseType
 516    attributes are required on each.
 517
 518       ( 1.3.6.1.1.10.4.9 NAME 'uddiPhone'
 519         DESC 'telephone number for contact'
 520         EQUALITY caseIgnoreMatch
 521         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 522       )
 523
 524    The useType precedes the telephone number by a separating '#' (e.g.,
 525    "Work Number#123 456-7890") .
 526
 527 4.10.  uddiEMail
 528
 529    This is used to hold email addresses for the contact.  This element
 530    can be adorned with an optional uddiUseType attribute for descriptive
 531    purposes.  If more than one email element is saved, uddiUseType
 532    attributes are required on each.
 533
 534       ( 1.3.6.1.1.10.4.10 NAME 'uddiEMail'
 535         DESC 'e-mail address for contact'
 536         EQUALITY caseIgnoreMatch
 537         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 538       )
 539
 540    The useType precedes the email address by a separating '#' (e.g.,
 541    "President of the United States #president@whitehouse.gov").
 542
 543 4.11.  uddiSortCode
 544
 545    The uddiSortCode is used to drive the behavior of external display
 546    mechanisms that sort addresses.  The suggested values for
 547    uddiSortCode include numeric ordering values (e.g., 1, 2, 3),
 548    alphabetic character ordering values (e.g., a, b, c), or the first n
 549    positions of relevant data within the address.
 550
 551       ( 1.3.6.1.1.10.4.11 NAME 'uddiSortCode'
 552         DESC 'specifies an external display mechanism'
 553         EQUALITY caseIgnoreMatch
 554         ORDERING caseIgnoreOrderingMatch
 555         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 556         SINGLE-VALUE
 557       )
 558
 559
 560
 561
 562 Bergeson, et al.             Informational                     [Page 10]
 563 \f
 564 RFC 4403                 LDAP Schema for UDDIv3            February 2006
 565
 566
 567    With UDDIv3, the sortCode attribute is deprecated because of the
 568    guarantee of preserving the document Order.
 569
 570 4.12.  uddiTModelKey
 571
 572    The uddiTModelKey is the unique identifier for a given instance of an
 573    uddiTModel.
 574
 575    It is also used in a KeyedReference and in Address structures.  When
 576    used with a keyed reference, this is the unique key to identify a
 577    value set and implies that the keyName keyValue pair in a
 578    uddiIdentifier or uddiCategory Bag are to be interpreted by the value
 579    set referenced by the tModelKey.
 580
 581    When used with Addressline elements, it implies that the keyName
 582    keyValue pair given by subsequent uddiAddressLine elements are to be
 583    interpreted by the address structure associated with the tModel that
 584    is referenced.
 585
 586       ( 1.3.6.1.1.10.4.12 NAME 'uddiTModelKey'
 587         DESC 'tModel unique identifier'
 588         EQUALITY caseIgnoreMatch
 589         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 590         SINGLE-VALUE
 591       )
 592
 593 4.13.  uddiAddressLine
 594
 595    The uddiAddressLine contains the actual address in freeform text.  If
 596    the address element contains a uddiTModelKey, these uddiAddressLine
 597    elements are to be adorned, each with an optional keyName keyValue
 598    attribute pair.  Together with the uddiTModelKey, keyName and
 599    keyValue qualify the uddiAddressLine in order to describe its
 600    meaning.
 601
 602    The uddiAddressLine elements contain string data with a line length
 603    limit of 80 character positions.  Each uddiAddressLine element can be
 604    adorned with two optional descriptive attributes, keyName and
 605    keyValue.  Both attributes must be present in each address line if a
 606    uddiTModelKey is assigned to the address structure.  By doing this,
 607    the otherwise arbitrary use of address lines becomes structured.
 608    Together with the address' uddiTModelKey, keyName and keyValue
 609    virtually build a uddiKeyedReference that represents an address line
 610    qualifier, given by the referenced uddiTModel.
 611
 612    When no uddiTModelKey is provided for the address structure, the
 613    keyName and keyValue attributes can be used without restrictions, for
 614    example, to provide descriptive information for each uddiAddressLine
 615
 616
 617
 618 Bergeson, et al.             Informational                     [Page 11]
 619 \f
 620 RFC 4403                 LDAP Schema for UDDIv3            February 2006
 621
 622
 623    by using the keyName attribute.  Since both the keyName and the
 624    keyValue attributes are optional, address line order is significant
 625    and will always be returned by the UDDI-compliant registry in the
 626    order originally provided during a call to save_business.
 627
 628       ( 1.3.6.1.1.10.4.13 NAME 'uddiAddressLine'
 629         DESC 'address'
 630         EQUALITY caseIgnoreMatch
 631         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 632       )
 633
 634    The keyName, keyValue, and addressData of this attribute are
 635    separated by "#" (e.g., "#"<keyName>"#"<keyValue>"#"<addressData>).
 636    The addressData is the only required portion of the attribute.
 637
 638 4.14.  uddiIdentifierBag
 639
 640    The uddiIdentifierBag element allows uddiBusinessEntity or uddiTModel
 641    structures to include information about common forms of
 642    identification such as D-U-N-S_ numbers, tax identifiers, etc.  This
 643    data can be used to signify the identity of the uddiBusinessEntity or
 644    can be used to signify the identity of the publishing party.
 645    Including data of this sort is optional, but when used greatly
 646    enhances the search behaviors exposed via the find_xx messages
 647    defined in the UDDI Version 2.0 API Specification [UDDIapi].  For a
 648    full description of the structures involved in establishing an
 649    identity, see UDDI Version 2.0 Data Structure Specification -
 650    Appendix A:  Using Identifiers [UDDIdsr].
 651
 652       ( 1.3.6.1.1.10.4.14  NAME 'uddiIdentifierBag'
 653         DESC 'identification information'
 654         EQUALITY caseIgnoreMatch
 655         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 656       )
 657
 658    The tModel, keyName, and keyValue of this attribute are separated by
 659    "#" (e.g., <tModel>"#"<keyName>"#"<keyValue>).  The keyValue is the
 660    only required portion of the attribute.
 661
 662 4.15.  uddiCategoryBag
 663
 664    The uddiCategoryBag element allows uddiBusinessEntity,
 665    uddiBusinessService, and uddiTModel structures to be categorized
 666    according to any of several available taxonomy-based classification
 667    schemes.  Operator Sites automatically provide validated
 668    categorization support for three taxonomies that cover industry codes
 669    (via NAICS), product and service classifications (via UNSPC), and
 670    geography (via ISO 3166).  Including data of this sort is optional,
 671
 672
 673
 674 Bergeson, et al.             Informational                     [Page 12]
 675 \f
 676 RFC 4403                 LDAP Schema for UDDIv3            February 2006
 677
 678
 679    but when used, it greatly enhances the search behaviors exposed by
 680    the find_xx messages defined in the UDDI Version 2.0 API
 681    Specification [UDDIapi].  For a full description of structures
 682    involved in establishing categorization information, see UDDI Version
 683    2.03 Data Structure Specification--Appendix B: Using Categorization
 684    [UDDIdsr].
 685
 686       ( 1.3.6.1.1.10.4.15 NAME 'uddiCategoryBag'
 687         DESC 'categorization information'
 688         EQUALITY caseIgnoreMatch
 689         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 690       )
 691
 692    The tModel, keyName, and keyValue of this attribute are separated by
 693    "#" (e.g., <tModel>"#"<keyName>"#"<keyValue>).  The keyValue is the
 694    only required portion of the attribute.
 695
 696    With UDDIv3, uddiBindingTemplates also supports the uddiCategoryBag
 697    element and they can also be categorized according to any of several
 698    available taxonomy-based classification schemes.
 699
 700 4.16.  uddiKeyedReference
 701
 702    The uddiKeyedReference is a general-purpose attribute for a name-
 703    value pair, with an additional reference to a tModel.
 704
 705       ( 1.3.6.1.1.10.4.16 NAME 'uddiKeyedReference'
 706         DESC 'categorization information'
 707         EQUALITY caseIgnoreMatch
 708         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 709       )
 710
 711    The tModel, keyName, and keyValue of this attribute are separated by
 712    "#" (e.g., <tModel>"#"<keyName>"#"<keyValue>).  The keyValue is the
 713    only required portion of the attribute.  With UDDIv3, the tModelKey
 714    also becomes a mandatory part of the attribute.
 715
 716    Also, UDDIv3 defines KeyedReferenceGroups for CategoryBags.  A
 717    keyedReferenceGroup contains a tModelKey and a simple list of
 718    KeyedReference structures.  The uddiKeyedReference attribute will
 719    support KeyedReferenceGroups by suffixing the tModelKey for
 720    KeyedReferenceGroup to each of the keyedReference values associated
 721    with the group.
 722
 723    For example, to represent a keyedReference group containing a list of
 724    2 keyed references, the attribute will hold the following 2 strings
 725    as its values:
 726
 727
 728
 729
 730 Bergeson, et al.             Informational                     [Page 13]
 731 \f
 732 RFC 4403                 LDAP Schema for UDDIv3            February 2006
 733
 734
 735       tModelKey1#KeyName1#KeyValue1#KeyedReferenceGroup1_tModelKey
 736       tModelKey2#KeyName2#KeyValue2#KeyedReferenceGroup1_tModelKey
 737
 738 4.17.  uddiServiceKey
 739
 740    This is the unique key for a given uddiBusinessService.  When saving
 741    a new uddiBusinessService structure, pass an empty uddiServiceKey
 742    value.  This signifies that a UUID value is to be generated.  To
 743    update an existing uddiBusinessService structure, pass the UUID value
 744    that corresponds to the existing service.  If a uddiServiceKey is
 745    received via an inquiry operation, the key values may not be blank.
 746    When saving a new or updated service projection, pass the
 747    uddiServiceKey of the referenced uddiBusinessService structure.
 748
 749    This attribute is optional when the uddiBindingTemplate data is
 750    contained within a fully expressed parent that already contains a
 751    uddiServiceKey value.  If the uddiBindingTemplate data is rendered
 752    into XML and has no containing parent that has within its data a
 753    uddiServiceKey, the value of the uddiServiceKey that is the ultimate
 754    containing parent of the uddiBindingTemplate is required to be
 755    provided.  This behavior supports the ability to browse through the
 756    parent-child relationships given any of the core elements as a
 757    starting point.
 758
 759       ( 1.3.6.1.1.10.4.17 NAME 'uddiServiceKey'
 760         DESC 'businessService unique identifier'
 761         EQUALITY caseIgnoreMatch
 762         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 763         SINGLE-VALUE
 764       )
 765
 766 4.18.  uddiBindingKey
 767
 768    This is the unique key for a given uddiBindingTemplate.  When saving
 769    a new uddiBindingTemplate structure, pass an empty uddiBindingKey
 770    value.  This signifies that a UUID value is to be generated.  To
 771    update an existing uddiBindingTemplate, pass the UUID value that
 772    corresponds to the existing uddiBindingTemplate instance.  If a
 773    uddiBindingKey is received via an inquiry operation, the key values
 774    may not be blank.
 775
 776       ( 1.3.6.1.1.10.4.18 NAME 'uddiBindingKey'
 777         DESC 'bindingTemplate unique identifier'
 778         EQUALITY caseIgnoreMatch
 779         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 780         SINGLE-VALUE
 781       )
 782
 783
 784
 785
 786 Bergeson, et al.             Informational                     [Page 14]
 787 \f
 788 RFC 4403                 LDAP Schema for UDDIv3            February 2006
 789
 790
 791 4.19.  uddiAccessPoint
 792
 793    The uddiAccessPoint element is an attribute-qualified pointer to a
 794    service entry point.  The notion of service at the metadata level
 795    seen here is fairly abstract and many types of entry points are
 796    accommodated.  A single attribute is provided named URLType.
 797
 798    Required attribute-qualified element8: This element is a text field
 799    that is used to convey the entry point address suitable for calling a
 800    particular Web service.  This may be a URL, an electronic mail
 801    address, or even a telephone number.  No assumptions about the type
 802    of data in this field can be made without first understanding the
 803    technical requirements associated with the Web service.
 804
 805       ( 1.3.6.1.1.10.4.19 NAME 'uddiAccessPoint'
 806         DESC 'entry point address to call a web service'
 807         EQUALITY caseIgnoreMatch
 808         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 809         SINGLE-VALUE
 810       )
 811
 812    The URLType value precedes the accessPoint value by a separating '#'.
 813
 814    With UDDIv3, the "URLType" attribute is replaced by a "UseType"
 815    attribute.  Using this UseType attribute, the accessPoint attribute
 816    can model a hostingRedirector or support indirection to indicate that
 817    the accesspoint is specified within a remotely hosted WSDL document.
 818
 819    For a UDDIv3 registry that needs to support UDDIv2 clients, the
 820    attribute must allow the representation of URLType and UseType values
 821    independently.
 822
 823    The UDDIv3 spec specifies the following logic for mapping values
 824    between URLType and UseType: If an entity is saved with the v3
 825    namespace and a v2 inquiry is made, the URLType will be returned as
 826    "other".  In the case when a v3 inquiry is made on an entity
 827    published with the v2 namespace, the v3 useType attribute will be
 828    returned as "endPoint".
 829
 830    For implementations that need to explicitly model both forms, the
 831    recommended format is as follows: v2URLType#v3UseType#Address
 832
 833 4.20.  uddiHostingRedirector
 834
 835    The uddiHostingRedirector element is used to designate that a
 836    uddiBindingTemplate entry is a pointer to a different
 837    uddiBindingTemplate entry.  The value in providing this facility is
 838    seen when a business or entity wants to expose a service description
 839
 840
 841
 842 Bergeson, et al.             Informational                     [Page 15]
 843 \f
 844 RFC 4403                 LDAP Schema for UDDIv3            February 2006
 845
 846
 847    (e.g., advertise that it has a service available that suits a
 848    specific purpose) that is actually a service described in a separate
 849    uddiBindingTemplate record.  This might occur when a service is
 850    remotely hosted (hence the name of this element), or when many
 851    service descriptions could benefit from a single service description.
 852
 853    The uddiHostingRedirector element has a single attribute and no
 854    element content.  The attribute is a uddiBindingKey value that is
 855    suitable within the same UDDI registry instance for querying and
 856    obtaining the uddiBindingDetail data that is to be used.
 857
 858    More on the uddiHostingRedirector can be found in the appendices for
 859    the UDDI Version 2.0 API Specification [UDDIapi].
 860
 861    Required element if uddiAccessPoint is not provided: This element is
 862    adorned with a uddiBindingKey attribute, giving the redirected
 863    reference to a different uddiBindingTemplate.  If you query a
 864    uddiBindingTemplate and find a uddiHostingRedirector value, you
 865    should retrieve that uddiBindingTemplate and use it in place of the
 866    one containing the uddiHostingRedirector data.
 867
 868       ( 1.3.6.1.1.10.4.20 NAME 'uddiHostingRedirector'
 869         DESC 'designates a pointer to another bindingTemplate'
 870         EQUALITY caseIgnoreMatch
 871         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 872         SINGLE-VALUE
 873       )
 874
 875    With UDDIv3, the hostingRedirector is a deprecated element, since its
 876    functionality is now covered by the accessPoint.  For backward-
 877    compatibility, it can still be used, but it is not recommended.
 878
 879 4.21.  uddiInstanceDescription
 880
 881    This is an optional repeating element.  This is one or more
 882    language-qualified text descriptions that designate what role a
 883    uddiTModel reference plays in the overall service description.
 884
 885       ( 1.3.6.1.1.10.4.21 NAME 'uddiInstanceDescription'
 886         DESC 'instance details description'
 887         EQUALITY caseIgnoreMatch
 888         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 889       )
 890
 891    The xml:lang value precedes the name value, with the "#" character
 892    used as the separator.
 893
 894
 895
 896
 897
 898 Bergeson, et al.             Informational                     [Page 16]
 899 \f
 900 RFC 4403                 LDAP Schema for UDDIv3            February 2006
 901
 902
 903 4.22.  uddiInstanceParms
 904
 905    The uddiInstanceParms is an optional element of the uddiInstance.  It
 906    is used to contain settings parameters or a URL reference to a file
 907    that contains settings or parameters required to use a specific facet
 908    of a uddiBindingTemplate description.  If used to house the
 909    parameters themselves, the suggested content is a namespace-qualified
 910    XML string using a namespace outside of the UDDI schema.  If used to
 911    house a URL pointer to a file, the suggested format is a URL that is
 912    suitable for retrieving the settings or parameters via HTTP-GET.
 913
 914       ( 1.3.6.1.1.10.4.22 NAME 'uddiInstanceParms'
 915         DESC 'URL reference to required settings'
 916         EQUALITY caseIgnoreMatch
 917         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 918         SINGLE-VALUE
 919       )
 920
 921 4.23.  uddiOverviewDescription
 922
 923    This is an optional repeating element.  This language-qualified
 924    string is intended to hold a short descriptive overview of how a
 925    particular uddiTModel is to be used.
 926
 927       ( 1.3.6.1.1.10.4.23 NAME 'uddiOverviewDescription'
 928         DESC 'outlines tModel usage'
 929         EQUALITY caseIgnoreMatch
 930         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 931       )
 932
 933    The xml:lang value precedes the name value, with the "#" character
 934    used as the separator.
 935
 936
 937
 938
 939
 940
 941
 942
 943
 944
 945
 946
 947
 948
 949
 950
 951
 952
 953
 954 Bergeson, et al.             Informational                     [Page 17]
 955 \f
 956 RFC 4403                 LDAP Schema for UDDIv3            February 2006
 957
 958
 959 4.24.  uddiOverviewURL
 960
 961    This is an optional element.  This string data element is to be used
 962    to hold a URL reference to a long form of an overview document that
 963    covers the way a particular uddiTModel specific reference is used as
 964    a component of an overall Web service description.  The recommended
 965    format for the overviewURL is a URI that is suitable for retrieving
 966    the actual overview document with an HTTP-GET operation, for example,
 967    via a Web browser.
 968
 969       ( 1.3.6.1.1.10.4.24 NAME 'uddiOverviewURL'
 970         DESC 'URL reference to overview document'
 971         EQUALITY caseIgnoreMatch
 972         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 973         SINGLE-VALUE
 974       )
 975
 976    With UDDIv3, uddiOverviewURL becomes multi-valued to allow the
 977    representation of multiple OverviewDocs within a single
 978    InstanceDetail element.
 979
 980    Modeling multiple OverviewDocs within an InstanceDetail element:
 981
 982    In UDDIv3, the InstanceDetails element in TmodelInstanceInfo can have
 983    multiple OverviewDoc's.  In UDDIv2, we could have only 1 OverviewDoc.
 984    To retain the grouping between a set of overviewDescriptions and
 985    overviewURL, we can make both OverviewDoc and OverviewURL multi-
 986    valued, and have a "group ID" Prefix to each value (to group
 987    OverviewDescriptions and OverviewURL).
 988
 989    An example is shown below:
 990
 991          Overview Description                            OverviewURL
 992          1#xml:lang#overviewDescription1         1#UseType#overviewURL
 993          1#xml:lang#overviewDescription2         2#UseType#overviewURL
 994          1#xml:lang#overviewDescription3         4#UseType#overviewURL
 995          3#xml:lang#overviewDescription1
 996          3#xml:lang#overviewDescription2
 997          4#xml:lang#overviewDescription1
 998
 999    This implies that OverviewDoc1 has 3 overview descriptions and an
1000    overviewURL.  OverviewDoc2 has only an overviewURL.  OverviewDoc3 has
1001    only 2 overviewDescriptions.  OverviewDoc4 also has 1 overview
1002    description and an overviewURL.
1003
1004
1005
1006
1007
1008
1009
1010 Bergeson, et al.             Informational                     [Page 18]
1011 \f
1012 RFC 4403                 LDAP Schema for UDDIv3            February 2006
1013
1014
1015 4.25.  uddiFromKey
1016
1017    The uddiFromKey is a required element.  This is the unique key
1018    reference to the first uddiBusinessEntity for which the assertion is
1019    made.
1020
1021       ( 1.3.6.1.1.10.4.25 NAME 'uddiFromKey'
1022         DESC 'unique businessEntity key reference'
1023         EQUALITY caseIgnoreMatch
1024         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
1025         SINGLE-VALUE
1026       )
1027
1028 4.26.  uddiToKey
1029
1030    The uddiToKey is a required element.  This is the unique key
1031    reference to the second uddiBusinessEntity for which the assertion is
1032    made.
1033
1034       ( 1.3.6.1.1.10.4.26 NAME 'uddiToKey'
1035         DESC 'unique businessEntity key reference'
1036         EQUALITY caseIgnoreMatch
1037         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
1038         SINGLE-VALUE
1039       )
1040
1041 4.27.  uddiUUID
1042
1043    The uddiUUID is a required element.  This is to ensure unique
1044    identification of uddiContact, uddiAddress, and
1045    uddiPublisherAssertion objects.
1046
1047       ( 1.3.6.1.1.10.4.27 NAME 'uddiUUID'
1048         DESC 'unique attribute'
1049         EQUALITY caseIgnoreMatch
1050         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
1051         SINGLE-VALUE
1052       )
1053
1054    With UDDIv3, this attribute will also be used for unique
1055    identification of Subscription-feature-related entities.
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066 Bergeson, et al.             Informational                     [Page 19]
1067 \f
1068 RFC 4403                 LDAP Schema for UDDIv3            February 2006
1069
1070
1071 4.28.  uddiIsHidden
1072
1073    This is used to provide functionality for the delete_tModel
1074    operation.  Logical deletion hides the deleted tModels from
1075    find_tModel result sets but does not physically delete it.
1076
1077       ( 1.3.6.1.1.10.4.28 NAME 'uddiIsHidden'
1078         DESC 'isHidden attribute'
1079         EQUALITY booleanMatch
1080         SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
1081         SINGLE-VALUE
1082       )
1083
1084    In case of UDDIv3, this attribute will represent the "deleted"
1085    attribute value.
1086
1087 4.29.  uddiIsProjection
1088
1089    This is used to identify a Business Service that has a Service
1090    Projection.
1091
1092       ( 1.3.6.1.1.10.4.29 NAME 'uddiIsProjection'
1093         DESC 'isServiceProjection attribute'
1094         EQUALITY booleanMatch
1095         SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
1096         SINGLE-VALUE
1097       )
1098
1099 4.30.  uddiLang
1100
1101    This is used to model the xml:lang value for the Address structure in
1102    UDDIv3.
1103
1104       ( 1.3.6.1.1.10.4.30 NAME 'uddiLang'
1105         DESC 'xml:lang value in v3 Address structure'
1106         EQUALITY caseIgnoreMatch
1107         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
1108         SINGLE-VALUE
1109       )
1110
1111    The following are attribute definitions to model new elements/fields
1112    in UDDIv3 information model.  These attribute definitions have the
1113    "uddiv3" prefix to indicate that these attributes represent UDDI
1114    information model elements unique to UDDIv3.
1115
1116
1117
1118
1119
1120
1121
1122 Bergeson, et al.             Informational                     [Page 20]
1123 \f
1124 RFC 4403                 LDAP Schema for UDDIv3            February 2006
1125
1126
1127 4.31.  uddiv3BusinessKey
1128
1129    This is the unique UDDIv3 identifier for a given instance of
1130    uddiBusinessEntity.  It is used in uddiBusinessEntity and
1131    uddiBusinessService.
1132
1133    A uddiBusinessEntity will include the uddiBusinessKey (the v2 form)
1134    for unique identification by UDDIv2 clients.  The uddiBusinessKey
1135    (36-char) will also be the LDAP naming attribute for the
1136    uddiBusinessEntity.  The uddiBusinessEntity entry MAY also include
1137    the uddiv3BusinessKey, the explicit v3 form key, which can be 255
1138    characters long.
1139
1140       ( 1.3.6.1.1.10.4.31 NAME 'uddiv3BusinessKey'
1141         DESC 'UDDIv3 businessEntity unique identifier'
1142         EQUALITY caseIgnoreMatch
1143         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
1144         SINGLE-VALUE
1145       )
1146
1147 4.32.  uddiv3ServiceKey
1148
1149    This is the unique UDDIv3 identifier for a given instance of
1150    uddiBusinessService.  It is used in uddiBusinessService and
1151    uddiBindingTemplate.
1152
1153    A uddiBusinessService will include the uddiServiceKey (the v2 form)
1154    for unique identification by UDDIv2 clients.  The uddiServiceKey
1155    (36-char) will also be the LDAP naming attribute for the
1156    uddiBusinessService entry.  The uddiBusinessService entry MAY also
1157    include the uddiv3ServiceKey, the explicit v3 form key, which can be
1158    255 characters long.
1159
1160       ( 1.3.6.1.1.10.4.32 NAME 'uddiv3ServiceKey'
1161         DESC 'UDDIv3 businessService unique identifier'
1162         EQUALITY caseIgnoreMatch
1163         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
1164         SINGLE-VALUE
1165       )
1166
1167 4.33.  uddiv3BindingKey
1168
1169    This is the unique UDDIv3 identifier for a given instance of
1170    uddiBindingTemplate.
1171
1172    A uddiBindingTemplate will include the uddiBindingKey (the v2 form)
1173    for unique identification by UDDIv2 clients.  The uddiBindingKey
1174    (36-char) will also be the LDAP naming attribute for the
1175
1176
1177
1178 Bergeson, et al.             Informational                     [Page 21]
1179 \f
1180 RFC 4403                 LDAP Schema for UDDIv3            February 2006
1181
1182
1183    uddiBindingTemplate entry.  The uddiBindingTemplate entry MAY also
1184    include the uddiv3BindingKey, the explicit v3 form key, which can be
1185    255 characters long.
1186
1187       ( 1.3.6.1.1.10.4.33 NAME 'uddiv3BindingKey'
1188         DESC 'UDDIv3 BindingTemplate unique identifier'
1189         EQUALITY caseIgnoreMatch
1190         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
1191         SINGLE-VALUE
1192       )
1193
1194 4.34.  uddiv3TModelKey
1195
1196    This is the unique UDDIv3 identifier for a given instance of a
1197    uddiTModel.
1198
1199    A uddiTModel will include the uddiTModelKey (the v2 form) for unique
1200    identification by UDDIv2 clients.  The uddiTModelKey (41-char) will
1201    also be the LDAP naming attribute for the uddiTModel entry.  The
1202    uddiTModel entry MAY also include the uddiv3TModelKey, the explicit
1203    v3 form key, which can be 255 characters long.
1204
1205       ( 1.3.6.1.1.10.4.34 NAME 'uddiv3TModelKey'
1206         DESC 'UDDIv3 TModel unique identifier'
1207         EQUALITY caseIgnoreMatch
1208         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
1209         SINGLE-VALUE
1210       )
1211
1212    The tModelKey is also used in a KeyedReference and in Address
1213    structures.  In all instances where a tModelKey is used as a
1214    reference to tModel, the v3 form of the tModel key (viz.
1215    uddiv3TModelKey) will be the form used, since using the v2 form key
1216    will require translating it to the v3 key by the UDDI Server, which
1217    may invalidate the digital signature of the entity.
1218
1219 4.35.  uddiv3DigitalSignature
1220
1221    The UDDIv3 v3 schema supports the signing of the following UDDI
1222    elements using "XML-Signature Syntax and Processing" (see
1223    http://www.w3.org/TR/xmldsig-core/).
1224
1225       ..businessEntity
1226       ..businessService
1227       ..bindingTemplate
1228       ..tModel
1229       ..publisherAssertion
1230
1231
1232
1233
1234 Bergeson, et al.             Informational                     [Page 22]
1235 \f
1236 RFC 4403                 LDAP Schema for UDDIv3            February 2006
1237
1238
1239    This uddiv3DigitalSignature attribute holds the digital signature for
1240    the corresponding UDDI entity.
1241
1242       ( 1.3.6.1.1.10.4.35 NAME 'uddiv3DigitalSignature'
1243         DESC 'UDDIv3 entity digital signature'
1244         EQUALITY caseExactMatch
1245         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
1246         )
1247
1248    A Signature element SHOULD be generated according to the required
1249    steps of "Core Generation" in XML-Signature Syntax and Processing.
1250    The signature should be calculated on the top-level element that will
1251    be stored by the registry as a result of the Publication API call.
1252    This element, referred to as the data object in the XML-Signature and
1253    Syntax specification, is the businessEntity element for save_business
1254    API calls, the businessService element for save_service API calls,
1255    the bindingTemplate for save_binding API calls, the tModel for
1256    save_tModel API calls, and the publisherAssertion for
1257    set_publisherAssertions and add_publisherAssertion API calls.
1258
1259    The signature should be generated on the elements before they are
1260    added to the body of an API call.  Also, according to the signature
1261    generation, all children of the element being signed are included in
1262    the generation of the signature unless first excluded by application
1263    of a transform.  Due to the containment of service projections as
1264    businessService elements within a businessEntity element, this also
1265    means that changes to the projected service will render a signature
1266    of the businessEntity containing the projection invalid, unless a
1267    businessService element representing a service projection is excluded
1268    using a transform.
1269
1270    Due to the location of the sequence of Signature elements within an
1271    element that is to be signed, the signature is "enveloped".  As a
1272    result of the enveloping of the signature, it is necessary to apply
1273    at least one transformation on the signed entity to exclude the
1274    signature or signature(s).  The transformation selected by a
1275    publisher or the XML-Signature tool is specified in a Transform
1276    element inside the Signature element.
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290 Bergeson, et al.             Informational                     [Page 23]
1291 \f
1292 RFC 4403                 LDAP Schema for UDDIv3            February 2006
1293
1294
1295 4.36.  uddiv3NodeId
1296
1297    This attribute contains the Node Identity for a UDDIv3 node.
1298
1299       ( 1.3.6.1.1.10.4.36 NAME 'uddiv3NodeId'
1300         DESC 'UDDIv3 Node Identifier'
1301         EQUALITY caseIgnoreMatch
1302         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
1303         SINGLE-VALUE
1304       )
1305
1306 4.37.  uddiv3EntityModificationTime
1307
1308    This attribute is used to maintain the last modification time for a
1309    UDDI entity.  It is needed in the context of maintaining the
1310    modifiedIncludingChildren element.  When a child entity (e.g.,
1311    uddiBindingTemplate) is updated, the parent entity (e.g.,
1312    uddiBusinessService) LDAP timestamp also gets updated.  The
1313    uddiv3EntityModificationTime attribute saves the last modification
1314    time of the parent entity (uddiBusinessService in this case).
1315
1316       ( 1.3.6.1.1.10.4.37 NAME 'uddiv3EntityModificationTime'
1317         DESC 'UDDIv3 Last Modified Time for Entity'
1318         EQUALITY generalizedTimeMatch
1319         SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1320         SINGLE-VALUE
1321       )
1322
1323    The following attribute definitions define attributes related to the
1324    modeling of UDDIv3 subscription-related entities in the LDAP
1325    directory.
1326
1327    Subscription provides clients, known as subscribers, with the ability
1328    to register their interest in receiving information concerning
1329    changes made in a UDDI registry.  These changes can be scoped based
1330    on preferences provided with the request.  The uddiv3Subscription
1331    object class is used to model registered UDDIv3 subscriptions.
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346 Bergeson, et al.             Informational                     [Page 24]
1347 \f
1348 RFC 4403                 LDAP Schema for UDDIv3            February 2006
1349
1350
1351 4.38.  uddiv3SubscriptionKey
1352
1353    This is the unique UDDIv3 identifier for a given instance of a
1354    uddiv3Subscription entity.
1355
1356       ( 1.3.6.1.1.10.4.38 NAME 'uddiv3SubscriptionKey'
1357         DESC 'UDDIv3 Subscription unique identifier'
1358         EQUALITY caseIgnoreMatch
1359         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
1360         SINGLE-VALUE
1361       )
1362
1363 4.39.  uddiv3SubscriptionFilter
1364
1365    This attribute contains the UDDIv3 Subscription Filter, specified as
1366    part of the save_subscription API, i.e., the Inquiry API specified as
1367    filtering criteria with a registered subscription.  The filtering
1368    criteria limits the scope of a subscription to a subset of registry
1369    records.  The get_xx and find_xx APIs are all valid choices for use
1370    as a subscriptionFilter.  Only one of these can be chosen for each
1371    subscription.
1372
1373       ( 1.3.6.1.1.10.4.39 NAME 'uddiv3SubscriptionFilter'
1374         DESC 'UDDIv3 Subscription Filter'
1375         EQUALITY caseIgnoreMatch
1376         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
1377         SINGLE-VALUE
1378       )
1379
1380 4.40.  uddiv3NotificationInterval
1381
1382    This attribute contains the Notification Interval string.  It is of
1383    the type xsd:duration and specifies how often Asynchronous change
1384    notifications are to be provided to a subscriber.
1385
1386       ( 1.3.6.1.1.10.4.40 NAME 'uddiv3NotificationInterval'
1387         DESC 'UDDIv3 Notification Interval'
1388         EQUALITY caseIgnoreMatch
1389         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
1390         SINGLE-VALUE
1391       )
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402 Bergeson, et al.             Informational                     [Page 25]
1403 \f
1404 RFC 4403                 LDAP Schema for UDDIv3            February 2006
1405
1406
1407 4.41.  uddiv3MaxEntities
1408
1409    This attribute contains the maximum number of entities to be returned
1410    as part of a subscription notification.  It is an integer and
1411    specifies the maximum number of entities in a notification returned
1412    to a subscription listener.
1413
1414       ( 1.3.6.1.1.10.4.41 NAME 'uddiv3MaxEntities'
1415         DESC 'UDDIv3 Subscription maxEntities field'
1416         EQUALITY integerMatch
1417         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
1418         SINGLE-VALUE
1419       )
1420
1421 4.42.  uddiv3ExpiresAfter
1422
1423    This attribute specifies the Expiry Time associated with a
1424    subscription.  It is of the XML Schema type xsd:dateTime.
1425
1426       ( 1.3.6.1.1.10.4.42 NAME 'uddiv3ExpiresAfter'
1427         DESC 'UDDIv3 Subscription ExpiresAfter field'
1428         EQUALITY generalizedTimeMatch
1429         SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1430         SINGLE-VALUE
1431       )
1432
1433 4.43.  uddiv3BriefResponse
1434
1435    This attribute is a Boolean flag for Brief Response associated with a
1436    subscription entity.  It controls the level of detail returned to a
1437    subscription listener.  The default is "false" when omitted.  When
1438    set to "true", it indicates that the subscription results are to be
1439    returned to the subscriber in the form of a keyBag, listing all of
1440    the entities that matched the subscriptionFilter.
1441
1442       ( 1.3.6.1.1.10.4.43 NAME 'uddiv3BriefResponse'
1443         DESC 'UDDIv3 Subscription ExpiresAfter field'
1444         EQUALITY booleanMatch
1445         SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
1446         SINGLE-VALUE
1447       )
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458 Bergeson, et al.             Informational                     [Page 26]
1459 \f
1460 RFC 4403                 LDAP Schema for UDDIv3            February 2006
1461
1462
1463 4.44.  uddiv3EntityKey
1464
1465    This is the unique UDDIv3 identifier for a given instance of a core
1466    UDDI data structure that is to be logged as an Obituary entry
1467    uddiv3EntityObituary.  When a core UDDIv3 Entity is deleted and there
1468    is an active subscription registered against this UDDI Entity, an
1469    Obituary entry is created, in which the v3 key of the deleted entry
1470    is logged as part of the uddiv3EntityKey attribute.
1471
1472       ( 1.3.6.1.1.10.4.44 NAME 'uddiv3EntityKey'
1473         DESC 'UDDIv3 Entity unique identifier'
1474         EQUALITY caseIgnoreMatch
1475         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
1476         SINGLE-VALUE
1477       )
1478
1479 4.45.  uddiv3EntityCreationTime
1480
1481    This attribute is used to log the original Creation Time for a UDDI
1482    Entity that is deleted in the uddiv3EntityObituary entry.
1483
1484    It is also used in uddiBusinessService and uddiBindingTemplate.  A
1485    Move BS operation needs to delete and recreate BT sub-tree due to
1486    lack of support for moving a sub-tree in many LDAPv3 servers.  This
1487    attribute is used to save the original creation time of the BT during
1488    a Move BS.
1489
1490       ( 1.3.6.1.1.10.4.45 NAME 'uddiv3EntityCreationTime'
1491         DESC 'UDDIv3 Entity Creation Time'
1492         EQUALITY generalizedTimeMatch
1493         SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1494         SINGLE-VALUE
1495       )
1496
1497 4.46.  uddiv3EntityDeletionTime
1498
1499    This attribute is used to log the entity deletion time for a UDDI
1500    Entity that is deleted in the uddiv3EntityObituary entry.
1501
1502       ( 1.3.6.1.1.10.4.46 NAME 'uddiv3EntityDeletionTime'
1503         DESC 'UDDIv3 Entity Deletion Time'
1504         EQUALITY generalizedTimeMatch
1505         SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1506         SINGLE-VALUE
1507       )
1508
1509
1510
1511
1512
1513
1514 Bergeson, et al.             Informational                     [Page 27]
1515 \f
1516 RFC 4403                 LDAP Schema for UDDIv3            February 2006
1517
1518
1519 5.  Object Class Definitions
1520
1521    The OIDs for the object classes in this document have been registered
1522    by the IANA.
1523
1524 5.1.  uddiBusinessEntity
1525
1526    This structural object class represents a businessEntity.
1527
1528       ( 1.3.6.1.1.10.6.1 NAME 'uddiBusinessEntity'
1529         SUP top
1530         STRUCTURAL
1531         MUST ( uddiBusinessKey $
1532                uddiName)
1533         MAY ( uddiAuthorizedName $
1534               uddiOperator $
1535               uddiDiscoveryURLs $
1536               uddiDescription $
1537               uddiIdentifierBag $
1538               uddiCategoryBag $
1539               uddiv3BusinessKey $
1540               uddiv3DigitalSignature $
1541               uddiv3EntityModificationTime $
1542               uddiv3NodeId)
1543       )
1544
1545 5.2.  uddiContact
1546
1547    This structural object class represents a contact.  It is contained
1548    by a uddiBusinessEntity.
1549
1550       ( 1.3.6.1.1.10.6.2 NAME 'uddiContact'
1551         SUP top
1552         STRUCTURAL
1553         MUST ( uddiPersonName $
1554                uddiUUID )
1555         MAY ( uddiUseType $
1556               uddiDescription $
1557               uddiPhone $
1558               uddiEMail )
1559       )
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570 Bergeson, et al.             Informational                     [Page 28]
1571 \f
1572 RFC 4403                 LDAP Schema for UDDIv3            February 2006
1573
1574
1575 5.3.  uddiAddress
1576
1577    This structural object class represents an address.  It is contained
1578    by a uddiContact.
1579
1580       ( 1.3.6.1.1.10.6.3 NAME 'uddiAddress'
1581         SUP top
1582         STRUCTURAL
1583         MUST ( uddiUUID )
1584         MAY ( uddiUseType $
1585               uddiSortCode $
1586               uddiTModelKey $
1587               uddiv3TmodelKey $
1588               uddiAddressLine $
1589               uddiLang)
1590       )
1591
1592 5.4.  uddiBusinessService
1593
1594    This structural object class represents a businessService.
1595
1596       ( 1.3.6.1.1.10.6.4 NAME 'uddiBusinessService'
1597         SUP top
1598         STRUCTURAL
1599         MUST ( uddiServiceKey )
1600         MAY ( uddiName $
1601            uddiBusinessKey $
1602               uddiDescription $
1603               uddiCategoryBag $
1604               uddiIsProjection $
1605               uddiv3ServiceKey $
1606               uddiv3BusinessKey $
1607               uddiv3DigitalSignature $
1608               uddiv3EntityCreationTime $
1609               uddiv3EntityModificationTime $
1610               uddiv3NodeId)
1611       )
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626 Bergeson, et al.             Informational                     [Page 29]
1627 \f
1628 RFC 4403                 LDAP Schema for UDDIv3            February 2006
1629
1630
1631 5.5.  uddiBindingTemplate
1632
1633    This structural object class represents a bindingTemplate.
1634
1635       ( 1.3.6.1.1.10.6.5 NAME 'uddiBindingTemplate'
1636         SUP top
1637         STRUCTURAL
1638         MUST ( uddiBindingKey )
1639         MAY ( uddiServiceKey $
1640               uddiDescription $
1641               uddiAccessPoint $
1642               uddiHostingRedirector
1643               uddiCategoryBag $
1644               uddiv3BindingKey $
1645               uddiv3ServiceKey $
1646               uddiv3DigitalSignature $
1647               uddiv3EntityCreationTime $
1648               uddiv3NodeId)
1649       )
1650
1651 5.6.  uddiTModelInstanceInfo
1652
1653    This structural object class represents a tModelInstanceInfo.  It is
1654    contained by a uddiBindingTemplate.
1655
1656       ( 1.3.6.1.1.10.6.6 NAME 'uddiTModelInstanceInfo'
1657         SUP top
1658         STRUCTURAL
1659         MUST ( uddiTModelKey )
1660         MAY ( uddiDescription $
1661               uddiInstanceDescription $
1662               uddiInstanceParms $
1663               uddiOverviewDescription $
1664               uddiOverviewURL $
1665               uddiv3TmodelKey)
1666       )
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682 Bergeson, et al.             Informational                     [Page 30]
1683 \f
1684 RFC 4403                 LDAP Schema for UDDIv3            February 2006
1685
1686
1687 5.7.  uddiTModel
1688
1689    This structural object class represents a tModel.
1690
1691       ( 1.3.6.1.1.10.6.7 NAME 'uddiTModel'
1692         SUP top
1693         STRUCTURAL
1694         MUST ( uddiTModelKey $
1695                uddiName )
1696         MAY ( uddiAuthorizedName $
1697               uddiOperator $
1698               uddiDescription $
1699               uddiOverviewDescription $
1700               uddiOverviewURL $
1701               uddiIdentifierBag $
1702               uddiCategoryBag $
1703               uddiIsHidden
1704               uddiv3TModelKey $
1705               uddiv3DigitalSignature $
1706               uddiv3NodeId)
1707       )
1708
1709 5.8.  uddiPublisherAssertion
1710
1711    This structural object class represents a publisherAssertion.
1712
1713       ( 1.3.6.1.1.10.6.8 NAME 'uddiPublisherAssertion'
1714         SUP top
1715         STRUCTURAL
1716         MUST ( uddiFromKey $
1717                uddiToKey $
1718                uddiKeyedReference $
1719                uddiUUID )
1720         MAY ( uddiv3DigitalSignature $
1721               uddiv3NodeId)
1722       )
1723
1724    The following are object class definitions to model new data
1725    structures needed to implement the UDDIv3 information model.  These
1726    object class definitions have the "uddiv3" prefix to indicate that
1727    these attributes represent UDDI information model elements unique to
1728    UDDIv3.
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738 Bergeson, et al.             Informational                     [Page 31]
1739 \f
1740 RFC 4403                 LDAP Schema for UDDIv3            February 2006
1741
1742
1743 5.9.  uddiv3Subscription
1744
1745    This structural object class represents a Subscription entity.
1746
1747       ( 1.3.6.1.1.10.6.9 NAME 'uddiv3Subscription'
1748         SUP top
1749         STRUCTURAL
1750         MUST ( uddiv3SubscriptionFilter $
1751                uddiUUID)
1752         MAY (  uddiAuthorizedName $
1753                uddiv3SubscriptionKey $
1754                uddiv3BindingKey $
1755                uddiv3NotificationInterval $
1756                uddiv3MaxEntities $
1757                uddiv3ExpiresAfter $
1758                uddiv3BriefResponse $
1759                uddiv3NodeId)
1760       )
1761
1762 5.10.  uddiv3EntityObituary
1763
1764    This structural object class represents an Obituary entry for and
1765    stores obituary information for deleted UDDIv3 entities needed for
1766    handling subscriptions.
1767
1768       ( 1.3.6.1.1.10.6.10 NAME 'uddiv3EntityObituary'
1769         SUP top
1770         STRUCTURAL
1771         MUST ( uddiv3EntityKey $
1772                uddiUUID)
1773         MAY (  uddiAuthorizedName $
1774                uddiv3EntityCreationTime $
1775                uddiv3EntityDeletionTime $
1776                uddiv3NodeId)
1777       )
1778
1779 6.  Name Forms
1780
1781    This section defines the required hierarchical structure rules and
1782    naming attributes for the object classes defined in Section 6.
1783
1784    The OIDs for the structure rules in this document have been
1785    registered by the IANA.
1786
1787
1788
1789
1790
1791
1792
1793
1794 Bergeson, et al.             Informational                     [Page 32]
1795 \f
1796 RFC 4403                 LDAP Schema for UDDIv3            February 2006
1797
1798
1799 6.1.  uddiBusinessEntityNameForm
1800
1801    This name form defines the naming attribute for a businessEntity.
1802
1803       ( 1.3.6.1.1.10.15.1 NAME 'uddiBusinessEntityNameForm'
1804         OC uddiBusinessEntity
1805         MUST ( uddiBusinessKey )
1806       )
1807
1808 6.2.  uddiContactNameForm
1809
1810    This name form defines the naming attribute for a contact.
1811
1812       ( 1.3.6.1.1.10.15.2 NAME 'uddiContactNameForm'
1813         OC uddiContact
1814         MUST ( uddiUUID )
1815       )
1816
1817 6.3.  uddiAddressNameForm
1818
1819    This name form defines the naming attribute for an address.
1820
1821       ( 1.3.6.1.1.10.15.3 NAME 'uddiAddressNameForm'
1822         OC uddiAddress
1823         MUST ( uddiUUID )
1824       )
1825
1826 6.4.  uddiBusinessServiceNameForm
1827
1828    This name form defines the naming attribute for a businessService.
1829
1830       ( 1.3.6.1.1.10.15.4  NAME 'uddiBusinessServiceNameForm'
1831         OC uddiBusinessService
1832         MUST ( uddiServiceKey )
1833       )
1834
1835 6.5.  uddiBindingTemplateNameForm
1836
1837    This name form defines the naming attribute for a bindingTemplate.
1838
1839       ( 1.3.6.1.1.10.15.5 NAME 'uddiBindingTemplateNameForm'
1840         OC uddiBindingTemplate
1841         MUST ( uddiBindingKey )
1842       )
1843
1844
1845
1846
1847
1848
1849
1850 Bergeson, et al.             Informational                     [Page 33]
1851 \f
1852 RFC 4403                 LDAP Schema for UDDIv3            February 2006
1853
1854
1855 6.6.  uddiTModelInstanceInfoNameForm
1856
1857    This name form defines the naming attribute for a tModelInstanceInfo.
1858
1859       ( 1.3.6.1.1.10.15.6 NAME 'uddiTModelInstanceInfoNameForm'
1860         OC uddiTModelInstanceInfo
1861         MUST ( uddiTModelKey )
1862       )
1863
1864 6.7.  uddiTModelNameForm
1865
1866    This name form defines the naming attribute for a tModel.
1867
1868       ( 1.3.6.1.1.10.15.7 NAME 'uddiTModelNameForm'
1869         OC uddiTModel
1870         MUST ( uddiTModelKey )
1871       )
1872
1873 6.8.  uddiPublisherAssertionNameForm
1874
1875    This name form defines the naming attribute for a publisherAssertion.
1876
1877       ( 1.3.6.1.1.10.15.8 NAME 'uddiPublisherAssertionNameForm'
1878         OC uddiPublisherAssertion
1879         MUST ( uddiUUID )
1880       )
1881
1882 6.9.  uddiv3SubscriptionNameForm
1883
1884    This name form defines the naming attribute for a Subscription.
1885
1886       ( 1.3.6.1.1.10.15.9 NAME 'uddiv3SubscriptionNameForm'
1887         OC uddiv3Subscription
1888         MUST ( uddiUUID )
1889       )
1890
1891 6.10.  uddiv3EntityObituaryNameForm
1892
1893    This name form defines the naming attribute for an Entity Obituary.
1894
1895       ( 1.3.6.1.1.10.15.10 NAME 'uddiv3EntityObituaryNameForm'
1896         OC uddiv3EntityObituary
1897         MUST ( uddiUUID )
1898       )
1899
1900
1901
1902
1903
1904
1905
1906 Bergeson, et al.             Informational                     [Page 34]
1907 \f
1908 RFC 4403                 LDAP Schema for UDDIv3            February 2006
1909
1910
1911 7.  DIT Structure Rules
1912
1913    This section defines the required hierarchical structure rules for
1914    the object classes defined in Section 6.
1915
1916    Note that rule identifiers defined here show the relationship between
1917    structure rules.  Implementations may use different identifiers but
1918    must follow the same hierarchical model.
1919
1920 7.1.  uddiBusinessEntityStructureRule
1921
1922       ( 1
1923         NAME 'uddiBusinessEntityStructureRule'
1924         FORM uddiBusinessEntityNameForm
1925       )
1926
1927 7.2.  uddiContactStructureRule
1928
1929    This structure rule defines the object class containment for a
1930    contact.
1931
1932       ( 2
1933         NAME 'uddiContactStructureRule'
1934         FORM uddiContactNameForm
1935         SUP ( 1 )
1936       )
1937
1938 7.3.  uddiAddressStructureRule
1939
1940    This structure rule defines the object class containment for an
1941    address.
1942
1943       ( 3
1944         NAME 'uddiAddressStructureRule'
1945         FORM uddiAddressNameForm
1946         SUP ( 2 )
1947       )
1948
1949 7.4.  uddiBusinessServiceStructureRule
1950
1951    This structure rule defines the object class containment for a
1952    businessService.
1953
1954       ( 4
1955         NAME 'uddiBusinessServiceStructureRule'
1956         FORM uddiBusinessServiceNameForm
1957         SUP ( 1 )
1958       )
1959
1960
1961
1962 Bergeson, et al.             Informational                     [Page 35]
1963 \f
1964 RFC 4403                 LDAP Schema for UDDIv3            February 2006
1965
1966
1967
1968 7.5.  uddiBindingTemplateStructureRule
1969
1970    This structure rule defines the object class containment for a
1971    bindingTemplate.
1972
1973       ( 5
1974         NAME 'uddiBindingTemplateStructureRule'
1975         FORM uddiBindingTemplateNameForm
1976         SUP ( 4 )
1977       )
1978
1979 7.6.  uddiTModelInstanceInfoStructureRule
1980
1981    This structure rule defines the object class containment for a
1982    tModelInstanceInfo.
1983
1984       ( 6
1985         NAME 'uddiTModelInstanceInfoStructureRule'
1986         FORM uddiTModelInstanceInfoNameForm
1987         SUP ( 5 )
1988       )
1989
1990 7.7.  uddiTModelStructureRule
1991
1992       ( 7
1993         NAME 'uddiTModelStructureRule'
1994         FORM uddiTModelNameForm
1995       )
1996
1997 7.8.  uddiPublisherAssertion
1998
1999       ( 8
2000         NAME 'uddiPublisherAssertionStructureRule'
2001         FORM uddiPublisherAssertionNameForm
2002       )
2003
2004 7.9.  uddiv3SubscriptionStructureRule
2005
2006       ( 9
2007         NAME 'uddiv3SubscriptionStructureRule'
2008         FORM uddiv3SubscriptionNameForm
2009       )
2010
2011
2012
2013
2014
2015
2016
2017
2018 Bergeson, et al.             Informational                     [Page 36]
2019 \f
2020 RFC 4403                 LDAP Schema for UDDIv3            February 2006
2021
2022
2023 7.10.  uddiv3EntityObituaryStructureRule
2024
2025       ( 10
2026         NAME 'uddiv3EntityObituaryStructureRule'
2027         FORM uddiv3EntityObituaryNameForm
2028       )
2029
2030 8.  Security Considerations
2031
2032    Storing UDDI data into the directory enables the data to be examined
2033    and used outside the environment in which it was originally created.
2034    The directory entry containing the UDDI data could be read and
2035    modified within the constraints imposed by the access control
2036    mechanisms of the directory.  With UDDIv3 [UDDIv3], publishers can
2037    digitally sign UDDI Entities enabling registry clients to validate
2038    the integrity of entries read from the UDDIv3 registry by verifying
2039    the digital signature.
2040
2041    Each UDDI Entity has a uddiAuthorizedName attribute that contains an
2042    LDAP DN identifying the publisher/owner.  The referenced LDAP object
2043    can provide the public key of the signer to a registry client for
2044    integrity validation of the UDDI Entity.
2045
2046    Other general LDAP [LDAPv3] security considerations apply.  Some of
2047    the UDDI attributes such as AccessPoints for services may contain
2048    sensitive information.  Use of strong authentication mechanisms and
2049    data integrity/confidentiality services [RFC2829][RFC2830] is
2050    advised.
2051
2052 9.  IANA Considerations
2053
2054    Refer to RFC 3383, "Internet Assigned Numbers Authority (IANA)
2055    Considerations for the Lightweight Directory Access Protocol (LDAP)"
2056    [RFC3383].
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074 Bergeson, et al.             Informational                     [Page 37]
2075 \f
2076 RFC 4403                 LDAP Schema for UDDIv3            February 2006
2077
2078
2079 9.1.  Object Identifier Registration
2080
2081    The IANA has registered an LDAP Object Identifier for use in this
2082    technical specification, according to the following template:
2083
2084    Subject: Request for LDAP OID Registration
2085    Person & email address to contact for further information:
2086       Bruce Bergeson (bruce.bergeson@novell.com)
2087    Specification: RFC 4403
2088    Author/Change Controller: IESG
2089    Comments:
2090       The assigned OID (10) will be used as a base for identifying
2091       a number of UDDI schema elements defined in this document.
2092
2093 9.2.  Object Identifier Descriptors
2094
2095    The IANA has registered the LDAP Descriptors used in this technical
2096    specification as detailed in the following template:
2097
2098    Subject: Request for LDAP Descriptor Registration Update
2099    Descriptor (short name): see table
2100    Object Identifier: see table
2101    Person & email address to contact for further information:
2102       Bruce Bergeson (bruce.bergeson@novell.com)
2103    Usage: see table
2104    Specification: RFC 4403
2105    Author/Change Controller: IESG
2106    Table:
2107
2108    The following descriptors have been added:
2109
2110    NAME                            Type    OID
2111    --------------                  ----    ------------
2112    uddiBusinessKey                 A       1.3.6.1.1.10.4.1
2113    uddiAuthorizedName              A       1.3.6.1.1.10.4.2
2114    uddiOperator                    A       1.3.6.1.1.10.4.3
2115    uddiName                        A       1.3.6.1.1.10.4.4
2116    uddiDescription                 A       1.3.6.1.1.10.4.5
2117    uddiDiscoveryURLs               A       1.3.6.1.1.10.4.6
2118    uddiUseType                     A       1.3.6.1.1.10.4.7
2119    uddiPersonName                  A       1.3.6.1.1.10.4.8
2120    uddiPhone                       A       1.3.6.1.1.10.4.9
2121    uddiEMail                       A       1.3.6.1.1.10.4.10
2122    uddiSortCode                    A       1.3.6.1.1.10.4.11
2123    uddiTModelKey                   A       1.3.6.1.1.10.4.12
2124    uddiAddressLine                 A       1.3.6.1.1.10.4.13
2125
2126
2127
2128
2129
2130 Bergeson, et al.             Informational                     [Page 38]
2131 \f
2132 RFC 4403                 LDAP Schema for UDDIv3            February 2006
2133
2134
2135    NAME                            Type    OID
2136    --------------                  ----    ------------
2137    uddiIdentifierBag               A       1.3.6.1.1.10.4.14
2138    uddiCategoryBag                 A       1.3.6.1.1.10.4.15
2139    uddiKeyedReference              A       1.3.6.1.1.10.4.16
2140    uddiServiceKey                  A       1.3.6.1.1.10.4.17
2141    uddiBindingKey                  A       1.3.6.1.1.10.4.18
2142    uddiAccessPoint                 A       1.3.6.1.1.10.4.19
2143    uddiHostingRedirector           A       1.3.6.1.1.10.4.20
2144    uddiInstanceDescription         A       1.3.6.1.1.10.4.21
2145    uddiInstanceParms               A       1.3.6.1.1.10.4.22
2146    uddiOverviewDescription         A       1.3.6.1.1.10.4.23
2147    uddiOverviewURL                 A       1.3.6.1.1.10.4.24
2148    uddiFromKey                     A       1.3.6.1.1.10.4.25
2149    uddiToKey                       A       1.3.6.1.1.10.4.26
2150    uddiUUID                        A       1.3.6.1.1.10.4.27
2151    uddiIsHidden                    A       1.3.6.1.1.10.4.28
2152    uddiIsProjection                A       1.3.6.1.1.10.4.29
2153    uddiLang                        A       1.3.6.1.1.10.4.30
2154    uddiv3BusinessKey               A       1.3.6.1.1.10.4.31
2155    uddiv3ServiceKey                A       1.3.6.1.1.10.4.32
2156    uddiv3BindingKey                A       1.3.6.1.1.10.4.33
2157    uddiv3TmodelKey                 A       1.3.6.1.1.10.4.34
2158    uddiv3DigitalSignature          A       1.3.6.1.1.10.4.35
2159    uddiv3NodeId                    A       1.3.6.1.1.10.4.36
2160    uddiv3EntityModificationTime    A       1.3.6.1.1.10.4.37
2161    uddiv3SubscriptionKey           A       1.3.6.1.1.10.4.38
2162    uddiv3SubscriptionFilter        A       1.3.6.1.1.10.4.39
2163    uddiv3NotificationInterval      A       1.3.6.1.1.10.4.40
2164    uddiv3MaxEntities               A       1.3.6.1.1.10.4.41
2165    uddiv3ExpiresAfter              A       1.3.6.1.1.10.4.42
2166    uddiv3BriefResponse             A       1.3.6.1.1.10.4.43
2167    uddiv3EntityKey                 A       1.3.6.1.1.10.4.44
2168    uddiv3EntityCreationTime        A       1.3.6.1.1.10.4.45
2169    uddiv3EntityDeletionTime        A       1.3.6.1.1.10.4.46
2170    uddiBusinessEntity              O       1.3.6.1.1.10.6.1
2171    uddiContact                     O       1.3.6.1.1.10.6.2
2172    uddiAddress                     O       1.3.6.1.1.10.6.3
2173    uddiBusinessService             O       1.3.6.1.1.10.6.4
2174    uddiBindingTemplate             O       1.3.6.1.1.10.6.5
2175    uddiTModelInstanceInfo          O       1.3.6.1.1.10.6.6
2176    uddiTModel                      O       1.3.6.1.1.10.6.7
2177    uddiPublisherAssertion          O       1.3.6.1.1.10.6.8
2178    uddiv3Subscription              O       1.3.6.1.1.10.6.9
2179    uddiv3EntityObituary            O       1.3.6.1.1.10.6.10
2180    uddiBusinessEntityNameForm      N       1.3.6.1.1.10.15.1
2181    uddiContactNameForm             N       1.3.6.1.1.10.15.2
2182    uddiAddressNameForm             N       1.3.6.1.1.10.15.3
2183
2184
2185
2186 Bergeson, et al.             Informational                     [Page 39]
2187 \f
2188 RFC 4403                 LDAP Schema for UDDIv3            February 2006
2189
2190
2191    NAME                            Type    OID
2192    --------------                  ----    ------------
2193    uddiBusinessServiceNameForm     N       1.3.6.1.1.10.15.4
2194    uddiBindingTemplateNameForm     N       1.3.6.1.1.10.15.5
2195    uddiTModelInstanceInfoNameForm  N       1.3.6.1.1.10.15.6
2196    uddiTModelNameForm              N       1.3.6.1.1.10.15.7
2197    uddiPublisherAssertionNameForm  N       1.3.6.1.1.10.15.8
2198    uddiv3SubscriptionNameForm      N       1.3.6.1.1.10.15.9
2199    uddiv3EntityObituaryNameForm    N       1.3.6.1.1.10.15.10
2200
2201    where Type A is Attribute, Type O is ObjectClass, Type N is NameForm
2202
2203    These assignments have been recorded in the following registry:
2204
2205    http://www.iana.org/assignments/ldap-parameters
2206
2207 10.  Normative References
2208
2209    [LDAPv3]  Hodges, J. and R. Morgan, "Lightweight Directory Access
2210              Protocol (v3): Technical Specification", RFC 3377,
2211              September 2002.
2212
2213    [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
2214              "Lightweight Directory Access Protocol (v3): Attribute
2215              Syntax Definitions", RFC 2252, December 1997.
2216
2217    [UDDIdsr] UDDI.ORG, "UDDI version 2.03 Data Structure Reference,"
2218              http://uddi.org/pubs/DataStructure-V2.03-Published-
2219              20020719.htm
2220
2221    [UDDIapi] "UDDI Version 2.04 API Specification",
2222              http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-
2223              20020719.htm
2224
2225    [UDDIv3]  UDDI Version 3.0, Published Specification, 19 July 2002
2226              http://uddi.org/pubs/uddi-v3.00-published-20020719.htm
2227
2228    [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2229              Requirement Levels", BCP 14, RFC 2119, March 1997.
2230
2231    [RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
2232              "Authentication Methods for LDAP", RFC 2829, May 2000.
2233
2234    [RFC2830] Hodges, J., Morgan, R., and M. Wahl, "Lightweight Directory
2235              Access Protocol (v3): Extension for Transport Layer
2236              Security", RFC 2830, May 2000.
2237
2238
2239
2240
2241
2242 Bergeson, et al.             Informational                     [Page 40]
2243 \f
2244 RFC 4403                 LDAP Schema for UDDIv3            February 2006
2245
2246
2247    [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
2248              Considerations for the Lightweight Directory Access
2249              Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
2250
2251    [XML]     Extensible Markup Language (XML) 1.0 (Second Edition) W3C
2252              Recommendation 6 October 2000 http://www.w3.org/TR/REC-xml
2253
2254    [URL]     Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
2255              Resource Identifier (URI): Generic Syntax", STD 66, RFC
2256              3986, January 2005.
2257
2258    [HTTP]    Fielding,  R., Gettys, J., Mogul, J., Frystyk, H.,
2259              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
2260              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
2261
2262 Authors' Addresses
2263
2264    Bruce Bergeson
2265    Novell, Inc.
2266    1800 S Novell Place
2267    Provo, UT  84606
2268
2269    Phone: +1 801 861 3854
2270    EMail: bruce.bergeson@novell.com
2271
2272
2273    Kent Boogert
2274    Novell, Inc.
2275    1800 S Novell Place
2276    Provo, UT  84606
2277
2278    Phone: +1 801 861 3212
2279    EMail: kent.boogert@novell.com
2280
2281
2282    Vijay Nanjundaswamy
2283    Oracle India Pvt. Ltd.
2284    Lexington Towers, Prestige St. John's Woods
2285    #18, 2nd Cross Road,
2286    Chikka Audugodi,
2287    Bangalore 560029
2288    India
2289
2290    Phone: +11 9180 4108 5000
2291    EMail: vijay.nanjundaswamy@oracle.com
2292
2293
2294
2295
2296
2297
2298 Bergeson, et al.             Informational                     [Page 41]
2299 \f
2300 RFC 4403                 LDAP Schema for UDDIv3            February 2006
2301
2302
2303 Full Copyright Statement
2304
2305    Copyright (C) The Internet Society (2006).
2306
2307    This document is subject to the rights, licenses and restrictions
2308    contained in BCP 78, and except as set forth therein, the authors
2309    retain all their rights.
2310
2311    This document and the information contained herein are provided on an
2312    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2313    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2314    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2315    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2316    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2317    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2318
2319 Intellectual Property
2320
2321    The IETF takes no position regarding the validity or scope of any
2322    Intellectual Property Rights or other rights that might be claimed to
2323    pertain to the implementation or use of the technology described in
2324    this document or the extent to which any license under such rights
2325    might or might not be available; nor does it represent that it has
2326    made any independent effort to identify any such rights.  Information
2327    on the procedures with respect to rights in RFC documents can be
2328    found in BCP 78 and BCP 79.
2329
2330    Copies of IPR disclosures made to the IETF Secretariat and any
2331    assurances of licenses to be made available, or the result of an
2332    attempt made to obtain a general license or permission for the use of
2333    such proprietary rights by implementers or users of this
2334    specification can be obtained from the IETF on-line IPR repository at
2335    http://www.ietf.org/ipr.
2336
2337    The IETF invites any interested party to bring to its attention any
2338    copyrights, patents or patent applications, or other proprietary
2339    rights that may cover technology that may be required to implement
2340    this standard.  Please address the information to the IETF at
2341    ietf-ipr@ietf.org.
2342
2343 Acknowledgement
2344
2345    Funding for the RFC Editor function is provided by the IETF
2346    Administrative Support Activity (IASA).
2347
2348
2349
2350
2351
2352
2353
2354 Bergeson, et al.             Informational                     [Page 42]
2355 \f