OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: ebXML Proof of Concept Proposal v0.5


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).
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC