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 & Response) * 1822, 1842 (StatusRequest and StatusResponse elements; really, the service is OPTIONAL) * 1905, 1955 (Signature element in Ping & Pong)</description>
<proposal>make suggested change</proposal>
<resolution>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) & 2403(248)</locus>
<section>Appendix A</section>
<priority>editorial</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href=' mailto:
chris.ferris@sun.com '>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='
http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html '>[see email]</a> Role element is used twice but not defined in a common location. Suggest defining Role at the top level and referring to that definition here. These are the only times <element> appears in the schema with a type attribute but not at the top level (not defining a global element).</description>
<proposal></proposal>
<resolution>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 signatu