text:
UDDI Spec TC |
UDDI Version 2.01 Operator's Specification
UDDI Committee Specification, 19 July 2002
Document identifier:
Latest version:
Luc Clément, Microsoft
Bob Atkinson, Microsoft
Tom Bellwood, IBM
Sharon Boeyen, Entrust
Matthew Dovey
David Ehnebuske, IBM
Greg Eisenberg, Microsoft
Shel Finkelstein, Sun Microsystems
Franz-Josef Fritz, SAP
Tom Glover, IBM
Andrew Hately, IBM
Alan Karp, HP
Sam Lee, Oracle
Wil Marshman, HP
Barbara McKee, IBM
Joel Munter, Intel
Andrew Nielsen, HP
Sachar Paulus, SAP
Venkatesan Ranganathan, HP
Chuck Reeves, Microsoft
Christian Thomas, Intel
The UDDI Spec TC recognizes the contributions of other participants from the UDDI.org Working Group:
Fennivel Chai, DealEasy
UDDI Business Registry Operators Council
This document describes the behavior and operational parameters required of all UDDI Node Operators.
This specification has attained the status of OASIS Standard.
Committee members should send comments on this Committee Specification to the email@example.com list. Others should subscribe to and send comments to the firstname.lastname@example.com list. To subscribe, send an email message to firstname.lastname@example.com with the word "subscribe" as the body of the message.
For information on whether any intellectual property claims have been disclosed that may be essential to implementing this Committee Specification, and any offers of licensing terms, please refer to the Intellectual Property Rights section of the UDDI Spec TC web page (http://www.oasis-open.org/committees/uddi-spec/).
Copyright © 2001-2002 by Accenture, Ariba, Inc., Commerce One, Inc., Fujitsu Limited, Hewlett-Packard Company, i2 Technologies, Inc., Intel Corporation, International Business Machines Corporation, Microsoft Corporation, Oracle Corporation, SAP AG, Sun Microsystems, Inc., and VeriSign, Inc. All Rights Reserved.
Copyright © OASIS Open 2002-2003. All Rights Reserved.
Table of Contents
2 Managing Directory Information
2.4 Operator Resignation from UDDI
2.4.1 Orderly Operator Resignation
2.4.2 Abrupt Operator Resignation
3.1.1 Data Replication Policy Assertions
3.1.2 Data Management, Integrity, and Confidentiality Policy Assertions
3.1.3 Administration (including Privacy) Policy Assertions
3.1.4 Availability Policy Assertions
3.1.6 Policy for Contesting Entries
3.2 Approved Certificate Authorities
4 Data Management Requirements
4.1.1 XML White Space Processing Requirements
4.2.1 Tier 1 Publisher Accounts
4.2.2 Tier 2 Publisher Accounts
4.4.6 Checked Taxonomies and Identifiers
4.4.8 Field Length Restrictions
5.1 Scenarios – Intra-operator Transfer:
5.2 Scenarios – Inter-operator Transfer:
5.3 Custody Transfer Considerations
5.4.3 Custody Transfer Cancellation
5.4.4 Entity Change Restrictions
5.5 Operator Access Point Registration
6.1 UUID Generation Algorithms
7.1 Establishing User Credentials
7.4 Contacting the Administrator
8.1 UDDI Specifications and Documents
8.2 Standards and Other Specifications
Appendix A: External Validation Services for Taxonomies and Identifiers
A.1 Registration and Approval Considerations
A.2 Save_xxx API Considerations
Appendix B: request_transfer (SOAP API)
Appendix C: confirm_transfer (SOAP API)
Appendix D: cancel_transfer (SOAP API)
Appendix E: Element Length Restrictions
Appendix F: Custody Transfer tModel
This document is one of several that define the UDDI Version 2.0 Specification. It covers UDDI Node Operator requirements beyond those specified in the UDDI Version 2.0 Programmer's Reference and the UDDI Version 2.0 Replication Specification. The UDDI Version 2.0 Programmer's Reference provides a short introduction to the UDDI project and describes the public UDDI interfaces. The replication specifications describe the protocol used for UDDI Operator Nodes to synchronize registry information. This document describes the behavior and operational parameters required of all UDDI Node Operators.
There are three primary audiences for this document:
Implementers will find information in this document that defines one required protocol (Custody Transfer)[1], as well as recommendations and the operational behaviors all UDDI Node Operators are required to implement as a part of their UDDI services. The goal of these policies and behaviors is to ensure that UDDI services works smoothly and consistently, both for the user community as a whole, and for the individual Node Operators. The document also touches upon such topics as site security and data management.
This document does not stand alone. In order to fully understand the full scope of the UDDI specifications, each of the documents referenced in Section 9 of this document should be reviewed in detail.
UDDI Node Operators store and provide registration information for business and Web services. This section provides general guidelines for managing and maintaining this information within the UDDI registry.
UDDI registry entries are registered through services provided by any one of the Operator Nodes. These data registration services are defined as the "publish" operations documented in the Programmers API Specification. Publisher registration and custody transfer services are exposed by a Web browser based interface implemented at each Operator Node. An Operator Node is exclusively responsible for allowing the publisher to update or delete directory entries that were originally entered through its interfaces. As such, the Operator Node is described as having 'custody' of the set of registry entries created through its site. No UDDI Operator Nodes are permitted to make changes to entries that were not originally registered at their site. The term 'custody' is used frequently when describing management policies for UDDI information.
When storing information within the UDDI registry, the Node Operator must maintain a valid email address for the publisher of each businessEntity, tModel, and relationship assertion in its custody. This email address must not be accessible outside the Operator Node; either through replication processing between UDDI Operator Nodes or the UDDI APIs. The only exception to this requirement is in the implementation of the Custody Transfer operation described in Section 5 of this document.
Each Node Operator is responsible for durably recording and backing up the information stored in the UDDI registry. The operator may not rely in this regard on the ability to communicate with and receive old changes from other extant Node Operators in order to restore themselves in the face of a system failure or other outage.
The UDDI registry contains multiple types of related information. When making updates to the registered information, the integrity of the overall registry must be maintained.
When deleting information from the UDDI registry, the Node Operator must adhere to the following rules:
For whatever reason, a given Node Operator may cease performing its responsibilities as an operator, including support of the UDDI API and replication protocols. In this case, the process described below must be followed in order to facilitate migration of the information from the resigning Operator Node to the remaining UDDI registry sites.
An orderly resignation of an Operator Node is one that is facilitated and supported by the Node Operator for the duration of the transition period. If an operator determines that they will no longer continue to operate their registry node, they must provide written notification to the remaining UDDI registry sites participating in the replication scheme. The Node Operator must also provide notice to all of its registered publishers and facilitate the transfer of registry information to the other operator sites. The transition period is 45 calendar days from when receipt of notification is acknowledged by the other operators. The process for transition is as follows:
The Node Operator must post a visible notice of their shutdown schedule on their web site.
The Node Operator must provide an email notification to all of its registered publishers indicating that it is no longer operating a UDDI Operator Node, and that entries must be transferred to an alternate Operator Node.
Each publisher must initiate the custody transfer process at the Source Operator[3], and select the Target Operator for their entries to be migrated. The publisher is given a 15 calendar day notice to complete the custody transfer operation.
After 15 calendar days from the initial notification message, a second notification is to be sent to the remaining publisher accounts with entries at the Source Operator. Again, the publisher must be instructed to respond within 15 calendar days and complete the migration to another site.
After a total of 30 calendar days from the initial notification, any remaining entries at the Source Operator are considered 'orphaned'. The registry entries remaining in the custody of the Source Node are processed in the same manner as required by the abrupt resignation described in Section 2.4.2 of this document.
The Source Operator must remain online for at least 15 additional calendar days, or until all other operator nodes have successfully processed all the replication updates, before shutting down. The Source Operator is required to remain online for a maximum of 30 days. If the other Operator Nodes have not successfully processed all the pending updates in that time period, any remaining issues will be resolved out of band through coordination with the other Node Operators participating in the replication cloud.
Once notification that the operator is resigning from UDDI operation is sent to the publishers, it is strongly recommended that the Node Operator no longer accept any new publisher accounts, or additional entries or changes to the registry[4] – either from the Web browser or UDDI programming interfaces. Read, replication, and custody transfer operations must be supported until the site is shut down. Once the final replication file is generated by the resigning Operator Node, no further changes to registry information, or initiation of the custody transfer operation may be permitted at the Source Operator site.
When the Operator Node is shut down, the other Node Operators participating in the replication cloud must update and distribute a revised replication configuration file as appropriate for the remaining Operator Nodes.
Should an operator fail to fulfill its responsibilities for a transition period, and cease operation in an abrupt manner, the UDDI operators will attempt to facilitate the transfer of registry entries to minimize the negative effect on other registered organizations. As account information for each publisher is not available to the other Operator Nodes, this is a best effort activity only, and some information is likely to fail to be transitioned properly.
The other UDDI Node Operators participating in the replication cloud will coordinate distribution of the transition effort amongst themselves. Guidelines are as follows:
businessEntities: Contact information in the orphaned business entities may be used to contact the business or individual responsible for the entry. Should the contact confirm their responsibility for the entry and desire to transfer to another Operator Node, the operator site will coordinate the creation of new publisher accounts, and associating business entities with them.
tModels: Since tModel registry entries do not contain contact information, it is more difficult to determine how to contact the business or individual responsible for them. In this case, manual intervention may be required. As this is an expensive process, only those tModels that are in use (referenced by a bindingTemplate or other registry entry) will be considered for transition. The remaining UDDI Node Operators will make a best effort to determine the contact responsible for the entry through specifications or information in the entry. Should this information not be available, or the expense in manually facilitating the transition be determined too significant by the other Node Operators participating in the replication cloud, the remaining in use tModels will be transitioned in fair proportion to the remaining Operator Nodes and held in 'custody' of the operator's respective publisher account.
Any entries that are successfully transitioned to a new operator will be confirmed at the other UDDI Operator Nodes through the replication process described in the custody transfer protocol.
There are three major categories of security considerations for UDDI: Unauthorized Access, Disclosure of Information and Denial of Service. Each Node Operator is responsible for implementing its own security mechanisms, but all operators need to adhere to certain policies to ensure interoperability and to implement a core set of common security policies.
Inter-operator security and authentication requirements are defined in the UDDI Version 2.0 Replication Specification.
Each operator must have a set of clearly stated policies for data replication, data integrity and confidentiality, availability, administration, and audit registered with the other UDDI operators participating in the replication cloud, and visibly posted on their UDDI registry web site. Each policy subsection below asserts the minimum policies required of every UDDI Node Operator.
Policies for data replication are provided in the UDDI Version 2.0 Replication Specification. Additionally, the following policies must be followed.
This section describes how operators store and modify information, and with who is allowed to modify the information.
Each operator must implement these policy assertions and document them in its policy files.
This section details the efforts required to ensure that users have continued access to UDDI registry information and resources. In the event of an outage at any UDDI Operator Node, all registry information is available from each of the alternate operators. Additionally, each Node Operator must adhere to the following:
Each operator is responsible for collecting audit information for the 12 most recent months of operation and for making this information available to the Operators Council should a dispute be filed with that body. The process of handling a dispute claim is documented in Section 3.1.6 of this document.
As a point of implementation, it should be noted that the requirements for the replication change record journal and the audit log are similar in nature, and can likely share much implementation within a UDDI Operator Node.
Audit requirements are related to interaction through both the API, and replication processing.
The following information is required to be included in the UDDI Node Operator audit trail.
Publisher account: This is a unique identifier for the authenticated account that was used to complete the operation in the UDDI registry. It may be either an internal identifier, or the identifier that is returned as the value of the authorizedName attribute. In either case, the identifier value must be sufficient to uniquely identify a specific publisher account.
Time Stamp: The date and time the operation was performed. This value should be in the standard XML timeInstant[8] data type.
Name of API: The name of the message processed. This value generally corresponds to the name of the first element within the SOAP body of the message. Examples include save_business or delete_tModel.
UUID of major entity(s): The unique identifiers for each registry entry that was changed. These include businessKey, serviceKey, bindingKey, and tModelKey attributes, as well as identifiers for changes to relationship assertions.
Email address: The validated email address that was used by the publisher when their account was created at the Operator Node, and any subsequent updates made by the publisher.
The UDDI Terms of Use require that information published to the UDDI registry be accurate, and that the publisher has authorization from the business to represent them within UDDI. However, unscrupulous individuals may choose to violate this agreement and publish unauthorized information. In this case, the Node Operator should follow the process outlined here in a best effort attempt to address the issue.
In any case, the Node Operator is not responsible for arbitration between the parties, and may choose to remove any entries at any time. An effort should be made to assist in resolving any issues, but only in those cases where it is clear that a business is being misrepresented. All other issues should be settled directly between the parties though established legal processes.
Operators must obtain their X.509 V3 certificate from any of the following Certificate Authorities:
Note that the UDDI operators may certify additional Certificate Authorities. Any additions to this list will be available from the uddi.org web site.
In certificates that the Certificate Authorities issue, the 'issuer name' field will, respectively, be:
Each UDDI operator must adhere to certain rules regarding manipulation and management of registry data. These rules are described below.
Given the use of XML and SOAP within UDDI, an operator must take care to adhere to these standards when processing data. Specific additional requirements layered upon these standards may be included in the UDDI specification. Each operator is responsible for implementing these additional requirements as well as those defined by the published standards.
Leading and trailing white space (space, tab, carriage return, line feed, etc.) must be stripped by operators from all data received before processing such data. Processing includes all functions carried out by an operator once it receives any API call. For example, before performing a query the operator must strip all leading and trailing white space from the query keys. As another example, a business entity to be saved must first have all leading and trailing white space stripped from its fields.
As a matter of explanation, this requirement is intended to address challenges around predictably managing leading white space in terms of searching, name matching, and the like. Removing any leading and trailing white space simplifies the ability to match data values in the registry.
Note that stripping of white space only occurs for element and attribute values. White space between tags must be handled properly per the XML specifications.
Assume for the purposes of this example that the element <desc> has a length limitation of 13. A save request includes the data
<desc>(space)(space)A sample foo string(space)(space)</desc>
where (space) denotes a single white space character. Embedded white space in this example is a single space character as well.
When the text is trimmed, the following results:
<desc>A sample foo string</desc>
Next, truncation to the required field length results in the following:
<desc>A sample foo(space)</desc>
Again, the trailing space is trimmed, and the string that is saved to the registry is:
<desc>A sample foo</desc>
"Garbage" data within UDDI is defined to be useless data either intentionally or carelessly added by users via the publish API defined in the Programmers API Specification. This garbage can impact UDDI in two ways. The primary concern is that garbage not be permitted to collect at such a rate as to actually shut down one or more UDDI operators. This could be, for example, a vast amount of data added to UDDI as a form of a denial of service attack upon the registry.
The secondary concern is that dense groups of garbage data not be permitted to cloud query results for specific entities. For example, a critical mass of data that appears to be related to the "Super Duper Widget Company" but in actuality is not could prevent legitimate users from discerning which of the many query results is the real "Super Duper Widget Company."
In order to make it more difficult for such garbage data to be created, publisher accounts are grouped into two categories, Tier 1 and Tier 2, each of which have different limits on the number of entities they may create. When users attempt to save an entity, which would exceed their limit, the operator must refuse the operation and return the error code E_accountLimitExceeded. See the UDDI Version 2.0 Programmer's Reference for more information.
Each Tier 1 account at an Operator Node is restricted in the number of entities it is allowed to create by default. The default registration limits for these accounts at public UDDI Operator Nodes are listed in the table below. Note that private implementations may implement alternate limits, or may remove publication limits altogether.
Tier 1 Account Limits for Public Registries
Entity Type |
Tier One Publishing Limit |
businessEntity |
1 |
businessServices per businessEntity |
4 |
bindingTemplates per businessService |
2 |
tModels |
100 |
relationship assertions |
10 |
It is often the case that certain users (such as market makers, registrars, and large organizations) have a legitimate need to create more than the limit of entities placed on Tier 1 publisher accounts. To do so, such users must contact their operator to negotiate higher limits. An operator must verify the identity of the user requesting higher limits and must track the new limits of such users. Operators have the right to reject such requests for any reason.
UDDI Operators are required to implement length restrictions on data stored in the registry. The UDDI Version 2.0 Data Structure Reference includes the maximum length for each element and attribute.
If an operator receives data longer than the lengths indicated in the UDDI Version 2.0 Data Structure Reference, it must truncate them to the maximum length before saving to the UDDI registry per the process described in section 4.1.1 above. Note that leading and trailing white space removal must occur before any data truncation. Responses to the request reflect the data actually saved to the registry, which may include elements that have been trimmed and truncated before they were stored.
As an additional comment, it should be noted that the truncation process might, in turn, generate additional trailing white space. This trailing white space must again be truncated before storing the information to the registry.
Implementation Note: Version 1.0 API requests must exhibit version 1.0 compliant behavior for all information in the UDDI registry - including that information saved through version 2.0 interfaces. This impacts two areas. Data exceeding the version 1.0 field size limitations must be properly truncated to the version 1.0 size limits before the response is returned to the caller. Second, additional elements and attributes introduced by the version 2.0 specification may not be returned in response to a version 1.0 request.
Each UDDI node operator is required to validate XML messages, and required restrictions on the data before processing. The following validation checks must be performed before performing a save_xxx operation, and before accepting replication data from other nodes. In all cases, if one of the errors listed below is detected in an inbound replication stream, the request may not be saved to the registry, and replication processing is stopped until the issue is resolved at the source operator.
Each Node Operator must validate incoming data against both the API Replication, and Custody Transfer XML schemas as a part of all operations processing registry data. The error code returned in this case is E_fatalError. The error text will clearly indicate the nature of the problem processing the message.
All XML messages must be encoded in UTF-8. The encoding attribute must be present in the message. If the encoding is incorrect, or not present, an error is generated.
The error code returned in this case is E_fatalError. The error text will clearly indicate the nature of the problem processing the message.
The UUID must be in the format XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX (8-4-4-4-12) where each character is a hexadecimal value from the set {A-F,a-f,0-9}. UUIDs are case insensitive (upper and lower case character values are equivalent). UUIDs for tModels must be prepended with the identifier 'uuid:' in all locations where they are present. The node operator must verify that these requirements are met when processing requests. Otherwise, an error is generated.
The error code returned in this case is E_fatalError. The error text will clearly indicate the nature of the problem processing the message.
All data references that contain UUID keys of other data in fact refer to data that actually exists in the data store. Specifically, this means that:
Of these, the first requirement is pragmatically the most significant, since tModels are often created, updated, and referenced independently from the other top level elements, whereas these other elements are typically created and updated together in the same location.
If UUID reference checks fail for any of the reasons listed above, the error code returned is E_invalidKey. The error text returned should include the UUID referenced, and where in the message it was included.
Each UUID stored must be verified to be unique. The Operator Node must not allow the generation or storage of a UUID that is already present somewhere in the registry. This applies to both the Operator Node where the entry was originally saved, and all other Operator Nodes where the entries are saved upon replication processing.
When saving new or updated registry entries with checked taxonomy or identifier values, these keys must be verified by each operator.
The error code returned in this case is E_invalidValue. The error text returned should include the taxonomy or identifier UUID and name, and the value included in the request that was detected to be in error.
Only the custodian Operator Node may originate change records that update or otherwise change the contents of data.
The error code returned in this case is E_userMismatch.
Each operator must verify field length restrictions before processing updates to the UDDI registry. On inbound replication, entries returned from other operators must be checked to verify that the required truncation of entries was completed before the information was saved to the originating operator.
On a save operation, any fields exceeding length restrictions established for the version of the UDDI specification indicated are truncated before they are saved to the registry. The response message contains the actual values saved to the registry. It is the responsibility of the client application to detect whether any of the data was truncated due to exceeding length restrictions.
On an inquiry operation, any fields exceeding length restrictions established for the version of the UDDI specification indicated are truncated before they are returned to the caller.
Violation of field length restrictions halts replication processing, but UDDI API requests truncate the data per the UDDI specifications.
Each operator must verify leading and trailing white space removal before processing updates to the UDDI registry. On inbound replication, entries returned from other operators must be checked to verify that the required leading and trailing white space removal was completed before the information was saved to the originating operator.
Violation of the white space removal requirements halts replication processing, but UDDI API requests remove white space per the UDDI specifications.
The UDDI Business Registry contains entries representing service types and businesses. Each entry in the registry is associated with exactly one publisher account and node operator. There are a number of scenarios where the publisher may choose to transfer one or more of its registry entries to an alternate publisher account, and/or to another UDDI registry node operator.
The simpler case is that of transferring entries between two accounts that are registered at the same Operator Node. Usage scenarios for this type of custody transfer include the following:
The more complex case is the transfer of a set of entries across node operators, and by extension, across publisher accounts. All of the above scenarios apply, as well as those listed below.
Unsatisfactory service level: The functionality or service level provided by a given operator node is insufficient, and the publisher wishes to move their information to another site.
Change in availability for an operator node: An operator is no longer providing UDDI services, and all publisher accounts need to be migrated to an alternate.
Business Mergers, Acquisitions, or Consolidations: Changes in organizational structure may result in the need to make changes to the set of publisher accounts used to manage the registry entries.
For any of these scenarios, a consistent mechanism is provided to facilitate the transfer of information across publisher accounts or operator nodes.
It is expected that the entity custody transfer operation will not occur frequently. This activity is generally the result of employee or organizational changes, or consolidation of registry entries across publishers. An exceptional case is a change in the set of available registry operator sites. In this release, operation performance (in terms of time to complete the transfer) is not considered a high priority.
Public UDDI interfaces supporting custody transfer initiation will not be provided in this release of the UDDI specifications. The presence of these interfaces may introduce security and integrity issues that are not as prevalent with a browser-based manual initiation.
Only businessEntity, tModel, and related relationship assertion entries can be transferred between publisher accounts. When a businessEntity is transferred, all related business services and corresponding bindings are transferred as well. The Target Operator needs to take care to update change permissions on all sub-elements as a part of the transfer operation.
Complexity in the entity transfer process is introduced by the need to precisely correlate publisher accounts together across operator nodes[9]. During this process, explicit manual confirmation by the account owners is required.
Note that the Source Publisher (see below) is not required to transfer all of its entries in a single Custody Transfer request, nor is it required to transfer all of its entries to the same Target Publisher or Target Operator. Any combination or subset of UDDI registry entries may be transferred to any number of target publishers or Node Operators.
Transfer of information between operator nodes is a multi-step process requiring coordination between both operators and publishers. The process is initiated and confirmed manually by the publishers, with additional interaction between the operator nodes through both UDDI API and replication stream updates. The transfer operation is further secured through the out of band exchange of a shared secret between the source and target publishers.
The Node Operator may only respond to UDDI API requests related to custody transfer if they are initiated by a recognized UDDI Operator Node. This verification should be established through the same security mechanisms defined by the UDDI Version 2.0 Replication Specifications.
The interaction diagram below includes the following roles. It describes the roles and communication between operators and publishers in completing a successful registry entry transfer.
Source Publisher: The individual originating the transfer request. This individual is identified with its corresponding publisher account at the Source Operator.
Source Operator: The custodian operator for the registry entities before the transfer operation is completed (the "from" operator node).
Target Publisher: The publisher account where the registry entities are being transferred to.
Target Operator: The target custodian operator for the registry entities (the "to" Operator Node).
All Operators: All the UDDI Operator Nodes except the source node.
Figure 1: Custody Transfer Process
Execution of the custody transfer operation requires multiple steps. The six primary steps are described in the following sections.
Step A: The source publisher provides a shared secret to the destination publisher. This shared secret acts as a verification mechanism to ensure that the destination publisher is indeed the desired individual. Before initiating the transfer operation, this information is exchanged through a private, out of band, mechanism such as a phone call, fax, secure email, or other means. It must not be shared with anyone other than the target publisher and Source Operator. When initiating the transfer operation at the source operator site, the source publisher will be required to provide this information.
Step B: The source publisher requests transfer of one or more of its registry entries. The publisher may request the transfer of businessEntities and/or tModels. Publisher assertions are transferred with businessEntities. The publisher may not request the transfer of businessServices or bindingTemplates, as these are contained within their parent businessEntity, and may not be separated.
Each Node Operator must provide a user interface feature to allow the publisher to manage the registry entries they have published. Publishers accessing this feature must be authenticated and secured using the same mechanism used to protect registry entries from unauthorized update or deletion. For each entity eligible for transfer (businessEntity or tModel), the publisher must be able to indicate which UDDI node operator and destination publisher account the entry is to be transferred to. The list of operators presented to the user must match the registration list included within the UDDI Node Operator identifiers[10]. For each transfer group, the source publisher must provide a shared secret. This information is included in the request_transfer message passed to the target operator.
The user interface must require the confirmation of the transfer request before initiation of the transfer process. The confirmation prompt must indicate the Target Operator, target publisher, name[11] and key[12] for each registry entry to be transferred. The shared secret must not be displayed. The source publisher must also be given the option to cancel the transfer request at any time before Step G (this is described in more detail later).
Step C: Once the source publisher manually confirms the transfer request, the Source Operator makes a UDDI API request to the Target Operator to provide notification of the transfer request.
The request_transfer message is posted to the Target Operator, and includes the keys for the registry entries being transferred. Note that multiple keys may be transferred within a single transfer request.
Step D: Once the transfer request is received by the Target Operator, the transfer must be verified by the target publisher account holder. A confirmation email message is sent to the target publisher indicated in the publisherEMail element transmitted in the request_transfer message.
The confirmation email message sent to the target publisher account holder is as follows:
To: publisherEMail
Subject: UDDI Transfer Confirmation Request
The following UDDI entity transfer has been requested. Please confirm the transfer to the publisher account by following the link below and the instructions provided there.
Transfer Group Key:
Transfer Group:
Key Type Key Name Key Value
(type) (name) (uuid)
Source UDDI Node Information
Publisher Name: authorizedName
Publisher Email: publisherEMail
Operator: sourceOperator
Target UDDI Node Information
Operator: targetOperator
Confirmation URL: URL
The values indicated in italics above are transmitted in the request_transfer API request. Those for Key Type (businessKey or tModelKey), Key Name (value of the description element), and Key Value (the UUID for the registry entry) are obtained directly from the UDDI registry. Each key should be listed along with its name value on individual lines in the message. The Target Operator generates the Confirmation URL in order to process the transfer request confirmation.
Step E: Upon receipt of the transfer confirmation email message, the target publisher manually follows the embedded hyperlink (URL) provided in the Confirmation URL value to the Target Operator node. This link ultimately resolves to a page hosted at the Target Operator site where the publisher can complete (confirm or cancel) the transfer operation.
When the link is followed, the user must be precisely matched to a publisher account at the Target Operator site. If the publisher already has an account at the target node, they must be authenticated using that account information before confirming the transfer operation. If no account is present, they may be presented with an option to create a new account at transfer time. In either case, the publisher must be authenticated before being allowed to confirm the transfer.
Once authenticated, the target publisher must be prompted to enter the value of the shared secret as was provided by the source publisher. The shared secret values must match exactly. If the values do not match exactly, the target publisher may not be granted access to the transfer request information. Otherwise, the target publisher is presented with information regarding the transfer request, matching the original notification email message. The target publisher must be allowed to either confirm or cancel the transfer operation.
Note: Only five unsuccessful attempts to match the shared secret are allowed for any one custody transfer operation. On the fifth attempt, the target operator must cancel the transfer request by sending a cancel_transfer message to the source operator. An indication should be provided to the target publisher to indicate that they have exhausted the allowed number of attempts, and that the transfer operation must be re-initiated by the source publisher in order to proceed.
Step F: Confirmation of the request is reported back to the Source Operator through a confirm_transfer API message. If the transfer request is cancelled, a cancel_transfer API request is sent to the Source Operator. The syntax for both of these requests is included in the Appendix of this document.
Step G: This step applies when the transfer operation has been confirmed through the receipt of a confirm_transfer request at the Source Operator node. If the request has not been cancelled by the source publisher, the Source Operator relinquishes custody of the registry entry by creating a custodyTransfer replication journal entry. Once this entry is created, custody transfer is released, and all subsequent updates must be processed at the target UDDI registry site.
When this journal entry is processed by the Target Operator, the values of the operator and authorizedName attributes are changed to reflect the information at the Target site. Additionally, the value of the discoveryURL element for the businessEntity useType is updated to reflect the new URL used to access the XML representation of the businessEntity at the new operator site. Note that multiple discoveryURL elements may be present in the business entity. The Target Operator may only change the entry for the discoveryURL for the useType of businessEntity.
The custody transfer operation can be cancelled at any time before the custodyTransfer journal entry is created.
The source publisher may return to the Source Operator site and cancel the operation through the user interface. The UDDI node operator must provide this functionality as a part of the custody transfer functionality. If the operation is cancelled at the source site, the corresponding confirm_transfer request that may be sent by the target operator results in the E_transferAborted Fault being returned.
If the target publisher does not accept the custody transfer, a cancel_transfer message is transmitted to the Source Operator site, and custody remains with the original publisher.
Note that cancellation of the transfer request applies to the entire transfer group. The set of keys included in a transfer group are processed as a single batch.
The publisher may make changes to the entity to be transferred at any time before the confirm_transfer message is received at the Source Operator. Any changes made before the confirm_transfer API message is received and processed by the Source Operator node will be correctly handled by the standard replication process. Once the custodyTransfer replication journal entry is created, no additional updates are allowed at the Source Operator, and custody is formally relinquished to the Target Operator.
Note: There is a small time window when the transferred entity may not be updated at any operator site. This occurs for the period between when the Source Operator creates the custodyTransfer entry in the replication stream, and when the registry entry is processed at the target site and the new publisher account is associated with the registry entry.
Each UDDI Node Operator must register the access point for the Custody Transfer Protocol tModel. To protect against Denial of Service attacks, or unauthorized attempts to access the service, the hostingRedirector functionality may be used as desired by the Node Operator.
Heavy use is made of UUIDs within UDDI. Operators are responsible for creating these UUIDs and must make certain that the process of creating these is a correct one. For versions 1.0 and 2.0 of the UDDI specification, operators are required to use the DCE UUID generation algorithm as defined below. This section describes the accepted UUID generation algorithms.
A number of algorithms for generating UUIDs are described in the following reference.
Implementation of these algorithms has been approved for use within UDDI Node Operator implementations. Additionally, careful consideration must be made in determining which algorithm is selected for a given implementation, and that the random number-based approach includes generation of truly random numbers.
The UDDI operators reserve the right to review the algorithm used to generate UUIDs as implemented by a new public UDDI Node Operator, as well as a large sample set of values generated by the algorithm, prior to the public site becoming part of the production cloud.
It is also important to note that a number of checks on the GUID generation and formatting are required by the public UDDI Operator Nodes. These verification steps are outlined in section 4.4 of this document.
Establishing User Credentials: This user interface will allow an individual or business (a publisher) to establish a login and password on a particular UDDI operator node.
Account Activation: This interface allows a publisher to enable their account at a given Operator Node.
Changing Ownership of Business Entities and tModels: This user interface will allow an owner of Business Entities and/or tModels to transfer ownership to another publisher account. Details on the custody transfer process are provided in section 5.
Contacting the Administrator: This interface allows anyone to contact the administrator of the UDDI Operator Node.
Before publishers are allowed to register information at an operator node, they need to establish an account with the operator. The process for this is operator-specific but must meet the minimum criteria explained here.
It is essential that there is a mechanism to identify a name and email of a contact for any entity that registers business entities in UDDI. Although this data is not reflected in the schema provided by UDDI, it should be stored and obtainable by an operator for business entities mastered in their specific operator instance. This information may not be left blank in the registration – valid values must be obtained through verification of the email address (and a response received via email from that account). User information may not be shared publicly, or with the other Operator Nodes[14]. The only account information that is visible outside a given Operator is the public identifier for the publisher.
An operator is required to collect this information via an HTML 3.2 user interface on the operator's UDDI web site. An operator must also provide a means via this HTML user interface to update the user's credentials (to change a password, for example).
Each operator must obtain an indication of acknowledgment of the operator policies by the registrant for audit purposes. Section 3.3 of the UDDI Operators Agreement identifies non-compliance concerns and operator responsibilities for complying with Third Party audits.
Although the user registers with the operator and establishes an account at the operator node, the account itself is not activated until the user completes the activation procedure. To require an account to be "activated" means that all UDDI APIs that require authentication will fail until the account is activated.
For the account to be activated, the operator must email the user instructions in plain text that identifies a website for the user to visit to actually activate the account. The email must describe clearly the purpose for this activation and how to perform it. The activation website may require no more than that the user supply the account's authentication credentials in order to activate the account.
A UDDI Node Operator must provide an HTML 3.2 user interface to permit a user to transfer ownership of data it currently owns to another user. The protocol for transfer of registry entries is fully described in Section 5 of this document.
A UDDI Node Operator must provide a mechanism to contact the site administrator via Email.
Communication with the UDDI Node Operator User Interface must be secured via SSL all operations where passwords, security information, or registry entry changes are communicated, as well as all authenticated operations on registry data. This includes, but is not limited to, the following items:
This document refers to other UDDI documents as well as several widely recognized standards and specifications. Detailed information on these may be found as follows:
UDDI Version 2.0 Operator's Specification (this document)
UDDI Version 2.0 Custody Transfer Schema
UDDI Version 2.0 Programmer's API Specification
UDDI Version 2.0 API Schema
UDDI Version 2.0 Replication Specification
UDDI Version 2.0 Replication Schema
UUID Generation Algorithms
XML Schema
http://www.w3.org/TR/2001/PR-xmlschema-0-20010330 http://www.w3.org/TR/2001/PR-xmlschema-1-20010330
X.509 V3 Certificate
This appendix describes the UDDI Node Operator requirements related to support of external taxonomy and identifier validation services. Details of the protocol and supporting interfaces are described in the UDDI Version 2.0 Programmer's API Specification. Throughout this section, any requirements for validating taxonomy values also apply to validating identifier values.
A.1 Registration and Approval Considerations
A hosting redirector is used to pair this bindingKey with the access point and caching option provided by the service provider. Redirection is usually handled by the operator, but can be delegated to a redirector service provided by someone else, often the taxonomy provider.
The tModelKey of the taxonomy and the tModelKey of the uddi-org:taxonomy tModel must be placed into the approved service binding's tModelInstanceInfo structure. This enables the validation service for the particular taxonomy to be found by all of the operators.
An operator must place all of the bindingTemplates for the same service (those sharing the same specification tModel) under the same businessService.
A.2 Save_xxx API Considerations
Save behavior described by this section applies whenever an entity is saved which has an associated identifierBag or categoryBag.
Breaking the path to the accessPoint in the hostingRedirector service.
Asking the validating taxonomy provider to categorize its tModel as unvalidatable. After a replication cycle, attempts to categorize with this taxonomy will thus be rejected until it is made available again. Existing references to this taxonomy remain valid in subsequent saves.
Having the custodial operator mark the taxonomy's tModel as unvalidatable. This has the same effect as the option above.
Removing the approved validation service from the custodial operator's operational businessEntity. This is a last resort for rogue providers since this has the affect of making the taxonomy or identifier system non-validating. If the tModel has been referenced at all, subsequent attempts to gain approval for another validation service for the tModel will fail.
The source UDDI node operator posts a request to the Target Operator to initiate the custody transfer operation. The request_transfer message includes the key to be transferred, operator identifiers, and information about the publisher account
<request_transfer generic="2.0" xmlns="urn:uddi-org:custody_v2">
<registryKey businessKey | tModelKey />…
<?xml version="1.0" encoding="UTF-8" ?>
<Envelope xmlns=http://schemas.xmlsoap.org/soap/envelope/>
<request_transfer generic="2.0" xmlns="urn:uddi-org:custody_v2">
<api:authInfo>---authorization token here---</api:authInfo>
<sharedSecret>my dog has fleas and the weather is warm today. enter this secret information in order to access the custody transfer information.</sharedSecret>
Note: The Operator Node may only respond to requests made by other recognized operators. Otherwise, an E_requestDenied Fault must be returned.
On success, this operation returns a SOAP Fault with the error number set to E_success.
If any error occurs in processing this message, a dispositionReport structure will be returned to the caller in a SOAP Fault. The following error number information will be relevant:
E_authTokenExpired: signifies that the authentication token value passed in the authInfo argument is no longer valid because the token has expired.
E_authTokenRequired: signifies that the authentication token value passed in the authInfo argument is either missing or is not valid.
E_invalidKeyPassed: This error is returned when either the key does not exist, is of the wrong type.
E_requestDenied: This error is returned if the Target Operator does not accept the custody transfer, or the requestor is not an authorized Operator Node.
E_unsupported: This error is returned if the custody transfer protocol is not implemented by the Target Operator.
E_userMismatch: signifies that the UUID key value passed in the request refers to data that is not controlled by the individual who is represented in the authentication token.
When a custody transfer operation is confirmed, the Source Operator is notified of the result of the operation through a confirm_transfer request. This request is triggered by the manual action of the target publisher at the Target Operator web site.
<confirm_transfer generic="2.0" xmlns="urn:uddi-org:custody_v2">
Note that this message is similar to the request_transfer message, in that the values of the elements transmitted are the same, with the exception of the authorizedName. The authorizedName is changed to the new account identifier at the Target Operator site.
The email address of the publisher at the target site is not shared with the Source Operator node.
<?xml version="1.0" encoding="UTF-8" ?>
<Envelope xmlns=http://schemas.xmlsoap.org/soap/envelope/>
<confirm_transfer generic="2.0" xmlns="urn:uddi-org:custody_v2">
<authInfo>---authorization token here---</authInfo>
When received by the Source Operator, this message serves as notification to change the registry entry and broadcast the update through the replication stream. This message triggers a custody_transfer journal entry to be created for the entry. All subsequent changes to this entry are made at the destination operator site.
The operation must be successful for all keys in the transferGroup. Otherwise, a SOAP Fault is generated.
Note: The Operator Node may only respond to requests made by other recognized operators. Otherwise, an E_requestDenied Fault must be returned.
On success, this operation returns a SOAP Fault with the error number set to E_success.
If any error occurs in processing this message, a dispositionReport structure will be returned to the caller in a SOAP Fault. The following error number information will be relevant:
E_authTokenExpired: signifies that the authentication token value passed in the authInfo argument is no longer valid because the token has expired.
E_authTokenRequired: signifies that the authentication token value passed in the authInfo argument is either missing or is not valid.
E_invalidKeyPassed: This error is returned when either the key does not exist, is of the wrong type.
E_requestDenied: This error is returned if the Target Operator does not accept the custody transfer, or the requestor is not an authorized Operator Node.
E_transferAborted: signifies that the source publisher cancelled the transfer request. The custody transfer will not be completed.
E_userMismatch: signifies that the UUID key value in the passed in the transferKey refers to a transfer group that is not available to the target operator who is represented in the authentication token.
cancel_transfer (SOAP API)
When a custody transfer operation is cancelled, the Source Operator is notified of the result of the operation through a cancel_transfer request. This request is triggered by the manual action of the target publisher at the Target Operator web site.
<cancel_transfer generic="2.0" xmlns="urn:uddi-org:custody_v2">
Note that this message is similar to the request_transfer message, in that the values of the elements transmitted are the same.
<?xml version="1.0" encoding="UTF-8" ?>
<Envelope xmlns=http://schemas.xmlsoap.org/soap/envelope/>
<cancel_transfer generic="2.0" xmlns="urn:uddi-org:custody_v2">
<authInfo>---authorization token here---</authInfo>
When this request is received by the Source Operator, the pending custody transfer request is cancelled. The publisher may no longer confirm the transfer at the Target Operator site, or cancel the request again at the source. Any subsequent operations on the listed entities must be reinitiated at the source UDDI registry node.
The errInfo element must be populated will additional details regarding the reason for the transfer cancellation. The value of the errCode attribute must be one of the following:
Note: The Operator Node may only respond to requests made by other recognized operators. Otherwise, an E_requestDenied Fault must be returned.
On success, this operation returns a SOAP Fault with the error number set to E_success.
If any error occurs in processing this message, a dispositionReport structure will be returned to the caller in a SOAP Fault. The following error number information will be relevant:
E_authTokenExpired: signifies that the authentication token value passed in the authInfo argument is no longer valid because the token has expired.
E_authTokenRequired: signifies that the authentication token value passed in the authInfo argument is either missing or is not valid.
E_invalidKeyPassed: This error is returned when either the key does not exist, is of the wring type.
E_requestDenied: This error is returned if the Target Operator does not accept the custody transfer, or the requestor is not an authorized Operator Node.
E_userMismatch: signifies that the UUID key value in the passed in the transferKey refers to a transfer group that is not available to the target operator who is represented in the authentication token.
The table below describes the data types and maximum length restrictions for each element used in the custody transfer protocol. Note that many of these elements have been previously been described in the UDDI Version 2.0 API Specification. The name of the element reused from the API specification.
Name |
Data Type and Length |
Reference |
authInfo |
see UDDI API Specification (authInfo) |
authorizedName |
see UDDI API Specification (authorizedName) |
sharedSecret |
string (255) |
sourceEmail |
string (255) |
targetEmail |
string (255) |
sourceOperator |
see UDDI API Specification (operator) |
targetOperator |
see UDDI API Specification (operator) |
businessKey |
see UDDI API Specification (businessKey) |
tModelKey |
see UDDI API Specification (tModelKey) |
requestExpiration |
timeInstant |
errInfo |
see UDDI API Specification (errInfo) |
errCode |
see UDDI API Specification (errCode) |
The Core tModel for the Custody Transfer protocol is as follows:
<description xml:lang="en">UDDI Custody Transfer API Version 2.0</description>
<description xml:lang="en">This tModel defines the custody transfer API calls for the UDDI registry.</description>
Copyright © 2001-2002 by Accenture, Ariba, Inc., Commerce One, Inc., Fujitsu Limited, Hewlett-Packard Company, i2 Technologies, Inc., Intel Corporation, International Business Machines Corporation, Microsoft Corporation, Oracle Corporation, SAP AG, Sun Microsystems, Inc., and VeriSign, Inc. All Rights Reserved.
These UDDI Specifications (the "Documents") are provided by the companies named above ("Licensors") under the following license. By using and/or copying this Document, or the Document from which this statement is linked, you (the licensee) agree that you have read, understood, and will comply with the following terms and conditions:
Permission to copy, prepare derivative works based on, and distribute the contents of this Document, or the Document from which this statement is linked, and derivative works thereof, in any medium for any purpose and without fee or royalty under copyrights is hereby granted, provided that you include the following on ALL copies of the document, or portions thereof, that you use:
1. A link to the original document posted on uddi.org.
2. An attribution statement : "Copyright © 2000 - 2002 by Accenture, Ariba, Inc., Commerce One, Inc. Fujitsu Limited, Hewlett-Packard Company, i2 Technologies, Inc., Intel Corporation, International Business Machines Corporation, Microsoft Corporation, Oracle Corporation, SAP AG, Sun Microsystems, Inc., and VeriSign, Inc. All Rights Reserved."
If the Licensors own any patents or patent applications that may be required for implementing and using the specifications contained in the Document in products that comply with the specifications, upon written request, a non-exclusive license under such patents shall be granted on reasonable and non-discriminatory terms.
EXCEPT TO THE EXTENT PROHIBITED BY LOCAL LAW, THIS DOCUMENT (OR THE DOCUMENT TO WHICH THIS STATEMENT IS LINKED) IS PROVIDED "AS IS," AND LICENSORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, ACCURACY OF THE INFORMATIONAL CONTENT, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE DOCUMENT ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY OR (WITH THE EXCEPTION OF THE RELEVANT PATENT LICENSE RIGHTS ACTUALLY GRANTED UNDER THE PRIOR PARAGRAPH) LICENSOR PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. Some jurisdictions do not allow exclusions of implied warranties or conditions, so the above exclusion may not apply to you to the extent prohibited by local laws. You may have other rights that vary from country to country, state to state, or province to province.
EXCEPT TO THE EXTENT PROHIBITED BY LOCAL LAW, LICENSORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL DAMAGES, OR OTHER DAMAGES (INCLUDING LOST PROFIT, LOST DATA, OR DOWNTIME COSTS), ARISING OUT OF ANY USE, INABILITY TO USE, OR THE RESULTS OF USE OF THE DOCUMENT OR THE PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS THEREOF, WHETHER BASED IN WARRANTY, CONTRACT, TORT, OR OTHER LEGAL THEORY, AND WHETHER OR NOT ANY LICENSOR WAS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Some jurisdictions do not allow the exclusion or limitation of liability for incidental or consequential damages, so the above limitation may not apply to you to the extent prohibited by local laws.
Copyright © OASIS Open 2002-2003. All Rights Reserved.
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.
OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
[1] The Custody Transfer tModel is but one of several tModels defined for UDDI. Please refer to the remainder of the UDDI Specifications for more information.
[2] Note that deletion of the businessService may result in the deletion of bindingTemplates as described immediately below.
[3] See section 5 for the Custody Transfer protocol definition, and descriptions of source and target operator sites.
[4] While each operator may determine their own approach to this, one alternative to consider is implementing this restriction through lowering publishing limits to zero for each account.
[5] See Section 9 of this document for details on obtaining SSL specifications.
[6] USNs are defined in the UDDI Version 2.0 Replication Specification.
[7] USNs are defined in the UDDI Version 2.0 Replication Specification.
[8] See the UDDI Version 2.0 Replication Specification for additional references to the timeInstant data type.
[9] In the UDDI Version 2.0 timeframe, node operators do not share user account information. The transfer process facilitates sharing of sufficient account detail information to complete the operation.
[10] A tModel has been established for the checked identifier set of UDDI Operator Nodes.
[11] The value in the <name> element for the entity to be transferred.
[12] The value of the businessKey or tModelKey attribute for the entity to be transferred.
[13] This document will also be available for download from the uddi.org web site.
[14] With the exception of the information required to execute the Custody Transfer protocol.


text:
In this Sprint Round Record Recap, we discuss Joe Lawhorn - Cyclist's recent world records crossing the US state of Ohio from East to West (233 miles) and then back again for a total of 466 miles! Joe also holds the record for the Ohio single crossing from West to East. Congratulations, Joe! Let's roll!
--- Support this podcast: https://podcasters.spotify.com/pod/show/ultracyclingshow/support

subset: commoncrawl


text:
C&K Components has developed the KLT Series of top-actuated pico switches. Employing a small 1.4mm dome within a patented new type of switch structure that represents a significant reduction in size of the existing KMT Series of nano switches, the KLT Series switches are ideal for mobile phones and handheld MP3 player accessories as well as any other professional devices where compact packaging is of the essence.
Featuring actuation forces of 1.0N, 1.6 and 2.2N, the KLT Series switches have a 30% tactile minimum and measure 2.7 x 1.85 x 0.55mm. The halogen free and RoHS-compliant switch is currently in the prototype stage, and features a 300,000-cycle lifespan along with IP-68 rated sealing.
"The goal of the KLT Series design is to facilitate simple integration within existing systems that require more space savings than are typically afforded by other miniature pushbutton switches," said Jerome Smolinski, senior product manager at C&K Components. "The KLT Series, with its extended lifespan and rugged design by way of advanced films and strong metal bases, will be the ideal choice for designers working with limited space but who cannot afford to sacrifice switch or signal quality."
The KLT Series switches feature a small footprint and the highest number of cycles within the smallest packaging. The momentary action pushbutton switch has a maximum power rating of .5VA, maximum voltage rating of 32VDC, and is fully functionality within a temperature range of -40ºC to 85ºC.
C&K Components
Part Number: KLT


text:
6m x 10m PVC 500gsm Marquee
6m x 10m PVC 500gsm Marquee with Belgiam PVC covers with End Gable supports, eaves support bars individual interchangeable windows, walls and doors. Hire Quality for your event and more.
- 500gsm Belgian PVC
- Steel Galvanised Frame (Rust Free)
- Hire Quality Marquee
- Holds 90 People
- Fully Waterproof & Windproof
- Re-enforced Frame For Extra Stability
- Delivery 2-3 working days
6m x 10m Commercial Marquee 500gsm PVC for Sale:
Why Bigmarquee:
- Designers of PVC Marquees in the UK for over 20 years, our engineers ensure continual improvement on design.
- We are confident that our structures are the highest quality 500gsm PVC Marquees in the UK.
- Most noteworthy being the use of higher grade Belgian PVC and not the much cheaper Chinese alternative.
- Even more re-enforced and supported where they need to be.
- As a result we're proud that our marquees will last many years and weather many storms, not just good for one event.
- Many returning customers like The British Army, The National Trust, The Caravan Club & hire companies due to our professional conduct.
- Consequently festivals like Glastonbury and Download always use us again and again.
- We're popular because we make sure that we don't lower the quality of our marquees for sale to increase profits.
- Finally, our marquees are the choice of the professionals and this is why the professionals use bigmarquees.
Also Order With This Marquee:
- Roof Lining
- Curtain Linings
- Marquee Carpet Flooring
- Tie Down Kit
- Lighting
- Marquee Walkway
- Heaters
- Gutter
- Marquee Spare Parts
6m x 10m 500 gsm PVC Marquee:
- Fire Retardant – We always use Belgian PVC marquee covers which are Flame Retardant to BS5438 & BS7837 in white 500gsm Rip Stop PVC on the roof and sides of our marquees, with welded (not sewn) seams because this provides total waterproofing along the joins.
- Georgian Windows – We have True Georgian rounded window side panels which are 2m x 2m and are individual panels (5 for each side) which attach to eaves leg and ground bar poles with bungee ties because this allows the panels freedom of movement in strong gusts of wind which intern prevents splitting and ripping of the panels but these are all attached together and waterproofed with the leg covers.
- Interchangeable Panels – We manufacture our marquees with fully interchangeable panels – All panels around the marquee are the same size and therefore compatible so you an move your doors, windows or plain panels where ever you need them.
- Completely Sealed – We make sure that our marquees are completely sealed to the wind and the rain with fixed leg covers which connect every side panel to the next, this means no flapping leg covers so gaping holes which can be exploited by the wind
- Rain Run Off Skirt – We ensure that these are on all panels and leg covers covering all sides and ends of the marquee as a result the water will run off away from the marquee ensuring that no water runs back under and inside the marquee.
- Roof Bracing – we provide both vertical and horizontal for extra strength, therefore the marquee can better cope with loading from Snow, Rain & Wind.
- Roof Purlin's – we provide these for extra support to ensure that there is no water pooling on the roof eaves during heavy down pours
- Ground bars – we provide these on all 4 sides of the marquee included in the price as we know that these are essential to the structure and stability of the marquee
- Bolted Joints – we ensure that we use fixed pole to joint connections for a firm fit and a ridged frame which does not sway and twist in the wind.
- Re-Enforced End Gables – Our end gables are made up of 3 individual 2m x 2m plain panels incorporating a non structural pole support between each panel for added strength in the wind, one of the plain panels at each end has zips incorporated so that the panel can be used as a door, all panels and support poles can be removed individually or completely.
- Vertical walls – we design and build our marquees with vertical walls as this is essential for weathering a marquee to the house or for attaching your marquee to other marquees or to walkways
- Zinc Galvanised Poles – the marquee poles are made from 38mm diameter strong galvanised steel with a 1.3mm wall thickness
- Zinc Galvanised Joints – the marquee joints are also made from strong galvanised steel which is 42mm diameter and has a 1.3mm wall thicknes
- Length: 10m – Need a Bigger Size – Joining Two Marquees With A Gutter
- Width: 6m – Need a Bigger Size – Joining Two Marquees With A Gutter
- Height: 3m
- Overall Floor Space: 60 sq m
- Capacity Seated: 66 seated
- Capacity Standing: 90 standing
- Height to Gutter: 2m
- Height to Apex: 3m
- Clearance from ground to horizontal wind brace: 2.6m
- Frame : 38mm / 42mm Galvanised strong steel tubing bolted secure, eaves braces vertical & horizontal, roof braces, end gable support bracing – with 3 separate 2m panel gables.
- Sidewalls: 500gsm, Fire retardant rip stop PVC, with the option to roll up or remove individual 2m panels. Fire Retardant to: BS 7837:1996 – BS5438:1989 Test method 2B with welded seams, 100% wind & waterproof.
- Interchangeable Side & End Walls : Yes
- Plain Sides Available: Yes – select in options
- Roof: 500gsm, marquee roof is in one complete section, similarly BS fire retardant rip stop PVC. Also with welded seams, 100% completely wind & waterproof.
- Branded: No
- Eyelets: Brass, Heavy duty.
- Clear span: 6m
- Weight: 270 Kg
- Warrantee: Yes
- Money Back Guarantee: Yes
- All Spare Parts Available: Yes
- Durability: Commercial 4 seasons
- People Needed to Erect: Min 2 – Ideal 3-4
- We provide you with a full 12 Month Warranty and full marquee spares back up with every marquee for sale.
- With 2 to 4 people this marquee proves very easy to erect and with the comprehensive easy to follow instructions we supply when the marquee is delivered together with the video we have in our Marquee Instructions section, it's almost too easy.
Points To Note:
- Ensure you purchase tie down kits with this marquee while ordering.
- Cleaning, Maintenance & Storage
- Need a Bigger Size – Joining Two Marquees With A Gutter
Why Buy This 6m x 10m Marquee 500gsm PVC Marquee:
- Very easy to erect.
- Very easy to transport and easy to store.
- Commercial hire quality
- All year round use.
- Welded seams which mean that no water will seep through.
- Completely sealed marquee sides and ends.
- Sealed to ensure that no wind or rain can force its way inside the marquee.
- Equipped with eaves braces, these support the PVC material span between bays on your roof cover.
- Eave supports stop water pooling during heavy downpours, preventing weight build up and ultimately the collapse of your structure.
Be an Event Master and not an Event Disaster!
Highest Quality 6m x 10m Marquee 500gsm PVC for Sale in the UK.
Additional information
Weight | 270 kg |
Dimensions | 2100 × 500 × 600 cm |
There are no reviews yet.


text:
Professional and smooth experience!
Everything went as promised. Smooth payment process and professional editing. They helped me a lot and I would highly recommend them.
August 2016
Our editing service is dedicated to turning your writing into fluent, native-level English.
Pass over the responsibility of perfecting your writing to our professional editors. Make sure your ideas are communicated clearly and fluently so they have the greatest impact.
Simply upload your document into the hands of our language experts!
Professional and smooth experience!
Everything went as promised. Smooth payment process and professional editing. They helped me a lot and I would highly recommend them.
August 2016
Feedback for English Trackers
This is a great service for non-native English speaking people. Their response is in a reasonable time and their advice is very useful. I strongly recommend them to anyone who needs such service.
June 2016
Great service!
I resorted to English Tracker for the proofreading of several academic articles. They were always very helpful and professional, I strongly recommend them!
April 2016
Great service that is timely and affordable!
They gave me a very personalised service that addressed all my needs for editing.
March 2016
Our online English editing and English proofreading services are offered with a simple pricing structure. We believe our clients appreciate knowing the price and turnaround time of our English correction service instantly, without having to wade through long upload forms or complex pricing tables.
Give me an instant price for your online English editing service.
English correction is not a skill that just any native speaker can carry out. Our English correction service is provided by professional, highly experienced editors. We recruit editors who have years of experience of English editing and English proofreading work. Once corrected by our teams, the English in your edited document will flow as if written by a native English speaker.
Introduce me to your professional editors.
The fact that our English editing services are provided online means that we can easily allocate a native English editor and a second proofreader to edit then check every document we handle. Quality is built into every phase of our English correction service and having a two-tier editing/proofreading service ensures you receive a faultless document.
Read why this double-checking was coded into our workflow.
We want you to be assured that our focus is on providing a quality English editing service. That's why we offer a 100% money back guarantee with our English editing and English proofreading services.
Give me more details about this no-questions-asked guarantee


text:
Journal of Anthropological Archaeology (Article in Press)
Mobility, contact, and exchange in the Baltic Sea basin 6000–2000 BC
Marek Zvelebil
My intention in this paper is to outline the main features and principal aspects of contact and exchange among the later prehistoric hunter–gatherers (late Mesolithic and post-Mesolithic) in the Baltic Sea basin, which covers the southern and eastern reaches of Northern Europe, and to summarise the main advances in current research. The area broadly covered includes the Baltic Sea basin that has provided effective routes for communication between the coastal regions surrounding the Baltic Sea, central Baltic islands, and regions further away in the north European Plain, inland regions of Fennoscandia and Russia that could be reached by an extensive network of major rivers and lakes. Effective transport for negotiating these routes both in the summer and winter existed already from the early Mesolithic. Goods moved along these routes included a wide range of artefacts discussed in the paper. Geographically, exchange was organised at three levels: regionally, inter-regionally, and over long distances. Each mode of exchange was probably organised along different lines socially, and each served to implement wide-ranging social strategies for the general purposes of social reproduction, mate exchange and biological reproduction, as well as the spread of innovations. In the concluding section, I discuss the nature of contacts and consequences of exchanges between the early farming communities and the hunter–gathering groups within the framework of the core-periphery relations.


text:
Dasani Water Gets a Sexy Makeover in New Ad Campaign
Today, Dasani launches a new $20 million campaign designed to set the bottled water maker apart from the crowd. The campaign is decidedly more adventurous than your usual water bottle marketing. As described in the New York Times today:
...in one Dasani commercial, a man and woman frolic in an elevator as a security camera captures the action, but they turn out to be husband and wife. In another spot, a woman spends a night out on the town with an extremely attractive man, then heads home where she gets undressed and jumps into bed � with her teddy bear.
Bummer, I was hoping for another round of bikini babes fighting in a pool of...oh...bottled water.


text:
View all text of Part 65 [§ 65.1 - § 65.17]
§ 65.10 - Mapping of areas protected by levee systems.
(a) General. For purposes of the NFIP, FEMA will only recognize in its flood hazard and risk mapping effort those levee systems that meet, and continue to meet, minimum design, operation, and maintenance standards that are consistent with the level of protection sought through the comprehensive flood plain management criteria established by § 60.3 of this subchapter. Accordingly, this section describes the types of information FEMA needs to recognize, on NFIP maps, that a levee system provides protection from the base flood. This information must be supplied to FEMA by the community or other party seeking recognition of such a levee system at the time a flood risk study or restudy is conducted, when a map revision under the provisions of part 65 of this subchapter is sought based on a levee system, and upon request by the Federal Insurance Administrator during the review of previously recognized structures. The FEMA review will be for the sole purpose of establishing appropriate risk zone determinations for NFIP maps and shall not constitute a determination by FEMA as to how a structure or system will perform in a flood event.
(b) Design criteria. For levees to be recognized by FEMA, evidence that adequate design and operation and maintenance systems are in place to provide reasonable assurance that protection from the base flood exists must be provided. The following requirements must be met:
(1) Freeboard. (i) Riverine levees must provide a minimum freeboard of three feet above the water-surface level of the base flood. An additional one foot above the minimum is required within 100 feet in either side of structures (such as bridges) riverward of the levee or wherever the flow is constricted. An additional one-half foot above the minimum at the upstream end of the levee, tapering to not less than the minimum at the downstream end of the levee, is also required.
(ii) Occasionally, exceptions to the minimum riverine freeboard requirement described in paragraph (b)(1)(i) of this section, may be approved. Appropriate engineering analyses demonstrating adequate protection with a lesser freeboard must be submitted to support a request for such an exception. The material presented must evaluate the uncertainty in the estimated base flood elevation profile and include, but not necessarily be limited to an assessment of statistical confidence limits of the 100-year discharge; changes in stage-discharge relationships; and the sources, potential, and magnitude of debris, sediment, and ice accumulation. It must be also shown that the levee will remain structurally stable during the base flood when such additional loading considerations are imposed. Under no circumstances will freeboard of less than two feet be accepted.
(iii) For coastal levees, the freeboard must be established at one foot above the height of the one percent wave or the maximum wave runup (whichever is greater) associated with the 100-year stillwater surge elevation at the site.
(iv) Occasionally, exceptions to the minimum coastal levee freeboard requirement described in paragraph (b)(1)(iii) of this section, may be approved. Appropriate engineering analyses demonstrating adequate protection with a lesser freeboard must be submitted to support a request for such an exception. The material presented must evaluate the uncertainty in the estimated base flood loading conditions. Particular emphasis must be placed on the effects of wave attack and overtopping on the stability of the levee. Under no circumstances, however, will a freeboard of less than two feet above the 100-year stillwater surge elevation be accepted.
(2) Closures. All openings must be provided with closure devices that are structural parts of the system during operation and design according to sound engineering practice.
(3) Embankment protection. Engineering analyses must be submitted that demonstrate that no appreciable erosion of the levee embankment can be expected during the base flood, as a result of either currents or waves, and that anticipated erosion will not result in failure of the levee embankment or foundation directly or indirectly through reduction of the seepage path and subsequent instability. The factors to be addressed in such analyses include, but are not limited to: Expected flow velocities (especially in constricted areas); expected wind and wave action; ice loading; impact of debris; slope protection techniques; duration of flooding at various stages and velocities; embankment and foundation materials; levee alignment, bends, and transitions; and levee side slopes.
(4) Embankment and foundation stability. Engineering analyses that evaluate levee embankment stability must be submitted. The analyses provided shall evaluate expected seepage during loading conditions associated with the base flood and shall demonstrate that seepage into or through the levee foundation and embankment will not jeopardize embankment or foundation stability. An alternative analysis demonstrating that the levee is designed and constructed for stability against loading conditions for Case IV as defined in the U.S. Army Corps of Engineers (COE) manual, "Design and Construction of Levees" (EM 1110–2–1913, Chapter 6, Section II), may be used. The factors that shall be addressed in the analyses include: Depth of flooding, duration of flooding, embankment geometry and length of seepage path at critical locations, embankment and foundation materials, embankment compaction, penetrations, other design factors affecting seepage (such as drainage layers), and other design factors affecting embankment and foundation stability (such as berms).
(5) Settlement. Engineering analyses must be submitted that assess the potential and magnitude of future losses of freeboard as a result of levee settlement and demonstrate that freeboard will be maintained within the minimum standards set forth in paragraph (b)(1) of this section. This analysis must address embankment loads, compressibility of embankment soils, compressibility of foundation soils, age of the levee system, and construction compaction methods. In addition, detailed settlement analysis using procedures such as those described in the COE manual, "Soil Mechanics Design—Settlement Analysis" (EM 1100–2–1904) must be submitted.
(6) Interior drainage. An analysis must be submitted that identifies the source(s) of such flooding, the extent of the flooded area, and, if the average depth is greater than one foot, the water-surface elevation(s) of the base flood. This analysis must be based on the joint probability of interior and exterior flooding and the capacity of facilities (such as drainage lines and pumps) for evacuating interior floodwaters.
(7) Other design criteria. In unique situations, such as those where the levee system has relatively high vulnerability, FEMA may require that other design criteria and analyses be submitted to show that the levees provide adequate protection. In such situations, sound engineering practice will be the standard on which FEMA will base its determinations. FEMA will also provide the rationale for requiring this additional information.
(c) Operation plans and criteria. For a levee system to be recognized, the operational criteria must be as described below. All closure devices or mechanical systems for internal drainage, whether manual or automatic, must be operated in accordance with an officially adopted operation manual, a copy of which must be provided to FEMA by the operator when levee or drainage system recognition is being sought or when the manual for a previously recognized system is revised in any manner. All operations must be under the jurisdiction of a Federal or State agency, an agency created by Federal or State law, or an agency of a community participating in the NFIP.
(1) Closures. Operation plans for closures must include the following:
(i) Documentation of the flood warning system, under the jurisdiction of Federal, State, or community officials, that will be used to trigger emergency operation activities and demonstration that sufficient flood warning time exists for the completed operation of all closure structures, including necessary sealing, before floodwaters reach the base of the closure.
(ii) A formal plan of operation including specific actions and assignments of responsibility by individual name or title.
(iii) Provisions for periodic operation, at not less than one-year intervals, of the closure structure for testing and training purposes.
(2) Interior drainage systems. Interior drainage systems associated with levee systems usually include storage areas, gravity outlets, pumping stations, or a combination thereof. These drainage systems will be recognized by FEMA on NFIP maps for flood protection purposes only if the following minimum criteria are included in the operation plan:
(i) Documentation of the flood warning system, under the jurisdiction of Federal, State, or community officials, that will be used to trigger emergency operation activities and demonstration that sufficient flood warning time exists to permit activation of mechanized portions of the drainage system.
(ii) A formal plan of operation including specific actions and assignments of responsibility by individual name or title.
(iii) Provision for manual backup for the activation of automatic systems.
(iv) Provisions for periodic inspection of interior drainage systems and periodic operation of any mechanized portions for testing and training purposes. No more than one year shall elapse between either the inspections or the operations.
(3) Other operation plans and criteria. Other operating plans and criteria may be required by FEMA to ensure that adequate protection is provided in specific situations. In such cases, sound emergency management practice will be the standard upon which FEMA determinations will be based.
(d) Maintenance plans and criteria. For levee systems to be recognized as providing protection from the base flood, the maintenance criteria must be as described herein. Levee systems must be maintained in accordance with an officially adopted maintenance plan, and a copy of this plan must be provided to FEMA by the owner of the levee system when recognition is being sought or when the plan for a previously recognized system is revised in any manner. All maintenance activities must be under the jurisdiction of a Federal or State agency, an agency created by Federal or State law, or an agency of a community participating in the NFIP that must assume ultimate responsibility for maintenance. This plan must document the formal procedure that ensures that the stability, height, and overall integrity of the levee and its associated structures and systems are maintained. At a minimum, maintenance plans shall specify the maintenance activities to be performed, the frequency of their performance, and the person by name or title responsible for their performance.
(e) Certification requirements. Data submitted to support that a given levee system complies with the structural requirements set forth in paragraphs (b)(1) through (7) of this section must be certified by a registered professional engineer. Also, certified as-built plans of the levee must be submitted. Certifications are subject to the definition given at § 65.2 of this subchapter. In lieu of these structural requirements, a Federal agency with responsibility for levee design may certify that the levee has been adequately designed and constructed to provide protection against the base flood.


text:
The Covington YMCA is preparing for the 13th Annual Covington Cheerios Challenge on Saturday, April 19, which will include a 10K/ 5K Road Race, 1-mile Fun Run/Walk and new this year, a Tot Trot for children 5 and under.
The event will be held at the YMCA on Newton Drive, with the 10K beginning at 7:30 a.m., the Trix Tot Trot at 8:45 a.m., the 1-mile fun run/walk at 9:00 a.m., and the 5K at 9:30 a.m.
This Covington Cheerios Challenge is a USATF Certified – AJC Peachtree Road Race Qualifier. This is the 13th year that the YMCA has worked in partnership with General Mills and other local businesses to create this community event.
"Participation in this event continues to grow tremendously each year and we have come a long way in these 13 years" Kacie Brown, YMCA Membership Director said. "It is an exciting day for the YMCA and for our community. In 2013 we had a record setting turn out of runners and walkers and are expecting even more participants in 2014! We appreciate the hard work of our 116 volunteers who come out to make this event possible. The excitement and support around the Covington Cheerios Challenge is contagious.
"We are thrilled to announce that the Cheerios No. 31 Race Car will be back at our event again this year and we will also be having a Silent Auction in conjunction with our event."
The Silent Auction will begin during packet pickup on April 18 at 10 a.m. and continue until the start of the 5K on Saturday, April 19.
The Cheerios Challenge is a part of the YMCA's annual Healthy Kid's Day Celebration. All proceeds from this event will go toward the YMCA's Annual Giving Campaign which offers financial assistance to families in our community who otherwise could not participate in Y programs.
For more information call the YMCA at 770-787-3908 or visit the Y's website at cvy.ymcaalanta.org. Registration forms for the races can be downloaded from this website. Online registration is available at active.com.
The YMCA wishes to thank Advantage Fire, BB&T, General Mills, Ginn Motor Company, Police Who Care/Covington Police Department and Sunbelt Builders for their sponsorship of this event.


text:
Im-mi-nent: (Adj, DOJ) 20 Months
Michael Isikoff has obtained and posted the white paper DOJ gave to the Senate Intelligence and Judiciary Committees to stave off giving them the OLC memos that actually authorized Anwar al-Awlaki's killing. I noted its mention in an SJC markup last year.
While the memos they are hiding are almost certainly far more damning (as I'll lay out tomorrow), this is utterly damning in itself.
It effectively defines imminence so as to have no meaning.
First, the condition that an operational leader present an "imminent" threat of violent attack against the United States does not require the United States to have clear evidence that a specific attack on U.S. persons and interests will take place in the immediate future. Given the nature of, for example, the terrorist attacks on September 11, in which civilian airliners were hijacked to strike the World Trade Center and the Pentagon, this definition of imminence, which would require the United States to refrain from action until preparations for an attack are concluded, would not allow the United States sufficient time to defend itself. The defensive options available to the United States may be reduced or eliminated if al-Qa'ida operatives disappear and cannot be found when the time of their attack approaches. Consequently, with respect to al-Qa'ida leaders who are continually planning attacks, the United States is likely to have only a limited window of opportunity within which to defend Americans in a manner that has both a high likelihood of success and sufficiencly reduces the probabilities of civilian casualties.
By its nature, therefore, the threat posed by al-Qa'ida and its associated forces demands a broader concept of imminence in judging when a person continually planning terror attacks presents an imminent threat, making the use of force appropriate. In this context, imminence must incorporate considerations of the relevant window of opportunity, the possibility of reducing collateral damage to civilians, and the likelihood of heading off future disastrous attacks on Americans.
With this understanding, a high-level official could conclude, for example, that an individual poses an "imminent threat" of violent attack against the United States where he is an operational leader of al-Qa'ida or an associated force and is personally and continually involved in planning terrorist attacks against the United States. Moreover, where the al-Qa'ida member in question has recently been involved in activities posing an imminent threat of violent attack against the United States, and there is no evidence suggesting that he has renounced or abandoned such activities, that member's involvement in al-Qa'ida's continuing terrorist campaign against the United States would support the conclusion that the members is an imminent threat.
Even assuming this is the justification they used to kill Anwar al-Awlaki, they killed him about 20 months after the alleged attacks (the UndieBomber and plotting against British Airways) in which they sort of have evidence against him (though DOJ has always managed to make sure that evidence was not challenged in an antagonistic setting).
If you measure from the toner cartridge plot — in which other AQAP members seem to have been the operational leaders — it was a year between the plot and the killing.
Anwar al-Awlaki may have been dangerous and surely was a hateful man. But it appears clear that DOJ had no evidence he was an imminent threat — at least as traditionally defined.
So they just redefined it.
Update: See Opino Juris for an assessment of this definition from an IHL and IHRL perspective.
Update: I've corrected my transcription of the imminent passage above (I had had "Second" instead of "Moreover").