RE: Should ebXML standards be based on XML?

[matt@xmlglobal.com]

Why must issues such as encryption and transport even be contemplated now? 
 If we do well in designing the message format by using a combination of 
MIME and
XML, it will be trivial to add the transport and encryption mechanisms 
later.  It is only remotely beneficial to waste time on these components 
for the sake of things that
should be built in, like content and receipt verification, and process 
flow.

If  MIME+XML is specified as the lingua franca for messaging, we already 
have a transport mechanism that supports both (HTTP).  This transport 
mechanism also supports
certificate based encryption, (SSL,TLS, etc.).  Other transport mechanisms 
can also use SSL.  The SSL approach is nice because the decryption is 
handled pretty seamlessly, so 
applications would not be limited to a few headers of elements that were 
left unencrypted for the routing of processing decision stages.

I think the key is to establish a chain of preferred protocols, sort of 
like how web browsers will often try to negotiate a HTTP/1.1 connection, 
but can always fall back to HTTP/1.0.  ebXML should
define a sequence of accepted encryption+transport schemes, and have the 
sending software able to handle them all.  Then, the receiver can 
implement what he/she likes for accepting
transmissions - and the sender can simply reject to send to receivers who 
do not meet their security baseline.

my $0.02 (CAD) 
--
Matthew MacKenzie
VP R&D / CTO
XML Global Technologies, Inc.




David Burdett <david.burdett@commerceone.com>
Sent by: owner-ebxml@lists.oasis-open.org
14/04/2000 08:38 AM

 
        To:     "Kit (Christopher) Lueder" <kit@mitre.org>
        cc:     ebxml <ebxml@lists.oasis-open.org>, 
ebxml-requirements@lists.oasis-open.org
        Subject:        RE: Should ebXML standards be based on XML?

Kit

The bottom line on this is that **current** XML standards do not **yet**
meet **all** our requirements. Please note the emphasis. Specifically, it
does not support encryption, which is a real business requirement. Below I
present the choices we have and then an analysis of each one ... which 
leads
to a conclusion. 

If you disgree with any of this reasoning please state clearly the reasons
why.

I am also copying this to the Requirements group so that they can also
understand the choices we are *having* to make.

Regards

David

CHOICES
We have a few choices for going forward:
1. Wait until the W3C develops the standards that we need. On encryption
this could be 12? 18? months away.
2. Develop an ebXML but leave gaps where the w3C cannot (yet) provide
solutions.
3. Develop our own "XML" equivalent to cover the gaps, e.g. for 
encryption.
4. Adopt an existing accepted standard method of encryption as our one and
only ever solution. The only one I know of is S/MIME.
5. Adopt a hybrid approach. Specifically, we do an "XML only solution" 
when
encryption is not needed and some other (S/MIME?) when it is.
6. Adopt a non-XML solution in the short term, then when the W3C or other
standards groups have developed technology that meets our needs move 
towards
it.

KIT. Do you agree that this is a comprehensive list of alternatives - 
please
suggest others if you think not ?

ANALYSIS
Option 1 - Wait for the W3C
If we wait for the W3C to develop standards before we can completely 
specify
ebXML transport, then we should stop NOW, contribute to these other 
efforts
to speed them and then reform later when the missing standards are 
becoming
more stable. This means that no implementations of ebXML Transport could
start until say at least 12 months away. This is unacceptable in my view -
frankly if ebXML is not going to deliver anything useful for 18 months, 
then
my company has much better use to make of time.

Option 2 - Leave gaps until the W3C develops a solution
Some of the gaps (e.g. encyrption) are reall business requirements (e.g. 
for
C1). This means we would have to devise our own separate solution to meet
the need. However this would non-interoperable with other solutions and
would require implementers to devise two solutions.

Option 3 - Develop our own XML technology to cover the gaps
I would seriously question that the ebXML group has the appropriate skills
to develop, for example, an XML based encryption approach. If we did try, 
we
will probably get it wrong and anyway it would compete with the W3C
approach. This is also unacceptable as we should only do things we have 
the
skill to do and we shouldn't compete with the W3C.

Option 4 - Adopt an existing standard method as our one and only solution.
This will allow us to continue working now on ebXML and will have the
"benefit" that we will never change it ... except that existing standards
change anyway over time. So even if, for example we only ever wanted to 
use
MIME, we would have to change at some point in the future as MIME evolves. 
I
think we can't ever commit to a single "standard".

Option 5 - Adopt a hybrid aproach.
This is unacceptable, at least in the short term, since it means that
implementers would *have* to develop two alternative solutions at the same
time when there is no need. It would also overly complicate the solution 
and
delay its adoption.

Option 6 - Adopt a non-XML solution in the short term.
This is like Option 3 in that we can continue to move forward immediately.
However it recognizes that existing standards evolve and new standards are
developed. Therefore, when "good" new standards are developed that meet 
our
requirements, e.g. for encryption. Then they can be adopted.

CONCLUSION
It is my honest opinion that the W3C and the XML community in general 
will,
over the next 12-18 months, develop XML based solutions that will meet all
our requirements. I also anticipate that we will more than likely adopt 
them
in a new version of the ebXML transport. But until then, we MUST NOT make
the completion of our work dependent on the development of standards that
not only do not yet exist - no work has even started on them. I think
therefore that option 6 is the only viable approach we can take.

If you disagree with my analysis, please state clearly the reasons why and
what alternative "choice" you think meets our needs better.

Regards

David


-----Original Message-----
From: Kit (Christopher) Lueder [mailto:kit@mitre.org]
Sent: Friday, April 14, 2000 5:39 AM
To: ebxml
Cc: ebxml-requirements
Subject: Should ebXML standards be based on XML?


There is an active debate currently going on at the ebXML
Transport/Routing/Packaging list about whether the ebXML standards
should be based on XML. The current direction of that group is to use
MIME for the outer envelope, not XML. They are proceeding with a
specification that will be brought forward for vote, but that seems like
a pretty late time to ask for a change in direction, if you disagree
with their approach. If you have any concerns, this may be an opportune
time to express them.
Kit Lueder.
MITRE.

-- 
    _/    _/             Kit C. J. Lueder 
   _/   _/         _/   The MITRE Corp.         Tel:  703-883-5205
  _/_/_/    _/  _/_/_/ 1820 Dolley Madison Bl  Cell: 703-577-2463
 _/   _/   _/    _/   Mailstop W722           FAX:  703-883-7996
_/    _/  _/    _/   McLean, VA 22102        Mail: kit@mitre.org
Worse than an unanswered question is an unquestioned answer.

<snip>