OASIS ebXML Messaging TC |
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).
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 |
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:
|
|||||||
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/"/""/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 |