XML Protocol WG Last Call Issues List

Although the WG agreed to the s/MUST/MAY/ resolution for
the rpc:ProcedureNotFound fault subcode as described in [0],
subsequent discussion on this thread suggested that there
may be support for removal of the rpc:ProcedureNotFound
fault subcode and the establishment of a more generalized
fault subcode that would apply in all cases, not just RPC.

During the XMLP Telcon on 4th July 2002, to close the Issue record [1]
without modification to the specifications  on the grounds that:

a) the current solution is not broken and 
b) does not prohibit the definition of a more generic fault subcodes by others.

Last week at WWW2002, Rohit Khare mentioned something that I believe
demonstrates why a RFC 822/2822 binding is not a protocol binding.

During one of our Developers Day protocols panels, he suggested that
the behaviour of the "Bcc" header depended upon the semantics with which
the message was transferred.  For example, if a message that was
constructed with this SMTP binding were transferred with HTTP (a
perfectly valid thing, since HTTP also uses RFC 822), then the Bcc
header would be passed through, rather than being treated as hop-by-hop.
The processing of Bcc in the expected way *requires* that it and the
message be tranferred with email semantics.  The only way that this can
currently be done, since there exists no abstract description of what an
email binding entails, is to bind the message to an email transfer
protocol.  I don't particularly care which one is used, though I believe
SMTP is the only widely deployed standardized one.

    The XMLP WG has decided to close issue 207 with no further
    action, considering the Email binding is fine as is, and you were
    the only proponent for that call and said you could live with it.
    

> Section 5, Section 5.2.1, Section 5.3.1:
> Clarify that whitespace IS (potentially) significant in Header and
> Body blocks.  Changes are needed at the very end of section 5.0.
> Also, 5.2.1 and 5.3.1 should be brought in line with the conventions
> established for 5.4.5.1, etc., which talk about character children and
> whitespace. 
> +1, but I think that this may need some discussion.
I think the last paragraph of 5.0 is OK as it says "Unless otherwise 
indicated...". I've added a bullet to 5.2.1 and 5.3.1 noting that 
whitespace is significant.
 
Question: Is whitespace within the Body significant or only within 
children of the body ? At the moment we only state the latter.

The text of the LC WD is has improved clarity regarding 
the significance of whitespace.

The WG will add an extra bullet, saying whitespaces
is insignificant except where specified otherwise.

The WG decided this is an editorial issue. 

[Aside: The record is does not say where this bullet will be added, but I
believe it be in Part 1 Section 5.0]

> Section 5.1.1:
> The encodingStyle attribute SHOULD NOT appear on the SOAP
> Envelope [reference to 5.1], SOAP Body [reference to 5.3] or SOAP
> Header [reference to 5.2] element information items.
Not sure whether this should be a MUST because of the scoping rules for encodingStyle ?

    The XMLP WG has decided to close issue 209 by changing the SHOULD
    to a MUST, in order to bring the text in agreement with the
    schema. It considers this issue is editorial in nature.

Section 5.2.1 (and 5.3.1):
(Don't we allow arbitrary attributes on header blocks?  This may
need to be a last call issue.  Still, I'm curious whether we ever
intended to rule these out?  The equivalent issue exists for Body
child elements, IMO.)
 <original>
Each SOAP header block element information item:

 * MUST have a [namespace name] property which has a value, that
   is, be namespace qualified.

 * MAY have an encodingStyle attribute information item in its
   [attributes] property.

 * MAY have an role attribute information item in its [attributes]
   property.

 * MAY have a mustUnderstand attribute information item in its
   [attributes] property.
 </original>

 <suggested>
 Each SOAP header block element information item:

 * MUST have a [namespace name] property which has a value, that
   is, be namespace qualified.

 ** May have zero or more attribute information items.  Among
   these MAY be any or all of the following, which have special
  significance for SOAP processing:
      - encodingStyle attribute information item
      - role attribute information item
      - mustUnderstand attribute information item
 </suggested>

The XMLP WG has decided to close issue 210 by accepting your text.  The
change is as follows:

<newText>
Each SOAP header block element information item:

MUST have a [namespace name] property which has a value, that is, MUST be
namespace qualified.

MAY have any number of character information item children.  Child character
information items whose character code is amongst the whitespace characters
as defined by [XML 1.0] are considered significant.

MAY have zero or more attribute information items in its [attributes]
property.  Among these MAY be any or all of the following, which have
special significance for SOAP processing: 
 - encodingStyle attribute information item (see 5.1.1 SOAP encodingStyle
 Attribute).
 - role attribute information item (see 5.2.2 SOAP role Attribute).
 - mustUnderstand attribute information item (see 5.2.3 SOAP mustUnderstand
 Attribute).
</newText>

 Section 1.4 (and 3.1):
 "SOAP feature: An abstract piece of functionality..." (what is an
 abstract piece of functionality?...same phrase appears in 3.1)

The XMLP WG has decided to close issue 211 with the following editorial
change:

Section 1.4 (and 3.1):

"SOAP feature: An abstract piece of functionality..."

was changed to:

"SOAP feature: An extension of the SOAP messaging framework...".

 Section 3.1:
 (AMBANT (the word "it") and generally a bit awkward.)
 <original>
 While the SOAP Protocol Binding Framework provides for the possibility
 that such features may be expressed outside the SOAP envelope, it does
 not define a specific architecture for the processing or error
 handling of these externally expressed features by a SOAP
 intermediary. 
 </original>

 <suggested>
 Although the SOAP Protocol Binding Framework allows end-to-end
 features to be expressed outside the SOAP envelope, no standard
 mechanism is provided for the processing by intermediaries of the
 resulting messages.
 </suggested>

The XMLP WG had decided to close action 212 by incorporating your
suggested change. It considers this issue is editorial in
nature.

 Section 3.3: relationship to section 3.1.1 is awkward.  Both
 establish special rules for MEPs.  Suggest that all description
 of special rules for MEPs be in one place or the other.

The XMLP WG has decided to close issue 213 with the following editorial
change:

Moved MEP specific rules to section 3.3 (dropping from 3.1.1).

 Section 5.2.3:
 (the final reference to "false or 0" seems to violate our style
 guideline, I.e.  that we never talk about multiple lexical forms,
 unless it matters.  In the first sentence it does matter, in the
 2nd it doesn't.  Still, I'm not sure I'd make that part of the
 change.)
 <original>
 If relaying the message, a SOAP intermediary MAY substitute
 "true" for the value "1", or "false" for "0". The SOAP
 mustUnderstand attribute information item may be omitted if its
 value would have been "false" or "0".
 </original>

 <suggested notSureWeShouldChange="true">
 If relaying the message, a SOAP intermediary MAY substitute
 "true" for the value "1", or "false" for "0". The SOAP
 mustUnderstand attribute information item may be omitted from the
 relayed message if its value would have been "false".
 </suggested>

The XMLP WG has decided to close issue 214 with the following
resolution:

In Section 5.2.3, the final reference to "false or 0" violated our style
guideline (only referring to multiple lexical values if it really matters).
Your suggested text change was made (removing 'or "0"').  In addition, a
similar entry two paragraphs above was made.
    

> Section 5.4.4:
> What do we mean "similar"?  They are as different as the
> definition of a variable and a reference to that variable.
> <original>
> The Role element information item is similar to the SOAP role
> attribute information item (see 5.2.2 SOAP role Attribute),
> except that the value of the Role element information item
> identifies the role the node was playing at the point the fault
> occurred. </original>
> <suggested>
> The Role element information identifies a role the node was
> playing at the point the fault occurred.  This MUST BE one of the
> roles assumed by the node during processing of the message [ref
> to section 2.6].
> </suggested>

 Partly done. I removed the "is similar to the SOAP role
 attribute information item (see 5.2.2 SOAP role Attribute),
 except that the value of the Role element information item". I did not
 add the sentence "This MUST BE one of the roles assumed by the node
 during processing of the message [ref to section 2.6]." as this seems to
 go beyond the bounds of an editorial change.

The XMLP WG has decided to close issue 215 with the following
resolution:

Your text for 5.4.4 has been accepted with a slight modification.

The first sentence of the section beginning "The Role element
information..." was changed to:

"The value of the Role element information item identifies a role the node
was playing at the point the fault occurred. This MUST be one of the roles
assumed by the node during processing of the message (see 2.2 SOAP Roles and
SOAP Nodes)." 

Second sentence is actually at the end of the section and reads: 

"The value of the Role element information item MUST be one of the roles
assumed by the node during processing of the message (see 2.2 SOAP Roles and
SOAP Nodes)."

 Section 7:
 I find this section to generally be in need of editing to tighten
 the wording and to make the messages clearer.  I would still
 prefer to put it in an appendix, as almost none of the rules in
 it are testable or can be directly used to distinguish a conforming
 from a non-conforming implementation.

    The WG discussed this issue on 10th July and decided to close it without 
    incorporating any of the suggested revisions.
    

 (Section 2.1 SOAP Nodes)
A SOAP node MUST be identified by a URI.
Wonder if we should say "unambigously identified". eg.  http://.../next
does not unambiguously identify a SOAP node (some context for interpretation
is required in addition to a URI in order to identify a SOAP node from this
URI).
Can the  URI be relative? I think not! Should we say "absolute URI"?

Good points. Another question: why 'MUST' a SOAP node be identified by a
URI ? Roles are identified by a URI, but why must a SOAP node be ?
Should this be a 'MAY' ?

During the XMLP-WG telcon on 17th July 2002 the XMLP-WG resolved to close
issue 217 as proposed by Marc Hadley in [2]:

  Proposal
  ========

I think Stuart pretty much nailed it above. Identifying a node is 
optional, but when a node *is* identified a URI is used.

Suggest we change "A SOAP node MUST be identified by a URI." to "A 
SOAP node is identified by an unambiguous URI".

 (Section 2.7.2 Active Intermediaries)

One mechanism by which an active intermediary can describe the
modifications performed on a message is by inserting header
blocks into the outbound SOAP message. These header blocks
can inform downstream SOAP nodes acting in roles whose correct
operation depends on receiving such notification. In this case,
the semantics of such inserted header blocks should also call
for either the same or other header blocks to be (re)inserted
at subsequent intermediaries as necessary to ensure that the
message can be safely processed by nodes yet further downstream.
For example, if a message with header blocks removed for encryption
passes through a second intermediary (without the original header
blocks being decrypted and reconstructed), then indication that
the encryption has occurred must be retained in the second
relayed message.

Personnally I'd delete this paragraph... it feels a little arm-wavey. It
certainly specifies nothing and is largely tutorial.. if that.

At its telcon today (after you left), the XMLP WG decided to close Last
Call issue #218 [1] by removing the paragraph to which you objected to the
Primer.
    

 (Section 3.1 SOAP Features)
 3rd Paragraph - last sentence:
 A feature expressed as SOAP headers is known as a SOAP module,
 and each module should be specified according to the rules
 in 3.2 SOAP Modules.

 Personnally, I would like a really strong model of features, properties,
 modules, bindings and expressions.  "A feature expressed as SOAP headers is
 known as a SOAP module..." just does not do it for me.

 Features are abstract things (given the examples). Modules are specifications
 of concrete behaviours and message components that realise the functionality
 of one (or more) features. In the case of modules the syntactic message
 components (feature related properties (state) ?) are expressed within SOAP
 headers. But... SOAP modules are not, not, not a kind of feature (that's
 what the quoted sentence says if you drop out the qualification).

 On the whole I don't think we articulate the concepts of features,
 properties, modules and bindings with any rigourous clarity - we need to do
 that.

On July 31st, the WG agreed to close issue #219 as follows:

Replace the sentence in section 3.1 beginning with "A feature expressed as 
SOAP headers..." with the following:

"When a feature is expressed this way, the combined syntax and semantics of 
such headers are known as a SOAP Module, and are specified according to the 
rules in section 3.2 SOAP Modules."

Then replace the first two sentences of 3.2 with:

"The term 'SOAP Module' refers to the set of syntax and semantics associated 
with implementing a particular feature (link to 3.1) as SOAP headers.  
A Module is described in a Module Specification, which adheres to the 
following rules. It:"

Further, we agreed to insert the following as the new second rule in 
section 3.2, moving the other rules down one:

"2. MUST, *if* the Module implements a Feature which has already been defined 
elsewhere, clearly refer to said Feature's URI.  Note that a Module may EITHER 
explicitly refer to a separate Feature in this way OR may implicitly define 
a Feature simply by describing the semantics of the Module."

(note that this last bit relies on a Feature having a URI, which is dealt 
with by the resolution of issue #230 [2])

 (3.1 SOAP Features)
 Last paragraph:
 A binding specification that expresses such features external to
 the SOAP envelope should define its own processing rules to which
 a SOAP node is expected to conform (for example, describing what
 information must be passed along with the SOAP message as it
 leaves the intermediary).

 seems contradictory with (from 4. SOAP protocol binding framework):

 A binding does not provide a separate processing model and does
 not constitute a SOAP node by itself. Rather a SOAP binding is
 an integral part of a SOAP node (see 2. SOAP Processing Model).

 The first says that a binding does provide a model for processing features
 external to the envelope. The second says more globally that a binding does
 not provide a separate processing model.

 If there are subtle distinctions here then we MUST find ways to remove the
 subtelty from the language. IMO a spec has *no* business being subtle... it
 only leads to trouble later.

    At the f2f the WG decided to close issue 220 you raised by changing
    the text in Part 1, section 3.1, last paragraph (based on the email
    exchange between you and Noah [3]):
    
    <originalText>
    A binding specification that expresses such features external to the SOAP
    envelope needs to define its own processing rules to which a SOAP node is
    expected to conform (for example, describing what information is passed
    along with the SOAP message as it leaves the intermediary). It is
    recommended that, where practical, end-to-end features be expressed as SOAP
    header blocks, so that the rules defined by the SOAP Processing Model can
    be employed.
    </originalText>
    
    <newText>
    A binding specification that expresses such features external to the SOAP
    envelope needs to define its own processing rules for those externally
    expressed features.  A SOAP node is expected to conform to these processing
    rules (for example, describing what information is passed along with the
    SOAP message as it leaves the intermediary). The processing of SOAP
    envelopes in accordance with the 2.  SOAP Processing Model MUST NOT be
    overridden by binding specifications.
    </newText>
    

 (Section 5 SOAP Message Construct)

 3rd paragraph: We are not clear about whether intermediaries MUST, SHOULD, MAY,
 SHOULD NOT or MUST NOT forward PIs - only that a message SHOULD NOT contain
 them.

At the SOAP WG Telcon of September 4th, the WG agreed to close issue 221 by
adopting the text:

"Except in the special case of intermediaries (see below), envelopes 
transmitted by SOAP senders MUST NOT contain PIs.

Receivers (including intermediaries)  receiving an envelope with a PI 
SHOULD fault with a sender fault.  However, in the case where performance 
considerations make it impractical for an intermediary to detect PIs in a 
message to be relayed, such intermediaries MAY leave the PIs unchanged in 
the relayed message." 

 (Section 5.1.1 SOAP encodingStyle Attribute)
 1st paragraph:
 SOAP defines an optional encodingStyle attribute information item which
 indicates the encoding rules used to serialize a SOAP message.
 
 This sentence suggest that a single instance of the attribute applies to the
 whole message... which I believe is not the case. I'm also not sure how we
 resolved whether the attribute can be carried on the envelope itself or not.

It was noted during the WG call, July 10, that the latest Last Call
specification text clarifies the scope of the encodingStyle attribute as
stated below:

    First sentence of 5.1.1 now reads:
    The encodingStyle attribute information item indicates the encoding rules
    used to serialize parts of a SOAP message.
    Additionally, later in the section one finds:
     The scope of the encodingStyle attribute information item is that of its
     owner element information item and that element information item's
     descendants, unless a descendant itself carries such an attribute
     information item. If no encodingStyle attribute information item is in scope
     for a particular element information item or the value of such an attribute
     information item is the zero-length URI ("") then no claims are made
     regarding the encoding style of that element information item and its
     descendants.
     

Tables 9 [1] and 16 [2] of the latest editors drafts of SOAP 1.2 contain entries such as:

----------------+--------------------------------------------------------
 Additional     | Generated in accordance with the rules for the binding
                | specific expression of any optional features 
 Headers        | in use for this message exchange
----------------+--------------------------------------------------------

IBM is pleased to see these entries but requests that consideration be
given to adding a clarification during last call.

Specifically, IBM requests that a note be added to make clear that features
such as http Content-Encoding [3] may be enabled through use of the
features described in the table entry above.   IBM would like for
content-encoding to be supported when using SOAP over HTTP, and we believe
that the current draft does support it.  We are only requesting that the
spec be made a bit clearer on this point.  Thank you very much.

In response to issue, we are augmenting the text in Value of the Addt'l Headers row 
in Tables 15 [2] and 22 [3] in Part 2 of the SOAP spec. 

"Generated in accordance with the rules for the binding specific expression
of any optional features in use for this message exchange. For example, a
content-encoding header [4] may be used to express an optional Compression
feature."

From [2], this should be added to section 7.4.1.2 [4]:

Table 11 refers to some but not all of the existing HTTP/1.1 status
codes (see RFC 2616). In addition to these status codes, HTTP provides
an open-ended mechanism for supporting status codes defined by HTTP
extensions (see RFC 2817 for a registration mechanism for new status
codes). HTTP status codes are divided into status code classes as
described in RFC 2616, section 6.1.1. The SOAP HTTP binding follows the
rules of any HTTP application which means that an implementation of the
SOAP HTTP binding must understand the class of any status code, as
indicated by the first digit, and treat any unrecognized response as
being equivalent to the x00 status code of that class, with the
exception that an unrecognized response must not be cached.

During the XMLP telcon on July 10th, the XMLP working group accepted Henrik
Nielsen's suggested text listed in LC-Issue #224 [1].  The editors have
taken an action item to add this to section 7.5.1.2 "Requesting" near Table
#17, effectively closing this issue.
    

From [1], this should replace the 2nd paragraph in section 2 [3]:

This section defines the SOAP distributed processing model. The SOAP
processing model specifies how a SOAP receiver processes a SOAP
message. It applies to a single message only, in isolation from any
other SOAP message. The SOAP processing model itself does not maintain
any state or perform any correlation or coordination between messages,
even, for example, when used in combination with a feature which
involves sending multiple SOAP messages in sequence, each subsequent
message depending on the response to the previous message. It is the
responsibility of each such features to define such combined processing.

Section 4. SOAP Protocol Binding Framework defines a framework for
describing the rules for how SOAP messages can be exchanged over a
variety of underlying protocols. Section 3. SOAP Extensibility Model
describes how SOAP can be extended and how SOAP extensions might
interact with the SOAP processing model and the SOAP protocol binding
framework.

The XML WG has decided to close issue 225 with the text you
suggested. It considers this issue is editorial in nature.
    

Most existing Web services set up namespaces in competition with that of
the Web (URIs). They do this because they use a single URI for the
"service" and then use proprietary identifiers within. For instance UDDI
uses UUIDs, .NET My Services uses Passport User IDs and XPaths and so
forth. Others use RPC to set up a parameterized n-tuple as an addressing
mechanism. The problems with this are well-documented, but the tools do
not really support a URI-centric mode of operation and (I fear) will not
unless the specification makes clear that they are mistaken. 

I believe that the SOAP specification (or at least primer) should
address this issue directly. Here is what I propose (based in parton
some terminological suggestions by Noah Mendelsohn):

"""One of the principles of Web Architecture is that all important
resources should be identified by URIs. This implies that most
well-architected SOAP services will be embodied as large 
numbers or resources, each with its own URI.  Indeed, many
such resources are likely to be created dynamically during
operation of the service, as new information becomes available.
For example, a service allowing airline tickets to be ordered would
have different URIs for each order. As new orders come in, they would
be given URIs and SOAP requests would be directed at those URIs, not at
a single monolithic "service" URI."""

"... The problems with this are well-documented, but the tools do not 
really support a URI-centric mode of operation and (I fear) will not unless 
the specification makes clear that they are mistaken. ..."

We propose to close this issue without further changes to the specs because:

1.  Details of URI encoding are out-of-scope of the Normative parts of SOAP 
1.2 [6],
2.  The Primer provides non-normative discussion in section 3.1.3 [3], 
which appears to address your concern,
3.  Part 2 also seems to address your concern [7], and
4.  The Web Services Architecture or Description WGs may be more receptive 
of further work on this issue

Also see [4], where it looks like the TAG had an action to ask WSAWG to 
address this (or a very similar) concern.

 From the IRC log of that TAG call [5],
 20:05:26 [Ian]
 Action DC: Write up architecture concern.

 More recently, looks like the TAG may be working through the WSDWG [8][9].

 WSD WG has it as issue #61 [10].

Part 2 Table 15 [1] in the HTTP binding specification states that the HTTP
Method is set "According to the webmeth:Method property (typically POST or
GET)." This implies that correct operation of the HTTP binding *requires*
the *use* of the Web Method feature rather than merely the provision of the
feature by implimentations of the binding. I take the MUST in [2] to be a
statement about the provision rather than the use of the Web Method feature.

IMO it should be possible to use either of the Request-Response or
SOAP-Response MEPs without knowledge of the Web Method feature and that in
such circumstances the HTTP Method used should be POST and GET respectively.
This latter is behaviour is in line with the norm described in the narrative
in the final paragraph of part 2 section 6.4.3 [3] but is not evident as
default behaviour in the HTTP binding description.

</Comment>

See also issue 228.

Suggested Remedy
----------------
In the first row of Part 2 Table 15  [1], replace "According to the
webmeth:Method property (typically POST or GET)." with

"When the webmeth:Method property is present in the Message Exchange
Context, HTTP Method is set according to the value of the webmeth:Method
property (typically POST or GET). Otherwise, the HTTP methods used is POST
if the message exchange pattern in use is the 6.2
Request-Response Message Exchange Pattern ie.  context:ExchangePatternName is set to
http://www.w3.org/2002/06/soap/mep/request-response/ or the GET if the
message exchange pattern is 6.3 SOAP Response Message Exchange
Pattern ie. context:ExchangePatternName is set to
http://www.w3.org/2002/06/soap/mep/SOAP-response/."

More compact wording to similar effect or tabular presentation would be
acceptable.  eg for the first row of Table 15:
============+=========================+=================================
HTTP Method |webmeth:Method used      | Set according to webmeth:Method
            +-------------------------+---------------------------------
            |Request-Response MEP &   | HTTP POST
            |(webmeth:Method not-used)| 
            +-------------------------+---------------------------------
            |SOAP-Response MEP &      | HTTP GET
            |(webmeth:Method not-used)|
============+=========================+==================================

At it's face to face meeting in Palo Alto (July 31 - Aug 2, 2002), the 
workgroup agreed to the following resolution of issue 227:

*  A binding specification MAY require that certain "feature(s)" be used 
in particular situations when using the binding.  In other words, the 
binding specification may decline to provide any means of operation when 
such feature is not used.

* Whether use of a feature is optional or mandatory (in the sense 
described above), a feature must always be used correctly when used.  In 
other words, the use by the binding specification must be consistent with 
the specification for the feature itself.

* Issue 227 in particular questions such mandatory use of the webMethod 
feature by the HTTP binding.  The WG has voted to make no change in this 
mandatory use of the webMethod feature by the http binding.  The HTTP 
binding continues to mandate that a sending node determine the webMethod 
(e.g. POST, GET) to be used when transmitting a non-Response message. 
(Note that the entire property-based binding framework is abstract:  at no 
point does the HTTP binding attempt to describe a particular API or 
implementation structure, so this resolution says nothing about whether 
method names such as GET would be supplied explicitly or otherwise on some 
particular API;  it merely mandates that the sending node determine the 
method in some implementation specific manner, and it declines to supply 
any standard way of inferring the method from other information provided 
with the message to be transmitted.

A related issue to issue 227 is that despite the sentence at [4], 
the paragraph at [3] does not give full account of the usage of the Web Method 
feature in combination with either the Request-Response or SOAP-Response 
MEPs for example which if any of the following are allowed/disallowed:

a) MEP=Request-Response, webmeth:Method=GET
b) MEP=Request-Response, webmeth:Method=DELETE
c) MEP=SOAP-Response, webmeth:Method=POST
d) MEP=SOAP-Response, webmeth:Method=PUT
e) MEP=SOAP-Response, webmeth:Method=DELETE

Such "unusual" use is discouraged in  [3] but to comply with [4] the spec should be more explicit about the Web Method values that may be used with
particular MEPs, ie. PUT and POST with Request-Response and GET (any
others?) with SOAP-Response.

Preconditions about the 'legal' combinations of MEP and Method could be
expressed in the Web Method feature description.

During the last f2f, the WG came up with this decision to close issue 228:

<<
  Replace last paragraph of [2] with "Bindings implementing this feature
  MUST employee a Message Exchange Pattern with semantics that are
  compatible with the web method selected.  For example, the (link to
  response only)  pattern is compatible with GET.
>>

Section 2.6 Processing SOAP Messages [1] of SOAP Version 1.2 Part 1:
Messaging Framework [2] reads:

|    4. Process all header blocks targeted at the node and, in the case of
|       an ultimate SOAP receiver, the SOAP body. A SOAP node MUST process
|       all SOAP header blocks targeted at it. A SOAP node MAY choose to  
|       ignore the application level processing specified by non-mandatory
|       SOAP header blocks targeted at it.                                

The last two sentences seem contradictory. A SOAP node:
- MUST process all SOAP header blocks targeted at it.
- MAY choose to ignore the application level processing specified by
  non-mandatory SOAP header blocks targeted at it.

  An old version of this text used to say [3]:

  |    2. Process SOAP blocks targeted at the SOAP node, generating SOAP
  |       faults (see 4.4 SOAP Fault) if necessary. A SOAP node MUST process
  |       SOAP blocks identified as mandatory. A SOAP node MAY process or
  |       ignore SOAP blocks not so identified.

  This seemed to make more sense; a SOAP node:
  - MUST process all SOAP header blocks targeted at it that are
    identified as mandatory.
    - MAY process or ignore SOAP blocks targeted at it that are not marked
      as mandatory.

      Or maybe there is a subtle difference between "application level
      processing" and "processing" that I missed.

Issue 229, which you raised, was discussed by the XMLP WG and 
the resolution suggested in [2] was adopted. 

I note upon looking over the latest draft that although issue 203 
[1] has been 
closed with the proposed text describing the rules about module specifications,
there is still a slight problem that I'd like to clean up (after last call - 
so you can consider this the first item on the LC-feedback queue! :)).

In the "requirements for features" section (3.1.1), we do not actually note 
that features should be associated with a URI in their specification.  I think 
this would be a good thing to add.  It would make it easier for the authors of 
binding and module specifications to refer to implemented features, and there 
may well be call to indicate in descriptions or negotiation protocols that a 
particular feature is used/referenced/required without specifying a particular 
implementation of that feature.  Also, it would make it easier to talk about 
features with RDF models.

Concrete proposal:

In section 3.1.1 of part 1, move all the other items down, and insert a new 
item #1:
1. A URI used to refer to the feature.

On July 31st, the WG agreed to close issue #230 as follows:

In section 3.1.1 of part 1, move all the other items down, and insert a new 
item #1:

1. A URI used to refer to the feature. This enables the feature to be 
unambiguously referenced in description languages or during negotiation.
    

>  I believe that since in array the names are irrelevant, we must 
> not assume that they are the same. The name may be used for type 
> matching (if using some schema validation as suggested in 
> http://www.w3.org/TR/soap12-part2/#encschema ) or it may be 
> generated or (usually) it can be the same (like 'item' or 
> something) but the latter is just one of the options.
 
Hmmm, thats not my reading of it. The rules in [1] are:
 "1. For a graph edge which is distinguished by label ("struct" or 
    "generic"), the namespace name and local name properties of the element 
    information item together determine the value of the edge label.
  2. For a graph edge which is distinguished by position ("array" or 
    "generic"):
      * The ordinal position of the graph edge corresponds to the 
	position of the element information item relative to its siblings
      * If outbound edges are distinguished only by position ("array") 
	then the local name and namespace name properties of the element 
	information item are not significant."

If the names of the child elements are not the same then the outbound 
edges are NOT distinguished only by position (see 2, bullet 2 above) and 
hence you have a generic rather than an array.
I agree that the actual names of the array elements are not significant 
(although, as Jacek notes, they can be used for type matching) but they 
should all be the same.

At the SOAP WG Telcon of October 9th, the WG agreed to close issue 231 by
adopting the text proposed in
http://lists.w3.org/Archives/Public/xml-dist-app/2002Sep/0193.html. The WG
voted to adopt the attribute name of nodeType for use within the proposal
text. The subissue of 231 was also closed by agreeing to the text in 
http://lists.w3.org/Archives/Public/xml-dist-app/2002Sep/0192.html.
    

Having a header block without mustUnderstand set to "true" allows the
SOAP node supposed to process this block to ignore it as shown in
2.7.1 Forwarding Intermediaries [2],:

|   Forwarding intermediaries MUST process the message according to the
|   SOAP processing model defined in 2.6 Processing SOAP Messages. They
|   MUST also remove from the message all SOAP header blocks targeted at
|   themselves, prior to forwarding, regardless of whether these header
|   blocks were processed or ignored.  

and in 2.6 Processing SOAP Messages [3]:

|    4. Process all header blocks targeted at the node and, in the case of
|       an ultimate SOAP receiver, the SOAP body. A SOAP node MUST process
|       all SOAP header blocks targeted at it. A SOAP node MAY choose to  
|       ignore the application level processing specified by non-mandatory
|       SOAP header blocks targeted at it.                                

The probability that somebody included a header and really wants
something to happen as a result of its processing is high. The
probability that the person doesn't care if the header is ignored is
low.

For example, every header block used as examples in the primer [4] (that I saw) uses env:mustUnderstand="true".

It therefore seems natural to make "true" the default value for
mustUnderstand.

The XML Protocol (XMLP) WG has decided to close issue 232, which you
originated, with the following resolution.

The XMLP WG has decided to close this issue without any change to the default
value of the mustUnderstand attribute. It was felt that this change would
be inconsistent with the current design and would cause mass confusion
in the migration from SOAP 1.1 to SOAP 1.2.

From [1] it says:
"Omitting the SOAP role attribute information item is equivalent to
supplying that attribute with a value of
"http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver". An
empty value for this attribute is equivalent to omitting the attribute
completely, i.e. targeting the SOAP header block at an ultimate SOAP
receiver."

However, "" is a value relative URI and so this statement conflicts with
our use of xml:base [2] and our use of relative URIs:
"URIs used as values in information items identified by the
"http://www.w3.org/2002/06/soap-envelope" and
"http://www.w3.org/2002/06/soap-encoding" XML namespaces can be either
relative or absolute."

Proposed resolution: Remove the last sentence in the above paragraph so
that it reads:

"Omitting the SOAP role attribute information item is equivalent to
supplying that attribute with a value of
"http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver"."
   

During the F2F, the WG has decided to close issue 233
by accepting your proposal:
 Remove the last sentence in the paragraph.
 

Part 2, section 3.1.6 arraySize Attribute Information Item [1] reads:

|   The array's dimensions are represented by each item in the list of
|   sizes (unspecified size in case of the asterisk).

This reminds me of the XML Schema maxOccurs attribute which specifies
how many maximum times an element occurs [3].

maxOccurs unbounded value used to be "*" and was changed into
"unbounded" by the XML Schema Working Group (see issue 221 [2]).

For alignment purposes, I think that SOAP should also use "unbounded".
Should the XML Schema Working Group define an array type, they would
most certainly go with "unbounded".

 
The XMLP WG has decided to close its last call issue #234 keeping the 
status quo. The rationale is provided in the thread starting with 
Gudge's proposal [2].
    

This email is to point out an assertion in SOAP 1.2 Part 1  [1] which is not listed in the Assertion and Test Collection  [2] document.

The assertion occurs in section 5.4.3. The assertion text is:

The type of the Node element information item is anyURI in the 
"http://www.w3.org/2001/XMLSchema" namespace.

Issue 235 has been closed by adding the missing assertion in the
SOAP 1.2 Assertions and Test Collection document.
    

There is typo in SOAP 1.2 Part 1 section 1.2.

"The SOAP envelope has the namespace name ..." should be
"The SOAP Envelope has the namespace name ..."

The complete paragraph is:

Some of the information items defined by this document are identified
using XML namespace [7] names (see 5. SOAP Message Construct). In particular, this document defines the following namespace names:

* The SOAP envelope has the namespace name
    "http://www.w3.org/2002/06/soap-envelope" (see 5. SOAP Message
      Construct).
* The SOAP Misunderstood element information item has the namespace
	name
    "http://www.w3.org/2002/06/soap-faults" (see 5.4.8 SOAP mustUnderstand Faults).  
* The SOAP Upgrade element information item has the namespace name 
    "http://www.w3.org/2002/06/soap-upgrade" (see 5.4.7 VersionMismatch Faults).

The editors have resolved the issue by removing the duplication of the
namespace information. The changes can be seen in the editors copy [3] (
deleted text is struckout and highlighted in red )
    

Assertion 70, "Text from the specification" in [1] does not cut-and-paste correctly from the SOAP 1.2 Part 1 [2]. There is a missing a bullet:

" Any number of character information item children. Child character
information
  items whose character code is amongst the whitespace characters as
  defined by
   [8] are considered significant."

Issue 237 has been closed by fixing the 'cut-and-paste' error. The
SOAP 1.2 Assertions and Test Collection document has been updated accordingly.

Example 4:
Element <m:reservation.........................> has got
env:mustUnderstand="true" attribute defined.
  
This element appears in the <env:body..........> of the SOAP message.
   
The primer further says that mustUnderstand attribute is not allowed in the body. It is only allowed in header blocks.
    
Is this a mistake?

Thanks for pointing this out (see excerpt below). It was a cut-and-paste 
mistake, and will be removed from the next revision of the SOAP 1.2 Primer WD.

BTW, in the same element that you mention, the "role" attribute is also 
undefined for a body element, and should also be removed.

In Paragraph 6.3.3, (SOAP Response MEP), the text after Table 12 ('Bindings 
that...') is identical to the text after Table 7. This text needs updating - 
it refers to a SOAP request which is not part of the SOAP Response MEP (only 
the response is SOAP, the request is an HTTP GET without SOAP envelope, i.e. 
SOAP-free).

Thanks for spotting this. I think this is a cut-and-paste problem 
and that this text should be removed from the SOAP response section 
entirely.
    

In section 5.2 of the Requirements document [1] it states
"It must be possible to associate a P3P Privacy Policy with 
an XMLP message." In a previous exchange with the
P3P Specification working group [2] we agreed that indeed
it appeared that this was possible. However, we do not
believe that the requirement can be adequately met without
actually documenting how a P3P policy can be associated
with an XMLP message. As there are a variety of ways this
might be done, it is important that your working group
document the preferred method so that implementations
will be interoperable.

In our previous discussion [2] it was suggested that a SOAP
header could be defined to associate a policy with 
a message. (Actually it might make more sense to associate
a policy reference file with a message if there is a way to
uniquely reference messages by URI -- that's a topic we would
be happy to discuss with you further). As far as we can tell, no 
such header has been defined. Furthermore it was 
suggested that a policy could be directly embedded within 
a header. If this mechanism is to be
used, it would need to be documented that embedding a 
P3P policy has the meaning of associating that policy
with the message within which it is embedded. There may
be some scoping and lifetime issues that would also be
necessary to resolve, as well as issues about resolving
potential policy conflicts. 

When XMLP messages are
conveyed over HTTP the existing mechanisms defined
in the P3P1.0 specification may be used to associate policies
with XMLP messages. However, it is unclear to us whether
the P3P specification supplies a sufficient level of granularity
to identify XMLP messages. If it does not, it is likely that
the P3P extension mechanism could be used to provide
this granularity, but again this would need to be documented.
Furthermore, if other mechanisms are defined specifically for
use with XMLP, then conflicts may arise between these 
mechanisms and the P3P1.0-defined mechanisms. The
proper way to resolve these conflicts needs to be documented
as well.

Besides documenting how a P3P policy should be associated
with an XMLP message, we believe it would be useful to offer
some usage scenarios that include P3P. We are concerned
that in the absence of discussion of privacy and P3P, developers
will be likely to ignore privacy issues when implementing
the XML Protocol.

1. http://www.w3.org/TR/2002/WD-xmlp-reqs-20020626
2. http://lists.w3.org/Archives/Public/xmlp-comments/2002Jan/0022.html

The XML Protocol (XMLP) WG has decided to close issue 240, which you
originated, with the following resolution.

The XMLP WG respectfully disagrees that the XMLP WG must document how P3P
policies should be associated with XMLP messages in order to satisfy the
requirement that it be possible "to associate a P3P Privacy Policy with an
XMLP message". We believe the requirement is met through our previous
agreement that in principle it is possible to associate P3P Privacy
Policies with XMLP messages. The XMLP WG's charter explicitly states that
its mission is to provide a framework that can support a wide variety of
applications, but its mission explicitly excludes defining the semantics
associated with particular applications. The XMLP WG does recognize the
importance of Privacy, and it suggests sending the question of which other
WG takes on this task to the Web Services Co-Ordination Group for
consideration.

# SOAP Version 1.2 Usage Scenarios
# W3C Working Draft 26 June 2002
#    This version:
#           http://www.w3.org/TR/2002/WD-xmlp-scenarios-20020626
# 2.6 S6 Request with encrypted payload
# 
# 2.6.1 Scenario Definition
# 
#    A sender wishes to exchange data with a receiver and has agreed to
#    encrypt the payload. The sending and receiving applications agree on
#    the encryption methodology. Data is encrypted by the originating
#    application and sent to the receiver via SOAP. The data reaches the
#    receiving application untouched, and may then be decrypted in the
#    agreed-upon manner.

The *most* problematic issue for Signatures and Encryption are those related 
to detaching and inserting XML in one document from another. Simply, XML 
was not designed to do this well, and in many circumstances its not 
possible to do it well. Consequently, I believe that applications that do 
this need to be very clear about the methods of removal/insertion and SOAP 
seems an obvious example of this. I'd think the WG should consider either 
defining a mechanism of attachment/detachment (and the related Infoset 
clean up) or contrain/warn applications as xmldsig [1] and xenc [2] have 
done about the use of xmlns="", and xml:foo attributes, and using qualified 
names in attribute values -- or at least quickly repeat/reference those 
arnings.

At the F2F, the XMLP discussed issue 241 you raised.
After hearing your clarifications, the WG has decided
to close this issue without changes in the specification.

#    Following completion of Last Call, the XML Protocol Working Group has
#    agreed to advance the specification according to four exit criteria:
#     1. Sufficient reports of implementation experience have been gathered
#        to demonstrate that SOAP processors based on the specification are
#        implementable and have compatible behavior.

What does this mean in the context of the primer and scenarios? Will you 
want to see evidence of all the scenarios having been accomplished before 
you advance the specifications?

The XML Protocol (XMLP) WG has decided to close issue 242, which you
originated, with the following resolution.

The XMLP WG intends to collect implementation experience regarding the
features present in Parts 1 and 2 of the SOAP specification only. The
appearance of the  "4 exit criteria" statement in Last Call documents other
than Parts 1 and 2 was a mistake, and was not intended to indicate that the
WG would be collecting implementation experience based on other documents
such as the Primer and Scenarios documents.

#     2. An implementation report shows that there are at least two
#        different and interoperable implementations of every mandatory and
#        optional feature.

My comment is more  to Part 1, then this primer, but I also recommend a 
requirement of one COMPLETE implementation of all mandatory features: 
"Given different implementations, their variance in the 20% each fails to 
do well causes 80% of the users' headaches."

We believe the essence of your concern to be that we have committed to 
looking for implementations of each of the mandatory features of our 
specification, but not to one single implementation that embodies them 
all.  We discussed your concern at some length at our face to face meeting 
in Palo Alto this week, and I think it's fair to say there is considerable 
sympathy for the spirit of the concern that you raise.   So, we gave some 
thought to how this might reasonably be done.

SOAP is a wire format, and the specification is quite intentionally 
written to not have any notion of a COMPLETE implementation.  Just as a 
simple example, the mandatory responsibilities of a sender are different 
from those of a receiver, and there is no requirement that any one piece 
of software provide both capabilities.  Also, the generation of certain 
faults is mandatory in the abstract, but where you deliver them depends on 
the (optional) message exchange pattern in use (for the request/response 
MEP,  faults generated when processing a request are sent back to the 
requester, but faults generated in processing a response are generally 
known only to the node encountering the error...since we have way to get 
back to the responder.)    A further example of an implementation that 
conforms to mandatory requirements but that fails to illustrate certain 
interesting behaviors:  we expect that many embedded controllers will 
decline all header processing by merely claiming not to "understand" any 
(or most) headers.   So, there is no notion of a COMPLETE implementation, 
and only a few truly mandatory requirements;  there are of course 
mandatory requirements in most particular situations.

That said, we do expect that certain sorts of implementations will be 
reasonably common.  For example, we anticipate that many vendors will 
build relatively general purpose SOAP "servers" that serve as receivers 
for requests and as senders for responses.   Taking all these 
considerations into account, the workgroup has decided that our formal 
criteria for exit from last call will not change, but that we will 
undertake a good faith effort to ensure that implementations exist that 
embody the anticipated common combinations of mandatory (and as 
apppropriate optional) features.  We hope that you will find this approach 
to be appropriate. 
    

#    Therefore, when a RPC definition is such that all the parts of its
#    method signature can be described as resource-identifying and hence

Please define "method signature", this will be useful and also make it clear 
you are not speaking of a digital signature.

The expression "method signature" has been removed, and therefore does not 
need to be defined. Words such as "method description" are used where 
appropriate.

#    Example 5b
#        <rpc:result>m:status</rpc:result>
#        <m:status>confirmed</m:status>

This is a very odd sort of construct. I know it's just an example, but is 
this sort of thing expected to be the norm, I would expect:
  <rpc:result><m:status>confirmed</m:status></rpc:result>

The Primer follows the main specifications in this formulation; so your issue 
is really an issue against the Parts 1, 2 specifications. A similar concern 
against the main specifications has been raised in Issue #299 [2].

Therefore, I intend to close this issue from the point of view of the 
Primer, and will revise the example only if the main specifications change 
as a part of the resolution of Issue 299.

#   2.3 Fault scenarios
#    The SOAP Body element has another distinguished role in that it is the
#    place where such fault information is placed. The SOAP fault model
#    (see Part 1, section 5.4) requires that all SOAP-specific and
#    application-specific faults be reported using a single distinguished
#    element, Fault, carried within the Body element. The Fault
#    element contains two mandatory sub-elements, Code and
#    Reason, and (optionally) application-specific information in the
#    Detail sub-element within the Fault. Another optional
#    sub-element, Node, identifies via a URI the SOAP node which
#    generated the fault, its absence implying that it was the ultimate
#    recipient of the message which did so. There is another optional
#    sub-element, Role, which identifies the role that the node which
#    generated the fault was playing.

The various specifications repeatedly attempt to define the difference  the 
header and the body, which I appreciate, but I'm still a little confused. I 
understand that header information is of interest on the hop 
(intermediaries) but the body is for the end-to-end (destination). But if 
I'm putting error messages in the body, couldn't it be possible that the 
intermediaries would be interested in that as well?

During the last f2f, the WG came up with the decision to close issue 246 
you raised without further changes to the spec: 
Reason: There is nothing within the spec that prevents an intermediary 
from inspecting the error messages within the body.
We recognise there is a potential problem with this, but it is not by 
itself significant enough to warrant another last call. If we decide
to go back to last call we will reconsider the design for fault handling
in body and/or headers.

#    Part 1 section 5.4 of the SOAP specifications describes the
#    structure of the fault message while the SOAP processing model defines

I was briefly confused by these "Part 1" section foo, I kept thinking, Part 
1 of what specification? I know it's stated in section 1, but perhaps on 
the first few instances in the text, you could include the full name.

This comment has been incorporated into the editor's copy of the Primer

#    Example 12b

In the Primer, an example has the "Example #" and a description below the 
example, Part 1 has the description at the top. These should be harmonized, 
I prefer it at the top.

We respectfully decline to make the proposed change, as this adds a lot of 
extra work without any real benefit. Moreover, the examples in the main 
specifications are not referenced elsewhere in the documents except in the 
immediate preceding text. The Primer makes frequent references to individual 
examples from various parts of the document, hence an additional row. Changing 
its position would not, in our opinion, add anything, and we do not feel that 
readers would be discommoded by its current placement.
    

# 1.2.2 Robustness Principle
# 
#    In some cases, the use of XML technologies allows the flexibility for
#    expressing semantically equivalent statements in a variety of
#    different ways. In order to obtain robust and interoperable
#    implementations it is essential that SOAP implementations take into
#    account the Robustness Principle as expressed by RFC 1123 
#    and RFC 793 : "Be liberal in what you accept, and
#    conservative in what you send".

I know this can be a matter of debate, but I believe this principle has 
caused the majority of headaches of users of document formats: permitting 
innumerable cruddy instances which necessitate complex heuristic based 
parser/applications. While it is still  in some limited protocol scenarios, 
I'm generally cautious towards it, and oppose it with to document 
syntaxes.

Regarding issue 249, we are moving section 1.2.2 from the specification.

# 2.2 SOAP Roles and SOAP Nodes
#    This specification defines the following SOAP roles:
#      * "http://www.w3.org/2002/06/soap-envelope/role/next". Each SOAP
#        intermediary and the ultimate SOAP receiver MUST act in this role
#        and MAY additionally assume zero or more other SOAP roles.
#      * "http://www.w3.org/2002/06/soap-envelope/role/none". SOAP nodes
#        MUST NOT act in this role.
#      * "http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver".
#        To establish itself as an ultimate SOAP receiver a SOAP node MUST
#        act in this role. SOAP intermediaries MUST NOT act in this role.

Where? If the intent is to define them here, it merely states if a SOAP node 
can act in the role, I really haven't found a good definition of these 
roles.

The relationship between a role and a role name is similar to that
between a resource and a URI. The role name is just an identifier
identifying the role. In fact, given that the role name is a URI, a role
is therefore a resource.

In the current text, I would tend to agree with you that it would be
more appropriate to say that we define roles who have known URIs rather
than saying that we define role names. Throughout the spec we talk about
roles and not just their names.

In response to your comment, would the editorial clarification below
make the definition of roles easier to pinpoint?

* * * * * 

This specification defines the following roles which have special
significance in a SOAP message (see 2.6 Processing SOAP Messages):

* The role identified by the URI
"http://www.w3.org/2002/06/soap-envelope/role/next". Each SOAP
intermediary and the ultimate SOAP receiver MUST act in this role and
MAY additionally assume zero or more other SOAP roles.

* The role identified by the URI
"http://www.w3.org/2002/06/soap-envelope/role/none". SOAP nodes MUST NOT
act in this role.

* The role identified by the URI
"http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver". To
establish itself as an ultimate SOAP receiver a SOAP node MUST act in
this role. SOAP intermediaries MUST NOT act in this role.

In addition to those described above, other roles MAY be defined as
necessary to meet the needs of SOAP applications.

In addition to the three SOAP roles defined above, other roles MAY be
defined as necessary to meet the needs of SOAP applications.

* * * * *
    

# 2.4 Understanding SOAP Headers
#    Mandatory SOAP header blocks are presumed to somehow modify the
#    semantics of other headers or body elements. 

This surprises me, I'd think I could have Mandatory SOAP headers that can 
co-exist, however on further thought this sounds like a good idea.

The XMLP working group have closed Issue 251 by stating that it
requires no action as it is a non-issue. If you disagree with this
assessment of the issue please let the working group know as soon as
possible.

# 5. SOAP Message Construct
# 
#    The XML infoset of a SOAP message MUST NOT contain a document type
#    declaration information item.
# 
#    A SOAP message SHOULD NOT contain processing instruction information
#    items. A SOAP receiver MUST ignore processing instruction information
#    items in SOAP messages that it receives.

I recommend you also make (or reference) further constraints on xml:foo and 
other issues I mentioned if it's likely that the payload will be detached/ 
-- unless you define methods of changing the Infoset in these ways.

The WG decided to close issue 252 as it is a duplicate of issue 241
[2] (that you also raised).

# 6. Use of URIs in SOAP
#
#    SOAP does not define a base URI but relies on the mechanisms defined
#    in XML Base  and RFC 2396  for establishing a base
#    URI against which relative URIs can be made absolute.

Again, use of base URIs across payload attach/detach boundaries should be 
constrained.

The editors have decided to resolve this issue by taking no action. SOAP
does rely on XML base and RFC 2396  for dealing with relative URIs. The
editors did not consider it necessary to say anything about payload
boundaries in this specification.
    

# SOAP Version 1.2 Part 2: Adjuncts
# W3C Working Draft 26 June 2002
#    This version:
#           http://www.w3.org/TR/2002/WD-soap12-part2-20020626
# 3.1 Rules for Encoding Graphs in XML

Would the RDF datamodel and serialization suffice in place of this?

The XML Protocol (XMLP) WG discussed and decided to close issue 254,
which you originated, with the following resolution:

SOAP encoding is optimized for various applications and has implementation
standing in the community. We do not believe that RDF should replace SOAP
encoding.

Example 4 is a SOAP RPC request with a mandatory header 
and two "in" parameters.  However, it is not clear 
(or at least not clear to me) what the two "in" parameters
are.  Please explicitly call them out in the text.  
Also please explain what the "5" is in the header 
(one line before </t:transaction>). 
(Maybe it's one of the two parameters?)

Example 5 is a RPC response with two "out" parameters.  
However, it is not clear what the two "out" parameters are.  
Please explicitly identify them in the text.

This comment has been incorporated into the editor's copy of the Primer

When printing on A4 paper, many of the examples get cut off
on the right. Examples should be reedited so that they are
somewhat less wide and can be printed on paper around the
world without loss.

I have printed Part 1 and Part 2 of the spec on A4 paper and all example print
correctly. Hence no action has been taken.
  

The examples should be changed to be more international.  
People travel all around the world, to places that have
names with characters outside US-ASCII,... Web Services
can easily take care of this, and this should be shown.
(please ask your chair, who knows how to do this from
the XML Schema primer :-)

Your editorial comment on the SOAP Part0: Primer, marked as Last Call Issue#257
has been accepted and handled in the latest editor's copy of the document.  
The passenger's name as well as fault texts have been "internationalized".
  

Example 6: The use of xml:lang="en-US" is very good. A comment
 saying why xml:lang is important would be even better.

This comment has been incorporated into the editor's copy of the Primer

Example 8b: <x:date>12-14-01</x:date>: This is not interoperable!
Please use either XML Schema dates (<x:date>2001-12-14</x:date>),
because this is machine-to-machine communication, or something
like <x:date xml:lang='en-US'>December 14, 2001</x:date> if this
is intended for human viewers.

This comment has been incorporated into the editor's copy of the Primer

Example 11: charset="utf-8": It would be a good chance to shortly
explain the rules for the charset parameter with application/soap+xml
(because otherwise, the reader has to follow two references).
The best recommendation is probably: Don't use a 'charset' parameter
on 'Content-Type', because then the rules for freestanding
XML (UTF-8 and UTF-16 (the later always with BOM) as defauts,
otherwise <?xml ... encoding='foo'...) apply.

This comment has been incorporated into the editor's copy of the Primer

> 4.2: "A binding, if using XML 1.0... MAY mandate that a particular
> character encoding or set of encodings be used." 

This is good, but should be changed to say that in such a case, UTF-8/UTF-16
should be choosen (in accordance with XML 1.0 and the Character Model).

  See Gudge's proposal and following thread.
  See Gudge's amended proposal and following thread.
  See Gudge's second amended proposal and following thread.
  

The editors have closed this issue with no change on the grounds that
the requested change is already covered by the "application/soap+xml"
media type registration [3] by reference to RFC3023 [4].

5., last paragraph: This is written as if all white space is
by default ignored. But it is probably meant to apply only
to insignificant whitespace (e.g. between elements in element content).

The language in the specification will be amended to make sure it is clear
that only insignificant whitespace can be ignored.

5.4.2: <reason>: xml:lang is optimal, but there should be a note
 saying that it is strongly recommended.

<reason>: xml:lang is said to have a namespace name of
"http://www.w3.org/XML/1998/namespace". This alone does not
guarantee that the prefix will be 'xml' in XML 1.0 serialization,
because the Infoset spec doesn't say so (or at least I didn't
find something to that effect). This has to be nailed
down here to avoid serializations such as
<reason xmlns:foo='http://www.w3.org/XML/1998/namespace' foo:lang='...

<reason> is a human-readable string, but there is no way
for the request side to indicate which language would be preferred.
This is a serious problem. Solutions may include the definition
of a soap feature (preferably a module) for this, or requirements/
recommendations for bindings to make mechanisms they have available
(e.g. Accept-Language for the HTTP binding).

In some cases, it can make sense to send <reason> in 
more than one language. Is this allowed? It may be a good idea.

<reason> is currently the only place where human readable text is
used. But despite Web Services being primarily machine-to-machine,
we expect that quite some applications will include data that is
ultimately targeted at humans, or will have to make some part
of their processing dependent on human language and culture.
This seems to indicate that some more work will have to be done.

The XMLP WG has decided to modify SOAP Reason element (5.4.2 in Part1)
in the following manner:

- The Reason element information item has one or more Text element
information item children:

  <env:Reason> 
    <env:Text xml:lang="en-US">wrong color</env:Text>
    <env:Text xml:lang="en-GB">wrong colour</env:Text> 
  </env:Reason>

- The Text element information item has any number of character
information item children to explain the neture of the fault.

- Each Text element MUST have xml:lang attribute information item
(prefix of lang attribute information item MUST be "xml:").

- When there are multiple Text element information items, values of
xml:lang attribute information items MUST be unique.

Applications can make multiple language versions of the fault text
available using this mechanism. Applications could negotiate
the language for the fault text using a mechanism built using SOAP headers.
However we do not provide such a mechanism.
  

6. This section should make it clear that soap uses the XML Schema
type 'anyURI', and that therefore characters outside US-ASCII are
allowed, but have to be mapped to URIs via UTF-8 (i.e. SOAP
essentially uses IRIs, refer to XML Schema or XLink for conversion
details) if e.g. the underlying protocol doesn't
support IRIs. There also should be a requirement to deal with this
in the binding framework, and an explanation of how to deal with
this in the HTTP binding, as well as some tests (I can help
with the tests). Also, a note in the Primer would help.

The editors decided to resolve this issue with no action. The full rationale
can be found at [3] but essentially we deemed that it is out-of-scope for
our spec to say anything about IRIs given they are already covered by
the XML Schema Part 2 specification [4].
  

7.3: feature conflict between soap features and features in the
underlying protocol: This is a general issue, not only for
security. It should be mentioned in the chapter on bindings.

The XML Protocol WG has decided to close editorial issue 265 raised
by you without changes to the specification. The justification follows
below. If you cannot accept this resolution then please send your
concerns to the <xml-dist-app@w3.org> mailing list indicating the
issue number of the issue in the subject.

We believe the issue of interacting features, regardless of whether they
are expressed as SOAP modules or part of the binding) is covered in part
1, section 3.2 where it is stated that a SOAP module specification:

"MUST clearly specify any known interactions with or changes to the
interpretation of the SOAP body. Furthermore, it MUST clearly specify
any known interactions with or changes to the interpretation of other
SOAP features (whether or not those features are themselves modules).
For example, we can imagine a module which encrypts the SOAP body and
inserts a SOAP header block containing a checksum and an indication of
the encryption mechanism used. The specification for such a module would
indicate that the decryption algorithm on the receiving side is to be
run prior to any other modules which rely on the contents of the SOAP
body."
  

2: How is XML mixed content represented in this graph model?
Can it be represented? If not, this is a serious problem for
internationalization.

The XMLP WG has decided to close this issue without any
change to the SOAP Data Model and without any change to
the SOAP Encoding. The XMLP WG recognizes the general
importance of enabling I18N, however SOAP's model and
serialization is designed for interfacing with
programming languages many of which we believe would be
incapable of dealing with the resulting marked up text.
Indeed, there has been early experience (e.g. on
"soapbuilders") binding the SOAP Encoding to a large
number of widely deployed systems (e.g. Java, .Net,
etc.) We have reason to believe that most, perhaps all
of these would be incapable of effeciently representing
(e.g. in their Unicode string types) the sort of marked
up text that is conveyed by mixed content.

We realize that this decision is at best a practical
compromise from the point of view of i18n.  We
believe, however, that the sensible order of attack on
this problem is to first encourage the development of
programming systems that can indeed efficiently
manipulate such richly structured text.  At that point,
it would indeed be sensible to consider "raising the
bar" and providing at least an option for mixed content
in the SOAP encoding.  In the meantime, we do not
believe that we can adopt an approach that would
substantially break most or all of our existing users'
implementations.

The XMLP WG notes that the SOAP Data Model and Encoding
are optional, and the SOAP framework allows someone to
create their own model with a serialisation that
provides mixed content.

 3.1.2: encoding simple values:
 There should be a note mentioning that most characters in the
 C0 range cannot be represented in XML.

The XML Protocol WG has decided to close issue 267 raised by you by
adding a note in SOAP 1.2 part 2, section 3.1.2 saying:

        Note that certain Unicode characters cannot be represented 
	in XML (see [XML 1.0]). 
  

5.1.1: Properties are restricted to simple datatypes. This may
   cause serious problems for internationalization.

The XMLP Working Group have closed Issue 268 with the following
resolution:

Change the following text from Part 2 5.1.1 [2];

'Property values are typed, and the type of a property-value is defined
by an XML Schema simple datatype in the specification which introduces
the property. For example, the type of RetryCount is xsi:int .'

To read:

'Where appropriate properties SHOULD have an XML Schema type'

The WG will also update the property tables to include a 'Type' column.

7.5.1.3: response MAY be of content type other than application/soap+xml:
add a note saying that care is needed because different 
content types may have different rules for the 'charset' parameter.

The XML Protocol WG has decided to close issue 269 without making changes to 
the SOAP 1.2 specification. The reason for the decision is stated below.

The issue reads as follows

        7.5.1.3: response MAY be of content type other than 
	application/soap+xml: add a note saying that care is 
	needed because different content types may have 
	different rules for the 'charset' parameter.

However, in Table 18 [5] which is just above the paragraph you mention
(and which is the target of the paragraph), we say that:

"The response message is assumed to be a SOAP envelope serialized
according to the rules for carrying SOAP messages in the media type
given in the Content-Type header field."

The only other place where we mention possible media type encodings is
in Table 15 [6] where we say:

"SOAP message serialized according to the rules for carrying SOAP
messages in the media type given by the Content-Type header field. Rules
for carrying SOAP messages in media type "application/soap+xml" are
given in A. "The application/soap+xml Media Type".

In both places do we state that it is the responsibility of the media
type to dictate the rules for the encoding. As the parameter "charset"
is part of a specific media type definition, the WG felt that it is out
of scope of the HTTP binding to refer to the use of the charset
parameter.

For the specific case of "application/soap+xml" of which registration is
undertaken by the XML Protocol WG, issues related to the use of the
charset parameter are explicitly described in appendix A.
  

- Appendix A: This needs a major overhaul (Masahiro Sekiguchi already
   pointed out some problems quite a while ago).

   - Start with some introductory text explaining what's going on.

   - XML Name has two parts -> An XML Name ...

   - Let Prefix be computed: There is really no computation going on at all.

   - In order from left to right -> In order from first to last
     (otherwise, you get problems with bidirectionality)
     [but this will drop out anyway]

   - 2: change to: Let TAG be a name in an application, represented
     as a sequence of characters encoded in a particular character encoding.

   - 3: change to: Let UNI be the sequence of characters of TAG
     transcoded to Unicode with a normalizing transcoder (using NFC),
     and let M<sub>1</sub>, M<sub>2</sub>, ... , 
     M<sub>N</sub> be the characters of UNI, in order from 
     first to last.

   - Add a note: The number of characters in TAG is not necessarily
     the same as the number of characters in UNI, because transcoding
     may be one-to-many or many-to-one. The details of transcoding may
     be implementation-defined. There may be (very rarely) cases where
     there is no equivalent Unicode representation for TAG; such cases
     are not covered here.
									           - remove 4.
										   - Change all T<sub>foo</sub> to M<sub>foo</sub> in the rest.

   - Remove 5.1, moving up 5.2,...

   - Say explicitly that hex digits always use upper case letters.

   - Add examples with non-ASCII characters, both in the BMP (not
     only Latin-1) and outside the BMP.

  The XML Protocol WG has decided to close issue 270 raised by you by
  applying substantial amount of editorial work in order to clarify the
  text [2], which for other reasons now is in Appendix B and not Appendix
  A. The rewrite also took into account contributions and suggestions by
  Asir S Vedamuthu [3] and Mike Champion [4]. The comments raised by Mike
  are logged as issue 341 [4] for which a separate closing text will be
  generated.
  

Acknowledgements: I assume that the 'member of the WG'
"Noah Mendelson (IBM)" and the the 'previous member of
the WG' "Noah Mendelson (Lotus Development)" are one and
the same person. This would appropriately be reflected
by saying 'member of the WG': "Noah Mendelson (IBM,
formerly Lotus Development)". There are other cases
like this