FW: Comments for Messaging Service Specification

[Rik Drummond <drummond@onramp.net>]

 

-----Original Message-----
From: Ralph Berwanger [mailto:rberwanger@bTrade.com]
Sent: Wednesday, August 23, 2000 11:42 AM
To: Rik Drummond
Subject: FW: Comments for Messaging Service Specification

Rik, This was sent out late last night and bounced back.  Can you please post it to the listserv so that the members will have it

 

-----Original Message-----
From: Ralph Berwanger [mailto:rab7067@earthlink.net]
Sent: Wednesday, August 23, 2000 12:25 PM
To: Main Identity
Subject: Fw: Comments for Messaging Service Specification

 

 

----- Original Message -----

 

From: Ralph Berwanger

To: ebXML Transport Mailing List

Sent: Tuesday, August 22, 2000 10:13 PM

Subject: Comments for Messaging Service Specification

 

The attached HTML is a composite of all comments received as of 8/22/2000 (Yes, Marty your comments are in the list).  I had planned to arrange the list so that those typographical and grammer errors were up from.  The problem was that the review process then became very disjointed because you were forced to jump all ove the document.  I have instead arranged the comments in order of their line reference number.  Those comments that are not directed to  a single set of reference lines are at the end of the list. Notice that there are a total of 161 comments.  It is going to be a challenge to complete this task in the time allocated during the conferenc call. Look forward to the discussion on Thursday.  I have also attached the Excel spreadsheet for those who would rather have that format.

 

Ralph Berwanger

Item No.	Submitter	Reference	Comment	Status
1	David Burdett	Email dated 8/21  Line 14	Arrange authors in alphabetic order
2	David Burdett	Email dated 8/21  Line 12/16	Add angle brackets
3	David Burdett	Email dated 8/21          Line 29'	Add a footnote to the page after "addressed" that states "The current specification is a working draft. Some of the requirements are note yet supported". If we don't then some people might think that we are addressing everything in this version.
4	David Burdett	Email dated 8/21          Line 99'	change "encapsulate ebXML" to "encapsulate (package) ebXML" as otherwise need to define what is meant by package on lines 136/7
5	David Burdett	Email dated 8/21  Line 99-100	replace "ebXML message headers and payloads" by "ebXML payloads" as the message header is covered by this spec
6	Marty Sachs	email dated 8/20      Line 100-101	delete 'ebXML message headers' since the headers are part of the structure specified in this document
7	Ian Jones	email dated 8/17     Line 102	remove the sentence starting "The main goal…" it is repeated.
8	Marty Sachs	email dated 8/20     Line 103	Agnostic' means speptical about the existence of God.  The religious meaning is the onlyh definition in Webster's Third International Dictionary.  I know that 'agnostic' is starting to be used as 'neutral' or something similar.  Please see that the glossary contains a definition of 'agnostic' appropriate to its use here.
9	Gordon van Huizen	email dated 8/21     Line 105	Add something like the following, since the spec will be have scope beyond the original envelope and header specifications: "This specification also discusses messaging service behavior that the recommended message structure is intended to support.". We need to make it clear that there are normative semantics behind the message structure, and that this document discussed them.
10	Ian Jones	email dated 8/17     Line 106	reverse the order of the first 2 sentences
11	Ian Jones	email dated 8/17     Line 109	This may be incorrect when document is reformatted
12	David Burdett	Email dated 8/21          Line 111'	Remove Service Interface or at least make it optional as Service Interface may be in a separate spec
13	Ian Jones	email dated 8/17     Line 122	Entire section will need revision if document is reformatted
14	Gordon van Huizen	email dated 8/21     Line 124-127	The list here needs to be expanded to include the itemsin the note on lines 111-112.
15	David Burdett	Email dated 8/21  Line 132-133	Fix indentation
16	David Burdett	Email dated 8/21  Line 139	text missing. Replace by copying text from lines 360-370
17	Ian Jones	email dated 8/17     Line 140	remove lines 140 and 141
18	David Burdett	Email dated 8/21          Line 143-144, 147-148	suggests that XML can be case-insensitive which it can't. Also L147, suggests that this applies to the whole spec when it only applies to packaging. Suggest moving these two comments to the start of section 2 after l 149
19	David Burdett	Email dated 8/21  Line 148	Add another bullet point to explain use of italics, e.g. Message Manifest is in italics on Line 284
20	Henry Lowe	Email dated 8/21 Line 153	as there is no other ebXML enveloping than MIME, change the "for example MIME ..." to "i.e., MIME ...".
21	David Burdett	Email dated 8/21          Line 153'	Change "for example" to "specifically" as we only allow MIME
22	David Burdett	Email dated 8/21  Line 156	Container MUST -> Container that MUST"
23	Henry Lowe	Email dated 8/21 Fig in 2.1	put a reference on it such as Figure 2-1.
24	Gordon van Huizen	email dated 8/21     Line 180-189	Some degree of mapping to transport envelopes must be addressed in the spec, at least in the form of a recommendation, for interoperability.
25	Marty Sachs	email dated 8/20     Line 184-185	I don't understand what the 'standard transport level envelopes are.'  If this refers to the standard headers defined by HTTP, FTP, SMTP, etc., have all transport envelopes places to put the identity of a specific ebXML handler?
26	Marty Sachs	email dated 8/20     Line 187	Please explain 'such structures' and when the transport envelope is required.  Ifthe transport envelope is really the HTTP, SMTP, FTP, etc. header, then it is always required. This sentence seems to imply that the transport envelope is in fact something else.  What is it?
27	Marty Sachs	email dated 8/20     Line 188-189	A transport envelope is not needed for FTP.'  FTP must have some kind of headers so again, there is an implication that the transport envelope is something else.  Is 'transport envelope' supposed to be 'Message envelope'?  But if so, why is it not needed for FTP?
28	David Burdett	Email dated 8/21  Line 189'	We need to specify exactly how to specify the data communication (aka transport) envelopes for specific protocols
29	David Burdett	Email dated 8/21  Linre 190-191	Change "Message Envelope" to "ebXML Message Envelope" to make consistent with diagram on page 7
30	David Burdett	Email dated 8/21  Line 193	Change "headers" -> "headers that conform to [RFC 2045]" to mandate conformance to the standard
31	Ian Jones	email dated 8/17     Line 194	reverse line 194 and 195 to match the following text
32	David Burdett	Email dated 8/21  Line 197-198'	Change first sentence to "ContentType SHALL be set to 'multipart/related' on all ebXML Message Envelopes."
33	Ian Jones	email dated 8/17     Line 198	replace 'X' with Appendix D
34	Dick Brooks	email dated 8/14      Line 198	replace 'multi-part' with 'multipart'
35	Henry Lowe	Email dated 8/21 Line 199-201	199 says there are four attirbutes, but only two are listed, i.e., type and boundary (items 1 and 4  2 and 3 are missing).
36	David Burdett	Email dated 8/21          Line 199-201'	Only two attributes are defined. Not sure if this is a typo or an omission
37	Dick Brooks	email dated 8/14               Line 200	replace 'four' with 'two'
38	David Burdett	Email dated 8/21  Line 201	Add an example of a Content-Type attribute
39	Dick Brooks	email dated 8/14      Line 202	replace '4' with '2'
40	Henry Lowe	Email dated 8/21 Line 204-205	If there is only one valid value, the text "is an example usage of the" should be changed to "line must be included for".
41	David Burdett	Email dated 8/21  Line 206	Limit example to just the "type= ..."
42	Marty Sachs	email dated 8/20     Line 210-211	This specification should sprcify a boundary string that cannot occur in the content areas of a body part.  If there is not sucah a unique string, then this specification should have some discussion (informative?) of how to select an appropriate string for a given message.
43	David Burdett	Email dated 8/21  Line 212	Limit example to just "boundary= ..."
44	Dick Brooks	email dated 8/14      Line 213	remove 'version=0.1' from the example
45	David Burdett	Email dated 8/21  Line 214	Move section 2.3.2 on Content-Length to before section 2.3.1 to make consistent with the list on lines 194/5
46	Henry Lowe	Email dated 8/21 Line 220	application/vnd.eb+xml  should be changed to "application/vnd.eb+xml", i.e., remove the spaces after and before the ".
47	Dick Brooks	email dated 8/14      Line 221	insert a ':' before 'boundary'
48	Dick Brooks	email dated 8/14      Line 221	remove the spaces before and after 'application/vnd.eb+xml'
49	Henry Lowe	Email dated 8/21 Line224-225	Can there be more than one header?  If no, the text "There MUST be one ebXML header ..." should be chnaged to read "There MUST be one and only one ebXML header ...".
50	David Burdett	Email dated 8/21  Line 225-227'	Following on from General Comment 2 above, change last sentence to read "The ebXMl Heder Envelope container consists of an ebXML Header Envelope and an ebXML Header Document"
51	Dick Brooks	email dated 8/14      Section 2.4	add the following to sectrion 2.4:  'The header body part MUST occur as the first (a.k.a. root) body part in an ebXML message.
52	David Burdett	Email dated 8/21  Line 228	Change to "The ebXML Header Envelope conforms to [RFC2045] amd consists of three MIME headers:"
53	David Burdett	Email dated 8/21  Line 238	elete second sentence of this para as it is covered by change to L228 above
54	Henry Lowe	Email dated 8/21 Line 241-244	Is this value the same as the value in section 2.3.2?  It sounds like it is.  If it is, so state.
55	Dick Brooks	email dated 8/14      Lines 243. 244	In section 2.4.2. Replaced lines which read, 'The Content-Length header is a decimal value used to identify the total number of OTCTST contained in the constituent message body parts, includeing body part boundaries. Emple:' with 'The Content-Length header is a decimal value used to identify the total number of OCTETS contained in the ebXML header document (excluding body part boundaries). Example:'
56	David Burdett	Email dated 8/21  line 248	It wasn't clear to me what was being referred to by the "encoded" attribute. It needs to be made specific
57	David Burdett	Email dated 8/21  Line 249	I think "message structures" is ambiguous. Suggest changing sentence to "version - a value indicating the version of the ebXML Transport, Routing and Packaging Messaging Specification that the structure of the message conforms to"
58	David Burdett	Email dated 8/21  Line 251-253	Guidance or rules need to be specified on when the version (or versionless) alternatives should beused
59	Henry Lowe	Email dated 8/21 Line 253	while the version of this document is 0.1, the final released document will be 1.0.  Change ""0.1"" to ""1.0"".
60	Dick Brooks	email dated 8/14      Line 254	replace "0.1' with '1.0'
61	Henry Lowe	Email dated 8/21 Line 256	Is ISO 8895-1 identical to UTF-8?  If so, perhaps this should be noted.
62	Dick Brooks	email dated 8/14      Line 256	replace 'iso-8859-1' with 'UTF-8'
63	Dick Brooks	email dated 8/14      Line 259	remove the spaces between 'charset' and '=' and 'UTF-8'
64	David Burdett	Email dated 8/21  Line 259	Optional Support for Signed Header. This whole section strikes me as very woolly and therefore likely to be interpreted differently by implementers. I suggest that we remove this and also the reference to digital signing on L233, pending development of the security spec.
65	Henry Lowe	Email dated 8/21 Line 259-268	Do we want to say anything about multi-hop transmission of messages?  For example "NOTE: In the case of multi-hop transmission (e.g.,bridging), it will be necessary to de-crypt or re-sign header documents at intermediate forwarding nodes."
66	David Burdett	Email dated 8/21  Line 270	Change "envelope" -> "Container"
67	Ian Jones	email dated 8/17     Line 281	replace 'X' with Appendix B
68	Marty Sachs	email dated 8/20     Line 283	Replace 'transport-specific' by 'message-service-specific'  Please examine the document for any remaining instance of 'transport' which really refer to the messaging service.
69	David Burdett	Email dated 8/21  Line 283-289	It is not clear, how it is decided what entries go in the Manifest. I suggest that we replace the second sentence to the end of the paragraph with ... "The ebXML Header Document contains a Message Manifest that identifies the parts of the ebXML Header Document that are present as well as the payload information that is present. See section xxx Message Manifest, for rules on what should exist. If the Message Manifest indicates that a Payload Container is present, then it will consist of an ebXML Payload Envelope and a content portion.
70	David Burdett	Email dated 8/21  Line 284	"is/are" -> "are"
71	Ian Jones	email dated 8/17     Line 287	change 'Payload Container wil not be present' to 'Payload Container SHALL not be present'
72	David Burdett	Email dated 8/21  Line 290	Change to "The ebXML Payload Envelope conforms to [RFC2045] and consists of three MIME headers:
73	David Burdett	Email dated 8/21  Line 295	Change both "payloads" to "containers".
74	David Burdett	Email dated 8/21  Line 299	Delete "MIME header  identifies this instance of an ebXML"
75	Henry Lowe	Email dated 8/21 Line 299-300	some words are missing, but it's not clear what  please fix.
76	Marty Sachs	email dated 8/20     Line 300	I believe that the words, 'identifies the instance of an ebXML' should be deleted.
77	David Burdett	Email dated 8/21  Line 300-301	Remove second sentence as covered by change to L290
78	Dick Brooks	email dated 8/14      Lines 300/301	replace "The Content-ID MIME header identifies this instance of an ebXML is used to uniquely identify an instance of an ebXML message payload body part." with  "The  Content-ID MIME header is used to uniqely identify an instance of an ebXML message payload body part."
79	Henry Lowe	Email dated 8/21 Line 303	in the example, is "ebxmlpayload" required?  If not, how do you know that this part contains a payload?  There is no attribute saying this is a payload.
80	Dick Brooks	email dated 8/14     Line 311	replace 'header' with ''payload'
81	Ian Jones	email dated 8/17     Line 312	entire section only discusses digital signature not encryption, it is a direct copy of section 2.4.4 at line 259
82	Dick Brooks	email dated 8/14      Line 313	replace 'application/vnd.eb+xml' with 'application/xml'
83	David Burdett	Email dated 8/21  Line 312-321	See comments on Optional Support for Signed Header above.
84	Dick Brooks	email dated 8/14      Section 2.5.4	need to specify that encryption is also allowed.
85	Dick Brooks	email dated 8/14      Section 2.5.4.	should specify that implementers SHOULD indicate the character set used within the payload when the content-type permits the inclusion of the 'charset' parameter.
86	David Burdett	Email dated 8/21  Line 323	Change "ebXML Payload envelope" to ebXML Payload Container"
87	Ian Jones	email dated 8/17     Line 333	replace 'X' with 'Appendix B'
88	Henry Lowe	Email dated 8/21 Line 334-355	Is the Message digest some sort of check sum such as a CRC?  If so, where does it go in the message?
89	David Burdett	Email dated 8/21  Line 334	Message Digest. I think that we should make this stricter to improve interoperability. How about ... >>>Parties may create a "Message Digest" over a "Domain of Computation" to ensure the integrity of data exchanged using messages that conform to this specification. The Domain of Computation begins with the first "-" octet of the first boundary following the ebXML Message Envelope. The Domain of Computation ends with the last "-" of the final boundary of an ebXML message.  All octets between and including these begin and end points are Domain of Calculation. A Message Digest is calculated by applying a [SHA1] or [MD5] hash over the domain of computation and storing the result in xxx.<<< What isn't clear to me is how the digest should be recorded in an interoperable way. It can't go in the
90	Ian Jones	email dated 8/17     Line 341	should the definition of '-' be the full ASCII.  I have not checked the spec, I know this is very picky but we must be exacly to ensure interoperability
91	Marty Sachs	email dated 8/20     Line 344	I believe some words are missing at the end of this line.  I cannot find anything in this document indicating where the message digest goes.
92	Ian Jones	email dated 8/17     Line 348	change 'points' to 'octets'.
93	Dick Brooks	email dated 8/14      Lines 351, 352	in example, replace lines with "Content-Type: multipart/related; type="application/vnd.eb+xml"; boundary="8760"
94	Henry Lowe	Email dated 8/21 Line 356	Section headers, such "3 Message Header" should match the boxes in figure 2-1 in section 2.1.  For example, this section should be "3 ebXML Header Document".  Make it much easier to read the document.
95	David Burdett	Email dated 8/21  Line 356	Change "Message Header" -> "ebXML Header Document" to conform to the diagram on page 7
96	David Burdett	Email dated 8/21  Line 357	Change "ebXML Header" -> "ebXML Header Document"
97	David Burdett	Email dated 8/21  Line 358	Change "each header" -> "each principal header"
98	David Burdett	Email dated 8/21  Line 364	Remove line
99	David Burdett	Email dated 8/21  Line 366	to he -> "to the"
100	David Burdett	Email dated 8/21  Line 369-370	Delete last sentence as the reason for this statement (routing headers?) is not explained. If we include it we need to specify the circumstances or reasons why information might be added
101	Henry Lowe	Email dated 8/21 Line 372-373	The first sentence isn't entirely clear.
102	Dick Brooks	email dated 8/14      line 370	replace 'he' with 'the'
103	Marty Sachs	email dated 8/20     Line 373	The word 'MAY' on this line is snot being used in the RFC2119 sense.  Removethe capitalizaiton.
104	Marty Sachs	email dated 8/20     Line 374	Please provide 'To' and 'From' subelements for TPAId.  Each trading partner should be able to select its own value of TPAId in order to use it as a local rapid locator.
105	Marty Sachs	email dated 8/20     Line 374	Please add text explaining the meaning of the context attribute in TPAId
106	Marty Sachs	email dated 8/20     Line 376	ConversationId: Please add text explaining the meaning of the context attribute on ConversationId.  SEE EMAIL
107	Marty Sachs	email dated 8/20     Line 378	Please state that the valaue of the ServiceInterface tage is stated in the TPA.
108	Marty Sachs	email dated 8/20     line 381	Plese state that the action name is defined in the TPA.
109	David Burdett	Email dated 8/21  Line 382	Change "transport-specific" -> "messaging service-specific"
110	Ian Jones	email dated 8/17     Line 383	section referred to has been removed - remove entire sentence statring, "This is described in more…"
111	David Burdett	Email dated 8/21  Line 383	Reference to Section 4 is incorrect. Section 4 is now Security Considerations.
112	David Burdett	Email dated 8/21  Line 385-386	We don't define what we mean by an application-generate message. Suggest changing definition to "Normal - the ebXML Payload Container contains data that has been provided to the ebXML Messaging Service by the software that called it. For example a business document such as a Purchase Order"
113	David Burdett	Email dated 8/21  Line 387	a -> "an"
114	Gordon van Huizen	email dated 8/21     Line 387-388	In San Jose we discussed rolling Acknowledgment and Error message types (which are both messaging-service specific) into a generic "System" message type, as the primary intent of these types is to indicate whether the payload should be processed by the application or by the messaging service. Employing the generic System type also has other benefits:  (1) It allows for additional messaging-service specific messages beyond acknowledgment and error (such as start of frame, eartbeat, etc.); (2) There is no need for application programmers to be aware ofsystem-level messages and their types or subtypes. Enumerating them may prove confusing to application developers. I also have a concern about the use of the term "messaging-service specific". Does this mean that the essages are specific to (a) a particular messaging service implementation or (b) ebXML messaging services in general? If (a), they shouldn't be enumerated in the spec at all but my hair-trigger interoperability exception gets thrown. Either way, the term could be more clear.
115	David Burdett	Email dated 8/21  Line 390	Change definition to "Manifest - lists and identifies the content of the ebXML Header Document and the ebXML Payload Container" - for rationale see reference to line 407+ below.
116	Ian Jones	email dated 8/17     Line 391	More than routing information is held in the header suggest changing description to something like 'Header-information for processing the entire payload such as routing,…'
117	David Burdett	Email dated 8/21  Line391	Header isn't just routing information. Suggest changing to conform to definition on L368-9.
118	David Burdett	Email dated 8/21  Line 405	Change "Payload document(s)" -> "ebXML Header Document principal elements and ebXML Payload Container contents"
119	David Burdett	Email dated 8/21  Line 406	Change "document" -> "data or information"
120	David Burdett	Email dated 8/21  Line 407	Add section on guidelines for use ...  >>>Document Reference elements MUST created for each principal header element that is not a Manifest or a Header element. It is RECOMMENDED that Document Reference elements are created for each top-level MIME part contained within the ebXML Payload Container. It is an implementation decision of the application or process that is using the ebXML Messaging Service to specify which parte of the ebXML Payload Container are referenced by the Message Manifest".<<<  The rational for this is that knowledge of the existence of, for example, digital signatures, routing headers, etc in the ebXML Header Document is something that the ebXML Messaging Service could usefully discover from the Manifest. Specifying guidelines on what should be referenced in the ebXML Payload Containers should help provide some consistency of use.
121	David Burdett	Email dated 8/21  Line 411	Following on from a discussion on email ... i) Change "DocumentLabel" to "DocumentDescription" ii) Add new element "DocumentPurpose" that has a definition of ... >>>"A code that enables the purpose of the referenced document to be determined without retreiving it. Some values for Document Purpose are reserved by the ebXML Messaging Service. These begin with "ebXMLHeader:" and are followed by the name of the principal header element that is present."
122	David Burdett	Email dated 8/21  Line432	TPAInfo - just a place holder that I think changes are required here, that will arise out of work in the TP group that we haven't yet done.
123	David Burdett	Email dated 8/21  Line 449	Need to update definition of PartyId to reflect conclusion (?) of the discussion on the list on PartyId - suggest we add a comment that this is under review.
124	Henry Lowe	Email dated 8/21 Line 449-467	Two comments on these lines: 1. PartyId is not defined completely and, more importantly, the parameter "context" is not defined except in what can be derived from the example. It would seem from the example, that the address 12345 is a valid address for an underlying transport which recognizes and uses DUNS numbers to message delivery.  If this is the case, then the "context" parameter would seem to reflect the mapping onto the underlying transport and a message to be sent over a CORBA transport, you would have, for example <To> <PartyId context="corbalocURL">555xyz.com/Prod/TradingService</PartyId> </To>
125	Marty Sachs	email dated 8/20     Line 458-460	More discussion of the conterxt attribute in needed.  At a minimum, the following sentence should be added following the sentence ending on line 459:   The context attribute identifies the set of identifiers from which the value of PartyID is derived.  It may either identify a standard set of identifiers such as DUNS numbers or may be a keyword which identifies non-standard identifiers agreed to by the partners who are exchanging ebXML messages.
126	Ian Jones	email dated 8/17     Line 469	Is TPAInfo mandatory?
127	Ian Jones	email dated 8/17     Line 488	Where did 'context' come from in the example, it is not described anywhere?
128	Ian Jones	Teleconference 8/17  Line 495	need proposal to address 'Not Applicable' , 'None' or validation thru DTD
129	David Burdett	Email dated 8/21  Line494	Delete "uniquely". Message Data doesn't uniquely identify a message, Message Id does.
130	Ian Jones	email dated 8/17        Line475	definition needs to be corrected
131	Marty Sachs	email dated 8/20     497	MessageId:  Please add a discussion of the attribute called for in the DTD and add the attribute to the example.
132	Marty Sachs	email dated 8/20     Line 501	RefToMessageId:  Please add a discussion of the attribute called for in the DTD and add the attribute to the example. UUID is a default value of the attribute, not the message ID.
133	David Burdett	Email dated 8/21  Line 502	Change 'Not Applicable'" to ' "NotApplicable" (case-sensitive) '
134	Ian Jones	email dated 8/17     Line 502	Why is RefToMessageId mandatory?  No obvious rational, is NotApplicable' the correct setting? Is 'None' closer?
135	Marty Sachs	email dated 8/20     Line 508-510	Please use different message ids in these example forMessageId and RefToMessageID
136	Ian Jones	email dated 8/17     Line 512	Why is 'ReliableMessagingInfo' mandatory? Is 'Unspecified' the correct work?
137	David Burdett	Email dated 8/21  Line 512	See recent email suggesting new value of "Delivery Semantics" of "CommunicationProtocol"
138	Marty Sachs	email dated 8/20     Line 516	Please delete the word "subordinate".  An attribute is part of the tag.
139	Marty Sachs	email dated 8/20     Line 517	Please remove the capitalization from "MAY".  It is not being used here in the RFC2119 sense.  Please give an example of this tag.
140	Gordon van Huizen	email dated 8/21     Line 517	<AsbestosSuitOn> A number of references in other ebXML documents indicate that the purpose of reliable messaging is for guaranteed delivery ("OnceAndOnlyOnce" semantics, which is even called out specifically in some cases). It's fair to say that this is how ebXML reliable messaging is being marketed, and a reasonable expectation to many. Why, then, do we pull back here to "AtMostOnce"? Since we fully anticipate that ebXML implementations can ride atop reliable messaging infrastructures such as MQSeries and JMS implementations, why are we reluctant to provide a value of OnceAndOnlyOnce within the enumeration for the DeliverySemantics attribute? Presumably the ability to support guaranteed delivery is negotiated at the TPA level. If a given provider doesn't support guaranteed delivery, fine. But let's at least provide a value in the message header for it.  If we are dead serious about NOT supporting OnceAndOnlyOnce in ebXML, we need to ensure that other ebXML documents make it clear that it is not supported so that expectations are appropriately calibrated. My opinion, though, is that we should support OnceAndOnlyOnce for providers that are willing to offer it.  A further issue is that AtMostOnce should not imply reliability, although in our specs it does. The literal role of AtMostOnce is limited to dup elimination. The processing and performance impact for what we currently specify above and beyond dup elimination is significant. If the intention is to provide additional semantics beyond AtMostOnce ("I don't guarantee that a message will arrive safely, but I will make my best effort to be reliable by providing persistence for all reliable messages at both sides of the link and I can tell you whether a message did or did not make it to the receiving message service persistence store"), there should at least be a way to specify whether or not a given message requires this level of reliability. Simply indicating "AtMostOnce" or "Unspecified" does not offer this distinction.  If we continue to NOT support the notion of guaranteed messages (OnceAndOnlyOnce), my recommendation would be to completely decouple "persistent" messages from "at most once" messages--a decoupling for which there is some precedence. If others feel that we should not decouple these semantics for some reason, we need to find an alternative to calling our reliable semantics "AtMostOnce". </AsbestosSuitOn>
141	David Burdett	Email dated 8/21  Line 521	This section should be removed pending completion of the TRP Security spec.
142	David Burdett	Email dated 8/21  Line 522	If this section is kept then "Realm Security" needs to be explained. It doesn't mean anything to me.
143	Marty Sachs	email dated 8/20     Line 524	Please provide a normative reference to SSL.
144	David Burdett	Email dated 8/21  Line 527	References - Need to expand references to include other documents (e.g. [RFC2045].
145	David Burdett	Email dated 8/21  Line 527	(and elsewhere). Need to make the referencing style consistent.
146	Marty Sachs	email dated 8/20     Line 528	Please change the title to "Normative Referneces".  Any informative references should go in a separate section.
147	Marty Sachs	email dated 8/20     Line 533	Please provide a normative reference to Realm Security.
148	Marty Sachs	email dated 8/20     Line 537	Please add the title of RFC 2111,  add a reference to XML 1.0,  add a reference to the MIME RFC, add references to any other standards referred to in the text
149	David Burdett	Email dated 8/21'	We should use "communication protocol" rather than "transport" or "transport protocol" when we are referring to the likes of HTTP or SMTP. Lines where this applies are: 101, 102, 121, 152, 153, 180, 181, 182, 184, 186, 187 (twice), 189 (twice), 521, 1317, 1327, 1338 (transport level requirement)
150	David Burdett	Email dated 8/21'	Envelope vs Container. These are used ambiguously. For example, the diagram on page 7 suggests that the ebXML (header or payload) container and the envelope are the same. However the examples on lines 273-280 (header) and lines 325-332, indicate that the "header" is the MIME header for the mime part. Suggest we add the following definitions after the diagrams on page 7:                                                       "* An ebXML Header (or Payload) Envelope are the MIME headers that are associated with a MIME part                                                         * An ebXML Header (or Payload) document is the content of the MIME part and is:                                                                                                                                                       - an XML document for the ebXML Header, and                                                                                                            - an XML or some other document for the ebXML Payload * An ebXML Header (or Payload) container, is the combination of the ebXML Header (or Payload) envelop and the document it contains" 3. Appendices C & D Why are these included within the spec. I think that they should be removed as it makes the spec shorter and they are non-normative. However I don't think the information should be lost. It should be included in a non-normative "rationale" document that explains how decisions were made for those people who are new to ebXML TRP.
151	Henry Lowe	Email dated 8/21 ROUTING	This is not unrelated to the issue of routing.  This document says nothing about how routing is handled or reflected in the message header.  If we are using source routing (i.e., the message originator or perhaps the TPA defines the route the message will take to the destination).  Presumably a full set of source routing information will need to be contained in the header or perhaps in subheaders containing the route when the route comprises more than a single hop.  This set of routing information would have to contain the necessary "context" for each transport in the case of different transports being used for different hops, e.g., hop-1 uses HTTP, hop-2 uses CORBA, hop-3 uses MQSeries, and hop-4 uses SMTP (OK, perhaps this is a bit complicated, but the  header information structure should be able to support this  heaven knows what the real world may turn up).
152	Marty Sachs	Email dated 8/22  GENERAL	Some of the dicussions about interrelations between Reliable Messaging and transport protocols point up the need to state the assumptions about the transport function in some manner.  One possibility is some kind of definition of a conceptual interface between the Messaging Service and the transport function.  It's fine to say that the messaging service is agnostic to the transport protocol but in real life, the Messaging Service run-time must interact with the transport run-time. Design of the messaging service protocol must be with the understanding of what goes on in the most likely transports.  Since it is highly likely that an implementation will include both the messaging service and the transport function, it may be  sufficient to express the interactions as a series of informative notes (or an informative appendix) rather than as a formal interface definition. The important point is that the assumptions have to be stated to ensure that the messaging service and transport function will work together correctly.
153	David Burdett	Email dated 8/21  Appendix B	Suggest removing the detail of the XML documents to make the examples much shorter.
154	David Burdett	Email dated 8/21  GENERAL	Add titles to all figures.
155	David Burdett	Email dated 8/21  GENERAL	Use capitals consistently, specifically:   i) "ebXML header document" -> "ebXML Header Document"   ii) "ebXML header envelope" -> "ebXML Header Envelope"
156	Marty Sachs	Acknowledgments	Are they up to date?
157	Dick Brooks	email dated 8/14      General	version' is in the Content-type header of the ebXML header and in the ebXMLHeader root element of the ebXML header document.  I should be in only one place.
158	Dick Brooks	email dated 8/14      General	we need to provide a complete list of possible values for the 'content' attribute within the PartyId element.
159	Dick Brooks	email dated 8/14      General	The MessageData element should also include a 'DeliveryDeadline' element which indicates the last instance in time a message can be delivered to an intended recipient and a 'ResponseDeadline' element to tell the receiver how long they have to send an acknowledgment.  I believe it would also be valuable to indicate how an acknowledgment should be sent on the same session that was used to send the ebXML message.  If the AcknowledgeTo element is not present then whatever was specified in the TPA determines how acknowledgments are delivered.
160	Shumpei Nakagaki	email dated 8/16        Appendix B          Line 801-803, 1064-1067	The Appendix B shows the ebXML Message envelope message example only.  The spec is for the envelope and header. Line 801 thru 803 and line 1064 thru 1067 should be replaced with:                                                                                                                          <MessageType>Normal</MessageType><Manifest><DocumentReference><DocumentLabel>Payroll</DocumentLabel><Intent>RecordCommission</Intent></DocumentReference></Manifest><Header><From><PartyId context="DUNS">12345</PartyId></From><To><PartyId context="DUNS">67890</PartyId></To><TPAInfo><TPAId Context="tpadb">12345678</TPAId><ConversationId context="tpadb">987654321</ConversationId><ServiceInterface>RecordCommission</ServiceInterface><Action>Newrecord</Action></TPAInfo><MessageData><MessageId>123456789</MessageId><TimeStamp>20000725T122905.000Z</TimeStamp><RefToMessageId>987654321</RefToMessageId></MessageData><ReliableMessageInfo><DeliverySemantics>"Unspecified"</DeliverySemantics></ReliableMessageInfo></Header>
161	Marty Sachs	Email dated 8/22   Appendix B	Both of the example XML files in Appendix B need to be updated to conform to the new header definitions, both <ebXMLMessageHeader> and <Header>.  The DTD and Schema appear to be OK.

Messaging Service Structure Change List (v1.0).xls