RFC 4403 - Lightweight Directory Access Protocol (LDAP) Sche(2)

时间:2006-11-02 来源: 作者: 点击:
4.16.uddiKeyedReference TheuddiKeyedReferenceisageneral-purposeattributeforaname- valuepair,withanadditionalreferencetoatModel. (1.3.6.1.1.10.4.16NAME’uddiKeyedReference’ DESC’categorizationinform
  

4.16.  uddiKeyedReference

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

      ( 1.3.6.1.1.10.4.16 NAME ’uddiKeyedReference’
        DESC ’categorization information’
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
      )

   The tModel, keyName, and keyValue of this attribute are separated by
   "#" (e.g., <tModel>"#"<keyName>"#"<keyValue>).  The keyValue is the
   only required portion of the attribute.  With UDDIv3, the tModelKey
   also becomes a mandatory part of the attribute.

   Also, UDDIv3 defines KeyedReferenceGroups for CategoryBags.  A
   keyedReferenceGroup contains a tModelKey and a simple list of
   KeyedReference structures.  The uddiKeyedReference attribute will
   support KeyedReferenceGroups by suffixing the tModelKey for
   KeyedReferenceGroup to each of the keyedReference values associated
   with the group.

   For example, to represent a keyedReference group containing a list of
   2 keyed references, the attribute will hold the following 2 strings
   as its values:

      tModelKey1#KeyName1#KeyValue1#KeyedReferenceGroup1_tModelKey
      tModelKey2#KeyName2#KeyValue2#KeyedReferenceGroup1_tModelKey

4.17.  uddiServiceKey

   This is the unique key for a given uddiBusinessService.  When saving
   a new uddiBusinessService structure, pass an empty uddiServiceKey
   value.  This signifies that a UUID value is to be generated.  To
   update an existing uddiBusinessService structure, pass the UUID value
   that corresponds to the existing service.  If a uddiServiceKey is
   received via an inquiry operation, the key values may not be blank.
   When saving a new or updated service projection, pass the
   uddiServiceKey of the referenced uddiBusinessService structure.

   This attribute is optional when the uddiBindingTemplate data is
   contained within a fully expressed parent that already contains a
   uddiServiceKey value.  If the uddiBindingTemplate data is rendered
   into XML and has no containing parent that has within its data a
   uddiServiceKey, the value of the uddiServiceKey that is the ultimate
   containing parent of the uddiBindingTemplate is required to be
   provided.  This behavior supports the ability to browse through the
   parent-child relationships given any of the core elements as a
   starting point.

      ( 1.3.6.1.1.10.4.17 NAME ’uddiServiceKey’
        DESC ’businessService unique identifier’
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE
      )

4.18.  uddiBindingKey

   This is the unique key for a given uddiBindingTemplate.  When saving
   a new uddiBindingTemplate structure, pass an empty uddiBindingKey
   value.  This signifies that a UUID value is to be generated.  To
   update an existing uddiBindingTemplate, pass the UUID value that
   corresponds to the existing uddiBindingTemplate instance.  If a
   uddiBindingKey is received via an inquiry operation, the key values
   may not be blank.

      ( 1.3.6.1.1.10.4.18 NAME ’uddiBindingKey’
        DESC ’bindingTemplate unique identifier’
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE
      )

4.19.  uddiAccessPoint

   The uddiAccessPoint element is an attribute-qualified pointer to a
   service entry point.  The notion of service at the metadata level
   seen here is fairly abstract and many types of entry points are
   accommodated.  A single attribute is provided named URLType.

   Required attribute-qualified element8: This element is a text field
   that is used to convey the entry point address suitable for calling a
   particular Web service.  This may be a URL, an electronic mail
   address, or even a telephone number.  No assumptions about the type
   of data in this field can be made without first understanding the
   technical requirements associated with the Web service.

      ( 1.3.6.1.1.10.4.19 NAME ’uddiAccessPoint’
        DESC ’entry point address to call a web service’
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE
      )

   The URLType value precedes the accessPoint value by a separating ’#’.

   With UDDIv3, the "URLType" attribute is replaced by a "UseType"
   attribute.  Using this UseType attribute, the accessPoint attribute
   can model a hostingRedirector or support indirection to indicate that
   the accesspoint is specified within a remotely hosted WSDL document.

   For a UDDIv3 registry that needs to support UDDIv2 clients, the
   attribute must allow the representation of URLType and UseType values
   independently.

   The UDDIv3 spec specifies the following logic for mapping values
   between URLType and UseType: If an entity is saved with the v3
   namespace and a v2 inquiry is made, the URLType will be returned as
   "other".  In the case when a v3 inquiry is made on an entity
   published with the v2 namespace, the v3 useType attribute will be
   returned as "endPoint".

   For implementations that need to explicitly model both forms, the
   recommended format is as follows: v2URLType#v3UseType#Address

4.20.  uddiHostingRedirector

   The uddiHostingRedirector element is used to designate that a
   uddiBindingTemplate entry is a pointer to a different
   uddiBindingTemplate entry.  The value in providing this facility is
   seen when a business or entity wants to expose a service description

   (e.g., advertise that it has a service available that suits a
   specific purpose) that is actually a service described in a separate
   uddiBindingTemplate record.  This might occur when a service is
   remotely hosted (hence the name of this element), or when many
   service descriptions could benefit from a single service description.

   The uddiHostingRedirector element has a single attribute and no
   element content.  The attribute is a uddiBindingKey value that is
   suitable within the same UDDI registry instance for querying and
   obtaining the uddiBindingDetail data that is to be used.

   More on the uddiHostingRedirector can be found in the appendices for
   the UDDI Version 2.0 API Specification [UDDIapi].

   Required element if uddiAccessPoint is not provided: This element is
   adorned with a uddiBindingKey attribute, giving the redirected
   reference to a different uddiBindingTemplate.  If you query a
   uddiBindingTemplate and find a uddiHostingRedirector value, you
   should retrieve that uddiBindingTemplate and use it in place of the
   one containing the uddiHostingRedirector data.

      ( 1.3.6.1.1.10.4.20 NAME ’uddiHostingRedirector’
        DESC ’designates a pointer to another bindingTemplate’
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE
      )

   With UDDIv3, the hostingRedirector is a deprecated element, since its
   functionality is now covered by the accessPoint.  For backward-
   compatibility, it can still be used, but it is not recommended.

4.21.  uddiInstanceDescription

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

      ( 1.3.6.1.1.10.4.21 NAME ’uddiInstanceDescription’
        DESC ’instance details description’
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
      )

   The xml:lang value precedes the name value, with the "#" character
   used as the separator.

4.22.  uddiInstanceParms

   The uddiInstanceParms is an optional element of the uddiInstance.  It
   is used to contain settings parameters or a URL reference to a file
   that contains settings or parameters required to use a specific facet
   of a uddiBindingTemplate description.  If used to house the
   parameters themselves, the suggested content is a namespace-qualified
   XML string using a namespace outside of the UDDI schema.  If used to
   house a URL pointer to a file, the suggested format is a URL that is
   suitable for retrieving the settings or parameters via HTTP-GET.

      ( 1.3.6.1.1.10.4.22 NAME ’uddiInstanceParms’
        DESC ’URL reference to required settings’
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE
      )

4.23.  uddiOverviewDescription

   This is an optional repeating element.  This language-qualified
   string is intended to hold a short descriptive overview of how a
   particular uddiTModel is to be used.

      ( 1.3.6.1.1.10.4.23 NAME ’uddiOverviewDescription’
        DESC ’outlines tModel usage’
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
      )

   The xml:lang value precedes the name value, with the "#" character
   used as the separator.

4.24.  uddiOverviewURL

   This is an optional element.  This string data element is to be used
   to hold a URL reference to a long form of an overview document that
   covers the way a particular uddiTModel specific reference is used as
   a component of an overall Web service description.  The recommended
   format for the overviewURL is a URI that is suitable for retrieving
   the actual overview document with an HTTP-GET operation, for example,
   via a Web browser.

      ( 1.3.6.1.1.10.4.24 NAME ’uddiOverviewURL’
        DESC ’URL reference to overview document’
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE
      )

   With UDDIv3, uddiOverviewURL becomes multi-valued to allow the
   representation of multiple OverviewDocs within a single
   InstanceDetail element.

   Modeling multiple OverviewDocs within an InstanceDetail element:

   In UDDIv3, the InstanceDetails element in TmodelInstanceInfo can have
   multiple OverviewDoc’s.  In UDDIv2, we could have only 1 OverviewDoc.
   To retain the grouping between a set of overviewDescriptions and
   overviewURL, we can make both OverviewDoc and OverviewURL multi-
   valued, and have a "group ID" Prefix to each value (to group
   OverviewDescriptions and OverviewURL).

   An example is shown below:

         Overview Description                            OverviewURL
         1#xml:lang#overviewDescription1         1#UseType#overviewURL
         1#xml:lang#overviewDescription2         2#UseType#overviewURL
         1#xml:lang#overviewDescription3         4#UseType#overviewURL
         3#xml:lang#overviewDescription1
         3#xml:lang#overviewDescription2
         4#xml:lang#overviewDescription1

   This implies that OverviewDoc1 has 3 overview descriptions and an
   overviewURL.  OverviewDoc2 has only an overviewURL.  OverviewDoc3 has
   only 2 overviewDescriptions.  OverviewDoc4 also has 1 overview
   description and an overviewURL.

4.25.  uddiFromKey

   The uddiFromKey is a required element.  This is the unique key
   reference to the first uddiBusinessEntity for which the assertion is
   made.

      ( 1.3.6.1.1.10.4.25 NAME ’uddiFromKey’
        DESC ’unique businessEntity key reference’
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE
      )

4.26.  uddiToKey

   The uddiToKey is a required element.  This is the unique key
   reference to the second uddiBusinessEntity for which the assertion is
   made.

      ( 1.3.6.1.1.10.4.26 NAME ’uddiToKey’
        DESC ’unique businessEntity key reference’
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE
      )

4.27.  uddiUUID

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

      ( 1.3.6.1.1.10.4.27 NAME ’uddiUUID’
        DESC ’unique attribute’
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE
      )

   With UDDIv3, this attribute will also be used for unique
   identification of Subscription-feature-related entities.

4.28.  uddiIsHidden

   This is used to provide functionality for the delete_tModel
   operation.  Logical deletion hides the deleted tModels from
   find_tModel result sets but does not physically delete it.

      ( 1.3.6.1.1.10.4.28 NAME ’uddiIsHidden’
        DESC ’isHidden attribute’
        EQUALITY booleanMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
        SINGLE-VALUE
      )

   In case of UDDIv3, this attribute will represent the "deleted"
   attribute value.

4.29.  uddiIsProjection

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

      ( 1.3.6.1.1.10.4.29 NAME ’uddiIsProjection’
        DESC ’isServiceProjection attribute’
        EQUALITY booleanMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
        SINGLE-VALUE
      )

4.30.  uddiLang

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

      ( 1.3.6.1.1.10.4.30 NAME ’uddiLang’
        DESC ’xml:lang value in v3 Address structure’
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE
      )

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

4.31.  uddiv3BusinessKey

   This is the unique UDDIv3 identifier for a given instance of
   uddiBusinessEntity.  It is used in uddiBusinessEntity and
   uddiBusinessService.

   A uddiBusinessEntity will include the uddiBusinessKey (the v2 form)
   for unique identification by UDDIv2 clients.  The uddiBusinessKey
   (36-char) will also be the LDAP naming attribute for the
   uddiBusinessEntity.  The uddiBusinessEntity entry MAY also include
   the uddiv3BusinessKey, the explicit v3 form key, which can be 255
   characters long.

      ( 1.3.6.1.1.10.4.31 NAME ’uddiv3BusinessKey’
        DESC ’UDDIv3 businessEntity unique identifier’
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE
      )

4.32.  uddiv3ServiceKey

   This is the unique UDDIv3 identifier for a given instance of
   uddiBusinessService.  It is used in uddiBusinessService and
   uddiBindingTemplate.

   A uddiBusinessService will include the uddiServiceKey (the v2 form)
   for unique identification by UDDIv2 clients.  The uddiServiceKey
   (36-char) will also be the LDAP naming attribute for the
   uddiBusinessService entry.  The uddiBusinessService entry MAY also
   include the uddiv3ServiceKey, the explicit v3 form key, which can be
   255 characters long.

      ( 1.3.6.1.1.10.4.32 NAME ’uddiv3ServiceKey’
        DESC ’UDDIv3 businessService unique identifier’
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE
      )

4.33.  uddiv3BindingKey

   This is the unique UDDIv3 identifier for a given instance of
   uddiBindingTemplate.

   A uddiBindingTemplate will include the uddiBindingKey (the v2 form)
   for unique identification by UDDIv2 clients.  The uddiBindingKey
   (36-char) will also be the LDAP naming attribute for the

   uddiBindingTemplate entry.  The uddiBindingTemplate entry MAY also
   include the uddiv3BindingKey, the explicit v3 form key, which can be
   255 characters long.

      ( 1.3.6.1.1.10.4.33 NAME ’uddiv3BindingKey’
        DESC ’UDDIv3 BindingTemplate unique identifier’
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE
      )

4.34.  uddiv3TModelKey

   This is the unique UDDIv3 identifier for a given instance of a
   uddiTModel.

   A uddiTModel will include the uddiTModelKey (the v2 form) for unique
   identification by UDDIv2 clients.  The uddiTModelKey (41-char) will
   also be the LDAP naming attribute for the uddiTModel entry.  The
   uddiTModel entry MAY also include the uddiv3TModelKey, the explicit
   v3 form key, which can be 255 characters long.

      ( 1.3.6.1.1.10.4.34 NAME ’uddiv3TModelKey’
        DESC ’UDDIv3 TModel unique identifier’
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE
      )

   The tModelKey is also used in a KeyedReference and in Address
   structures.  In all instances where a tModelKey is used as a
   reference to tModel, the v3 form of the tModel key (viz.
   uddiv3TModelKey) will be the form used, since using the v2 form key
   will require translating it to the v3 key by the UDDI Server, which
   may invalidate the digital signature of the entity.

4.35.  uddiv3DigitalSignature

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

      ..businessEntity
      ..businessService
      ..bindingTemplate
      ..tModel
      ..publisherAssertion

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

      ( 1.3.6.1.1.10.4.35 NAME ’uddiv3DigitalSignature’
        DESC ’UDDIv3 entity digital signature’
        EQUALITY caseExactMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        )

   A Signature element SHOULD be generated according to the required
   steps of "Core Generation" in XML-Signature Syntax and Processing.
   The signature should be calculated on the top-level element that will
   be stored by the registry as a result of the Publication API call.
   This element, referred to as the data object in the XML-Signature and
   Syntax specification, is the businessEntity element for save_business
   API calls, the businessService element for save_service API calls,
   the bindingTemplate for save_binding API calls, the tModel for
   save_tModel API calls, and the publisherAssertion for
   set_publisherAssertions and add_publisherAssertion API calls.

   The signature should be generated on the elements before they are
   added to the body of an API call.  Also, according to the signature
   generation, all children of the element being signed are included in
   the generation of the signature unless first excluded by application
   of a transform.  Due to the containment of service projections as
   businessService elements within a businessEntity element, this also
   means that changes to the projected service will render a signature
   of the businessEntity containing the projection invalid, unless a
   businessService element representing a service projection is excluded
   using a transform.

   Due to the location of the sequence of Signature elements within an
   element that is to be signed, the signature is "enveloped".  As a
   result of the enveloping of the signature, it is necessary to apply
   at least one transformation on the signed entity to exclude the
   signature or signature(s).  The transformation selected by a
   publisher or the XML-Signature tool is specified in a Transform
   element inside the Signature element.

4.36.  uddiv3NodeId

   This attribute contains the Node Identity for a UDDIv3 node.

      ( 1.3.6.1.1.10.4.36 NAME ’uddiv3NodeId’
        DESC ’UDDIv3 Node Identifier’
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE
      )

4.37.  uddiv3EntityModificationTime

   This attribute is used to maintain the last modification time for a
   UDDI entity.  It is needed in the context of maintaining the
   modifiedIncludingChildren element.  When a child entity (e.g.,
   uddiBindingTemplate) is updated, the parent entity (e.g.,
   uddiBusinessService) LDAP timestamp also gets updated.  The
   uddiv3EntityModificationTime attribute saves the last modification
   time of the parent entity (uddiBusinessService in this case).

      ( 1.3.6.1.1.10.4.37 NAME ’uddiv3EntityModificationTime’
        DESC ’UDDIv3 Last Modified Time for Entity’
        EQUALITY generalizedTimeMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
        SINGLE-VALUE
      )

   The following attribute definitions define attributes related to the
   modeling of UDDIv3 subscription-related entities in the LDAP
   directory.

   Subscription provides clients, known as subscribers, with the ability
   to register their interest in receiving information concerning
   changes made in a UDDI registry.  These changes can be scoped based
   on preferences provided with the request.  The uddiv3Subscription
   object class is used to model registered UDDIv3 subscriptions.

4.38.  uddiv3SubscriptionKey

   This is the unique UDDIv3 identifier for a given instance of a
   uddiv3Subscription entity.

      ( 1.3.6.1.1.10.4.38 NAME ’uddiv3SubscriptionKey’
        DESC ’UDDIv3 Subscription unique identifier’
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE
      )

4.39.  uddiv3SubscriptionFilter

   This attribute contains the UDDIv3 Subscription Filter, specified as
   part of the save_subscription API, i.e., the Inquiry API specified as
   filtering criteria with a registered subscription.  The filtering
   criteria limits the scope of a subscription to a subset of registry
   records.  The get_xx and find_xx APIs are all valid choices for use
   as a subscriptionFilter.  Only one of these can be chosen for each
   subscription.

      ( 1.3.6.1.1.10.4.39 NAME ’uddiv3SubscriptionFilter’
        DESC ’UDDIv3 Subscription Filter’
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE
      )

4.40.  uddiv3NotificationInterval

   This attribute contains the Notification Interval string.  It is of
   the type xsd:duration and specifies how often Asynchronous change
   notifications are to be provided to a subscriber.

      ( 1.3.6.1.1.10.4.40 NAME ’uddiv3NotificationInterval’
        DESC ’UDDIv3 Notification Interval’
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE
      )

4.41.  uddiv3MaxEntities

   This attribute contains the maximum number of entities to be returned
   as part of a subscription notification.  It is an integer and
   specifies the maximum number of entities in a notification returned
   to a subscription listener.

      ( 1.3.6.1.1.10.4.41 NAME ’uddiv3MaxEntities’
        DESC ’UDDIv3 Subscription maxEntities field’
        EQUALITY integerMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
        SINGLE-VALUE
      )

4.42.  uddiv3ExpiresAfter

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

      ( 1.3.6.1.1.10.4.42 NAME ’uddiv3ExpiresAfter’
        DESC ’UDDIv3 Subscription ExpiresAfter field’
        EQUALITY generalizedTimeMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
        SINGLE-VALUE
      )

4.43.  uddiv3BriefResponse

   This attribute is a Boolean flag for Brief Response associated with a
   subscription entity.  It controls the level of detail returned to a
   subscription listener.  The default is "false" when omitted.  When
   set to "true", it indicates that the subscription results are to be
   returned to the subscriber in the form of a keyBag, listing all of
   the entities that matched the subscriptionFilter.

      ( 1.3.6.1.1.10.4.43 NAME ’uddiv3BriefResponse’
        DESC ’UDDIv3 Subscription ExpiresAfter field’
        EQUALITY booleanMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
        SINGLE-VALUE
      )

4.44.  uddiv3EntityKey

   This is the unique UDDIv3 identifier for a given instance of a core
   UDDI data structure that is to be logged as an Obituary entry
   uddiv3EntityObituary.  When a core UDDIv3 Entity is deleted and there
   is an active subscription registered against this UDDI Entity, an
   Obituary entry is created, in which the v3 key of the deleted entry
   is logged as part of the uddiv3EntityKey attribute.

      ( 1.3.6.1.1.10.4.44 NAME ’uddiv3EntityKey’
        DESC ’UDDIv3 Entity unique identifier’
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE
      )

4.45.  uddiv3EntityCreationTime

   This attribute is used to log the original Creation Time for a UDDI
   Entity that is deleted in the uddiv3EntityObituary entry.

   It is also used in uddiBusinessService and uddiBindingTemplate.  A
   Move BS operation needs to delete and recreate BT sub-tree due to
   lack of support for moving a sub-tree in many LDAPv3 servers.  This
   attribute is used to save the original creation time of the BT during
   a Move BS.

      ( 1.3.6.1.1.10.4.45 NAME ’uddiv3EntityCreationTime’
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容