RE: Outstanding Issues - LONG please red to end

[Dick Brooks <dick@8760.com>]

Ian, see responses inline..

> ####
> Issue 1
> Title - Test indicator
>
> Detail -
> I would propose that we add a new element to be used to indicate
> whether the
> message is a test or live/production message. Both RosettaNet and OTA have
> something similar in purpose, although each calls it something
> different. I
> imagine that other vocabularies have something similar as well.
> The purpose
> of this element (or attribute as the case may be) is to enable parties to
> exchange messages prior to actually engaging in e-business, to ensure that
> their systems are prepared to correctly handle the messages
> they send each other.
>
> Proposed solution - Add test indicator

I'm not opposed to adding a test/production indicator to the ebXML header
document.
I do however question its practicality. There are others means to indicate a
"test"
versus "production" message exchange. For example:
- separate production and test ebxml handler URL's (mailboxes, FTP sites,
etc.)
- separate production and test Party ID's

>
> ###
> Issue 2
> Title - Content-Length
>
> Detail -
> 7.2.2 - Counting OCTECTS: is first correct or should it be last? Where
> should count actually start?
> Example - Proposal: Content-Length in payload envelop: should come after
> Content-ID. Reason: suspected error (vs. MIME spec).
> None - Remove requirement for mandatory Content-Length header
>
> Proposed solution - Remove Content-Length and only show in HTTP binding
>

If Content-Length is NOT part of the normative ebXML Message envelope then
it must
be addressed in the HTTP "transport bindings" section of the MS spec. We
also need to
decide if Content-Length should be included in SMTP and FTP bindings.

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

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