RE: ebXML PoC -- feedback to working groups

["Moberg, Dale" <Dale_Moberg@stercomm.com>]

There are still problems when using HTTP, servlets,
and some available APIs. In order to interoperate
I had to add an additional header for the MIME-entity
in the HTTP PDU. Also, when processing, I had to ignore
the real MIME-entity header (which sometimes did not
even have a content-type of "multipart/related" !!)
in order to find the right MIME body parts. So the actual
bits on the wire, as seen by a sniffer for example,
would not match the ebXML packaging.  

I hope that we can get this issue 
thoroughly resolved by the
next POC. I do not think it is a problem with the
spec as long as we continue to follow the IETF
RFCs on the layout for HTTP.

But there definitely is a problem for implementations
that impact interoperability. It is not a new problem, 
however. Maybe the bindings section needs a stronger
warning on the problem if it is not there already.

One answer is to reexamine the servlet IO interface
and work out a way that the sharing of the IO between
web server and servlet is less subject to confusion.
What happens is that the web server needs to read the
MIME entity's headers and so advances the stream
past the headers. If the servlet then just uses the stream
reference, it will miss the real headers (which are stored
on request properties ). It would be nice to make a new
inputstream class that could take the stored header data
and prepend it to the other input stream, resulting in
an input stream suitable to feed directly to a MIME 
multipart parser.


> -----Original Message-----
> From: Dick Brooks [mailto:dick@8760.com]
> Sent: Tuesday, November 14, 2000 4:00 PM
> To: Philippe DeSmedt; Ebxml-Poc (E-mail)
> Subject: RE: ebXML PoC -- feedback to working groups
> 
> 
> Philippe,
> 
> During the last POC there were a couple of packaging related 
> issues. Have
> all the packaging related issues been resolved?
> 
> Kudos to everyone involved in the POC. Your demonstrations 
> neutralize the
> FUD and build public confidence in ebXML.  High-5 to all of you!
> 
> Thanks,
> 
> 
> 
> Dick Brooks
> Group 8760
> 110 12th Street North
> Birmingham, AL 35203
> dick@8760.com
> 205-250-8053
> Fax: 205-250-8057
> http://www.8760.com/
> 
> InsideAgent - Empowering e-commerce solutions
> 
> > -----Original Message-----
> > From: Philippe DeSmedt [mailto:PDeSmedt@viquity.com]
> > Sent: Tuesday, November 14, 2000 1:49 PM
> > To: Ebxml-Poc (E-mail)
> > Subject: ebXML PoC -- feedback to working groups
> >
> >
> > All,
> >
> > At our post-PoC planning meeting in Tokyo, I was asked to 
> coordinate the
> > feedback from the PoC team to the various working groups.
> >
> > Let me summarize what I have heard so far:
> > *	the lack of precise specifications for multi-hop 
> messaging caused
> > some confusion; in particular, acknowledgements cannot 
> currently be sent
> > back to the original sender using the path (through the 
> hub) that the
> > original message took, but rather, the acknowledgement is sent
> > back directly
> > to the sender: the reason is that there is no place in the 
> header to keep
> > that information; furthermore, there are various interpretations
> > as to what
> > the acknowledgement should convey, i.e., received at the 
> next hop, or
> > received at the final destination;
> > resolution: this has been brough to the attention of the TR&P
> > working group,
> > which is currently taking on the specifications for 
> multi-hop messaging;
> > *	optionality is a problem: some of the fields in the header are
> > specified as optional (e.g. RefToMsgId (sp?)); optionality
> > greatly decreases
> > the likelihood of out-of-the-box interoperability;
> > resolution: this has been brought to the attention of the TR&P
> > woking group;
> > they will look carefully at all of the fields (current and
> > future) that are
> > optional;
> > *	default values can be a problem:
> > resolution: the TR&P group suggested that we look at the latest
> > spec (0.8),
> > as the number of attributes with optional values has been reduced;
> > *	I know that Hatem and his team have a number of issues that they
> > want to bring up (Hatem: could you please make that list 
> available to the
> > mailing list? Thanks much!)
> >
> > Please let me know if there are any issues that I have 
> missed, or if there
> > are new ones that you have thought about. It is important that
> > our feedback
> > gets communicated to the various working groups. So far, 
> comments seem to
> > pertain to TR&P. Are there any other groups that we have 
> feedback for? TP?
> > Reg/Rep? ...
> >
> > Thanks.
> >
> > -Philippe
> > _______________________________
> > Philippe De Smedt
> > Architect
> > Viquity Corporation (www.viquity.com)
> > 1161 N. Fair Oaks Avenue
> > Sunnyvale, CA 94089-2102
> > (408) 548-9722
> > (408) 747-5586 (fax)
> > pdesmedt@viquity.com
>