ࡱ > h j e f g bjbj g j j l L L L L L L L ` N] N] N] 8 ] | ^ | ` f ` $d ^ d d d 3f J }h Ai d $ L i f " 3f i i wv L L d d wv wv wv i L d L d wv i wv wv _{
L L d ~` ` L N] n ɕ , < 6 0 f =p : wv ` ` L L L L
ebXML Deployment Guide Template
Committee Specification Version 1.0
for ebXML Message Service Specification 2.0
OASIS ebXML Implementation, Interoperability and Conformance Technical Committee
7 April, 2003
Document identifier:
ebxml-iic-deploy-temp-10
Location:
HYPERLINK "http://www.oasis-open.org/committees/ebxml-iic" \l "documents" http://www.oasis-open.org/committees/ebxml-iic#documents
Editor:
Pete Wenzel, SeeBeyond < HYPERLINK "mailto:pete@seebeyond.com" pete@seebeyond.com>
Abstract:
Status:
This document has been approved as a committee specification, and is updated periodically on no particular schedule.
Committee members should send comments on this specification to the HYPERLINK "mailto:ebxml-iic@lists.oasis-open.org"ebxml-iic@lists.oasis-open.org list. Others should subscribe to and send comments to the HYPERLINK "mailto:ebxml-iic-comment@lists.oasis-open.org"ebxml-iic-comment@lists.oasis-open.org list. To subscribe, send an email message to HYPERLINK "mailto:ebxml-iic-comment-request@lists.oasis-open.org?body=subscribe"ebxml-iic-comment-request@lists.oasis-open.org with the word "subscribe" as the body of the message.
For more information about this work, including any errata and related efforts by this committee, please refer to our home page at HYPERLINK "http://www.oasis-open.org/committees/ebxml-iic"http://www.oasis-open.org/committees/ebxml-iic.
Table of Contents
TOC \o "2-3" \h \z \t "Heading 1,1,AppendixHeading1,1,Heading Section,1" HYPERLINK \l "_Toc37147326" 1 Introduction PAGEREF _Toc37147326 \h 4
HYPERLINK \l "_Toc37147327" 1.1 Terminology PAGEREF _Toc37147327 \h 4
HYPERLINK \l "_Toc37147328" 2 How to Use the Template PAGEREF _Toc37147328 \h 5
HYPERLINK \l "_Toc37147329" 3 Business-Level Requirements PAGEREF _Toc37147329 \h 7
HYPERLINK \l "_Toc37147330" 4 Technical-Level Requirements PAGEREF _Toc37147330 \h 9
HYPERLINK \l "_Toc37147331" 5 References PAGEREF _Toc37147331 \h 23
HYPERLINK \l "_Toc37147332" 5.1 Normative PAGEREF _Toc37147332 \h 23
HYPERLINK \l "_Toc37147333" 5.2 Non-normative PAGEREF _Toc37147333 \h 23
HYPERLINK \l "_Toc37147334" Appendix A. Acknowledgments PAGEREF _Toc37147334 \h 24
HYPERLINK \l "_Toc37147335" Appendix B. Revision History PAGEREF _Toc37147335 \h 25
HYPERLINK \l "_Toc37147336" Appendix C. Notices PAGEREF _Toc37147336 \h 26
1 Introduction
The ebXML Message Service Specification 2.0 [ REF ebMS \h ebMS] contains a plethora of configurable features and options. Any use of ebMS requires a certain amount of standardization within a trading community, and due to the degree of optionality allowed by the specification, these communities must also document exactly which parts of it must be deployed and how, in order to foster interoperability on multiple levels between participants. Such information may be collected and published as a Deployment Guide for a community. It also represents an agreed-upon convention for the use of the ebXML message handler within the community, the capabilities that are expected from an implementation, and the deployment details. This is not to be confused with the notion of Collaboration Protocol Agreement [ REF ebCPPA \h ebCPPA] (CPA), which focuses on the runtime collaboration mode between partners, for a particular business process. Some elements of the Deployment Template will, however, map to a communitys specific requirements of applicable CPA elements.
This Template document, upon being fully populated with specific requirements, thus becomes a Deployment Guide Instance Document. It is the intention of the OASIS ebXML IIC Technical Committee to collect and archive examples of Deployment Guides created from this Template, as an aid to user communities whose standardization efforts involve the ebXML Message Service. By publishing Deployment Guides for different communities using the same Template format, it will be easier for a user community to consult the configuration setups, as well as conventions used by other user communities with which they may want to interoperate. This will help them to assess whether these two communities will be able to interoperate, or under what conditions.
Terminology
The keywords must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this document are to be interpreted as described in [ REF RFC2119 \h \* MERGEFORMAT RFC2119].
How to Use the Template
The Template is divided into two user-targeted sectionsBusiness-Level Requirements and Technical-Level Requirementswhich correspond roughly to the Business Operational View and Functional Service View, respectively, as described by the ebXML Technical Architecture Specification [ REF ebTA \h ebTA].
The numbering and titles of the items is intended to match the section numbering and titles of the corresponding requirements or options in the Messaging specification document. This makes it easier to cross-reference these requirements to the original specification, for further details on the use and implications of the choices that can be made.
In many cases, the Technical-Level Requirements are a direct consequence of choices made in the Business-Level Requirements section. Where items appear to be duplicated between the two sections, the Technical-Level items are meant to provide more explicit details necessary for implementation of the business requirements, such as precise data formatting specifications.
Two classes of users would be expected to collaborate in the completion of this Template to produce a Deployment Guide:
Business Process Designers would detail the business-process specific requirements of the Message Service.
Standards Community Technical Architects would make the technical decisions necessary to implement the business processes most effectively.
Consumers of a Deployment Guide include:
Business process implementers (IT departments), to deploy a Message Service solution according to the requirements of specific trading communities.
Software solution vendors, to identify all areas in which business process specification bodies require software flexibility, and what specific configurations are necessary to support such standards.
Examples shown in the Value column are non-normative, having been provided by EANUCC based upon that organizations experience using this template, and should be replaced with text appropriate to the Deployment Guide developers organization.
When populating the Template, it is possible that a deployment requirement can have more than one answer. For example, when a requirement maps to a CPA element, users may want to specify several authorized values, as this community may want to allow more than one choice, to be further described by specific CPAs. In that case, and if CPAs are already defined, it is recommended to annotate each value with the CPA identification it will relate to. By doing so, the resulting Deployment Guide will give an overview of all the possible uses for a particular MSH feature (e.g. Security). This will help to quickly assess the deployment requirements for this particular feature. An alternative would be to provide pointers to existing CPAs, which the Template also allows. However, these CPAs may change in time (updates, additions). It is the role of the Deployment Guide to precisely show what capabilities are expected from a deployed implementation within a community. CPA designers will use it as a reference, so that new CPAs remain within these capabilities.
When no recommendation is made for an item of the template, one of the following values MUST be used:
Not Applicable: for items that are not relevant to the community.
No Recommendation Made: will indicate that there is no modification or preference for an item notated as such.
Pending: for items that are still under study for a recommendation, and for which some recommendation is likely to be specified in future versions of the Guide (yet, the user community did not want to wait for these to be specified before publishing a current version of the Guide.)
For items that specify text values, it should also be noted whether or not the values are case-sensitive.
Business-Level Requirements
[The items in this section are intended to be answered by a business process designer, and are either specific to the use cases and Business Processes being deployed, or are a matter of general policy.]
3.1.1.1 PartyId Element
SpecificationValueIs a specific standard used for party identification? Provide details.Example - EANUCC Global Location Number. Ref.: ISO6523 - ICD0088.
3.1.2 CPA Access
SpecificationValueIs a specific registry for storing CPAs required? If so, provide details.Is there a set of predefined CPA templates that can be used to create given Parties CPAs?
3.1.4 Service Element
SpecificationValueAre Services (related groups of Actions) defined for each party of each business process? List them, or provide a reference to the source of these values. [Per-process; absent from BPSS definitions.]
3.1.5 Action Element
SpecificationValueAre Actions defined for each party to each business process? List them, or provide a reference to the source of these values. [Per-process; may reference BusinessAction values in BPSS definitions. Appears as ThisPartyActionBinding/@action in CPA.]Example within the EANUCC system, approved values are specified by the EANUCC Message Service Implementation Guide.
Confirmation
3.1.1.2 Role Element
SpecificationValueAre Roles defined for each party of each business process? List them, or provide a reference to the source of these values. [Per-process; may reference Role values in BPSS definitions. Appears as Role/@name in CPA.]Example within the EANUCC system, approved values are specified by the EANUCC Message Service Implementation Guide.
http:/www.ean-ucc.org/roles/seller
Appendix C: Supported Security Services
SpecificationValueWhich security profile(s) are used, and under what circumstances (for which Business Processes)? [Refer to Appendix C of Message Service Specification. May be partially captured by BPSS isConfidential, isTamperproof, isAuthenticated definitions.]Example - within EANUCC, it is recommended to adopt persistent security at the application level, including:
Persistent digital signature
Persistent signed receipt
Persistent confidentiality
Persistent authorization
[This corresponds to Security Profile 21.]Are any specific third-party security packages approved or required?
4.1.2 Security and Management
SpecificationValueWhat security and management policies and practices are recommended?
6.6 Reliable Messaging Combinations
SpecificationValueWhich Reliable Messaging feature combinations are required? [Refer to Section 6.6 of Message Service Specification.]Technical-Level Requirements
This section requires an in-depth knowledge of the ebXML Message Service and all its constituent standards and technologies, and their application to the specific use cases and Business Processes of the user community being addressed.
2 ebXML with SOAP
2.1 Packaging Specification
2.1.3 Header Container
2.1.3.2 charset attribute
SpecificationValueIs the "charset" parameter of Content-Type header necessary?
If so, what is the (sub)set of allowed values?
2.1.4 Payload Container
SpecificationValueHow many Payload Containers must be present?
What is the structure and content of each container? [List MIME Content-Types and other process-specific requirements.]
How is each container distinguished from the others? [By a fixed ordering of containers, a fixed Manifest ordering, or specific Content-ID values.]
2.3 ebXML SOAP Envelope extensions
2.3.6 #wildcard Element Content
SpecificationValueAre additional namespace-qualified extension elements required? If so, specify.
2.3.7 id attribute
SpecificationValueIs a unique id attribute required for each (or any) ebXML SOAP extension elements, for the purpose of referencing it alone in a digital signature?
2.3.8 version attribute
SpecificationValueIs a version other than "2.0" allowed or required for any extension elements?
3 Core Extension Elements
3.1 MessageHeader Element
3.1.1 From and To Elements
3.1.1.1 PartyId Element
SpecificationValueShould multiple PartyId elements be present in From and To elements? [See section 3.1.1.1 of Business-Level Requirements. Appears as PartyId element in CPA.]Is the type attribute needed for each PartyId, and if so, what must it contain? [Appears as PartyId/@type in CPA.]Example within the EANUCC system, the PartyId element and type are represented using Global Location Number.
1234567890128
3.1.2 CPAId Element
SpecificationValueWhat identification scheme is used for the CPAId, and what form should it take? [If a URI, how is it constructed? Does it reference a real CPA, or is it just a symbolic identifier? See section 3.1.2 of Business-Level Requirements for repository information. Appears as CollaborationProtocolAgreement/@cpaid in CPA.]Example within the EANUCC system, the value of the CPAId is the concatenation of the Sender and Receiver GLNs followed by a four digit serial number.
1234567890128 - GLN Party A
3456789012340 - GLN Party B
0001 - CPA Number between parties A and B
3.1.4 Service Element
SpecificationValueIs there a defined "type" for Service elements? If so, what value must the type attribute contain? [Appears as Service/@type in CPA.]If not provided in Business-Level Requirements above, what is the set of possible values for the Service element? Is there a URI format scheme for this element? [Appears as Service element in CPA.]
3.1.6 MessageData Element
3.1.6.2 Timestamp Element
SpecificationValueMust Timestamp include the 'Z' (UTC) identifier? [Also for Timestamp elements described in ebMS sections 6.3.2.2, 6.4.5, 7.3.2.]
3.1.8 Description Element
SpecificationValueAre one or more Message Header Description elements required? In what language(s)? Is there a convention for its contents?
3.2 Manifest Element
3.2.2 Manifest Validation
SpecificationValueHow many Manifest elements must be present, and what must they reference?Must a URI that cannot be resolved be reported as an error?
3.2.1 Reference Element
SpecificationValueIs the xlink:role attribute required? What is its value?Are any other namespace-qualified attributes required?
3.2.1.1 Schema Element
SpecificationValueAre any Schema elements required? If so, what are their location and version attributes?
3.2.1.2 Description Element
SpecificationValueAre any Description elements required? If so, what are their contents?
4.1 Security Module
4.1.5 Security Considerations
SpecificationValueAre any recommendations given, with respect to protection or proper handling of MIME headers within an ebXML Message?
4.1.4.1 Persistent Digital Signature
SpecificationValueMust messages be digitally signed? [Yes, for Security Services Profiles 1, 6-21. Appears as BusinessTransactionCharacteristics/@isAuthenticated=persistent and BusinessTransactionCharacteristics/@isTamperProof=persistent in CPA]
4.1.1 Signature Element
SpecificationValueAre additional Signature elements required, by whom, and what should they reference?
4.1.3 Signature Generation
SpecificationValueWhat canonicalization method(s) must be applied to the data to be signed? [Recommended method is "http://www.w3.org/TR/2001/REC-xml-c14n-20010315".]What canonicalization method(s) must be applied to each payload object, if different from above?What signature method(s) must be applied?What Certificate Authorities (issuers) are allowed or required for signing certificates?Are direct-trusted (or self-signed) signing certificates allowed?What certificate verification policies and procedures must be followed?
4.1.4.2 Persistent Signed Receipt
SpecificationValueIs a digitally signed Acknowledgment message required? [Yes, for Security Services Profiles 7, 8, 10, 12, 14, 15, 17, 19-21. See the items beginning with Section 4.1.4.1 for specific Signature requirements. Appears as BusinessTransactionCharacteristics/@isNonRepudiationReceiptRequired=persistent in CPA.]If so, what is the Acknowledgment or Receipt schema?
4.1.4.3 Non-persistent Authentication
SpecificationValueAre communication channel authentication methods required? [Yes, for Security Services Profiles 2-5.]
Which methods are allowed or required?
[Appears as BusinessTransactionCharacteristics/@isAuthenticated=transient in CPA.]
4.1.4.4 Non-persistent Integrity
SpecificationValueAre communication channel integrity methods required? [Yes, for Security Services Profile 4.]
Which methods are allowed or required?
[Appears as BusinessTransactionCharacteristics/@isTamperproof=transient in CPA.]
4.1.4.5 Persistent Confidentiality
SpecificationValueIs selective confidentiality of elements within an ebXML Message SOAP Header required? If so, how is this to be accomplished? [Not addressed by Messaging Specification 2.0.]Is payload confidentiality (encryption) required? [Yes, for Security Services Profiles 13, 14, 16, 17, 21, 22.]
Which methods are allowed or required?
[Appears as BusinessTransactionCharacteristics/@isConfidential=persistent in CPA.]
4.1.4.6 Non-persistent Confidentiality
SpecificationValueAre communication channel confidentiality methods required? [Yes, for Security Services Profiles 3, 6, 8, 11, 12.]
Which methods are allowed or required?
[Appears as BusinessTransactionCharacteristics/@isConfidential=transient in CPA.]
4.1.4.7 Persistent Authorization
SpecificationValueAre persistent authorization methods required? [Yes, for Security Services Profiles 18-21.]
Which methods are allowed or required?
[Appears as BusinessTransactionCharacteristics/@isAuthorizationRequired=persistent in CPA.]
4.1.4.8 Non-persistent Authorization
SpecificationValueAre communication channel authorization methods required? [Yes, for Security Services Profile 2.]
Which methods are allowed or required?
[Appears as BusinessTransactionCharacteristics/@isAuthorizationRequired=transient in CPA.]
4.1.4.9 Trusted Timestamp
SpecificationValueIs a trusted timestamp required? [Yes, for Security Services Profiles 9-12, 15-17, 20, 21.] If so, provide details regarding its usage.
4.2 Error Handling Module
4.2.3 ErrorList Element
4.2.3.2 Error Element
4.2.3.2.2 codeContext attribute
SpecificationValueIs an alternative codeContext used? If so, specify.
4.2.3.2.3 errorCode attribute
SpecificationValueIf an alternative codeContext is used, what is its errorCode list?When errors should be reported to the sending application, how should this notification be performed (e.g. using a logging mechanism or a proactive callback)?
4.2.4 Implementing Error Reporting and Handling
4.2.4.2 Identifying the Error Reporting Location
SpecificationValueShould errors be reported to a URI that is different from that identified within the From element? What are the requirements for the error reporting URI and the policy for defining it?What is the policy for error reporting?
4.3 SyncReply Module
SpecificationValueIs SyncReply mode allowed, disallowed, or required, and under what circumstances? [May be process-specific.]If SyncReply mode is used, are MSH signals, business messages or both expected synchronously? [Affects setting of 6.4.7 syncReplyMode element. Appears as MessagingCharacteristics/@syncReplyMode in CPA.]
6 Reliable Messaging Module
6.2 Methods of Implementing Reliable Messaging
SpecificationValueIf reliable messaging is required, by which method(s) may it be implemented? [The ebXML Reliable Messaging protocol, or an alternative reliable messaging or transfer protocol.]
6.3 Reliable Messaging SOAP Header Extensions
6.3.1 AckRequested Element
6.3.1.1 SOAP actor attribute
SpecificationValueAre point-to-point (nextMSH) MSH Acknowledgments to be requested? [Yes, for RM Combinations 1, 3, 5, 7; refer to ebMS section 6.6. Appears as MessagingCharacteristics/@ackRequested with @actor=nextMSH in CPA.]Are end-to-end (toParty) MSH Acknowledgments to be requested? [Yes, for RM Combinations 1, 2, 5, 6. Appears as MessagingCharacteristics/@ackRequested with @actor=toPartyMSH in CPA.]
6.3.1.2 signed attribute
SpecificationValueMust MSH Acknowledgments be (requested to be) signed? [Appears as MessagingCharacteristics/@ackSignatureRequested in CPA.]
6.4 Reliable Messaging Parameters
6.4.1 DuplicateElimination
SpecificationValueIs elimination of duplicate messages required? [Yes, for RM Combinations 1-4. Appears as MessagingCharacteristics/@duplicateElimination in CPA.]What is the expected scope in time of duplicate elimination? In other words, how long should messages or message Ids be kept in persistent storage for this purpose?
6.4.3 Retries
SpecificationValueIf reliable messaging is used, how many times must an MSH attempt to redeliver an unacknowledged message? [Appears as ReliableMessaging/Retries in CPA.]
6.4.4 RetryInterval
SpecificationValueWhat is the minimum time a Sending MSH should wait between retries of an unacknowledged message? [Appears as ReliableMessaging/RetryInterval in CPA.]
6.4.6 PersistDuration
SpecificationValueHow long must data from a reliably sent message be kept in persistent storage by a receiving MSH, for the purpose of retransmission? [Appears as ReliableMessaging/PersistDuration in CPA.]
6.5 ebXML Reliable Messaging Protocol
6.5.3 Generating an Acknowledgment Message
SpecificationValueMust a response to a received message be included with the acknowledgment of the received message, are they to be separate, or are both forms allowed?
6.5.7 Failed Message Delivery
SpecificationValueIf a DeliveryFailure error message cannot be delivered successfully, how must the error message's destination party be informed of the problem?
7 Message Status Service
SpecificationValueIs the Message Status Service required for reliable and/or best-effort messaging?
7.1 Message Status Messages
7.1.1 Message Status Request Message
SpecificationValueIf used, must Message Status Request Messages be digitally signed?
7.1.2 Message Status Response Message
SpecificationValueIf used, must Message Status Response Messages be digitally signed?
7.1.3 Security Considerations
SpecificationValueMust unauthorized Message Status Request messages be ignored, rather than responded to, due to security concerns?
8 Message Service Handler Ping Service
SpecificationValueIs the Ping Service required?
8.1 Message Service Handler Ping Message
SpecificationValueIf used, must Ping Messages be digitally signed?
8.2 Message Service Handler Pong Message
SpecificationValueIf used, must Pong Messages be digitally signed?Under what circumstances must a Pong Message not be sent?
8.3 Security Considerations
SpecificationValueIf not supported or unauthorized, must the MSH receiving a Ping respond with an error message, or ignore it due to security concerns?
9 MessageOrder Module
SpecificationValueIs message ordering (within a Conversation) required? [If so, a once-and-only-once Reliable Messaging scheme must also be selected.]
10 Multi-Hop Module
SpecificationValueAre any store-and-forward intermediary MSH nodes present in the message path?
10.1 Multi-hop Reliable Messaging
SpecificationValueWhat are the values of Retry and RetryInterval between intermediate MSH nodes?
10.1.1 AckRequested Sample
SpecificationValueMust each intermediary request acknowledgment from the next MSH?Must each intermediary return an Intermediate Acknowledgment Message synchronously?
10.1.3 Multi-Hop Acknowledgments
SpecificationValueIf both intermediary (multi-hop) and endpoint acknowledgments are requested of the To Party, must they both be sent in the same message?
Appendix B Communications Protocol Bindings
B.1 Introduction
SpecificationValueIs HTTP a required or allowed transfer protocol? (See section B.2 for specifics of this protocol.)Is HTTPS a required or allowed transfer protocol? (See section B.2 for specifics of this protocol.)Is (E)SMTP a required or allowed transfer protocol? (See section B.3 for specifics of this protocol.)Are any transfer protocols other than HTTP and SMTP allowed or required? If so, describe the protocol binding to be used.
B.2 HTTP
B.2.2 Sending ebXML Service messages over HTTP
SpecificationValueIs a (non-identity) content-transfer-encoding required for any of the MIME multipart entities?If other than "ebXML" what must the SOAPAction HTTP header field contain?What additional MIME-like headers must be included among the HTTP headers?
B.2.3 HTTP Response Codes
SpecificationValueWhat client behaviors should result when 3xx, 4xx or 5xx HTTP error codes are received?
B.2.6 Access Control
SpecificationValueWhich HTTP access control mechanism(s) are required or allowed? [Basic, Digest, or client certificate (the latter only if transport-layer security is used), for example. Refer to item 4.1.4.8 in Security section. Appears as AccessAuthentication elements in CPA.]
B.2.7 Confidentiality and Transport Protocol Level Security
SpecificationValueIs HTTP transport-layer encryption required?
What protocol version(s)? [SSLv3, TLSv1, for example. Refer to item 4.1.4.6 in Security section.]What encryption algorithm(s) and minimum key lengths are required?What Certificate Authorities are acceptable for server certificate authentication?Are direct-trust (self-signed) server certificates allowed?Is client-side certificate-based authentication allowed or required?What client Certificate Authorities are acceptable?What certificate verification policies and procedures must be followed?
B.3 SMTP
B.3.1 Minimum Level of Supported Protocols
SpecificationValueWhat is needed in addition to the ebMS minimum requirements for SMTP?
B.3.2 Sending ebXML Messages over SMTP
SpecificationValueIs any specific content-transfer-encoding required, for MIME body parts that must conform to a 7-bit data path? [Base64 or quoted-printable, for example.]If other than "ebXML" what must the SOAPAction SMTP header field contain?What additional MIME headers must be included among the SMTP headers?
B.3.4 Access Control
SpecificationValueWhat SMTP access control mechanisms are required? [Refer to item 4.1.4.8 in Security section.]
B.3.5 Confidentiality and Transport Protocol Level Security
SpecificationValueIs transport-layer security required for SMTP, and what are the specifics of its use? [Refer to item 4.1.4.6 in Security section.]
B.4 Communication Errors during Reliable Messaging
SpecificationValueWhat communication protocol-level error recovery is required, before deferring to Reliable Messaging recovery? [For example, how many retries should occur in the case of failures in DNS, TCP connection, server errors, timeouts; and at what interval?]
Other Infrastructure Guidelines
The following infrastructure requirements fall outside the scope of the Messaging Specification, but may be important to specify in a Deployment Guide.
SpecificationValueWhat are typical and maximum message payload sizes that must be handled?What are typical communication bandwidth and processing capabilities of an MSH for these Services?References
Normative
[ebCPPA] OASIS, Collaboration-Protocol Profile and Agreement Specification Version 2.0, HYPERLINK "http://www.oasis-open.org/committees/ebxml-cppa/documents/ebCPP-2_0.pdf" http://www.oasis-open.org/committees/ebxml-cppa/documents/ebCPP-2_0.pdf, September 23, 2002.
[ebMS] OASIS, Title, HYPERLINK "http://www.oasis-open.org/committees/ebxml-msg/documents/ebMS_v2_0rev_c.pdf" http://www.oasis-open.org/committees/ebxml-msg/documents/ebMS_v2_0rev_c.pdf, February 21, 2002.
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, HYPERLINK "http://www.ietf.org/rfc/rfc2119.txt" http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.
Non-normative
[ebTA] ebXML, ebXML Technical Architecture Specification v1.0.4, HYPERLINK "http://www.ebxml.org/specs/ebTA.pdf" http://www.ebxml.org/specs/ebTA.pdf, February 16, 2001.
Acknowledgments
The following individuals were members of the committee during the development of this specification:
Mike Dillon, Drummond Group Inc. < HYPERLINK "mailto:mike@drummondgroup.com" mike@drummondgroup.com>
Jacques Durand, Fujitsu <HYPERLINK "mailto:jdurand@fs.fujitsu.com"jdurand@fs.fujitsu.com>
Jeffery Eck, Global Exchange Services <HYPERLINK "mailto:Jeffery.Eck@gxs.ge.com"Jeffery.Eck@gxs.ge.com>
Aaron Gomez, Drummond Group Inc. < HYPERLINK "mailto:%20aaron@drummondgroup.com" aaron@drummondgroup.com>
Michael Kass, NIST < HYPERLINK "mailto:michael.kass@nist.gov" michael.kass@nist.gov>
Matthew MacKenzie, Individual <HYPERLINK "mailto:matt@mac-kenzie.net"matt@mac-kenzie.net>
Monica Martin, Sun Microsystems < HYPERLINK "mailto:monica.martin@sun.com" monica.martin@sun.com>
Tim Sakach, Drake Certivo < HYPERLINK "http://www.oasis-open.org/apps/org/workgroup/ebxml-iic/members/wg_person.php?workgroup_person_id=5041" HYPERLINK "mailto:%20tsakach@certivo.net" tsakach@certivo.net>
Jeff Turpin, Cyclone Commerce < HYPERLINK "mailto:jturpin@cyclonecommerce.com" jturpin@cyclonecommerce.com>
Eric van Lydegraf Kinzan < HYPERLINK "mailto:ericv@kinzan.com" ericv@kinzan.com>
Pete Wenzel, SeeBeyond < HYPERLINK "mailto:pete@seebeyond.com" pete@seebeyond.com>
Steven Yung, Sun Microsystems < HYPERLINK "mailto:steven.yung@sun.com" steven.yung@sun.com>
In addition, the following people made contributions to this specification:
Thomas Bikeev, EAN International < HYPERLINK "mailto:bikeev@ean-int.org" bikeev@ean-int.org>
Revision History
RevDateBy WhomWhat0.126 June, 2002P. WenzelInitial draft.0.216 September, 2002P. WenzelReformatted document, published with notes by J. Durand.0.33 October, 2002P. WenzelRearranged into user-targeted sections, incorporated comments by J. Durand, M. Martin, E. van LydeGraf.1.027 January, 2003P. WenzelAdditional text, cleanup and CPA references by P. Wenzel; non-normative EANUCC examples by T.Bikeev; comments by J. Durand.1.024 February, 2003P. WenzelIncorporated comments by J. Durand.1.026 February, 2003P. WenzelIncorporated comments by M. MacKenzie.1.028 March, 2003P. WenzelApplied OASIS document formatting guidelines.
Notices
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.
Copyright OASIS Open 2003. All Rights Reserved.
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 does 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.
PAGE 2
ebxml-iic-deploy-temp-10 28 March, 2003
Copyright OASIS Open 2003. All Rights Reserved. Page PAGE 6 of NUMPAGES 26
Copyright 2002 OASIS. All rights reserved. Page PAGE 1 of NUMPAGES 1
H s
Y Z [ { | N O 0 1 2 ` a V W X 0J mH nH uj 0J UmH nH u jp Ujp Uj7o B*Uph
j 0J Ujzn UPJ jm Uj 5B* Uph 0J jl UaJ$ j Uj UmH nH tHu6 # H u
| 7
? ;
!
!
P
1
2
3
4
5
6
7
8
9
T
U
V
W
f
g
h
|h &js >*B*UmH nH ph u j?s UmH nH u &jr >*B*UmH nH ph u jIr UmH nH u j UmH nH umH nH u CJ OJ PJ QJ mH nH tHuj 0J UmH nH u &jq >*B*UmH nH ph u 0J mH nH umH nH u (
9 : ; < = > ? @ A \ ] ^ _ ` a } ~ ȸȸ|n j!v UmH nH u &ju >*B*UmH nH ph u j+u UmH nH u &jt >*B*UmH nH ph u mH nH uCJ OJ PJ QJ mH nH tHuj 0J UmH nH u j5t UmH nH u j UmH nH umH nH u 0J mH nH u +
4 5 6 8 9 : ; < = X Y δάΊά| j
x UmH nH u &jw >*B*UmH nH ph u jw UmH nH u mH nH u &jv >*B*UmH nH ph u mH nH u0J mH nH uCJ OJ PJ QJ mH nH tHuj 0J UmH nH u j UmH nH u )Y Z [ l m n
'
(
)
B
ϵߥן}ߥןi &jtz >*B*UmH nH ph u jy UmH nH u &j~y >*B*UmH nH ph u mH nH uCJ OJ PJ QJ mH nH tHujy UmH nH u j UmH nH umH nH u 0J mH nH uj 0J UmH nH u &jx >*B*UmH nH ph u&; I
[ \ I @ i
&