RE: Outstanding Issues - LONG please red to end

[Doug Bunting <Doug@ariba.com>]

Dick,

I've added more to issue 4 below.

thanx,
	doug

-----Original Message-----
From: Dick Brooks [mailto:dick@8760.com]
Sent: November 24, 2000 12:41
To: ian.c.jones@bt.com; ebxml-transport@lists.ebxml.org
Subject: RE: Outstanding Issues - LONG please red to end

<SNIP />

> ######
> Issue 4
> Title - Charset / encoding/ Mime-Type
>
> Detail - there are a lot related email/issues on this area
> 7.2.1 - Charset: former versions of documents had charset. Were we correct
> in removing charset as attribute of top level multipart Content-Type.
> Recommend adding an optional multipart/related 'start' attribute.
> 7.3.3.2 - "note this is not the default for MIME". This is not
> true. Suggest
> defaulting application/vnd.eb+XML to UTF-8
> 7.6 -	Encoding explicitly defined: Suggest "mandatory for the ebXML header
> and must have same value as charset/ MIME content-type.
> 7.6 -	"... although this is one of the default values...". This is not
> true.  The transport wins. For application XML, UTF-8. For text XML,
> US-ASCII.
> Example - ?xml element in header and payload header: change in text or in
> example to common attribute name for <<encoding>> (preferred) or charset.
> Reason: suspected error: inconsistency with spec text.
> 7.2.1.1 - Type attribute: conforms to XML media type. Recommendation:
> explicitly say that it conforms application XML or text XML otherwise we
> default encoding is ambiguous. Need to specify which it is being derived
> from. "It is derived from....."
>
> Proposed Solution ?? - over to you

IMO, the charset parameter is not needed in the ebXML Message MIME envelope
nor ebXML Header MIME envelope.
The ebXML MS spec should require the ebXML header document to include the
encoding attribute,
with a default value of UTF-8, within the ebXML header document prolog e.g.
<?xml version="1.0" encoding="UTF-8" ?>.
This will ensure that XML parsers will have access to the character set
encoding information
when processing the ebXML header document.

<Doug>
I proposed adding the charset parameter back to the Message MIME envelope to
allow for alternate character encodings of the MIME headers used for the
individual parts.  My memory of the various MIME RFC's must have been
failing (imagine that, they're so memorable).  MIME has not defined such a
parameter for the multipart types and we therefore don't need it.  I
withdraw my question about section 7.2.1.

My other comments about 7.2.1.1, 7.3.3.2 and 7.6 relate primarily to our
basing the new application/vnd.eb+XML type on an Internet Draft which isn't
going to be read by many people.  RFC 2376 defined the application/xml type
well enough that at least a few will understand its semantics.  My
suggestions are:
* 7.2.1.1: As I said, make it explicit application/vnd.eb+XML is derived
from application/xml and thus the MIME entity has no default character
encoding.  [Only an XML processor (not a MIME processor) will be able to
determine the character encoding.]

* 7.3.3.2: On second thought, just remove the comment about a "default for
MIME."  MIME doesn't define any default encodings for subtypes of
"application."  And, we're just making a recommendation about how the XML
header document should be encoded.

* 7.6: I'm going to contradict my previous comments and suggest we do not
make any additional requirements in this area.  The XML declaration adds
very little value to an XML document encoded in UTF-8.  The declaration is
certainly mandatory if an encoding other than UTF-8 is used for the Header
document or if the MIME envelope for this entity specifies a character
encoding.  Remove everything from "however" to the end of that sentence.  If
someone has good words about making sure an explicit charset encoding in the
MIME envelope for this part doesn't conflict with the XML declaration (if
necessary) or the real encoding of the document, feel free...
</Doug>

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