RE: Outstanding Issues - LONG please red to end

[Stefano POGLIANI <stefano.pogliani@sun.com>]

My 2 cents on #1.

As I already proposed in the relevant thread, I think that the "test indicator" (as it shapes from the original note and from David B.'s comments) looks more like a PING message.
The reason is that it the message will ONLY be processed by the MSH, why should a payload be necessary at all? And, if a payload is not necessary, shouldn't it be better to have a PING or, perhaps better, a "TEST" type-of-message instead than embedding a new attribute? 

/Stefano

> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Wednesday, November 22, 2000 7:09 PM
> To: 'ian.c.jones@bt.com'; ebxml-transport@lists.ebxml.org
> Subject: RE: Outstanding Issues - LONG please red to end
> 
> 
> 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  
>  
>