RE: Conf. Call follow-up

[David Burdett <david.burdett@commerceone.com>]

Ian said ...

>>> 	I also support the idea that we define the header, routing, manifest
structure then define how we put this in MIME for both SMTP and HTTP (as
Dick pointed out there are 2 variants), AND a XML wrapped version.  This I
believe this is what David was proposing in the XML Messaging requirements
paper. i.e. We are transport protocol independent and provide "mappings" to
them if needed.<<<

This is, I think, not *quite* what I meant. What I envisaged was the
following type of structure:

Transport Wrapper (e.g. SMTP or HTTP)
|  MIME Envelope Start (or Outer XML Envelope)
|  MIME Envelope Parameters ...
|  MIME (or XML) separator ...
|  |  <MessageHeader>
|  |    ...
|  |  </MessageHeader>
|  MIME (or XML) separator ...
|  |  <MessageRoutingInfo>
|  |    ...
|  |  </MessageRoutingInfo>
|  MIME (or XML) separator ...
|  |  <FirstDoc>
|  |    ...
|  |  </FirstDoc>
|  MIME (or XML) separator ...
|  |  <SecondDoc>
|  |    ...
|  |  </SecondDoc>
|  MIME (or XML) separator ...
|  | etc ...
|  MIME Envelope (end)
Transport Wrapper End

The point I'm trying to make is that I have always thought of the Message
Header as being an XML document containing the types of information we have
been identifying. I did not anticipate the information being held as
name-value pairs in the MIME Envelope Parameters. The main reason for this
is if you want to sign the information it contains. You can only sign
information in the parameters (I think) if you sign the complete message. On
the other hand if you sign only the message parts, then you have a better
chance of being able to break up the MIME message, throw away the MIME bits
and keep the rest safely stored away on disk. I always tend to think of the
MIME enevelope as just that, an envelope, which can be thrown away once you
opened it.

Regards

David

-----Original Message-----
From: ian.c.jones@bt.com [mailto:ian.c.jones@bt.com]
Sent: Friday, March 03, 2000 5:21 AM
To: ebXML-Transport@lists.oasis-open.org
Subject: Conf. Call follow-up


Team,

	I fully support John I's view that e-mail will be around for a long
time, this is how B2B is working now!  Most EDI is just like e-mail but
using private service not the internet the big companies understand it and
will not stop using it overnight, we should be evolutionary not revolution
in the transport game.  Those of us present in San Jose saw the BASDA demo,
this was all e-mail based and worked, it was what the smaller software
companies and users were happy with, it is simple.

	I also support the idea that we define the header, routing, manifest
structure then define how we put this in MIME for both SMTP and HTTP (as
Dick pointed out there are 2 variants), AND a XML wrapped version.  This I
believe this is what David was proposing in the XML Messaging requirements
paper. i.e. We are transport protocol independent and provide "mappings" to
them if needed.

	I am also concerned about expanding message sizes and
processing/parsing the XML stream.  If we have an overall XML wrapper the
transport services will have to validate the entire structure, this is not
an issue for a lightweight text only order message.  But, if from the
examples we want to include the full design specification, colour pictures
of the prototype, etc with the order, even though we do not need to
understand the non text data we still have to read all the way to the end to
check that the wrapper is terminated correctly.

	The statement that "there is an ebXML requirement for all ebXML
specifications to be compliant with W3C technical specifications."  Concerns
and worry's me,  I can not remember anything this strong being stated in
previous meeting/discussion.  I appreciate the need to respect, not
contradict, reuse, build on or extend W3C specifications, but the W3C is
about the "web" we are dealing with e-business they are not the same!  A lot
of people assume they are especially in the consumer world, I do not want us
to fall in to that way of thinking.  I understand that XML is W3C
Recommendation but we are about conducting e-business using XML in a
standard manner.

	A comment on Rik's suggestion of WAP protocols, to currently make
this sort of service usable most of the data would have to be text based as
the current phone technologies have limited display capabilities, so a
simple XML wrapped ebXML message structure to WAP would probably be
lightweight.  The main application of WAP is currently seen as consumer such
as banking.  The limitation of WAP (bandwidth) may be short as the next
generation of carrier systems such as GPRS (General Packet Radio Service)
are in testing and should be on sale later this year, with bandwidth similar
to current fixed line modems or better.  The WAP protocol may still be used
over GPRS but both more bandwidth and more end user processing will be
available, if the market wants them.

Ian Jones