Summary of comments on Messaging Service Spec v0-2

[Joseph Baran <joebaran@extol.com>]

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 (in both excel and html versions) is a summary of all 
comments posted to date to the QR team list.

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.

Since this is the first time the QR team has been in this position, I think 
we have a "point of order" question:

Do we need a formal vote, or is silence = acquiescence?

In any case, we can take it up at the conference call tomorrow.


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. I have no objection, but it does perhaps require 
another "point of order". In this case, it is easy to verify that the 
changes would not affect the QR review, 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 discussed.

Joe Baran

Messaging Service spec v0-2 QR summary.xls

Title: Messaging Service spec v0-2 QR summary

Item		Reference
No.	Submitter	Line	Email	Comment
1	Tim McGrath	110-115	9/14/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	9/14/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	9/14/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)	9/14/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	9/14/00	Both claim to be "The charset attribute is used to identify the character set used to create ht" STYLE="vnd.ms-excel.numberformat:m/d/yy">9/14/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)	9/14/00	"compliance statement' - should this document have one?
11	Nagwa Abdelghfour	(general)	9/15/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)	9/17/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)	9/18/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)	9/18/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!)

Last Updated on 9/18/00
By Joseph Baran