OASISOASIS ebXML Messaging TC

OASIS ebXML Messaging TC Issues List

Last update: April 30, 2002

Issues regarding the documents produced by the OASIS ebXML Messaging TC should be reported to ebxml-msg@lists.oasis-open.org (public archives).

Comments on this list should be sent to the ebxml-msg@lists.oasis-open.org mailing list (Archives).

Summary List of Outstanding Issues

id Status Spec Topic Class Section Title
26 Not Accepted line 982 spec minor technical 3.2.2 Manifest validation suggestion to discard note
34 Deferred line 1512 spec technical 7.3.1.4 AckRequested error on ack and ack on error issue
36 Deferred line 1580 spec technical 7.3.2.8 Acknowledgment... error on ack
96 Deferred line 969 spec technical 3.2.1.1 Comment on 1.09 and on
110 Defer line 1279 spec technical 4.2.3 Comment on 1.09 and on
47 Defer to v3.0 none schema technical Appendix A Schema element should have an optional "namespace" attribute
3 Active line 20 spec editorial title page title page
4 Active line 23 spec editorial ebXML participants ebXML participants
6 Active line 200 spec editorial Introduction typo
10 Active line 509 spec editorial 2.1.2 Message Package RFC2119 usage
15 Active line 784 spec editorial 3.1.1.2 PartyId element RFC2119 usage
16 Active line 788 spec editorial 3.1.1.2 Role element replacement text for Note
19 Active line 872 spec editorial 3.1.6.1 MessageId element local part of MID?
22 Active line 903 spec editorial 3.1.8 DuplicateElimination element "if there is a CPA with ..." is a little too vague
23 Active line 914 spec editorial 3.1.9 MessageHeader example example issue
31 Active line 1436 spec editorial 7 Reliable Messaging Module duplicate elimination characterization
33 Active line 1459 spec editorial 7.2 Methods ... editorial tweak
35 Active line 1564 spec editorial 7.3.2.5 [XMLDSIG] Reference typo
38 Active line 2054... spec editorial 11 Multihop... duplicate content with 11.1.4
49 Active line 193 spec editorial 1 Comment on 1.09 and on
50 Active line 208 spec editorial 1.1.1 Comment on 1.09 and on
54 Active line 262 spec editorial 1.1.4 Comment on 1.09 and on
55 Active line 263 spec editorial 1.1.4 Comment on 1.09 and on
57 Active line 282 spec editorial 1.2.1 Comment on 1.09 and on
58 Active line 287 spec editorial 1.2.1 Comment on 1.09 and on
59 Active line 361 spec editorial 1.2.3 Comment on 1.09 and on
60 Active line 373 spec editorial 1.2.3 Comment on 1.09 and on
61 Active line 377 spec editorial 1.2.3 Comment on 1.09 and on
62 Active line 423 spec editorial 1.2.4 Comment on 1.09 and on
63 Active Figure 2.1 spec editorial 1.2.4 Comment on 1.09 and on
64 Active Figure 2.1 spec editorial 1.2.4 Comment on 1.09 and on
65 Active Figure 2.1 spec editorial 1.2.4 Comment on 1.09 and on
66 Active Figure 2.1 spec editorial 1.2.4 Comment on 1.09 and on
67 Active Figure 2.1 spec editorial 1.2.4 Comment on 1.09 and on
68 Active Figure 2.1 spec editorial 1.2.4 Comment on 1.09 and on
69 Active line 462 spec editorial 2.1 Comment on 1.09 and on
70 Active line 508 spec editorial 2.1.2 Comment on 1.09 and on
73 Active line 631 spec editorial 2.3.2 Comment on 1.09 and on
75 Active line 717-722 spec editorial 2.3.9 Comment on 1.09 and on
76 Active line 722 spec editorial 2.3.9 Comment on 1.09 and on
77 Active line 722 spec editorial 2.3.10 Comment on 1.09 and on
79 Active line 729 spec editorial 2.3.10 Comment on 1.09 and on
80 Active line 732 spec editorial 2.3.11 Comment on 1.09 and on
81 Active line 812-818 spec editorial 3.1.2 Comment on 1.09 and on
86 Active line 838-840 spec editorial 3.1.4 Comment on 1.09 and on
90 Active line 885 spec editorial 3.1.6.3 Comment on 1.09 and on
93 Active line 916,921,924,926 spec editorial 3.1.9 Comment on 1.09 and on
94 Active line 926 spec editorial 3.1.9 Comment on 1.09 and on
95 Active line 949 spec editorial 3.2.1 Comment on 1.09 and on
99 Active line 1035 spec editorial 4.1.2.1 Comment on 1.09 and on
100 Active line 1099 spec editorial 4.1.3 Comment on 1.09 and on
106 Active line 1169 spec editorial 4.1.4.5 Comment on 1.09 and on
108 Active line 1251,1254 spec editorial 4.2 Comment on 1.09 and on
109 Active line 1257 spec editorial 4.2 Comment on 1.09 and on
111 Active line 1281 spec editorial 4.2.3 Comment on 1.09 and on
112 Active line 1282 spec editorial 4.2.3 Comment on 1.09 and on
113 Active line 1284 spec editorial 4.2.3.1 Comment on 1.09 and on
115 Active line 1294 spec editorial 4.2.3.2 Comment on 1.09 and on
120 Active line 1311 spec editorial 4.2.3.2.4 Comment on 1.09 and on
121 Active line 1312 spec editorial 4.2.3.2.4 Comment on 1.09 and on
124 Active line 1318-1320 spec editorial 4.2.3.2.5 Comment on 1.09 and on
125 Active line 1352 spec editorial 4.2.4.1 Comment on 1.09 and on
133 Active line 1398 spec editorial 5.1 Comment on 1.09 and on
134 Active line 1395 spec editorial 5.1 Comment on 1.09 and on
140 Active line 1426 spec editorial 7 Comment on 1.09 and on
141 Active line 1429 spec editorial 7 Comment on 1.09 and on
142 Active line 1429 spec editorial 7 Comment on 1.09 and on
143 Active line 1435 spec editorial 7 Comment on 1.09 and on
144 Active line 1436 spec editorial 7 Comment on 1.09 and on
147 Active line 1473 spec editorial 7.3.1 Comment on 1.09 and on
151 Active line 1526 spec editorial 7.3.2 Comment on 1.09 and on
153 Active line 1541 spec editorial 7.3.2.4 Comment on 1.09 and on
154 Active line 1543 spec editorial 7.3.2.4 Comment on 1.09 and on
155 Active line 1554 spec editorial 7.3.2.5 Comment on 1.09 and on
157 Active line 1570 spec editorial 7.3.2.6 Comment on 1.09 and on
160 Active line 1568-1584 spec editorial 7.4.1 Comment on 1.09 and on
161 Active line 1593 spec editorial 7.4.1 Comment on 1.09 and on
162 Active line 1601-1603 spec editorial 7.4.2 Comment on 1.09 and on
163 Active line 1613 spec editorial 7.4.4 Comment on 1.09 and on
164 Active line 1621-1622 spec editorial 7.4.6 Comment on 1.09 and on
168 Active line 1665-1666 spec editorial 7.5.2 Comment on 1.09 and on
169 Active line 1673-1676 spec editorial 7.5.2 Comment on 1.09 and on
171 Active line 1692-1703 spec editorial 7.5.3 Comment on 1.09 and on
172 Active line 1725-1737 spec editorial 7.5.5 Comment on 1.09 and on
174 Active line 1728 spec editorial 7.5.5 Comment on 1.09 and on
175 Active line 1729 spec editorial 7.5.5 Comment on 1.09 and on
176 Active line 1730 spec editorial 7.5.5 Comment on 1.09 and on
177 Active line 1731 spec editorial 7.5.5 Comment on 1.09 and on
178 Active line 1732 spec editorial 7.5.5 Comment on 1.09 and on
179 Active line 1733 spec editorial 7.5.5 Comment on 1.09 and on
180 Active line 1734 spec editorial 7.5.5 Comment on 1.09 and on
181 Active line 1735 spec editorial 7.5.5 Comment on 1.09 and on
182 Active line 1737 spec editorial 7.5.5 Comment on 1.09 and on
184 Active line 1752-1753 spec editorial 7.5.6 Comment on 1.09 and on
186 Active line 1777 spec editorial 8 Comment on 1.09 and on
187 Active line 1827 spec editorial 8.2 Comment on 1.09 and on
188 Active line 1849 spec editorial 8.3 Comment on 1.09 and on
191 Active line 1910 spec editorial 9.1 Comment on 1.09 and on
192 Active line 1913 spec editorial 9.1 Comment on 1.09 and on
193 Active line 1921 spec editorial 9.1 Comment on 1.09 and on
194 Active line 1967 spec editorial 9.2 Comment on 1.09 and on
195 Active line 1993-1994 spec editorial 10 Comment on 1.09 and on
196 Active line 2006 spec editorial 10.1 Comment on 1.09 and on
198 Active line 2485 spec editorial B.2.2 Comment on 1.09 and on
200 Active line 2549-2555 spec editorial B.2.5 Comment on 1.09 and on
203 Active line 2638 spec editorial B.3.2 Comment on 1.09 and on
204 Active line 2656 spec editorial B.3.2 Comment on 1.09 and on
205 Active line 2676 spec editorial B.3.2 Comment on 1.09 and on
206 Active line 2786,2799,2802-2806 spec editorial References Comment on 1.09 and on
207 Active line 2744-2766 spec editorial References Comment on 1.09 and on
208 Active line 2744-2814 spec editorial References Comment on 1.09 and on
209 Active line 2744-2814 spec editorial References Comment on 1.09 and on
210 Active line 2744-2814 spec editorial References Comment on 1.09 and on
211 Active line 2787-2788 spec editorial References Comment on 1.09 and on
212 Active line 1-2842 spec editorial All Rollup comment on 1.09 and on
213 Active line 1-2842 spec editorial All Rollup comment on 1.09 and on
214 Active line 1-2842 spec editorial All The word "then" appears
217 Active line 228 spec editorial 1.1.1 Section 1.1 is missing.
218 Active line 618,621 spec editorial 2.3.2 Messed up indentation
221 Active line 1049,1053,1065,1068-1072 spec editorial 4.1.3 Consistent typography
222 Active line 1114,1116 spec editorial 4.1.3 Unneeded character entity
223 Active line 1407 spec editorial 6.1.1 Section 6.1 is missing.
225 Active line 1529-1530 spec editorial 7.3.2.1 More on issue 224
227 Active line 1923-1924 spec editorial 9.1 Uselessly repeat namespace, etc.
228 Active line 2093 spec editorial 11.1.2 Kill Acknowledgment/RefToMessageId
56 Active line 263 spec technical 1.1.4 Comment on 1.09 and on
74 Active line 699 spec technical 2.3.6 Comment on 1.09 and on
78 Active line 722 spec technical 2.3.11 Comment on 1.09 and on
82 Active line 812,813 spec technical 3.1.2 Comment on 1.09 and on
87 Active line 850-851 spec technical 3.1.4.1 Comment on 1.09 and on
92 Active line 887-896 spec technical 3.1.6.4 Comment on 1.09 and on
97 Active line 979-981 spec technical 3.2.2 Comment on 1.09 and on
102 Active line 1154-1157 spec technical 4.1.4.2 Comment on 1.09 and on
103 Active line 1154-1157 spec technical 4.1.4.2 Comment on 1.09 and on
107 Active line 1068-1078 spec technical 4.1.4.5 Comment on 1.09 and on
119 Active line 1302-1304 spec technical 4.2.3.2.2 Comment on 1.09 and on
122 Active line 1315 spec technical 4.2.3.2.5 Comment on 1.09 and on
135 Active line 1400-1401 spec technical 5.1 Comment on 1.09 and on
136 Active line 1380-1404 spec technical 5.1 Comment on 1.09 and on
139 Active line 1422-1423 spec technical 6.1.5 Comment on 1.09 and on
145 Active line 1443 spec technical 7.1 Comment on 1.09 and on
146 Active line 1455 spec technical 7.1 Comment on 1.09 and on
148 Active line 1500-1502 spec technical 7.3.1.2 Comment on 1.09 and on
149 Active line 1515-1517 spec technical 7.3.2 Comment on 1.09 and on
150 Active line 1524 spec technical 7.3.2 Comment on 1.09 and on
152 Active line 1535-1537 spec technical 7.3.2.3 Comment on 1.09 and on
156 Active line 1557 spec technical 7.3.2.5 Comment on 1.09 and on
158 Active line 1577 spec technical 7.3.2.7 Comment on 1.09 and on
159 Active line 1580 spec technical 7.3.2.8 Comment on 1.09 and on
165 Active line 1636 spec technical 7.4.7 Comment on 1.09 and on
166 Active line 1629-1637 spec technical 7.4.7 Comment on 1.09 and on
167 Active line 1655 spec technical 7.5.1 Comment on 1.09 and on
170 Active line 1689-1691 spec technical 7.5.3 Comment on 1.09 and on
173 Active line 1726 spec technical 7.5.5 Comment on 1.09 and on
183 Active line 1744 spec technical 7.5.6 Comment on 1.09 and on
185 Active line 1753 spec technical 7.5.6 Comment on 1.09 and on
189 Active line 1864 spec technical 8.3.3 Comment on 1.09 and on
190 Active line 1867-1872 spec technical 8.3.3 Comment on 1.09 and on
197 Active line 2010 spec technical 10.1.1 Comment on 1.09 and on
199 Active line 2536-2547 spec technical B.2.4 Comment on 1.09 and on
201 Active line 2555 spec technical B.2.5 Comment on 1.09 and on
202 Active line 2622-1624 spec technical B.3.2 Comment on 1.09 and on
215 Active line 223 spec technical 1 contradictions between Appendix A
216 Active line 224 spec technical 1 Avoid contradictions between actual
219 Active line 779-781 spec technical 3.1.1.1 Is something a URI?
220 Active line 877-880 spec technical 3.1.6.2 Timestamp element precision
224 Active line 1486-1487 spec technical 7.3.1.1 Default actor introduced but not agreed
226 Active line 1713 spec technical 7.5.4 Ack on Ack problem
40 Active line 2245(95) schema editorial Appendix A restore comment in schema
45 Active line 2374(???) schema editorial Appendix A headerExtension.grp attribute group should be derived by extension from the bodyExtension.grp
46 Active line 2397(240) & 2403(248) schema editorial Appendix A Role element is used twice but not defined in a common location
41 Active line 2281(125) schema technical Appendix A Acknowledgment/RefToMessageId element should be removed
42 Active line 2282(126) schema technical Appendix A Acknowledgment/From element is not particularly useful

Detailed List of Issues

id Spec Section Topic Class Status Raised By Owner
1 line 15/16 title page spec editorial Closed Chris Ferris
Title: title page
Description: [see email]the date cited here should be consistent with its adoption as a TC, not the date that the document was published to the TC for consideration (vote). Given that the ballot is closed as of January 18, then the date cited here cannot be less than that date.
Proposal:
Resolution: done. Date adjusted
2 line 17/18 title page spec editorial Closed Chris Ferris
Title: boilerplate
Description: [see email] either the tense is incorrect (is presented) or this should be removed. Suggest that the latter be applied. In the event that the OASIS membership does approve the TC specification as an OASIS Standard, then I could see adding something to that effect.
Proposal: make suggested change
Resolution: done.
3 line 20 title page spec editorial Active Chris Ferris
Title: title page
Description: [see email] need to update the URI reference here. Should follow w3c approach and have a stable URI that people can reference which will always have the latest draft, in addition to an explicit URI for the specific reference to a specific draft for use in external references, etc.
Proposal: make suggested change
Resolution: done. Document name inserted [[Unclear this has been done and OASIS site is about to be changed massively.]]
4 line 23 ebXML participants spec editorial Active Chris Ferris
Title: ebXML participants
Description: [see email] I agree that having this section (ebXML Participants) in addition to the one in the appendix is both gratuitous and confusing. Suggest that we have but a single list, and that that list be in an appendix, if anywhere. There is no reason to cite the participants of the original ebXML project team.
Proposal: remove section "ebXML Participants"
Resolution: Disagree. Removing v1.0 names would be inappropriate -- there is nothing wrong with having an Acknowledgements section. Moving to the end would conflict. [[Group agrees to move things to the end of the document and acknowledge those no longer participating.]]
5 line 26 ebXML participants spec editorial Closed Chris Ferris
Title: ebXML Participants
Description: [see email] If the section is preserved (see issue 4), then s/meeting/meetings/
Proposal: make suggested change
Resolution: done
6 line 200 Introduction spec editorial Active Chris Ferris
Title: typo
Description: [see email] s/sending and receiving/that sends and receives/
Proposal: make suggested change
Resolution: Disagree. It is more correct NOT to use that or which.
7 line 208 Introduction spec editorial Closed Chris Ferris
Title: typo
Description: [see email] s/,//
Proposal: make suggested change
Resolution: done.
8 line 214 Introduction spec editorial Closed Chris Ferris
Title: editorial tweak
Description: [see email] s/Elements/Features/
Proposal: make suggested change
Resolution: done. This matches with Part II header.
9 line 472 2.1 Packaging Specification spec editorial Closed Chris Ferris
Title: editorial tweak
Description: [see email] s/the following figure/figure 2.1/
Proposal: make suggested change
Resolution: done. Added figure number in text.
10 line 509 2.1.2 Message Package spec editorial Active Chris Ferris
Title: RFC2119 usage
Description: [see email] s/may/can/
Proposal: make suggested change
Resolution: Disagree. Why, does not change anything? [[Make s/may/MUST/ change to line 512 of current document.]]
11 line 709 2.3.8 version attribute spec technical Closed Chris Ferris
Title: confusion w/r/t conformance
Description: [see email] this is going to lead to all manner of confusion. For conformance to THIS specification, all of the version attributes on any SOAP extension elements defined in THIS specification MUST have a value of "2.0". An ebXML message MAY contain SOAP header extension elements that have a value other than "2.0". An implementation conforming to this specification that receives a message with ebXML SOAP extensions qualified with a version other than "2.0" MAY process the message if it recognizes the version identified and is capable of processing it. It MUST respond with an error (details TBD) if it does not recognize the identified version.
Proposal: make suggested change
Resolution: done. Change *THIS* to *this* since this is not a 2119 keyword.
12 line 724 2.3.10 NextMSH actor URI spec editorial Closed Chris Ferris
Title: editorial tweak
Description: [see email] s/The /The URI /
Proposal: make suggested change
Resolution: done.
13 line 732 2.3.11 ToPartyMSH actor URI spec editorial Closed Chris Ferris
Title: editorial tweak
Description: [see email] s/The /The URI /
Proposal: make suggested change
Resolution: done.
14 line 764 3.1.1 From and To Party elements spec editorial Closed Chris Ferris
Title: RFC2119 usage/typo
Description: [see email] s/must/MUST/
Proposal: make suggested change
Resolution: done.
15 line 784 3.1.1.2 PartyId element spec editorial Active Chris Ferris
Title: RFC2119 usage
Description: [see email] use of the term OPTIONAL here may be confusing given the conformance statement. Suggest that this be rephrased as follows: The Role element, if present, ... (technical/editorial) Other instances of OPTIONAL where ordinality is meant:

* 500 (MIME start parameter) * 1801, 1814 (Signature element in Message Status Request & Response) * 1822, 1842 (StatusRequest and StatusResponse elements; really, the service is OPTIONAL) * 1905, 1955 (Signature element in Ping & Pong)
Proposal: make suggested change
Resolution: Disagree.
16 line 788 3.1.1.2 Role element spec editorial Active Chris Ferris
Title: replacement text for Note
Description: [see email] suggested replacement text for the Note:

Note: Use of a URI for the value of the Role element is RECOMMENDED. e.g. http://rosettanet.org/roles/buyer [[Make suggested change to current line 793. Be as consistent as possible with previous recommendation for PartyID. **Related issue: BPSS document doesn't require anything stricter than a non-empty string.**]]
Proposal: make suggested change
Resolution: Disagree. What is the difference?
17 line 810 3.1.2 CPAId element spec editorial Closed Chris Ferris
Title: CPA
Description: [see email] given that we agreed in the f2f that there *was*/*is* a CPA, this sentence should be removed so as to avoid any unnecessary confusion.
Proposal: make suggested change
Resolution: done. Deleted beginning phrase.
18 line 831 3.1.3 ConversationId element spec editorial Closed Chris Ferris
Title: typo
Description: s/schema/scheme/
Proposal: make suggested change
Resolution: done.
19 line 872 3.1.6.1 MessageId element spec editorial Active Chris Ferris
Title: local part of MID?
Description: [see email] We thought that an issue had been raised that challenged the "local part" characterization.
Proposal:
Resolution: This has been adjusted several times. This should be Technical.
20 line 899 3.1.7 DuplicateElimination element spec editorial Closed Chris Ferris
Title: duplicate detection
Description: [see email] While it may be true that in order to ensure that duplicates are detected and prevented from being forwarded to the application, a persistent store is required, it is not a request by the sender that the receiver have a persistent store, it is a request by the sender that the receiver filter duplicate messages such that the application does not receive them. This section needs a better description.
Proposal:
Resolution: done. Change to *check for duplicate messages*
21 line 901 3.1.8 DuplicateElimination element spec technical Closed Chris Ferris
Title: duplicate elimination confusion
Description: [see email] This too is going to be confusing to the reader. The semantics of duplicate elimination are such that the application that is to process the received message need not concern itself that it might be processing a duplicate message. The delivery semantics of this element alone might be either at-most-once or best-effort, but in conjunction with acknowledgments, retries, etc., can effect delivery semantics of once-and-only-once.
Proposal:
Resolution: done. Changed to *duplicate messages SHOULD be eliminated* Text already says to look at the table for more info.
22 line 903 3.1.8 DuplicateElimination element spec editorial Active Chris Ferris
Title: "if there is a CPA with ..." is a little too vague
Description: [see email] "if there is a CPA with ..." is a little too vague. This is related to the issue raised recently on the list[3]. We prefer that we be a bit more specific. Suggested text:

The DuplicateElimination element MUST NOT be present if the DeliveryChannel for the message in the CPA identified by CPAId has a value of "never". The DuplicateElimination element MUST be present if the DeliveryChannel for the message in the CPA identified by CPAId has a value of "always".
Proposal: make suggested change
Resolution: Disagree. Too big of a change -- need group approval.
23 line 914 3.1.9 MessageHeader example spec editorial Active Chris Ferris
Title: example issue
Description: [see email] (example) curious that the From party has no identified Role, but the To party does. Suggest that both be assigned a role or neither.
Proposal: make suggested change
Resolution: Disagree. This clearly shows the OPTIONAL nature of the role element. It certainly would not be wrong to have both or neither but it is not clear why this would be better.
24 line 942 3.2 Manifest element spec editorial Closed Chris Ferris
Title: premature reference to xlink:role
Description: [see email] this sentence seems premature since xlink:role is an attribute of Reference element which has not yet been defined. Suggest moving this sentence to the bullet defining xlink:role below (after line #961)
Proposal: make suggested change
Resolution: done. Not sure why this is important but it doesn't hurt.
25 line 972, 1321 3.2.1.2 Description element spec technical Closed Chris Ferris
Title: Description element
Description: [see email] The Description element defined in section 3.1.8 identifies the purpose of the Description element as describing the message. The Description element here is intended to provide for a description of the payload document identified by the Reference item. The structure/syntax of the element may be the same, but the purpose is quite different.

Suggest that we reference the structure of the description element, but that we augment the definition here (and elsewhere throughout the spec) with the specific purpose of the element in the current context.

In addition, the definition of the Description element at times conflicts with the schema (esp sect. 4.2.3.2.6). The Description element MUST not be empty as it extends non-empty-string.
Proposal: make suggested change
Resolution: done -- maybe. Deleted sentence about empty element on 1325.
26 line 982 3.2.2 Manifest validation spec minor technical Not Accepted Chris Ferris
Title: suggestion to discard note
Description: [see email] Chris previously sent a note suggesting that this Note be discarded. It isn't at all clear that it adds any value. Would add to text (or note) in section 3.2.2 that the xlink:href may be a Content-Location or a Content-ID as described in section 4.1.3, lines 1084-1089. If the ds:Reference element may have a URI of this type and that URI must match the xlink:href of some "corresponding" eb:Reference element, options must be similar.
Proposal: make suggested change
Resolution: Disagree. This came up and the group agreed to this note.
27 line 1029 4.1.2.1 Collaboration Protocol Agreement spec editorial Closed Chris Ferris
Title: RFC2119 usage
Description: [see email] s/may be/is/
Proposal: make suggested change
Resolution: done.
28 line 1037 4.1.3 Signature Generation spec editorial Closed Chris Ferris
Title: typo
Description: [see email] s/and //
Proposal: make suggested change
Resolution: done. Not sure this makes any difference.
29 line 1050 4.1.3 Signature Generation spec editorial Closed Chris Ferris
Title: editorial tweak
Description: s/for the ebXML Message Service//
Proposal: make suggested change
Resolution: done.
30 line 1434 7 Reliable Messaging Module spec technical Closed Chris Ferris
Title: RFC2119 MUST semantics for DFN
Description: [see email] This was supposed to have been changed to MUST. [[Sentence is a complete mess. Incredibly passive, describes a contract between the application and the MSH, not externally verifiable.]]
Proposal: make suggested change
Resolution: done. [[Group resolves to rewrite to use active voice and get things closer to intent. Dale has suggested text. **Do not do this as a wholesale 2.1 (or separate Errata for 2.0) driver -- removing passive voice entirely must be postponed until 3.0.**]]
31 line 1436 7 Reliable Messaging Module spec editorial Active Chris Ferris
Title: duplicate elimination characterization
Description: [see email] The method of duplicate elimination is not achieved via a persistent store, but is facilitated by same. The mechanism by which duplicates are detected and eliminated is via the MessageId. This is likely to become a source of confusion.
Proposal:
Resolution: Disagree. Duplicate detection IS accomplished through the use of a persistent store. MessageID is what is put in the message store. This sentence is the introduction to the next section and if this change is done then a new transitional sentence, containing persistent store, will have to be inserted.

There is nothing wrong with the sentence as it stands. This change does not improve the document.
32 line 1449 7.1 Persistent Storage... spec technical Closed Chris Ferris
Title: RFC2119 usage
Description: [see email] s/SHOULD/MUST/
Proposal: make suggested change
Resolution: done.
33 line 1459 7.2 Methods ... spec editorial Active Chris Ferris
Title: editorial tweak
Description: [see email] s/structures/extension modules/
Proposal: make suggested change
Resolution: Disagree. How does this improve the spec?
34 line 1512 7.3.1.4 AckRequested spec technical Deferred Chris Ferris
Title: error on ack and ack on error issue
Description: [see email] We agreed that an error message could be sent reliably. You are only precluded from requesting an acknowledgment on a message that itself is an acknowledgment message.
Proposal: make suggested change
Resolution: Disagree. More members on the list feel differently. Need vote.
35 line 1564 7.3.2.5 [XMLDSIG] Reference spec editorial Active Chris Ferris
Title: typo
Description: [see email] s/This/The/
Proposal: make suggested change
Resolution: Disagree. Why?
36 line 1580 7.3.2.8 Acknowledgment... spec technical Deferred Chris Ferris
Title: error on ack
Description: [see email] We did NOT agree to this at all. We agreed that an Error message *could* be sent reliably. Ref email for discussion.
Proposal: apply original TC resolution
Resolution: Disagree. See issue 34.
37 line 1809 8.1.2 MessageStatus... spec technical Closed Chris Ferris
Title: incorrect URI
Description: [see email] URI s/b urn:oasis:names:tc:ebxml-msg:service
Proposal: make suggested change
Resolution: done.
38 line 2054... 11 Multihop... spec editorial Active Chris Ferris
Title: duplicate content with 11.1.4
Description: [see email] this is essentially duplicate of the content of section 11.1.4, suggest it be deleted.
Proposal: make suggested change
Resolution: Disagree.
39 line 2791... Non-Normative References spec editorial Closed Chris Ferris
Title: references to ebXML specs
Description: [see email] references to ebXML specs should be qualified by their URI, and as previously cited, the ebRS reference should probably cite the 2.0 version of their spec(s).
Proposal: make suggested change
Resolution: done.
40 line 2245(95) Appendix A schema editorial Active Chris Ferris
Title: restore comment in schema
Description: [see email] Comment from last draft-msg-header-05.xsd had a useful annotation mentioning the soap:actor element in SyncReply MUST have the value http://schemas.xmlsoap.org/soap/actor/next Suggest restoring that inline documentation.
Proposal: restore comment
Resolution: Disagree. For some reason, this annotation is causing parser errors among the implementors. Not sure why. Since this is only a comment, leave it out. [[Try out in a few of today's tools, include if no current tool results in parser errors. Resolve any issues if possible. ACTION: doug]]
41 line 2281(125) Appendix A schema technical Active Chris Ferris
Title: Acknowledgment/RefToMessageId element should be removed
Description: [see email] Doug raised an issue[1] that the Acknowledgment/RefToMessageId element should be removed. It remains in the document and the schema but should be removed. An Acknowledgment element should be included if and only if the overall message refers to the original one of interest.
Proposal:
Resolution: Disagree. We voted for clarifications only, this is a functional change. Discussion: Since an Acknowledgment may be put on any returning document, the RefToMessageID in the MessageHeader may not be the same as in the Acknowledgment. This also allows for *bundling* Acknowledgments -- which might be useful in a high-volume, SMTP instance. All this probably won't happen, but unless we want to mandate that an Acknowledgment must be stand-alone, this element is necessary. [[The piggybacking issue. Group has agreed Acknowledgment/RefToMessageId has been deprecated and will be removed in a future version of the specification. Errata will require two RefToMessageId values MUST be identical in the current version.]]
42 line 2282(126) Appendix A schema technical Active Chris Ferris
Title: Acknowledgment/From element is not particularly useful
Description: [see email] Doug believes he mentioned this before w.r.t. the document. The Acknowledgment/From element is not particularly useful because it provides the Receiving MSH no actionable information. Since the current hop-to-hop text doesn't require messages to follow the same routes inbound and outbound, an AckRequested/From element might be useful -- letting the receiver know where to send the Acknowledgment in cases where it must be sent separately. Probably would be better to remove Acknowledgment/From since it covers only 1 of the 4 values hop-to-hop implementations might want to log. Other alternative is From and To in both AckRequested and Acknowledgment.
Proposal: remove Acknowledment/From element
Resolution: Disagree. Same reasoning as issue 41. To might be useful in Acknowledgment but that would be a functional change. [[Recommend element NOT be used. Deprecate the feature. Only addresses part of the information that may be interesting to log for intermediate acknowledgements. **Larger issue for 3.0: In light of market demand and vendor implementation, may wish to back away from intermediate acknowledgements.**]]
43 line 2304(148) Appendix A schema technical Closed Chris Ferris
Title: Description element here doesn't match the document
Description: [see email] Description element here doesn't match the document. We'd much prefer leaving the schema as is and correcting the document's poor description of this element and an "empty content" case. None of the other Description element occurrences in the text go so far away from standard practice as section 4.2.3.2.6. (Probably not good to mention w.r.t. schema at all.)
Proposal:
Resolution: Don't understand the problem -- looks fine. Removed comment in 4.2.3.2.6 about may be empty. See issue 25. This may already be resolved [[Mostly resolved, current text and schema are aligned. **Deferred issue for 3.0: Should make this use of Description element identical to that in the rest of the schema, allowing it to repeat (and using identical referencing text in the document).**]]
44 line 2282(126) Appendix A schema major technical Closed Chris Ferris
Title: sequenceNumber.type is poorly defined
Description: [see email] sequenceNumber.type is poorly defined. The base type for the element content must be nonNegativeInteger (not positiveInteger) to allow the oft-mentioned "0" value. Even better, should define a type derived from nonNegativeInteger with a [[nuke maxExclusive since it's a valid value]] maxInclusive="99999999" attribute and use that here (guess the attribute can be added in the element def'n as well). Going even one step better to avoid leading zeroes and the plus sign (as uselessly required by the documentation), could use pattern="0|([1-9][0-9]{0,7})", making the min and max values redundant.
Proposal: change base type of sequenceNumber.type to nonNegativeInteger
Resolution: done. Just the proposal, not the pattern. [[Went a bit further and added the maxInclusive. **Two issues for 3.0: Improve use of XML Schema in the next version of the specification. Add Glen's issue about identifying the last message in a conversation.
45 line 2374(???) Appendix A schema editorial Active Chris Ferris
Title: headerExtension.grp attribute group should be derived by extension from the bodyExtension.grp
Description: [see email] Why isn't the headerExtension.grp attribute group derived by extension from the bodyExtension.grp? That would be a bit more clear.
Proposal:
Resolution: Disagree. This is a nice-to-have. Not a bad suggestion, but this does not clarify or fix anything. [[Roll it in with other schema changes. Does not affect validity. Housekeeping.]]
46 line 2397(240) & 2403(248) Appendix A schema editorial Active Chris Ferris
Title: Role element is used twice but not defined in a common location
Description: [see email] Role element is used twice but not defined in a common location. Suggest defining Role at the top level and referring to that definition here. These are the only times <element> appears in the schema with a type attribute but not at the top level (not defining a global element). [[Roll it in with other schema changes. Does not affect validity. Housekeeping.]]
Proposal:
Resolution: Disagree. Nice-To-Have. Does not clarify or fix anything.
47 none Appendix A schema technical Defer to v3.0 Chris Ferris
Title: Schema element should have an optional "namespace" attribute
Description: [see email] It was proposed in this email that the Schema element have an optional "namespace" attribute. This was raised as a technical issue but not addressed.
Proposal:
Resolution: Disagree. This is a functional change. Not clear if this would be good or not but team voted for *clarifications*. [[ACTION: Doug will go back and look at original email. Seems the schema element has every attribute it could, including targetNamespace.]]
48 line 2169(???) Appendix A schema technical Closed Chris Ferris
Title: Import correct / latest schema for XML namespace
Description: [see email] should reference http://www.w3.org/2001/03/xml.xsd in the import statement instead of the "hacked" version currently cited.
Proposal: 2169 should reference http://www.w3.org/2001/03/xml.xsd in the import statement instead of the "hacked" version currently cited.
Resolution: done.
49 line 193 1 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Wording improvement
Proposal: s/format type/format or type/
Resolution: Disagree. Not sure what this adds? Not sure it is correct? [[Resolved: s/format type/type/ (delete "format") on current line 195.]]
50 line 208 1.1.1 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Clarification
Proposal: s/ebXML SOAP/Basic ebXML SOAP/
Resolution: Disagree. What is Basic ebXML SOAP? We have not defined anything called Basic ebXML anywhere in the spec.
51 line 211 1.1.1 spec editorial Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Correct reference
Proposal: s/section 4.1.5/section 4.2/
Resolution: done.
52 line 219 1.1.1 spec editorial Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Correct reference
Proposal: s/section 8/sections 8 and 9/
Resolution: done
53 line 221 1.1.1 spec editorial Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Correct reference, note replacement of trailing comma with period.
Proposal: s/(section 10.12),/(section 11)./
Resolution: done
54 line 262 1.1.4 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Wording improvement, hard to read implications.
Proposal: s/and understand//
Resolution: Disagree. Why?
55 line 263 1.1.4 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Wording improvement
Proposal: s/its implications/understand its implications/
Resolution: Disagree. Why? This is tied to issue 54.
56 line 263 1.1.4 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] MINOR TECHNICAL: Section needs words covering inconsistencies between specification text and our schema. I believe we decided the schema "wins" but that isn't reflected here without this added paragraph.
Proposal: a

The XML Schema definition for the ebXML SOAP extensions may conflict with the material in the body of this specification. [[When such a conflict is more than an added restriction in one document or the other]], the schema supersedes the specification [[until such time as the ebXML Messaging TC or its successor resolves the conflict]].
Resolution: Disagree. Actually, this is the opposite of correct. The schema should be non-normative and the spec should be correct. Code is always wrong if it conflicts with the words. [[General agreement separate schema document is "more normative" than Appendix A. General agreement the issues here don't touch (shouldn't touch) on how a conflict is resolved in a later version of the specification or the Errata document. Problem limited to explicit conflicts between schema and document, not the cases where one says something and other says nothing. Still undecided on schema versus text for these cases. Resolved to add this updated wording as a new proposal after line 264.]]
57 line 282 1.2.1 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Remove unecessary words that could cloud the picture.
Proposal: s/security and reliability//
Resolution: Disagree. Why? Looks fine as is.
58 line 287 1.2.1 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Avoid using ebMS to mean two different things (document and implementation of the specification).
Proposal: s/the ebMS/this document/
Resolution: Disagree. Not clear how this makes things better. [[Need separate names for the specification ([ebMS] - the physical document, Message Service Specification, this document), the abstract service offered (Message Service), a specific implementation of this service (MSH). Editor (Matt or Colleen) will take a pass through the document. We'll decide whether to do this in 2.1 or 3.0 when we see the number of changes. Likely intermediate resolution: Leave name for service alone but fix up references to the current document. ACTION: Matt or Colleen]]
59 line 361 1.2.3 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Avoid using ebMS to mean two different things.
Proposal: s/the ebMS MAY/this document may/
Resolution: Disagree, see issue 58. [[see 58 for updated resolution]]
60 line 373 1.2.3 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Make more specific.
Proposal: s/The CPA is/In [ebCPP], the CPA is/
Resolution: Disagree. Nice-To-Have.
61 line 377 1.2.3 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Minor editorial
Proposal: s/operations/operation/
Resolution: Disagree. Looks fine as is?
62 line 423 1.2.4 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] This and other changes attempt to align the figure with the preceding list.
Proposal: a

Delivery Module -- an abstract service interface an MSH uses to interact with the communication protocol layers when sending and receiving messages.
Resolution: Disagree. No changes to picture or text. TC has been through this exhastively and this is the product of our discussions. [[For figure 1.1 and surrounding text, general agreement to do changes to diagram / text for alignment as a 2.x.y issue. For this particular issue, use term "binding" rather than "delivery module". ACTION: Doug will contact Ralph to see if he still has source to diagram 1.1. **Note larger 3.0 issue about creating a better introduction to the concepts for new users.**]]
63 Figure 2.1 1.2.4 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Align figure with associated list
Proposal: s/Authentication, Authorization and Non-Repudiation services/Security Services (authentication, authorization and non-repudiation)/
Resolution: Disagree. See item 62. [[See updated resolution in 62]]
64 Figure 2.1 1.2.4 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Align figure with associated list
Proposal: s/Header Processing/Header Processing and Parsing/
Resolution: Disagree. See item 62. [[See updated resolution in 62]]
65 Figure 2.1 1.2.4 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Align figure with associated list
Proposal: s|Encryption and / or Digital Signatures|Security Services (encryption and / or digital signatures)|
Resolution: Disagree. See item 62. [[See updated resolution in 62]]
66 Figure 2.1 1.2.4 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Align figure with associated list
Proposal: s|Send/Receive Transport mapping and binding|(Send/Receive Transport mapping and binding)|
Resolution: Disagree. See item 62. [[See updated resolution in 62]]
67 Figure 2.1 1.2.4 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Align figure with associated list
Proposal: s|Send/Receive Transport mapping and binding|(Send/Receive Transport mapping and binding)|
Resolution: Disagree. See item 62. [[See updated resolution in 62]]
68 Figure 2.1 1.2.4 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Align figure with associated list
Proposal: Add Reliable Messaging box between "Message Packaging" and "Delivery Module" because message is packed once but (optionally) sent multiple times).
Resolution: Disagree. See item 62. [[See updated resolution in 62]]
69 line 462 2.1 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Minor editorial
Proposal: s/logical MIME parts/types of MIME parts/
Resolution: Disagree. *Logical* is the right word not *types*.
70 line 508 2.1.2 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Clarification
Proposal: s|non-multipart messages, which may occur|receipt of a SOAP message not packaged within a MIME multipart/related container. This packaging option is defined in the SOAP 1.1 [SOAP] specification. Senders MAY use this packaging|
Resolution: Disagree. Lots of words which don't add anything.
71 line 592 2.2.1 spec editorial Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Very confusing as it stands. We don't need to tell people what the XML Recommendation actually requires.
Proposal: s/: version='1.0'//
Resolution: done. This problem is caused because Chris had us delete the example and it still says *described below*. Changed to *described above*. Not sure what else to say. This seems so simple that perhaps we should not have this section.
72 line 609 2.3 spec editorial Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Minor editorial
Proposal: s/attribute/attributes/
Resolution: done.
73 line 631 2.3.2 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Text is necessary to avoid this URI appearing only in non-normative examples.
Proposal: a

This schema is available at http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd and SHOULD be referenced in a schemaLocation attribute in the SOAP Envelope element.
Resolution: Disagree. This is included in all the examples but why do we include it at all? Why don't we use the NS http://schemas.xmlsoap.org/soap/envelope/? We did this at first because some implementations were having problems getting to this URL but that seems to be no longer the case.
74 line 699 2.3.6 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Spills into a TECHNICAL issue: Our intentions should lean towards addition of new SOAP extensions rather than extending the ones we've defined when adding entirely new features.

Don't include first paragraph if we decide to re-insert foreign attributes anywhere.
Proposal: a

This extension mechanism is an exclusive choice. None of the elements defined in this specification support foreign namespace-qualified attributes. The wildcard elements are provided wherever extensions might be required for private extensions or future expansions to the protocol.

Note: Extension elements should be included in ebXML SOAP extensions only when they expand the semantics of that particular element. This mechanism might be used, for example, to extend the eb:Error element by providing additional structured information about a problem. Wholly new features should be implemented using separate SOAP extensions.
Resolution: Disagree. Where did we decided to *lean* toward new SOAP extensions? When did we decide we could not extend existing elements? This is not a true statement. Foreign extensions are allowed on ALL elements. We used to support foreign attributes on all top-level elements??? Not sure when this was removed??? Not sure there was a vote on this??? What happened??? Replaced anyAttribute on headerExtensions.grp and bodyExtensions.grp. Not sure allowing foreign attributes is better, but we should at least discuss before making a technical change. [[Generally agree 2.3.6 needs fixing. Generally agree new features should be RECOMMENDED to go elsewhere. ACTION: Update issue to cover exiting anyAttribute option, title of section. ** Purely editorial issue, remove "implementation of the" from line 699, last line of 2.3.6.**]]
75 line 717-722 2.3.9 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Defines SOAP, which shouldn't be necessary in our specification.
Proposal: delete these lines

OR [much prefer previous option but at least following change would define SOAP properly.]

718 s/REQUIRED SOAP mustUnderstand attribute on SOAP Header extensions/SOAP mustUnderstand attribute/
Resolution: Disagree. What does it mean if we don't REQUIRE mustUnderstand? All elements already state that mustUnderstand has a value of 1 so this is OK. This is part of issue 76. This change would be OK but not the next change. Since these go together, don't do either. Throughout the document we use this same sentence structure. This one should not be different. [[Go with second resolution.]]
76 line 722 2.3.9 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Now, describe our requirements over and above SOAP.
Proposal: a

For all ebXML SOAP Header extensions defined in this specification, the SOAP mustUnderstand attribute is REQUIRED and MUST have the value '1'. A compliant MSH MUST parse (but not necessarily support features associated with) all elements and attributes defined in this document.
Resolution: Disagree. How does this make things better than before? This changes nothing and adds nothing. Only do changes which mean something. [[Add this to the end of the section. Look at moving final proposed sentence into "1.3 Minimal Requirements for Conformance."]]
77 line 722 2.3.10 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Defining a new section introducing the soap:actor attribute with the existing 2.3.10 and 2.3.11 becoming 2.3.10.1 and 2.3.10.2 (subsections). This section does not redefine the SOAP actor attribute (unlike lines 717-722 I'd recommend we delete).
Proposal: a

2.3.10 SOAP actor attribute

All ebXML SOAP Header extensions defined in this specification that may be handled by an MSH node other than the ultimate recipient of a message allow inclusion of the SOAP actor attribute. If present, this attribute SHALL have one of the values defined in the following two subsections or the SOAP-defined value http://schemas.xmlsoap.org/soap/actor/next.
Resolution: Disagree. This is a functionality change by requiring that the SOAP actor be present. We have never required the actor and we specifically allowed a default so this actor would not appear except for multi-hop. Since these actors are only used for multi-hop, why are they even here? [[Agreed]]
78 line 722 2.3.11 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments]TECHNICAL issue: Current text leaves reader asking "What is the semantic difference between toPartyMSH and the default SOAP actor? When would a sending MSH specify toPartyMSH rather than leaving the soap:actor attribute out?" This is not clear in this document and if I need to check the archives for the reasoning we're leaving something important out.

I've been told the actor described in existing section 2.3.11 will support an intermediate node acting on behalf of the To Party in returning an Acknowledgment (prior to the ultimate recipient seeing the message). That's a great use case, handling (for example) trusted store and forward MSH implementations in the destination's DMZ. If that's the case, we need to be clear this actor value is specifically for use in the AckRequested and Acknowledgment elements. I don't think it's useful elsewhere.
Proposal: Changing the last sentence suggested in issue 77 to read "If present in the AckRequested or Acknowledgment elements (see sections 7.3.1 and 7.3.2), this attribute SHALL have one of the values defined in the following two subsections." would work since the other use of soap:actor (in eb:SyncReply) is very explicit about allowed values.

This might remain insufficient to make the intent of this actor clear to people outside our group.
Resolution: Disagree. Agree with the problem statement - What is the difference between ToPartyMSH and the default SOAP actor? Resolution would be to remove this actor and use the default SOAP actor. This is never used in the spec and it is the default thus substantively replacing the SOAP default (Not Good). To require the actor would be a functionality change. [[Propose deprecation or removal of the potential value because (according to section 6.3.1.1) there is no semantic difference between this value and the default SOAP actor.]]
79 line 729 2.3.10 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Clarify actions allows of soap:next actor.
Proposal: a Such an actor MAY ignore SOAP Header extensions targeted to "urn:oasis:names:tc:ebxml-msg:actor:nextMSH" but not the "http://schemas.xmlsoap.org/soap/actor/next" actor (which all SOAP nodes, including an ebXML MSH, MUST adopt).
Resolution: Disagree. This won't work. Intermediate, non-ebXML SOAP nodes MUST NOT participate or XMLDsig will fail. How would a non-MSH intermediary know how to handle the ebXML headers? An Intermediary which does understand and process ebXML headers would, by definition, be an ebXML MSH. It is not yet even clear that intermediate ebXML compliant nodes will work. Why are we worrying about non-ebXML nodes? [[Not adding any requirements on generic SOAP nodes as described in SOAP 1.1. Is this addition necessary? Close issue, no change made. **Note a SOAP 1.1 issue: No requirement for forwarding headers not consumed without change. Only rules for what you may remove. Doesn't even say you MUST forward the body untouched. ACTION: Group to check with their SOAP geeks about default rule for forwarding unconsumed header extensions (for 1.1 and 1.2).**]]
80 line 732 2.3.11 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Remove wordiness
Proposal: s/when used in the context of the//
Resolution: Disagree. Why? Same as previous section. We agreed to put off multi-hop until next version so there is no reason to worry about these sections since they are not actually used.
81 line 812-818 3.1.2 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Paragraphs mixed oddly.
Proposal: split into 2 paragraphs one sentence later
Resolution: Disagree. Tried to make change but didn't look right. Better as is.
82 line 812,813 3.1.2 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL: This discussion (including following two issues as well) did not reflect the decision to REQUIRE an error when a message / CPA consistency problem is detected.
Proposal: s/the appropriate handling of the conflict is undefined by this specification/the conflict MUST be reported to the Sending MSH/ [[Replace text with "MUST implement this feature. Deployments..."]]
Resolution: none [[Remember, we resolved to add perMessage and detect / report all conflicts in previous discussions. Refine the proposed text above slightly to make it a SHOULD, STRONGLY RECOMMENDED at least for test deployments. Now at lines 817-819. Also remove second sentence in this paragraph. Do we want to in addition say the validation MUST be implemented? Sure, that seems like the way to go. REQUIRE MSH to have detection facility and deployments SHOULD perform this conflict detection. Has anyone implemented message validation against CPA? Yes, most implementations are pretty anal. ACTION: Dale will reword 817-819 to describe MSH requirements in this area (MUST for implementation, SHOULD for deployment).]]
83 line 815 3.1.2 spec technical Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Wordiness and options not available according to our decisions.
Proposal: s/If a receiver chooses to generate an error as a result of a detected inconsistency,/If a Receiving MSH detects an inconsistency,/
Resolution: done.
84 line 816,817 3.1.2 spec technical Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] This error shouldn't be optional either.
Proposal: s/If it chooses to generate an error because the CPAId/If the CPAId/
Resolution: done.
85 line 831 3.1.3 spec editorial Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Already mentioned (again) in Chris' message.
Proposal: s/schema/scheme/
Resolution: done.
86 line 838-840 3.1.4 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] This discussion just confuses the issue because of its use of the word "role" without reference to the Role element. If there is a specific element in the CPA or BPSS documents that could be referenced here, fine. Otherwise don't mention it.
Proposal: d
Resolution: Disagree. What should be done here? This note was put in to try and clear up some confusion. Taking it out would add to the confusion, not limit it. [[Don't delete, appropriate words for alignment with BPSS. Could add wording for import from CPA document? Service and Action aren't really in BPSS. ACTION: Dale will propose reference to appendix of CPA specification when an actual CPA instance is used.]]
87 line 850-851 3.1.4.1 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL: It's not possible (or worthwhile) to determine whether or not something is a URI except by checking for a colon. Note as well: Unlike PartyId@type, we don't RECOMMEND that this attribute be a URI.
Proposal: Remove second sentence.
Resolution: Disagree. Agree that second sentence does not help much - neither does it hurt. No change. [[No strong RECOMMENDATION that Service be a URI. If it doesn't have a type, Service MUST be a URI? "It" pronoun in second sentence not resolved correctly. Multiple issues, (a) inconsistent with PartyId@type (not required to be a URI value), (b) MUST versus RECOMMENDED for URI in Service (don't recommend leaving type attribute out) (c) "It" reference incorrect. (d) 4.1.5 reference is incorrect. (e) 4.1.5 reference in 3.1.1.1 also incorrect. Resolution is to editorially fix (c) through (e). **Matt may propose relaxing URI requirent for Service element without a type.**]]
88 line 850 3.1.4.1 spec technical Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL issue: How are unrecognised services (those not mentioned in the BPSS referenced from the CPA for example) handled? Need to define error handling for that case.
Proposal: Add such an error and describe it in this section. Or, just use one of the existing errors.
Resolution: done. Added sentence above 3.1.6.
89 line 872-873 3.1.6.1 spec editorial Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] As Chris has mentioned, the second sentence of this paragraph should be removed. I mentioned earlier that RFC2822 mentions the local part of email addresses but doesn't distinguish between the left and right sides of a message id except with respect to possible generation rules. It never mentions "local part" when describing message id values.
Proposal: Remove second sentence.
Resolution: done. Not sure this was necessary.
90 line 885 3.1.6.3 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Add reference.
Proposal: s/messages,/messages (see section 4.2),/
Resolution: Disagree. Issue below (91) corrects this.
91 line 886 3.1.6.3 spec editorial Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Correct reference.
Proposal: s/section 4.1.5/section 4.2.1.1/
Resolution: done.
92 line 887-896 3.1.6.4 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL issue: Should describe clock synchronization between MSH nodes. Is it required? Does it not matter because the durations expected are large values?
Proposal: I would prefer explicit mention of synchronization or clock accuracy as a deployment issue rather than ignoring the issue entirely. This is the only place in our specification where time values must be compared.
Resolution: Disagree. The team specifically removed mshTimeAccuracy and decided to ignore this issue. [[Took earlier words about clock accuracy out. Add note to recommend use of NTP to make their clocks more accurate and therefore better synchronized. ACTION: Pete will propose a Note.]]
93 line 916,921,924,926 3.1.9 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] replace "someType" and similar labels with example values, this is an example
Proposal: change to avoid labeling the value
Resolution: Disagree. This doesn't matter. Why would a real type be more correct?
94 line 926 3.1.9 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Ignore comment about this line in issue 93 if you can perform this deletion. From the service and action values, this is a new order -- what message is referenced?
Proposal: d
Resolution: Disagree. There could be a previous quote message which is referenced. Why is this an issue? [[Is this a reference to a quote? Probably more clear to remove RefToMessageId element. Resolved to remove RefToMessageId element at line 934.]]
95 line 949 3.2.1 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Was a correction to previous reference to 2.3.6 material:

965 s/any namespace-qualified element content belonging to a foreign namespace// [References to 2.3.6 should be consistent in these lists.]
Proposal: a

#wildcard (see section 2.3.6 for details)
Resolution: Disagree. We fixed the schema to allow for #wildcard elements on all top-level elements but we made an editorial decision NOT to add this all the way through the spec and we say this in 2.3.6.
96 line 969 3.2.1.1 spec technical Deferred Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL issue: For schema references, should allow a "namespace" attribute. The location attribute in that case would be a preferred schemaLocation for the described schema. This would also require a small addition to the ebXML Messaging schema.
Proposal: a

namespace -- If present, identifies the target namespace of the schema document found at the above location.
Resolution: Disagree. Adding an attribute would be a functional change. [[Defer to 3.0]]
97 line 979-981 3.2.2 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL issue: Error requirements here are overly restrictive. The problem might be a security failure accessing content elsewhere on the Internet, for example.
Proposal: Suggest adding something to the effect of "When no other defined error applies...".
Resolution: Disagree. Already says this is implementation decision. [[Not necessarily a MIME problem (for external information). May want to change error to ManifestError in the future. Leave alone for now, defer adding ManifestError to 3.0 (if we remember).]]
98 line 1009 4.1 spec editorial Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Keep things together
Proposal: Move last sentence to end of line 1006 (the previous paragraph)
Resolution: done.
99 line 1035 4.1.2.1 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Common sentence structure in bullets, explain this case.
Proposal: s/payload./payload(s). The MSH takes and active part in providing these security measures, as part of its generation of the SOAP message and through the parameters it passes to the underlying communication protocol./
Resolution: Disagree. Don't understand. What parameters are passed to the underlying communication protocol? Not clear that any security parameters are passed?
100 line 1099 4.1.3 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Current xsi:schemaLocation doesn't include the namespace identifier for our schema, resulting in illegal syntax. recommendations.
Proposal: a

http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd

[Or, even better, the second tuple in this attribute value (after this addition) should be moved to separate xsi:schemaLocation attributes on the soap:Header and soap:Body elements. Otherwise, we conflict with our own "one namespace per such attribute".]
Resolution: Don't understand the problem? This looks fine? The xsi:schemaLocation is optional anyway.
101 line 1146-1150 4.1.4.1 spec editorial Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Introduce things before use.
Proposal: Move before line 1143, making this the first paragraph and allows it to introduce use of XML Signature.
Resolution: done.
102 line 1154-1157 4.1.4.2 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL issue: This text disallows a receiving MSH returning a message saying "party B definitely received the message with id XYZ". Since that party likely has the message stored with party A's signatures, having to say "party B received the message with id XYZ and these contents" seems a burden only some relationships will require. It also stretches the previous definition of a signed message to mean just the inclusion of a Signature element in the soap:Header.
Proposal: Inclusion of ds:Reference elements should be an option even for signed acknowledgments.
Resolution: Disagree. This has been discussed many times. A signed Acknowledgment is meaningless without the resulting hash/digest. This is not a resource problem since this ds:Reference will be identical to the element in the original signed message. Once the original signature is verified, the original element can simply be copied.
103 line 1154-1157 4.1.4.2 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL issue: Unlike the Manifest element we're defining, the dsig:Signature element is not required to reference every payload in a message. (Line 1084, correctly, says "requiring signing".) The copying described here is likely insufficient for the "and these contents" claim you want.
Proposal: Make it more clear any included Reference elements should be generated over the portions of a message the sender chooses to acknowledge.
Resolution: Disagree. Already know what elements signed by looking at original ds:Signature element. This would only be an issue if the Acknowledgment was signed but the original was not. We discussed this and decided that in this unusual case, the entire message would be used to create the ds:Reference element in the Acknowledgment.
104 line 1160 4.1.4.3 spec editorial Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Minor editorial
Proposal: s/,//
Resolution: done.
105 line 1166 4.1.4.4 spec editorial Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] CRC is one technology to do what is necessary here, generalise.
Proposal: s/integrity check CRCs of/digests and comparisons of/
Resolution: done. Not sure what this adds or corrects.
106 line 1169 4.1.4.5 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Minor editorial
Proposal: s/document(s)/document/
Resolution: Disagree. Why? This looks OK.
107 line 1068-1078 4.1.4.5 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL issue: It's not clear how XML Encryption will address this problem except for payloads expressed as XML documents.
Proposal: If this will work, describe it. Otherwise, reference a future solution in later versions of ebXML-MSH or another (presently known) solution.
Resolution: Disagree. Agree with the problem description. The first paragraph of 4.1.4.5 is certainly NOT TRUE. It is not clear that XML Encryption will work at all. No change because it is not clear what to do.
108 line 1251,1254 4.2 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] should not pluralize the name of an element even if only part is bold.
Proposal: s/Faults/Fault messages/
Resolution: none
109 line 1257 4.2 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] The section 4.2.1 is missing -- we skip from 4.2 Error Handling Module to 4.2.1.1 Definitions.
Proposal: We should at least have an intermediate heading or (probably easier) make 4.2.1.1 be 4.2.1.
Resolution: Disagree. This is a problem with MSword. There does not seem to be any way to reference a level 4 header directly after a level 2 header. This should be 4.2.0.1 but that does not seem to be possible.
110 line 1279 4.2.3 spec technical Defer Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL issue: I had a suggestion in this section to add an actor attribute to the ErrorList element. Even though intermediates may never hear about errors and DFN messages may take other routes back to the originator, the problem is likely reduced by the lack of duplicate elimination at intermediaries. I'd support adding this attribute in support of store-and-forward intermediaries performing retries to later destinations if someone proposes it again. I'm simply removing (but logging for later use) my suggestion because it didn't get any notice last time and might induce feature creep.
Proposal: No change at this time, defer to later version.
Resolution: Disagree. While it might be possible for a reply to take another path back (although doubtful) an Error to the previous hop MUST take the same path. This is a functional change. Defer.
111 line 1281 4.2.3 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Wildcard descriptions.
Proposal: a

#wildcard (see section 2.3.6 for details)
Resolution: Disagree. We fixed the schema to allow for #wildcard elements on all top-level elements but we made an editorial decision NOT to add this all the way through the spec and we say this in 2.3.6.
112 line 1282 4.2.3 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Reduce wordiness
Proposal: s/reported then/reported,/
Resolution: Disagree. Either way is right, looks better the way it is.
113 line 1284 4.2.3.1 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Minor editorial
Proposal: s/of any of the Error elements/of the grouped Error elements/
Resolution: Disagree. This change does not add anything.
114 line 1285 4.2.3.1 spec editorial Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Correct punctuation
Proposal: s/, otherwise/; otherwise,/
Resolution: done.
115 line 1294 4.2.3.2 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Wildcard descriptions
Proposal: a

#wildcard (see section 2.3.6 for details)
Resolution: Disagree. We fixed the schema to allow for #wildcard elements on all top-level elements but we made an editorial decision NOT to add this all the way through the spec and we say this in 2.3.6.
116 line 1295 4.2.3.2 spec technical Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL: As Chris mentioned, the Description element MUST have content if present.
Proposal: s/The content of the Description element MAY contain error message text.//
Resolution: done.
117 line 1301 4.2.3.2.2 spec editorial Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Should not pluralize our element names.
Proposal: s/errorCodes/errorCode attribute values/ s/then//
Resolution: done.
118 line 1303 4.2.3.2.2 spec editorial Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Should not pluralise our element names.
Proposal: s/errorCodes/errorCode value(s)/
Resolution: done
119 line 1302-1304 4.2.3.2.2 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL issue: Our list of codes is comprehensive due to its inclusion of OtherXML and Unknown. How can "legal" additions to the list of error codes be created without violating these restrictions?
Proposal: Specifically mention the errors OtherXML and Unknown as exceptions to this requirement.
Resolution: Disagree. This has come up before and the team decided to leave this as is.
120 line 1311 4.2.3.2.4 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Current text could be interpreted to mean one Error in a list with Warning severity means the message was processed. Remove that unintended implication.
Proposal: s/problem./problem. (Other Error elements in the list may describe problems preventing further processing.)/
Resolution: none
121 line 1312 4.2.3.2.4 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Minor editorial
Proposal: s/there is/there was/
Resolution: Disagree. Why? Either way would be correct.
122 line 1315 4.2.3.2.5 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL issue: Need some text requiring the value of this attribute be a URL. Otherwise the later discussion doesn't make that much sense.
Proposal: a The value of this attribute MUST be a URL.
Resolution: Disagree. Is this true? Would an XPointer be a URI? Is this always the case?
123 line 1319-1320 4.2.3.2.5 spec editorial Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Don't redefine something well-described in another specification.
Proposal: s/in the format cid:23912480wsr, where the text after the ":" is the value of the MIME part's content-id/using URI scheme "cid"/
Resolution: done.
124 line 1318-1320 4.2.3.2.5 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] A previous TECHNICAL issue about these lines has been partially resolved through limiting section 2.1.6 to REQUIRING a SOAP Fault only in the outermost Message Package. Nonetheless, the ebXML handler is unlikely to be invoked when the payload containers or other MIME packaging is incorrect.
Proposal: Refer to 2.1.6, saying that errors with locations of this type may be unlikely (depending upon the SOAP implementation in use).
Resolution: none
125 line 1352 4.2.4.1 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Make it more clear only an Acknowledgment ends retries. Of course, Acknowledgment and ErrorList may appear in the same message.
Proposal: a With the possible exception of retries to the message in error, additional messages in the conversation MUST NOT be sent after receiving any message containing such an ErrorList.
Resolution: Disagree. This creates a new requirement. Although ConversationID is in the header, we do not use it for anything (at least not in the core). This would make a new requirement for monitoring ConversationID. Comment is not wrong, though. Needs more thought. It is not true that only Acknowledgment ends retries, might also be ended by ErrorList or if Retries is exceeded or if TTL is exceeded or if PersistDuration is exceeded (there may be other things as well...).
126 line 1359 4.2.4.1.1 spec technical Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Text allows Error on Error which was not our intent.
Proposal: s/header SHOULD/header and no ErrorList with highestSeverity set to Error SHOULD/
Resolution: done. Yes, we have disallowed any response to an Error message. Section deleted.
127 line 1360 4.2.4.1.1 spec technical Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL issue: What does "ignore" mean in the context of HTTP with SyncReply true?
Proposal: Explain
Resolution: done. Section deleted.
128 line 1369-1370 4.2.4.2 spec technical Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL issue: Unparsable messages will be caught by the SOAP processor underlying most "layered" MSH implementations. It's not possible for us to specify the action of that SOAP processor.
Proposal: Reduce requirement level from SHOULD to MAY.
Resolution: done.
129 line 1375 4.2.4.3 spec editorial Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Clarify
Proposal: s/not being sent as a result of processing of an earlier message/being sent on its own, with no payload data/
Resolution: done. Tried to make this change but result was strange. Instead changed sentence to *An ErrorList element can also be included in an independent message.*
130 line 1376 4.2.4.3 spec technical Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL: Use specified service and action for any ErrorList sent on its own. Warning severity won't always mean we have a payload to carry.
Proposal: s/if the highestSeverity is set to Error,//
Resolution: done.
131 line 1372-1379 4.2.4.3 spec technical Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL: Actually, this section still makes little sense. I believe an attempt was made to describe the Service and Action when ErrorList is sent on its own. That may occur regardless of the highestSeverity and the problem is mostly addressed through the two changes above.

In addition, "processing" is used in the first paragraph without context and we still need to remind users that ErrorList with highestSeverity="Error" can't be combined with payload data.
Proposal: Something at the end of the first paragraph like "This method MUST NOT be used if the highestSeverity is "Error". No further processing of the message in error could have occurred in that case." may help.
Resolution: done.
132 line 1380-1404 5 spec editorial Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Entire section would be better placed as section 4.3.
Proposal: Move it there
Resolution: done.
133 line 1398 5.1 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Reduce wordiness
Proposal: s/has the following attributes/consists of/
Resolution: Disagree. Don't see the requested text.
134 line 1395 5.1 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Wildcard descriptions
Proposal: a

#wildcard (see section 2.3.6 for details)
Resolution: Disagree. We fixed the schema to allow for #wildcard elements on all top-level elements but we made an editorial decision NOT to add this all the way through the spec and we say this in 2.3.6.
135 line 1400-1401 5.1 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL issue: This seems backwards. SyncReply s/b allowed if syncReplyMode is none (for the Acknowledgment message to come back synchronously); if syncReplyMode is not none and it's a synchronous communication protocol in use, SyncReply MUST be present. Further, intermediaries may have no idea about the CPA in use and could easily violate these overly strict restrictions (e.g. an intermediary just prior to the To Party requesting a synchronous hop-to-hop Acknowledgment).
Proposal: Reduce error constraints as described.
Resolution: Disagree. If SyncReplyMode is none then SyncReply MUST NOT be present. This is why we added mshSignalsOnly. SyncReply does not work with multi-hop RM anyway. If the next hop responds with an Acknowledgment after the message is sent on then the connection drops and a business response or an Acknowledgment from the end CANNOT be synchronous.
136 line 1380-1404 5.1 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL issue: During the discussion of this addition we agreed to add words about SOAP processors w/o full MSH understanding and their need to forward a like extension. Those words are missing. Note: Intermediate MSH nodes MAY forward using a different protocol than the incoming message and are therefore NOT REQUIRED to insert a copy of this element in all cases.
Proposal: With exception of above note, add words suggested and voted on during an earlier face to face meeting. I think Chris made the suggestion.
Resolution: Disagree. This was part of the discussion but not agreed to (are there some minutes to this effect?). How would an intermediary know whether to insert a SyncReply element anyway?
137 line 1416-1417 6.1.4 spec editorial Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Introduce in section 8.2.3
Proposal: s/except the StatusRequest element.//
Resolution: done. Changed StatusRequest to Manifest.
138 line 1420 6.1.4 spec editorial Closed Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Why is this bullet all alone?
Proposal: Should be part of previous paragraph after recommended deletions.
Resolution: done. Removed bullet.
139 line 1422-1423 6.1.5 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL issue: SyncReply is not allowed everywhere. Issue previously was about lack of description for SyncReply, now it's too loose.
Proposal: Should say (here or in 5.1) the SyncReply element is not allowed in a synchronous response message.
Resolution: Disagree. Couldn't a synchronous response message contain a business reply which also needs to be responded to - or could it contain an AckRequested? This is also opposed to the idea of an Error Message sent reliably (which we do not allow) or a synchronous Error on an Acknowledgment. This could be a severe restriction on optional elements; but, this section is about Core elements only. Restrictions with optional elements are noted in those sections.
140 line 1426 7 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Reliable Messaging isn't defined.
Proposal: a

For the purposes of this document, "Reliable Messaging" is defined to mean sending a message that both parties will know was received by the To Party's application intact once and only once, detect a permanent failure situation or retry until giving up.

Note: Failure remains an option even when making full use of ebXML Reliable Messaging. In addition, this addresses duplication only when caused by errant MSH implementations or communication protocols: Applications may send distinct messages containing the same payload and receiving applications may need to handle these duplicates.
Resolution: Disagree. This is an introduction and we don't need to say everything up front. This is too big a change.
141 line 1429 7 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Point example is specific to intermediaries though protocol is generally flexible (see issue 142).
Proposal: s/flexible/flexible with respect to intermediaries/
Resolution: Disagree. This doesn't make any sense?
142 line 1429 7 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Expand on flexibility.
Proposal: a

The protocol is also flexible with respect to the features implemented by communications protocols, ebXML MSH software and applications. Options are available controlling MSH implementation of well-defined segments of the overall reliability requirements. Most of the following discussion assumes all ebXML reliable messaging options are enabled.

Note: This assumption in the text should not prevent use of reliable communication protocols, idempotent application semantics, et cetera instead. ebXML Reliable Messaging semantics should be considered whenever such alternatives are not available or the MSH implementation is more efficient.
Resolution: Disagree. The statement is incorrect. The discussion DOES NOT assume that all ebXML reliable messaging options are enabled.

We also agreed NOT to consider other reliable transfer protocols and just go with ebXML Reliable Messaging, which negates the note.
143 line 1435 7 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Not explained why a message could be received more than once.
Proposal: s/once/once (due to retries or the nature of the communications protocol in use)/
Resolution: Disagree. Issue description not correct. It says in the previous sentence that *a Sending MSH MAY trigger successive retries...*. Not clear what this adds.
144 line 1436 7 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Better explain what turning duplicate elimination means to receiver.
Proposal: a Retries initiated by a Sending MSH and duplicates introduced by an unreliable communication protocol MUST be handled by the Receiving MSH or higher application layers at the To Party.
Resolution: Disagree. Why is this necessary? ALL retries are handled by the Receiving MSH -- unless there is a Delivery Failure somewhere. This statement is not wrong but it is not clear what it adds at this point in the document. This is all discussed later.
145 line 1443 7.1 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Set a real minimum requirement for reliability.
Proposal: s/SHOULD/MUST/
Resolution: none
146 line 1455 7.1 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL: All of the following information is presently missing which is internally inconsistent.
Proposal: a

In order to associate an Acknowledgment element with the corresponding application state and to send retries, a Sending MSH SHOULD save the following in persistent storage:
  • MessageId of the sent message
  • Timestamp, RetryInterval and remaining Retries (elements and parameters to the MSH), providing support for a queue of messages awaiting retry or application failure notification
  • Entire SOAP message for use in later retries
  • links to application state for any required notifications
The possible notifications from a Sending MSH to the From Party application are:
  • Successful delivery (Sending MSH has received an Acknowledgment element in a message not containing an ErrorList)
  • Acknowledged delivery with errors (Sending MSH has received a message containing both Acknowledgment and ErrorList elements; processing MAY have continued at the To Party in this case)
  • Timeout (TimeToLive expired or Retries have been exhausted)
Resolution: none
147 line 1473 7.3.1 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Wildcard descriptions
Proposal: a

#wildcard (see section 2.3.6 for details)
Resolution: Disagree. We fixed the schema to allow for #wildcard elements on all top-level elements but we made an editorial decision NOT to add this all the way through the spec and we say this in 2.3.6.
148 line 1500-1502 7.3.1.2 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL issue: I previously suggested this case should result in an Error because it was inconsistent with the other Inconsistent errors, resulting in just a Warning. Now, the text requires Inconsistent/Warning where NotSupported/Error would be appropriate. It's gotten worse and should be Inconsistent/Error or the combination of that with a NotSupported/Error option.
Proposal: Change text to use only Error severity. Probably best to stick with Inconsistent status code.
Resolution: none
149 line 1515-1517 7.3.2 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL: This isn't sensible and is a massive change from 1.0. Why would an Acknowledgment message be bundled into another message that isn't in response to the message in question?

Issue 41 (in the schema) is directly related to this one.
Proposal: s/The RefToMessageId element in an Acknowledgment element is used to identify the message being acknowledged by its MessageId.//
Resolution: none
150 line 1524 7.3.2 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Please refer to issues 41, 149 and others mentioning those issues for related updates to the schema and specification.
Proposal: d
Resolution: none
151 line 1526 7.3.2 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Wildcard descriptions
Proposal: a

#wildcard (see section 2.3.6 for details)
Resolution: Disagree. We fixed the schema to allow for #wildcard elements on all top-level elements but we made an editorial decision NOT to add this all the way through the spec and we say this in 2.3.6.
152 line 1535-1537 7.3.2.3 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Please refer to issues 41, 149 and others mentioning those issues for related updates to the schema and specification.
Proposal: d
Resolution: none
153 line 1541 7.3.2.4 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Clarify use of From element. Not necessary if change in issue 42 is accepted.
Proposal: a This form SHOULD be used for hop-to-hop Acknowledgment messages from intermediate nodes, especially when the message also contains data from other nodes.
Resolution: none
154 line 1543 7.3.2.4 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Clarify use of From element. Not necessary if change in issue 42 is accepted.
Proposal: a This form SHOULD be used for all end-to-end Acknowledgment messages.
Resolution: none
155 line 1554 7.3.2.5 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Note: This section contains more references than it did before. It still doesn't refer to 4.1.4.2 but should. Some of the recent reference additions may be worth removing.
Proposal: s/derived/derived (as described in section 4.1.4.2)/
Resolution: none
156 line 1557 7.3.2.5 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL: Again, I disagree with this requirement because it disallows the To Party MSH acknowledging receipt of a message and signing the acknowledgment without also describing the contents. The message already has the RefToMessageId element and any disagreements about the contents of that message would be covered through the signing the original party did. I would prefer to strike this sentence and much of the surrounding discussion. It's a bit worse now that the text attempts to define "signed Acknowledgment Message" two ways simultaneously (signed Ack either means "it contains both Ack and Signature" or "contains both Ack with Reference list and Signature").

For additional discussion, please refer to issue 102.
Proposal: s/element/list/

This proposal is a minor editorial change to the text. As mentioned above, I would prefer to strike this sentence and much of the surrounding discussion. This is a fallback if the larger change is not accepted.
Resolution: none
157 line 1570 7.3.2.6 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] If issue 42 is accepted, example would no longer be correct.
Proposal: d
Resolution: none
158 line 1577 7.3.2.7 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL: I could go either way here (prefer either Action) but we haven't made a choice yet.
Proposal: a

When an Acknowledgment message and Error message are combined without additional payloads (regardless of the highestSeverity attribute of the included ErrorList element), the service and action described in 4.2.4.3 MUST be used.
Resolution: none
159 line 1580 7.3.2.8 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Note TECHNICAL issue already raised about this last sentence and related disussion in issue 34. The inability to send a reliable Error (even when a Warning and combined with payload data) in the current text should be resolved by killing this sentence. This issue was resolved during the last face-to-face and Chris most recently mentioned it.

The only vote that has taken place around the error on acknowledgment issue was acceptance of resolutions for the issue database. That is clear on this subject.
Proposal: Remove this sentence.
Resolution: none
160 line 1568-1584 7.4.1 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] This section repeats some of 3.1.7 and adds new information. The new information belongs better in 3.1.7. All that should be left here is information about the relation between the CPA flag and the DuplicateElimination element. At the moment, the semantics of the DuplicateElimination element are described again -- without reference to section 3.1.7.
Proposal: Factor this information between 7.4.1 and 3.1.7, removing duplications.
Resolution: none
161 line 1593 7.4.1 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] "Ignored" hasn't been defined in this context. Be more explicit, especially since application layers remain free to eliminate duplicates.
Proposal: s/duplicate messages to be ignored/the To Party application never to see duplicate messages/
Resolution: none
162 line 1601-1603 7.4.2 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] This section attempts to re-define an element already described in section 7.3.1 and adds no new information. Just nuke the section. At most, mention that some configuration information must be available to the From Party MSH to determine whether or not an acknowledgment may be requested and whether or not it could be signed.
Proposal: d
Resolution: none
163 line 1613 7.4.4 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Minor editorial
Proposal: s/between retries/between later retries/
Resolution: none
164 line 1621-1622 7.4.6 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] The equation should describe something under MSH control when sending a message. Similar syntax to 7.4.5 makes it easier to read.
Proposal: s/The timestamp for a reliably sent message (found in the message header), plus its PersistDuration (found in the CPA), must be greater than its TimeToLive (found in the message header)./For a reliably delivered message, TimeToLive MUST conform to:

TimeToLive < TimeStamp + PersistDuration

where TimeStamp comes from MessageData and PersistDuration is found in the CPA./
Resolution: none
165 line 1636 7.4.7 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Last error requirement in this section conflicts with "ignore" requirement that's first. Keep the choices separate and avoid ambiguity.
Proposal: s/If the value of syncReplyMode is none and a SyncReply element is present,/If the value of syncReplyMode is not none, the communications protocol is synchronous and a SyncReply element is not present in a message,/

[This sentence should be joined with the previous paragraph.]
Resolution: none
166 line 1629-1637 7.4.7 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL: The current wording disallows sending MSH signals synchronously. Change in issue 164 also doesn't address problems raised earlier around heterogeneous routes to the destination and intermediaries not being party to the CPA.
Proposal: Since we're going out of our way to describe CPA semantics in this section, make sure we include mention of the "mshSignals" option in the syncReplyMode parameter.

Heterogeneous routes should be a subject for discussion on the list. At the least, we should mention that error handling assumes a homgeneous route between From and To parties.
Resolution: none
167 line 1655 7.5.1 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Current words don't mention anything about notification of failures or other application interactions.
Proposal: a

6. Notify application of delivery success or failure (if requested).
Resolution: none
168 line 1665-1666 7.5.2 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Remove duplicate instructions.
Proposal: s/generate an Acknowledgment Message (see section 7.5.3). Follow/follow/
Resolution: none
169 line 1673-1676 7.5.2 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Move everything from this paragraph except the first sentence into 7.5.3, assuming that section continues to have some useful content. This is general information about all Acknowledgment messages generated. Replace these sentences with ", as described in section 7.5.3".
Proposal: Update text as described.
Resolution: none
170 line 1689-1691 7.5.3 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Because the RefToMessageId element adds no value to an Acknowledgment element, this paragraph means little. If anything is necessary, section 7.3.2 should (somewhere) remind people, as is done for Error messages, that the MessageData/RefToMessageId value must be set appropriately.

Please refer to issues 41, 149 and others mentioning those issues for related updates to the schema and specification.
Proposal: d
Resolution: none
171 line 1692-1703 7.5.3 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Most of this section attempts to redefine what's already in 7.3.2. and 7.3.2.7 without adding much value and confusing some issues (e.g. some bullets are generally true while others apply only to stand-alone Ack messages). Copy what's not already in those sections appropriately and make sure that section is now consistent. This section (7.5.3) should be left with only a reference to 7.3.2 and the "persisted storage" description from 7.5.2. Maybe, the last 3 bullets could stay here.
Proposal: Move text and re-factor 7.3.2, 7.3.2.7 and 7.5.3.
Resolution: none
172 line 1725-1737 7.5.5 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] This section should come after what's now 7.5.6, reverse two sections
Proposal: Move section as described.
Resolution: none
173 line 1726 7.5.5 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Current text requires return of stored acknowledgment for every duplicate, regardless of DuplicateElimination element's presence. There should be no need for identical acknowledgments or even special handling of duplicate messages without that element.
Proposal: s/duplicate/duplicate and DuplicateElimination is present/
Resolution: none
174 line 1728 7.5.5 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Clarify the word "it".
Proposal: s/it/first that/
Resolution: none
175 line 1729 7.5.5 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Eliminate "that".
Proposal: s/that matches/matching/
Resolution: none
176 line 1730 7.5.5 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Reduce wordiness
Proposal: s/then/,/
Resolution: none
177 line 1731 7.5.5 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Clarify text, removing "that".
Proposal: s/MSH that sent the received message/Sending MSH for the duplicate message/
Resolution: none
178 line 1732 7.5.5 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Remove unecessary "if".
Proposal: s/and if/and/
Resolution: none
179 line 1733 7.5.5 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Reduce wordiness.
Proposal: s/then/,/ s/that//
Resolution: none
180 line 1734 7.5.5 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Reduce wordiness.
Proposal: s/same//
Resolution: none
181 line 1735 7.5.5 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Reduce wordiness
Proposal: s/that was//
Resolution: none
182 line 1737 7.5.5 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Add useful reference.
Proposal: s/Message/Message (as described in section 7.5.3)/
Resolution: none
183 line 1744 7.5.6 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Please refer to issues 41, 149 and others mentioning those issues for related updates to the schema and specification.
Proposal: s/the same RefToMessageId as/a RefToMessageId value matching the MessageId of/
Resolution: none
184 line 1752-1753 7.5.6 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Note unbalanced parentheses are also fixed by removing this unnecessary text.
Proposal: s/sent to the sender Party A)//
Resolution: none
185 line 1753 7.5.6 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL: If the recipient ensures a duplicate is identical, we should say what happens if the check fails.
Proposal: a

2a) The recipient of a duplicate message MAY confirm the duplicate is indeed identical to the original, allowing for changes introduced by intermediate nodes. If this is found not to be the case, the receiving MSH SHOULD issue an error with errorCode of Inconsistent and a severity of Error.
Resolution: none
186 line 1777 8 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Reword to use "A Message Status Response message" as the subject, matching the previous bullet's style.
Proposal: Change as described.
Resolution: none
187 line 1827 8.2 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Wildcard descriptions
Proposal: a

#wildcard (see section 2.3.6 for details)
Resolution: Disagree. We fixed the schema to allow for #wildcard elements on all top-level elements but we made an editorial decision NOT to add this all the way through the spec and we say this in 2.3.6.
188 line 1849 8.3 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Wildcard descriptions
Proposal: a

#wildcard (see section 2.3.6 for details)
Resolution: Disagree. We fixed the schema to allow for #wildcard elements on all top-level elements but we made an editorial decision NOT to add this all the way through the spec and we say this in 2.3.6.
189 line 1864 8.3.3 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL issue: We had some reason for handling this requester error in the response element rather than using an ErrorList. Did this have something to do with the possibility of sending multiple StatusRequest elements in the same message? Either way, we need text describing why this isn't handled using an Error message.
Proposal: Describe reasoning behind unusual error handling.
Resolution: none
190 line 1867-1872 8.3.3 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL issue: This expands the list of possible values from those in MSH 1.0 without explanation. Hadn't we agreed the additional status values (Processed and Forwarded) are likely to be information the MSH doesn't know and shouldn't tell an outside party?
Proposal: Restore list of message status values from 1.0 specification.
Resolution: none
191 line 1910 9.1 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Complete the example according to our specification.
Proposal: s|Boundary"|Boundary"; type="text/xml"; start="gobblelygook"|
Resolution: none
192 line 1913 9.1 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Complete example according to our specification, related to issue 191.
Proposal: a

Content-Id: <gobbledygook>
Resolution: none
193 line 1921 9.1 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Correct the xsi:schemaLocation for the ebXML MSH namespace to use proper syntax. This would be a technical issue if it appeared outside an example.
Proposal: Repeat the string (identically)
Resolution: none
194 line 1967 9.2 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Correct the xsi:schemaLocation for the ebXML MSH namespace to use proper syntax. This would be a technical issue if it appeared outside an example.
Proposal: Repeat the string (identically)
Resolution: none
195 line 1993-1994 10 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Duplicate information in adjacent paragraphs.
Proposal: Remove second sentence. Information is better expressed in the next paragraph.
Resolution: none
196 line 2006 10.1 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Wildcard descriptions
Proposal: a

#wildcard (see section 2.3.6 for details)
Resolution: Disagree. We fixed the schema to allow for #wildcard elements on all top-level elements but we made an editorial decision NOT to add this all the way through the spec and we say this in 2.3.6.
197 line 2010 10.1.1 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL issue: I made a mistake in this suggestion. The SequenceNumber element is required inside an optional element and therefore is not REQUIRED of all implementations. Remove word again (sorry).
Proposal: undo s/SequenceNumber/REQUIRED SequenceNumber/ change previously requested
Resolution: none
198 line 2485 B.2.2 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Current xsi:schemaLocation doesn't include the namespace identifier for our schema, resulting in illegal syntax. Probably, the second tuple in this attribute value (after addition below) should be moved to separate xsi:schemaLocation attributes on the soap:Header and soap:Body elements. Otherwise, we conflict with our own "one namespace per such attribute" recommendations.
Proposal: a

http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd
Resolution: none
199 line 2536-2547 B.2.4 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] TECHNICAL: I won't repeat all of the technical discussions of problems in this section. My memory dims this late in the game but I seem to recall issues with requiring SOAP Fault separately (since the SOAP processor isn't something we're defining) and problems using the Fault element asynchronously in any case (since it provides no context for the error described).
Proposal: Remove this requirement.
Resolution: none
200 line 2549-2555 B.2.5 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] I'm not sure this section is as clear as it could be. It seems David had a different interpretation.
Proposal: Might need some rewording.
Resolution: none
201 line 2555 B.2.5 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Don't force SOAP processor to change it's default behavior for the lowly MSH handler. That is, only the ebXML handler can satisfy this requirement.
Proposal: s/Post/Post if the message is processed by an ebXML MSH handler/
Resolution: none
202 line 2622-1624 B.3.2 spec technical Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] This header is defined only for HTTP communication.
Proposal: d
Resolution: none
203 line 2638 B.3.2 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] As above, in issue 202. Editorial because this occurrence is in an example.
Proposal: d
Resolution: none
204 line 2656 B.3.2 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Correct the xsi:schemaLocation for the ebXML MSH namespace to use proper syntax.
Proposal: Repeat the string (identically).
Resolution: none
205 line 2676 B.3.2 spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Correct the xsi:schemaLocation for the ebXML MSH namespace to use proper syntax.
Proposal: Repeat the string (identically).
Resolution: none
206 line 2786,2799,2802-2806 References spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Entire section and all references in the text should consistently use [RFC1234] for references to these documents. XMLMEDIA, PGP/MIME and S/MIME* all violate this consistency.
Proposal: Update as described
Resolution: none
207 line 2744-2766 References spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Sort the RFC entries by their number.
Proposal: Update as described
Resolution: none
208 line 2744-2814 References spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] Entire section should use a consistent format for the references, order and contain similar information. For example, references to RFC documents should all include the title of the RFC and (probably, I don't remember the IETF standards) IETF RFC1234. W3C documents are very inconsistent in this section.
Proposal: Update as described
Resolution: none
209 line 2744-2814 References spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] For documents available online (such as all ebXML documents but likely excluding the RFC's, letting people head to their favorite RFC source), please include URL values. These are presently missing from most ebXML documents.
Proposal: Update as described
Resolution: none
210 line 2744-2814 References spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] All references to W3C documents should consistently include the date in their URL values.
Proposal: Update as described
Resolution: none
211 line 2787-2788 References spec editorial Active Doug Bunting
Title: Comment on 1.09 and on
Description: [see email, which includes references to November comments] This should refer to the section of the Unicode Standard that defines UTF-8. This is an incomplete definition for the term UTF-8.
Proposal: Update as described
Resolution: none
212 line 1-2842 All spec editorial Active Doug Bunting
Title: Rollup comment on 1.09 and on
Description: [see email] I found a fair number of incorrect references to sections in the document.
Proposal: Why doesn't this document use links to correct sections so that edits don't mess them up?
Resolution: none
213 line 1-2842 All spec editorial Active Doug Bunting
Title: Rollup comment on 1.09 and on
Description: [see email] Issues above suggest(ed) adding references to 2.3.6 (then 2.2.6) where they were missing in the 1.09 document. The 2.0 document instead contains no references at all to 2.3.6. Only the schema describes where wildcard element content is allowed. (The schema does, at my suggestion, allow <any> element content on all top-level SOAP extensions and the Error and Reference elements we define.) Just a placeholder to tie issues 95, 111, 115, 134, 147, 151, 187, 188 and 196 together. Treat those as sub-issues.
Proposal: Restore the "#wildcard" lines from 1.09 and add those mentioned in the listed issues.
Resolution: Disagree. We fixed the schema to allow for #wildcard elements on all top-level elements but we made an editorial decision NOT to add this all the way through the spec and we say this in 2.3.6.
214 line 1-2842 All spec editorial Active Doug Bunting
Title: The word "then" appears
Description: [see email] The word "then" appears often instead of a comma. The document might be significantly shorter the other way.
Proposal: Search for word "then" and replace with comma wherever possible. Some occurrences called out in other submitted issues.
Resolution: none
215 line 223 1 spec technical Active Doug Bunting
Title: contradictions between Appendix A
Description: [see email] TECHNICAL: This and following issue are a TECHNICAL change necessary to avoid problems with contradictions between Appendix A and the schema available directly from the web site.
Proposal: s/normative/non-normative/
Resolution: none
216 line 224 1 spec technical Active Doug Bunting
Title: Avoid contradictions between actual
Description: [see email] TECHNICAL: Avoid contradictions between actual schema and Appendix A.
Proposal: a

The XML Schema document found at http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd is a normative part of this specification and supersedes the "snapshot" found in Appendix A.
Resolution: none
217 line 228 1.1.1 spec editorial Active Doug Bunting
Title: Section 1.1 is missing.
Description: [see email] Section 1.1 is missing.
Proposal: Suggest adding "1.1 Background" or some such.
Resolution: none
218 line 618,621 2.3.2 spec editorial Active Doug Bunting
Title: Messed up indentation
Description: [see email] I guess it made sense to remove the background highlighting these lines (because it was also used for examples). Unfortunately, the removal of that attribute messed up the indentation.
Proposal: Move these lines to the left to line up with other URI values called out in the specification.
Resolution: none
219 line 779-781 3.1.1.1 spec technical Active Doug Bunting
Title: Is something a URI?
Description: [see email] TECHNICAL: It's not possible (or worthwhile) to determine whether or not something is a URI except by checking for a colon.
Proposal: Remove second sentence.
Resolution: none
220 line 877-880 3.1.6.2 spec technical Active Doug Bunting
Title: Timestamp element precision
Description: [see email] TECHNICAL: This section on the Timestamp element doesn't require any particular precision for the value. All examples in this document are accurate only to seconds, likely not enough for reliable ordering of received messages (among other purposes). Timestamps generally include at least milliseconds and we should be at least that prescriptive.
Proposal: Add strong suggestion or requirement (capitalized MUST) at least to use all available (platform-provided) precision in timestamp value. In examples throughout the document, add 4 digits to right of decimal for every timestamp value.
Resolution: none
221 line 1049,1053,1065,1068-1072 4.1.3 spec editorial Active Doug Bunting
Title: Consistent typography
Description: [see email] To be consistent with the typographic changes to sections 2.3.1 and 2.3.2, removing the background from non-example material in section 4.1.3 would seem appropriate. The lines referenced in this issue are the remaining cases of normative material against a grey background. That background should be removed.
Proposal: Update as described.
Resolution: none
222 line 1114,1116 4.1.3 spec editorial Active Doug Bunting
Title: Unneeded character entity
Description: [see email] No reason to use the character entity for quotation marks outside an attribute value. Just lessens readability of the example.
Proposal: s/&quot;/""/g [Just want one doublequote - faking out editor]
Resolution: none
223 line 1407 6.1.1 spec editorial Active Doug Bunting
Title: Section 6.1 is missing.
Description: [see email] Section 6.1 is missing.
Proposal: Suggest making 6.1.1 through 6.1.5 be 6.1 through 6.5. Chapter 6 has no lower or later sections.
Resolution: none
224 line 1486-1487 7.3.1.1 spec technical Active Doug Bunting
Title: Default actor introduced but not agreed
Description: [see email] TECHNICAL: I suggested adding a default actor option to the AckRequested and Acknowledgment elements. Later in the discussion, I was convinced by others in the group this wasn't a necessary addition and I withdrew it. Since the sender doesn't know whether another MSH is authorized to act on behalf of the To Party, toPartyMSH is enough. The document and schema unfortunately followed my suggestion and not its withdrawal.
Proposal: s/or by leaving this attribute out.//
Resolution: none
225 line 1529-1530 7.3.2.1 spec editorial Active Doug Bunting
Title: More on issue 224
Description: [see email] Reasoning as in previous issue.
Proposal: Remove last sentence in paragraph.
Resolution: none
226 line 1713 7.5.4 spec technical Active Doug Bunting
Title: Ack on Ack problem
Description: [see email] TECHNICAL: We agreed that MSH doesn't support Ack on Ack. However, that should apply only to stand-alone Ack messages. Quite reasonable to send Ack and AckR together with a business response, maybe an ErrorList (containing warnings) too. Improvement may require some text changes earlier in the document as well.
Proposal: s/Acknowledgment Messages/Acknowledgment Messages sent without payload data/
Resolution: none
227 line 1923-1924 9.1 spec editorial Active Doug Bunting
Title: Uselessly repeat namespace, etc.
Description: [see email] These lines uselessly repeat the namespace and location declarations for our schema. Worse, the schemaLocation attribute does not have the correct syntax.
Proposal: d
Resolution: none
228 line 2093 11.1.2 spec editorial Active Doug Bunting
Title: Kill Acknowledgment/RefToMessageId
Description: [see email] Please refer to issues 41, 149 and others mentioning those issues for related updates to the schema and specification.
Proposal: d
Resolution: none

Table Legend

id
Issue number
Title
Short title/name of the issue
Spec
Document referred to in issue (AM = Abstract Model, Spec = XMLP/SOAP Specification
Description
Short description of issue, possibly including link to origin of issue
Section
Reference to specification section that motivated this issue
Topic
Rough topic categorisation, one of: env(elope), rpc, enc(oding), meta(issue), bind(ing), fault
Class
Design or Editorial
Status
One of: Unassigned, Active, Closed, Postponed
Proposal
Current proposal for resolution of issue, possibly including link to further text
Resolution
Short description of resolution, possibly including link to a more elaborate description
Raised by
Person who raised the issue
Owner
ebXML Messaging TC Member responsible for the issue
Maintained by Christopher Ferris.