[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-msg] Delayed issues
|
My apologies for taking so long converting my issues into XML
form. My list wasn't in as regular a structure as I would have
hoped. Attached, please find an updated version of Chris' list with many
(but not all) of my "Old Comments" issues appended. I think I'm somewhere
in section 7...
This should provide a great place to start on the editorial
discussions.
thanx,
doug
|
<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="ebxml-msg-issues-html.xsl" type="text/xsl"?>
<!DOCTYPE issues SYSTEM "ebxml-msg-issues.dtd" >
<issues update='January 30, 2002'>
<issue>
<issue-num>1</issue-num>
<title>title page</title>
<locus>line 15/16</locus>
<section>title page</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a>the date cited here should be consistent
with its adoption as a TC, not the date that the
document was published to the TC for consideration
(vote). Given that the ballot is closed as of
January 18, then the date cited here cannot be
less than that date.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>2</issue-num>
<title>boilerplate</title>
<locus>line 17/18</locus>
<section>title page</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> either the tense is incorrect (is presented)
or this should be removed. Suggest that the latter be
applied. In the event that the OASIS membership
does approve the TC specification as an OASIS Standard,
then I could see adding something to that effect.
</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>3</issue-num>
<title>title page</title>
<locus>line 20</locus>
<section>title page</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> need to update the URI reference here. Should follow
w3c approach and have a stable URI that people can reference
which will always have the latest draft, in addition to an
explicit URI for the specific reference to a specific draft
for use in external references, etc.</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>4</issue-num>
<title>ebXML participants</title>
<locus>line 23</locus>
<section>ebXML participants</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> I agree that having this section (ebXML Participants)
in addition to the one in the appendix is both gratuitous
and confusing. Suggest that we have but a single list, and
that that list be in an appendix, if anywhere. There is
no reason to cite the participants of the original ebXML
project team.</description>
<proposal>remove section "ebXML Participants"</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>5</issue-num>
<title>ebXML Participants</title>
<locus>line 26</locus>
<section>ebXML participants</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> If the section is preserved (see issue 4), then
s/meeting/meetings/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>6</issue-num>
<title>typo</title>
<locus>line 200</locus>
<section>Introduction</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/sending and receiving/that sends and receives/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>7</issue-num>
<title>typo</title>
<locus>line 208</locus>
<section>Introduction</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/,//</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>8</issue-num>
<title>editorial tweak</title>
<locus>line 214</locus>
<section>Introduction</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/Elements/Features/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>9</issue-num>
<title>editorial tweak</title>
<locus>line 472</locus>
<section>2.1 Packaging Specification</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/the following figure/figure 2.1/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>10</issue-num>
<title>RFC2119 usage</title>
<locus>line 509</locus>
<section>2.1.2 Message Package</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/may/can/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>11</issue-num>
<title>confusion w/r/t conformance</title>
<locus>line 709</locus>
<section>2.3.8 version attribute</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> this is going to lead to all manner of confusion.
For conformance to THIS specification, all of the version
attributes on any SOAP extension elements defined in THIS
specification MUST have a value of "2.0".
An ebXML message MAY contain SOAP header extension elements
that have a value other than "2.0". An implementation
conforming to this specification that receives a message
with ebXML SOAP extensions qualified with a version other
than "2.0" MAY process the message if it recognizes the
version identified and is capable of processing it. It
MUST respond with an error (details TBD) if it does not
recognize the identified version.</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>12</issue-num>
<title>editorial tweak</title>
<locus>line 724</locus>
<section>2.3.10 NextMSH actor URI</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/The /The URI /</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>13</issue-num>
<title>editorial tweak</title>
<locus>line 732</locus>
<section>2.3.11 ToPartyMSH actor URI</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/The /The URI /</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>14</issue-num>
<title>RFC2119 usage/typo</title>
<locus>line 764</locus>
<section>3.1.1 From and To Party elements</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/must/MUST/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>15</issue-num>
<title>RFC2119 usage</title>
<locus>line 784</locus>
<section>3.1.1.2 PartyId element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> use of the term OPTIONAL here may be confusing
given the conformance statement. Suggest that this be
rephrased as follows:
The Role element, if present, ...
(technical/editorial)
Other instances of OPTIONAL where ordinality is meant:<p/>
* 500 (MIME start parameter)
* 1801, 1814 (Signature element in Message Status
Request & Response)
* 1822, 1842 (StatusRequest and StatusResponse
elements; really, the service is OPTIONAL)
* 1905, 1955 (Signature element in Ping & Pong)</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>16</issue-num>
<title>replacement text for Note</title>
<locus>line 788</locus>
<section>3.1.1.2 Role element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> suggested replacement text for the Note:<p/>
Note: Use of a URI for the value of the Role element
is RECOMMENDED. e.g. http://rosettanet.org/roles/buyer</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>17</issue-num>
<title>CPA</title>
<locus>line 810</locus>
<section>3.1.2 CPAId element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> given that we agreed in the f2f that there *was*/*is*
a CPA, this sentence should be removed so as to avoid any
unnecessary confusion.</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>18</issue-num>
<title>typo</title>
<locus>line 831</locus>
<section>3.1.3 ConversationId element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description>s/schema/scheme/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>19</issue-num>
<title>local part of MID?</title>
<locus>line 872</locus>
<section>3.1.6.1 MessageId element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> We thought that an issue had been raised that challenged
the "local part" characterization.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>20</issue-num>
<title>duplicate detection</title>
<locus>line 899</locus>
<section>3.1.7 DuplicateElimination element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> While it may be true that in order to ensure that
duplicates are detected and prevented from being forwarded
to the application, a persistent store is required,
it is not a request by the sender that
the receiver have a persistent store, it is a request by
the sender that the receiver filter duplicate messages
such that the application does not receive them.
This section needs a better description.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>21</issue-num>
<title>duplicate elimination confusion</title>
<locus>line 901</locus>
<section>3.1.8 DuplicateElimination element</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> This too is going to be confusing to the reader.
The semantics of duplicate elimination are such that the
application that is to process the received message need
not concern itself that it might be processing a duplicate
message. The delivery semantics of this element alone might
be either at-most-once or best-effort, but in conjunction
with acknowledgments, retries, etc., can effect delivery
semantics of once-and-only-once.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>22</issue-num>
<title>"if there is a CPA with ..." is a little too vague</title>
<locus>line 903</locus>
<section>3.1.8 DuplicateElimination element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> "if there is a CPA with ..." is a little too vague.
This is related to the issue raised recently on the list[3].
We prefer that we be a bit more specific. Suggested text:<p/>
The DuplicateElimination element MUST NOT be present if
the DeliveryChannel for the message in the CPA identified
by CPAId has a value of "never". The DuplicateElimination
element MUST be present if the DeliveryChannel for the
message in the CPA identified by CPAId has a value of
"always". </description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>23</issue-num>
<title>example issue</title>
<locus>line 914</locus>
<section>3.1.9 MessageHeader example</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> (example) curious that the From party has no
identified Role, but the To party does. Suggest that
both be assigned a role or neither. </description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>24</issue-num>
<title>premature reference to xlink:role</title>
<locus>line 942</locus>
<section>3.2 Manifest element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> this sentence seems premature since xlink:role is
an attribute of Reference element which has not yet been
defined. Suggest moving this sentence to the bullet
defining xlink:role below (after line #961)</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>25</issue-num>
<title>Description element</title>
<locus>line 972, 1321</locus>
<section>3.2.1.2 Description element</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> The Description element defined in section 3.1.8
identifies the purpose of the Description element as
describing the message. The Description element here
is intended to provide for a description of the payload
document identified by the Reference item. The
structure/syntax of the element may be the same, but
the purpose is quite different.<p/>
Suggest that we reference the structure of the description
element, but that we augment the definition here (and
elsewhere throughout the spec) with the specific purpose
of the element in the current context.<p/>
In addition, the definition of the Description element
at times conflicts with the schema (esp sect. 4.2.3.2.6). The
Description element MUST not be empty as it extends
non-empty-string. </description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>26</issue-num>
<title>suggestion to discard note</title>
<locus>line 982</locus>
<section>3.2.2 Manifest validation</section>
<priority>minor technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> Chris previously sent a note suggesting that this
Note be discarded. It isn't at all clear that it adds
any value. Would add to text (or note) in section 3.2.2 that the
xlink:href may be a Content-Location or a Content-ID
as described in section 4.1.3, lines 1084-1089.
If the ds:Reference element may have a URI of this
type and that URI must match the xlink:href of some
"corresponding" eb:Reference element, options must
be similar. </description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>27</issue-num>
<title>RFC2119 usage</title>
<locus>line 1029</locus>
<section>4.1.2.1 Collaboration Protocol Agreement</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/may be/is/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>28</issue-num>
<title>typo</title>
<locus>line 1037</locus>
<section>4.1.3 Signature Generation</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/and //</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>29</issue-num>
<title>editorial tweak</title>
<locus>line 1050</locus>
<section>4.1.3 Signature Generation</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description>s/for the ebXML Message Service//</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>30</issue-num>
<title>RFC2119 MUST semantics for DFN</title>
<locus>line 1434</locus>
<section>7 Reliable Messaging Module</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> This was supposed to have been changed to MUST.</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>31</issue-num>
<title>duplicate eleimination characterization</title>
<locus>line 1436</locus>
<section>7 Reliable Messaging Module</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> The method of duplicate elimination is not achieved
via a persistent store, but is facilitated by same.
The mechanism by which duplicates are detected and
eliminated is via the MessageId. This is likely
to become a source of confusion.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>32</issue-num>
<title>RFC2119 usage</title>
<locus>line 1449</locus>
<section>7.1 Persistent Storage...</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/SHOULD/MUST/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>33</issue-num>
<title>editorial tweak</title>
<locus>line 1459</locus>
<section>7.2 Methods ...</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/structures/extension modules/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>34</issue-num>
<title>error on ack and ack on error issue</title>
<locus>line 1512</locus>
<section>7.3.1.4 AckRequested</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> We agreed that an error message could be sent
reliably. You are only precluded from requesting an
acknowledgment on a message that itself is an acknowledgment
message. </description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>35</issue-num>
<title>typo</title>
<locus>line 1564</locus>
<section>7.3.2.5 [XMLDSIG] Reference</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/This/The/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>36</issue-num>
<title>error on ack</title>
<locus>line 1580</locus>
<section>7.3.2.8 Acknowledgment...</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> We did NOT agree to this at all. We
agreed that an Error message *could* be sent reliably.
Ref <a href='http://lists.oasis-Active.org/archives/ebxml-msg/200201/msg00036.html'>email</a> for discussion.</description>
<proposal>apply original TC resolution</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>37</issue-num>
<title>incorrect URI</title>
<locus>line 1809</locus>
<section>8.1.2 MessageStatus...</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> URI s/b urn:oasis:names:tc:ebxml-msg:service</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>38</issue-num>
<title>duplicate content with 11.1.4</title>
<locus>line 2054...</locus>
<section>11 Multihop...</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> this is essentially duplicate of the content of
section 11.1.4, suggest it be deleted.</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>39</issue-num>
<title>references to ebXML specs</title>
<locus>line 2791...</locus>
<section>Non-Normative References</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> references to ebXML specs should be qualified by
their URI, and as previously cited, the ebRS reference
should probably cite the 2.0 version of their spec(s).</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>40</issue-num>
<title>restore comment in schema</title>
<locus>line 2245(95)</locus>
<section>Appendix A</section>
<priority>editorial</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> Comment from last draft-msg-header-05.xsd had a useful
annotation mentioning the soap:actor element in
SyncReply MUST have the value
http://schemas.xmlsoap.org/soap/actor/next
Suggest restoring that inline documentation.</description>
<proposal>restore comment</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>41</issue-num>
<title>Acknowledgment/RefToMessageId
element should be removed</title>
<locus>line 2281(125)</locus>
<section>Appendix A</section>
<priority>technical</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> Doug raised an issue[1] that the Acknowledgment/RefToMessageId
element should be removed. It remains in the document and
the schema but should be removed. An Acknowledgment element
should be included if and only if the overall message
refers to the original one of interest.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>42</issue-num>
<title>Acknowledgment/From element is not particularly useful</title>
<locus>line 2282(126)</locus>
<section>Appendix A</section>
<priority>technical</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> Doug believes he mentioned this before w.r.t. the document.
The Acknowledgment/From element is not particularly useful
because it provides the Receiving MSH no actionable information.
Since the current hop-to-hop text doesn't require messages
to follow the same routes inbound and outbound, an
AckRequested/From element might be useful -- letting the
receiver know where to send the Acknowledgment in cases
where it must be sent separately. Probably would be better
to remove Acknowledgment/From since it covers only 1 of the 4
values hop-to-hop implementations might want to log.
Other alternative is From and To in both AckRequested and
Acknowledgment.</description>
<proposal>remove Acknowledment/From element</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>43</issue-num>
<title>Description element here doesn't match the document</title>
<locus>line 2304(148)</locus>
<section>Appendix A</section>
<priority>technical</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> Description element here doesn't match the document. We'd
much prefer leaving the schema as is and correcting the
document's poor description of this element and an
"empty content" case. None of the other Description
element occurrences in the text go so far away from
standard practice as section 4.2.3.2.6. (Probably not good
to mention w.r.t. schema at all.)</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>44</issue-num>
<title>sequenceNumber.type is poorly defined</title>
<locus>line 2282(126)</locus>
<section>Appendix A</section>
<priority>major technical</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> sequenceNumber.type is poorly defined. The base type for
the element content must be nonNegativeInteger (not
positiveInteger) to allow the oft-mentioned "0" value.
Even better, should define a type derived from
nonNegativeInteger with a maxExclusive="99999999" attribute
and use that here (guess the attribute can be added in
the element def'n as well). Going even one step better to
avoid leading zeroes and the plus sign (as uselessly required
by the documentation), could use pattern="0|([1-9][0-9]{0,7})",
making the min and max values redundant.</description>
<proposal>change base type of sequenceNumber.type to nonNegativeInteger</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>45</issue-num>
<title>headerExtension.grp attribute group should be derived by
extension from the bodyExtension.grp</title>
<locus>line 2374(???)</locus>
<section>Appendix A</section>
<priority>editorial</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> Why isn't the headerExtension.grp attribute group derived by
extension from the bodyExtension.grp? That would be a
bit more clear.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>46</issue-num>
<title>Role element is used twice but not defined in a common location</title>
<locus>line 2397(240) & 2403(248)</locus>
<section>Appendix A</section>
<priority>editorial</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> Role element is used twice but not defined in a common
location. Suggest defining Role at the top level and
referring to that definition here. These are the only times
<element> appears in the schema with a type attribute but
not at the top level (not defining a global element).</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>47</issue-num>
<title>Schema element should have an optional
"namespace" attribute</title>
<locus>none</locus>
<section>Appendix A</section>
<priority>technical</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> It was proposed in this <a href='http://lists.oasis-Active.org/archives/ebxml-msg/200111/msg00323.html'>email</a> that the Schema element have an optional
"namespace" attribute. This was raised as a technical
issue but not addressed.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>48</issue-num>
<title>Import correct / latest schema for XML namespace</title>
<locus>line 2169(???)</locus>
<section>Appendix A</section>
<priority>technical</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> should reference <a href='http://www.w3.org/2001/03/xml.xsd'>http://www.w3.org/2001/03/xml.xsd</a> in
the import statement instead of the "hacked" version
currently cited.</description>
<proposal>2169 should reference <a href='http://www.w3.org/2001/03/xml.xsd'>http://www.w3.org/2001/03/xml.xsd</a> in
the import statement instead of the "hacked" version
currently cited.</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>49</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 193</locus>
<section>1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a></originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Wording improvement
</description>
<proposal>s/format type/format or type/</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>50</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 208</locus>
<section>1.1.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a></originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Clarification
</description>
<proposal>s/ebXML SOAP/Basic ebXML SOAP/</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>51</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 211</locus>
<section>1.1.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a></originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Correct reference
</description>
<proposal>s/section 4.1.5/section 4.2/</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>52</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 219</locus>
<section>1.1.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a></originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Correct reference
</description>
<proposal>s/section 8/sections 8 and 9/</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>53</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 221</locus>
<section>1.1.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a></originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Correct reference, note replacement of trailing
comma with period.
</description>
<proposal>s/(section 10.12),/(section 11)./</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>54</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 262</locus>
<section>1.1.4</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a></originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Wording improvement, hard to read implications.
</description>
<proposal>s/and understand//
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>55</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 263</locus>
<section>1.1.4</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a></originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Wording improvement
</description>
<proposal>s/its implications/understand its implications/</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>56</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 263</locus>
<section>1.1.4</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a></originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> MINOR TECHNICAL: Section needs words covering inconsistencies between
specification text and our schema. I believe we decided the schema "wins"
but that isn't reflected here without this added paragraph.
</description>
<proposal>a<p/>
The XML Schema definition for the ebXML SOAP extensions may conflict with
the material in the body of this specification. In all such cases, the
schema supersedes the specification.</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>57</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 282</locus>
<section>1.2.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a></originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Remove unecessary words that could cloud the picture.
</description>
<proposal>s/security and reliability//</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>58</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 287</locus>
<section>1.2.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a></originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Avoid using ebMS to mean two different things (document and
implementation of the specification).
</description>
<proposal>s/the ebMS/this document/</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>59</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 361</locus>
<section>1.2.3</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a></originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Avoid using ebMS to mean two different things.
</description>
<proposal>s/the ebMS MAY/this document may/</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>60</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 373</locus>
<section>1.2.3</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Make more specific.
</description>
<proposal>s/The CPA is/In [ebCPP], the CPA is/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>61</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 377</locus>
<section>1.2.3</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Minor editorial
</description>
<proposal>s/operations/operation/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>62</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 423</locus>
<section>1.2.4</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> This and other changes attempt to align the figure with the preceding
list.
</description>
<proposal>a<p/>
Delivery Module -- an abstract service interface an MSH uses to interact with the communication protocol layers when sending and receiving messages.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>63</issue-num>
<title>Comment on 1.09 and on</title>
<locus>Figure 2.1</locus>
<section>1.2.4</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Align figure with associated list
</description>
<proposal>s/Authentication, Authorization and Non-Repudiation services/Security Services (authentication, authorization and non-repudiation)/</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>64</issue-num>
<title>Comment on 1.09 and on</title>
<locus>Figure 2.1</locus>
<section>1.2.4</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Align figure with associated list
</description>
<proposal>s/Header Processing/Header Processing and Parsing/</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>65</issue-num>
<title>Comment on 1.09 and on</title>
<locus>Figure 2.1</locus>
<section>1.2.4</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Align figure with associated list
</description>
<proposal>s|Encryption and / or Digital Signatures|Security Services (encryption and / or digital signatures)|</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>66</issue-num>
<title>Comment on 1.09 and on</title>
<locus>Figure 2.1</locus>
<section>1.2.4</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Align figure with associated list
</description>
<proposal>s|Send/Receive Transport mapping and binding|(Send/Receive Transport mapping and binding)|</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>67</issue-num>
<title>Comment on 1.09 and on</title>
<locus>Figure 2.1</locus>
<section>1.2.4</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Align figure with associated list
</description>
<proposal>s|Send/Receive Transport mapping and binding|(Send/Receive Transport mapping and binding)|</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>68</issue-num>
<title>Comment on 1.09 and on</title>
<locus>Figure 2.1</locus>
<section>1.2.4</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Align figure with associated list
</description>
<proposal>Add Reliable Messaging box between "Message Packaging" and
"Delivery Module" because message is packed once but (optionally) sent
multiple times).
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>69</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 462</locus>
<section>2.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Minor editorial
</description>
<proposal>s/logical MIME parts/types of MIME parts/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>70</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 508</locus>
<section>2.1.2</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Clarification
</description>
<proposal>s|non-multipart messages, which may occur|receipt of a SOAP
message not packaged within a MIME multipart/related container. This
packaging option is defined in the SOAP 1.1 [SOAP] specification. Senders
MAY use this packaging|
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>71</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 592</locus>
<section>2.2.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Very confusing as it stands. We don't need to tell people what the XML Recommendation actually requires.
</description>
<proposal>s/: version='1.0'//
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>72</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 609</locus>
<section>2.3</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Minor editorial
</description>
<proposal>s/attribute/attributes/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>73</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 631</locus>
<section>2.3.2</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Text is necessary to avoid this URI appearing only in non-normative examples.
</description>
<proposal>a <p/>
This schema is available at
http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd
and SHOULD be referenced in a schemaLocation attribute in the SOAP Envelope element.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>74</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 699</locus>
<section>2.3.6</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Spills into a TECHNICAL issue: Our intentions should lean towards
addition of new SOAP extensions rather than extending the ones we've
defined when adding entirely new features.<p/>
Don't include first paragraph if we decide to re-insert foreign attributes
anywhere.
</description>
<proposal>a<p/>
This extension mechanism is an exclusive choice. None of the elements
defined in this specification support foreign namespace-qualified
attributes. The wildcard elements are provided wherever extensions might
be required for private extensions or future expansions to the protocol.<p/>
Note: Extension elements should be included in ebXML SOAP extensions only
when they expand the semantics of that particular element. This mechanism
might be used, for example, to extend the eb:Error element by providing
additional structured information about a problem. Wholly new features
should be implemented using separate SOAP extensions.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>75</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 717-722</locus>
<section>2.3.9</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Defines SOAP, which shouldn't be necessary in our specification.
</description>
<proposal>delete these lines<p/>
OR [much prefer previous option but at least following change would define
SOAP properly.]<p/>
718 s/REQUIRED SOAP mustUnderstand attribute on SOAP Header extensions/SOAP mustUnderstand attribute/</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>76</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 722</locus>
<section>2.3.9</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Now, describe our requirements over and above SOAP.
</description>
<proposal>a<p/>
For all ebXML SOAP Header extensions defined in this specification, the
SOAP mustUnderstand attribute is REQUIRED and MUST have the value '1'. A
compliant MSH MUST parse (but not necessarily support features associated
with) all elements and attributes defined in this document.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>77</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 722</locus>
<section>2.3.10</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Defining a new section introducing the soap:actor attribute with the existing 2.3.10 and 2.3.11 becoming 2.3.10.1 and 2.3.10.2 (subsections). This section does not redefine the SOAP actor attribute (unlike lines 717-722 I'd recommend we delete).
</description>
<proposal>a<p/>
2.3.10 SOAP actor attribute<p/>
All ebXML SOAP Header extensions defined in this specification that may be
handled by an MSH node other than the ultimate recipient of a message allow
inclusion of the SOAP actor attribute. If present, this attribute SHALL
have one of the values defined in the following two subsections or the
SOAP-defined value http://schemas.xmlsoap.org/soap/actor/next.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>78</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 722</locus>
<section>2.3.11</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a>TECHNICAL issue: Current text leaves reader asking "What is the
semantic difference between toPartyMSH and the default SOAP actor? When
would a sending MSH specify toPartyMSH rather than leaving the soap:actor
attribute out?" This is not clear in this document and if I need to check
the archives for the reasoning we're leaving something important out.<p/>
I've been told the actor described in existing section 2.3.11 will
support an intermediate node acting on behalf of the To Party in returning
an Acknowledgment (prior to the ultimate recipient seeing the message).
That's a great use case, handling (for example) trusted store and forward
MSH implementations in the destination's DMZ. If that's the case, we need
to be clear this actor value is specifically for use in the AckRequested
and Acknowledgment elements. I don't think it's useful elsewhere.
</description>
<proposal>Changing the last sentence suggested in issue 77 to read "If
present in the AckRequested or Acknowledgment elements (see sections 7.3.1
and 7.3.2), this attribute SHALL have one of the values defined in the
following two subsections." would work since the other use of soap:actor
(in eb:SyncReply) is very explicit about allowed values.<p/>
This might remain insufficient to make the intent of this actor clear to
people outside our group.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>79</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 729</locus>
<section>2.3.10</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Clarify actions allows of soap:next actor.
</description>
<proposal>a Such an actor MAY ignore SOAP Header extensions targeted to
"urn:oasis:names:tc:ebxml-msg:actor:nextMSH" but not the
"http://schemas.xmlsoap.org/soap/actor/next" actor (which all SOAP nodes,
including an ebXML MSH, MUST adopt).
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>80</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 732</locus>
<section>2.3.11</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Remove wordiness
</description>
<proposal>s/when used in the context of the//
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>81</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 812-818</locus>
<section>3.1.2</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Paragraphs mixed oddly.
</description>
<proposal>split into 2 paragraphs one sentence later
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>82</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 812,813</locus>
<section>3.1.2</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> TECHNICAL: This discussion (including following two issues as well) did not reflect the decision to REQUIRE an error when a message / CPA consistency problem is detected.
</description>
<proposal>s/the appropriate handling of the conflict is undefined by this
specification/the conflict MUST be reported to the Sending MSH/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>83</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 815</locus>
<section>3.1.2</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Wordiness and options not available according to our decisions.
</description>
<proposal>s/If a receiver chooses to generate an error as a result of a detected inconsistency,/If a Receiving MSH detects an inconsistency,/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>84</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 816,817</locus>
<section>3.1.2</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> This error shouldn't be optional either.
</description>
<proposal>s/If it chooses to generate an error because the CPAId/If the CPAId/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>85</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 831</locus>
<section>3.1.3</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Already mentioned (again) in Chris' message.
</description>
<proposal>s/schema/scheme/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>86</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 838-840</locus>
<section>3.1.4</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> This discussion just confuses the issue because of its use of the word "role" without reference to the Role element. If there is a specific element in the CPA or BPSS documents that could be referenced here, fine. Otherwise don't mention it.
</description>
<proposal>d
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>87</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 850-851</locus>
<section>3.1.4.1</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> TECHNICAL: It's not possible (or worthwhile) to determine whether or
not something is a URI except by checking for a colon. Note as well:
Unlike PartyId@type, we don't RECOMMEND that this attribute be a URI.
</description>
<proposal>Remove second sentence.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>88</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 850</locus>
<section>3.1.4.1</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> TECHNICAL issue: How are unrecognised services (those not mentioned in
the BPSS referenced from the CPA for example) handled? Need to define
error handling for that case.
</description>
<proposal>Add such an error and describe it in this section. Or, just use
one of the existing errors.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>89</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 872-873</locus>
<section>3.1.6.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> As Chris has mentioned, the second sentence of this paragraph should
be removed. I mentioned earlier that RFC2822 mentions the local part of
email addresses but doesn't distinguish between the left and right sides of
a message id except with respect to possible generation rules. It never
mentions "local part" when describing message id values.
</description>
<proposal>Remove second sentence.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>90</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 885</locus>
<section>3.1.6.3</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Add reference.
</description>
<proposal>s/messages,/messages (see section 4.2),/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>91</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 886</locus>
<section>3.1.6.3</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Correct reference.
</description>
<proposal>s/section 4.1.5/section 4.2.1.1/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>92</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 887-896</locus>
<section>3.1.6.4</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> TECHNICAL issue: Should describe clock synchronization between MSH
nodes. Is it required? Does it not matter because the durations expected
are large values?
</description>
<proposal>I would prefer explicit mention of synchronization or clock
accuracy as a deployment issue rather than ignoring the issue entirely.
This is the only place in our specification where time values must be
compared.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>93</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 916,921,924,926</locus>
<section>3.1.9</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> replace "someType" and similar labels with example values, this is an example
</description>
<proposal>change to avoid labeling the value
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>94</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 926</locus>
<section>3.1.9</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Ignore comment about this line in issue 93 if you can perform this
deletion. From the service and action values, this is a new order -- what
message is referenced?
</description>
<proposal>d
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>95</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 949</locus>
<section>3.2.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Was a correction to previous reference to 2.3.6 material:<p/>
965 s/any namespace-qualified element content belonging to a foreign
namespace// [References to 2.3.6 should be consistent in these lists.]
</description>
<proposal>a<p/>
#wildcard (see section 2.3.6 for details)
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>96</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 969</locus>
<section>3.2.1.1</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> TECHNICAL issue: For schema references, should allow a "namespace"
attribute. The location attribute in that case would be a preferred
schemaLocation for the described schema. This would also require a small
addition to the ebXML Messaging schema.
</description>
<proposal>a <p/>
namespace -- If present, identifies the target namespace of the schema
document found at the above location.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>97</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 979-981</locus>
<section>3.2.2</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> TECHNICAL issue: Error requirements here are overly restrictive. The
problem might be a security failure accessing content elsewhere on the
Internet, for example.
</description>
<proposal>Suggest adding something to the effect of "When no other
defined error applies...".
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>98</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1009</locus>
<section>4.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Keep things together
</description>
<proposal>Move last sentence to end of line 1006 (the previous paragraph)
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>99</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1035</locus>
<section>4.1.2.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Common sentence structure in bullets, explain this case.
</description>
<proposal>s/payload./payload(s). The MSH takes and active part in
providing these security measures, as part of its generation of the SOAP
message and through the parameters it passes to the underlying
communication protocol./
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>100</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1099</locus>
<section>4.1.3</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Current xsi:schemaLocation doesn't include the namespace identifier
for our schema, resulting in illegal syntax.
recommendations.
</description>
<proposal>a<p/>
http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd
<p/> [Or, even better, the second tuple in this attribute value (after this
addition) should be moved to separate xsi:schemaLocation attributes
on the soap:Header and soap:Body elements. Otherwise, we conflict with our
own "one namespace per such attribute".]
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>101</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1146-1150</locus>
<section>4.1.4.1</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Introduce things before use.
</description>
<proposal>Move before line 1143, making this the first paragraph and allows
it to introduce use of XML Signature.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>102</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1154-1157</locus>
<section>4.1.4.2</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> TECHNICAL issue: This text disallows a receiving MSH returning a
message saying "party B definitely received the message with id XYZ".
Since that party likely has the message stored with party A's signatures,
having to say "party B received the message with id XYZ and these contents"
seems a burden only some relationships will require. It also stretches the
previous definition of a signed message to mean just the inclusion of a
Signature element in the soap:Header.
</description>
<proposal>Inclusion of ds:Reference elements should be an option even for
signed acknowledgments.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>103</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1154-1157</locus>
<section>4.1.4.2</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> TECHNICAL issue: Unlike the Manifest element we're defining, the
dsig:Signature element is not required to reference every payload in a
message. (Line 1084, correctly, says "requiring signing".) The copying
described here is likely insufficient for the "and these contents" claim
you want.
</description>
<proposal>Make it more clear any included Reference elements should be
generated over the portions of a message the sender chooses to acknowledge.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>104</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1160</locus>
<section>4.1.4.3</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Minor editorial
</description>
<proposal>s/,//
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>105</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1166</locus>
<section>4.1.4.4</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> CRC is one technology to do what is necessary here, generalise.
</description>
<proposal>s/integrity check CRCs of/digests and comparisons of/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>106</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1169</locus>
<section>4.1.4.5</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> Minor editorial
</description>
<proposal>s/document(s)/document/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>107</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1068-1078</locus>
<section>4.1.4.5</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> TECHNICAL issue: It's not clear how XML Encryption will address this
problem except for payloads expressed as XML documents.
</description>
<proposal>If this will work, describe it. Otherwise, reference a future
solution in later versions of ebXML-MSH or another (presently known)
solution.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>108</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1251,1254</locus>
<section>4.2</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> should not pluralize the name of an element even if only part is bold
</description>
<proposal>s/Faults/Fault messages/
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>109</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1257</locus>
<section>4.2</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> The section 4.2.1 is missing -- we skip from 4.2 Error Handling Module to 4.2.1.1 Definitions.
</description>
<proposal>We should at least have an intermediate heading or (probably
easier) make 4.2.1.1 be 4.2.1.
</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>110</issue-num>
<title>Comment on 1.09 and on</title>
<locus>line 1279</locus>
<section>4.2.3</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:dougb62@yahoo.com'>Doug Bunting</a>
</originator>
<responsible></responsible>
<description>
<a
href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html'>
[see email, which includes references to November comments]
</a> TECHNICAL issue: I had a suggestion in this section to add an actor
attribute to the ErrorList element. Even though intermediates may never
hear about 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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</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>none</resolution>
</issue>
<maintainer>
<fullname>Christopher Ferris</fullname>
<uri>mailto:chris.ferris@sun.com</uri>
</maintainer>
</issues>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC