The Standard Business Document Header, SBDH, was developed by UN/CEFACT in 2004 to facilitate internal routing and management of EDI and other business document files, primarily in applications where documents are being exchanged directly between two systems.
The Business Document Envelope, BDE, was developed by OASIS in 2015 to facilitate routing of business document files across networks with multiple gateways (also known as 4-cornered architectures).
Business document headers and envelopes provide a standardized semantic layer enabling business applications and document exchange gateways to determine logical routing and addressing information for processing the exchange of business documents between multiple parties.
A document header works by adding additional standardized document headers to an existing document, whereas a document envelope separates the semantic information from the document and carries the document within it as a payload.
Some of the principal functional differences between an envelope and a header are that the envelope may carry in it more than one payload at a time, and it can maintain its content confidential while being transported over a network with multiple gateways.
The two specifications, although using different technical approaches, address to a large extent the same application area. This risks increasing the cost in global document exchange by forcing users to apply different software for different business partners.

The project will explore if a joint technical specification can be developed that will outline:
     •	a single Header/Envelope Technical Specification
     •	where a header technology and where envelope technology would be applied
     •	the relationship with CCL and CCTS [spell out]
     •	how it could be used with, and how it would be agnostic to transport protocols, including AS2, ebMS and web services (including AS4)
     •	how it would be agnostic to payload content
     •	the implications on the current user base including migration guidance, if applicable

A proof of concept based on a draft of the deliverables outlined in chapter 3 should be carried out by a minimum of three independent implementations, demonstrating interoperability.
Out of Scope: The project will not include the use of newer exchange technologies and environments, such as cloud computing, APIs and mobile devices, except to prove being agnostic to transport technologies in general. If required, this will be set up as a separate project.