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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml message

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


Subject: RE: ebXML standards issues - another good comment - last one


	               

	From: Internet-Drafts@ietf.org[SMTP:Internet-Drafts@ietf.org]
	                  Reply To: Internet-Drafts@ietf.org
	                  Sent: Tuesday, January 25, 2000 4:10 AM
	                  To: IETF-Announce
	                  Cc: ietf-trade@lists.eListX.com
	                  Subject: I-D ACTION:draft-ietf-trade-xmlmsg-requirements-00.txt

	                  A New Internet-Draft is available from the on-line Internet-Drafts directories.
	                  This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

	                  Title : Requirements for XML Messaging Version 1.0 Release 00
	                  Author(s) : D. Burdett
	                  Filename : draft-ietf-trade-xmlmsg-requirements-00.txt
	                  Pages : 60
	                  Date : 24-Jan-00

	                  http://www.ietf.org/internet-drafts/draft-ietf-trade-xmlmsg-requirements-00.txt
	                  This specification contains requirements for a generic approach to
	                  the reliable, resilient, secure, tamper resistant, authenticated
	                  exchange of XML or other electronic documents over insecure transport
	                  mechanisms.
	                  The specification provides the requirements and framework for a set
	                  of related specifications on XML Messaging covering:
	                  o Requirements for XML Messaging (this paper)
	                  o Common XML Message Elements
	                  o Document Exchange and Transactions
	                  o Reliable Messaging
	                  o Secure Messaging
	                  o Document Choreography Definitions
	                  o Common Document Exchanges
	                  o Transport Protocol Supplements
	                  Although much work has been carried out on the other parts of the XML
	                  Messaging specification described above, they are sill in development

	                  A URL for this Internet-Draft is:
	                  http://www.ietf.org/internet-drafts/draft-ietf-trade-xmlmsg-requirements-00.txt


	                  Internet-Drafts are also available by anonymous FTP. Login with the username
	                  "anonymous" and a password of your e-mail address. After logging in,
	                  type "cd internet-drafts" and then
	                  "get draft-ietf-trade-xmlmsg-requirements-00.txt".

	                  A list of Internet-Drafts directories can be found in
	                  http://www.ietf.org/shadow.html 
	                  or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


	                  Internet-Drafts can also be obtained by e-mail.

	                  Send a message to:
	                  mailserv@ietf.org.
	                  In the body type:
	                  "FILE /internet-drafts/draft-ietf-trade-xmlmsg-requirements-00.txt".

	                  NOTE: The mail server at ietf.org can return the document in
	                  MIME-encoded form by using the "mpack" utility. To use this
	                  feature, insert the command "ENCODING mime" before the "FILE"
	                  command. To decode the response(s), you will need "munpack" or
	                  a MIME-compliant mail reader. Different MIME-compliant mail readers
	                  exhibit different behavior, especially when dealing with
	                  "multipart" MIME messages (i.e. documents which have been split
	                  up into multiple messages), so check your local documentation on
	                  how to manipulate these messages.


	                  Below is the data which will enable a MIME compliant mail reader
	                  implementation to automatically retrieve the ASCII version of the
	                  Internet-Draft.
> ----------
> From: 	matt@xmlglobal.com[SMTP:matt@xmlglobal.com]
> Sent: 	Friday, April 14, 2000 1:25 PM
> To: 	David Burdett
> Cc: 	ebxml@lists.oasis-open.org; ebxml-requirements@lists.oasis-open.org; kit@mitre.org
> Subject: 	RE: Should ebXML standards be based on XML?
> 
> 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>
> 
> 
> 
> 


[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