Re: Latest packaging spec...

[Henry Lowe <hlowe@omg.org>]

Prasad,

I agree with what you're saying about the clear separation 
on what's transport and what's application. 

However, I think part of the problem here is that, in the 
back of their minds, some people are thinking in terms of 
this "handler" which is going to look inside the header 
in the MIME message and use that information to possibly 
forward the envelope + payload to its final destination. 
However, in doing this, it has to possible change some of 
the information in the header, e.g., route traversed.

This brings up the question, is the handler transport or 
application?  Then, of course, there's the issue, which 
you raised re non-repudiation, of the handler changing 
some of the information in the MIME package.

Sorry, I'm not offering solutions -- just trying to point 
out what I think may be part of the problem here which 
hasn't seen the light of day yet.

Herny
-------------------------------------------
At 12:49 PM 04/26/2000 -0700, Prasad Yendluri wrote: 
>
> Hi Dick, 
>
> This is the basic premise of my argument or thinking: 
>
> The "ebXML-Headers part and the ebXML-Payload part(s) encased in the ebXML
> envelope" is the primary unit of exchange between two ebXML end-points,
> transported through any transfer mechanism. The message envelope is needed to
> keep the headers and payload together. We chose MIME based enveloping scheme
> (or the multipart/related message envelope) as it provided the ideal packing
> scheme at this point in time. With the potential for use of all XML packaging
> scheme in the future, the entire message envelope (and contents) should be
> viewed as an opaque-object that is simply transferred over a transport. Hence
> transport related headers (MIME or not) should be layered on top of this
> object based on the needs of the transport and they should not disturb the
> basic ebXML message structurally. 
>
> The ebXML Message Header Specification and the Requirements specifications
> refer to the "ebXML Message Envelope" as transport independent envelope, and
> calls for a separate transport envelop, which is also consistent with the
> above. 
>
> If my basic premise is incorrect then I have no case. However, if that is
> accurate then I would suggest we keep the transport headers layered on top of
> the whole envelope and not merge the envelope into transport headers. 
>
> Breaking up the message envelope at the transport level in a transport
> dependent way complicates things like saving the entire received message for
> non-repudiation etc. also. If we were to keep the transported object always
> consistent and independent of transport, this process would be much simpler. 
>
> Please see below some follow up in <PY> also. 
>
> "Dick Brooks (E)" wrote: 
>>
>> Hi Prasad,see inline comments marked with <db></db>
>>>
>>>    
>>> -----Original Message-----  
>>> From: Prasad Yendluri
>>> [<mailto:pyendluri@vitria.com>mailto:pyendluri@vitria.com]  
>>> Sent: Tuesday, April 25, 2000 5:07 PM
>>>
>>> Hi Dick, 
>>>
>>> I have couple of comments. Sorry I missed to recognize these last time
>>> around. 
>>>    * The Message Structure (sec 4.2) shows the "Transport Envelope"
encasing
>>>    the "ebXML Message Envelope", which is consistent with the (latest)
>>>    Message Header Specification also. However section 4.7 "complete example
>>>    of .. ebXML message .. sent via HTTP POST", brings in the complete ebXML
>>>    Message Envelope into the transport envelope. I mean the headers like,
>>>    "Content-Type: multipart/related; type=ebxml", "Content-Length" etc. are
>>>    made part of the MIME headers for the HTTP POST. This, I think is
>>>    undesirable for the following reasons: 
>>>    * This blurs the distinction between the two envelops. The transport
>>>    mechanism should simply "transport" and "deliver" the entire "ebXML
>>>    Message Envelope" with its constituent parts as is.  
>>>    * <db> Yes, I see your point. However the alternative to the current
>>>    approach would require us to create and register a new multipart
>>>    content-type (because we are defining a multipart object). If we were to
>>>    create a "multipart/ebxml" content type, as a replacement for
>>>    multipart/related, would this remove the "blur"?</db> 
>>
>> <PY>  My issue is with merging the ebXML message envelope into the HTTP
>> transport envelope. Multipart/related for ebXML message envelope is good.
>> However, the entire ebXML message envelope (and contents) should be
>> preserved as part of the transfer mechanism. If we don't do it, we have
>> already separated out the headers and payload at the transport level itself
>> and removed the message envelope prior to transfer.  
>> We are supposed to save the entire received message for non-repudiation. How
>> do you define what constitues a  received message unambiguously if what
>> exactly is received changes with the transport? 
>>
>> The new Message Header Specification puts the "Check Message Structure"
>> step, that checks for proper MIME formation of the message after the save
>> step for the same reason, in the "ebXML Aware Software Layer". This is
>> consistent with the transport layer simply transferring complete
>> ebXML-Message-Envelope as is.  
>> </PY>
>>>
>>> When other transports like FTP are used, we will deliver the entire
>>> mime/multipart message with the message envelope headers. That would make
>>> the delivered goods inconsistent between the two kinds of transports.  
>>> <db> I disagree, the FTP transport is simply different from other
>>> transports in that it is not "MIME aware" and does not attempt to define
>>> the type of data being sent (other than generically binary or ascii). ebXML
>>> implementers will have to "adjust" to the requirements of each transport
>>> they plan to support. In the case of FTP the "RAW" ebXML message is sent
>>> without prepending any transport specific MIME headers whereas SMTP and
>>> HTTP, being "MIME aware", makes it appear like the transport and message
>>> envelopes are one. This is simply a side effect of "MIME aware" transports.
>>> </db> 
>>
>> <PY>  
>> We should not make the delivered goods variable based on the transport used.
>> This would complicate and  make inconsistent the processing steps from both
>> specification and implementation perspectives. 
>>
>> As I stated above, the processing steps as specified in the "ebXML Aware
>> Software Layer" of the "Message Header Specification" become highly
>> transport dependent and confusing. We should avoid that by all means.  
>> </PY>
>>>
>>> An organization receiving ebXML messages from via different transports
>>> corresponding to say different partners, might want to deliver them all
>>> into an input queue processed by a common processing logic. The messages
>>> delivered from all transport mechanisms need to be in identical format for
>>> this to be possible.  
>>> <db>I believe this will be possible using the current packaging, however
>>> all ebXML implementers must be prepared to handle transformations to ebXML
>>> messages caused by specific transports. 
>>
>> <PY> This calls for regeneration of ebXML message envelop on the receiving
>> side.  If you regenerate the ebXML message envelope on the receiving side in
>> a transport dependent way, we would have potentially different  versions of
>> the same ebXML message (envelope) received by different partners through
>> different transports. How does a sending side really reconcile in case of a
>> dispute?
>>
>> By the current mechanism, adding the ebXML Message envelope is selectively
>> handled by the transport layer (either on the sending or receiving side),
>> which should not be case.  
>> </PY>
>>>
>>>  When SSL is used,  if I am correct the HTTP POST / GET related headers are
>>> not protected by SSL. Only the content is.  
>>> <db>Reference an earlier post to this issue - RFC 2246/page 31 appears to
>>> indicate that ALL data is encrypted.</db>  
>>
>> <PY> O.k. I was not sure also. Not an issue to worry about anymore. </PY>
>>>
>>> Last but probably not least.  With this mechanism, if the type of the ebXML
>>> message ever changes (e.g. from MIME to XML), we will need to rehash the
>>> transport envelop all over. It would be desirable to ship either XML or
>>> MIME formatted ebXML message using the same transport envelope type.  
>>> <db>It's difficult to say what changes would be needed with a "pure XML"
>>> enveloping scheme because one does not exist. However I do believe there
>>> could be lots of changes to the current MIME based ebXML specification.  I
>>> really don't believe we can avoid changing the current specification and
>>> code base when/if an XML packaging standard arrives and is adopted by
>>> ebXML.Even if we adopted a scheme like you describe below, it too would be
>>> vulnerable to change under a pure XML approach.</db> 
>>
>> <PY> If we keep the transport headers  really independent of the payload
>> type, and payload envelope independent of transport mechanism, I see no
>> reason to change the transport envelop later on.  
>> </PY>
>>
>>>
>>> <db> In summary, I understand your concern, but I'm having trouble seeing
>>> how an additional level of enveloping helps solve the issues you raise
>>> above.The added envelope appears redundant with respect to FTP, plus the
>>> ebXML group would have to register a new MIME type and define it's
>>> behavior/structure/semantics, and this could take a fair bit of time. I
>>> really believe the current packaging is capable of meeting the needs you
>>> identify.</db>
>>
>> <PY> I am beginning to think we have some disconnect here. I am not calling
>> for additional level of enveloping. I am suggesting we keep the transport
>> and message envelopes really separate and not merge one into the other. What
>> I am proposing does not require FTP to have additional redundant envelop
>> (MIME headers). 
>>
>> I am not sure if we really need a new MIME type? The ebXML-Message-Envelop
>> would still be of multipart/related. It is just the HTTP / SMTP transport
>> level would have an "application/x-ebxml" type. 
>>
>> The use of  "application" content-type is appropriate IMHO here since it is
>> really data for the ebXML application and with the use of "x-ebxml" subtype
>> we do not require to register a new MIME type. The use of the application
>> type is also consistent with the MIME specifications.  
>>  </PY>
>>
>> Thanks again. 
>>
>> Prasad 
>>>
>>>   
>>>
>>> Dick Brooks  
>>>
>>> <http://www.8760.com/>http://www.8760.com/ 
>>>
>>>
>>>
>>> Hence I would like to suggest that we use a different "fixed" content-type
>>> for the HTTP transport. For example "application/x-ebxml". Then the example
>>> would look like, 
>>> POST /ebxmlhandler HTTP/1.1 Content-Type: application/x-ebxml; <any
>>> params?> Content-Length: 9293 ...........etc.......... 
>>>
>>> { The entire MIME multipart/related message goes here}   
>>>    * The content-type of the ebXML header container also needs to be of a
>>>    flexible type like the payload and not fixed at application/xml since, 
>>>    * We expect more than one header part in the ebXML header. Per the
latest
>>>    Header specification sent out by David Burdett, the header can have
>>>    parts for "Message Routing Info", "Message Routing History",
>>>    "Signatures", "Errors?" etc. 
>>>    * Even if we think some of these headers can be sub-elements/sections of
>>>    the same XML document, it seems other parts (e.g. signatures) need to be
>>>    separate at least as of now (since xml-dsig specifications /
>>>    implementations are not mature yet). Also, it might be needed to put the
>>>    routing headers in a separate (XML) document so that it can be updated
>>>    (and signed) independent of the rest of the header sections. 
>>> Hence I would also like to recommend we make the header content-type also
>>> flexible with Content-Id value of "ebxmlheader" clearly identifying it as
>>> ebXML header.  <db> Actually I think this is already the case, reference
>>> section 4.5.1 at the bottom of page 11.</db> 
>>> Thanks, Prasad
>>
>
>