RE: Outstanding Issues - LONG please red to end

["Burdett, David" <david.burdett@commerceone.com>]

Ian

See some comments below on issues 1 and 2 marked with <Daveb></Daveb>. I
don't have strong views on four ... and will rely on experts in MIME.

David

-----Original Message-----
From: ian.c.jones@bt.com [mailto:ian.c.jones@bt.com]
Sent: Wednesday, November 22, 2000 8:45 AM
To: ebxml-transport@lists.ebxml.org
Subject: Outstanding Issues - LONG please red to end


All TR&P contributors,

###################################################
Part 1 - what and why

	in Tokyo I volunteered to try and organise the outstanding issues
form the version 0.21d spec.  It was decided that we would handle one
topic/section at a time and resolve them on the list or vote via the
conference calls.

	I propose to publish them in small groups or even one at a time if
the issue has many comments.  Where I have a proposal or one has been made I
will post that also.  It was also decided that I would post Major discussion
type issues and simple ones that we can just reject or vote on during a call
so that we can maximise the time we have.

	Each issue will have the following format - it is email friendly so
that you do not have to open other documents which can cause problems.  The
format does not lend itself to this put the word/excel formats I tried
really require landscape screens to make sense.  This is another reason for
doing them one at a time.

Title - description of issue
Detail - Section (of 0.21d) and original comment (this may be repeated)
Proposed solution - if suggested may have several alternatives
Resolution - when we have one

	I will also keep a complete list that I will post if requested - or
I will put it to the site.  I WILL not accept comments on anything other
than those issues out for comment this is how we got here and I WILL NOT go
back.

###############################################################
Part 2
	This first issues

We started these last week
####
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  
<Daveb>I agree we should add a test indicator although we need to be precise
on what is being tested. I propose that messages with the test indicator set
should be processed by a MSH and forwarded to another MSH but NOT passed to
the application. If you want to do application level testing then this
information needs to be included as an attribute/element in the payload.
</Daveb>
###
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

<Daveb>Agreed</Daveb>
##### NEW ONES

Issue 3
Title - Title of Definition and Scope

Detail -
7 - Section needs a new title. "Definition and Scope" is not an appropriate
title. Refer to Steve Holes comment for suggested titles.

Proposal - Reject this as an ebXML issue - if not satisfied raise with STC

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

#########################################################################
end of first ones

I'll post more as soon as we start agreeing the solutions as 4 should be
more than enough to think about at one time (yes 1 is simple and we have
discussed the first 2 - so post a proposed solution!).


Ian Jones
E-Commerce Engineer

Email: ian.c.jones@bt.com