<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="ebxml-msg-issues-html.xsl" type="text/xsl"?>
<!DOCTYPE issues SYSTEM "ebxml-msg-issues.dtd" >
<issues update='January 30, 2002'>
<issue>
<issue-num>1</issue-num>
<title>title page</title>
<locus>line 15/16</locus>
<section>title page</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a>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.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>2</issue-num>
<title>boilerplate</title>
<locus>line 17/18</locus>
<section>title page</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> 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.
</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>3</issue-num>
<title>title page</title>
<locus>line 20</locus>
<section>title page</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> 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.</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>4</issue-num>
<title>ebXML participants</title>
<locus>line 23</locus>
<section>ebXML participants</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> 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.</description>
<proposal>remove section "ebXML Participants"</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>5</issue-num>
<title>ebXML Participants</title>
<locus>line 26</locus>
<section>ebXML participants</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> If the section is preserved (see issue 4), then
s/meeting/meetings/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>6</issue-num>
<title>typo</title>
<locus>line 200</locus>
<section>Introduction</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/sending and receiving/that sends and receives/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>7</issue-num>
<title>typo</title>
<locus>line 208</locus>
<section>Introduction</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/,//</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>8</issue-num>
<title>editorial tweak</title>
<locus>line 214</locus>
<section>Introduction</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/Elements/Features/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>9</issue-num>
<title>editorial tweak</title>
<locus>line 472</locus>
<section>2.1 Packaging Specification</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/the following figure/figure 2.1/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>10</issue-num>
<title>RFC2119 usage</title>
<locus>line 509</locus>
<section>2.1.2 Message Package</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/may/can/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>11</issue-num>
<title>confusion w/r/t conformance</title>
<locus>line 709</locus>
<section>2.3.8 version attribute</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> 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.</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>12</issue-num>
<title>editorial tweak</title>
<locus>line 724</locus>
<section>2.3.10 NextMSH actor URI</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/The /The URI /</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>13</issue-num>
<title>editorial tweak</title>
<locus>line 732</locus>
<section>2.3.11 ToPartyMSH actor URI</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/The /The URI /</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>14</issue-num>
<title>RFC2119 usage/typo</title>
<locus>line 764</locus>
<section>3.1.1 From and To Party elements</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/must/MUST/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>15</issue-num>
<title>RFC2119 usage</title>
<locus>line 784</locus>
<section>3.1.1.2 PartyId element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> 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:<p/>
* 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)</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>16</issue-num>
<title>replacement text for Note</title>
<locus>line 788</locus>
<section>3.1.1.2 Role element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> suggested replacement text for the Note:<p/>
Note: Use of a URI for the value of the Role element
is RECOMMENDED. e.g. http://rosettanet.org/roles/buyer</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>17</issue-num>
<title>CPA</title>
<locus>line 810</locus>
<section>3.1.2 CPAId element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> 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.</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>18</issue-num>
<title>typo</title>
<locus>line 831</locus>
<section>3.1.3 ConversationId element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description>s/schema/scheme/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>19</issue-num>
<title>local part of MID?</title>
<locus>line 872</locus>
<section>3.1.6.1 MessageId element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> We thought that an issue had been raised that challenged
the "local part" characterization.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>20</issue-num>
<title>duplicate detection</title>
<locus>line 899</locus>
<section>3.1.7 DuplicateElimination element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> 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.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>21</issue-num>
<title>duplicate elimination confusion</title>
<locus>line 901</locus>
<section>3.1.8 DuplicateElimination element</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> 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.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>22</issue-num>
<title>"if there is a CPA with ..." is a little too vague</title>
<locus>line 903</locus>
<section>3.1.8 DuplicateElimination element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> "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:<p/>
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". </description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>23</issue-num>
<title>example issue</title>
<locus>line 914</locus>
<section>3.1.9 MessageHeader example</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> (example) curious that the From party has no
identified Role, but the To party does. Suggest that
both be assigned a role or neither. </description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>24</issue-num>
<title>premature reference to xlink:role</title>
<locus>line 942</locus>
<section>3.2 Manifest element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> 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)</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>25</issue-num>
<title>Description element</title>
<locus>line 972, 1321</locus>
<section>3.2.1.2 Description element</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> 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.<p/>
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.<p/>
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. </description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>26</issue-num>
<title>suggestion to discard note</title>
<locus>line 982</locus>
<section>3.2.2 Manifest validation</section>
<priority>minor technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> 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. </description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>27</issue-num>
<title>RFC2119 usage</title>
<locus>line 1029</locus>
<section>4.1.2.1 Collaboration Protocol Agreement</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/may be/is/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>28</issue-num>
<title>typo</title>
<locus>line 1037</locus>
<section>4.1.3 Signature Generation</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/and //</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>29</issue-num>
<title>editorial tweak</title>
<locus>line 1050</locus>
<section>4.1.3 Signature Generation</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description>s/for the ebXML Message Service//</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>30</issue-num>
<title>RFC2119 MUST semantics for DFN</title>
<locus>line 1434</locus>
<section>7 Reliable Messaging Module</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> This was supposed to have been changed to MUST.</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>31</issue-num>
<title>duplicate eleimination characterization</title>
<locus>line 1436</locus>
<section>7 Reliable Messaging Module</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> 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.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>32</issue-num>
<title>RFC2119 usage</title>
<locus>line 1449</locus>
<section>7.1 Persistent Storage...</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/SHOULD/MUST/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>33</issue-num>
<title>editorial tweak</title>
<locus>line 1459</locus>
<section>7.2 Methods ...</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/structures/extension modules/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>34</issue-num>
<title>error on ack and ack on error issue</title>
<locus>line 1512</locus>
<section>7.3.1.4 AckRequested</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> 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. </description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>35</issue-num>
<title>typo</title>
<locus>line 1564</locus>
<section>7.3.2.5 [XMLDSIG] Reference</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/This/The/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>36</issue-num>
<title>error on ack</title>
<locus>line 1580</locus>
<section>7.3.2.8 Acknowledgment...</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> We did NOT agree to this at all. We
agreed that an Error message *could* be sent reliably.
Ref <a href='http://lists.oasis-Active.org/archives/ebxml-msg/200201/msg00036.html'>email</a> for discussion.</description>
<proposal>apply original TC resolution</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>37</issue-num>
<title>incorrect URI</title>
<locus>line 1809</locus>
<section>8.1.2 MessageStatus...</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> URI s/b urn:oasis:names:tc:ebxml-msg:service</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>38</issue-num>
<title>duplicate content with 11.1.4</title>
<locus>line 2054...</locus>
<section>11 Multihop...</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> this is essentially duplicate of the content of
section 11.1.4, suggest it be deleted.</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>39</issue-num>
<title>references to ebXML specs</title>
<locus>line 2791...</locus>
<section>Non-Normative References</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> 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).</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>40</issue-num>
<title>restore comment in schema</title>
<locus>line 2245(95)</locus>
<section>Appendix A</section>
<priority>editorial</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> 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.</description>
<proposal>restore comment</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>41</issue-num>
<title>Acknowledgment/RefToMessageId
element should be removed</title>
<locus>line 2281(125)</locus>
<section>Appendix A</section>
<priority>technical</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> 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.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>42</issue-num>
<title>Acknowledgment/From element is not particularly useful</title>
<locus>line 2282(126)</locus>
<section>Appendix A</section>
<priority>technical</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> 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.</description>
<proposal>remove Acknowledment/From element</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>43</issue-num>
<title>Description element here doesn't match the document</title>
<locus>line 2304(148)</locus>
<section>Appendix A</section>
<priority>technical</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> 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.)</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>44</issue-num>
<title>sequenceNumber.type is poorly defined</title>
<locus>line 2282(126)</locus>
<section>Appendix A</section>
<priority>major technical</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> 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.</description>
<proposal>change base type of sequenceNumber.type to nonNegativeInteger</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>45</issue-num>
<title>headerExtension.grp attribute group should be derived by
extension from the bodyExtension.grp</title>
<locus>line 2374(???)</locus>
<section>Appendix A</section>
<priority>editorial</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> Why isn't the headerExtension.grp attribute group derived by
extension from the bodyExtension.grp? That would be a
bit more clear.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>46</issue-num>
<title>Role element is used twice but not defined in a common location</title>
<locus>line 2397(240) & 2403(248)</locus>
<section>Appendix A</section>
<priority>editorial</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> 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).</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>47</issue-num>
<title>Schema element should have an optional
"namespace" attribute</title>
<locus>none</locus>
<section>Appendix A</section>
<priority>technical</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> It was proposed in this <a href='http://lists.oasis-Active.org/archives/ebxml-msg/200111/msg00323.html'>email</a> that the Schema element have an optional
"namespace" attribute. This was raised as a technical
issue but not addressed.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>48</issue-num>
<title>Import correct / latest schema for XML namespace</title>
<locus>line 2169(???)</locus>
<section>Appendix A</section>
<priority>technical</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> should reference <a href='http://www.w3.org/2001/03/xml.xsd'>http://www.w3.org/2001/03/xml.xsd</a> in
the import statement instead of the "hacked" version
currently cited.</description>
<proposal>2169 should reference <a href='http://www.w3.org/2001/03/xml.xsd'>http://www.w3.org/2001/03/xml.xsd</a> in
the import statement instead of the "hacked" version
currently cited.</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>49</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 193</locus>
<section>1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a></originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Wording improvement
</description>
<proposal>s/format type/format or type/</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>50</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 208</locus>
<section>1.1.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a></originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Clarification
</description>
<proposal>s/ebXML SOAP/Basic ebXML SOAP/</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>51</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 211</locus>
<section>1.1.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a></originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Correct reference
</description>
<proposal>s/section 4.1.5/section 4.2/</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>52</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 219</locus>
<section>1.1.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a></originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Correct reference
</description>
<proposal>s/section 8/sections 8 and 9/</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>53</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 221</locus>
<section>1.1.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a></originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Correct reference, note replacement of trailing
comma with period.
</description>
<proposal>s/(section 10.12),/(section 11)./</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>54</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 262</locus>
<section>1.1.4</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a></originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Wording improvement, hard to read implications.
</description>
<proposal>s/and understand//
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>55</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 263</locus>
<section>1.1.4</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a></originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Wording improvement
</description>
<proposal>s/its implications/understand its implications/</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>56</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 263</locus>
<section>1.1.4</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a></originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> 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.
</description>
<proposal>a<p/>
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.</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>57</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 282</locus>
<section>1.2.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a></originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Remove unecessary words that could cloud the picture.
</description>
<proposal>s/security and reliability//</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>58</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 287</locus>
<section>1.2.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a></originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Avoid using ebMS to mean two different things (document and
implementation of the specification).
</description>
<proposal>s/the ebMS/this document/</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>59</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 361</locus>
<section>1.2.3</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a></originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Avoid using ebMS to mean two different things.
</description>
<proposal>s/the ebMS MAY/this document may/</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>60</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 373</locus>
<section>1.2.3</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Make more specific.
</description>
<proposal>s/The CPA is/In [ebCPP], the CPA is/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>61</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 377</locus>
<section>1.2.3</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Minor editorial
</description>
<proposal>s/operations/operation/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>62</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 423</locus>
<section>1.2.4</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> This and other changes attempt to align the figure with the preceding
list.
</description>
<proposal>a<p/>
Delivery Module -- an abstract service interface an MSH uses to interact with the communication protocol layers when sending and receiving messages.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>63</issue-num>
<title>Comment on 1.09 and on</title>
<locus>Figure 2.1</locus>
<section>1.2.4</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Align figure with associated list
</description>
<proposal>s/Authentication, Authorization and Non-Repudiation services/Security Services (authentication, authorization and non-repudiation)/</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>64</issue-num>
<title>Comment on 1.09 and on</title>
<locus>Figure 2.1</locus>
<section>1.2.4</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Align figure with associated list
</description>
<proposal>s/Header Processing/Header Processing and Parsing/</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>65</issue-num>
<title>Comment on 1.09 and on</title>
<locus>Figure 2.1</locus>
<section>1.2.4</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Align figure with associated list
</description>
<proposal>s|Encryption and / or Digital Signatures|Security Services (encryption and / or digital signatures)|</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>66</issue-num>
<title>Comment on 1.09 and on</title>
<locus>Figure 2.1</locus>
<section>1.2.4</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Align figure with associated list
</description>
<proposal>s|Send/Receive Transport mapping and binding|(Send/Receive Transport mapping and binding)|</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>67</issue-num>
<title>Comment on 1.09 and on</title>
<locus>Figure 2.1</locus>
<section>1.2.4</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Align figure with associated list
</description>
<proposal>s|Send/Receive Transport mapping and binding|(Send/Receive Transport mapping and binding)|</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>68</issue-num>
<title>Comment on 1.09 and on</title>
<locus>Figure 2.1</locus>
<section>1.2.4</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Align figure with associated list
</description>
<proposal>Add Reliable Messaging box between "Message Packaging" and
"Delivery Module" because message is packed once but (optionally) sent
multiple times).
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>69</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 462</locus>
<section>2.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Minor editorial
</description>
<proposal>s/logical MIME parts/types of MIME parts/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>70</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 508</locus>
<section>2.1.2</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Clarification
</description>
<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|
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>71</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 592</locus>
<section>2.2.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Very confusing as it stands. We don't need to tell people what the XML Recommendation actually requires.
</description>
<proposal>s/: version='1.0'//
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>72</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 609</locus>
<section>2.3</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Minor editorial
</description>
<proposal>s/attribute/attributes/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>73</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 631</locus>
<section>2.3.2</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Text is necessary to avoid this URI appearing only in non-normative examples.
</description>
<proposal>a <p/>
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.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>74</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 699</locus>
<section>2.3.6</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> 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.<p/>
Don't include first paragraph if we decide to re-insert foreign attributes
anywhere.
</description>
<proposal>a<p/>
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.<p/>
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.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>75</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 717-722</locus>
<section>2.3.9</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Defines SOAP, which shouldn't be necessary in our specification.
</description>
<proposal>delete these lines<p/>
OR [much prefer previous option but at least following change would define
SOAP properly.]<p/>
718 s/REQUIRED SOAP mustUnderstand attribute on SOAP Header extensions/SOAP mustUnderstand attribute/</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>76</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 722</locus>
<section>2.3.9</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Now, describe our requirements over and above SOAP.
</description>
<proposal>a<p/>
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.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>77</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 722</locus>
<section>2.3.10</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> 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).
</description>
<proposal>a<p/>
2.3.10 SOAP actor attribute<p/>
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.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>78</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 722</locus>
<section>2.3.11</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a>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.<p/>
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.
</description>
<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.<p/>
This might remain insufficient to make the intent of this actor clear to
people outside our group.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>79</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 729</locus>
<section>2.3.10</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Clarify actions allows of soap:next actor.
</description>
<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).
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>80</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 732</locus>
<section>2.3.11</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Remove wordiness
</description>
<proposal>s/when used in the context of the//
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>81</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 812-818</locus>
<section>3.1.2</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Paragraphs mixed oddly.
</description>
<proposal>split into 2 paragraphs one sentence later
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>82</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 812,813</locus>
<section>3.1.2</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> 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.
</description>
<proposal>s/the appropriate handling of the conflict is undefined by this
specification/the conflict MUST be reported to the Sending MSH/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>83</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 815</locus>
<section>3.1.2</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Wordiness and options not available according to our decisions.
</description>
<proposal>s/If a receiver chooses to generate an error as a result of a detected inconsistency,/If a Receiving MSH detects an inconsistency,/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>84</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 816,817</locus>
<section>3.1.2</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> This error shouldn't be optional either.
</description>
<proposal>s/If it chooses to generate an error because the CPAId/If the CPAId/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>85</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 831</locus>
<section>3.1.3</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Already mentioned (again) in Chris' message.
</description>
<proposal>s/schema/scheme/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>86</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 838-840</locus>
<section>3.1.4</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> 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.
</description>
<proposal>d
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>87</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 850-851</locus>
<section>3.1.4.1</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> 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.
</description>
<proposal>Remove second sentence.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>88</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 850</locus>
<section>3.1.4.1</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> 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.
</description>
<proposal>Add such an error and describe it in this section. Or, just use
one of the existing errors.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>89</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 872-873</locus>
<section>3.1.6.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> 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.
</description>
<proposal>Remove second sentence.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>90</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 885</locus>
<section>3.1.6.3</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Add reference.
</description>
<proposal>s/messages,/messages (see section 4.2),/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>91</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 886</locus>
<section>3.1.6.3</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Correct reference.
</description>
<proposal>s/section 4.1.5/section 4.2.1.1/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>92</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 887-896</locus>
<section>3.1.6.4</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> TECHNICAL issue: Should describe clock synchronization between MSH
nodes. Is it required? Does it not matter because the durations expected
are large values?
</description>
<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.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>93</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 916,921,924,926</locus>
<section>3.1.9</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> replace "someType" and similar labels with example values, this is an example
</description>
<proposal>change to avoid labeling the value
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>94</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 926</locus>
<section>3.1.9</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> 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?
</description>
<proposal>d
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>95</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 949</locus>
<section>3.2.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Was a correction to previous reference to 2.3.6 material:<p/>
965 s/any namespace-qualified element content belonging to a foreign
namespace// [References to 2.3.6 should be consistent in these lists.]
</description>
<proposal>a<p/>
#wildcard (see section 2.3.6 for details)
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>96</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 969</locus>
<section>3.2.1.1</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> 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.
</description>
<proposal>a <p/>
namespace -- If present, identifies the target namespace of the schema
document found at the above location.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>97</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 979-981</locus>
<section>3.2.2</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> TECHNICAL issue: Error requirements here are overly restrictive. The
problem might be a security failure accessing content elsewhere on the
Internet, for example.
</description>
<proposal>Suggest adding something to the effect of "When no other
defined error applies...".
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>98</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1009</locus>
<section>4.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Keep things together
</description>
<proposal>Move last sentence to end of line 1006 (the previous paragraph)
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>99</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1035</locus>
<section>4.1.2.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Common sentence structure in bullets, explain this case.
</description>
<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./
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>100</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1099</locus>
<section>4.1.3</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Current xsi:schemaLocation doesn't include the namespace identifier
for our schema, resulting in illegal syntax.
recommendations.
</description>
<proposal>a<p/>
http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd
<p/> [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".]
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>101</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1146-1150</locus>
<section>4.1.4.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Introduce things before use.
</description>
<proposal>Move before line 1143, making this the first paragraph and allows
it to introduce use of XML Signature.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>102</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1154-1157</locus>
<section>4.1.4.2</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> 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.
</description>
<proposal>Inclusion of ds:Reference elements should be an option even for
signed acknowledgments.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>103</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1154-1157</locus>
<section>4.1.4.2</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> 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.
</description>
<proposal>Make it more clear any included Reference elements should be
generated over the portions of a message the sender chooses to acknowledge.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>104</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1160</locus>
<section>4.1.4.3</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Minor editorial
</description>
<proposal>s/,//
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>105</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1166</locus>
<section>4.1.4.4</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> CRC is one technology to do what is necessary here, generalise.
</description>
<proposal>s/integrity check CRCs of/digests and comparisons of/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>106</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1169</locus>
<section>4.1.4.5</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Minor editorial
</description>
<proposal>s/document(s)/document/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>107</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1068-1078</locus>
<section>4.1.4.5</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> TECHNICAL issue: It's not clear how XML Encryption will address this
problem except for payloads expressed as XML documents.
</description>
<proposal>If this will work, describe it. Otherwise, reference a future
solution in later versions of ebXML-MSH or another (presently known)
solution.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>108</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1251,1254</locus>
<section>4.2</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> should not pluralize the name of an element even if only part is bold
</description>
<proposal>s/Faults/Fault messages/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>109</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1257</locus>
<section>4.2</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> The section 4.2.1 is missing -- we skip from 4.2 Error Handling Module to 4.2.1.1 Definitions.
</description>
<proposal>We should at least have an intermediate heading or (probably
easier) make 4.2.1.1 be 4.2.1.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>110</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1279</locus>
<section>4.2.3</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> 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 error