----- Original Message -----
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.
</DB>
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)
characters.
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.
</DB>
My few cents however.
Best Regards,
Prasad