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!)