ĐĎॹá > ţ˙ Ą Ł ţ˙˙˙ ˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ěĽÁ 7 řż
Í bjbjUU %r 7| 7| žÇ Á ˙˙ ˙˙ ˙˙ l ě ě ě ě Č Č Č Ü Ěh Ěh Ěh 8 i | i Ü O d j n p L Zp Zp Zp v ö z $ 4{ Î Đ Đ Đ Đ Đ Đ $ ł Ó x ô Č Č{ u v Č{ Č{ ô z ě ě Zp Zp Ş z z z Č{ ä ě V Zp Č Zp Î z Č{ Î z ° z *¤ j Ĺ G B Č Ź Zp j -}¸żÜ đO Ěh Ź Î ˛ ş 0 O ž î K z K Ź z Ü Ü ě ě ě ě Ů ebXML Transport, Routing & PackagingMessage Envelope STRAWMAN Specification
Working Draft DOCPROPERTY "ebXML WorkingDraft Date" \* MERGEFORMAT 07-May-2000
This version:
STRAWMAN 0.3
Latest version:
N/A
Previous version:
STRAWMAN 0.2
Editor:
Dick Brooks < HYPERLINK "mailto:david.burdett@commerceone.com" dick@8760.com>
Authors:
Dick Brooks < HYPERLINK "mailto:david.burdett@commerceone.com" dick@8760.com>
Nick Kassem < HYPERLINK mailto:john_ibbotson@uk.ibm.com nick.kassem@sun.com>
Contributors:
See Acknowledgements
Copyright statement
Whose do we put? IETF?? ebXML?? UN/CEFACT?? OASIS?? ...
Abstract
This document is a straw-man proposal whose purpose is to solicit additional input and convey the current state of the ebXML packaging recommendations.
This document defines the structure (a.k.a. envelope) used to encapsulate data for transport between parties, following the specifications defined by ebXML. Every attempt has been made to ensure that ebXML requirements, related to transport, routing and packaging are addressed within this specification. Adherence to industry standards, consideration of existing business-to-business practices and support for Small and Medium Enterprises were key factors influencing the direction of this specification.
Status of this Document
This document is a STRAWMAN proposal and is not to be referenced as a formal industry standard by any party.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Table of Contents
TOC \o "1-3" \h \z HYPERLINK \l "_Toc482358859" 1 Introduction PAGEREF _Toc482358859 \h 3
HYPERLINK \l "_Toc482358860" 1.1 Purpose and Scope PAGEREF _Toc482358860 \h 3
HYPERLINK \l "_Toc482358861" 1.1.1 Goals PAGEREF _Toc482358861 \h 3
HYPERLINK \l "_Toc482358862" 1.2 Relationship to other specifications PAGEREF _Toc482358862 \h 3
HYPERLINK \l "_Toc482358863" 1.3 Specification Structure PAGEREF _Toc482358863 \h 4
HYPERLINK \l "_Toc482358864" 2 Packaging and Other Requirements PAGEREF _Toc482358864 \h 4
HYPERLINK \l "_Toc482358865" 3 Candidate Packaging Technologies and Selection Process PAGEREF _Toc482358865 \h 6
HYPERLINK \l "_Toc482358866" 3.1 Selection Process PAGEREF _Toc482358866 \h 6
HYPERLINK \l "_Toc482358867" 3.2 MIME PAGEREF _Toc482358867 \h 6
HYPERLINK \l "_Toc482358868" 3.3 XML PAGEREF _Toc482358868 \h 7
HYPERLINK \l "_Toc482358869" 3.4 Conclusion PAGEREF _Toc482358869 \h 7
HYPERLINK \l "_Toc482358870" 4 Packaging Specification PAGEREF _Toc482358870 \h 9
HYPERLINK \l "_Toc482358871" 4.1 General Conventions PAGEREF _Toc482358871 \h 9
HYPERLINK \l "_Toc482358872" 4.2 Message Structure PAGEREF _Toc482358872 \h 9
HYPERLINK \l "_Toc482358873" 4.3 Transport Envelope PAGEREF _Toc482358873 \h 10
HYPERLINK \l "_Toc482358874" 4.4 Message Envelope Specifications PAGEREF _Toc482358874 \h 10
HYPERLINK \l "_Toc482358875" 4.4.1 Content-type PAGEREF _Toc482358875 \h 10
HYPERLINK \l "_Toc482358876" 4.4.2 Content-Length PAGEREF _Toc482358876 \h 11
HYPERLINK \l "_Toc482358877" 4.4.3 Complete ebXML Message Envelope Example PAGEREF _Toc482358877 \h 12
HYPERLINK \l "_Toc482358878" 4.5 ebXML Header Container Specifications PAGEREF _Toc482358878 \h 12
HYPERLINK \l "_Toc482358879" 4.5.1 Content-ID PAGEREF _Toc482358879 \h 12
HYPERLINK \l "_Toc482358880" 4.5.2 Content-Length PAGEREF _Toc482358880 \h 13
HYPERLINK \l "_Toc482358881" 4.5.3 Content-Type PAGEREF _Toc482358881 \h 13
HYPERLINK \l "_Toc482358882" 4.5.4 Complete Example of an ebXML Header container PAGEREF _Toc482358882 \h 13
HYPERLINK \l "_Toc482358883" 4.6 Payload Container Specifications PAGEREF _Toc482358883 \h 14
HYPERLINK \l "_Toc482358884" 4.6.1 Content-ID PAGEREF _Toc482358884 \h 14
HYPERLINK \l "_Toc482358885" 4.6.2 Content-Length PAGEREF _Toc482358885 \h 14
HYPERLINK \l "_Toc482358886" 4.6.3 Content-Type PAGEREF _Toc482358886 \h 14
HYPERLINK \l "_Toc482358887" 4.6.4 Complete Example of an ebXML Payload container PAGEREF _Toc482358887 \h 15
HYPERLINK \l "_Toc482358888" 4.7 Complete Example of an ebXML Message enveloped using multipart/related content-type sent via HTTP POST PAGEREF _Toc482358888 \h 16
HYPERLINK \l "_Toc482358889" 4.8 Complete Example of an ebXML Message enveloped using multipart/related content-type sent via SMTP PAGEREF _Toc482358889 \h 23
HYPERLINK \l "_Toc482358890" 5 Security Considerations PAGEREF _Toc482358890 \h 30
HYPERLINK \l "_Toc482358891" 6 References PAGEREF _Toc482358891 \h 30
HYPERLINK \l "_Toc482358892" 7 Acknowledgements PAGEREF _Toc482358892 \h 30
HYPERLINK \l "_Toc482358893" 8 Glossary PAGEREF _Toc482358893 \h 31
HYPERLINK \l "_Toc482358894" 9 Authors' Address PAGEREF _Toc482358894 \h 31
Introduction
This specification defines the message structure used to encapsulate ebXML message headers and payloads for transport between parties. No assumption or dependency is made relative to transport protocol or type of payload; the specifications contained here are both payload and transport agnostic. This main goal of this specification is to define an enveloping structure to encapsulate any digitally encoded payload for transport over any data communication mechanism. No limitation is implied relative to processing mode, the structures defined in this specification can be used in one-way, broadcast, request/response (a.k.a. RPC) or full messaging mode communications between parties.
Purpose and Scope
This document provides software practitioners with sufficient detail to develop software used in the packaging, exchange and processing of information following ebXML Transport, Routing and Packaging specifications. This document defines the enveloping specifications used to represent ebXML messages and encapsulate ebXML message headers and digital payloads for transport over a data communication mechanism. There are other aspects of ebXML messaging that are not addressed in this document, for example: Content and Semantics of Message Headers, payload structure, business processes, choreography of message exchanges and error handling. These are addressed in other ebXML specification documents.
Software practitioners are expected to use this document in combination with other ebXML specification documents when creating ebXML compliant software.
Goals
Meet the requirements specified by the ebXML Transport, Routing and Packaging Overview and Requirements Document -version 0.92 [1]
Meet the requirements identified by the packaging sub-group (the people responsible for creating this specification)
Compatible with other ebXML specifications
Leverage existing industry standards
Implementable in a prototype by the May meeting of ebXML group
Enable parties to "package" very simple to very complex combinations of headers and payloads
Payload Neutral
Transport Neutral
Support corporate security policies and business practices
Relationship to other specifications
This specification is one of a set of related specifications that cover:
ebXML Messaging Overview - describes the relationship between the various ebXML specifications described below and how they are used in a compliant way with each other
ebXML Message Header Specification - this specification, Also will defines how we handle requests, responses, message acks, cancel, error, etc and include state diagrams for each end.
ebXML Reliable Messaging Specification - how to achieve robust reliable once-only delivery of message in a vendor neutral, transport independent way Not sure if this should include being proactive in efforts to recover from failure
ebXML Messaging Security and Signature Specification - this will cover:
how to use S/MIME with ebXML Messages
how to use PGP with ebXML Messages
how to use IETF/W3C XML Digital Signatures with ebXML Messages
ebXML Common Transactions contains specifications of commonly used transactions that are applicable to many situations
ebXML Transaction Status Inquiry Specification - how to inquire on the current status of a transaction
ebXML Service Availability Specification - how to determine if a Service is up and running
ebXML Messaging Discovery Specification - how to determine the parameters associated with a Service from the ebXML Messaging perspective.
ebXML Publish & Subscribe Specification - how to do Publish and Subscribe securely using any of the aboveNot sure if this is in or out of scope for ebXML
ebXML Messaging Audit Trail Specification - how to use ebXML to create audit trails of the messages exchanged during a transaction.
Specification Structure
This specification is organized around four main topics:
Packaging and Other Requirements
Candidate Packaging Technologies and Selection Process
Packaging Specifications
Security Considerations
Packaging and Other Requirements
The packaging sub-group began development of the ebXML envelope specification (this document) by first identifying requirements from the Transport Routing and Packaging Overview and Requirements [1] that directly affect enveloping. Secondly, the group identified requirements, specific to enveloping that were not included in [1]. This combined list of requirements was used by the group to evaluate candidate packaging technologies and would ultimately serve as the "checklist" for choosing a solution. The combined list of requirements considered by the packaging sub-group includes:
Able to handle large documents
Able to envelope any document type
Minimize intrusion to payload (special encodings or alterations)
Minimize potential for abnormal termination caused by envelopes
Facilitate a migration path for existing installed base and technologies
Low processing overhead
Support for recursive documents
Able to preserve digital signatures
Able to unambiguously identify signed data
Documents, expressed either in XML or other electronic formats, must be able to be wrapped inside a message envelope for transporting between the parties involved in that want to execute an eCommerce - Service or Trasanaction [1]
Multiple documents, whether related or not, may be transportable within a single message envelope [1]
Messages can be transported over many network protocols (e.g. HTTP, SMTP, CORBA, JMQ, MQSeries, MSMQ, etc) [1]
Messages can be sent using a variety of methods: [1]
a) to a single party, e.g. by specifying a URL
b) to multiple parties, e.g. by specifying a list of URLs
c) to an agent or intermediary for forwarding to the next party
Individual messages must be capable of routing serially or in parallel with other related messages [1]
Publish and Subscribe[1]
a) Messages may be distributed to the members of a list of parties using a "Publish and Subscribe"
mechanism
b) the anonymity of the subscriber may optionally be maintained
Documents and/or message headers may be digitally signed [1]
The signature over the documents or message headers should be independent of the transport protocol used [1]
A single digital signature may be used to bind together documents either: [1]
i) within the same message
ii) in another message
iii) somewhere else (for example the content at a URL)
Signatures on digitally signed documents can be used to: [1]
i) verify the authenticity of the party that is the sender,
ii) provide non-repudiation of origin or receipt, and
iii) ensure that the content of the message has not changed
All or part of the documents in a message may be encrypted prior to sending [1]
messages may be encrypted during transportation using a transport protocol [1]
documents may be time stamped securely with a digital signature [1]
Platform Independent Interoperability [1]
1) Servers/systems that support the exchange of documents can be treated as "black boxes"
2) The method used to transport documents is completely independent of:
a) the hardware used by the server/services at each end
b) the software or systems architecture of the server/services at each
c) the language used for implementation of systems and applications.
3) Support for a service can be expressed solely in terms of the type and sequence in which documents (and their message envelopes) can be exchanged
4) The approach must be suitable for implementation on hardware that varies from a very simple device to a large multi-processor/system complex
The protocol must be extensible to support: [1]
a) additional types of data in message headers and message routing information
b) new values for codes
c) new ways and methods of exchanging data
enable any party to carry out integrated eCommerce transactions with any other party anywhere in the world using their hardware and software vendor of choice [1]
attract a wide variety of vendors to implement the approach [1]
to not reinvent the wheel - re-use where possible [1]
to enable existing "messaging" solutions to "bridge" to the ebXML solution [1]
to scale from SMEs to large companies [1]
to scale from low power to high end solutions [1]
Candidate Packaging Technologies and Selection Process
The packaging sub-group began its investigation of packaging technologies by identifying the technologies currently used for business-to-business message exchange or were being developed for this purpose. The following packaging technologies were identified:
MIME - currently in use by companies exchanging business transactions using E-mail and HTTP
XML - currently used by RosettaNet and Microsoft (BizTalk and SOAP) and others
Selection Process
Each candidate technology was evaluated based on its ability to meet the requirements listed in the section titled "Packaging and other Requirements" elsewhere in this document. When necessary, specific parties were contacted to provide details describing how a technology was being used to meet specific requirements. The following parties were contacted to provide expert insight:
Microsoft - David Turner, regarding use of XML packaging in BizTalk
Develop Mentor - Don Box, regarding use of XML packaging in SOAP
Vitria - Prasad Yendluri, regarding use of XML packaging in RosettaNet
Jonathan Borden - author of XMTP [3], an XML to MIME transformation tool
The packaging sub-group considered the inputs of people from the ebXML Transport mailing list as well as the parties listed above, before making a selection.
MIME
Multipurpose Internet Mail Extensions (MIME) is an international standard created by the Internet Engineering Task Force. It has been implemented by numerous software vendors across the globe and has been used to exchange mixed type payloads, including XML, for several years. MIME was designed purely as a packaging (enveloping) solution to allow the transport of mixed payloads using Internet E-mail (SMTP). MIME is also being used by other transport technologies as a packaging technology, most notably HTTP.
XML
eXtensible Markup Language (XML) is an international standard created by the World Wide Web Consortium. It has been implemented by numerous software vendors across the globe and has been used to describe a broad spectrum of document structures from very simple to very complex. XML is a very flexible description language that can be used to represent virtually any type of document. XML can be used solely for packaging (enveloping) documents of any type, providing the data can be "transformed" into "legal XML.
In some cases, XML documents must be placed into a transport specific "envelopes" before being transported. For example, XML data must be placed into a MIME envelope when being transported via SMTP or HTTP.
Conclusion
The packaging sub-group examined the capabilities of both XML and MIME relative to the list of packaging requirements above. It's important to note that neither technology met all of the ebXML requirements and in the end it was the packaging sub-groups assessment of which technology came closest to meeting ALL of the ebXML requirements that determined which technology should be used.
MIME was chosen to serve as the ebXML packaging technology, over XML, based on the following:
There is no formal packaging standard within IETF or W3C, based on XML. If ebXML were to choose XML as a packaging technology it would be required to define an XML packaging specification and submit this to IETF or W3C for adoption as a formal standard. The packaging group decided that MIME was a better choice, given the following requirement:
"to not reinvent the wheel - re-use where possible [1]
XML requires that binary and other types of payload data be base64 encoded in order to be encapsulated within a XML root document. Base64 encoding ensures that no illegal XML characters exist within a document and recursive XML documents are "hidden". Base64 encoding imposes a significant processing overhead and results in larger messages, which affect both transmission and processing times. Base64 encoding of binary data is required of MIME content when being transported by SMTP, but this is a transport level requirement, not a requirement imposed by MIME. Binary data can be packaged and transported without alteration when using MIME over HTTP. MIME was chosen over XML based on the following requirements:
- Minimize intrusion to payload (special encodings or alterations)
- Low processing overhead
There is no industry standard way to package an encrypted message, or portion of a message, using XML. MIME was chosen over XML based on the following requirement:
- All or part of the documents in a message may be encrypted prior to sending [1]
The packaging sub-group did find that the deficiencies listed above that caused XML to be excluded were directly related to XML's immaturity relative to MIME. It was the sub-groups opinion that XML is a powerful technology, with great potential and the ebXML group should continue to monitor XML's progress in these areas. It is expected that XML will overcome these issues and may one day provide a good packaging solution for ebXML.
The ebXML executive committee should consider sending this document to the W3C for consideration as a set of requirements to be used by a W3C workgroup in the creation of an XML based packaging solution.
Packaging Specification
General Conventions
All headers, attributes and values defined in this specification are to be handled in a case insensitive fashion, regardless of the way information is presented in this document
All messages following the ebXML standard must follow the specifications for packaging defined in this document, regardless of message type (request, response, error, et al).
Values associated with MIME header attributes are valid in both "quoted" and unquoted form, for example both of the following forms are valid: (type="ebxml" or type=ebxml)
Message Structure
A Message Consists of:
a conditional outer Transport Envelope, such as HTTP or SMTP, that wraps,
a transport independent Message Envelope, for example MIME multipart/related, that contains the two main parts of the Message:
a Header container that is used to envelope one ebXML header document, and
an optional Payload container that is used to envelope the real payload of the Message
ebXML
Header
Container
ebXML
Payload
Container
Transport Envelope
This document does NOT define any requirements affecting the structure of transport level envelopes. It is expected that existing transport systems, such as SMTP, HTTP, FTP and others can be used to send/receive ebXML compliant messages, without modification. The only requirement ebXML has on the transport envelope is the ability to identify a specific "handler" to receive incoming ebXML messages. All known transports support this requirement.
A transport envelope is only required in those cases requiring such structures. In the case of HTTP or SMTP transport envelopes are REQUIRED, however in the case of FTP no transport envelope is needed.
In summary, an implementer of software to process ebXML messages must be aware of transport specific requirements relative to transport envelopes.
Implementers are expected to provide an ebXML handler to process all incoming ebXML requests for service contained within an ebXML message. This handler may be a dispatch process or an actual application with the capability to process the message. There will be at least one ebXML handler for each supported transport protocol. In the SMTP case this ebXML handler could be associated with a particular mailbox (e.g. ebxmlhandler@mycompany.com). In the HTTP case the ebXML handler is contained in the Request-URI on a POST operation, for example:
request URI
POST /ebxmlhandler HTTP/1.1
Implementers must provide a means to communicate the name of an ebXML handler for all trading partners to use when sending ebXML messages. Implementers should consider using a common identifier, such as "ebxmlhandler", or, alternatively provide a "discovery mechanism" to be used by a sender to determine the ebXML handler to receive service request.
Message Envelope Specifications
The message envelope is used to identify the message as an ebXML compliant structure and encapsulates the header and payload body parts. A message envelope MUST HAVE two MIME headers:
Content-Length
Content-type
Content-type
Three MIME media types were considered to serve as content-type for the ebXML Message Envelope:
- Multipart/related
- Multipart/Mixed
- Multipart/form-data
The group selected the multipart/related media type to serve as the preferred message envelope content-type.
Note:
There was some discussion over the similarities of multipart/related and multipart/mixed, both of which appear to offer similar capabilities and both could meet stated requirements. However, the group converged on multipart/related, believing it to be more semantically appropriate for ebXML.
There was significant discussion over whether to support multipart/form-data as an alternate content-type for message-envelope, due to the large installed base of web browsers that support this content-type.
It was determined that multipart/related was a more generic content-type than multipart/form-data and the multipart/related content-type is the preferred content-type for ebXML message envelopes. Multipart/form-data content-type is typically associated with HTTP/HTML web forms, whereas multipart/related can be associated with any type of data.
Additionally, due to limitations in their handling of multipart ebXML payloads it was determined that existing web browsers are unable to support the full breadth of functions needed to package complex ebXML messages containing multipart payloads. Therefore browser vendors are encouraged to add support for the ebXML enveloping standard as specified in this document.
The Content-type header also contains three attributes:
type
version
boundary
The type attribute is used to identify the message envelope as an ebXML compliant structure. There is only one valid value for this attribute: "ebxml". The following is an example usage of the type attribute:
Content-type: multipart/related; type="ebxml"
The version attribute is used to identify the particular version of ebxml message envelope being used. There are currently two valid values for version:
"0" indicating a version-less message; ALL ebXML implementations must support version-less messages
"0.1" indicating the current version of ebXML.
Currently, there are no version-less message envelopes defined, therefore all message headers SHOULD USE "0.1". The following is an example usage of version:
Content-type: multipart/related; type="ebxml"; version="0.1"
The boundary attribute is used to identify the body part separator used to identify the start and end points of each body part contained in the message. The boundary should be chosen carefully to insure that it does not occur within the content area of a body part. Example usage of the boundary attribute:
Content-type: multipart/related; type="ebxml"; version="0.1"; boundary="-------8760"
Content-Length
The Content-Length header is a decimal value used to identify the total number of OCTETS contained in all message body parts, including body part boundaries. Example:
Content-Length: 9841
Complete ebXML Message Envelope Example
An example of a complete ebXML compliant Message Envelope appears as follows:
Content-type: multipart/related; type="ebxml"; version="0.1"; boundary="-------8760"
Content-Length: 9841
ebXML Header Container Specifications
The ebXML Header container is a MIME body part used to encapsulate an ebXML header document. The ebXML header document is described in ebXML Message Header Specification [2]. There MUST BE one ebXML header document associated with every ebXML Message. The ebXML Header container consists of a MIME Header portion, referred to as the ebXML Header envelope and a content portion.
The ebXML Header envelope, consists of three MIME headers:
Content-ID
Content-Length
Content-Type
The content portion contains a ebXML header document as defined by [2]. The ebXML header document within the content portion of the container MAY BE enhanced during transport, provided it has not been digitally signed. Any change in the size of the ebXML header document must be reflected in Content-Length header of the ebXML Message Envelope and ebXML Header envelope.
Content-ID
The Content-ID MIME header is used to uniquely identify this container as the ebXML header envelope. There is only one possible value to associate with this header "ebxmlheader". An example usage follows:
Content-ID: ebxmlheader
Content-Length
The Content-Length header contains a decimal value used to identify the total number of OCTETS contained in the ebXML header document residing in the content portion of the container. Example:
Content-Length: 4208
Content-Type
The Content-type for an ebXML header is identified with the value "application/xml", as defined in RFC2376. An example of this content-type is:
Content-type: application/xml
Optional Support for Signed Headers
Implementers are free to support digitally signed ebXML header documents. Digitally signed ebXML headers must be identified with the appropriate Content-Type and structure appropriate for the cryptographic tool used. In the case of S/MIME, the content-type must contain the correct value and attributes as specified in RFC 2633; in the case of OpenPGP, the content-type must contain the correct values and attributes specified in RFC 2015.
Implementers must follow the guidelines specified in RFC 2015 and RFC 2633 for creating and processing digitally signed objects.
If XML Dsig is used then implementers are expected to follow the specifications contained in the W3C Recommendation for XML Dsig.
Complete Example of an ebXML Header container
The following represents an example of an ebXML header envelope and ebXML header document:
-------------------------------------------------------------------------------------------------
Content-ID: ebxmlheader -------------| |
Content-Length: 2048 | ebXML Header Envelope |
Content-Type: application/xml -------------| | ebXML
| Header
-------------| | Container
........ | ebXML header Document |
| |
-------------| |
-------------------------------------------------------------------------------------------------
NOTE: Place REAL ebXML Header example here when available.
Payload Container Specifications
The payload container of Message is optional. The ebXML header document contains a Message Manifest that identifies whether a payload container is present or not. If the Message Manifest of the ebXML header contains no entries then the ebXML payload container will not be present in the ebXML Message.
However, if the Message Manifest of the ebXML header indicates that a payload is present it will consist of a MIME header portion, referred to as the ebXML payload envelope and a content portion.
The ebXML Payload envelope, consists of three MIME headers:
Content-ID
Content-Length
Content-Type
The content portion contains whatever structure and content two consenting parties agree to exchange. ebXML makes no provision nor limits in any way the structure or content of payloads. Payloads may contain simple plain text object or complex nested multipart objects. This is the implementers decision.
Content-ID
The Content-ID MIME header is used to uniquely identify this container as the ebXML payload envelope. There is only one possible value to associate with this header "ebxmlpayload". An example usage follows:
Content-ID: ebxmlpayload
Content-Length
The Content-Length header contains a decimal value used to identify the total number of OCTETS contained in the content portion of the payload container. Example:
Content-Length: 5012
Content-Type
The Content-type for an ebXML header is determined by the implementer and is used to identify with the type of data contained in the content portion of the payload container.
Optional Support for Signed and Encrypted Payloads
Implementers are free to support encrypted and digitally signed paylaods. Digitally signed and/or encrypted payloads must be identified with the appropriate Content-Type and structure appropriate for the cryptographic tool used. In the case of S/MIME, the content-type must contain the correct value and attributes as specified in RFC 2633; in the case of OpenPGP, the content-type must contain the correct values and attributes specified in RFC 2015.
Implementers must follow the guidelines specified in RFC 2015 and RFC 2633 for creating and processing encrypted and digitally signed objects.
If XML Dsig is used then implementers are expected to follow the specifications contained in the W3C Recommendation for XML Dsig.
Complete Example of an ebXML Payload container
The following represents an example of an ebXML payload envelope and ebXML payload document:
-------------------------------------------------------------------------------------------------
Content-ID: ebxmlpayload -------------| |
Content-Length: 4096 | ebXML Payload Envelope |
Content-Type: application/xml -------------| | ebXML
| Payload
-------------| | Container
........ | ebXML Payload |
| |
-------------| |
-------------------------------------------------------------------------------------------------
Complete Example of an ebXML Message enveloped using multipart/related content-type sent via HTTP POST
NOTE: The following example is representative of the ebXML packaging structure ONLY. ebXML headers used in this example are not to be construed as ACTUAL ebXML header structures. The "official" format and content of ebXML headers is defined in ebXML Transport, Routing and Packaging: Message Header Specification version x.x. Published dd mmmm 2000 [2].
Following is a complete example of an ebXML Message sent via HTTP POST method:
POST /ebxmlhandler HTTP/1.1
Accept: multipart/related
Accept-Language: en-us
Content-Type: multipart/related; type=ebxml; version=0.1; boundary=---------------------------7d02a82e5f8
Accept-Encoding: gzip, deflate
User-Agent: Group 8760 InsideAgent
Host: localhost:9090
Content-Length: 9293
Connection: Keep-Alive
-----------------------------7d02a82e5f8
Content-ID: ebxmlheader
Content-Length: 211
Content-Type: application/xml
1.0
Request
Payroll
RecordCommission
-----------------------------7d02a82e5f8
Content-ID: ebxmlpayload
Content-Length: 7517
Content-Type: text/xml
http://www.pms.com/HITISInterface
http://www.crs.com/HITISInterface
http://www.pms.com/HITISInterface
1234567890
1234567890
1999-11-10T10:23:44
1234-567-8901
18097YZ
DBZ223
3457YTXV
098787818097YZ
HI234
1234STL
19991223T17:53:22
20000122
00000003T000000
Mr.
John
Q.
jones
Jr.
Professor
JohnJones
Mrs.
Sally
T.
Jones
SallyJones
67TR901-AZ
USD
185.00
USD
12.00
0.0525
not applicable
USD
00.00
Default percentage commission agreement
7930
HOTEL7890
HI234
1234STL
USD
185.00
USD
00.00
This commission per agreement with Travel Agents, Inc.
00.00
USD
10.00
7930
HOTEL7890
HI234
1234STL
3457YTXV
09878783276XY
BASS123
1234STL
19991223T17:53:22
20000122
00000003T000000
Mr.
Kevin
R.
Smithson
Jr.
Professor
Kevin Smithson
Miss
Mary
T.
Smithson
esq.
Professor
MarySmithson
67TR901-AZ
USD
185.00
USD
12.00
0.0525
not applicable
USD
00.00
Default percentage commission agreement
7930
HOTEL7890
HI234
1234STL
USD
185.00
USD
00.00
Flat commission per agreement with TA
00.00
USD
10.00
7930
HOTEL7890
HI234
1234STL
-----------------------------7d02a82e5f8--
Complete Example of an ebXML Message enveloped using multipart/related content-type sent via SMTP
NOTE: The following example is representative of the ebXML packaging structure ONLY. ebXML headers used in this example are not to be construed as ACTUAL ebXML header structures. The "official" format and content of ebXML headers is defined in ebXML Transport, Routing and Packaging: Message Header Specification version x.x. Published dd mmmm 2000 [2].
Also, the default Content-transfer-encoding type of 7BIT is being used in this message.
Following is a complete example of an ebXML Message sent via SMTP:
From dick@8760.com Sun May 7 17:01:14 2000
Received: from granger.mail.mindspring.net by alpha2000.tech-comm.com; (8.8.5/1.1.8.2/05Jun95-1217PM)
id RAA32702; Sun, 7 May 2000 17:01:13 -0500 (CDT)
Received: from gamma (user-33qt10l.dialup.mindspring.com [199.174.132.21])
by granger.mail.mindspring.net (8.9.3/8.8.5) with SMTP id SAA11942
for ; Sun, 7 May 2000 18:11:14 -0400 (EDT)
From: "Dick Brooks (E)"
To:
Subject: OTA Commission Event
Date: Sun, 7 May 2000 17:07:38 -0500
Message-ID:
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Content-Length: 8081
Content-Type: multipart/related; type="ebxml"; version="0.1";
boundary="----=_NextPart_000_0005_01BFB846.BF7FABA0"
------=_NextPart_000_0005_01BFB846.BF7FABA0
Content-Type: application/xml
Content-ID: ebxmlheader
Content-Length: 272
1.0
Request
Payroll
RecordCommission
------=_NextPart_000_0005_01BFB846.BF7FABA0
Content-Type: text/xml
Content-ID: ebxmlpayload
Content-Length: 7515
http://www.pms.com/HITISInterface
http://www.crs.com/HITISInterface
http://www.pms.com/HITISInterface
1234567890
1234567890
1999-11-10T10:23:44
1234-567-8901
18097YZ
DBZ223
3457YTXV
098787818097YZ
HI234
1234STL
19991223T17:53:22
20000122
00000003T000000
Mr.
John
Q.
jones
Jr.
Professor
JohnJones
Mrs.
Sally
T.
Jones
SallyJones
67TR901-AZ
USD
185.00
USD
12.00
0.0525
not applicable
USD
00.00
Default percentage commission agreement
7930
HOTEL7890
HI234
1234STL
USD
185.00
USD
00.00
This commission per agreement with Travel Agents, Inc.
00.00
USD
10.00
7930
HOTEL7890
HI234
1234STL
3457YTXV
09878783276XY
BASS123
1234STL
19991223T17:53:22
20000122
00000003T000000
Mr.
Kevin
R.
Smithson
Jr.
Professor
Kevin Smithson
Miss
Mary
T.
Smithson
esq.
Professor
MarySmithson
67TR901-AZ
USD
185.00
USD
12.00
0.0525
not applicable
USD
00.00
Default percentage commission agreement
7930
HOTEL7890
HI234
1234STL
USD
185.00
USD
00.00
Flat commission per agreement with TA
00.00
USD
10.00
7930
HOTEL7890
HI234
1234STL
------=_NextPart_000_0005_01BFB846.BF7FABA0--
Security Considerations
Implementers should examine carefully the security features of each transport. In the case of HTTP, Implementers are encouraged to use Realm Security, using basic authentication for access controls and SSL to protect sensitive information.
Users of E-Mail based solution should ensure that anti-spamming services are in place and filtering is used to prevent unauthorized access to E-Commerce Servers.
References
[1] ebXML Transport, Routing and Packaging: Overview and Requirements document version x.x. Published xx April 2000
[2] ebXML Transport, Routing and Packaging: Message Header Specification version x.x. Published dd mmmm 2000
[3] XMTP - Extensible Mail Transport Protocol
http://www.openhealth.org/documents/xmtp.htm
Acknowledgements
Jonathan Borden - Author of XMTP
Jon Bosak - Sun
David Burdett - Commerce One
Rik Drummond - Drummond Group
Christopher Ferris - Sun
Jim McCarthy - webXI
Bob Miller - GEIS
Dale Moberg - Sterling Commerce
Prasad Yendluri - Vitria
Glossary
Authors' Address
Dick Brooks
Group 8760
110 12th Street North
Suite F103
Birmingham, Alabama 35203
Telephone: 205-250-8053
E-mail: dick@8760.com
Nick Kassem
Sun Microsystems
E-mail: Nick.Kassem@eng.sun.com
***Need the rest of Nicks info***
PAGE 37
FILENAME \* MERGEFORMAT ebXML Message Envelope Specification v0-2 ( DOCPROPERTY "ebXML WorkingDraft Date" \* MERGEFORMAT 1-April-2000 ) PAGE \* MERGEFORMAT 2
payload object
ebXML header document
ebxml payload envelope
ebXML header envelope
ebXML Message Envelope
Transport Envelope
[ \ â ď 7 8 9 F G ` a ˘ Ł ˛ ł Ţ ß ŕ ó ô . y , n
o
˘
Ł
¤
Ľ
Ś
§
ł
´
ľ
Ď
Đ
Ń
Ň
Ó
Ô
Ő
Ö
×
ó
ô
ú ú ú ř ú đúíú ú ĺúíú ú Ýúíú Ű Ű Ň ú úËí í˝Ë¸Ż¸ŚŚŚËŻËí í j¤ Uj U CJ OJ QJ aJ 0JO aJ j' >*B*Uph ˙
j 0JO U56>*CJ \ 6jv Ujť U0JO j U] j U = M Ą Ż ź Ě Đ â ď ÷ I R Ľ ö . y , \
n
Ő
ý ű ů ÷ ů ÷ ů ÷ ů ÷ ů ÷ ÷ ů ÷ ő ů ő ë ő ő é ő ő é ç G
G $d NĆ ˙ R Q P , žË Ě Í ţţţ ô
ő
ö
ů
ú
' ( ) * + , - . / K L M N S T Y Z [ u v w x y z { | } Ä Ĺ Ć ŕ á â ă ä ĺ ć ç č
ńęçŢçÜŐÜÍŐÜŐęŢęç çżęçŢçÜŐܡŐÜŐęŢęç çŠęçŢçÜŐÜĄŐÜŐęŢęç çęçŢj >*B*Uph ˙ j Uj >*B*Uph ˙ j Uj >*B*Uph ˙ j Uj U CJ OJ QJ aJ 0JO
j 0JO Uj! >*B*Uph ˙ :Ő
- { ć D Š $
|
Ç
b ž p Ę 1 ß P ˝ i ż 6 ň J Ć ý ű ý ý ů ů ý ý ý ý ů ý ý ý ý ű ű ű ý ű ű ű ű ý ű ű ű ű ý " # $ > ? @ A B C D E F b c d e f g Ł ¤ Ľ Ś § ¨ Š Ş Ť Ç Č É Ę Ë Ě
!
"
#
$
%
&
B
C
D
E
H
I
Z
[
\
v
ýűôűěôűôĺÜĺý ýÎĺÉÜÉűôűÁôűôĺÜĺý ýłĺÜűôűĽôűôĺÜĺý ýĺýÜýűôű jý >*B*Uph ˙ j U0JO ]aJ j >*B*Uph ˙ j U0JO aJ j >*B*Uph ˙ CJ OJ QJ aJ
j 0JO Uj Uj U 0JO :v
w
x
y
z
{
|
}
~
Ą
Ľ
Ś
§
Á
Â
Ă
Ä
Ĺ
Ć
Ç
Č
É
ĺ
ć
ç
č
ë
ě
ď
đ
ń
/ 0 1 2 5 6 @ A B \ ] ^ _ ` a b ÷đîđçŢçŰ ŰÍçŰŢŰîđîĹđîđçŢçŰ ŰˇçŰŢŰîđîŻđîđçŢçŰ ŰĄçŰŢŰîđîđîđçŢ jh Ujë >*B*Uph ˙ jn Ujń
>*B*Uph ˙ jt
Uj÷ >*B*Uph ˙ 0JO CJ OJ QJ aJ
j 0JO Uj U jz U