now i am really worried. are you suggestion because legacy software was built with weak architectures, we have to continue to use it? clearly there is a need for some form of message service interface to deal with electronic document exchange, but we should not constrain the role of this module with how EDI gateways and translators work today. to use a real world analogy, the accounts payable clerk should not be expected to have access to the envelope the invoice came in before they can pay the bill. You will find that the invoice has all the details necessary. In my experience, some EDI applications have corrupted this modularity of function (by having business applications process enveloping details). This has always been a case where the implementors have confused business transactions with document exchange transactions. Despite the similarities of many elements within the envelope and those in the business document, these are not (and should not be) the same things. To use a trite example, the From (SMTP) is not the Sender (ebXML MSH, UNB.S002.004) of an Order document is not the Buyer (the business application). I think you will find this model holds true for all the elemnts you are considering for a 'generic header'. As another example, a messaging thread is not the business thread of document exchange. If we want to reference which order we are responding to, we use a business components such as 'ReferencedOrder', we don't try and kludge this using enveloping information. I note a thread along this vein is now running in ebxml-dev, so perhaps i am not alone is this concern. To use their example, the ebXML MSH ConverstionID should not be used to denote a business thread (e.g. this is my response to your order) it is to denote a document exchange (e.g. this is the second attempt to send this response). EDI implementations sometimes do this because it is a band-aid solution, simpler than trying to correct the message/document definition. If, as you say, this is not a business modeling problem, then I would encourage the ATG folks to participate in discussion with the ebXML MS team (and specifically the role of a Message Service Interface). I suspect this is where the mechanics will be resolved, not by peeling off EDI band-aids and sticking them on UBL. A Gregory wrote: Tim: I think there might be some confusion here. You are correct in pointing out that this is duplicative of messaging fields, and that point has not been lost on those doing the Generic Header project - alignment is key. The point is that long before the message envelope has been created, and after the envelope has been received and opened - some of the messaging information is still needed by applications that *cannot* access the envelope information. This is a very common problem, especially with tools such as EDI translators that are now being equipped to handle XML (they always relied on the control fields in the message). The idea is to have an optional, standard place to put this data *in the message* should that be needed. Melanie can probably better answer your questions, but I would point out that this is not a business modelling concern - it is strictly mechanistic, to accomodate the capabilities of tools and applications. Cheers, Arofan