Versioning, "version" and namespaces

[Rich Salz <rsalz@caveosystems.com>]

This is Technical discussion; I'm not sure if it's major or minor. :)

As I understand it, the MIME headers in the ebXML Message Envelope are
there so that the carrying protocol (HTTP, SMTP, etc), can detect that
the messages is an ebXML message and deliver it to the ebXML processor. 
That is, it's really nothing other than the same type of
plug-in/dispatch that causes my browser to startup Acrobat when I click
on a link to a PDF file.  Do they serve any other purpose?

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.

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
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.

It is already clear -- if only from internal editorial notes in the
specification -- that duplicating information (especially in two
different formats) will be problematic.

XML has a way to declare the character set of an XML document.  I
believe the specification is made simpler if it omits the charset
attribute and instead says
	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)

XML also has a way to do versioning -- the namespace.	Just as the DTD on
line 357 has a date encoded in it, the namespace at line 373 should
also:
	http://www.ebxml.org/namespaces/2001/messageheader
Later revisions of the specification will change the date, achieving
versioning.

I believe someone said that putting a "version" attribute in the ebXML
Header MIME
headers lets the ebXML application check if it can handle the message
without parsing the entire header document.  If that's the rationale, I
believe it's insufficient. The version attribute in the message header
should be sufficient to let the carrying protocol deliver the message to
the proper ebXML application. The ability to quickly check against local
software configuration errors does not justify the problems of trying to
keep the same information in sync in three places.

Section 8.2.1.1 (lines 372) require the default namespace for the
ebXMLHeader document to have a particular value.  I don't think you can
do that. :) And if you can, you shouldn't, as it needlessly prohibits a
document like this:
  <eb:ebXMLHeader
xmlns:eb="http://www.ebxml/namespaces/2001/messageheader">
    <eb:Manifest>
      ...
I believe most namespace-aware XML tools (except for XML
canonicalization) generally make it hard for you to even tell the
difference between an QNAME and a simple name in the current default
namespace.

Look forward to any comments.
	/r$