The WG decided to remove test T20 from the SOAP Version 1.2
Specification Assertions and Test Collection document [3] in order to
resolve the issue.
This will be reflected in the next editor's copy of the SOAP Version 1.2
Assertion and Test Collection document.

It may be a good idea to mention that there is another possible outcome for
the second of the three cases ([1], omitted parameter), which is that the
receiver may fault [2]. This case is also covered by test XMLP-2
[3] in the Test Collection.

T77 is specifically designed to test assertion 2-complexenc-nil, and has
semantics designed to suit the same (which does require missing
parameter to be responded with a non-fault SOAP response). Given the
high bar set for making changes to PR documents, the WG decided to
resolve the issue by maintaining status quo.

The recently posted proposed recommendation of SOAP Version 1.2
Messaging Framework
http://www.w3.org/TR/soap12-part1/#soapinterminfoset further
restricts the legal content of SOAP messages that what is generally known:
Comment information items MAY appear as children and/or descendants
of the [document element] element information item but not before or
after that element information item.
In other words, SOAP messages cannot contain comments in either the
prolog or epilog of a document. This was inferrable from the previous
December 2002 working draft, but was stated in much less obvious
language.
If I had to guess, I'd say this is an attempt to allow multiple SOAP
messages to be stuffed into a single file or stream with clear
boundaries between them. Whether that's a good idea or not, I don't
think such a major change should be tossed out without further
analysis and debate. This could introduce problems for various tools
such as editors that like to stick a "credit" comment in the prolog
of a document. This spec should go back to last call WD.

The working group considered this issue and decided to close the
issue with no action. The grounds for this decision are as follows:
1. As you observe there is no change here between the CR[3] and
PR[2] specification documents in terms of their position regarding
Comment Information Items in a SOAP message infoset.
2. SOAP messages can still be processed using standard XML parsers.
3. There are any number of other things one could put in an XML
Infoset that would cause that Infoset to be illegal per the SOAP
specification. For example, the [document element] having a [local name]
property with a value other than 'Envelope'.
4. There is no requirement that SOAP messages be creatable/editable
with all existing XML tools.

Example 8a in section 4.1.1 of the Primer is incorrectly described.
The example is
GET /travelcompany.example.org/reservations?code=FT35ZBQ HTTP/1.1
Host: travelcompany.example.org
Accept: text/html, application/soap+xml
The explanatory text is "The HTTP Accept header is used to indicate
the preferred representation of the resource being requested, which
in this example is an "application/soap+xml" media type for
consumption by a machine client, rather than the "text/html" media
type for rendition by a browser client for consumption by a human."
However, there is nothing in Example 8a that indicates that
application/soap+xml is preferable to text/html. The client indicates
that it is willing to accept either one with equal priority (the
default q=1). In order to indicate that application/soap+xml is
preferred the example shoudl either remove text/html from the Accept
header completely or adjust the relative q values of the MIME types
accepted. For example,
GET /travelcompany.example.org/reservations?code=FT35ZBQ HTTP/1.1
Host: travelcompany.example.org
Accept: text/html; q=0.5, application/soap+xml

The XMLP group discussed your comment and has agreed to accept your second suggestion
to include the q value to indicate the preference for the application/soap+xml media type.
This will be reflected in the next editor's copy of the Primer.

In the document SOAP Version 1.2 Part 0: Primer with status of Proposed
Recommendation, I noted the following issue.
In Example 4, the xml declaration is <?xml version='1.0' ?> without any
encoding attribute, therefore the value of encoding defaults to utf-8.
Within the same soap message, an element is found with french characters.
<n:name xmlns:n="http://mycompany.example.com/employees">
Ĺke Jógvan Řyvind
</n:name>
This is incorrect according to the XML 1.0 Recommendation unless the
characters are escaped with the values. According to my knowledge, two
things could be done at this point by modifying Example 4's text:
1.) Add an encoding attribute to the xml declaration
<?xml version='1.0' encoding='ISO-8859-1' ?>
2.) Change the element to
<n:name xmlns:n="http://mycompany.example.com/employees">
&#197;ke J&#243;gvan &#216;yvind
</n:name>
making it a well formed xml document (due to assumption of encoding="utf-8")

You raised an issue against the SOAP 1.2 Part
0 Proposed Recommendation regarding the use of the XML declaration in
examples. After the ensuing e-mail discussion[3] on xml-dist-app the WG
concurs with your conclusion[4] that there is no issue to answer.

Are the following messages semantically equivalent (namespace
declarations omitted for brevity)?
<S:Envelope>
<S:Header></S:Header>
<S:Body><tns:foo/></S:Body>
</S:Envelope>
and
<S:Envelope>
<S:Body><tns:foo/></S:Body>
</S:Envelope>
In other words, if there are no headers, are message processors allowed
to insert/delete an empty Header element? I believe the answer is yes,
as I can't find text that says otherwise.
And what if there are no EII's for the Body, can that be omitted?
<S:Envelope>
<S:Header><tns:foo/></S:Header>
</S:Envelope>
and
<S:Envelope>
</S:Envelope>
This has implications for message normalization and the ability to sign
SOAP messages.

You (indirectly) raised an issue ( classed number 428[1] ) against the
SOAP 1.2 Part 1 Proposed Recommendation[2] regarding whether a SOAP
intermediary can add a <soap:Header/> element to a SOAP message that
does not already have one. After some discussion the WG has decided to
amend the 3rd item in the numbered list[3] as follows:
3. Element information items for additional header blocks MAY be
added to the [children] property of the SOAP Header element information
item as detailed in 2.7.2 SOAP Forwarding Intermediaries. In this case,
a SOAP Header element information item MAY be added, as the first member
of the [children] property of the SOAP Envelope element information item,
if it is not already present.
Prior to taking this decision we solicted input from implementers. All
responses indicated that the above change would NOT impact existing SOAP
1.2 implementations.

4.1.3 states:
"Example 13 <http://www.w3.org/TR/soap12-part0/#Ref477488396111> is the
same as that in Example 9
<http://www.w3.org/TR/soap12-part0/#Ref47748839611> , except that the
Request-URI has been modified to include the reservation code, which
serves to identify the resource ..."
Both examples use the same request URI.

You raised an issue which is a text/example disagreement involving examples 9
and 13 in the SOAP Primer. Thank you for noting this discrepancy. The WG has
resolved this with the following amendments to the Primer.
1. In example 9, replace the first line with:
POST /Reservations HTTP/1.1
2. Rewrite the 1st para following example 9 (>>deletions<<, <<additions>>) thus:
"Example 9 shows an RPC request directed at >>a specific reservation at << the travel
service application. The SOAP message is sent in the body of a HTTP POST method
directed at the URI identifying the >>specific reservation<< <<"Reservations" resource
on the server travelcompany.example.org>>. When using HTTP, the request URI indicates
the resource to which the invocation is "posted". Other than <<requiring that>> it be a
valid URI, SOAP places no formal restriction on the form of the request URI (see [RFC 2396]
for more information on URIs). However, one of the principles of the Web architecture is
that all important resources be identified by URIs. This implies that most well-architected
SOAP services will be embodied as a large number of resources, each with its own URI. Indeed,
many such resources are likely to be created dynamically during the operation of a service,
such as, for instance, the specific travel reservation shown in the example. So, a
well-architected travel service application >>will<< <<should>> have different
URIs for each reservation, and SOAP requests to retrieve or manipulate those reservations
will be directed at their URIs, and not at a single monolithic "reservations" URI, <<as
shown in Example 9>>.<< Example 13 in section 4.1.3 shows the preferred way to address
resources such as a particular travel reservation. Therefore, we defer until section 4.1.3
further discussion of Web architecture compatible SOAP/HTTP usage.>>"
3. Delete the 2nd para following Example 9 (it will be moved and merged into section 4.1.3,
see item 5 below).
4. Rewrite the 1st para **before** Example 13 (>>deletions<<, <<additions>>) thus:
"Example 13 is the same as that in Example 9, except that the <<HTTP>> Request-URI has been
modified to include the reservation code, which serves to identify the resource (the reservation
in question, which is being confirmed and paid for) >>, while the other parameters in the RPC,
such as the creditCard number are ancillary data to be processed by the resource. Note, however,
that all the resource-identifying elements have been retained as in Example 9 in their encoded
form in the SOAP env:Body element<< .
5. Add a **new** paragraph just **after** Example 13 with the following text (modified deleted text
from item 3 above):
"In Example 13, the resource to be manipulated is identified by two things: the first is that it
is a reservation (part of the method name), and the second is the specific instance of a reservation
(which is the value of the parameter code to the method). The remainder of the parameters in the RPC
such as the creditCard number are not resource-identifying, but are ancillary data to be processed
by the resource. It is the recommendation of [SOAP Part2] that resources that may be accessed by
SOAP-based RPCs should, where practical, place any such resource-identifying information as a part
of the URI identifying the target of the RPC. It should be noted, however, that [SOAP Part2] does
not offer any algorithm to do so. Such algorithms may be developed in future. Note, however, that
all the resource-identifying elements have been retained as in Example 9 in their encoded form in
the SOAP env:Body element."

The second paragraph of Section 5.4.8, SOAP mustUnderstand Faults, of
the SOAP Version 1.2 Part 1 PR states:
A SOAP node MAY generate a SOAP fault for any one or more SOAP
header blocks that were not understood in a SOAP message. It is
not a requirement that the fault contain the XML qualified names of
all such SOAP message blocks.
The paragraph following Example 7 in the SOAP Version 1.2 Part 0 PR states:
If there were several mandatory header blocks that were not
understood, then each would be identified by its qname attribute in
a series of such env:NotUnderstood header blocks.
Perhaps 'would' should be 'could', since one env:NotUnderstood is okay
when there's several header blocks that are not understood.

The following issue has been raised (e.g. [1]) on ws-arch: is there one
and only one ultimate receiver, or can there be several ultimate
receivers for the same message?
The issue is that multicast bindings, for example, may be prohibited if
there is only one single ultimate receiver.
Currently, Part 1 specifies there can only be ONE ultimate receiver (THE
ultimate receiver). An earlier version of Part 1 used to allow multiple
receivers (AN ultimate receiver), as per the resolution to issue 103 [2].
It appears that when the resolution to issue 103 was implemented, not
all occurences of "THE" were changes to "AN", and that an (unfortunate)
editorial sanity check later replaced all instances of "AN" to "THE",
instead of the contrary.
We have two options at this stage:
1) Go with whatever is in Part 1 today, considering that we are too late
in the Recommendation process; or
2) Reimplement the resolution to 103 (i.e. s/THE/AN/).
I have a preference for option 2) above and consider that this is an
editorial change only. However, I think we should first investigate
whether this change is likely to (severely) impact current
implementations. I don't think so, but at the same time I don't want to
take the risk of delaying publication.

The working group discussed the issue and decided to close it with no action
partly due to being very late in the process but mainly because there was no
desire amongst the WG to change the status quo.

I noticed that the printing problems linked to the large tables present
in the SOAP 1.2 Part 2 specification where still remaining in the PER
(see [1]). The issue is that as there are tables containing URIs in
several columns, those tables are very large and do not fit on a page
while printing.
Talking about this issue with Yves, he found that this issue had been
solved in a previous edition of the PER (see [2]), but this modification
seems to have been lost somewhere.
Could you change back the table layout to the one in [2] in the future
editions of the specification?

In part 0:
One minor typo in section 1: "[ResRep]specifes" should be "[ResRep]
(specifies"
In part 2:
A minor organizational point. The specification seems to be of two
minds regarding whether MEPs are Features or something sui generis. Part
I asserts that MEPs are Features; however, sections 7.3 and 7.4 (and
following sections) in Part II treats MEPs as something other than
Features. The HTTP binding supports the following Features: 2 MEPs as
specified, web-method and action. At a minimum, 7.4 should say that the
binding MUST support the following "additional" features.

The Working Group decided to close this issue (rec44) with the following
resolution:
(in part 0)
> One minor typo in section 1: "[ResRep]specifes" should be "[ResRep]
> (specifies"
Fixed in the edcopy [1]
(in part 2)
> A minor organizational point. The specification seems to be of two
> minds regarding whether MEPs are Features or something sui generis. Part
> I asserts that MEPs are Features; however, sections 7.3 and 7.4 (and
> following sections) in Part II treats MEPs as something other than
> Features. The HTTP binding supports the following Features: 2 MEPs as
> specified, web-method and action. At a minimum, 7.4 should say that the
> binding MUST support the following "additional" features.
The working group decided to adopt the proposed resolution and the text in
7.4 has been amended with "additional", see the edcopy in [2]