RE: Versioning, "version" and namespaces

[Dick Brooks <dick@8760.com>]

Rich,

> Therefore, it makes sense that this header have an identifying
> Content-Type and version. It also means that a particular carrier might
> convert the entire ebXML message to base64 and add a
> Content-Transfer-Encoding MIME header.  Or, the ebXML MSH might do that
> prior to invoking the transport. This means that the sentence giving
> implementations the right to ignore any other MIME header (line 297) is
> incorrect.

You are describing transport specific processing behavior, which should be
specified in a binding section of
the MSH spec. The reference at line 297 is misleading and, IMO, should be
changed to indicate that a MSH MUST
adhere to the processing rules, as specified in the XXXX transport binding
section.


> The ebXML Header Container (that is, the MIME headers for the ebXML
> bodypart) specifies the same MIME content-type as the envelope,
> application/vnd.eb+xml.  This is wrong: you can't have the same
> content-type mean both the container and the header. Perhaps

I'm not sure I'm understanding you correctly, but here is how I see it. The
ebXML message envelope (the outside wrapper) has a MIME content-type of
multipart/related and a type parameter=application/eb+xml. The ebxml header
body part has a MIME
content-type: application/eb+xml. This arrangement is proper according to
the multipart/related specification, RFC 2387.

> vnd.ebheader+xml?  I believe the version attribute (line 210ff) is a
> mistake, as is the charset attribute (line 218ff).  Both of these
> duplicate information that can be contained within the ebXML Header
> Document, in a completely self-contained XML-way.

This has been discussed before and I agree with this position.

> 	If the ebXML Header Document is not in UTF-8, then it MUST be
> 	transmitted using base64, and so indicate with a C-T-E header.
> This could replace section 7.3.2.2 (lines 218ff) and section 8.1.2
> (lines 330ff)

Base64 encoding is an artifact of older transports that couldn't handle
8-bit/binary representations. All transport related requirements
should be specified in a transport specific binding section and
not as part of the normative message specification.


Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions