HTML copy of list

[Ralph Berwanger <rab7067@earthlink.net>]

I apologize to those who are not using Excel.  Attached is a HTML copy of the comment list.

 

Ralph Berwanger

 

Category: 1- Editorial, 2-Minor Technical, 3-Major Technical
Item		Reference
No.	Submitter	Line	Email	Category	Comment	Status
1	David Burdett	14	21-Aug	1	Arrange authors in alphabetic order
1a	Phillipe DeSmedt	5 44	24-Aug	1	we need to make sure that the lists of authors and contributors, as well as the Acknowledgements section (6) are up-to-date -- there are many people who have valuably contributed to the specs, through e-mail, conference calls, and face-to-face meetings, that have been left off;
2	David Burdett	12-16	21-Aug	1	Add angle brackets
3	David Burdett	29	21-Aug	2	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.
3a	Chris Ferris	98-104	22-Aug	1	This section should reflect the revised nature of the document.  The Messaging Service (ebXML-MS) specification will define the whole service, not just the structure of the messages.  I like Rik's idea of having 'parts' or 'sections' but another consideration would be to wait for the revised format and as a group, decide how a 'service' can be mapped.
4	David Burdett	99	21-Aug	2	change "encapsulate ebXML" to "encapsulate (package) ebXML" as otherwise need to define what is meant by package on lines 136/7
5	David Burdett	99-100	21-Aug	2	replace "ebXML message headers and payloads" by "ebXML payloads" as the message header is covered by this spec
5a	Phillipe DeSmedt	100-101	24-Aug	2	if we will indeed have a section where bindings are specified for mime-aware vs non-mime-aware transports, as we have been discussing, we'll need to update the Introduction (1), where it is currently stated that 'no assumption or dependency is made relative to transport protocol [...]
6	Marty Sachs	100-101	20-Aug		delete 'ebXML message headers' since the headers are part of the structure specified in this document
7	Ian Jones	102	17-Aug	1	remove the sentence starting "The main goal…" it is repeated.
8	Marty Sachs	103	20-Aug		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.
8a	Chris Ferris	105-112	22-Aug	1	see item 3a
9	Gordon van Huizen	104	21-Aug	2	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	106	17-Aug	1	reverse the order of the first 2 sentences
11	Ian Jones	109	17-Aug	X	This may be incorrect when document is reformatted
12	David Burdett	111	21-Aug	3	Remove Service Interface or at least make it optional as Service Interface may be in a separate spec
13	Ian Jones	122	17-Aug	1	Entire section will need revision if document is reformatted
14	Gordon van Huizen	124-127	21-Aug	X	The list here needs to be expanded to include the itemsin the note on lines 111-112.
15	David Burdett	132-133	21-Aug	1	Fix indentation
16	David Burdett	140	21-Aug	1	text missing. Replace by copying text from lines 360-370
17	Ian Jones	141	17-Aug	1	remove lines 140 and 141
17a	Dale Moberg	line 143	18-Aug	2	The MIME and HTTP/SMTP conventions always assume that the header field-name is case-insensitive for matching operations. Values in a field-body (the stuff after the colon) can be case-sensitive (see RFC 822, 3.4.7) . Mime content-type values are case-insensitive; (RFC 2045, section 5.1) and parameter names are case insensitive. The term "attribute" is an XML term and not a MIME term for a syntactical unit. The way the language reads now it suggests that any value in the header is to be matched in a case-insensitive way. Is that what is wanted? I don't think so, especially for Message-ID and Content-Id values, for example.
18	David Burdett	144-145  148-149	21-Aug	2	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	149	21-Aug	2	Add another bullet point to explain use of italics, e.g. Message Manifest is in italics on Line 284
19a	Chris Ferris	122	22-Aug	2	Do we want to rename this section?  I would think that a related and relevant ebXML specification would be the one to be developed by the newly formed Trading Partner PT.
20	Henry Lowe	154	21-Aug	2	as there is no other ebXML enveloping than MIME, change the "for example MIME ..." to "i.e., MIME ...".
21	David Burdett	154	21-Aug	1	Change "for example" to "specifically" as we only allow MIME
22	David Burdett	157	21-Aug	1	Container MUST -> Container that MUST"
22a	Chris Ferris	140	22-Aug	1	This needs to be a little less terse.  Something like: "Message Headers-a specification of the structure and composition of the information necessary to an ebXML Messaging Service to sucessfully process an ebXML compliant message.
22b	Chris Ferris	141-142	22-Aug	1	Do we still need this?
22c	Chris Ferris	144	22-Aug	2	XML tags are case sensitive.  The statement here derives from the packaging sprcification which discusses MIME headers and attributes which is expressly case sensitive.  I think that this needs some serious clarification before the document is released.
23	Henry Lowe	180	21-Aug	1	put a reference on it such as Figure 2-1.
23a	Chris Ferris	152	22-Aug	X	This seems to be an unintended carry-over from the merge and should be removed.
23b	Chris Ferris	152	22-Aug	2	Do we want to define the term and concept of an ebXML message?  I would think that we would.  I think that we should have a consistent mechanism for identifying all ebXML Glossary defined terms and that ebXML message should be one of those terms.
24	Gordon van Huizen	181-190	21-Aug	3	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	184-185	20-Aug		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?
25a	Chris Ferris	154	22-Aug	1	Remove the phrase 'for example'.  We have concluded that it is MIME multipart/related… Suggest phrasing:  A transport independent message envelope which is a MIME multipart/rrelated container which encapsulates the two principal parts of an ebXML message.
26	Marty Sachs	187	20-Aug		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?
26a	Chris Ferris	157	22-Aug	1	Change to 'a single Payload Container…' for clarity.
27	Marty Sachs	188-189	20-Aug		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	190	21-Aug	3	We need to specify exactly how to specify the data communication (aka transport) envelopes for specific protocols
29	David Burdett	192-193	21-Aug	1	Change "Message Envelope" to "ebXML Message Envelope" to make consistent with diagram on page 7
30	David Burdett	194	21-Aug	1	Change "headers" -> "headers that conform to [RFC 2045]" to mandate conformance to the standard
31	Ian Jones	194-195	17-Aug	1	reverse line 194 and 195 to match the following text
32	David Burdett	198-199	21-Aug	1	Change first sentence to "ContentType SHALL be set to 'multipart/related' on all ebXML Message Envelopes."
33	Ian Jones	198	17-Aug	1	replace 'X' with Appendix D
34	Dick Brooks	198	14-Aug	1	replace 'multi-part' with 'multipart'
35	Henry Lowe	200-202	21-Aug	2	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	200-202	21-Aug	2	Only two attributes are defined. Not sure if this is a typo or an omission
36a	Dale Moberg	line 203 and elsewhere	18-Aug	1	A Content Id value is to have the same syntax as a Message Id (RFC 2045,section 7) , so in the example, the string should begin with '<' and end with '>'. (The BNF++ is " msg-id =  "<" addr-spec ">") The explanation of the cid: URI  presumes that the content-id has this syntax, because it strips off the "<" and ">" to avoid conflicts with XML lexical rules. So throughout all the example PDUs, the values should look like legal Content-Ids, like <fds78904321quafouipq@ebxmlhost.realm>
37	Dick Brooks	200	14-Aug	1	replace 'four' with 'two'
38	David Burdett	202+	21-Aug	1	Add an example of a Content-Type attribute
39	Dick Brooks	202	14-Aug	1	replace '4' with '2'
40	Henry Lowe	205-206	21-Aug	1	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	207	21-Aug	1	Limit example to just the "type= ..."
42	Marty Sachs	210-211	20-Aug		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.
42a	Chris Ferris	182-186	22-Aug	3	I think that we need to resolve this issue before we release the document for review.  It is too much of a substantial change to leave out.  I think that Dick owns this, correct?
43	David Burdett	213-214	21-Aug	1	Limit example to just "boundary= ..."
44	Dick Brooks	213	14-Aug	1	remove 'version=0.1' from the example
45	David Burdett	215	21-Aug	1	Move section 2.3.2 on Content-Length to before section 2.3.1 to make consistent with the list on lines 194/5
46a	Chris Ferris	189-190	22-Aug	1	Change: 'Implementers of software to process ebXML messages MUST…' to 'Implementers of an ebXML Messaging Service MUST…'  I also think that the close of this sentence could be made more clear.
46	Henry Lowe	221	21-Aug	1	application/vnd.eb+xml  should be changed to "application/vnd.eb+xml", i.e., remove the spaces after and before the ".
47	Dick Brooks	221	21-Aug	1	insert a ':' before 'boundary'
48	Dick Brooks	221	21-Aug	1	remove the spaces before and after 'application/vnd.eb+xml'
48a	Chris Ferris	192	22-Aug	1	If Message Envelope is a glossary defined term, it should be capitalized and italicized, no?  Also, message should be ebXML Messages and similarly italicized.
49	Henry Lowe	225-226	22-Aug	2	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	224-228	22-Aug	2	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	Sect 2.4	22-Aug	1	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	227	22-Aug	1	Change to "The ebXML Header Envelope conforms to [RFC2045] amd consists of three MIME headers:"
52a	Chris Ferris	199	22-Aug	1	I assume that the appendices will be cross referenced with their references.  Please review to ensure that any references are updated accordingly before publishing.
52b	Chris Ferris	200	22-Aug	1	References four (4) attributes, yet only two (1 and 4) are listed. Please fix.
52c	Chris Ferris	201-202	22-Aug	2	Arethese attributes mandatory?  Should we use MUST or SHALL to make this clear?  I would think that both attributes MUST be present.  Type to clearly and unambiguously idnetify the message as an ebXML Message and the other (boundary) to demark the boundaries of the MIME multipart/related body parts.
53	David Burdett	238-240	22-Aug	1	elete second sentence of this para as it is covered by change to L228 above
54	Henry Lowe	242-245	22-Aug	2	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	243-244	22-Aug	3	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:'
55a	Chris Ferris	216	22-Aug	1	Is content-Length a mandatory header?  If so, this should be made explicit.  If not, then the header should be expressly identified as advisory.  I would think that it would be useful to have this always present.
56	David Burdett	248	22-Aug	2	It wasn't clear to me what was being referred to by the "encoded" attribute. It needs to be made specific
57	David Burdett	250	22-Aug	2	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	252-254	22-Aug	2	Guidance or rules need to be specified on when the version (or versionless) alternatives should beused
59	Henry Lowe	254	22-Aug	1	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	254	22-Aug	1	replace "0.1' with '1.0'
61	Henry Lowe	257	22-Aug	2	Is ISO 8895-1 identical to UTF-8?  If so, perhaps this should be noted.
62	Dick Brooks	256	22-Aug	2	replace 'iso-8859-1' with 'UTF-8'
63	Dick Brooks	259	22-Aug	1	remove the spaces between 'charset' and '=' and 'UTF-8'
64	David Burdett	260-270	22-Aug	3	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	260-270	22-Aug	3	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	272	22-Aug	1	Change "envelope" -> "Container"
67	Ian Jones	283	22-Aug	1	replace 'X' with Appendix B
68	Marty Sachs	283	22-Aug		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	285-291	22-Aug	3	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	286	22-Aug	1	"is/are" -> "are"
71	Ian Jones	288	22-Aug	1	change 'Payload Container wil not be present' to 'Payload Container SHALL not be present'
72	David Burdett	292	21-Aug	1	Change to "The ebXML Payload Envelope conforms to [RFC2045] and consists of three MIME headers:
73	David Burdett	297	21-Aug	1	Change both "payloads" to "containers".
74	David Burdett	301	21-Aug	1	Delete "MIME header  identifies this instance of an ebXML"
75	Henry Lowe	301-302	22-Aug	1	some words are missing, but it's not clear what  please fix.
76	Marty Sachs	300	22-Aug		I believe that the words, 'identifies the instance of an ebXML' should be deleted.
77	David Burdett	301-304	21-Aug	1	Remove second sentence as covered by change to L290
78	Dick Brooks	300-301	22-Aug	1	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	305	22-Aug	2	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	311	22-Aug	1	replace 'header' with ''payload'
81	Ian Jones	314	22-Aug	2	entire section only discusses digital signature not encryption, it is a direct copy of section 2.4.4 at line 259
82	Dick Brooks	313	22-Aug	1	replace 'application/vnd.eb+xml' with 'application/xml'
83	David Burdett	312-321	21-Aug	1	See comments on Optional Support for Signed Header above.
84	Dick Brooks	Section 2.5.4	22-Aug	3	need to specify that encryption is also allowed.
85	Dick Brooks	Section 2.5.4	22-Aug	1	should specify that implementers SHOULD indicate the character set used within the payload when the content-type permits the inclusion of the 'charset' parameter.
85a	Philippe DeSmedt	Section 2.5.4	22-Aug		Optional Support for Signed and Encrypted Payloads: This section appears to have been copied verbatim from section 2.4.4 (Optional Support for Signed Headers), and makes no mention of encryption. Encryption is not done on the header, but it is suggested as a possibility for the payload. As such, we'll need to add a sentence or paragraph to section 2.5.4 that actually specifies how encryption could de done (in addition to signing), i.e., have the body of the section correspond to its title;
86	David Burdett	326	22-Aug	1	Change "ebXML Payload envelope" to ebXML Payload Container"
87	Ian Jones	336	22-Aug	1	replace 'X' with 'Appendix B'
88	Henry Lowe	337-358	22-Aug	2	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	334	22-Aug	3	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	344	22-Aug	2	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	344	22-Aug		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	351	22-Aug	1	change 'points' to 'octets'.
93	Dick Brooks	351-352	22-Aug	1	in example, replace lines with "Content-Type: multipart/related; type="application/vnd.eb+xml"; boundary="8760"
94	Henry Lowe	359	22-Aug	1	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	359	22-Aug	1	Change "Message Header" -> "ebXML Header Document" to conform to the diagram on page 7
96	David Burdett	360	22-Aug	1	Change "ebXML Header" -> "ebXML Header Document"
97	David Burdett	361	22-Aug	1	Change "each header" -> "each principal header"
98	David Burdett	364	4-Jan	1	Remove line
99	David Burdett	370	22-Aug	1	to he -> "to the"
100	David Burdett	376-377	22-Aug	2	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	376-377	22-Aug	1	The first sentence isn't entirely clear.
101a	Philippe DeSmedt	372-373	22-Aug		I'm a bit unclear as to the meaning of the NOTE in section 3 (lines 372-373): re. possibly missing header elements, it is stated: '[...] Every effort will be made to preclude this possibility.' As we are 'only' at version 0.1 of this document, there's a strong likelihood that things will change throughout the document (hopefully not by much). Why do we add a NOTE only to this section? Are we more concerned with this piece of the spec changing than other pieces? If so, why?
102	Dick Brooks	370	22-Aug	1	replace 'he' with 'the'
103	Marty Sachs	373	22-Aug		The word 'MAY' on this line is snot being used in the RFC2119 sense.  Removethe capitalizaiton.
104	Marty Sachs	374	22-Aug		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	374	22-Aug		Please add text explaining the meaning of the context attribute in TPAId
106	Marty Sachs	376	22-Aug		ConversationId: Please add text explaining the meaning of the context attribute on ConversationId.  SEE EMAIL
107	Marty Sachs	378	22-Aug		Please state that the valaue of the ServiceInterface tage is stated in the TPA.
108	Marty Sachs	381	22-Aug		Plese state that the action name is defined in the TPA.
109	David Burdett	386	22-Aug	1	Change "transport-specific" -> "messaging service-specific"
110	Ian Jones	387	22-Aug	1	section referred to has been removed - remove entire sentence statring, "This is described in more…"
111	David Burdett	387	22-Aug	1	Reference to Section 4 is incorrect. Section 4 is now Security Considerations.
112	David Burdett	389-390	22-Aug	2	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	391	22-Aug	1	a -> "an"
114	Gordon van Huizen	387-388	22-Aug		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	394	22-Aug	3	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	395	22-Aug	2	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	395	22-Aug	1	Header isn't just routing information. Suggest changing to conform to definition on L368-9.
118	David Burdett	410	22-Aug	1	Change "Payload document(s)" -> "ebXML Header Document principal elements and ebXML Payload Container contents"
119	David Burdett	411	22-Aug	1	Change "document" -> "data or information"
120	David Burdett	412+	22-Aug	3	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	416+	22-Aug	3	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	437	22-Aug	3	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	454+	22-Aug	3	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	454-472	22-Aug	2	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>
124a	Willaim Kammerer	454	22-Aug		The example shows a 5 digit value while it is qualified as a DUNS value and should be 9 digits, suggest that it be changed.
124b	Willaim Kammerer	454	22-Aug		We might need two attributes in the ,PartyhId> element, one top specify the promulgator or the code list (e.g., ISO 9735 , ISO 6523, ASC X12) and a second to give the specific naming authority.
125	Marty Sachs	458-460	22-Aug		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	473	22-Aug	2	Is TPAInfo mandatory?
127	Ian Jones	492	22-Aug	2	Where did 'context' come from in the example, it is not described anywhere?
128	Ian Jones	507	22-Aug	2	need proposal to address 'Not Applicable' , 'None' or validation thru DTD
129	David Burdett	494	22-Aug	1	Delete "uniquely". Message Data doesn't uniquely identify a message, Message Id does.
130	Ian Jones	475	22-Aug	?	definition needs to be corrected
131	Marty Sachs	497	22-Aug		MessageId:  Please add a discussion of the attribute called for in the DTD and add the attribute to the example.
132	Marty Sachs	502	22-Aug		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	507	22-Aug	1	Change 'Not Applicable'" to ' "NotApplicable" (case-sensitive) '
134	Ian Jones	505	22-Aug	2	Why is RefToMessageId mandatory?  No obvious rational, is NotApplicable' the correct setting? Is 'None' closer?
135	Marty Sachs	508-510	22-Aug		Please use different message ids in these example forMessageId and RefToMessageID
136	Ian Jones	517	22-Aug	2	Why is 'ReliableMessagingInfo' mandatory? Is 'Unspecified' the correct work?
137	David Burdett	520	22-Aug	3	See recent email suggesting new value of "Delivery Semantics" of "CommunicationProtocol"
138	Marty Sachs	516	22-Aug		Please delete the word "subordinate".  An attribute is part of the tag.
139	Marty Sachs	517	22-Aug		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	522	22-Aug	3	<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	521	22-Aug	3	This section should be removed pending completion of the TRP Security spec.
142	David Burdett	527	22-Aug	1	If this section is kept then "Realm Security" needs to be explained. It doesn't mean anything to me.
143	Marty Sachs	524	22-Aug		Please provide a normative reference to SSL.
144	David Burdett	532	22-Aug	1	References - Need to expand references to include other documents (e.g. [RFC2045].
145	David Burdett	533	22-Aug	1	(and elsewhere). Need to make the referencing style consistent.
146	Marty Sachs	528	22-Aug		Please change the title to "Normative Referneces".  Any informative references should go in a separate section.
147	Marty Sachs	533	22-Aug		Please provide a normative reference to Realm Security.
148	Marty Sachs	537	22-Aug		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	General	22-Aug	1	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, 153, 154, 181, 182, 183, 185,187, 188 (twice), 190 (twice), 526, 1322, 1332, 1343 (transport level requirement)
150	David Burdett	General	21-Aug	1	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 275-282 (header) and lines 328-335, 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
151	Henry Lowe	Routing	22-Aug	3	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	General	22-Aug		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	781+	22-Aug	1	Suggest removing the detail of the XML documents to make the examples much shorter.
154	David Burdett	General	22-Aug	1	Add titles to all figures.
155	David Burdett	General	22-Aug	1	Use capitals consistently, specifically:   i) "ebXML header document" -> "ebXML Header Document"   ii) "ebXML header envelope" -> "ebXML Header Envelope"
156	Marty Sachs	544+	22-Aug		Are they up to date? (acknowldegments)
157	Dick Brooks	General	22-Aug	2	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	General	22-Aug	3	we need to provide a complete list of possible values for the 'content' attribute within the PartyId element.
159	Dick Brooks	General	22-Aug	3	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	801-803, 1064-1067	22-Aug		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	781+	22-Aug		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.