OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-stc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: ACTION: REVIEW - ebxml Messaging Services spec v 0.2

Last week, the Transport, Routing, & Packaging team submitted "Messaging Service Spec v0-2" to the Quality Review team for review. Today (Monday, Sept. 18) is the end of the five business-day period for QR team review.

Attached below is a summary of all comments prepared by Joe Baran on behalf of the QR Team

It appears that the consensus of all who have commented is that the document should be forwarded to the Executive Committee with a recommendation that it be released for the first period of review by the full ebXML membership.
In the meantime, there has been continuing discussion and comment on the referenced document on the TR&P list, including the posting of a minor revision (v0-21). I have reviewed the "deltas" between v0-2 and v0-21 (by using a "Compare Document" on the Word versions), and they appear to be minor editorial corrections. I expect that the TR&P team would actually like to release v0-21. The QR Team has no objection, but the idea of setting a precedent of "submit one version for QR review and then promote the next version for public comment" needs to be monitored.
Rik Drummond wrote:
for QR's review.

Please Note: the spec is NOT in the new ebxml document format yet. the
editor doing it is on vacation. everything else is ready for your
thanks, Rik

tim mcgrath
TEDIS   fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142

Title: Messaging Service spec v0-2 QR summary
Item Reference
No. Submitter Line Email Comment
1 Tim McGrath 110-115 14/09/00 This section has some ambiguities.  What is the rationale behind putting the Message Service Specification as one document when it is clearly incomplete? This does not seem to be an umbrella specification with place holders for the missing sections.  Why not have the security, extensibility, service interface, reliability, and versioning  as separate documents (as I think they once were)?
2 Tim McGrath 114-115 14/09/00 lines 114-115 appear to contradict lines 130-133. It is not clearly stated that Message security, extensibility, service interface, reliability, and versioning are  not yet in this document but will be later.
3 Tim McGrath 130,137 14/09/00 more importantly, line 130 also appears to contradict line 137 - is "behavior of the messaging service software" the same as "Messaging Service Interface Specification "?
4 Tim McGrath (general) 14/09/00 There are some issues of  style for naming, the TA team have been discussing this (I.e., "upper-camel-case" vs. "lower-camel-case" etc.)  Duane has subsequently put this issue on the TA Team agenda.  I suggest we ask the TRP Team to adopt the TA Team recommended conventions.
5 Tim McGrath 211-215;261-268  14/09/00 Both claim to be "The charset attribute is used to identify the character set used to create the message" and yet propose different  values. I think it means the outer  and inner encoding methods but if so it should not use the same first sentence.
6 Tim McGrath 409-423 14/09/00 We should make note that these elements are a context of the Core Component known as 'Party'.  As such there may be alignment issues when the Core Components are defined.  TRP needs to confer with CC on an interim solution which allows future compatibility.
7 Tim McGrath 424-440 14/09/00 I am not familiar with the TPA team's strategy but the same argument as for 'Party' may apply here too.
8 Tim McGrath 455-456 14/09/00 I am not sure if this is too technical for our review but I don't see why we need to mandate that previous MessageIDs must be valid.  How would that work in practice? no-one is going to control this except the trading partners and then it forms part of their agreement.
9 Tim McGrath 463-475 14/09/00 If reliable messaging is still to be defined is it wise to put this element in now? This raises an important issue about proposed method for extensibility of the Header.
10 Tim McGrath (general) 14/09/00  "compliance statement' - should this document have one?
11 Nagwa Abdelghfour (general) 15/09/00 I think this spec is in a good shape to pass. I know that the spec does not yet include security and reliability as these are being worked separately, but I think we just need to note that in our report.
12 Bob Glushko (general) 17/09/00 I didn't see anything in the messaging spec that warrants us not letting it out for general review, except for the point already amply made that  the metainformation that security and reliability considerations were explicitly deferred should be prominent in any call for review. Otherwise these are too obvious omissions and will attract comments that aren't relevant to this round.
13 Joe Baran (general) 18/09/00 I agree that there are no issues serious enough to warrant delay of progress of this spec. I agree that the "to be determined" parts on Reliability, Security, etc. should be at least indicated with placeholders (if they are indeed to become part of this spec), or referenced in section 1.2 (if they are to be separate documents).
14 Joe Baran (general) 18/09/00 While it is true that the requirements have evolved since the publication of the TR&P Overview & Requirements (v 0-96, 26-May-2000), I think it is important that the requirements and the current document plan be aligned. Either that, or scrap the TR&P Overview & Requirements document (clearly, the former is a more desirable approach!)

Messaging Service spec v0-2 QR summary.xls

tel;cell:+61 (0)438352228
fn:tim mcgrath

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC