RE: ebXML Proof of Concept Proposal v0.5

[Marc Breissinger <marcb@webmethods.com>]

It is not too late.  Part of the reason for building the proof of concept and the demo environment is to highlight any practical implementation issues with the specification.  I believe that this would certainly qualify.  Perhaps this topic should be added to the agenda the TR&P working group meeting in San Jose for discussion.  It really does not affect the ebXML specification at all -- only the mapping to particular transports.  Today, those mappings are represented in the packaging specification by two example messages.  At the very least, I would propose that at the meeting, we push for making official "sections" to the document that show specifically how the ebXML message is bundled inside the transport envelopes of the big three transports: HTTP, SMTP and FTP.  That would make the mappings unambiguous.

 

Marc

-----Original Message-----
From: Patil, Sanjay [mailto:Spatil@netfish.com]
Sent: Friday, July 28, 2000 12:45 PM
To: 'marcb@webmethods.com'; Prasad Yendluri
Cc: ebXML POC Mailing List; 'dick@8760.com'; Askary, Sid
Subject: RE: ebXML Proof of Concept Proposal v0.5

[Marc]   This does bring up a larger issue on maintaining the separation of the ebXML Message Envelope from the transport envelope.  For example, if we truly maintained the spearation of the ebXML MIME message envelope from the transport envelope, an HTTP transport ebXML message would look like the following:

 <snip>

 

[Patil, Sanjay]  This is an interesting point, Marc. I was myself thinking about this issue last

couple of days trying to find any convincing reasons for mixing the transport envelope and

the  ebXML message envelope. Does anyone on the mailing list know the rationale behind

this decision. If it's not too late, may be we should consider a change as the mix of the

headers from the two unrelated envelopes is going to cause issues ...

1>Difficulty in using MIME and HTTP APIs together. Service implementers will have tough

    time creating valid ebXML s=642132016-28072000>    time creating valid message. Typically

    APIs which make the HTTP request available to applications have separate set of APIs

    for accessing headers and the body. This will make it difficult to use MIME APIs which

    in their simplest form would like to suck in the whole MIME message including headers

    and body from a stream. Also, a valid MIME message needs to have the mandatory

    header "MIME-Version: 1.0". Service implementers will have to hand code insertion of this

    header while instantiating the MIME message.

2> Any future wrappers for ebXML message can not be accommodated. ex. Rosettanet has

     the concept of RosettaNet object in which the Rosettanet MIME message is nicely

    encased along with detached signature, etc. The RosettaNet object is then considered

    as the body of the HTTP message. With this next version of RosettaNet are free to modify

    the structure of the RN Object without breaking transport level processing in the services.

3> There might be cases of conflicting headers between transport and ebXML message

     headers. Or simply put, we are leaving ebXML message at the mercy of the HTTP engine

     which may modify or alter the sequence, etc of the ebXML message headers.

4> Transport independence, which will affect the processing flexibility at hubs.

 

 

May be it's still not too late.

 

thanks,

Sanjay Patil

Netfish Technologies. 

 

=================================================================================================================

5. If SMTP is part of the Hub model, I am not sure if we can guarantee "hub should not cause any alteration of the envelope, header or payload of the messages". I mean SMTP (mail) servers are likely to add additional headers to the (transport) envelope, which gets into the message envelope also (per ebXML scheme)!  

The point was that the hub should not alter the ebXML message envelope, header or payload.  The transport envelope can be modified at will.  In fact, part of the value add of the hub could be to connect partners that support different protocols that otherwise would not be able to talk to each other.  This does bring up a larger issue on maintaining the separation of the ebXML Message Envelope from the transport envelope.  For example, if we truly maintained the spearation of the ebXML MIME message envelope from the transport envelope, an HTTP transport ebXML message would look like the following:

 

POST destination-server- ebxmlhandlder-URI HTTP/1.1

Host: destination-server-domain:destination-server-port

Content-Type: multipart/related;

              charset="iso-8859-1";

              boundary= transport-envelope-boundary

Content-Length: int-length [units based on content-transfer-encoding]

 

-- transport-envelope-boundary

Content-Type: multipart/related;  

               type=”application/vnd.eb+xml”;

               charset="iso-8859-1";

               version=0.1 ;

                            MIME-Version=1.0 ;

               boundary=ebxml-envelope-boundary

Content-Length: int-length [units based on content-transfer-encoding]

 

-- ebxml-envelope-boundary

Content-ID: uid@originator-domain 

Content-Length: int-length [units based on content-transfer-encoding] 

Content-Type: application/vnd.eb+xml  

<?xml version="1.0" encoding="UTF-8"?>

<ebXMLHeader>

 ....

</ebXMLHeader>  

--ebxml-envelope-boundary

Content-ID: uid@originator-domain

Content-Length: int-length [units based on content-transfer-encoding]

Content-Type: ???/???

  

< Payload >

         --ebxml-envelope-boundary--

--transport-envelope-boundary--  

 

This scheme would allow for a hub to route a message without affecting the ebXML message envelope.  The hub could switch protocols from HTTP to SMTP to FTP to whatever without affecting the ebXML envelope.  However, the current packaging specification mixes the definitions of the ebXML message envelope with the transport envelope and we should follow the specification.  Thus, I suppose we have to allow the hub to alter the ebXML envelope (much to my dismay).