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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

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

Subject: Re: Latest ebXML Message Envelope Specification-version 0-5

Prasad, see comments inline bracketed by <DB></DB>.
----- Original Message -----
To: Ebxml
Sent: Monday, May 22, 2000 7:52 PM
Subject: Re: Latest ebXML Message Envelope Specification-version 0-5

Hi Dick,

I mostly have the same basic comments I had on the previous version (except the last one):

1. RFC conformant use of the "type" paramater with multipart/related type. That is specify the root document type in the "type" parameter, instead of the current value "ebxbl". This you also listed as open issue in this email.Could we flag this as an open issue in the specification.

<DB>Will include this in the next release, unless we resolve it beforehand.</DB>

2. How do we provide for consistent reference of what is sent and what is received between sending and receiving entities so that a verifiable non-repudiation of receipt can be generated. The issue I had was with the pushing the MIME headers from ebXML Message Envelope into the transport level MIME headers. The examples in sections 4.7 and 4.8 show the "Content-Type" and other headers from "ebXML Message Envelope" being used at the tranport level, effectively removing them from the transport level payload (a.k.a ebXML Message Envelope).  It was suggested one could simply add (prepend) these headers back on the receiving side, to recreate the original ebXML Message Envelope. The problem I see with that approach  is, SMTP and HTTP transports do not necessarily preserve the order, case, spacing and other attributes of the MIME headers.  For example how does the receiving side "ebxmlhandler" entity know in which order the original "ebXML Message Envelope" had the Content-Length, Content-Type, Content-Description and MIME-Version (etc.) headers? Also was the casing like Content-Type (vs) content-type? Was the "bondary" listed on the same line as the "Content-Type" or was it split on a separate line etc. All these factors are not significant w.r.t. HTTP or SMTP transport. However they are significant when one needs to generate a non-refutable receipt. The digest computed would be different (obviously) if the received message is not exactly identical to the sent one.

<DB>I don't believe the problem lies with HTTP or SMTP, all data sent via SMTP or HTTP is streamed over a socket in the order it was written by the sender (TCP/IP fragmentation and reassembly preserve the order). The issue you raise is germane to the mechanism used by the receiver to process the data stream (e.g. web server using CGI, servlets, ASP, Sendmail MTA, whatever). If the receiving process provides a RAW interface to the datastream then there is no problem accessing the original "bits" as they were presented by the sender. To prove this to myself I wrote a small program to send a HTTP POST containing only the ebXML message to "netcat" and sure enough - everything arrived in the order I sent it.

However, this does not address what I believe is the real "root" of the issue you raise, which is;

"What  data is considered within the signature block when creating an ebXML signed receipt? Is the message envelope part of the signature block?"

If the message envelope is OUTSIDE the signature block then there will be no problem producing signatures over any part of the ebXML header or payload containers and non-repudiation is preserved. If the message header is INSIDE the signature block then it is imperative that a receiving process be capable of accessing the senders complete data stream (via a RAW interface on a web or SMTP server) in order to create the signature. Personally, I see no reason to include the message envelope in the signature block because there is no "business data" contained there.


3. Wondering if using "application/vnd.ebxml" in place of application/xml is better. I mean ebXML is not a "vendor" and the subtype "xml"  is more likely to have a readily available support than "vnd.ebxml".

<DB>There are three registration trees listed on the IANA application for a MIME media type; Vendor, IETF and Personal. Only Vendor and IETF are viable for ebXML purposes. RFC 2048 states the following guildelines regarding IETF and Vendor trees:

   2.1.1.  IETF Tree

   The IETF tree is intended for types of general interest to the
   Internet Community. Registration in the IETF tree requires approval
   by the IESG and publication of the media type registration as some
   form of RFC.

   Media types in the IETF tree are normally denoted by names that are
   not explicitly faceted, i.e., do not contain period (".", full stop)

   The "owner" of a media type registration in the IETF tree is assumed
   to be the IETF itself.  Modification or alteration of the
   specification requires the same level of processing (e.g.  standards
   track) required for the initial registration.

2.1.2.  Vendor Tree

   The vendor tree is used for media types associated with commercially
   available products.  "Vendor" or "producer" are construed as
   equivalent and very broadly in this context. A registration may be placed in the vendor tree by anyone who has
   need to interchange files associated with the particular product.
   However, the registration formally belongs to the vendor or
   organization producing the software or file format.  Changes to the
   specification will be made at their request, as discussed in
   subsequent sections.

   Registrations in the vendor tree will be distinguished by the leading
   facet "vnd.".  That may be followed, at the discretion of the
   registration, by either a media type name from a well-known producer
   (e.g., "vnd.mudpie") or by an IANA-approved designation of the
   producer's name which is then followed by a media type or product
   designation (e.g., vnd.bigcompany.funnypictures).

   While public exposure and review of media types to be registered in
   the vendor tree is not required, using the ietf-types list for review
   is strongly encouraged to improve the quality of those
   specifications. Registrations in the vendor tree may be submitted
   directly to the IANA.

It appears registration in the IETF tree could be lengthy due to the RFC process and IESG approval requirements. I'm not opposed to going this route, I'm just pointing out that it could take some time. Do we have the time to pursue an IETF tree registration (application/ebxml)?

I suggested the vendor tree because the registration is owned by an organization, in this case ebXML, OASIS or the UN/CEFACT and it is a much simpler (quicker) process. Candidly, I would be satisfied with either approach. IMO it's really a question of whether or not people can live with the fact that the media type belongs to ebXML, as opposed to the IETF and the string contains the "vnd." in the media type. If people can't live with this then we'll have to pursue the IETF route and this could take a good bit of time.



My few cents however.

Best Regards,


[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