OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [ebxml-msg] ebXML-MS rev A


This is what I have so far.  I have gone through the first 144 combined items as submitted by Doug on Jan 31.  I have generally used the rule that if it isn't a fix, don't do it.  We have implementors which have already finished their v2.0 code -- so no functional changes.
 
Nevertheless, I have tried to do the simple edits.  I used the Resolution field to record.  The easy ones are marked in the resolution field as Done (sometimes with comments).  The ones I disagreed with are marked as Disagree (always with comments).  Those I don't know or haven't looked at yet are still marked as None.  I have only marked the Status on those we discussed today and designated as Not Accepted or Deferred.
 
I am still dismayed at the volume of comments.  The vast majority of these are *nice to have* or rehashes of old topics we have already discussed many times.  I see probably a dozen or so which are actual fixes (I haven't read much past 144).  We voted NOT to accept these kinds of changes and we need to follow the vote of the team.  However, there are a small few which we must fix.
 
Please review ALL the marked items since we must now vote on even editorial changes.  Even though I have marked an item as Done, does NOT mean we have to accept it.  If the team decided to throw out all editorial changes and do fixes only, I would not object.
 
Regards,
 
David Fischer
Drummond Group
ebXML-MS Editor.
 
Note:  To see the Change List, save ALL attachments to a single folder (like the desktop) and open the XML.
<?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>done. Date adjusted</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>done.</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>done. Document name inserted</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>Disagree.  Removing v1.0 names would be inappropriate -- there is nothing wrong with having an Acknowledgements section.  Moving to the end would conflict.</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>done</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>Disagree.  It is more correct NOT to use that or which.</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>done.</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>done.  This matches with Part II header.</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>done.  Added figure number in text.</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>Disagree.  Why, does not change anything?</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>done.  Change *THIS* to *this* since this is not a 2119 keyword.</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>done.</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>done.</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>done.</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 &amp; Response)  * 1822, 1842 (StatusRequest and StatusResponse elements; really, the service is OPTIONAL)  * 1905, 1955 (Signature element in Ping &amp; Pong)</description>
  <proposal>make suggested change</proposal>
  <resolution>Disagree.</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>Disagree.  What is the difference?</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>done.  Deleted beginning phrase.</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>done.</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>This has been adjusted several times.  This should be Technical.</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>done.  Change to *check for duplicate messages*</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>done. Changed to *duplicate messages SHOULD be eliminated* Text already says to look at the table for more info.</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>Disagree.  Too big of a change -- need group approval.</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>Disagree.  This clearly shows the OPTIONAL nature of the role element. It certainly would not be wrong to have both or neither but it is not clear why this would be better.</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>done.  Not sure why this is important but it doesn't hurt.</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>done -- maybe.  Deleted sentence about empty element on 1325.</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>Not Accepted</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>Disagree.  This came up and the group agreed to this note.</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>done.</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>done.  Not sure this makes any difference.</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>done.</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>done.</resolution>
</issue>
<issue>
  <issue-num>31</issue-num>
  <title>duplicate elimination 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>Disagree.  Duplicate detection IS accomplished through the use of a persistent store.  MessageID is what is put in the message store.  This sentence is the introduction to the next section and if this change is done then a new transitional sentence, containing persistent store, will have to be inserted.<p/>There is nothing wrong with the sentence as it stands.  This change does not improve the document.</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>done.</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>Disagree.  How does this improve the spec?</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>Deferred</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>Disagree.  More members on the list feel differently.  Need vote.</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>Disagree.  Why?</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>Deferred</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>Disagree.  See issue 34.</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>done.</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>Disagree.</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>done.</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>Disagree.  For some reason, this annotation is causing parser errors among the implementors. Not sure why.  Since this is only a comment, leave it out.</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>Disagree.  We voted for clarifications only, this is a functional change.  Discussion:  Since an Acknowledgment may be put on any returning document, the RefToMessageID in the MessageHeader may not be the same as in the Acknowledgment.  This also allows for *bundling* Acknowledgments -- which might be useful in a high-volume, SMTP instance. All this probably won't happen, but unless we want to mandate that an Acknowledgment must be stand-alone, this element is necessary.</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>Disagree.  Same reasoning as issue 41.  To might be useful in Acknowledgment but that would be a functional change.</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>Don't understand the problem -- looks fine.  Removed comment in 4.2.3.2.6 about may be empty. See issue 25.  This may already be resolved</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>done.  Just the proposal, not the pattern.</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>Disagree.  This is a nice-to-have.  Not a bad suggestion, but this does not clarify or fix anything.</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) &amp; 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 &lt;element> appears in the schema with a type attribute but not at the top level (not defining a global element).</description>
  <proposal></proposal>
  <resolution>Disagree.  Nice-To-Have.  Does not clarify or fix anything.</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>Defer to v3.0</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>Disagree.  This is a functional change.  Not clear if this would be good or not but team voted for *clarifications*.</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>done.</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>Disagree.  Not sure what this adds?  Not sure it is correct?</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>Disagree.  What is Basic ebXML SOAP? We have not defined anything called Basic ebXML anywhere in the spec.</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>done.</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>done</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>done</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>Disagree.  Why?</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>Disagree.  Why? This is tied to issue 54.</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>Disagree. Actually, this is the opposite of correct.  The schema should be non-normative and the spec should be correct. Code is always wrong if it conflicts with the words.</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>Disagree.  Why?  Looks fine as is.</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>Disagree.  Not clear how this makes things better.</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>Disagree, see issue 58.</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>Disagree.  Nice-To-Have.</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>Disagree.  Looks fine as is?</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>Disagree.  No changes to picture or text.  TC has been through this exhastively and this is the product of our discussions.</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>Disagree.  See item 62.</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>Disagree.  See item 62.</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>Disagree.  See item 62.</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>Disagree.  See item 62.</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>Disagree.  See item 62.</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>Disagree.  See item 62.</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>Disagree.  *Logical* is the right word not *types*.</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>Disagree.  Lots of words which don't add anything.</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>done.  This problem is caused because Chris had us delete the example and it still says *described below*. Changed to *described above*.  Not sure what else to say.  This seems so simple that perhaps we should not have this section.</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>done.</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>Disagree.  This is included in all the examples but why do we include it at all?  Why don't we use the NS http://schemas.xmlsoap.org/soap/envelope/?  We did this at first because some implementations were having problems getting to this URL but that seems to be no longer the case.</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>Disagree.  Where did we decided to *lean* toward new SOAP extensions?  When did we decide we could not extend existing elements?  This is not a true statement.  Foreign extensions are allowed on ALL elements.  We used to support foreign attributes on all top-level elements???  Not sure when this was removed???  Not sure there was a vote on this???  What happened???  Replaced anyAttribute on headerExtensions.grp and bodyExtensions.grp.  Not sure allowing foreign attributes is better, but we should at least discuss before making a technical change. </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> Disagree.  What does it mean if we don't REQUIRE mustUnderstand?  All elements already state that mustUnderstand has a value of 1 so this is OK.  This is part of issue 76.  This change would be OK but not the next change.  Since these go together, don't do either.  Throughout the document we use this same sentence structure.  This one should not be different.</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>Disagree.  How does this make things better than before?  This changes nothing and adds nothing.  Only do changes which mean something.</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>Disagree.  This is a functionality change by requiring that the SOAP actor be present.  We have never required the actor and we specifically allowed a default so this actor would not appear except for multi-hop.  Since these actors are only used for multi-hop, why are they even here?</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>Disagree.  Agree with the problem statement - What is the difference between ToPartyMSH and the default SOAP actor?  Resolution would be to remove this actor and use the default SOAP actor.  This is never used in the spec and it is the default thus substantively replacing the SOAP default (Not Good).  To require the actor would be a functionality change. </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>Disagree.  This won't work.  Intermediate, non-ebXML SOAP nodes MUST NOT participate or XMLDsig will fail.  How would a non-MSH intermediary know how to handle the ebXML headers?  An Intermediary which does understand and process ebXML headers would, by definition, be an ebXML MSH.  It is not yet even clear that intermediate ebXML compliant nodes will work.  Why are we worrying about non-ebXML nodes? </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>Disagree.  Why?  Same as previous section.  We agreed to put off multi-hop until next version so there is no reason to worry about these sections since they are not actually used. </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>Disagree.  Tried to make change but didn't look right.  Better as is. </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>done.</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>done.</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>done.</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>Disagree.  What should be done here?  This note was put in to try and clear up some confusion.  Taking it out would add to the confusion, not limit it.</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>Disagree.  Agree that second sentence does not help much - neither does it hurt.  No change.</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>done.  Added sentence above 3.1.6.</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>done.  Not sure this was necessary.</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>Disagree.  Issue below (91) corrects this.</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>done.</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>Disagree.  The team specifically removed mshTimeAccuracy and decided to ignore this issue.</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>Disagree.  This doesn't matter.  Why would a real type be more correct? </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>Disagree.  There could be a previous quote message which is referenced.  Why is this an issue?</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>Disagree.  We fixed the schema to allow for #wildcard elements on all top-level elements but we made an editorial decision NOT to add this all the way through the spec and we say this in 2.3.6.</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>Disagree.  Adding an attribute would be a functional change.  </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>Disagree.  Already says this is implementation decision.</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>done.</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>Disagree.  Don't understand.  What parameters are passed to the underlying communication protocol?  Not clear that any security parameters are passed? </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>Don't understand the problem?  This looks fine?  The xsi:schemaLocation is optional anyway.  </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>done.</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>Disagree.  This has been discussed many times.  A signed Acknowledgment is meaningless without the resulting hash/digest.  This is not a resource problem since this ds:Reference will be identical to the element in the original signed message.  Once the original signature is verified, the original element can simply be copied. </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>Disagree.  Already know what elements signed by looking at original ds:Signature element.  This would only be an issue if the Acknowledgment was signed but the original was not.  We discussed this and decided that in this unusual case, the entire message would be used to create the ds:Reference element in the Acknowledgment. </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>done.</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>done.  Not sure what this adds or corrects.</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>Disagree.  Why?  This looks OK. </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>Disagree.  Agree with the problem description.  The first paragraph of 4.1.4.5 is certainly NOT TRUE.  It is not clear that XML Encryption will work at all.  No change because it is not clear what to do. </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>Disagree.  This is a problem with MSword.  There does not seem to be any way to reference a level 4 header directly after a level 2 header.  This should be 4.2.0.1 but that does not seem to be possible. </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>Defer</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 errors and DFN messages may take other routes back to the originator, the problem is likely reduced by the lack of duplicate elimination at intermediaries.  I'd support adding this attribute in support of store-and-forward intermediaries performing retries to later destinations if someone proposes it again.  I'm simply removing (but logging for later use) my suggestion because it didn't get any notice last time and might induce feature creep.</description>
  <proposal>No change at this time, defer to later version.</proposal>
  <resolution>Disagree.  While it might be possible for a reply to take another path back (although doubtful) an Error to the previous hop MUST take the same path.  This is a functional change.  Defer.</resolution>
</issue>
<issue>
  <issue-num>111</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1281</locus>
  <section>4.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> Wildcard descriptions.</description>
  <proposal>a<p/>#wildcard (see section 2.3.6 for details)</proposal>
  <resolution>Disagree.  We fixed the schema to allow for #wildcard elements on all top-level elements but we made an editorial decision NOT to add this all the way through the spec and we say this in 2.3.6.</resolution>
</issue>
<issue>
  <issue-num>112</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1282</locus>
  <section>4.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> Reduce wordiness</description>
  <proposal>s/reported then/reported,/</proposal>
  <resolution>Disagree.  Either way is right, looks better the way it is. </resolution>
</issue>
<issue>
  <issue-num>113</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1284</locus>
  <section>4.2.3.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/of any of the Error elements/of the grouped Error elements/</proposal>
  <resolution>Disagree.  This change does not add anything. </resolution>
</issue>
<issue>
  <issue-num>114</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1285</locus>
  <section>4.2.3.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 punctuation</description>
  <proposal>s/, otherwise/; otherwise,/</proposal>
  <resolution>done.</resolution>
</issue>
<issue>
  <issue-num>115</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1294</locus>
  <section>4.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> Wildcard descriptions</description>
  <proposal>a<p/>#wildcard (see section 2.3.6 for details)</proposal>
  <resolution>Disagree.  We fixed the schema to allow for #wildcard elements on all top-level elements but we made an editorial decision NOT to add this all the way through the spec and we say this in 2.3.6.</resolution>
</issue>
<issue>
  <issue-num>116</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1295</locus>
  <section>4.2.3.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: As Chris mentioned, the Description element MUST have content if present.</description>
  <proposal>s/The content of the Description element MAY contain error message text.//</proposal>
  <resolution>done.</resolution>
</issue>
<issue>
  <issue-num>117</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1301</locus>
  <section>4.2.3.2.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 our element names.</description>
  <proposal>s/errorCodes/errorCode attribute values/ s/then//</proposal>
  <resolution>done.</resolution>
</issue>
<issue>
  <issue-num>118</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1303</locus>
  <section>4.2.3.2.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 pluralise our element names.</description>
  <proposal>s/errorCodes/errorCode value(s)/</proposal>
  <resolution>done</resolution>
</issue>
<issue>
  <issue-num>119</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1302-1304</locus>
  <section>4.2.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: Our list of codes is comprehensive due to its inclusion of OtherXML and Unknown. How can "legal" additions to the list of error codes be created without violating these restrictions?</description>
  <proposal>Specifically mention the errors OtherXML and Unknown as exceptions to this requirement.</proposal>
  <resolution>Disagree.  This has come up before and the team decided to leave this as is.</resolution>
</issue>
<issue>
  <issue-num>120</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1311</locus>
  <section>4.2.3.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> Current text could be interpreted to mean one Error in a list with Warning severity means the message was processed.  Remove that unintended implication.</description>
  <proposal>s/problem./problem.  (Other Error elements in the list may describe problems preventing further processing.)/</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>121</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1312</locus>
  <section>4.2.3.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> Minor editorial</description>
  <proposal>s/there is/there was/</proposal>
  <resolution>Disagree.  Why?  Either way would be correct. </resolution>
</issue>
<issue>
  <issue-num>122</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1315</locus>
  <section>4.2.3.2.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: Need some text requiring the value of this attribute be a URL.  Otherwise the later discussion doesn't make that much sense.</description>
  <proposal>a The value of this attribute MUST be a URL.</proposal>
  <resolution>Disagree.  Is this true?  Would an XPointer be a URI?  Is this always the case?</resolution>
</issue>
<issue>
  <issue-num>123</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1319-1320</locus>
  <section>4.2.3.2.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> Don't redefine something well-described in another specification.</description>
  <proposal>s/in the format cid:23912480wsr, where the text after the ":" is the value of the MIME part's content-id/using URI scheme "cid"/</proposal>
  <resolution>done.</resolution> </issue>
<issue>
  <issue-num>124</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1318-1320</locus>
  <section>4.2.3.2.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> A previous TECHNICAL issue about these lines has been partially resolved through limiting section 2.1.6 to REQUIRING a SOAP Fault only in the outermost Message Package.  Nonetheless, the ebXML handler is unlikely to be invoked when the payload containers or other MIME packaging is incorrect.</description>
  <proposal>Refer to 2.1.6, saying that errors with locations of this type may be unlikely (depending upon the SOAP implementation in use).</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>125</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1352</locus>
  <section>4.2.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> Make it more clear only an Acknowledgment ends retries.  Of course, Acknowledgment and ErrorList may appear in the same message.</description>
  <proposal>a With the possible exception of retries to the message in error, additional messages in the conversation MUST NOT be sent after receiving any message containing such an ErrorList.</proposal>
  <resolution>Disagree.  This creates a new requirement.  Although ConversationID is in the header, we do not use it for anything (at least not in the core).  This would make a new requirement for monitoring ConversationID.  Comment is not wrong, though.  Needs more thought.  It is not true that only Acknowledgment ends retries, might also be ended by ErrorList or if Retries is exceeded or if TTL is exceeded or if PersistDuration is exceeded (there may be other things as well...).</resolution>
</issue>
<issue>
  <issue-num>126</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1359</locus>
  <section>4.2.4.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> Text allows Error on Error which was not our intent.</description>
  <proposal>s/header SHOULD/header and no ErrorList with highestSeverity set to Error SHOULD/</proposal>
  <resolution>done.  Yes, we have disallowed any response to an Error message.  Section deleted.</resolution>
</issue>
<issue>
  <issue-num>127</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1360</locus>
  <section>4.2.4.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: What does "ignore" mean in the context of HTTP with SyncReply true?</description>
  <proposal>Explain</proposal>
  <resolution>done.  Section deleted.</resolution>
</issue>
<issue>
  <issue-num>128</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1369-1370</locus>
  <section>4.2.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: Unparsable messages will be caught by the SOAP processor underlying most "layered" MSH implementations.  It's not possible for us to specify the action of that SOAP processor.</description>
  <proposal>Reduce requirement level from SHOULD to MAY.</proposal>
  <resolution>done.</resolution>
</issue>
<issue>
  <issue-num>129</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1375</locus>
  <section>4.2.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> Clarify</description>
  <proposal>s/not being sent as a result of processing of an earlier message/being sent on its own, with no payload data/</proposal>
  <resolution>done.  Tried to make this change but result was strange.  Instead changed sentence to *An ErrorList element can also be included in an independent message.*</resolution>
</issue>
<issue>
  <issue-num>130</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1376</locus>
  <section>4.2.4.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: Use specified service and action for any ErrorList sent on its own.  Warning severity won't always mean we have a payload to carry.</description>
  <proposal>s/if the highestSeverity is set to Error,//</proposal>
  <resolution>done.</resolution>
</issue>
<issue>
  <issue-num>131</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1372-1379</locus>
  <section>4.2.4.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: Actually, this section still makes little sense.  I believe an attempt was made to describe the Service and Action when ErrorList is sent on its own.  That may occur regardless of the highestSeverity and the problem is mostly addressed through the two changes above.<p/>In addition, "processing" is used in the first paragraph without context and we still need to remind users that ErrorList with highestSeverity="Error" can't be combined with payload data.</description>
  <proposal>  Something at the end of the first paragraph like "This method MUST NOT be used if the highestSeverity is "Error".  No further processing of the message in error could have occurred in that case." may help.</proposal>
  <resolution>done.</resolution>
</issue>
<issue>
  <issue-num>132</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1380-1404</locus>
  <section>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> Entire section would be better placed as section 4.3.</description>
  <proposal>Move it there</proposal>
  <resolution>done.</resolution>
</issue>
<issue>
  <issue-num>133</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1398</locus>
  <section>5.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> Reduce wordiness</description>
  <proposal>s/has the following attributes/consists of/</proposal>
  <resolution>Disagree.  Don't see the requested text. </resolution>
</issue>
<issue>
  <issue-num>134</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1395</locus>
  <section>5.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> Wildcard descriptions</description>
  <proposal>a<p/>#wildcard (see section 2.3.6 for details)</proposal>
  <resolution>Disagree.  We fixed the schema to allow for #wildcard elements on all top-level elements but we made an editorial decision NOT to add this all the way through the spec and we say this in 2.3.6.</resolution>
</issue>
<issue>
  <issue-num>135</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1400-1401</locus>
  <section>5.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: This seems backwards.  SyncReply s/b allowed if syncReplyMode is none (for the Acknowledgment message to come back synchronously); if syncReplyMode is not none and it's a synchronous communication protocol in use, SyncReply MUST be present.  Further, intermediaries may have no idea about the CPA in use and could easily violate these overly strict restrictions (e.g. an intermediary just prior to the To Party requesting a synchronous hop-to-hop Acknowledgment).</description>
  <proposal>Reduce error constraints as described.</proposal>
  <resolution>Disagree.  If SyncReplyMode is none then SyncReply MUST NOT be present.  This is why we added mshSignalsOnly.  SyncReply does not work with multi-hop RM anyway.  If the next hop responds with an Acknowledgment after the message is sent on then the connection drops and a business response or an Acknowledgment from the end CANNOT be synchronous.</resolution>
</issue>
<issue>
  <issue-num>136</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1380-1404</locus>
  <section>5.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: During the discussion of this addition we agreed to add words about SOAP processors w/o full MSH understanding and their need to forward a like extension.  Those words are missing.  Note: Intermediate MSH nodes MAY forward using a different protocol than the incoming message and are therefore NOT REQUIRED to insert a copy of this element in all cases.</description>
  <proposal>With exception of above note, add words suggested and voted on during an earlier face to face meeting.  I think Chris made the suggestion.</proposal>
  <resolution>Disagree.  This was part of the discussion but not agreed to (are there some minutes to this effect?).  How would an intermediary know whether to insert a SyncReply element anyway?</resolution>
</issue>
<issue>
  <issue-num>137</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1416-1417</locus>
  <section>6.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> Introduce in section 8.2.3</description>
  <proposal>s/except the StatusRequest element.//</proposal>
  <resolution>done.  Changed StatusRequest to Manifest.</resolution>
</issue>
<issue>
  <issue-num>138</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1420</locus>
  <section>6.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> Why is this bullet all alone?</description>
  <proposal>Should be part of previous paragraph after recommended deletions.</proposal>
  <resolution>done.  Removed bullet.</resolution>
</issue>
<issue>
  <issue-num>139</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1422-1423</locus>
  <section>6.1.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: SyncReply is not allowed everywhere.  Issue previously was about lack of description for SyncReply, now it's too loose.</description>
  <proposal> Should say (here or in 5.1) the SyncReply element is not allowed in a synchronous response message.</proposal>
  <resolution>Disagree.  Couldn't a synchronous response message contain a business reply which also needs to be responded to - or could it contain an AckRequested?  This is also opposed to the idea of an Error Message sent reliably (which we do not allow) or a synchronous Error on an Acknowledgment. This could be a severe restriction on optional elements; but, this section is about Core elements only. Restrictions with optional elements are noted in those sections.</resolution>
</issue>
<issue>
  <issue-num>140</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1426</locus>
  <section>7</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> Reliable Messaging isn't defined.</description>
  <proposal>a<p/>For the purposes of this document, "Reliable Messaging" is defined to mean sending a message that both parties will know was received by the To Party's application intact once and only once, detect a permanent failure situation or retry until giving up.<p/>Note: Failure remains an option even when making full use of ebXML Reliable Messaging.  In addition, this addresses duplication only when caused by errant MSH implementations or communication protocols: Applications may send distinct messages containing the same payload and receiving applications may need to handle these duplicates.</proposal>
  <resolution>Disagree.  This is an introduction and we don't need to say everything up front. This is too big a change.</resolution>
</issue>
<issue>
  <issue-num>141</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1429</locus>
  <section>7</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> Point example is specific to intermediaries though protocol is generally flexible (see issue 142).</description>
  <proposal>s/flexible/flexible with respect to intermediaries/</proposal>
  <resolution>Disagree.  This doesn't make any sense?</resolution>
</issue>
<issue>
  <issue-num>142</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1429</locus>
  <section>7</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> Expand on flexibility.</description>
  <proposal>a<p/>The protocol is also flexible with respect to the features implemented by communications protocols, ebXML MSH software and applications.  Options are available controlling MSH implementation of well-defined segments of the overall reliability requirements.  Most of the following discussion assumes all ebXML reliable messaging options are enabled.<p/>Note: This assumption in the text should not prevent use of reliable communication protocols, idempotent application semantics, et cetera instead.  ebXML Reliable Messaging semantics should be considered whenever such alternatives are not available or the MSH implementation is more efficient.<p/></proposal>
  <resolution>Disagree.  The statement is incorrect.  The discussion DOES NOT assume that all ebXML reliable messaging options are enabled.<p/>We also agreed NOT to consider other reliable transfer protocols and just go with ebXML Reliable Messaging, which negates the note.</resolution>
</issue>
<issue>
  <issue-num>143</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1435</locus>
  <section>7</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> Not explained why a message could be received more than once.</description>
  <proposal>s/once/once (due to retries or the nature of the communications protocol in use)/</proposal>
  <resolution>Disagree.  Issue description not correct.  It says in the previous sentence that *a Sending MSH MAY trigger successive retries...*.  Not clear what this adds.</resolution>
</issue>
<issue>
  <issue-num>144</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1436</locus>
  <section>7</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> Better explain what turning duplicate elimination means to receiver.</description>
  <proposal>a Retries initiated by a Sending MSH and duplicates introduced by an unreliable communication protocol MUST be handled by the Receiving MSH or higher application layers at the To Party.</proposal>
  <resolution>Disagree.  Why is this necessary?  ALL retries are handled by the Receiving MSH -- unless there is a Delivery Failure somewhere.  This statement is not wrong but it is not clear what it adds at this point in the document.  This is all discussed later.</resolution>
</issue>
<issue>
  <issue-num>145</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1443</locus>
  <section>7.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> Set a real minimum requirement for reliability.</description>
  <proposal>s/SHOULD/MUST/</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>146</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1455</locus>
  <section>7.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: All of the following information is presently missing which is internally inconsistent.</description>
  <proposal>a<p/>In order to associate an Acknowledgment element with the corresponding application state and to send retries, a Sending MSH SHOULD save the following in persistent storage:<ul><li>MessageId of the sent message</li><li>Timestamp, RetryInterval and remaining Retries (elements and parameters to the MSH), providing support for a queue of messages awaiting retry or application failure notification</li><li>Entire SOAP message for use in later retries</li><li>links to application state for any required notifications</li></ul>The possible notifications from a Sending MSH to the From Party application are:<ul><li>Successful delivery (Sending MSH has received an Acknowledgment element in a message not containing an ErrorList)</li><li>Acknowledged delivery with errors (Sending MSH has received a message containing both Acknowledgment and ErrorList elements; processing MAY have continued at the To Party in this case)</li><li>Timeout (TimeToLive expired or Retries have been exhausted)</li></ul></proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>147</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1473</locus>
  <section>7.3.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> Wildcard descriptions</description>
  <proposal>a<p/>#wildcard (see section 2.3.6 for details)</proposal>
  <resolution>Disagree.  We fixed the schema to allow for #wildcard elements on all top-level elements but we made an editorial decision NOT to add this all the way through the spec and we say this in 2.3.6.</resolution>
</issue>
<issue>
  <issue-num>148</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1500-1502</locus>
  <section>7.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 issue: I previously suggested this case should result in an Error because it was inconsistent with the other Inconsistent errors, resulting in just a Warning.  Now, the text requires Inconsistent/Warning where NotSupported/Error would be appropriate.  It's gotten worse and should be Inconsistent/Error or the combination of that with a NotSupported/Error option.</description>
  <proposal>Change text to use only Error severity.  Probably best to stick with Inconsistent status code.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>149</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1515-1517</locus>
  <section>7.3.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 isn't sensible and is a massive change from 1.0.  Why would an Acknowledgment message be bundled into another message that isn't in response to the message in question?<p/>Issue <a href="#x41">41</a> (in the schema) is directly related to this one.</description>
  <proposal>s/The RefToMessageId element in an Acknowledgment element is used to identify the message being acknowledged by its MessageId.//</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>150</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1524</locus>
  <section>7.3.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> Please refer to issues <a href="#x41">41</a>, <a href="#x149">149</a> and others mentioning those issues for related updates to the schema and specification.</description>
  <proposal>d</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>151</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1526</locus>
  <section>7.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> Wildcard descriptions</description>
  <proposal>a<p/>
#wildcard (see section 2.3.6 for details)</proposal>
  <resolution>Disagree.  We fixed the schema to allow for #wildcard elements on all top-level elements but we made an editorial decision NOT to add this all the way through the spec and we say this in 2.3.6.</resolution>
</issue>
<issue>
  <issue-num>152</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1535-1537</locus>
  <section>7.3.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> Please refer to issues <a href="#x41">41</a>, <a href="#x149">149</a> and others mentioning those issues for related updates to the schema and specification.</description>
  <proposal>d</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>153</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1541</locus>
  <section>7.3.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> Clarify use of From element.  Not necessary if change in issue <a href="#x42">42</a> is accepted.</description>
  <proposal>a This form SHOULD be used for hop-to-hop Acknowledgment messages from intermediate nodes, especially when the message also contains data from other nodes.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>154</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1543</locus>
  <section>7.3.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>  Clarify use of From element.  Not necessary if change in issue <a href="#x42">42</a> is accepted.</description>
  <proposal>a This form SHOULD be used for all end-to-end Acknowledgment messages.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>155</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1554</locus>
  <section>7.3.2.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> Note: This section contains more references than it did before.  It still doesn't refer to 4.1.4.2 but should.  Some of the recent reference additions may be worth removing.</description>
  <proposal>s/derived/derived (as described in section 4.1.4.2)/</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>156</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1557</locus>
  <section>7.3.2.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: Again, I disagree with this requirement because it disallows the To Party MSH acknowledging receipt of a message and signing the acknowledgment without also describing the contents.  The message already has the RefToMessageId element and any disagreements about the contents of that message would be covered through the signing the original party did.  I would prefer to strike this sentence and much of the surrounding discussion.  It's a bit worse now that the text attempts to define "signed Acknowledgment Message" two ways simultaneously (signed Ack either means "it contains both Ack and Signature" or "contains both Ack with Reference list and Signature").<p/>For additional discussion, please refer to issue <a href="#x102">102</a>.</description>
  <proposal>s/element/list/<p/>
This proposal is a minor editorial change to the text.  As mentioned above, I would prefer to strike this sentence and much of the surrounding discussion.  This is a fallback if the larger change is not accepted.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>157</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1570</locus>
  <section>7.3.2.6</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> If issue <a href="#x42">42</a> is accepted, example would no longer be correct.</description>
  <proposal>d</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>158</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1577</locus>
  <section>7.3.2.7</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: I could go either way here (prefer either Action) but we haven't made a choice yet.</description>
  <proposal>a<p/>When an Acknowledgment message and Error message are combined without additional payloads (regardless of the highestSeverity attribute of the included ErrorList element), the service and action described in 4.2.4.3 MUST be used.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>159</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1580</locus>
  <section>7.3.2.8</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> Note TECHNICAL issue already raised about this last sentence and related disussion in issue <a href="#x34">34</a>.  The inability to send a reliable Error (even when a Warning and combined with payload data) in the current text should be resolved by killing this sentence.  This issue was resolved during the last face-to-face and Chris most recently mentioned it.<p/>The only vote that has taken place around the error on acknowledgment issue was acceptance of resolutions for the issue database.  That is clear on this subject.</description>
  <proposal>Remove this sentence.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>160</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1568-1584</locus>
  <section>7.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> This section repeats some of 3.1.7 and adds new information.  The new information belongs better in 3.1.7.  All that should be left here is information about the relation between the CPA flag and the DuplicateElimination element.  At the moment, the semantics of the DuplicateElimination element are described again -- without reference to section 3.1.7.</description>
  <proposal>Factor this information between 7.4.1 and 3.1.7, removing duplications.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>161</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1593</locus>
  <section>7.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> "Ignored" hasn't been defined in this context.  Be more explicit, especially since application layers remain free to eliminate duplicates.</description>
  <proposal>s/duplicate messages to be ignored/the To Party application never to see duplicate messages/</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>162</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1601-1603</locus>
  <section>7.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> This section attempts to re-define an element already described in section 7.3.1 and adds no new information.  Just nuke the section.  At most, mention that some configuration information must be available to the From Party MSH to determine whether or not an acknowledgment may be requested and whether or not it could be signed.</description>
  <proposal>d</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>163</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1613</locus>
  <section>7.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> Minor editorial</description>
  <proposal>s/between retries/between later retries/</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>164</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1621-1622</locus>
  <section>7.4.6</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 equation should describe something under MSH control when sending a message.  Similar syntax to 7.4.5 makes it easier to read.</description>
  <proposal>s/The timestamp for a reliably sent message (found in the message header), plus its PersistDuration (found in the CPA), must be greater than its TimeToLive (found in the message header)./For a reliably delivered message, TimeToLive MUST conform to:<p/>TimeToLive &lt; TimeStamp + PersistDuration<p/>where TimeStamp comes from MessageData and PersistDuration is found in the CPA./</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>165</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1636</locus>
  <section>7.4.7</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> Last error requirement in this section conflicts with "ignore" requirement that's first.  Keep the choices separate and avoid ambiguity.</description>
  <proposal>s/If the value of syncReplyMode is none and a SyncReply element is present,/If the value of syncReplyMode is not none, the communications protocol is synchronous and a SyncReply element is not present in a message,/<p/>[This sentence should be joined with the previous paragraph.]</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>166</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1629-1637</locus>
  <section>7.4.7</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: The current wording disallows sending MSH signals synchronously.  Change in issue <a href="#x164">164</a> also doesn't address problems raised earlier around heterogeneous routes to the destination and intermediaries not being party to the CPA.</description>
  <proposal>Since we're going out of our way to describe CPA semantics in this section, make sure we include mention of the "mshSignals" option in the syncReplyMode parameter.<p/>Heterogeneous routes should be a subject for discussion on the list.  At the least, we should mention that error handling assumes a homgeneous route between From and To parties.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>167</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1655</locus>
  <section>7.5.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> Current words don't mention anything about notification of failures or other application interactions.</description>
  <proposal>a<p/>6. Notify application of delivery success or failure (if requested).</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>168</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1665-1666</locus>
  <section>7.5.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> Remove duplicate instructions.</description>
  <proposal>s/generate an Acknowledgment Message (see section 7.5.3).  Follow/follow/</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>169</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1673-1676</locus>
  <section>7.5.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> Move everything from this paragraph except the first sentence into 7.5.3, assuming that section continues to have some useful content.  This is general information about all Acknowledgment messages generated.  Replace these sentences with ", as described in section 7.5.3".</description>
  <proposal>Update text as described.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>170</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1689-1691</locus>
  <section>7.5.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> Because the RefToMessageId element adds no value to an Acknowledgment element, this paragraph means little.  If anything is necessary, section 7.3.2 should (somewhere) remind people, as is done for Error messages, that the MessageData/RefToMessageId value must be set appropriately.<p/>Please refer to issues <a href="#x41">41</a>, <a href="#x149">149</a> and others mentioning those issues for related updates to the schema and specification.</description>
  <proposal>d</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>171</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1692-1703</locus>
  <section>7.5.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> Most of this section attempts to redefine what's already in 7.3.2. and 7.3.2.7 without adding much value and confusing some issues (e.g. some bullets are generally true while others apply only to stand-alone Ack messages).  Copy what's not already in those sections appropriately and make sure that section is now consistent.  This section (7.5.3) should be left with only a reference to 7.3.2 and the "persisted storage" description from 7.5.2.  Maybe, the last 3 bullets could stay here.</description>
  <proposal>Move text and re-factor 7.3.2, 7.3.2.7 and 7.5.3.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>172</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1725-1737</locus>
  <section>7.5.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> This section should come after what's now 7.5.6, reverse two sections</description>
  <proposal>Move section as described.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>173</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1726</locus>
  <section>7.5.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> Current text requires return of stored acknowledgment for every duplicate, regardless of DuplicateElimination element's presence.  There should be no need for identical acknowledgments or even special handling of duplicate messages without that element.</description>
  <proposal>s/duplicate/duplicate and DuplicateElimination is present/</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>174</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1728</locus>
  <section>7.5.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> Clarify the word "it".</description>
  <proposal>s/it/first that/</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>175</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1729</locus>
  <section>7.5.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> Eliminate "that".</description>
  <proposal>s/that matches/matching/</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>176</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1730</locus>
  <section>7.5.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> Reduce wordiness</description>
  <proposal>s/then/,/</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>177</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1731</locus>
  <section>7.5.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> Clarify text, removing "that".</description>
  <proposal>s/MSH that sent the received message/Sending MSH for the duplicate message/</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>178</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1732</locus>
  <section>7.5.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> Remove unecessary "if".</description>
  <proposal>s/and if/and/</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>179</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1733</locus>
  <section>7.5.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> Reduce wordiness.</description>
  <proposal>s/then/,/ s/that//</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>180</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1734</locus>
  <section>7.5.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> Reduce wordiness.</description>
  <proposal>s/same//</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>181</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1735</locus>
  <section>7.5.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> Reduce wordiness</description>
  <proposal>s/that was//</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>182</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1737</locus>
  <section>7.5.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> Add useful reference.</description>
  <proposal>s/Message/Message (as described in section 7.5.3)/</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>183</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1744</locus>
  <section>7.5.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> Please refer to issues <a href="#x41">41</a>, <a href="#x149">149</a> and others mentioning those issues for related updates to the schema and specification.</description>
  <proposal>s/the same RefToMessageId as/a RefToMessageId value matching the MessageId of/</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>184</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1752-1753</locus>
  <section>7.5.6</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> Note unbalanced parentheses are also fixed by removing this unnecessary text.</description>
  <proposal>s/sent to the sender Party A)//</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>185</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1753</locus>
  <section>7.5.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> TECHNICAL: If the recipient ensures a duplicate is identical, we should say what happens if the check fails.</description>
  <proposal>a<p/>2a) The recipient of a duplicate message MAY confirm the duplicate is indeed identical to the original, allowing for changes introduced by intermediate nodes.  If this is found not to be the case, the receiving MSH SHOULD issue an error with errorCode of Inconsistent and a severity of Error.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>186</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1777</locus>
  <section>8</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> Reword to use "A Message Status Response message" as the subject, matching the previous bullet's style.</description>
  <proposal>Change as described.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>187</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1827</locus>
  <section>8.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> Wildcard descriptions</description>
  <proposal>a<p/>#wildcard (see section 2.3.6 for details)</proposal>
  <resolution>Disagree.  We fixed the schema to allow for #wildcard elements on all top-level elements but we made an editorial decision NOT to add this all the way through the spec and we say this in 2.3.6.</resolution>
</issue>
<issue>
  <issue-num>188</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1849</locus>
  <section>8.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> Wildcard descriptions</description>
  <proposal>a<p/>#wildcard (see section 2.3.6 for details)</proposal>
  <resolution>Disagree.  We fixed the schema to allow for #wildcard elements on all top-level elements but we made an editorial decision NOT to add this all the way through the spec and we say this in 2.3.6.</resolution>
</issue>
<issue>
  <issue-num>189</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1864</locus>
  <section>8.3.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: We had some reason for handling this requester error in the response element rather than using an ErrorList.  Did this have something to do with the possibility of sending multiple StatusRequest elements in the same message?  Either way, we need text describing why this isn't handled using an Error message.</description>
  <proposal>Describe reasoning behind unusual error handling.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>190</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1867-1872</locus>
  <section>8.3.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: This expands the list of possible values from those in MSH 1.0 without explanation.  Hadn't we agreed the additional status values (Processed and Forwarded) are likely to be information the MSH doesn't know and shouldn't tell an outside party?</description>
  <proposal>Restore list of message status values from 1.0 specification.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>191</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1910</locus>
  <section>9.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> Complete the example according to our specification.</description>
  <proposal>s|Boundary"|Boundary"; type="text/xml"; start="gobblelygook"|</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>192</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1913</locus>
  <section>9.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> Complete example according to our specification, related to issue <a href="#x191">191</a>.</description>
  <proposal>a<p/>Content-Id: &lt;gobbledygook&gt;</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>193</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1921</locus>
  <section>9.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 the xsi:schemaLocation for the ebXML MSH namespace to use proper syntax.  This would be a technical issue if it appeared outside an example.</description>
  <proposal>Repeat the string (identically)</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>194</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1967</locus>
  <section>9.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> Correct the xsi:schemaLocation for the ebXML MSH namespace to use proper syntax.  This would be a technical issue if it appeared outside an example.</description>
  <proposal>Repeat the string (identically)</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>195</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 1993-1994</locus>
  <section>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> Duplicate information in adjacent paragraphs.</description>
  <proposal>Remove second sentence.  Information is better expressed in the next paragraph.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>196</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 2006</locus>
  <section>10.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> Wildcard descriptions</description>
  <proposal>a<p/>#wildcard (see section 2.3.6 for details)</proposal>
  <resolution>Disagree.  We fixed the schema to allow for #wildcard elements on all top-level elements but we made an editorial decision NOT to add this all the way through the spec and we say this in 2.3.6.</resolution>
</issue>
<issue>
  <issue-num>197</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 2010</locus>
  <section>10.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: I made a mistake in this suggestion.  The SequenceNumber element is required inside an optional element and therefore is not REQUIRED of all implementations.  Remove word again (sorry).</description>
  <proposal>undo s/SequenceNumber/REQUIRED SequenceNumber/ change previously requested</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>198</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 2485</locus>
  <section>B.2.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> Current xsi:schemaLocation doesn't include the namespace identifier for our schema, resulting in illegal syntax.  Probably, the second tuple in this attribute value (after addition below) should be moved to separate xsi:schemaLocation attributes on the soap:Header and soap:Body elements.  Otherwise, we conflict with our own "one namespace per such attribute" recommendations.</description>
  <proposal>a<p/>
http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>199</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 2536-2547</locus>
  <section>B.2.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: I won't repeat all of the technical discussions of problems in this section.  My memory dims this late in the game but I seem to recall issues with requiring SOAP Fault separately (since the SOAP processor isn't something we're defining) and problems using the Fault element asynchronously in any case (since it provides no context for the error described).</description>
  <proposal>  Remove this requirement.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>200</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 2549-2555</locus>
  <section>B.2.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> I'm not sure this section is as clear as it could be.  It seems David had a different interpretation.</description>
  <proposal> Might need some rewording.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>201</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 2555</locus>
  <section>B.2.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> Don't force SOAP processor to change it's default behavior for the lowly MSH handler.  That is, only the ebXML handler can satisfy this requirement.</description>
  <proposal>s/Post/Post if the message is processed by an ebXML MSH handler/</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>202</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 2622-1624</locus> <section>B.3.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 header is defined only for HTTP communication.</description>
  <proposal>d</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>203</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 2638</locus>
  <section>B.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> As above, in issue <a href="#x202">202</a>.  Editorial because this occurrence is in an example.</description>
  <proposal>d</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>204</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 2656</locus>
  <section>B.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> Correct the xsi:schemaLocation for the ebXML MSH namespace to use proper syntax.</description>
  <proposal> Repeat the string (identically).</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>205</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 2676</locus>
  <section>B.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> Correct the xsi:schemaLocation for the ebXML MSH namespace to use proper syntax.</description>
  <proposal> Repeat the string (identically).</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>206</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 2786,2799,2802-2806</locus>
  <section>References</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> Entire section and all references in the text should consistently use [RFC1234] for references to these documents.  XMLMEDIA, PGP/MIME and S/MIME* all violate this consistency.</description>
  <proposal> Update as described</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>207</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 2744-2766</locus>
  <section>References</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> Sort the RFC entries by their number.</description>
  <proposal> Update as described</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>208</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 2744-2814</locus>
  <section>References</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> Entire section should use a consistent format for the references, order and contain similar information.  For example, references to RFC documents should all include the title of the RFC and (probably, I don't remember the IETF standards) IETF RFC1234.  W3C documents are very inconsistent in this section.</description>
  <proposal> Update as described</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>209</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 2744-2814</locus>
  <section>References</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> For documents available online (such as all ebXML documents but likely excluding the RFC's, letting people head to their favorite RFC source), please include URL values.  These are presently missing from most ebXML documents.</description>
  <proposal> Update as described</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>210</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 2744-2814</locus>
  <section>References</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> All references to W3C documents should consistently include the date in their URL values.</description>
  <proposal> Update as described</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>211</issue-num>
  <title>Comment on 1.09 and on</title>
  <locus>line 2787-2788</locus>
  <section>References</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 should refer to the section of the Unicode Standard that defines UTF-8.  This is an incomplete definition for the term UTF-8.</description>
  <proposal>Update as described</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>212</issue-num>
  <title>Rollup comment on 1.09 and on</title>
  <locus>line 1-2842</locus>
  <section>All</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]</a> I found a fair number of incorrect references to sections in the document.</description>
  <proposal>  Why doesn't this document use links to correct sections so that edits don't mess them up?</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>213</issue-num>
  <title>Rollup comment on 1.09 and on</title>
  <locus>line 1-2842</locus>
  <section>All</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]</a> Issues above suggest(ed) adding references to 2.3.6 (then 2.2.6) where they were missing in the 1.09 document.  The 2.0 document instead contains no references at all to 2.3.6.  Only the schema describes where wildcard element content is allowed.  (The schema does, at my suggestion, allow &lt;any&gt; element content on all top-level SOAP extensions and the Error and Reference elements we define.) Just a placeholder to tie issues <a href="#x95">95</a>, <a href="#x111">111</a>, <a href="#x115">115</a>, <a href="#x134">134</a>, <a href="#x147">147</a>, <a href="#x151">151</a>, <a href="#x187">187</a>, <a href="#x188">188</a> and <a href="#x196">196</a> together.  Treat those as sub-issues.</description>
  <proposal> Restore the "#wildcard" lines from 1.09 and add those mentioned in the listed issues.</proposal>
  <resolution>Disagree.  We fixed the schema to allow for #wildcard elements on all top-level elements but we made an editorial decision NOT to add this all the way through the spec and we say this in 2.3.6.</resolution>
</issue>
<issue>
  <issue-num>214</issue-num>
  <title>The word "then" appears</title>
  <locus>line 1-2842</locus>
  <section>All</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]</a> The word "then" appears often instead of a comma.  The document might be significantly shorter the other way.</description>
  <proposal> Search for word "then" and replace with comma wherever possible.  Some occurrences called out in other submitted issues.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>215</issue-num>
  <title>contradictions between Appendix A</title>
  <locus>line 223</locus>
  <section>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]</a> TECHNICAL: This and following issue are a TECHNICAL change necessary to avoid problems with contradictions between Appendix A and the schema available directly from the web site.</description>
  <proposal>s/normative/non-normative/</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>216</issue-num>
  <title>Avoid contradictions between actual</title>
  <locus>line 224</locus>
  <section>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]</a> TECHNICAL: Avoid contradictions between actual schema and Appendix A.</description>
  <proposal>a<p/>The XML Schema document found at http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd is a normative part of this specification and supersedes the "snapshot" found in Appendix A.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>217</issue-num>
  <title>Section 1.1 is missing.</title>
  <locus>line 228</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]</a> Section 1.1 is missing.</description>
  <proposal> Suggest adding "1.1 Background" or some such.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>218</issue-num>
  <title>Messed up indentation</title>
  <locus>line 618,621</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]</a> I guess it made sense to remove the background highlighting these lines (because it was also used for examples).  Unfortunately, the removal of that attribute messed up the indentation.</description>
  <proposal>Move these lines to the left to line up with other URI values called out in the specification.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>219</issue-num>
  <title>Is something a URI?</title>
  <locus>line 779-781</locus>
  <section>3.1.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]</a> TECHNICAL: It's not possible (or worthwhile) to determine whether or not something is a URI except by checking for a colon.</description>
  <proposal> Remove second sentence.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>220</issue-num>
  <title>Timestamp element precision</title>
  <locus>line 877-880</locus>
  <section>3.1.6.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]</a> TECHNICAL: This section on the Timestamp element doesn't require any particular precision for the value.  All examples in this document are accurate only to seconds, likely not enough for reliable ordering of received messages (among other purposes).  Timestamps generally include at least milliseconds and we should be at least that prescriptive.</description>
  <proposal> Add strong suggestion or requirement (capitalized MUST) at least to use all available (platform-provided) precision in timestamp value.  In examples throughout the document, add 4 digits to right of decimal for every timestamp value.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>221</issue-num>
  <title>Consistent typography</title>
  <locus>line 1049,1053,1065,1068-1072</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]</a> To be consistent with the typographic changes to sections 2.3.1 and 2.3.2, removing the background from non-example material in section 4.1.3 would seem appropriate.  The lines referenced in this issue are the remaining cases of normative material against a grey background.  That background should be removed.</description>
  <proposal> Update as described.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>222</issue-num>
  <title>Unneeded character entity</title>
  <locus>line 1114,1116</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]</a> No reason to use the character entity for quotation marks outside an attribute value.  Just lessens readability of the example.</description>
  <proposal>s/&amp;quot;/""/g [Just want one doublequote - faking out editor]</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>223</issue-num>
  <title>Section 6.1 is missing.</title>
  <locus>line 1407</locus>
  <section>6.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]</a> Section 6.1 is missing.</description>
  <proposal> Suggest making 6.1.1 through 6.1.5 be 6.1 through 6.5.  Chapter 6 has no lower or later sections.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>224</issue-num>
  <title>Default actor introduced but not agreed</title>
  <locus>line 1486-1487</locus>
  <section>7.3.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]</a> TECHNICAL: I suggested adding a default actor option to the AckRequested and Acknowledgment elements.  Later in the discussion, I was convinced by others in the group this wasn't a necessary addition and I withdrew it.  Since the sender doesn't know whether another MSH is authorized to act on behalf of the To Party, toPartyMSH is enough.  The document and schema unfortunately followed my suggestion and not its withdrawal.</description>
  <proposal>s/or by leaving this attribute out.//</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>225</issue-num>
  <title>More on issue <a href="#x224">224</a></title>
  <locus>line 1529-1530</locus>
  <section>7.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]</a> Reasoning as in previous issue.</description>
  <proposal>Remove last sentence in paragraph.</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>226</issue-num>
  <title>Ack on Ack problem</title>
  <locus>line 1713</locus>
  <section>7.5.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]</a> TECHNICAL: We agreed that MSH doesn't support Ack on Ack.  However, that should apply only to stand-alone Ack messages.  Quite reasonable to send Ack and AckR together with a business response, maybe an ErrorList (containing warnings) too.  Improvement may require some text changes earlier in the document as well.</description>
  <proposal>s/Acknowledgment Messages/Acknowledgment Messages sent without payload data/</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>227</issue-num>
  <title>Uselessly repeat namespace, etc.</title>
  <locus>line 1923-1924</locus>
  <section>9.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]</a> These lines uselessly repeat the namespace and location declarations for our schema.  Worse, the schemaLocation attribute does not have the correct syntax.</description>
  <proposal>d</proposal>
  <resolution>none</resolution>
</issue>
<issue>
  <issue-num>228</issue-num>
  <title>Kill Acknowledgment/RefToMessageId</title>
  <locus>line 2093</locus>
  <section>11.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]</a> Please refer to issues <a href="#x41">41</a>, <a href="#x149">149</a> and others mentioning those issues for related updates to the schema and specification.</description>
  <proposal>d</proposal>
  <resolution>none</resolution>
</issue>
  <maintainer>
  <fullname>Christopher Ferris</fullname>
  <uri>mailto:chris.ferris@sun.com</uri></maintainer>
</issues>
 
<?xml version="1.0" ?> 
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

<!--
  Style sheet for converting xmlp-issues.xml into a static HTML
  document
        January 28, 2002 (CBF)
          adapted from XML Protocol WG Issues List XSLT.
        November 6, 2001 (HH)
          Not using the initials thingy anymore.
        October 16, 2001 (HH)
          Added list of maintainer.
        October 3, 2001 (HH)
          Removed closed issues from the summary table.
        October 3, 2001 (HH)
          Added an explanation of the acronyms used.
        September 25, 2001 (HH)
          Added support for em.
	September 18, 2001 (HH)
	  Added a few spaces.
        September 6, 2001 (HH)
          Now referencing xmlp-comments.
        September 6, 2001 (HH)
          Changed order in the summary from alphabetical to:
          Active, Unassigned, Postponed, Closed
          Fixed order of locus to:
          Spec, AM
        August 24, 2001 (HH)
          Added template for <pre>, and removed the one for text()
          which was unnecessary.
        June 20, 2001 (HH)
          Added some colors to make the list clearer
        June 3, 2001 (DCF)
          Added subheading to show xmlp-issues.xml (up)date
        May 30, 2001 (DCF)
          Added support for topic and title fields
        May 24, 2001 (DCF)
          Added summary table, doctype and style statements
        May 23, 2001 (DCF)
          Added support for proposal tag, reworded table text
        May 16, 2001 (DCF)
          Added default sort by issue number
        May 14, 2001 (DCF)
          Initially created

  $Id: xmlp-issues-html.xsl,v 1.18 2001/11/06 10:53:18 hugo Exp $
-->

<xsl:strip-space elements="*"/>
<xsl:output
   method="html"
   encoding="iso-8859-1"
   omit-xml-declaration="yes"
   doctype-public="-//W3C//DTD HTML 4.01 Transitional//EN"
   />

<xsl:template match="/">
  <html>
    <head>
      <title>OASIS ebXML Message Service TC Issues List</title>

      <style type="text/css">
         body {color: black; background: white;}
         .Closed { background-color: #888888; }
      </style>

    </head>
    <body>
    <table><tr><td width="5%" align="center" valign="middle">
    <a href="http://oasis-open.org/">
    <img src="http://oasis-open.org/images/oasis_logo.gif" alt="OASIS" 
    bgcolor="#3c1a57"
    height="46"
    width="131" border="0"/></a>
    </td><td width="95%">
    <a href="http://oasis-open.org/committees/ebxml-msg">OASIS ebXML Messaging TC</a>
    </td></tr></table>

    <h1>OASIS ebXML Messaging TC Issues List</h1>
    
    <h3>Last update: <xsl:value-of select="issues/@update"/></h3>
    
    <p>Issues regarding the <a href="./#drafts">documents produced by
    the OASIS ebXML Messaging TC</a> should be reported to <a
    href="mailto:ebxml-msg@lists.oasis-open.org">ebxml-msg@lists.oasis-open.org</a> (<a
    href="http://lists.oasis-open.org/archives/ebxml-msg/">public
    archives</a>).</p>

    <p>Comments on this list should be sent to the
    <a href="mailto:ebxml-msg@lists.oasis-open.org">ebxml-msg@lists.oasis-open.org</a>
    mailing
    list (<a
    href="http://lists.oasis-open.org/archives/ebxml-msg/">Archives</a>).</p>

	<p></p>

    <ul>
      <li><a href="#summaryList">Summary list of outstanding issues</a></li>
      <li><a href="#detailList">Detailed list of issues</a></li>
      <li><a href="#legend">Legend for detailed list</a></li>
    </ul>
     
    <xsl:apply-templates mode="summary" />
    <xsl:apply-templates mode="detail" />

    <hr/>

	<xsl:apply-templates select="issues/maintainer" />

    </body>
  </html> 
</xsl:template>

<xsl:template match="issues" mode="summary">
  <h2><a name="summaryList"></a>Summary List of Outstanding Issues</h2>
  <table border='1'>
      <tr>
        <th><a href="#id">id</a></th>
        <th><a href="#Status">Status</a></th>
        <th><a href="#Spec">Spec</a></th>
        <th><a href="#Topic">Topic</a></th>
        <th><a href="#Class">Class</a></th>
        <th><a href="#Section">Section</a></th>
        <th><a href="#Title">Title</a></th>
      </tr>
    <xsl:apply-templates select="issue[child::status!='Closed']"
	mode="summary">
      <xsl:sort select="status='Postponed'" />
      <xsl:sort select="status='Unassigned'" />
      <xsl:sort select="status='Active'" />
      <xsl:sort select="topic" order="descending"/>
      <xsl:sort select="priority" />
      <xsl:sort data-type="number" select="issue-num" />
    </xsl:apply-templates>
  </table>
</xsl:template>

<xsl:template match="issue" mode="summary">
      <tr>
        <td>
          <a href="#x{issue-num}">
            <xsl:value-of select="issue-num"/>
          </a>
        </td>
        <td><xsl:value-of select="status"/></td>
        <td><xsl:value-of select="locus"/></td>
        <td><xsl:value-of select="topic"/></td>
        <td><xsl:value-of select="priority"/></td>
        <td><xsl:value-of select="section"/></td>
        <td><xsl:value-of select="title"/></td>
      </tr>
</xsl:template>

<xsl:template match="issues" mode="detail">
   <h2><a name="detailList"></a>Detailed List of Issues</h2>
  <table border='1'>
      <tr>
        <th><a href="#id">id</a></th>
        <th><a href="#Spec">Spec</a></th>
        <th><a href="#Section">Section</a></th>
        <th><a href="#Topic">Topic</a></th>
        <th><a href="#Class">Class</a></th>
        <th><a href="#Status">Status</a></th>
        <th><a href="#Raised by">Raised By</a></th>
        <th><a href="#Owner">Owner</a></th>
      </tr>
    <xsl:apply-templates select="issue" mode="detail">
      <xsl:sort data-type="number" select="issue-num" />
    </xsl:apply-templates>
  </table>
  <h2><a name="legend">Table Legend</a></h2>
   <dl>
   <dt><a name="id">id</a></dt>
   <dd>Issue number</dd>
   <dt><a name="title">Title</a></dt>
   <dd>Short title/name of the issue</dd>
   <dt><a name="Spec">Spec</a></dt>
   <dd>Document referred to in issue (AM = Abstract Model, Spec = XMLP/SOAP Specification</dd>
   <dt><a name="Description">Description</a></dt>
   <dd>Short description of issue, possibly including link to origin of issue</dd>
   <dt><a name="Section">Section</a></dt>
   <dd>Reference to specification section that motivated this issue</dd>
   <dt><a name="Topic">Topic</a></dt>
   <dd>Rough topic categorisation, one of: env(elope), rpc, enc(oding), meta(issue), bind(ing), fault</dd>
   <dt><a name="Class">Class</a></dt>
   <dd>Design or Editorial</dd>
   <dt><a name="Status">Status</a></dt>
   <dd>One of: Unassigned, Active, Closed, Postponed</dd>
   <dt><a name="Proposal">Proposal</a></dt>
   <dd>Current proposal for resolution of issue, possibly including link to further text</dd>
   <dt><a name="Resolution">Resolution</a></dt>
   <dd>Short description of resolution, possibly including link to a more elaborate description</dd>
   <dt><a name="Raised">Raised by</a></dt>
   <dd>Person who raised the issue</dd>
   <dt><a name="Owner">Owner</a></dt>
   <dd>ebXML Messaging TC Member responsible for the issue</dd>
   </dl>
</xsl:template>

<xsl:template match="issue" mode="detail">
                <tbody class="{status}">
      <tr>
        <xsl:apply-templates select="issue-num" mode="detail" />
        <xsl:apply-templates select="locus" mode="detail" />
        <xsl:apply-templates select="section" mode="detail" />
        <xsl:apply-templates select="topic" mode="detail" />
        <xsl:apply-templates select="priority" mode="detail" />
        <xsl:apply-templates select="status" mode="detail" />
        <xsl:apply-templates select="originator" mode="detail" />
        <xsl:apply-templates select="responsible" mode="detail" />
      </tr>
      <tr>
        <xsl:apply-templates select="title" mode="detail" />
      </tr>
      <tr>
        <xsl:apply-templates select="description" mode="detail" />
      </tr>
      <tr>
        <xsl:apply-templates select="proposal" mode="detail" />
      </tr>
      <tr>
        <xsl:apply-templates select="resolution" mode="detail" />
      </tr>
                     </tbody>
</xsl:template>

<xsl:template match="issue-num" mode="detail">
  <td rowspan='5' valign='top'>
    <b><a name="x{.}"><xsl:value-of select="."/></a></b> 
  </td>
</xsl:template>

<xsl:template match="locus" mode="detail">
  <td>
    <xsl:apply-templates />
  </td>
</xsl:template>

<xsl:template match="section" mode="detail">
  <td>
    <xsl:apply-templates />
  </td>
</xsl:template>

<xsl:template match="topic" mode="detail">
  <td>
    <xsl:apply-templates />
  </td>
</xsl:template>

<xsl:template match="priority" mode="detail">
  <td>
    <xsl:apply-templates />
  </td>
</xsl:template>

<xsl:template match="status" mode="detail">
  <td>
    <xsl:apply-templates />
  </td>
</xsl:template>

<xsl:template match="originator" mode="detail">
  <td>
    <xsl:apply-templates />
  </td>
</xsl:template>

<xsl:template match="responsible" mode="detail">
  <td>
    <xsl:apply-templates />
  </td>
</xsl:template>

<xsl:template match="title" mode="detail">
  <td colspan='7'>
    <b>Title:</b>
    <xsl:text> </xsl:text>
    <xsl:apply-templates />
  </td>
</xsl:template>

<xsl:template match="description" mode="detail">
  <td colspan='7'>
    <b>Description:</b>
    <xsl:text> </xsl:text>
    <xsl:apply-templates />
  </td>
</xsl:template>

<xsl:template match="proposal" mode="detail">
  <td colspan='7'>
    <b>Proposal:</b>
    <xsl:text> </xsl:text>
    <xsl:apply-templates />
  </td>
</xsl:template>

<xsl:template match="resolution" mode="detail">
  <td colspan='7'>
    <b>Resolution:</b>
    <xsl:text> </xsl:text>
    <xsl:apply-templates />
  </td>
</xsl:template>

<!-- Sign the document -->

  <xsl:template match="maintainer">
    <address>
      <small>
	Maintained by <a href="{uri}"><xsl:value-of select="fullname"/>.</a>
      </small>
    </address>
  </xsl:template>

<!-- HTML like stuff -->

<xsl:template match="a[@href]">
    <a>
      <xsl:attribute name="href">
        <xsl:value-of select="@href"/>
      </xsl:attribute>
      <xsl:apply-templates />
    </a>
</xsl:template>

<xsl:template match="a[@name]">
    <a>
      <xsl:attribute name="name">
        <xsl:value-of select="@name"/>
      </xsl:attribute>
      <xsl:apply-templates />
    </a>
</xsl:template>

<xsl:template match="pre">
  <pre>
    <xsl:apply-templates />
  </pre>
</xsl:template>

<xsl:template match="p">
  <p>
    <xsl:apply-templates />
  </p>
</xsl:template>

<xsl:template match="em">
  <em>
    <xsl:apply-templates />
  </em>
</xsl:template>

<xsl:template match="ul">
  <ul>
    <xsl:for-each select="li">
      <li><xsl:apply-templates /></li>
    </xsl:for-each>
  </ul>
</xsl:template>

</xsl:stylesheet>

ebxml-msg-issues.dtd

ebMS_v2_0rev_a.zip



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC