| 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 acknowledgm | |||||||