OASISOASIS ebXML Messaging TC

OASIS ebXML Messaging TC Issues List

Last update: January 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
1 Active line 15/16 spec editorial title page title page
2 Active line 17/18 spec editorial title page boilerplate
3 Active line 20 spec editorial title page title page
4 Active line 23 spec editorial ebXML participants ebXML participants
5 Active line 26 spec editorial ebXML participants ebXML Participants
6 Active line 200 spec editorial Introduction typo
7 Active line 208 spec editorial Introduction typo
8 Active line 214 spec editorial Introduction editorial tweak
9 Active line 472 spec editorial 2.1 Packaging Specification editorial tweak
10 Active line 509 spec editorial 2.1.2 Message Package RFC2119 usage
12 Active line 724 spec editorial 2.3.10 NextMSH actor URI editorial tweak
13 Active line 732 spec editorial 2.3.11 ToPartyMSH actor URI editorial tweak
14 Active line 764 spec editorial 3.1.1 From and To Party elements RFC2119 usage/typo
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
17 Active line 810 spec editorial 3.1.2 CPAId element CPA
18 Active line 831 spec editorial 3.1.3 ConversationId element typo
19 Active line 872 spec editorial 3.1.6.1 MessageId element local part of MID?
20 Active line 899 spec editorial 3.1.7 DuplicateElimination element duplicate detection
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
24 Active line 942 spec editorial 3.2 Manifest element premature reference to xlink:role
27 Active line 1029 spec editorial 4.1.2.1 Collaboration Protocol Agreement RFC2119 usage
28 Active line 1037 spec editorial 4.1.3 Signature Generation typo
29 Active line 1050 spec editorial 4.1.3 Signature Generation editorial tweak
31 Active line 1436 spec editorial 7 Reliable Messaging Module duplicate eleimination 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
39 Active line 2791... spec editorial Non-Normative References references to ebXML specs
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
51 Active line 211 spec editorial 1.1.1 Comment on 1.09 and on
52 Active line 219 spec editorial 1.1.1 Comment on 1.09 and on
53 Active line 221 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
71 Active line 592 spec editorial 2.2.1 Comment on 1.09 and on
72 Active line 609 spec editorial 2.3 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
85 Active line 831 spec editorial 3.1.3 Comment on 1.09 and on
86 Active line 838-840 spec editorial 3.1.4 Comment on 1.09 and on
89 Active line 872-873 spec editorial 3.1.6.1 Comment on 1.09 and on
90 Active line 885 spec editorial 3.1.6.3 Comment on 1.09 and on
91 Active line 886 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
98 Active line 1009 spec editorial 4.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
101 Active line 1146-1150 spec editorial 4.1.4.1 Comment on 1.09 and on
104 Active line 1160 spec editorial 4.1.4.3 Comment on 1.09 and on
105 Active line 1166 spec editorial 4.1.4.4 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
114 Active line 1285 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
117 Active line 1301 spec editorial 4.2.3.2.2 Comment on 1.09 and on
118 Active line 1303 spec editorial 4.2.3.2.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
123 Active line 1319-1320 spec editorial 4.2.3.2.5 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
129 Active line 1375 spec editorial 4.2.4.3 Comment on 1.09 and on
132 Active line 1380-1404 spec editorial 5 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
137 Active line 1416-1417 spec editorial 6.1.4 Comment on 1.09 and on
138 Active line 1420 spec editorial 6.1.4 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
26 Active line 982 spec minor technical 3.2.2 Manifest validation suggestion to discard note
11 Active line 709 spec technical 2.3.8 version attribute confusion w/r/t conformance
21 Active line 901 spec technical 3.1.8 DuplicateElimination element duplicate elimination confusion
25 Active line 972, 1321 spec technical 3.2.1.2 Description element Description element
30 Active line 1434 spec technical 7 Reliable Messaging Module RFC2119 MUST semantics for DFN
32 Active line 1449 spec technical 7.1 Persistent Storage... RFC2119 usage
34 Active line 1512 spec technical 7.3.1.4 AckRequested error on ack and ack on error issue
36 Active line 1580 spec technical 7.3.2.8 Acknowledgment... error on ack
37 Active line 1809 spec technical 8.1.2 MessageStatus... incorrect URI
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
83 Active line 815 spec technical 3.1.2 Comment on 1.09 and on
84 Active line 816,817 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
88 Active line 850 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
96 Active line 969 spec technical 3.2.1.1 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
110 Active line 1279 spec technical 4.2.3 Comment on 1.09 and on
116 Active line 1295 spec technical 4.2.3.2 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
126 Active line 1359 spec technical 4.2.4.1.1 Comment on 1.09 and on
127 Active line 1360 spec technical 4.2.4.1.1 Comment on 1.09 and on
128 Active line 1369-1370 spec technical 4.2.4.2 Comment on 1.09 and on
130 Active line 1376 spec technical 4.2.4.3 Comment on 1.09 and on
131 Active line 1372-1379 spec technical 4.2.4.3 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
44 Active line 2282(126) schema major technical Appendix A sequenceNumber.type is poorly defined
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
43 Active line 2304(148) schema technical Appendix A Description element here doesn't match the document
47 Active none schema technical Appendix A Schema element should have an optional "namespace" attribute
48 Active line 2169(???) schema technical Appendix A Import correct / latest schema for XML namespace

Detailed List of Issues

id Spec Section Topic Class Status Raised By Owner
1 line 15/16 title page spec editorial Active 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: none
2 line 17/18 title page spec editorial Active 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: none
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: none
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: none
5 line 26 ebXML participants spec editorial Active 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: none
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: none
7 line 208 Introduction spec editorial Active Chris Ferris
Title: typo
Description: [see email] s/,//
Proposal: make suggested change
Resolution: none
8 line 214 Introduction spec editorial Active Chris Ferris
Title: editorial tweak
Description: [see email] s/Elements/Features/
Proposal: make suggested change
Resolution: none
9 line 472 2.1 Packaging Specification spec editorial Active Chris Ferris
Title: editorial tweak
Description: [see email] s/the following figure/figure 2.1/
Proposal: make suggested change
Resolution: none
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: none
11 line 709 2.3.8 version attribute spec technical Active 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: none
12 line 724 2.3.10 NextMSH actor URI spec editorial Active Chris Ferris
Title: editorial tweak
Description: [see email] s/The /The URI /
Proposal: make suggested change
Resolution: none
13 line 732 2.3.11 ToPartyMSH actor URI spec editorial Active Chris Ferris
Title: editorial tweak
Description: [see email] s/The /The URI /
Proposal: make suggested change
Resolution: none
14 line 764 3.1.1 From and To Party elements spec editorial Active Chris Ferris
Title: RFC2119 usage/typo
Description: [see email] s/must/MUST/
Proposal: make suggested change
Resolution: none
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: none
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
Proposal: make suggested change
Resolution: none
17 line 810 3.1.2 CPAId element spec editorial Active 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: none
18 line 831 3.1.3 ConversationId element spec editorial Active Chris Ferris
Title: typo
Description: s/schema/scheme/
Proposal: make suggested change
Resolution: none
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: none
20 line 899 3.1.7 DuplicateElimination element spec editorial Active 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: none
21 line 901 3.1.8 DuplicateElimination element spec technical Active 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: none
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: none
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: none
24 line 942 3.2 Manifest element spec editorial Active 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: none
25 line 972, 1321 3.2.1.2 Description element spec technical Active 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: none
26 line 982 3.2.2 Manifest validation spec minor technical Active 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: none
27 line 1029 4.1.2.1 Collaboration Protocol Agreement spec editorial Active Chris Ferris
Title: RFC2119 usage
Description: [see email] s/may be/is/
Proposal: make suggested change
Resolution: none
28 line 1037 4.1.3 Signature Generation spec editorial Active Chris Ferris
Title: typo
Description: [see email] s/and //
Proposal: make suggested change
Resolution: none
29 line 1050 4.1.3 Signature Generation spec editorial Active Chris Ferris
Title: editorial tweak
Description: s/for the ebXML Message Service//
Proposal: make suggested change
Resolution: none
30 line 1434 7 Reliable Messaging Module spec technical Active Chris Ferris
Title: RFC2119 MUST semantics for DFN
Description: [see email] This was supposed to have been changed to MUST.
Proposal: make suggested change
Resolution: none
31 line 1436 7 Reliable Messaging Module spec editorial Active Chris Ferris
Title: duplicate eleimination 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: none
32 line 1449 7.1 Persistent Storage... spec technical Active Chris Ferris
Title: RFC2119 usage
Description: [see email] s/SHOULD/MUST/
Proposal: make suggested change
Resolution: none
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: none
34 line 1512 7.3.1.4 AckRequested spec technical Active 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: none
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: none
36 line 1580 7.3.2.8 Acknowledgment... spec technical Active 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: none
37 line 1809 8.1.2 MessageStatus... spec technical Active Chris Ferris
Title: incorrect URI
Description: [see email] URI s/b urn:oasis:names:tc:ebxml-msg:service
Proposal: make suggested change
Resolution: none
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: none
39 line 2791... Non-Normative References spec editorial Active 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: none
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: none
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: none
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: none
43 line 2304(148) Appendix A schema technical Active 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: none
44 line 2282(126) Appendix A schema major technical Active 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 maxExclusive="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: none
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: none
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).
Proposal:
Resolution: none
47 none Appendix A schema technical Active 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: none
48 line 2169(???) Appendix A schema technical Active 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: none
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: none
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: none
51 line 211 1.1.1 spec editorial Active 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: none
52 line 219 1.1.1 spec editorial Active 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: none
53 line 221 1.1.1 spec editorial Active 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: none
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: none
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: none
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. In all such cases, the schema supersedes the specification.
Resolution: none
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: none
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: none
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: none
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: none
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: none
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: none
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: none
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: none
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: none
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: none
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: none
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: none
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: none
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: none
71 line 592 2.2.1 spec editorial Active 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: none
72 line 609 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/attribute/attributes/
Resolution: none
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: none
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: none
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: none
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: none
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: none
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: none
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: none
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: none
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: none
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/
Resolution: none
83 line 815 3.1.2 spec technical Active 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: none
84 line 816,817 3.1.2 spec technical Active 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: none
85 line 831 3.1.3 spec editorial Active 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: none
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: none
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: none
88 line 850 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 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: none
89 line 872-873 3.1.6.1 spec editorial Active 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: none
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: none
91 line 886 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] Correct reference.
Proposal: s/section 4.1.5/section 4.2.1.1/
Resolution: none
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: none
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: none
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: none
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: none
96 line 969 3.2.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: 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: none
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: none
98 line 1009 4.1 spec editorial Active 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: none
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: none
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: none
101 line 1146-1150 4.1.4.1 spec editorial Active 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: none
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: none
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: none
104 line 1160 4.1.4.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/,//
Resolution: none
105 line 1166 4.1.4.4 spec editorial Active 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: none
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: none
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: none
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: none
110 line 1279 4.2.3 spec technical Active 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: none
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: none
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: none
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: none
114 line 1285 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] Correct punctuation
Proposal: s/, otherwise/; otherwise,/
Resolution: none
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: none
116 line 1295 4.2.3.2 spec technical Active 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: none
117 line 1301 4.2.3.2.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 our element names.
Proposal: s/errorCodes/errorCode attribute values/ s/then//
Resolution: none
118 line 1303 4.2.3.2.2 spec editorial Active 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: none
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: none
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: none
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: none
123 line 1319-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] 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: none
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: none
126 line 1359 4.2.4.1.1 spec technical Active 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: none
127 line 1360 4.2.4.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: What does "ignore" mean in the context of HTTP with SyncReply true?
Proposal: Explain
Resolution: none
128 line 1369-1370 4.2.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: 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: none
129 line 1375 4.2.4.3 spec editorial Active 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: none
130 line 1376 4.2.4.3 spec technical Active 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: none
131 line 1372-1379 4.2.4.3 spec technical Active 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: none
132 line 1380-1404 5 spec editorial Active 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: none
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: none
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: none
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: none
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: none
137 line 1416-1417 6.1.4 spec editorial Active 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: none
138 line 1420 6.1.4 spec editorial Active 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: none
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: none
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: none
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: none
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: none
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: none
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: none
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: none
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: none
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: none
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: none
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: none
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 occurance 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 favourite 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: none
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 occurances 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.