W3CArchitecture DomainXML Protocol WG

XML Protocol WG Last Call Issues List

Last update: $Date: 2004/08/12 12:45:22 $

Issues regarding the documents produced but the XML Protocol Working Group should be reported to xmlp-comments@w3.org (public archives).

Comments on this list should be sent to the xml-dist-app@w3.org mailing list (Archives).

In this document, AMG means abstract model group, RPCTF means RPC task force, TBTF means transport binding task force and ETF means encoding task force.

For the previous list of closed and postponed issues, you can read the WG issue list.

Summary List of Outstanding Issues

idStatusSpecTopicClassReqTitle

Detailed List of Issues

idSpecReqTopicClassStatusRaised ByOwner
206specn/arpcDesignClosedChristopher Ferris
Title: resolution to rpc:ProcedureNotFound fault subcode
Description:
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.
[email]
Proposal:
Resolution:
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.
[email]
207specn/aBindingDesignClosedMark Baker
Title: Is RFC 822/2822 binding a protocol binding?
Description:
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.
[email]
Proposal:
Resolution:
    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.
    
[email]
208specn/ametaDesignClosedNoah Mendelsohn
Title: Clarify that whitespace IS (potentially) significant in Header and Body blocks
Description:
> 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.
[email]
Proposal:
Resolution:
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]
209specn/aEncodingDesignClosedNoah Mendelsohn
Title: scoping rules for encodingStyle
Description:
> 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 ?
[email]
Proposal:
Resolution:
    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.
/[email]
210specn/ametaDesignClosedNoah Mendelsohn
Title: Don't we allow arbitrary attributes on header blocks?
Description:
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>
[email]
Proposal:
 <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>
Resolution:
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>
[email]
211specn/aEditorialDesignClosedNoah Mendelsohn
Title: Define "abstract piece of functionality"
Description:
 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)
[email]
Proposal:
Resolution:
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...".
[email]
212specn/abindingDesignClosedNoah Mendelsohn
Title: Error handling or processing of externally expressed features
Description:
 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>
[email]
Proposal:
 <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>
Resolution:
The XMLP WG had decided to close action 212 by incorporating your
suggested change. It considers this issue is editorial in
nature.
[email]
213specn/aEditorialDesignClosedNoah Mendelsohn
Title: Special rules for MEPs
Description:
 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.
[email]
Proposal:
Resolution:
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).
[email]
214specn/aEditorialDesignClosedNoah Mendelsohn
Title: The final reference to "false or 0" seems to violate our style guideline
Description:
 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>
[email]
Proposal:
 <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>
Resolution:
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.
    
215specn/ametaDesignClosedNoah Mendelsohn
Title: The role EII must be one of the roles assumed by the node during processing?
Description:
> 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.
[email]
Proposal:
Resolution:
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)."
[email, email]
216specn/ametaDesignClosedNoah Mendelsohn
Title: Make the security considerations clearer
Description:
 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.
[email]
Proposal:
Resolution:
    The WG discussed this issue on 10th July and decided to close it without 
    incorporating any of the suggested revisions.
    
[email]
217specn/ametaDesignClosedStuart Williams
Title: (Relative or not?) URI identifying a SOAP node
Description:
 (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' ?
[email]
Proposal:
Resolution:
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".
[email]
218specn/ametaDesignClosedStuart Williams
Title: Active intermediaries specification
Description:
 (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.
[email]
Proposal:
Resolution:
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.
    
[email]
219specn/ametaDesignClosedStuart Williams
Title: Definition of a SOAP module
Description:
 (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.
[email]
Proposal:
Resolution:
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])
[email]
220specn/aBindingDesignClosedStuart Williams
Title: Remove contradiction on SOAP binding definition
Description:
 (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.
[email]
Proposal:
Resolution:
    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>
    
[email]
221specn/ametaDesignClosedStuart Williams
Title: Clarify whether intermediaries forward Processing Instructions
Description:
 (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.
[email]
Proposal:
Resolution:
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." 
[email,email]
222specn/aEncodingDesignClosedStuart Williams
Title: Single instance of encodingStyle attribute (scope?)
Description:
 (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.
[email]
Proposal:
Resolution:
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.
     
[email]
223specn/aBindingDesignClosedNoah Mendelsohn
Title: Use of optional HTTP Features
Description:
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.
[email]
Proposal:
Resolution:
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."
[email]
224specn/aBindingDesignClosedHenrik Frystyk Nielsen
Title: HTTP status codes
Description:
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.
[email]
Proposal:
Resolution:
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.
    
[email]
225specn/ametaDesignClosedHenrik Frystyk Nielsen
Title: SOAP processing model
Description:
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.
[email]
Proposal:
Resolution:
The XML WG has decided to close issue 225 with the text you
suggested. It considers this issue is editorial in nature.
    
[email]
226specn/ametaDesignClosedPaul Prescod
Title: What does WS URI address?
Description:
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. 
[email]
Proposal:
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."""
Resolution:
"... 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].
[email]
227specn/aBindingDesignClosedStuart Williams
Title: Web Method Feature
Description:
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.

[email]
Proposal:
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)|
============+=========================+==================================
Resolution:
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.
[email,email]
228specn/aBindingDesignClosedStuart Williams
Title: Be more explicit about the Web Method values that may be used with particular MEPs
Description:
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.
[email]
Proposal:
Resolution:
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.
>>
[email]
229specn/ametaDesignClosedHugo Haas
Title: Clarify "non-mandatory" in Processing SOAP Messages section
Description:
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.
[email]
Proposal:
Resolution:
Issue 229, which you raised, was discussed by the XMLP WG and 
the resolution suggested in [2] was adopted. 
[email]
230specn/ametaDesignClosedGlen Daniels
Title: Definition of features
Description:
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.
[email]
Proposal:
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.
Resolution:
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.
    
[email]
231specn/aEncodingDesignClosedMarc Hadley
Title: What is the difference between a "struct" and an "array" in the edge case?
Description:
>  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.
[email]
Proposal: email, email
Resolution:
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.
    
[email]
232specn/ametaDesignClosedHugo Haas
Title: Changing the default value of mustUnderstand to "true"
Description:
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.
[email]
Proposal:
Resolution:
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.
[email]
233specn/ametaDesignClosedHenrik Frystyk Nielsen
Title: Conflict between empty role value and SOAP 1.2's use of xml:base
Description:
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."
[email]
Proposal:
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"."
   
Resolution:
During the F2F, the WG has decided to close issue 233
by accepting your proposal:
 Remove the last sentence in the paragraph.
 
[email]
234specn/aEncodingDesignClosedHugo Haas
Title: Change maximum arraySize value to "unbounded"
Description:
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".
[email]
Proposal:
Resolution:
 
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].
    
[email]
235test collectionn/aEditorialDesignClosedAnish Karmarkar
Title: Assertion and Test Collection doc: missing assertion
Description:
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.
[email]
Proposal:
Resolution:
Issue 235 has been closed by adding the missing assertion in the
SOAP 1.2 Assertions and Test Collection document.
    
[email]
236specn/aEditorialDesignClosedAnish Karmarkar
Title: SOAP 1.2 Part 1 section 1.2 Editorial nit
Description:
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).
[email]
Proposal:
Resolution:
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 )
    
[email]
237test collectionn/aEditorialDesignClosedAnish Karmarkar
Title: SOAP 1.2 Assertions and Test Collection: Editorial
Description:
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."
[email]
Proposal:
Resolution:
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.
[email]
238specn/aEditorialDesignClosedAjay Dubey
Title: SOAP Version 1.2 Part 0: Editorial
Description:
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?
[email]
Proposal:
Resolution:
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.
[email]
239specn/aEditorialDesignClosedMichael Mahan
Title: SOAP Version 1.2 Part 2: Editorial
Description:
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).
[email]
Proposal:
Resolution:
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.
    
[email]
240specn/ametaDesignClosedLorrie Cranor
Title: comments from P3P Specification working group
Description:
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
[email]
Proposal:
Resolution:
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.
[email]
241specn/ametaDesignClosedJoseph Reagle
Title: detaching and inserting XML in one document from another (encryption issue)
Description:
# 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.
[email]
Proposal:
Resolution:
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.
[email]
242specn/ametaDesignClosedJoseph Reagle
Title: Editorial: SOAP Version 1.2 Part 0: Primer - about implementations
Description:
#    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?
[email]
Proposal:
Resolution:
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.
[email]
243specn/ametaDesignClosedJoseph Reagle
Title: SOAP Version 1.2 Part 0: Primer & part 1 - implementations
Description:
#     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."
[email]
Proposal:
Resolution:
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. 
    
[email]
244specn/aEditorialDesignClosedJoseph Reagle
Title: SOAP Version 1.2 Part 0: Primer - define method signature
Description:
#    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.
[email]
Proposal:
Resolution:
The expression "method signature" has been removed, and therefore does not 
need to be defined. Words such as "method description" are used where 
appropriate.
[email]
245specn/aEditorialDesignClosedJoseph Reagle
Title: SOAP Version 1.2 Part 0: Primer - exemple 5b
Description:
#    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>
[email]
Proposal:
Resolution:
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.
[email,email]
246specn/ametaDesignClosedJoseph Reagle
Title: SOAP Version 1.2 Part 0: Primer - header and body definition
Description:
#   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?
[email]
Proposal:
Resolution:
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.
[email]
247specn/aEditorialDesignClosedJoseph Reagle
Title: SOAP Version 1.2 Part 0: Primer - Editorial
Description:
#    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.
[email]
Proposal:
Resolution:
This comment has been incorporated into the editor's copy of the Primer
[email]
248specn/aEditorialDesignClosedJoseph Reagle
Title: Editorial - Harmonizing example captions and descriptions
Description:
#    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.
[email]
Proposal:
Resolution:
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.
    
[email]
249specn/ametaDesignClosedJoseph Reagle
Title: SOAP Version 1.2 Part 1: Messaging Framework
Description:
# 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.
[email]
Proposal:
Resolution:
Regarding issue 249, we are moving section 1.2.2 from the specification.
[email]
250specn/ametaDesignClosedJoseph Reagle
Title: SOAP Version 1.2 Part 1 - definition of a role
Description:
# 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.
[email,email]
Proposal:
Resolution:
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.

* * * * *
    
[email]
251specn/ametaDesignClosedJoseph Reagle
Title: SOAP Version 1.2 Part 1 - Mandatory SOAP headers
Description:
# 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.
[email]
Proposal:
Resolution:
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.
[email]
252specn/ametaDesignClosedJoseph Reagle
Title: SOAP Version 1.2 Part 1 - SOAP Message Construct
Description:
# 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.
[email]
Proposal:
Resolution:
The WG decided to close issue 252 as it is a duplicate of issue 241
[2] (that you also raised).
253specn/aEditorialDesignClosedJoseph Reagle
Title: SOAP Version 1.2 Part 2 - URIs in SOAP
Description:
# 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.
[email,email]
Proposal:
Resolution:
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.
    
[email]
254specn/ametaDesignClosedJoseph Reagle
Title: SOAP Version 1.2 Part 2 vs RDF datamodel
Description:
# 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?
[email]
Proposal:
Resolution:
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.
[email]
255specn/aEditorialDesignClosedArt Salwin
Title: SOAP Version 1.2 Part 0 - Clarify what the parameters are in examples 4 and 5
Description:
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.
[email]
Proposal:
Resolution:
This comment has been incorporated into the editor's copy of the Primer
[email]
256specn/aEditorialDesignClosedMartin Duerst
Title: Printing on A4 paper
Description:
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.
[email]
Proposal:
Resolution:
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.
  
[email]
257specn/aEditorialDesignClosedMartin Duerst
Title: Part 0 - Examples should be more international
Description:
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 :-)
[email]
Proposal:
Resolution:
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".
  
[email]
258specn/aEditorialDesignClosedMartin Duerst
Title: Part 0 - Explain why xml:lang is important
Description:
Example 6: The use of xml:lang="en-US" is very good. A comment
 saying why xml:lang is important would be even better.
[email]
Proposal:
Resolution:
This comment has been incorporated into the editor's copy of the Primer
[email]
259specn/aEditorialDesignClosedMartin Duerst
Title: Part 0 - change x:date
Description:
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.
[email]
Proposal:
Resolution:
This comment has been incorporated into the editor's copy of the Primer
[email]
260specn/aEditorialDesignClosedMartin Duerst
Title: Part 0 - explain rules for charset with application/soap+xml
Description:
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.
[email]
Proposal:
Resolution:
This comment has been incorporated into the editor's copy of the Primer
[email]
261specn/aEditorialDesignClosedMartin Duerst
Title: Part 0 - choose character encoding UTF8/16
Description:
> 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).
[email]
Proposal:
  See Gudge's proposal and following thread.
  See Gudge's amended proposal and following thread.
  See Gudge's second amended proposal and following thread.
  
Resolution:
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].
[email]
262specn/aEditorialDesignClosedMartin Duerst
Title: Part 0 - significant whitespace?
Description:
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).
(See also 208) [email]
Proposal: See Gudge's proposal
Resolution:
The language in the specification will be amended to make sure it is clear
that only insignificant whitespace can be ignored.
[email]
263specn/aEditorialDesignClosedMartin Duerst
Title: Part 0 - comments on <reason>
Description:
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.
[email]
Proposal:
Resolution:
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.
  
[email]
264specn/aEditorialDesignClosedMartin Duerst
Title: Part 0 - section 6 - URIs
Description:
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.
[email]
Proposal:
Resolution:
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].
  
[email]
265specn/aEditorialDesignClosedMartin Duerst
Title: Part 0 - section 7.3 - Feature conflicts
Description:
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.
[email]
Proposal:
Resolution:
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."
  
[email]
266specn/ametaDesignClosedMartin Duerst
Title: Part 2 - Mixed content representation
Description:
2: How is XML mixed content represented in this graph model?
Can it be represented? If not, this is a serious problem for
internationalization.
[email]
Proposal:
Resolution:
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.
[email]
267specn/aEditorialDesignClosedMartin Duerst
Title: Part 2 - section 3.1.2 Editorial.
Description:
 3.1.2: encoding simple values:
 There should be a note mentioning that most characters in the
 C0 range cannot be represented in XML.
[email]
Proposal:
Resolution:
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]). 
  
[email]
268specn/ametaDesignClosedMartin Duerst
Title: Part 2 - properties datatypes
Description:
5.1.1: Properties are restricted to simple datatypes. This may
   cause serious problems for internationalization.
[email]
Proposal:
Resolution:
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.
[email]
269specn/aEditorialDesignClosedMartin Duerst
Title: Part 2 - section 7.5.1.3 - editorial
Description:
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.
[email]
Proposal:
Resolution:
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.
  
[email]
270specn/aEditorialDesignClosedMartin Duerst
Title: Part 2 - Appendix A - Editorial
Description:
- 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.
[email]
Proposal:
Resolution:
  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.
  
[email]
271specn/aEditorialDesignClosedMartin Duerst
Title: General - acknoledgments section
Description:
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 (apologies to Noah for picking him as an
example).
[email]
Proposal:
Resolution:
The XML Protocol WG has decided to close issue 271 raised by you by
adjusting the list of present and former WG members and their
affiliations. You can find the updated list for present members at [2]
and former members at [3]. For obvious reasons, the lists may of course
still change.
  
[email]
272specn/aEditorialDesignClosedMartin Duerst
Title: Part 0 - editorial comments
Description:
My impression is that this is not really a primer. Even the
first example is already very long. In various places, issues
such as GET vs. POST,... are discussed. Although such issues are
very important, their discussion in the Primer seems to be more
a reflection of the fact that tehy were disucssed extensively
in the WG, rather than being written with careful consideration
for beginners.
(...)
2.2.2, "Part 2 Section 4.1.1provides": ed.: space missing.
There are other places where a space before or after a link
got lost.

2.4, last table (unnumbered): having two columns, one for intermediary
and another for ultimate receiver, seems completely unnecessary.
(...)
3.1.1, "RDF format for the itinerary might have been choosen":
There are too many might, could,... in the spec overall. This is
a typical example.

3.1.2, before example 13: ed: that the all the -> that all the
[email]
Proposal:
Resolution:
This comment has been incorporated into the editor's copy of the Primer
[email]
273specn/aEditorialDesignClosedMartin Duerst
Title: Part 0 - 1.1, 'pure information retrieval' and GET
Description:
1.1, 'pure information retrieval': GET requests can be used
very appropriately for many more things than 'pure information
retrieval'. Assume a web service that accepts XML Schema dates
and returns dates formatted e.g. for Japanese cheques. While
the service would do calculations, it would have a very high
cachability.
[email]
Proposal:
Resolution:
This comment has been incorporated into the editor's copy of the Primer
[email]
274specn/aEditorialDesignClosedMartin Duerst
Title: Part 0 - Content-Type missing.
Description:
3.2, example 14: Content-Type missing.
[email]
Proposal:
Resolution:
This comment has been incorporated into the editor's copy of the Primer
[email]
275specn/ametaDesignClosedMartin Duerst
Title: Part 0 - This currently doesn't look very inviting
Description:
3., paragraph starting with 'However, a soap message may travel':
This and other places show how 'weak' soap currently is. Rather
than being a well-defined, complete protocol layer that can
easily be used from higher layers and mapped to lower layers,
it seems to be a collection of options, and even for the simplest
uses, a large number of things have to be selected/specified again
by each application. This currently doesn't look very inviting.
[email]
Proposal:
Resolution:
The XMLP WG has discussed your comment on the SOAP 1.2 Primer, and decided to 
close it with no change to the referenced section of the Primer. The referenced 
primer text merely captures in informal terms some aspects of the protocol 
binding framework specified or implied in the normative parts of the SOAP specification. 
Thus your comment appears to be a general observation on what you feel to be 
the shortcomings of the SOAP binding framework rather than a request for 
specific changes to the Primer.
  
[email]
276specn/aEditorialDesignClosedMartin Duerst
Title: Part 0 - Why does the sender need soap
Description:
3.2, just before example 14: Why does the sender need soap
capabilities? Somebody could just send a soap message in an
email with a simple mua, couldn't they?
[email]
Proposal:
Resolution:
This comment has been incorporated into the editor's copy of the Primer
[email]
277specn/ametaDesignClosedMartin Duerst
Title: Part 1 - general comments
Description:
General: The use of URIs in some places and qnames in other places
is arbitrary and very confusing. Except for element/attribute names,
URIs should always be used. This would also simplify mapping to
description languages,...

General: Compared to other W3C specs, soap uses a very large number
of namespaces. Many of these namespaces in turn are used for very
few things. This creates an unnecessary overhead in particular
for small messages (as they may e.g. be used on small devices),
and overall seems quite unnecessary.
[email]
Proposal: See email and email.
Resolution:
Issue 277 contains two parts:

1 - The use of URIs in some places and qnames in other places
is arbitrary and very confusing. Except for element/attribute names,
URIs should always be used. This would also simplify mapping to
description languages,...

2 - Compared to other W3C specs, soap uses a very large number
of namespaces. Many of these namespaces in turn are used for very
few things. This creates an unnecessary overhead in particular
for small messages (as they may e.g. be used on small devices),
and overall seems quite unnecessary.

Part 1 resolution:
Since your review of the spec, it has evolved, and in several places the 
usage of QNames has been replaced by the usage or URIs. Furthermore, the 
working group has agreed upon the following resolution for closing this 
first part of the issue:
- in Part 1, 5.4.1.3 SOAP Value Element (with Subcode parent)
we continue using QNames for representing the SOAP Value Element in Faults.
<rationale>
this may be inconsistent with other usage of QNames, but the WG thinks 
that the change to URIs was not necessary and would have a great impact 
on current implementation of SOAP 1.2.
</rationale>

- in Part 1, 5.4.7 VersionMismatchFaults
- in Part 1, 5.4.8 mustUnderstand Faults
- in Part 2, 2.2 Graph Nodes
- in Part 2, 3.1.4 Computing the Type Name property
- in Part 2, 3.1.4.1 itemType Attribute Information Item
we continue using QNames in those places.
<rationale>
in all those places, QNames are used for refering to Element Information 
Item Names or Attribute Information Item Names. Consequently, the WG 
thinks the usage of QNames is appropriate.
</rationale>

- in Part 2, 5.1.1 Properties
we will name properties with URIs rather than with QNames.
<rationale>
it seems more coherent to use URIs here, and the change should not have 
too much impact on current implementations.
</rationale>

Part 2 resolution:
- Keep http://www.w3.org/2002/06/soap-envelope namespace.
<rationale>
This is the main spec namespace.
</rationale>

- Merge http://www.w3.org/2002/06/soap-faults namespace and
http://www.w3.org/2002/06/soap-upgrade namespace into
http://www.w3.org/2002/06/soap-envelope namespace.
<rationale>
Both namespaces are used in the main part of the SOAP
1.2 specification and are tightly linked with the processing of SOAP
messages.
</rationale>

- Keep http://www.w3.org/2002/06/soap-encoding namespace.
<rationale>
This namespace is used for defining aii in an independant part of the spec.
</rationale>

- Keep http://www.w3.org/2002/06/soap-rpc namespace.
<rationale>
This namespace is used for defining an eii in an independant part of the
spec.
</rationale>

- Remove http://www.w3.org/2002/06/soap/mep/ namespace and
http://www.w3.org/2002/06/soap/mep/FailureReasons/ namespace.
<rationale>
They are not used anymore.
</rationale>

- Remove http://www.w3.org/2002/06/soap/bindingFramework/ExchangeContext/
namespace, http://www.w3.org/2002/06/soap/mep/request-response/
namespace and http://www.w3.org/2002/06/soap/features/web-method/
namespace.
<rationale>
Those namespaces were only used for identifying properties with QNames. 
As properties are now identified with URIs, they are not used anymore.
</rationale>

In addition the WG agreed to change the name of the envelope Element 
Information Item found in the old http://www.w3.org/2002/06/soap-upgrade 
namespace to supportedEnvelope to avoid collision with the envelope 
Element Information Item found in the 
http://www.w3.org/2002/06/soap-envelope namespace.
  
[email]
278specn/aEditorialDesignClosedMartin Duerst
Title: Part 1 - editorial
Description:
Example 1 (nit): The message should probably expire a bit later,
to avoid that it's never seen because the receiver didn't have
time at the right moment.

2.6: "at-most one fault" -> "at most one fault"

2.7.1: Re-inserting ... emphasizes the need to process them at
each soap node ...: weird wording. Maybe: Processing is defined
here in terms of reinserting (rather than leaving things in place)
to emphasize the need ....

5.2.3: "MAY be omitted if its value would have been ...": another
example of 'would'.

5.3.1: Please add: "* May have any number of element or attribute
children." It would be strange if body child elements had to be
CDATA only.

7.1 ed: side affects -> side effects

7.3.1 ed: 'associated that protoco': 'with' missing.
[email]
Proposal:
Resolution:
>Example 1 (nit): The message should probably expire a bit 
>later, to avoid that it's never seen because the receiver 
>didn't have time at the right moment.

Example 1 has NOT been changed. The point is that if the message is not
processed before 2pm then it's too late.

>2.6: "at-most one fault" -> "at most one fault"

done

>2.7.1: Re-inserting ... emphasizes the need to process them at 
>each soap node ...: weird wording. Maybe: Processing is 
>defined here in terms of reinserting (rather than leaving 
>things in place) to emphasize the need ....

Now says: "Processing is defined here in terms of re-inserting header
blocks (rather than leaving them in place) to emphasize the need to
process them at each SOAP node along the SOAP message path."

>5.2.3: "MAY be omitted if its value would have been ...": 
>another example of 'would'.

Now says: "A SOAP intermediary MAY omit the SOAP mustUnderstand
attribute information item if its value is "false"

>5.3.1: Please add: "* May have any number of element or 
>attribute children." It would be strange if body child 
>elements had to be CDATA only.

done

>7.1 ed: side affects -> side effects

done

>7.3.1 ed: 'associated that protoco': 'with' missing.

done
[email]
279specn/aEditorialDesignClosedMartin Duerst
Title: Part 1 - active intermediaries
Description:
2.7.2 Active Intermediaries: Are these part of the processing
model, or is this a way to 'cheat' around the processing model?
It sounds as if they can do just about anything, which looks
highly suspicious.
[email]
Proposal:
Resolution:
The XML Protocol WG has decided to close issue 279 without
changes to the specification. The reason is that SOAP 1.2 part 1,
section 2.7.2 [2] already states that active intermediaries must follow
the same rules as forwarding intermediaries:

"In addition to the processing performed by forwarding intermediaries,
active intermediaries undertake additional processing that can modify
the outbound message in ways not described in the inbound message."
    
[email]
280specn/aEditorialDesignClosedMartin Duerst
Title: Part 1 - change the SOAP Processing Model
Description:
3.2, point 2: Is it allowed to just change the soap processing
model? In arbitrary ways? or are there restrictions?
[email]
Proposal:
Resolution:
You have asked whether SOAP Modules were allowed to change the 
soap processing model in arbitrary ways, or whether they are any 
restrictions (Part 1, Section 3.2, bullet 2 [now bullet 3]).

The XMLP WG has decided to close issue 280 by adding the 
following text:

"The SOAP extensibility model does not limit the extent to
which SOAP can be extended. Nor does it prevent extensions
from modifying the SOAP processing model from that described
in Section 2.6"
  
[email]
281specn/aEditorialDesignClosedMartin Duerst
Title: Part 1 - multiple features
Description:
4.2, multiple features: 'MUST provide any info necessary for
their successful use in combination': Is it okay to say
'feature A and B cannot be used together', or is this not allowed?
[email]
Proposal:
Resolution:
The XMLP WG has closed this issue by incorporating the following 
text into Part 1.

---------------------
Revised text:

In cases where multiple features are supported by a binding specification, the
specifications for those features MUST provide any information necessary for 
their successful use in combination. Similarly, any dependencies of one
feature on another (i.e. if successful use of one feature depends on use or 
non-use of another) MUST be specified. This binding framework does not provide 
any explicit mechanism for controlling the use of such interdependent features.
  
[email]
282specn/aEditorialDesignClosedMartin Duerst
Title: Part 2 - Editorial
Description:
Intro: ed) The list of points (1.-7.) mixes full sentences and
nominal phrases, which is very awquard to read.

2.2.1, title (ed): looks strange. I suggest something like
'single-reference and multi-reference nodes'.
3.: A simple example showing a model graph and one or two

possible encodings is urgently needed because it will make
reading and understanding this section a lot easier for a
lot of people.

3.1.6: ed
[2]   nextConcreteSize   ::=   " " concreteSize: The notation for
space is confusing. Better use something explicit
(such as S

4.1.2: "the 6.4 Web Method Specification Feature feature": 'feature feature'
sounds weird. (ed)

4.2.2, 3rd bullet point: It is unclear here if a return value
has to be present for a procedure that can return various values,
one of which being 'void', in the case where the actual return
value is 'void'. (yes seems the correct answer to me, to avoid
counting wrong, but then how exactly will this be represented)

4.2.3, 1st para:
'<body> MUST contain only a single child element' and 'is constrained
to produce a single tree' are not the same. The former can lead
to a graph e.g. with cycles as long as all nodes in the graph
can be reached by following edges starting from a single node.
(such a thing is probably called a 'single-rooted graph', but
maybe it's called something else).

>>>>
tem 4:
'or when there is a mismatch ...': This mismatch has to be
clarified/restricted, otherwise everything can be a env:Sender
fault.

4.4, Note: 'if the receiver does support' ???
'if the receiver does NOT support' seems to make more sense.

5.1.2 The figure should be numbered and labeled, and should be
redone to look sharper. (ed)

6.2.2 This should make clear that there are no soap intermediaries.
(I hope I got this right)

7.1, ed: performingsimilar: add space

7.5.1.2, 415: support Content-type: add 'the'
ed       500: an SOAP fault->a SOAP fault

table 21, ed: 'has generating': fix grammar
[email]
Proposal:
Resolution:
The editors have incorporated your suggested changes, albeit the 
ones listed below:
   * Did NOT change title of 2.2.1.  
   * Have not put examples into section 3, this should go into 
     the primer instead.  
   * Did NOT change 3rd bullet of 4.2.2.
[email]
283specn/aEditorialDesignClosedMartin Duerst
Title: Part 2 - enc:MissingID
Description:
3.2: enc:MissingID: this sounds right only in some cases. In others,
'DuplicateID' or so seems better, or change to 'IDProblem' or so
if you want just one subcode.
[email]
Proposal:
Resolution:
You have raised an issue enc:MissingID vs. enc:DuplicateID.

The XMLP WG has decided to close this issue by adding 
enc:DuplicatedID and modifying the prose accordingly. Note that 
we have *not* provided a subcode for the case where *both* id and 
ref attributes appear on an element.
  
[email]
284specn/aEditorialDesignClosedMartin Duerst
Title: Part 2 - 'binding-specific address of the target soap node'
Description:
4. 'binding-specific address of the target soap node': My understanding
up to here was that soap nodes were identified by an (any)URI, without
this being binding-specific. Please clarify here or earlier.
[email]
Proposal:
Resolution:
The XMLP WG has decided to adopt your suggested change of 
removing "binding-specific" in the sentence "binding-specific 
address of the target soap node".
[email]
285specn/aEditorialDesignClosedMartin Duerst
Title: Part 2 - App B - Clarifications
Description:
B: 'validation ... MUST NOT be required by conforming processors':
Does this mean: 'conforming processors are not required to validate'
or 'it is forbidden that a conforming processor validates' or what?

B: Could there be a feature/module requiring validation in a certain
way (rather than this being purely application-level)?

B2: 'Validation against the minimum schema will not succeed': WHY?
This seems wrong.

B3: '...schemas could be constructed ... certain graphs': Why
only graphs? Couldn't it be just about any kind of data?
[email]
Proposal:
Resolution:
The XMLP WG has decided to clarify Appendix B (now Appendix C) as 
per your request for clarification. Changes to this appendix 
are highlighted [2] in red (deletions) and green (additions).
[email]
286specn/aEditorialDesignClosedMartin Duerst
Title: Part 2 - Is a soap intermediary a http intermediary?
Description:
7.1, first note: Is a soap intermediary a http intermediary?
[email]
Proposal:
Resolution:
You asked whether in 7.1, first note, the intermediary was "a 
soap intermediary or an http intermediary"?

The XMLP WG has decided to closed this issue by inserting the 
following text:

   "(which may or may not also be SOAP intermediaries)"
   
[email]
287specn/aEditorialDesignClosedPhilippe Le Hégaret
Title: Part 0 - Example 7b - contradicting text and table
Description:
2.4 SOAP Processing Model:

(this section would better with more subsections)
[...]

Example 7b
[...]
     <r:aThirdBlock xmlns:r="http://example.com">
          ::::
    </r:aThirdBlock>
[...]
In Example 7b, the ultimate recipient of the message - the SOAP
processor which plays the "ultimatereceiver" role - must process both
the Body as well as the header block aThirdBlock. 
[...]
             Node intermediary ultimate receiver
mustUnderstand     
"true"         must process   must process
"false"        may process     may process
absent         may process     may process
[...]
Does the ultimate receiver must process the block aThirdBlock as
described in the text or may process it, as described in the table?
[email]
Proposal:
Resolution:
This comment has been incorporated into the editor's copy of the Primer
[email]
288specn/aEditorialDesignClosedPhilippe Le Hégaret
Title: Part 1 - notations
Description:
General comment: as a user, this specification is difficult to read. The
Infoset-like notation would be better with a BNF notation. I wish
the editors didn't follow the example of the XML Schema specification
before rewriting the SOAP spec. The style used plays against the
technology described in the specification imho.

It is unfortunate that SOAP and WSDL are not used the same conventions
for markup. SOAP uses capitalized-word and WSDL lowercases. I noticed
that SOAP Part 1 contains several occurences of "mustUnderstand" and
"MustUnderstand" btw.
[email]
Proposal:
Resolution:
After carefull examination, the XMLP WG rejected your proposal to 
use BNF instead of Infoset.

The WG also wishes to point out that "mustUnderstand" (lowercase 
"m") is an attribute, and "MustUnderstand" (capital "M") is a 
fault code.

In accordance, the WG has decided to close this issue without any 
further action.
  
[email]
289specn/aEditorialDesignClosedPhilippe Le Hégaret
Title: Part 1 - How does an intermediary do when receiving a fault?
Description:
Section 5.4:
How does an intermediary do when receiving a fault? Is it guarantee to
be forwarded to the original Sender (or previous intermediary) if known?
[email]
Proposal:
Resolution:
The XMLP WG has decided to close issue 289 without any further 
action. The WG considers that the precise definition of the 
forwarding feature is out-of-scope for this specification.
[email]
290specn/aEditorialDesignClosedPhilippe Le Hégaret
Title: Part 1 - How does a SOAP Node know the SOAP version to use?
Description:
Section 5.4.7:
The envelope (lowercase, without namespace name) element is used to
indicate a mismatch SOAP version in the Envelope (capitalized, with
namespace name) element. How does a SOAP Node know the SOAP version to
use?
[email]
Proposal:
Resolution:
  Rereading the specification, I realized that the response to my question
  is in fact described in the envelope documentation:
  [[
  The Upgrade header block consists of an Upgrade element information
  item  containing an ordered list of qualified names of SOAP envelopes
  that the SOAP node supports in the order most to least preferred.
  ]]
[email]
291specn/ametaDesignClosedPhilippe Le Hégaret
Title: Part 1 - Why does the envelope element not have a namespace name?
Description:
Why does the envelope element not have a namespace name?
[email]
Proposal:
Resolution:
The XML Protocol (XMLP) WG has decided to close issue 291, which you
originated, with the following resolution.

1. The "envelope" element is renamed to "Envelope"
2. The (new) "Envelope" element is made part of the
"http://www.w3.org/2002/06/soap-upgrade" namespace
[email]
292specn/ametaDesignClosedJacek Kopecky
Title: RPC and Encoding fault combinations
Description:
 In SOAP Encoding [1] it says that a SOAP receiver

 >>SHOULD generate an "env:Sender" SOAP fault with a subcode 
 of enc:MissingID if the message violates the constraints on id 
 and ref attribute information items (see 3.1.5.3 Constraints on 
 id and ref attribute information items).<<

  In SOAP RPC [2] it says that 

  >>A fault with a Value of "env:Sender" for Code and a Value of 
  "rpc:BadArguments" for Subcode MUST be generated when the
  receiver cannot parse the arguments or when there is a mismatch
  between what the receiver expects and what the sender has sent.<<

   It is unclear what should happen when both these conditions are
   met - RPC server cannot parse arguments because of a missing ID.  
   Technically, the RPC fault is a MUST and the Encoding fault is a
   SHOULD, so the former takes precedence, but is this the
   intention?

    I'd like a clarification on the relationship of these faults.
[email]
Proposal:
Resolution:
The WG agreed with your concern and decided to close this issue 
by adding the following text to section 2.6 of SOAP 1.2 Part 1[2]:

"A message may contain or result in multiple errors
during processing. Except where the order of detection is
specifically indicated (as for mustUnderstand faults above),
a SOAP node is at liberty to reflect any  single fault from the
set of possible faults prescribed for the errors encountered. The
selection of a fault need not be predicated on the application of the
"MUST", "SHOULD" or "MAY" keywords to the generation of the fault,
with the exception that if one or more of the prescribed
faults is qualified with the "MUST" keyword, then any one fault from the
set of possible faults MUST be generated."
  
[email]
293specn/aEditorialDesignClosedJ-J Moreau
Title: Editorial - Primer - replace "::::" by "..."
Description:
Examples

I would suggest replacing the following symbols:
    ::::
(i.e. 4 colons) by the more widespread notation:
    ...
(i.e. 3 dots [ellipsis]).
[email]
Proposal:
Resolution:
This comment has been incorporated into the editor's copy of the Primer
[email]
294specn/ametaDesignClosedJ-J Moreau
Title: part2 - message exchange context out of nowhere?
Description:
Message Exchange Context

The notion of Message Exchange Context (MEC) is central to the
Binding Framework. However:

   * No formal definition for it is given in the glossary. There
     is only a vague description for it in part 2, section 5.1.2.
   * No real indication is given as to how a MEC is initialized
     or, possibly, transferred. For example, how does a SOAP node
     determine it should instantiate
     "context:ExchangePatternName" to
     "http://www.w3.org/2002/06/soap/mep/request-response/" and
     not to something else? IMO, part 2 should be explicit,
     either saying this is implementation specific, or providing
     a standard means for indicating, for example, the features
     being used.
[email]
Proposal: See proposal. See second proposal.
Resolution:
On last weeks telcon I took an action to flesh out my proposed
resolution for issue 294 to show the text to be added to the spec.
Here it is.

<current>
5.1.2 Property Scope

Properties within a SOAP node can differ in terms of their scope and
the origins of their values. Some properties are scoped per
message-exchange, while others have a wider significance. For example,
the scope of a SOAP message property is per message-exchange, but the
scope of a User Identity property may extend beyond the exchange of a
single message. The values of some properties arise directly from the
operations of the SOAP node and message exchanges, while others arise
in implementation specific ways due to the local environment. As shown
in the figure below, we make the distinction between per
message-exchange and more widely scoped properties by assigning them to
different containers called Message Exchange Context and Environment
respectively. All properties, regardless of their scope, are shared by
SOAP and a particular Binding.

<Graphic caption="Model describing properties shared between SOAP and
Binding"/>

The values of properties in Environment may depend upon local
circumstances (as depicted by the external arrow from Environment in
the figure above). More specifically, the properties in the example
could be influenced by an Operating System User ID on whose behalf a
message exchange is being executed. The mapping of information in a
particular implementation to such properties is outside the scope of
the binding framework although the abstract representation of such
information as properties is not.
</current>

<proposed>
5.1.2 Property Scope

Properties within a SOAP node differ in terms of their scope and the
origins of their values. As shown in the figure below, we make the
distinction between per message-exchange and more widely scoped
properties by assigning them to different containers called Message
Exchange Context and Environment Context respectively. All properties,
regardless of their scope, are shared by a SOAP node and a particular
Binding.

<Graphic caption="Model describing properties shared between SOAP and
Binding"/>

5.1.2.1 Message Exchange Context

A message exchange context is a collection of properties whose scope is
limited to an instance of a given message exchange pattern. An example
of a message exchange context property is the identifier of the message
exchange pattern in use.

5.1.2.2 Environment Context

The environment context is a collection of properties whose scope
extends beyond an instance of a given message exchange pattern.
Examples of environment context properties are the IP address of the
SOAP node or the current date and time.

The values of properties in Environment may depend upon local
circumstances (as depicted by the external arrow from Environment in
the figure above). More specifically, the properties in the example
could be influenced by an operating system user ID on whose behalf a
message exchange is being executed. The mapping of information in a
particular implementation to such properties is outside the scope of
the binding framework although the abstract representation of such
information as properties is not.
</proposed>

<current>
7.5 MEP Operation

For binding instances conforming to this specification:

*  A SOAP node instantiated at an HTTP client may assume the role (i.e.
the property context:Role ) of "RequestingSOAPNode".

*  A SOAP node instantiated at an HTTP server may assume the role (i.e.
the property context:Role ) of "RespondingSOAPNode".

The remainder of this section describes the MEP state machine and its
relation to the HTTP protocol. In the state tables below, the states
are defined as values of the property context:State (see 6.2 SOAP
Request-Response Message Exchange Pattern), and are of type xs:anyURI .
For brevity, relative URIs are used, the base URI being the value of
context:Role .
</current>

<proposed>
7.5 MEP Operation

For binding instances conforming to this specification:

*  A SOAP node instantiated at an HTTP client may assume the role (i.e.
the property context:Role ) of "RequestingSOAPNode".

*  A SOAP node instantiated at an HTTP server may assume the role (i.e.
the property context:Role ) of "RespondingSOAPNode".

The remainder of this section describes the MEP state machine and its
relation to the HTTP protocol. In the state tables below, the states
are defined as values of the property context:State (see 6.2 SOAP
Request-Response Message Exchange Pattern and 6.3 SOAP Response Message
Exchange Pattern), and are of type xs:anyURI. For brevity, relative
URIs are used, the base URI being the value of context:Role.

The message exchange pattern in use is indicated by the HTTP method
used in the request. HTTP GET corresponds to the SOAP-Response MEP,
HTTP POST corresponds to the SOAP Request-Response MEP.
</proposed>


[1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0118.html
--
Marc Hadley

---------------------------------------------------
From [3]:

Posting on behalf of Jacek. Based on today's XMLP WG meeting, and addition
to Marc's proposal.

======================================
7.4 Supported Features

An implementation of the SOAP HTTP Binding MUST support the following
feature:

* "http://www.w3.org/2002/06/soap/features/web-method/" (see 6.4 Web
 Method Specification Feature)

<addition>
 The possible values of webmeth:Method property are restricted in this HTTP
 binding according to the MEP in use (as present in
 context:ExchangePatternName):

          context:ExchangePatternName                   | webmeth:Method
--------------------------------------------------------+-----------------
 "http://www.w3.org/2002/06/soap/mep/request-response/" |     "POST"
 "http://www.w3.org/2002/06/soap/mep/soap-response/"    |     "GET"


  Note: other SOAP Version 1.2 bindings to HTTP may permit other combinations
  of context:ExchangePatternName and webmeth:Method.
</addition>
  ======================================
  
[email]
295specn/aEditorialDesignClosedPaul Prescod
Title: URI/RPC Primer Changes
Description:
The Primer implies that using URIs correctly is only important in an RPC
context. But the truth is that *whenever* SOAP is used over HTTP, the
SOAP specification recommends that the URI should be
resource-identifing. The primer also has a confusing paragraph-ordering
in that it concentrates on resource retrievals and then switches to
mentioning POST later. Reading the beginning of the section you would
never expect what comes at the end.

=====
I propose to change the title:

  change: 3.1.3 Conveying Web-friendly RPCs
  to: 3.1.3 Web-friendly SOAP Messages

Then I propose to add at the very beginning:

add: "One of the most central concepts of the World Wide Web is that of
a URI as a resource identifier. SOAP services that use the HTTP binding
and wish to interoperate with other Web software should use URIs to
address all important resources in their service."

Then I propose to start the next paragraph with the phrase "For
example," 

  change: A very important - indeed predominant - use ...
  to: "For example, a very important - indeed predominant - use of the
   World Wide Web is pure information retrieval, "

Next I propose to remove references of the word "RPC" to indicate that
the points made are more general than RPC:

  change: There are many instances when RPCs are designed ....
  to: There are many instances when messages are designed ....

  change: with a parameter of the RPC representing the object .....
  to: with an element of the body representing the object ....

I do not believe that the word "typical" should be used to describe the
historical SOAP/RPC behaviour. Hopefully in a year what is typical will
have changed.

  change: In the typical SOAP/RPC usage scenario, the HTTP ...
  to: In some SOAP/RPC implementations, the HTTP ....

More removals of the over-specific "RPC":

  change: Even in this case, the HTTP POST with a SOAP message conveying
    the RPC can be represented in a Web-friendly manner. 
  to: Even in this case, the HTTP POST with a SOAP message can be
     represented in a Web-friendly manner. 

  change: As with the use of the GET, Part 2 recommends that any part of
      the RPC signature that serves
  to: As with the use of GET, any part of the message that serves

  change: The same parameters may, of course, be retained in the encoded
	RPC in the SOAP Body element.
  to: The same parameters may, of course be retained in the SOAP Body.

  change: Note, however, that the all the parameters in the RPC signature....
  to: Note, however that all of the resource-identifying elements have
    been retained
[email]
Proposal:
Resolution:
This comment has been incorporated into the editor's copy of the Primer
[email]
296specn/aEditorialDesignClosedPeter Drayton
Title: Message in Example 2 in Primer doesn't match prose exactly
Description:
SOAP Version 1.2 Part 0: Primer, Section 2.2.1, Example 2:

The prose describing the message says that the message is returned from
the travel service, requesting clarification on the choice of airports
in the departing city. However, the message itself doesn't (a) contain
any indication that it is a request for clarification; (b) indicate if
the request pertains to the outbound leg or the inbound leg; (c)
indicate if the request pertains to the departure or arrival airport of
a specific leg.

It is possible to claim that the target node provides the context for
processing the message, i.e the message might be sent to different
endpoints depending on which leg & choice of arrival/departure requires
clarification, and the endpoints might know that they are participating
in a conversational exchange and understand the flow, but I don't think
this is very clear. It also seems strange to me that the same
<itinerary> element is sent in both directions, with different child
elements and meaning. I don't think this is as clear as it could be for
a primer.

I'd suggest modifying example 2 to make the flow of messages back and
forth clearer. For example:

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"> 
 <env:Header>
   <m:reservation xmlns:m="http://travelcompany.example.org/reservation" 
       env:role="http://www.w3.org/2002/06/soap-envelope/role/next"
                     env:mustUnderstand="true">
    <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
    <m:dateAndTime>2001-11-29T13:35:00.000-05:00</m:dateAndTime>
   </m:reservation>
   <n:passenger xmlns:n="http://mycompany.example.com/employees"
       env:role="http://www.w3.org/2002/06/soap-envelope/role/next"
                   env:mustUnderstand="true">
    <n:name>John Q. Public</n:name>
   </n:passenger>
 </env:Header>
 <env:Body>
  <q:itineraryClarification
       xmlns:q="http://travelcompany.example.org/reservation/travel/">
    <q:departure>
      <q:departing>
        <q:airportChoices>
          JFK LGA EWR 
        </q:airportChoices>
      </q:departing>
    </q:departure>
    <q:return>
      <q:arriving>
         <q:airportChoices>
           JFK LGA EWR 
         </q:airportChoices>
      </q:arriving>
    </q:return>
   </q:itineraryClarification>
  </env:Body>
</env:Envelope>

This structure mirrors the prose, presuming the prose meant "...namely 
the choice of airports in the departing city *on both the outbound and
the inbound legs*". If the prose meant to only request clarification on
one of the legs, the sample could obviously be simplified.
[email]
Proposal:
Resolution:
Thank you for your comment, which has been listed as Issue 296 in the SOAP 1.2
Last Call Issues List. 

Your suggestion appears to be a good one, and I shall include it in the next 
revision of the SOAP 1.2 Primer.
  
[email]
297specn/ametaDesignClosedJacek Kopecky
Title: Generic compound types unnecessary
Description:
It is Systinet's position that the 'generics' in the SOAP Data
Model are unnecessary and their handling is unclear. We don't see
any use for 'generics' in the known uses of SOAP Encoding.
See also the posponed issue 185 [in 5].
[email]
Proposal:
Resolution:
the Working Group has decided to close issue 185 [1] and last call
issue 297 by removing generics from the SOAP Data Model (see bullet
1 in section 2.3 of Adjuncts [3]).

The rationale for this decision is that the WG agrees with the
originator of the issues that generics are unnecessary in the Data
Model.

The issue was discussed among the implementors (see latest discussion
thread [6]) and among the xml-dist-app community (see the latest
discussion thread [7]) without reaching any obvious consensus.

Additionally, the working group has asked for feedback on this issue by
introducing an editorial note at the end of section 2.3 of Adjuncts [3]
that asks explicitly whether generics should remain or should be
removed. The prevalent feedback has indicated that generics should be
removed. Also, the implementors among the WG members have confirmed that
they would welcome removing generics, with one exception of WebMethods,
who prefer generics to stay but don't oppose the majority of the
members.

Note that issues 365 [4] and 366 [5] are affected by this decision, too.
    
[email]
298specn/ametaDesignClosedJacek Kopecky
Title: RPC array representation unnecessary
Description:
It is Systinet's opinion that the array representation of RPC
invocation and results is unnecessary. The 'struct'
representation suffices because in most interface description
languages invocation parameters do have names. The situation is
similar to that of another W3C recommendation - RDF, where
properties are unordered and container membership properties are
named _1, _2 etc. to achieve ordering - [6].
 We are aware that adding array representation is the resolution
 for issue 180 [in 5], but we are not planning to implement this
 part of the SOAP RPC Representation.
  (The same comment can apply to arrays in the SOAP Data Model but
  we'd call it "going too far". 8-) )
[email]
Proposal:
Resolution:
This is to inform you that the XMLP WG has decided to close the Last
Call issue 298 by removing the array representation from the SOAP
RPC Representation, sections 4.2.1, 4.2.2 [2,3]. Also, mentions of this
representation will be removed from sectsion 4 a 4.2.3 [5,6].

The rationale: the WG has agreed with the initiator of the issue that
the array representation is unnecessary to achieve interoperable RPC
using SOAP. Currently, WSDL doesn't support normative description of RPC
services with positional parameters; furthermore, implementors from
various member companies have indicated that they would welcome removing
the array representation of RPC in SOAP. Lastly, array representation
caused some interoperability problems recorded in the soapbuilders
archive [4]. 
  
[email]
299specn/ametaDesignClosedJacek Kopecky
Title: RPC return value accessor too complex
Description:
 It is Systinet's opinion that the current way of identifying the
 RPC return value in the RPC result struct (via a known parameter)
 is too complex a solution for the problem and that it obscures
 the representation.
  Nevertheless, our implementation does support this; the concern
  is for ease of understanding for newcomers to SOAP.

<Amended when closing issue 245>
    This issue also covers issue 245
</Amended when closing issue 245>

[email]
Proposal:
Resolution:
The XMLP WG has decided to close issue 299 without taking any action.

The group felt that, although there is merit to your point about the
complexity of the RPC return value mechanism, a change now would affect
current implementations and that there is a risk to change at this last
stage in the process.   Users have an option to not use this in their
implementations.
  
[email]
300specn/ametaDesignClosedJacek Kopecky
Title: How is version transition handled in the HTTP binding?
Description:
In Part 1, appendix A [3], the handling of SOAP 1.1 messages by
SOAP 1.2 nodes is specified. It says that a node can generate a
SOAP 1.1 version mismatch fault. In SOAP 1.1 messages travel via
the HTTP binding using the content-type text/xml, whereas in SOAP
1.2 the messages travel using the content-type
application/soap+xml.
 Is the version transition still practical if current SOAP 1.1
 nodes only accept text/xml SOAP messages; so when they receive a
 "known" SOAP fault, it has an "unknown" content-type and
 therefore may not be recognized as a known fault?
[email]
Proposal: See Henrik's proposal
Resolution:
In response to issue 300 raised by you against the SOAP 1.2 Last
Call specification, the WG has decided to incorporate the text provided
in [1], which we believe clarifies the issue at hand. 
  
[email]
301specn/ametaDesignClosedJacek Kopecky
Title: Missing universal transport binding
Description:
 The SOAP 1.2 HTTP binding defines a binding to an application
 protocol; i.e. it only supports one application, and that is HTTP
 itself (also known as REST).
  Shouldn't the SOAP specification also contain at least one
  transport binding that can be used for all SOAP applications?  
  We suggest a TCP binding.
[email]
Proposal: Gudge proposes that we rule this out-of-scope and close it with no action. email
Resolution:
  The XMLP WG has decided to close issue 301 which you raised with no
  action taken.  The proposal to create a universal transport binding is
  considered out of scope as defined by the charter, which requires the WG to
  produce only one binding [2] (section 2.3).
  
[email]
302specn/ametaDesignClosedJacek Kopecky
Title: Data Model edges originating and not terminating
Description:
In the SOAP Data Model it is said about graph edges that they
are said to originate at a graph node and terminate at a graph
node. In Encoding section 3.1.3 bullet 4 it says that "if a graph
edge does not terminate in a graph node then..."
 Is it possible (from the point of view of the Data Model) for an
 edge not to terminate in a graph node? Isn't it contrary to the
 common definition of a graph edge? The SOAP Data Model doesn't
 define the term "edge" so the common definition has to be
 accepted.
  Our understanding is that there are no such edges (not
  terminating in a graph node); there may be "missing edges"
  instead that can be described in bullet 4 section 3.1.3.
[email]
Proposal:
Resolution:
The working group has decided to close this issue by adding the following
text to Section 2.1 [3]

"An edge MAY have only an originating graph node, that is be
outbound only. An edge MAY have only a   terminating graph node, that is
be inbound only."
  
[email]
303specn/ametaDesignClosedJacek Kopecky
Title: Fault for broken array attributes?
Description:
While SOAP Encoding specifies faults that are generated in cases
like missing ID and missing type; it does not specify faults that
should be generated in case of malformed encoding attributes
(like arraySize and itemType) and in case of inconsistency
between the array size and the actual number of members.
[email]
Proposal:
Resolution:
  The XMLP WG has closed its issue #303 judging that it is not necessary 
  to do anything and that the status quo is good.
  
[email]
304specn/ametaDesignClosedJacek Kopecky
Title: No one-way MEP
Description:
 SOAP is a messaging protocol. Before MEPs are introduced, it is
 inherently one-way. One-way MEP is a widely used one and one
 that's exploited in WSDL 1.1; the basis for another W3C
 specification-in-progress, WSDL 1.2. Moreover, SOAP Abstract
 Model has a one-way operation as one of the two basic operations.
  Also, the resolution [7] to issue 38 says that "the SOAP 1.2
  specification makes it easy to exchange one way and two-way
  messages." Also, issue 179 deals with one-way messaging; the
  resolution to this issue makes one-way messaging optional in
  bindings.
   Altogether, we'd like to see the SOAP 1.2 specification not only
   enable, but also provide a spec for one-way messaging.
[email]
Proposal:
Resolution:
 
This is to inform you that the XMLP WG has decided to close its Last
Call issue 304 with no changes to the SOAP 1.2 specs.

The WG acknowledges the importance of a one-way Message Exchange
Pattern, but the SOAP 1.2 specification is intentionally written as
extensible so that any party may add MEPs (or bindings and other
components). 

It is possible that the XMLP WG produces a one-way MEP later. Such a
document need not be synchronized in time with SOAP 1.2 specification.
    
[email]
305specn/ametaDesignClosedJacek Kopecky
Title: The SOAP Response MEP doesn't need sending+receiving states
Description:
(related to issue 239, maybe covered by it)

 It is unclear why this MEP needs the sending+receiving states in
 the state machines when there is nothing really that is sent from
 the requester to the responder. This also affects the states
 figure.
[email]
Proposal: See Henrik's proposal and following thread.
Resolution:
The WG agreed with your analysis and has 
closed this issue by renaming the SOAP Repsonse states as follows:

(i) Requesting SOAP node state "Sending+Receiving" becomes 
"Receiving"[2]
(ii) Responding SOAP node state "Receiving+Sending" becomes "Sending"[2]

The HTTP binding [3] was also modified to include new sections 
describing these states.
  
[email]
306specn/ametaDesignClosedJacek Kopecky
Title: Is use of Appendix A optional?
Description:
 It is unclear in the RPC Representation whether the links to
 Appendix A are a MUST (an identifier MUST be mapped to an XML
 name using Appendix A's algorithm) or a MAY (for a possible
 mapping algorithm see Appendix A).
[email]
Proposal: See thread
Resolution:
The Appendix titled "Mapping Application Defined Names to XML Names" will
be referenced from the appropriate sections of the SOAP 1.2 Part 2 spec
that describes the RPC Representation (probably sections 4.2.1 and 4.2.2),
and the mandate for using the mapping will be "SHOULD". More exact wording
can be found in [2] (although this will be modified slightly to accomodate
at least one other issue resolution).
  
[email]
307specn/ametaDesignClosedAdam Souzis
Title: overrestrictive constrainsts for "SOAP header block" and "SOAP Body child Element"?
Description:
Unless I'm missing something, the spec appears to disallow children 
elements for the child element information items of both the SOAP Header 
and the SOAP Body.

See:
5.2.1 SOAP header block

5.3.1 SOAP Body child Element

Both sections only state that they "MAY have any number of character 
information item children" but there is no mention allowing element 
information item children.

Perhaps you intended to define the "SOAP header block" and "SOAP Body child 
Element" as descendents of the SOAP Header and the SOAP Body element 
information items respectively and not as just the children?

As it stands now most of examples given in the spec are invalid, for 
example, Example 1 in Part 1, because n:priority is a child element of the 
"SOAP header block" n:alertcontrol and because m:msg is a child element of 
the "SOAP Body child Element" m:alert.

If the authors did indeed intend this restriction and these are indeed 
invalid examples, then I'm sure I would not be alone in protesting this as 
overly restrictive constraints.
[email]
Proposal:
Resolution:
 We acknowledge that this is a bug. The spec will be changed to allow
 header and body blocks to have element and character information items
 as children. 

 Thank you for bringing this error to the attention of the Working Group.
  
[emai]
308specn/aEditorialDesignClosedDon Box
Title: Editorial comments on Primer (RPC)
Description:
I am concerned that the Primer reinforces the myth that there are in
fact two (and only two) distinct worlds: document and rpc. It does this
by (a) calling out non-RPC applications by name (document), (b)
discussing RPC-specifics too early and (c) intermingling RPC-isms in
other broad/general concepts. Moreover, the specific examples seemed to
have a very artificial distinction.

Granted, the primer needs to address RPC-specifics such as <rpc:result>
and the convention of encoding the operation/method name as the QName of
the first child of Body. I'm all for that!

However, given that less than 5% of the normative specs even discuss RPC
(1842 words out of a total of 37042), it felt very strange that RPC
wound up permeating the primer as it did.

Also, there seems to be factoring issues, in that there is a co-mingling
of the presentation of broad SOAP features inside the RPC sections.
Specifically, in section 2.2.2 of the primer, the paragraph beginning
with "RPCs may also require additional information..." as this issue is
NOT specific to RPC but rather to any app that needs to augment the
schema/content of the body with additional contextual goo.
[email]
Proposal:
Resolution:
- Section 2.2.1 has been renamed "Conversational message exchanges", although 
this by itself may not not fully address the myth (document vs. rpc) that you 
feel is being propagated. However, the WG does not believe that the Primer 
propagates such a view. The examples are sufficiently varied - although following
one overall theme - to suggest the many uses of SOAP. In the RPC examples, the 
same example has been repeated in a different section to emphasize a different 
aspect, e.g., syntax in one section but a transfer mechanism in another. It 
would help if you could point out specific text in [0] where you feel the reader 
may be so misled.

- Early in the formulation of the contents of the Primer, the WG decided that 
the document should build up from the more straightforward scenarios - single 
message, request-response, fault handling,...- to the more complex features. 
Thus RPC was placed where it is today.

- As handling RPCs remains a requirement on SOAP 1.2 and a very common usage 
pattern currently, it is inevitable that there should be an emphasis on it in 
the Primer. In particular, a few more examples were chosen as RPCs to convey 
how not to do it in a Web Architecture incompatible way. This may account for 
the seeming emphasis. 

- Following other LC comments which have also suggested that section 2.2.2 
should concentrate on the RPC syntax issues, the discussion of web architecture 
compatibility has been removed from that section; section 3.1.3 concentrates on 
the web architecture compatible ways of conveying rpcs.

- Re you comment on section 2.2.2 "RPCs may require additional information...", 
please note that this was motivating the addition of a SOAP header in the 
example, to provide an example of item 6 from the list earlier in the section, 
the list itself being taken from part 2 describing RPCs. However, an additional 
note has been added (please see [0] same para) to point out that such 
info is not RPC specific.
  
[email]
309specn/aEditorialDesignClosedDave Beckett
Title: Comments on Primer - QNames
Description:
My main concern that stood out is the use of XML qnames, the
(namespace name, local name) pair, for identifiers.  This doesn't seem
particular webby to me - URIs are the web's identifiers.

The TAG has been discussing this:

  (DRAFT) TAG Finding: Using Qualified Names (QNames) as Identifiers in Content
    http://www.w3.org/2001/tag/doc/qnameids.html

but offers mostly observations.  This seemed relevant:

"Using QNames in untyped (#PCDATA or xs:string) attribute values or
element content places an additional burden on the processor that
was not anticipated by [XML Namespaces]."

Please consider this draft finding and the SOAP use of qnames.

In particular, SOAP seems to use all of qnames, uris and CDATA in
attribute values and element content as identifiers and it isn't
clear to me coming to this new, when this choice is made or why.
[email]
Proposal:
Resolution:
The XML Protocol issue #309 has been closed by the 
XML Protocol working group who felt that it is a duplicate of issue
#227 which 
is still to be resolved.
    
[email]
310specn/aEditorialDesignClosedDave Beckett
Title: Comments on Primer - Editorial - xmlns
Description:
2.1

m:reference contains something as element that could be a URI
but could look like a qname too given the use elsewhere
of qnames in element content.


Note why xmlns attributes are defined at the most local place in
env:Body rather than on doc element.  I assume this is a convention
for these examples rather than required, which

"In Example 1, the header contains two header blocks, each of which
is defined in its own namespace"

so are namespaces part of the SOAP model?  Are these XML namespaces?
Either way - if they are, mention it, if not, add an explanation

---

"The <tt>Body</tt> element ..."

I would rather the <tt>env:Body</tt> element was used throughout 
if talking about that precise thing rather than the element local name 
<tt>Body</tt>.
In this case the example uses <tt>env:Body</tt>, so changing it 
makes it more consistent.
[email]
Proposal:
Resolution:
This comment has been incorporated into the editor's copy of the Primer
[email]
311specn/aEditorialDesignClosedDave Beckett
Title: Comments on Primer - Editorial - example 4
Description:
2.2.2

Example 4 has the t:transaction "5" hanging about like this:

...    env:mustUnderstand="true" > 
                  5 
    </t:transaction>

which took me a while to work out that it was the element content. 
Maybe just me.

It has some additional odd formatting:

</m:reservation>   <o:creditCard xmlns:o="http://mycompany.example.com/financial">
		      
and indenting that doesn't help reading the XML structure (and SOAP
structs):

    <o:expiration>2005-02</o:expiration>
    </o:creditCard>

Example 4 title says two "in" parameters
How are the parameters 'in'?  It isn't clear from the example.  Is 
that the default?  Is it decided out of band?  
[email]
Proposal:
Resolution:
This comment has been incorporated into the editor's copy of the Primer
[email]
312specn/aEditorialDesignClosedDave Beckett
Title: Comments on Primer - Editorial - examples 7/7a - 5a
Description:
2.3

Example 7 - why is xmlns:f defined on env:Envelope and not the
env:Header or f:Misunderstood elements?  Is it convention again?

General note: Also noticed some XML args are using '', some ""
I understand these are equivalent, it just stands out to me.


2.4

Example 7a elided example stands out as curious why SOAP mixing use
of qnames URIs, and CDATA for identifiers i.e. why:

 <p:oneBlock xmlns:p="http://example.com" 
             env:role="http://example.com/Log">

and not:

 <p:oneBlock xmlns:p="http://example.com" 
             env:role="p:Log">

I guess it is suuppose roles are expected to be defined as an
unlimited set of terms, ie URIs, rather than as names in an XML
namespace.

I'm comparing to earlier use of the attribute env:encodingStyle
(takes URI value), env:mustUnderstand attribute (takes CDATA
with a fixed set of terms), env:Value element (takes qname value from
fixed set of terms)

It isn't obvious when to use these or why qnames/CDATA are
chosen for fixed sets of terms.

--

The phrase 'actor attribute' suddenly appears in middle of a
paragraph, and related to, the ultimateReceiver role and talks about
the absence of such an attribute indicating such a role, when actors
have never before been discussed!  (this is the first use of the word)
Is this a typo, and 'role attribute' was meant?

I noticed later on in the changes that the role attribute was renamed
from earlier versions, maybe this needs updating.

--

"The body element" para?

should be <tt>Body</tt> since talking about the element, not 
the general SOAP body.

--

in the unlabeled table
  "The following table summarizes how the processing actions"
  both columns are the same - why is this table needed?

  General: please add numbers, titles (summary?), anchors to all tables
  and link to them.


--------

Example 5a has different indenting levels, style from Example 4 - please
make them consistent.

Example 5a
'out' parameters - how is that indicated in this example?  Unlike
the example 5b which uses rpc:result, this example has no such
indicator.
[email]
Proposal:
Resolution:
This comment has been incorporated into the editor's copy of the Primer
[email]
313specn/aEditorialDesignClosedDave Beckett
Title: Comments on Primer - Editorial - Formatting & typos
Description:
3.1

para 3,4 formatting
HTTP:1)the -> HTTP: 1) the
ofHTTP -> of HTTP
Acceptheader =>  Accept header

General: this suggests more spell checking needed throughout if these
weren't caught.  The HTML uses <span>s around them, so that might be
the cause.

3.1.2

Example 9 formatting near o:creditCard needs fixing as above

4.2
why are 'encoding schemes' labelled with an attribute called
env:encodingStyle ?  Surely this should be env:encodingScheme?

sec 6 - references don't seem to be in right document style
from the W3C Style guide.  'Latest version ..' links etc.
missing

General

The HTML uses style="color: #000000" etc.  May be better as CSS
classes and possibly with other emphasis methods for better
accessibility.
[email]
Proposal:
Resolution:
This comment has been incorporated into the editor's copy of the Primer
[email]
314specn/aEncodingDesignClosedDan Brickley
Title: Comments on part 2 - URI/URIref names
Description:
Summary:
Reading back, my comments are variations on a theme: the SOAP Encoding 
and its Data Model would benefit from a more explicit account
of the mechanisms by which node and edge types for use in SOAP graphs 
might be defined. There are a few places where the use of URIs might 
make it easier for other successor specs to flesh out such details (eg. 
URIs for kinds of edge label, for nodes, for node types).

URIs:
I specifically request one change to the spec in the light of 
implementation experience with SOAP: please specify a mechanism for 
identifying SOAP graph edge labels with URI/URIref names. Identifying 
nodes and their types would be useful, but identifying and describing 
SOAP edge labels is (in my database-oriented implementation) critical. 
We have a number of other activites at W3C that could support the richer 
description of SOAP graph edge labels: Web Service Description effort, 
RDF and RDF Schema, as well as the Web Ontology work. Providing 
URI/URIref names for graph edges is a very minimalistic hook that will 
make integration with such efforts cheaper and simpler, without adding 
to the implementation burden for SOAP implementations.

(...)
[[
2.1.1 Edge labels

An edge label is an XML Schema Qualified Name (see XML Schema Part 2: 
Datatypes)
]]

Spec change request:
Please specify an algorithm (for example, simple concatenation) by which
SOAP graph edge types (labels) can be named using URI/URIref syntax. 
This will make it much easier for out-of-band metadata, including but 
limited to RDF/XML metadata, to provide further information about the 
kinds of edges deployed in SOAP Encoding applications.

For example, I have a SOAP encoding application (using SOAP 1.1, being 
upgraded...) in which the serialised objects represent software 
packages. It uses edge labels such as 'ownerMailbox', 'homepage' etc. If 
these had URIs, we could write external RDF/XML descriptions about those 
edge labels, for example mapping to other SOAP Data Model constructs 
from similar applications created elsewhere, or specifying mathematical 
characteristics of the graph (eg. that certain edge labels have an 'at 
most one' semantic, a characteristic that can support graph merging 
algorithms and hence Web Service aggregation).

(more details of this on request... I want to get these comments in 
before last call closes or would provide examples from the implementation)

question:
What is the relationship between node types and edge label types in SOAP 
encoding? Can they be mixed freely? Can I use node types defined 
(somehow...) by one application, with instances of that node using edge 
labels drawn in multiple other schemas? Are there any rules constraining 
the sensible combinations of node and edge types.

Specifically, does the type of a node determine the edges that be 
attached to it? Does each kind of edge label have node types that they 
can point to and from?

Implementor feedback: I am storing and merging de-serialised SOAP 
Encoding messages in a database system. To implement, I had to assume an 
answer to these questions. I assumed that the SOAP Data Model allowed 
namespace mixing amongst types and edges, and that node types do not 
dictate the edge types for a node.

[[
2.2 Graph Nodes
[...]
Both types of graph node have an optional unique identifier of type ID 
in the namespace named "http://www.w3.org/2001/XMLSchema".
]]

Since the SOAP Data Model is defined in the abstract, separate from any 
specific XML (or non-XML) syntactic encoding, it isn't clear why XML's 
notion of ID is being used here. The spec says the node has a "unique 
identifier", but does not define the scope of this uniqueness. XML IDs 
are unique within some document. Is this an implicit constraint on all 
SOAP Data Model XML encodings, ie. that we have the rule of one Data 
Model graph per XML document? (to avoid unique ID clashes). Is the ID 
unique within the scope of one graph, or one encoding as an entire XML 
document of such a graph?

request: please allow nodes to be identified by URI/URIref

(same goes for node types btw; I won't recycle this comment for that 
part of the spec). so, please allow nodes, and their types, to be 
identified by URI/URIref.

The use of a global unique identifier here (ie. URI/URIref) would remove 
the question of identifier scope, since in a Web (Service) context, URI 
identifiers won't accidentally clash. This might help decouple the 
abstract Data Model from the specifics of its XML encoding. It would 
also support data merging between SOAP graphs that shared node 
identifiers, but that's an added bonus.

[email]
Proposal:
Resolution:
1.  The XMLP WG will not define a mechanism for assigning URIs to
graph edges. For the purposes of SOAP Data Model and Encoding, QNames
are sufficient.

2.  The XMLP WG will not specify an algorithm for generating URIs
from QNames. We note that the RDFCore WG have previously considered a
similar issue[5]. We also note that the TAG are considering this
issue[6]

3.  The XMLP WG will remove the ID property from nodes. It's
presence was an oversight on behalf of this editor. IDs are only needed
at serialization time and hence only need to appear in the encoding not
in the data model. We also note that the navigation model for the SOAP
Data Model is one of traversal rather than one based on node identity. 

This end the resolution of Issue 314.
Regarding other questions you raise in Issue 314
You asked: 

Q1: What is the relationship between node types and edge label types in
SOAP encoding?

A1: Not defined.

Q2: Can they be mixed freely? 

A2: Yes

Q3: Can I use node types defined (somehow...) by one application, with
instances of that node using edge 
labels drawn in multiple other schemas? 

A3: Yes

Q4: Are there any rules constraining the sensible combinations of node
and edge types.

A4: No

Q5: Specifically, does the type of a node determine the edges that be
attached to it? 

A5: No

Q6: Does each kind of edge label have node types that they can point to
and from?

A6: No

Note that the answers to the above are based on my own understanding of
your questions and how the SOAP data model works. I should note that I'm
not ENTIRELY sure I understand what you mean by 'node type'. You could
mean:

a) The type property of the node

b) Whether the node is a generic, struct or array

c) Something else I've not though of

However, if it's a or b then the answers stand. If it's c then get back
to me ( on xml-dist-app@w3.org please )
  
[email]
315specn/ametaDesignClosedDan Brickley
Title: Test cases / machine checkable test suite:
Description:
I don't comment on the fine-grained detail of the SOAP Encoding itself, 
except to say the following: please seriously consider creating a 
machine-usable test suite for this work. Defining a graph encoding 
syntax in XML is a  slippery task, and it is easy to make mistakes, both 
in the specification and in implementations. Apparent interop amongst 
deployed SOAP toolkits may reflect shared understanding in that part of 
the Web community as much as it reflects precision in the formal 
specification of the encoding rules. As this work moves into the wider 
Web community, we'll likely see more unexpected corner cases. Historical 
note: this happened with RDF and the RDF/XML graph encoding syntax. We 
had to clean up RDF's graph encoding rules post-REC. As a result of that 
experience, we have reworked the RDF specs to use a more mathematically 
precise account of the abstract graph model, accompanied by a 
machine-processable set of test cases. See
http://www.w3.org/RDF/ for details. I urge the XMLP WG to gather similar
test cases before proposing SOAP 1.2 goes to REC. It's very easy to get 
bugs in XML graph encoding rules. Having a test suite offers very useful 
protection against this
[email]
Proposal:
Resolution:
There are concrete specification of tests related to encoding in the Test
Collection. Various SOAP/1.2 messages are available for testing SOAP/1.2
encoding and many SOAP/1.2 endpoints are already available.
Also, groups are already actively engaged into testing SOAP/1.1 and we
expect they will do the same for Version 1.2.
  
[email]
316specn/aEncodingDesignClosedDan Brickley
Title: Comment on part 2 - SOAP Data Model
Description:
- -> http://www.w3.org/TR/soap12-part2/#datamodel
[[
2. SOAP Data Model

The SOAP Data Model represents application-defined data structures and 
values as a directed edge-labeled graph of nodes. Components of this 
graph are described in the following sections.
]]

The concept of 'application-defined' is somewhat unclear: are these data 
structures defined by the producers of the data, by consumers? what form 
do these definitions take? Might we expect to read a schema definition 
(W3C XML Schema? RELAX-NG?) that made such definitions explicit, or are 
the definitions expected to be implicit. For example, if I deploy a 
Java-based SOAP service, my application-defined data structures might be 
described in terms of Java, yet exposed to the world through the SOAP 
Encoding Data Model.

Readers of 1.2p2 could reasonably ask: 'what technology can I use to to 
expose my application-defined data structuring conventions? The SOAP 
1.2p2 Encoding explains how to expose instance data, but gives little 
account of how the underlying principles that tell us whether or not a 
particular SOAP graph meets the 'application-defined data structures' 
for a given service. Is there an expectation that technology will evolve 
to fill this gap? (a SOAP Encoding Schema Language has been mentioned in 
some discussions on xml-dist-app and www-ws-desc). If so, please make 
this expectation clearer in the specification (there is an aside later 
in the spec, but it isn't very detailed). If not, please note that SOAP 
1.2 does _not_ specify any mechanisms by which applications which use 
SOAP Encoding can describe the SOAP Encoded data structures they 
understand.

[[
The purpose of the SOAP Data Model is to provide a mapping of non-XML 
based data to some wire representation.
It is important to note that use of the SOAP Data Model, the 
accompanying SOAP Encoding (see 3. SOAP Encoding), and/or the SOAP RPC 
Representation (see 4. SOAP RPC Representation) is OPTIONAL. 
Applications which already model data in XML, for example using W3C XML 
Schema [4],[5], may not need to use the SOAP Data Model.
]]

As an introduction to the role of the SOAP Data Model, this could be 
clearer. It explains that one might take the Schema-based approach, or 
that one might take the SOAP Encoding approach, but offers little to 
motivate either decision. For a fresh application with no existing 
commitment to a Schema-based approach, the specification currently 
offers little advice to help SOAP adopters choose which path to take.
Are there identifiable benefits for using SOAP Encoding over a Schema 
approach? Perhaps (for example) that Web services can be deployed faster 
using object-to-XML encodings than through hand-crafting an XML Schema? 
The current text doesn't really sell us on the utility of SOAP Encoding; 
on the contrary, it has a somewhat wary, cautious tone, yet doesn't 
provide technical details on the tradeoffs. If you could add 2-3  bullet 
points to aid SOAP adopters make an informed decision here, that might help.

[[
2.1 Graph Edges
An edge MAY originate and terminate at the same graph node.
]]

addition clarification / test case:

May a graph contain more than one edge with the same originating and
terminating node? (and can such a thing be serialised? in the current 
Encoding rules? in other hypothetical encodings?)


[[
The outbound edges of a given graph node MAY be distinguished by label 
or by position, or both. Position is a total order on such edges; thus 
any outbound edge MAY be identified by position.
]]

This is a bit confusing. Whose freedom does the 'MAY' refer to? 
Consumers of the data? Or definers of a SOAP Data Model-based 
application data formats? (see above re Schema languages). The notion of 
'position' is introduced with reference to 'such edges'. But which ones? 
All of them, since 'any outbound edge MAY be identified by position'? 
Are there edge types for which position is irrelevant? (does 'position 
relate to 'document order' in the concrete XML Encoding of the data 
model?). I'm not sure I understand this paragraph enough to comment 
sensibly.

(...)
[[
2.3 Values
If the labels of a non-terminal graph node's outbound edges are not 
unique (i.e. they can be duplicated), the non-terminal graph node is 
known as a "generic"
]]

Seems odd. How do we know such things about edge labels? No mechanism 
has been described whereby we could acquire such metadata.

[[
Outbound edges of a generic MAY be distinguished by label and/or 
position, according to the needs of the application.
]]

Which application? This is even more confusing, unless I'm missing 
something. The impression I'm left with is that the meaning of a SOAP 
Data Model Graph is rather fluid, and open to competing, rival 
interpretations (eg. multiple consumer apps, or creators of namepsaces 
used in the encoding, vs creators of services that use those 
namespaces). If there was a SOAP Data Model schema language, it would 
presumably address constraints such as those described in 2.3. In its 
absence, there appears to be no authoritative account of the rules 
governing each kind of SOAP Data Model edge label. Section 2.3 should 
either be removed or augmented with a description of how (possibly out 
of band) metadata might provide such information in a machine-readable 
format. Without an account of this, word of mouth seems to be the only 
way to acquire such information.
[email]
Proposal:
Resolution:
We broke the issue into several questions:

Q1: How do applications describe what they send/receive?

A1: We consider it to be out of scope for our spec to define how
applications that use the SOAP encoding to encode data describe their
data structures.


Q2: When should I use the SOAP encoding?

A2: We do not consider it to be the job of our specification to tell
people when to use the SOAP Encoding ( i.e. it's out of scope )


Q3: May a graph contain more than one edge with the same originating and
terminating node? 

A3: Yes

Q4: And can such a thing be serialised? 

Q4: Yes

Q5: In the current Encoding rules? 

A5: Yes. E.g.

<narcissus id='me'>
    <name>Martin</name>
    <bestfriend ref='me' />
    <otherfriend ref='me' /> 
</narcissus>

Q6: In other hypothetical encodings?

A6: Yes ;-)
  
[email]
317specn/aEncodingDesignClosedDan Brickley
Title: Comment on part 2 - misc comments
Description:

Misc other comments:

I understand SOAP sevices can now be deployed with a GET binding.

This means we can expect to see things like HTML documents hyperlinking 
into SOAP services which return SOAP Encoding data graphs.

  - can these by styled with XSLT? eg. a stockticker might
    return XML for SOAP clients, but be XSLT'd into XHTML for humans.
    (ie. is it legal to include stylesheet PIs?)

  - can protocol oriented header information be ommitted? for simple 
   lookups, we often might want nothing more than the graph data itself.
   Would this be legal? Could we use the SOAP mime type?

  - SOAP Encoding is a useful syntax for dumping programmatic objects 
    into XML. Please consider making it easier for non-protocol uses to be 
    made of it. I could easily drop object serialisations onto an FTP site, 
    for example. Or deploy them on a normal HTTP server using normal HTTP 
    content negotiation, so humans got an HTML version of a document, and 
    SOAP clients got the graph encoding. The current spec doesn't seem to 
    anticipate such re-use.
[email]
Proposal:
Resolution:
1)XSLT/PI -> out of scope (not an use case)
2)out of scope and no (as envelope is missing)
3)out of scope also
  
[email]
318specn/aEncodingDesignClosedDan Brickley
Title: Comment on part 2 - encoding
Description:
[[
3.1 Rules for Encoding Graphs in XML
]]

This bit of the spec is much improved from the previous WD; thanks!


[[
3.1.4 Computing the Type Name property

Note:

These rules define how the type name property of a graph node in a graph 
is computed from a serialized encoding. This specification does not 
mandate validation using any particular schema language or type system.
[...]
However, nothing prohibits development of additional specifications to 
describe the use of SOAP with particular schema languages or type systems.
]]

This aside partly addresses some of my questions above. Perhaps it 
should have more prominence in the spec, since it (?) relates to edge 
types as well as node types, and to general issue of extensibility and 
further development of the Web service model.

One clarification request: where it says 'the use of SOAP with 
particular schema languages', does this mean 'the use of the SOAP 
Encoding Data Model with particular schema languages? ie. are you 
leaving open the possibility that Web Services may be able to provide 
additional metadata about their use of the Encoding and associated Data 
Model? (and relating to edge labels and their characteristics, as well 
as node types).

[[
... Such additional specifications MAY mandate validation using 
particular schema language, and MAY specify faults to be generated if 
validation fails. Such additional specifications MAY specify 
augmentations to the deserialized graph based on information determined 
from such a validation.
]]

This seems rather challenging from an extensibility and future proofing 
point of view. If I implement a SOAP 1.2 tookit now, including SOAP 
Encoding support, how would such running code know when it had 
encountered use of such an 'additional specification'? Is this a 
scenario where the SOAP 'mustUnderstand' mechanism should be used? If 
deployed 1.2 clients will be ignorant of 1.2++ services that use such 
mechanisms, this could cause problems.
[email]
Proposal:
Resolution:
Regarding section 3.1.4, part 2, paragraph 2, we are making editorial
changes to clarify that we are referring to the SOAP Encoding.

Regarding your final point, the SOAP extensibility model and the
mustUnderstand attribute would serve to handle future needs of the
type that you allude to.
[email]
319specn/aBindingDesignClosedHenrik Frystyk Nielsen
Title: Clarification that HTTP does define a base URI
Description:
Section 6 paragraphs 4 and 5 [1] indicate that the base URI may be
provided by the underlying transport, yet the referenced HTTP binding 
[2] in Part II makes no mention of this. In [1] it says:

"The underlying protocol binding MAY define a base URI which can act as
the base URI for the SOAP envelope (see 4. SOAP Protocol Binding
Framework and Part 2 [1] section HTTP binding)."

It seems like a useful clarification that we indicate that HTTP does
provide a base URI which is the Request URI as described in [2].
[email]
Proposal:
Resolution:
  The XML Protocol has decided to accept this proposal as the resolution
  to issue 319.

  Issue 319 mentions that it might be a useful clarification that
  because HTTP defines a base-URI in a couple of different ways, this
  propagates through the SOAP HTTP binding. The proposal is to include a
  paragraph in part 2 section 7.1 [2] saying:

  Note: HTTP/1.1 defines a base URI in the form of the Request-URI or the
  value of the Content-Location header field, see RFC 2616 for details.
  
[email]
320specn/ametaDesignClosedHenrik Frystyk Nielsen
Title: Clarification on Use of Multiple Fault Codes
Description:
In [1], it is stated that:

"SOAP fault codes are intended for use by software to provide an
algorithmic mechanism for identifying the fault.

The values of the Value child element information item of the Code
element information item are restricted to those in Table 2. Additional
fault subcodes MAY be created for use by applications or features. Such
subcodes are carried in the Value child element information item of the
Subcode element information item."

However, the text says very little about what the semantics of multiple
fault codes are and how these may relate to the SOAP Detail EII.

For example, is the contents of the Detail EII entirely orthogonal to
the fault codes, or do I have to understand the fault codes in order to
properly understand the details? I think this should be stated in order
to provide unambiguous semantics for SOAP faults.

Something like this may work as clarifying text for  [1]:

SOAP Fault Codes
----------------

SOAP fault codes are intended for use by software to provide an
algorithmic mechanism for identifying the fault. SOAP fault codes are
organized as a linked list of XML qualified names allowing a SOAP node
to identify the fault category at an increasing level of detail of the
SOAP fault. This is similar to the model used in other application layer
protocols like HTTP and SMTP. For example, in HTTP, there is a model of
three-digit status codes where the first digit indicates the overall
class of fault responses as described by RFC 2616. In SMTP, which also
uses a three-digit status code, the three digits of the reply each have
a special significance as described by RFC 2881:

"The first digit denotes whether the response is good, bad or
incomplete. An unsophisticated SMTP client, or one that receives an
unexpected code, will be able to determine its next action (proceed as
planned, redo, retrench, etc.) by examining this first digit. An SMTP
client that wants to know approximately what kind of error occurred
(e.g., mail system error, command syntax error) may examine the second
digit. The third digit and any supplemental information that may be
present is reserved for the finest gradation of information."

The top-level fault code is reserved by this specification using the
values defined by the faultCodeEnum type in the
"http://www.w3.org/2002/06/soap-envelope" namespace. Additional fault
subcodes MAY be created for use by applications or features. Such
subcodes are carried in the Value child element information item of the
Subcode element information item.

SOAP fault codes are to be interpreted as modifiers of contents of the
Detail EII in the sense that they provide the context for the contents
of Detail EII. A SOAP node MUST understand all SOAP fault codes in a
SOAP fault message in order to be able to interpret the Detail element
in a SOAP fault.

For example, if the Detail EII contains a timeout value, this value is
to be interpreted in the context of the SOAP fault codes. In the example
below, this means that the foo:MaxTime EII value is to be interpreted in
the context of the env:Sender, foo:Timeout fault code list.

<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"
              xmlns:foo="http://www.example.org/timeouts">
 <env:Body>
  <env:Fault>
   <env:Code>
     <env:Value>env:Sender</env:Value>
     <env:Subcode>
      <env:Value>foo:MessageTimeout</env:Value>
     </env:Subcode>
   </env:Code>
   <env:Reason>Sender Timeout</env:Reason>
   <env:Detail>
     <foo:MaxTime>P5M</foo:MaxTime>
   </env:Detail>    
  </env:Fault>
 </env:Body>
</env:Envelope>

This specification does not define a limit for how many Subcode EII a
SOAP fault might contain. Implementations should always follow the
Robustness Principle  [2] for interpreting SOAP fault codes. However,
while not a requirement of this specification, it is anticipated that
most practical examples can be supported by relatively few Subcode
EIIs."

Table 2: SOAP Fault Codes

...continue with table contents...
[email]
Proposal:
Resolution:
The WG has accepted the following boiled down version of the proposal
referenced in [1] for incorporation in SOAP 1.2 part 1, section 5.4.6 [2]:

* * * * *

SOAP fault codes are XML qualified names, and are intended to provide a
means by which faults are classified. A hierarchical list of SOAP codes
and associated supporting information is included in every SOAP fault
message, with each such code identifying the fault category at an
increasing level of detail.

The values of the Value child element information item of the Code
element information item are restricted to those defined by the
env:faultCodeEnum type (see Table 2). Additional fault subcodes MAY be
created for use by applications or features. Such subcodes are carried
in the Value child element information item of the Subcode element
information item.

SOAP fault codes are to be interpreted as modifiers of the contents of
the Detail element information item in the sense that they provide the
context for the Detail element information item. A SOAP node MUST
understand all SOAP fault codes in a SOAP fault message in order to be
able to interpret the Detail element information item in a SOAP fault.

* * * * *
  
[email]
321specn/ametaDesignClosedHenrik Frystyk Nielsen
Title: Two inconsistencies in SOAP-defined fault codes
Description:
The schema for the SOAP 1.2 envelope [1] defines a faultcodeEnum which
is used by the Value EII in the SOAP fault:

<xs:complexType name="faultcode">
  <xs:sequence>
      <xs:element name="Value" type="tns:faultcodeEnum"/>
      <xs:element name="Subcode" type="tns:subcode" minOccurs="0"/>
  </xs:sequence>
</xs:complexType>

<xs:simpleType name="faultcodeEnum">
  <xs:restriction base="xs:QName">
    <xs:enumeration value="tns:DataEncodingUnknown"/>
    <xs:enumeration value="tns:DTDNotSupported"/>
    <xs:enumeration value="tns:MustUnderstand"/>
    <xs:enumeration value="tns:Receiver"/>
    <xs:enumeration value="tns:Sender"/>
    <xs:enumeration value="tns:VersionMismatch"/>
  </xs:restriction>
</xs:simpleType>

However, the list is not consistent with the list in [2] which does not
include "DTDNotSupported". I believe the consensus on this issue, which
was reached in solving issue 191 [5], is that we do not define a
"DTDNotSupported" fault code in which case it should be deleted from the
schema.

The other inconsistency is that we in the table do not indicate whether
DataEncodingUnknown is a top-level fault code or a subcode. The place
this comes up is in the HTTP binding where we map the top-level fault
codes to HTTP fault codes. This was discussed as part of resolving issue
196 [3] and I believe the consensus was to make it a subcode of the
Sender code.

FWIW, I can live with it as a top-level fault, just don't want it to be
an oversight.
[email]
Proposal:
Resolution:
322specn/ametaDesignClosedHenrik Frystyk Nielsen
Title: Clarification on Use of SOAP Detail Element
Description:
I think the current description of the Detail EII in [1] is a leftover
from early days but now comes across as inconsistent with the overall
SOAP 1.2 processing model and the notion of multiple SOAP fault codes
(see also [2]). Our processing model provides a clear model for what a
fault means but the Detail element breaks this into two cases: faults
resulting from header faults and from body faults. This separation is
mediocre at best and has no impact on the processing of a SOAP message.
As a result I suggest that we fix this by removing the distinction
between header and body faults and allow the Detail EII to contain
additional information in either case.

That is, I suggest that we change the current text from [1]: 

"The Detail element information item MUST be present when the contents
of the SOAP Body could not be processed successfully. It MUST NOT be
used to carry error information about any SOAP header blocks. Detailed
error information for SOAP header blocks MUST be carried within the SOAP
header blocks themselves.

The absence of the Detail element information item indicates that a SOAP
Fault is not related to the processing of the SOAP Body . Presence of
the Detail element information item is a signal that the SOAP Body was
at least partially processed by an ultimate SOAP receiver before the
fault occurred.

All child element information items of the Detail element information
item are called detail entries (see 5.4.5.1 SOAP detail entry)."

And instead say:

"The Detail element information item MAY be present in a SOAP fault
carrying additional information relative to the SOAP fault codes
describing the fault (see section X.X). For example, the Detail EII
might contain information about a message not containing the proper
credentials, a timeout, etc. The presence of the Detail EII has no
significance as to which parts of the faulty SOAP message was processed.


All child element information items of the Detail element information
item are called detail entries (see 5.4.5.1 SOAP detail entry)."
[email]
Proposal:
Resolution:
The WG accepts the proposal and will change the spec accordingly.
[email]
323specn/ametaDesignClosedHenrik Frystyk Nielsen
Title: Use of "" in encodingStyle Attribute
Description:
In section [1] defining the encodingStyle attribute, we have the same
problem using an empty URI as we had in issue [2]:

"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."

When we made the transition to use XMLBase throughout, "" became a valid
relative URI and hence we can't use that to indicate that there is no
encoding. Instead I suggest that we introduce an explicit URI that
carries the same semantics but doesn't have this problem. An example of
such a URI is

 http://www.w3.org/2002/06/soap-envelope/encoding/none

[email]
Proposal:
Resolution:
The XMLP Working Group has closed Issue 323 by accepting your proposal:

To indicate that no claim about the encoding style are made, the value for the 
encodingStyle attribute information item will be changed from "" to 
"http://www.w3.org/2002/06/soap-envelope/encoding/none".
[email]
324specn/ametaDesignClosedHenrik Frystyk Nielsen
Title: Clarification on Use of what SOAP Faults Mean when not Direct and Only Child of Body
Description:
This is IMO purely editorial--in the text from [1]:

"To be recognized as carrying SOAP error information, a SOAP message
MUST contain a single SOAP Fault element information item as the only
child of the SOAP Body .

When generating a fault, SOAP senders MUST NOT include additional
element information items in the SOAP Body . A message whose Body
contains a Fault plus additional element information items has no
SOAP-defined semantics.

A SOAP Fault element information item MAY appear within a SOAP header
block, or as a descendant of a child element information item of the
SOAP Body ; in such cases, the element has no SOAP-defined semantics."

I don't think the last sentence is correct. The question is not really
whether it has SOAP-defined semantics but whether it is the result of
the processing as defined in section 2.6 [2]. I suggest changing the
last sentence to:

"A SOAP Fault element information item MAY appear within a SOAP header
block, or as a descendant of a child element information item of the
SOAP Body; in such cases, the element is not indicating a failure in the
processing of that message as defined by the SOAP processing model
defined in [2]".
[email]
Proposal:
Resolution:
The WG decided to close the issue without making any change to the spec.
The WG felt that the existing text conveys the correct and appropriate meaning.
[email]
325specn/aEncodingDesignClosedAnish Karmarkar
Title: Encoding - XML schema
Description:
SOAP 1.2 does a great job of separating the SOAP data model and soap
encoding.

The aim of the soap data model (section 2) is to provide a mapping of
non-XML based data to some wire representation (which is XML). The soap
data model is a directed edge labeled graph, whereas the XML data model
is tree based.
Soap encoding (section 3) bridges this gap by providing a way to encode
arrays and multirefs. But soap encoding does not use XML Schema to do
this (except for the use of xsi:type to determine the Type Name property
- section 3.1.4).

We believe that XML schema is the only interoperable type system
available in the existing XML technologies and that it is necessary to
define an optional encoding that uses XML Schema (define a XML schema
instance or provide a schema oriented solution) for serialization of
soap data model.
[email]
Proposal:
Resolution:
At the sept. 4th 2002 telecon, the WG decided to close LC issue 325 by
keeping status quo.
  
[email]
326specn/ametaDesignClosedMartin Gudgin
Title: Qualify attributes?
Description:
Should all the attributes defined by the SOAP spec be namespace
qualified? It would seem consistent that all attributes that appear on
elements that are NOT in a SOAP namespace be qualified. I think this
applies to all the attributes in the spec ( none of them appear on
Envelope, Header or Body ). We qualify role and mustUnderstand, but not
the other attribute like id/ref/itemType.
[email]
Proposal:
  I raised this issue at last call. The proposal is that we qualify all
  attributes in our spec. This means making the id and ref attribute
  information items qualified. This brings them into line with itemType
  and arraySize ( and mustUnderstand and role ).
  
email]
Resolution:
The working group has decided to close this issue by qualifying all the
attributes in the specification. Specifically the id and ref attributes
will be qualified by the soap-encoding namespace.
  
[email
327specn/ametaDesignClosedRay Whitmer
Title: Intellectual property
Description:
We feel that there may be significant intellectual property issues with 
the SOAP specification.

Multiple companies have said they believe they may have relevant 
patents.  Further investigation is required here before the 
specification should proceed to PR phase.

There is also a bit of divergence in some cases between IPR disclosures 
and grants in the SOAP 1.1 submission and the SOAP 1.2 specification and 
the IPR summary for SOAP should encompass declarations from both lists 
and reconcile them where different statements were made by the same 
companies.  These aggregate statements need to be considered and 
compared with the W3C definitions of royalty-free, looking for 
unacceptable terms which have been stipulated.
[email]
Proposal: see David's email and following thread
Resolution:
The WG has resolved issue 327 which you originated and as described in
  http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2002Dec/0094.html.
  
[email]
328specn/aEditorialDesignClosedPhilippe Le Hégaret
Title: Minor editorial change - part 2
Description:
In Part 2:

6.1 Property Conventions for Message Exchange Patterns
-> 6.1 Property Conventions for SOAP Message Exchange Patterns

6.2 Request-Response Message Exchange Pattern
-> 6.2 SOAP Request-Response Message Exchange Pattern

[email]
Proposal:
Resolution:
  The WG discussed this issue recently and agreed to make 
  the changes you requested.
  
[email]
329specn/ametaDesignClosedMike Champion
Title: Possible inconsistency in SOAP Process Model
Description:
SOAP1.2 Part 1: Messaging Framework


2.4 Understanding SOAP Headers, 3rd paragraph, 2nd sentences
      "Therefore, for every mandatory SOAP header block targeted to
      a node, that node MUST either process the header block or not
      process the SOAP message at all, and instead generate a fault
      ..."

This sentence implies that there can be at most one detection of a
fault caused by processing a header block as all further message
processing ceases on fault detection.

However, in various parts of Part 1, there is assumption that
multiple misunderstood header blocks may be possibly identified in
a fault message, e.g. in 2.6 Processing SOAP Messages, Rule 3:
      "If one or more of the header blocks identified in the preceding
      step are not understood by the node ..."
    e.g. in 5.4.8 SOAP mustUnderstand Faults, 2nd paragraph, 1st
    sentence:
      "A SOAP node MAY generate a SOAP fault for any one or more
       SOAP header blocks  ..."

Related commentary on this issue:

"A SOAP node MAY generate a SOAP fault for any one or more SOAP header
blocks that were not understood in a SOAP message."
This sentence is very ambiguous and seems to conflict with this sentence
from section 2.4 Understanding SOAP Headers:
"for every mandatory SOAP header block targeted to a node, that node MUST
either process the header block or not process the SOAP message at all, and
instead generate a fault"
My understanding (according to section 2.4) is that the SOAP node MUST
generate a SOAP fault for the first SOAP header block that is targeted at
that node, contains mustUnderstand="true", and that it does not understand.
When a node encounters a mustUnderstand error, it should stop processing
immediately (i.e., no further processing of other header blocks) and return
the error. Also, this sentence might be construed to mean that the SOAP
node
MAY generate multiple faults. If my understanding is correct, then Example
6
should be changed to include only one Misunderstood header blocks. If not,
then I would recommend that section 2.4 be changed to indicate that
processing may continue after encountering a mustUnderstand fault.
[email]
Proposal:
Resolution:
After discussion, the WG has decided to close this issue without 
changes in the specification. 

The WG follows the remarks made by Noah Mendelson in [3] section #1.
[email]
330specn/ametaDesignClosedMike Champion
Title: Contradiction in SOAP Process Model
Description:
2.4 Understanding SOAP Headers, 3rd paragraph, last sentence
      "Tagging SOAP header blocks as mandatory thus assures that
      such modifications will not be silently (and, presumably,
      erroneously) ignored by a SOAP node to which the header block
      is targeted."

This sentence implies that it will not be possible for modifications
by mandatory header blocks to be silently and erroneously ignored.

However, in the last 2 sentences of the next paragraph, it is said
that
      "it is not an error for an ultimate SOAP receiver to receive a
      message containing a mandatory header block that is targeted at a role
      other than the ones assumed by the ultimate SOAP receiver.
      This is the case, for example, when a header block has survived
      erroneously due to a routing or targeting error at a preceding
      intermediary."

That is, it is not an error for mandatory header block to survive
erroneously and therefore be silently ignored, thus contradicting the first
sentence quoted.
[email]
Proposal:
Resolution:
After discussion, the WG has decided to close this issue without 
changes in the specification. 

The WG follows the remarks made by Noah Mendelson in [3] section #2.

In addition, your issue was discussed by the WG earlier named the
"mustHappen" attribute. We desided to add no such attribute, because the
same semantic could be embodied by adding SOAP header blocks. The 
mustUnderstand feature was carefully designed to support such requirements.
[email]
331specn/ametaDesignClosedMike Champion
Title: URI Identification of MEPs
Description:
(Part 1)
Section 3.3 reads [2]:

|   In general the definition of a message exchange pattern:
|     * Is named by a URI.
|     * Describes the life cycle of a message exchange conforming to the
|       pattern.
|     * Describes the temporal/causal relationships of multiple messages
|       exchanged in conformance with the pattern.
|     * Describes the normal and abnormal termination of a message
|       exchange conforming to the pattern.

This suggests that not all MEPs are identified by a URI. From an
architectural point of view, and according to AR009.3[1], all conceptual
elements should be addressable directly via a URI.

We think that a URI should be required for MEPs: it is easy enough to
assign one and will ease identification.
[email]
Proposal:
Resolution:
Per clarification of the specification (see resolution for LC Issue 230)
an MEP as a feature must follow all the rules of the features and therefore 
MEPs are identified by URIs.
  
[email]
332specn/ametaDesignClosedMike Champion
Title: External references?
Description:
Section 2.6 reads [3]:

   "SOAP nodes MAY make reference to any information in the SOAP envelope
   when processing a SOAP body or SOAP header block. For example, a
   caching function can cache the entire SOAP message, if desired."

We wonder about external references. They are not explicitely
disallowed, but not referenced either. Needless to say, we think that
external references are useful, e.g. to reference a large image that
one doesn't want to carry along in the message.
[email]
Proposal:
Resolution:
The XMLP WG has decided to close issue 332 you raised with no
action taken.  We have discussed external references in the past at some
length, and determined their use should be application defined in most
cases.  Where external references are to attachments, we actively have work
ongoing.
[email]
333specn/ametaDesignClosedMike Champion
Title: QName vs URI
Description:
Sections 5.4.1.3[4] and 5.4.6[5] use and define QNames to identify
fault types, whereas WSAWG requirement AR009.3[1] calls for URIs.

This is related to two open TAG issues:
- Using Qualified Names (QNames) as Identifiers in Content[6].
- Algorithm for creating a URI from a QName[7].
[email]
Proposal:
Resolution:
The XMLP WG decided to close issue 333 you raised with no action
taken.  We reviewed the TAG findings with regard to using QNames in a
string [3] and determined our current specification is not in conflict with
those findings.
334specn/aEditorialDesignClosedMike Champion
Title: Mention SOAP response MEP
Description:
Part1
Section 2. SOAP Processing Model. First paragraph.
It would be nice to mention the SOAP Response MEP. Also we don't find that
section 3.3 SOAP Message Exchange Patterns (MEPs) really provides a
description of the relationship between SOAP message exchange patterns and
the SOAP extensibility model. It gives only a very brief definition of a
MEP, and it makes no explicit mention of the extensibility model. It does
describe the relationship between MEPs and the Protocol Binding Framework.
[email]
Proposal:
Resolution:
The XMLP WG has decided to close this issue with no action:

(i) The SOAP processing model is orthogonal to MEPs so there is no need 
to single out a particular MEP for mention in section 2.
(ii) Whilst it would be possible to change the reference to section 3.3 
to a more general reference to section 3, we prefer to maintain the 
more specific reference.
  
[email]
335specn/aEditorialDesignClosedMike Champion
Title: Intermediaries remove blocks
Description:
Section 2.7.2. Active Intermediaries. Second paragraph: Question.
It says, "an active intermediary might have removed and encrypted some or
all of the SOAP header blocks found in the inbound message". Shouldn't it
say, "some or all of the SOAP header blocks and SOAP body"?
[email]
Proposal:
Resolution:
The XMLP WG has decided to close this issue with no action since 
the text in question is only an example of the kind of modifications 
that intermediaries could make to a SOAP message. i.e. it does not 
preclude intermediaries from modifying the contents of the SOAP body.
  
[email]
336specn/ametaDesignClosedMike Champion
Title: Length of URIs.
Description:
I remember a somewhat long discussion on xml-dist-app about that and
am still unsure about what we should say, but the following statement
struck me [8]:

|   SOAP does not place any a priori limit on the length of a URI. Any
|   SOAP node MUST be able to handle the length of any URI that it
|   publishes and both SOAP senders and SOAP receivers SHOULD be able to
|   deal with URIs of at least 2048 characters in length.

Even though the URI specification doesn't specify any limit on the
length of a URI, the HTTP spec does provide a URI too long error
code[9].

2kB is identified here as a reasonable value to be able to handle.
This seems to be an architectural issue, a Web services one as well as
a Web one. I am afraid that such a statement will have a big impact on
software designed.

I think that I would be more comfortable by saying that software
should be able to handle URIs of arbitrary length, and that a
2kB-length is seen _in SOAP's context_ as a minimum value to support.
[email]
Proposal:
Resolution:
  The XML Protocol WG considered issue 336 today, an issue that you raised
  on the SOAP spec's statements about the length of URIs.  Rather than
  having some statement containing overlapping SHOULDs (SHOULD support
  URIs of arbitrary length and SHOULD support URIs of length 2048), it
  was felt that the existing text already provided appropriate motivation
  for handling URIs of arbitrary length.  Therefore, no change is being
  made to the specification.
  
[email]
337specn/aEditorialDesignClosedMike Champion
Title: Editorial - (grammar & typos) - part 1
Description:
Editorial - part 1

Section 3.3. SOAP Message Exchange Patterns (MEPs)
It would be nice to add a reference to Part 2, section 6.

Section 4.2. Binding Framework. Third paragraph:
ends with "one or more MEP". Should be "one or more MEPs".

Section 5.2.1. SOAP header block. In the paragraph following Example 3, in
the sentence, "A SOAP sender generating a SOAP message SHOULD use these
attributes only on SOAP header block.":
It should read, "only on a SOAP header block"

Section 5.4.8. SOAP mustUnderstand Faults. First sentence.
"When a SOAP node generates a fault with a Value of Code set to
"env:MustUnderstand" for," -- delete the word "for".

Section 7.3.1. Binding to Application-Specific Protocols. First paragraph,
last sentence:
"in order to reuse the existing infrastructure associated that protocol"
should be "associated with that protocol".
[email]
Proposal:
Resolution:
With the exception of the first item, the WG has accepted your
recommendations and made changes identical or similar to the ones you
request.  The workgroup did not decide to adopt the suggestion of a
reference to Part 2 section 6 from part 1 section 3.3.  
  
[email]
338specn/ametaDesignClosedMike Champion
Title: state machine description questions
Description:
(part 2)
Question
Section 6.2.3 State Machine Description, Table 6, Transition Condition,
Init
row

If the Transition Condition is "Unconditional", then the boundary
between Init state and the Requesting state is indistinguishable.
Shouldn't the two states be one state?

Question 
Section 6.2.3 State Machine Description, last bullet before 6.2.4
      "A requesting SOAP node MAY enter the Fail state, and thus
      abort transmission of the outbound SOAP request, based on
      information contained in an incoming streamed SOAP
      response".

In this case, should the responding SOAP node switch from generating
a SOAP response to a SOAP fault ?  Should the requesting SOAP node also
generate a SOAP fault since it initated the transmission abortion?
[email]
Proposal:
Resolution:
The XML Protocol (XMLP) WG discussed and decided to close issue 338,
which you originated, with the following resolutions:

<Mike>
Section 6.2.3 State Machine Description, Table 6, Transition Condition, Init
row

If the Transition Condition is "Unconditional", then the boundary
between Init state and the Requesting state is indistinguishable.
Shouldn't the two states be one state?
</Mike>

You are right. This is a bug. WG unanimously decided to change the
transition condition, from 'Init' STATE to 'Requesting' STATE, to
'Transmission of request message initiated'.

And, this change is in-sync with HTTP Binding. Where, 'Init' and
'Requesting' are distinct states and 'Transmission of request message
initiated' is the transition condition.

<Mike>
Section 6.2.3 State Machine Description, last bullet before 6.2.4
      "A requesting SOAP node MAY enter the Fail state, and thus
      abort transmission of the outbound SOAP request, based on
      information contained in an incoming streamed SOAP
      response".

In this case, should the responding SOAP node switch from generating
a SOAP response to a SOAP fault ?  Should the requesting SOAP node also
generate a SOAP fault since it initated the transmission abortion?
</Mike>

Close this issue with no action. Because, spec is correct and it outlines
the following,

* Requesting SOAP node does not issue a fault, just aborts and goes to fail state 
* Responding SOAP node goes to fail state, and sets context:FailureReason to "receptionFailure" 
* If context:FailureReason == fail:receptionFailure, then the responding 
node does not have to transmit any fault 

In general, responding SOAP node generates a SOAP fault if and only if the 
'normal' soap rules say generate a fault. If it is a binding level fault,
then the responding SOAP node generates a binding fault. If it is HTTP
binding, Table 20 contains a list of HTTP Binding generated faults.
  
[email]
339specn/aBindingDesignClosedMike Champion
Title: SOAP fault for Malformed Request Message
Description:
(part 2)
Question
Section 7.5.2.1 Init, Table 20, SOAP Fault, Malformed Request Message row
For Malformed Request Message ( HTTP Status Code 400, HTTP
Reason: Bad request) the SOAP Fault is "None".

Why not let the SOAP Fault to be "env:Sender", which is consistent
with Table 23?
[email]
Proposal:
Resolution:
The specification is correct regarding the difference between
Table 20 [2] and Table 23 [3].
Table 20 describes HTTP status codes corresponding to errors
that can occur in the Init state. In this state no SOAP
message has been received, and in accordance, the responding
node must not send a SOAP fault as it don't know if there is a
SOAP node at the other end.
On the other hand, table 23 describes HTTP status codes
corresponding to SOAP faults that might be generated by the
responding SOAP node.

Overall, some cleanup might make section 7.5.2 more clear. In
accordance, the specification will be modified according to
proposal in [4].
[email]
340specn/aBindingDesignClosedMike Champion
Title: RPC Faults and HTTP status
Description:
Question
Section 7.5.2.2 Receiving, Table 23, SOAP Fault to HTTP Status Mapping

What about mapping RPC Faults (see 4.4 RPC Faults) to HTTP Status?
E.g. rule 2 in 4.4 defines a fault "env:DataEncodingUnknown" which is not
mentioned in Table 23.

[email]
Proposal:
Resolution:
The XMLP Working Group has closed Issue 340 with the
following resolution:

Add a new line into Table 23 [2] for the env:DataEncodingUnknown:
SOAP Fault               HTTP Status Code  HTTP Reason Phrase
env:DataEncodingUnknown  500               Internal server error

The reason for choosing the 500 HTTP Status Code is to be
consistent with the HTTP Status Code associated to
env:VersionMismatch.
[email]
341specn/aEditorialDesignClosedMike Champion
Title: part 2 - App A - UCS notation
Description:
Section A.1 Rules for mapping application defined names to XML Names, Rule
5, case 4
      "Let U1, U2, ... , U8 be the eight hex digits [PROD: 4] such that Ti
       is "U+" U1 U2 ... U8 in the UCS-4 encoding."

The "U+" notation denotes the Unicode code point rather than either
UCS-2 or UCS-4 encoding.  Moreover, "the full range of Unicode code points
[are] from U+0000 to U+10FFFF inclusive; code points above U+10FFFF MUST
NOT be used".  (See Character Model for the World Wide Web 1.0, 3.5 Reference
Processing Model.)

Suggest it be change to:  "Let U1, U2, ... , U8 be the eight hex digits
[PROD: 4] such that Mi is U1 U2 ... U8 in the UCS-4 encoding."

Suggest also changing '
      "This case implies that Ti has a UCS-2 encoding, which is
      U+U5U6U7U8."
to:
      "This case implies that Ti has a UCS-2 encoding, which is U5U6U7U8."

[email]
Proposal:
Resolution:
In the email at [1] you raised on behalf of the WSAWG a set of issues, one
of which the XML Protocols Workgroup identified as it's last call issue
number 341. The issue related to the mapping of application-defined
names to XML. The workgroup received other comments on this part of the
specification, including a suggestion for substantial changes that we
logged as issue 270 [3].

As described in the email closing issue 270 [4], a significant rewrite of 
the section in question has incorporated the suggestions we received in the 
two issues.  Email [4] includes a reference to the revised text, which is in 
the editors draft of our specification. 
  
[email]
342specn/ametaDesignClosedMike Champion
Title: HTTP binding: interpretation of arbitrary HTTP status codes
Description:
Section 7.5.1.2 Requesting[8] describes how a SOAP sender reacts
to HTTP status codes returned by a SOAP receiver.

Table 17[9] only lists a limited number of methods for which next
states are listed. This seems to be contrary to the robustness
principle cited in Part 1[10]. What would happen if the 
requestingSOAP node was receiving a 402 Payment Required[11] for 
example?
[email]
Proposal:
Resolution:
The XML Protocol (XMLP) WG has decided to close issue 342, which you
originated, with the following resolution.

Issue 342 is a DUPLICATE of issue 224 [2]. WG resolved issue 224 by adding
the following paragraph to section 7.5.1.2 "Requesting" near Table 17,

"Table 17 details the transitions that take place when a requesting SOAP
node receives an HTTP status line and response headers. Table 17 refers to
some but not all of the existing HTTP/1.1 [RFC 2616] status codes. 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"
[email]
343specn/aEditorialDesignClosedMike Champion
Title: Editorial comments - Part 2
Description:
Editorial

Section 5. A Convention for Describing Features and Bindings. First
paragraph:
"it is used to describe a Request-Response MEP 6.2 Request-Response Message
Exchange Pattern and the SOAP HTTP Binding 7. SOAP HTTP Binding elsewhere
in this document."
It is also used to describe the the 6.4 Web Method Specification Feature
feature and the 6.3 SOAP Response Message Exchange Pattern MEP, isn't it?
[email]
Proposal:
Resolution:
I am pleased to inform you that the XML Protocols workgroup has closed this 
issue by adopting your recommended changes. 
[email]
344specn/aEditorialDesignClosedMike Champion
Title: Primer - Definition of SOAP header
Description:
(Part 0)

2.1. SOAP messages. The paragraph beginning with " A SOAP header".
When I first read this paragraph, I was concerned with the implication that
SOAP headers should be processed by a SOAP intermediary rather than by a
SOAP header processor within a SOAP server. Then it dawned on me that
perhaps the authors view a SOAP header processor as a SOAP intermediary.
Rather than starting with a description that implies the use of an
intermediary, I think the paragraph should start with a basic definition of
a SOAP header: A SOAP header is an extension mechanism that provides a way
to pass information that isn't application payload. Then it should discuss
why you might want to use this information (to pass control, directive, or
contextual information) and how to insert header processors into the SOAP
processing scheme (either as intermediaries or as header processors called
by a SOAP server). Or it might simply make it obvious to the reader that a
SOAP header processor is in fact a SOAP intermediary.
[email]
Proposal:
Resolution:
This comment has been incorporated into the editor's copy of the Primer
[email]
345specn/aEditorialDesignClosedMike Champion
Title: Primer: omission in example 2?
Description:
2.2.1. Document-style message exchange. Example 2.
Shouldn't the returned <p:airportChoices> element contain an enumeration?

[email]
Proposal:
Resolution:
  The schema document (not shown in the Primer, but implied and tangentially 
  mentioned in the text following example 2), of which example 2 is an instance,
  would show that the element "airportChoices" is a list type (xsd:list). 
  Hence the instance document - example 2 - lists the airport choices. So 
  no changes are necessary to example 2.
  
[email]
346specn/aEditorialDesignClosedMike Champion
Title: RPC and "Web-friendly" discussion in Primer
Description:
2.2.2. Remote procedure calls.
This discussion about RPC makes the assumption that it will use the HTTP
protocol, and hence spends a great deal of time up front discussing
"Web-friendly" concepts before discussing the basics of the the RPC
convention. I also find the tone to be somewhat defensive -- It sounds 
as if it's trying to convince me that this is the right way to do it 
(and that I have another choice). I much prefer the way this information is 
presented in Part 2, Section 4 [12]. It's very 
straight-forward and direct. It says -- this is
the way you do RPCs (articulating how it maps to the two MEPs), and when
you're using HTTP as a transport, you need to use the Web Method Feature.
The GET Web Method is the preferred mechanism to implement SOAP-based
idempotent information retrieval.

Since the RPC convention isn't dependent on HTTP, I'd recommend:
1) it be explicitly stated right up front (Part 2, section 4 describes it
in terms of RPC invocations and responses mapping naturally to HTTP requests
and responses,  but that RPC is not dependent on HTTP).
2) most of the Web-friendly discussion (The paragraphs starting with "Items
4 and 5" through "We defer until section 3") be moved to section 3 with
appropriate references to that section made in this section.
[email]
Proposal:
Resolution:
The main point in all these comments, that section 2.2.2 should only deal 
with the syntactical aspects of encapsulating rpcs and that the web-friendly 
discussion should be moved to section 3.1, has been accepted and incorporated 
into the latest editor's copy of the Primer.
  
[email]
347specn/aEditorialDesignClosedMike Champion
Title: Primer - RPC invocation
Description:
(related to 347)

2.2.2. Remote procedure calls. Point #4.
Is this "information needed to invoke a SOAP RPC"? Isn't this a
clarification of how the information described by points 2 and 3 must be
specified? I understand that we want to explain Web-friendly RPCs, but I
don't think this point belongs in this list. I think it belongs in the
follow-on text with appropriate references to section 3.1.1. I would
therefore recommend a change to the following two paragraphs to first
assert the requirement to clearly separate the arguments used to identify the
target Web resource from the arguments used to convey data or control
information and then to explain why.  We should promote the Web-friendly
way as the preferred way to implement information-retrieval requests, as
specified in Section 3.1.3.)
[email]
Proposal:
Resolution:
Regarding the points made in Issue 347 and 348 about items 4, 5 in 
section 2.2.2, no changes have been made to these items, as they are essentially
the same as that provided in SOAP part 2 (although written somewhat more 
informally). Specifically, the web method feature (item#5) is available to all 
bindings, and not just the HTTP one, although that is the usage that is 
standardized at this time. 
  
[email]
348specn/ametaDesignClosedMike Champion
Title: Primer - RPC - point only valid when using HTTP
Description:
2.2.2. Remote procedure calls. Point #5.
This point is only valid when using HTTP. Per Part 2, Section 4, this point
should read: "Values for properties as required by any features of the
binding to be used. For example, GET or POST for the webmeth:Method
property of the 6.4 Web Method Specification Feature."
[email]
Proposal:
Resolution:
Regarding the points made in Issue 347 and 348 about items 4, 5 in 
section 2.2.2, no changes have been made to these items, as they are essentially
the same as that provided in SOAP part 2 (although written somewhat more 
informally). Specifically, the web method feature (item#5) is available to all 
bindings, and not just the HTTP one, although that is the usage that is 
standardized at this time. 
  
[email]
349specn/ametaDesignClosedMike Champion
Title: Primer - RPC - add a reference to HTTP?
Description:
2.2.2. Remote procedure calls. The paragraph starting with "Items 4 and 5":
There should be a reference to HTTP in this paragraph (rather than just
referring to the World Wide Web). This paragraph should be moved to section 3.
[email]
Proposal:
Resolution:
The sentence referred to in Issue 349 has been deleted, as similar 
sentences already appear in section 3.1.3.
  
[email]
350specn/aEditorialDesignClosedMike Champion
Title: Editorial (grammar & typos) - Primer
Description:

1. Introduction. Last sentence of the paragraph starting with "Part 2".
I don't think this sentence belongs here. (No other part of this first
Introduction section gets into this much detail.) I'm concerned by the
implication that SOAP isn't "Web-friendly". At the very least, if the term
is introduced here, there must be a definition provided with it. I think
the topic is properly covered as part of the introduction in 1.1 Overview
section in the paragraph starting with Section 3.

2.2.2. Remote procedure calls. In the paragraph starting with "The central
role":
This paragraph should be moved to section 3.
A space is required here: "Part 2 Section 4.1.1provides"
  also "data that is necessary" should be "data that are necessary"

2.2.2. Remote procedure calls. Example 4:
For readability, here should be a line break between the elements in this
line:
</m:reservation>   <o:creditCard
  xmlns:o="http://mycompany.example.com/financial">
  and this line:
  </n:name>     <o:number>123456789099999</o:number>

2.2.2. Remote procedure calls. Third paragraph from the end, starting with
"While in principle":
"inependent" is misspelled.

2.4. SOAP processing model. Second paragraph:
"(with their contents elided for brevity)" -- we might want to use a more
well-known term than "elided" -- perhaps "removed" or "edited".

2.4. SOAP processing model. eleventh paragraph, starting "If a header
element":
"content is data" should be "contents are data".

2.4. SOAP Processing model. The paragraph starting with "The following
table":
"appropriate" should be "appropriately".

3. Using various protocol bindings. The paragraph starting with "Thus it is
apparent":
The phrase "accomplish a particular application semantics" (which appears
twice in this paragraph) should be either "accomplish particular
application semantics" or "accomplish a particular application semantic".

3. Using various protocol bindings. The paragraph starting with "Among
other things":
  The last sentence reads, "a non-SOAP message acting as a response followed
  by a SOAP message included as a part of the response" should say, "a
  non-SOAP message acting as a request followed by a SOAP message included as
  a part of the response".

3. Using various protocol bindings. The paragraph starting with "Part 2
section 7specifies":
  A space is required here: "Part 2 section 7specifies"

3.1. HTTP binding. Last sentence of the paragraph starting with "The
purpose of providing":
  "Acceptheader" should be "Accept header"

3.1.1. SOAP HTTP Get usage. The second paragraph, beginning with "Example
  8a shows":
  A space is required here:
  "URIhttp://travelcompany.example.org/reservations?code=FT35ZBQ"

3.1.1. SOAP HTTP Get usage. The third-to-last paragraph starting with "In
Example 8b"
  "outboundandreturn" shoudl be "outbound and return".

3.1.2. SOAP HTTP POST usage. Example 9:
  For readability, a line should be inserted between the elements here:
  </m:reservation>    <o:creditCard
  xmlns:o="http://mycompany.example.com/financial">
  and here:
  </n:name>    <o:number>123456789099999</o:number>

3.1.2. SOAP HTTP POST usage. In the paragraph betwee Example 9 and Example
10.
  "Example 10 shows the RPC return (with details elided)" -- again I
  recommend using a more common word than "elided".

3.1.2. SOAP HTTP POST usage. Last paragraph.
Are we using American or English spelling? Should "behaviour" be
"behavior"?

3.1.3. Conveying Web-friendly RPCs. In the paragraph just before Example
12b, starting with "Furthermore":
  The sentence "SOAP 1.2 recommends that the SOAP Response message exchange
  pattern be used as described in section 3.1.2." should refer to section
  3.1.1.

3.1.3. Conveying Web-friendly RPCs. In the paragraph just before Example
  13, starting with "Example 13":
  "thenameof" should be "the name of" and "Bodyelement" should be "Body
  element".

3.2. SOAP over email. In the paragraph starting with "Example 15":
  I recommend using a more commonly known word than "elided". Also a space is
  required in "email'sMessage-Id".

5. Changes between SOAP 1.1 and SOAP 1.2. Under "Document structure", first
  bullet:
  "strucure" should be "structure".
[email]
Proposal:
Resolution:
This comment has been incorporated into the editor's copy of the Primer
[email]
351specn/aEditorialDesignClosedSusan Lesch
Title: Editorial (typos) - All docs
Description:
This is only an editorial comment and I hope in time to help. A spell
checker found minor errors.

Twice in each of the four drafts, Mitre should read MITRE.

In Assertions and Test Collection
http://www.w3.org/TR/2002/WD-soap12-testcollection-20020626

s/existant/existent/
s/indetifier/identifier/
s/charater/character/
s/attibute/attribute/
s/concatanate/concatenate/
s/secound/second/
s/paramenter/parameter/
s/childern/children/

In Part 0: Primer
http://www.w3.org/TR/2002/WD-soap12-part0-20020626/

s/analyse/analyze/
s/targetted/targeted/
s/ancilliary/ancillary/

knowna priori should read
known a priori

In Part 1, nothing but MITRE to report

In Part 2: Adjuncts
http://www.w3.org/TR/2002/WD-soap12-part2-20020626/

s/performingsimilar/performing similar/
[email]
Proposal:
Resolution:
Thanks for your edits on SOAP Part 0: Primer, identified as LC Issue #351.
They have been included for the next revision of the Primer WD.
  
[email]
352specn/aEditorialDesignClosedMicah Dubinko
Title: Editorial - All docs
Description:
[Throughout] When referring to XML Schema datatypes, please use the more
compact notation 'xs:anyURI' instead of 'anyURI in the namespace named
"http://www.w3.org/2001/XMLSchema"'

[Throughout] Please use textual instead of numeric identifiers for
references ( [HTTP 1.1] instead of [2]) This applies to parts 0-2.

[Part1 8. References]
The following reference seem to be "orphaned" (not referred to from
anywhere)
[9] (XLink) Please remove the reference.

[Throughout] Please ensure that infoset property names and values have a
distinguishing typographical style.
(Example: "A specified property..." should be "A [specified] property...")
[email]
Proposal:
Resolution:
This comment has been incorporated into the editor's copy of the Primer
[email]
353specn/aEditorialDesignClosedMicah Dubinko
Title: Editorial - Readabilituy comments - part 2 sections 2/3
Description:
n) [Part2 2.1 Graph Edges & 2.2 Graph Nodes]
In the above sections, please provide an examples of non-XML data
structures, such as a 'struct' and 'array' from a programming language, and
how these map to abstract nodes and edges, or alternately include a
hyperlink to such examples in a separate document.

o) [Part2
  3.1.1 Encoding graph edges and nodes &
  3.1.2 Encoding simple values &
  3.1.3 Encoding compound values &
  3.1.4 Computing the Type Name property &
  3.1.5 Unique identifiers &
  3.1.6 arraySize Attribute Information Item]
For each of the above sections, please include at least one example, or
alternately include a hyperlink to an example in a separate document.

p) [Part2 3.1 Rules for encoding Graphs in XML]
"The encodings are described below from the perspective of a de-serializer."
Not only does this point of view conflict with the section name, it also
makes understanding the encoding unnecessarily difficult. Please re-write
this section from the point of view of an XML serializer.

q) [Part2 3.1.1 Encoding graph edges and nodes]
The first sentence of this section is strongly worded, and suggests that
element information items *only* represent edges, when in fact they at times
represent a combined edge and node. (for example in the first sentence of
3.1.3) Please correct this.
Bullet 4 mentions "a graph edge [that] does not terminate in a graph node".
This is confusing, and seemingly in conflict with the first sentence in 2.1:
" Edges in the graph are said to originate at a graph node and terminate at
a graph node."
[email]
Proposal:
Resolution:
Here is a brief summary of our decisions regarding your individual
suggestions:

>> n) [Part2 2.1 Graph Edges & 2.2 Graph Nodes]
>> In the above sections, please provide an examples of non-XML data
>> structures, such as a 'struct' and 'array' from a programming language, and
>> how these map to abstract nodes and edges, or alternately include a
>> hyperlink to such examples in a separate document.

Our general intention has been to minimize the inclusion of tutorial
material in the normative portion of the specification.  In addition, we
note that the recommendation does not in fact define a mapping from
programming languages, but only from an abstract data model.  Finally, we
generally try to avoid examples involving particular programming languages,
as it is difficult to avoid implicitly supporting or undermining the
interests of various member organizations that base their investments on
particular programming languages or technologies.  Accordingly, we
respectfully decline this suggestion.

>> o) [Part2
>>   3.1.1 Encoding graph edges and nodes &
>>   3.1.2 Encoding simple values &
>>   3.1.3 Encoding compound values &
>>   3.1.4 Computing the Type Name property &
>>   3.1.5 Unique identifiers &
>>   3.1.6 arraySize Attribute Information Item]
>> For each of the above sections, please include at least one example, or
>> alternately include a hyperlink to an example in a separate document.

Here too, we respectfully decline to include examples in the normative
parts of the recommendation.

>> p) [Part2 3.1 Rules for encoding Graphs in XML]
>> "The encodings are described below from the perspective of a de-serializer."
>> Not only does this point of view conflict with the section name, it also
>> makes understanding the encoding unnecessarily difficult. Please re-write
>> this section from the point of view of an XML serializer.

I was involved, along with one other editor, in drafting this section.  Our
original approach was indeed to adopt the perspective of the serializer.
In fact, this proved extremely difficult, and the current formulation
proved much more straightforward.  Though there are a number of subtleties,
the essence of the reason is that there is a 1-to-many relationship of
graphs to encodings:  the same graph can in general be represented many
ways (for example, the placement in the xml of targets of a ref= attribute
is in many cases not significant.  Conversely, each serialized encoding
represents exactly one graph.  Accordingly, we start with a serialization
and say essentially "this is THE graph it represents".  We then say in
effect "to serialize a graph, you can use any of the representations the
decode to the correct graph."

We agree that the title of the section was misleading, and have therefore
in response to your suggestion we have renamed it:  "Mapping between XML
and the SOAP Data Model".

>> q) [Part2 3.1.1 Encoding graph edges and nodes]
>> The first sentence of this section is strongly worded, and suggests that
>> element information items *only* represent edges, when in fact they at times
>> represent a combined edge and node. (for example in the first sentence of
>> 3.1.3) Please correct this.

As you suggest, the text in section 3.1.1 has been updated [3]. It now reads:

"1. If the element information item representing the edge does not have a
ref attribute information item (see 3.1.5.2 ref Attribute Information Item)
among its attributes then that element information item is said to
represent a node in the graph and the edge terminates at that node.

In such cases the element information item represents both a graph edge and
a graph node."

>> Bullet 4 mentions "a graph edge [that] does not terminate in a graph node".
>> This is confusing, and seemingly in conflict with the first sentence in 2.1:
>> " Edges in the graph are said to originate at a graph node and terminate at
>> a graph node."

In closing issue 302 [4], the workgroup has verified its decision that
edges can be "dangling" at either the source or the destination end.  The
note resolving that issue is at [5], and it includes a statement of our
intention to:

"close this issue by adding the following
text to Section 2.1 [6] {<== reference number changed...NRM}

"An edge MAY have only an originating graph node, that is be outbound only.
An edge MAY have only a terminating graph node, that is be inbound only."
  
[email]
354specn/aEditorialDesignClosedMicah Dubinko
Title: Part 0 - clarifications on terms
Description:
a) [Part0 3. Using various protocol bindings]
"...an encrypted form." Can you clarify in the text whether you mean 'a
fill-out form' vs. "the mode in which a thing exists"? [dictionary.com]

b) [Part0 3.1.1. SOAP HTTP GET usage]
Please mention that to use an XML SOAP envelope as XForms external instance
data, HTTP GET usage (SOAP Response Message Exchange Pattern) is required.
At the editors' discretion, you might also mention other similar cases, such
as document() in XSLT, etc.
[email]
Proposal:
Resolution:
Comment a) has been incorporated into the editor's copy of the Primer
[email]
355specn/aEncodingDesignClosedMicah Dubinko
Title: May a SOAP infoset legally contain comment information items?
Description:
c) [Part1 5. SOAP Message Construct]
May a SOAP infoset legally contain comment information items? If yes, where?
Please clarify.
[email]
Proposal: See Gudge's proposal
Resolution:
 
The WG resolved this by saying that comments are allowed
anywhere in the [document element] but not before or after that element.
There are some restrictions in the processing model WRT when comments
can be added and/or removed. [2].
  
[email]
356specn/ametaDesignClosedMicah Dubinko
Title: SOAP Body child Element namespace qualified
Description:
d) [Part1 5.3.1 SOAP Body child Element]
Child elements "MUST have a [namespace name] property which has a value,
that is, be namespace qualified." We request removing this restriction for
the following reason:
Many XML Forms use non-namespaced instance data, and we expect SOAP to
become a common source of instance data for such Forms. Thus, a requirement
for namespaces would put an unnecessary burden on adoption of both SOAP and
XForms.
[email]
Proposal:
Resolution:
The XML Protocol WG has decided to close issue 356 by changing the 
MUST requirement for namespace qualification of SOAP Body
content to a SHOULD with a descriptive note explaining the reason for
the SHOULD. The resolution text which will be applied to Part1 5.3.1
"SOAP Body child Element" is the following:

* * * * * 

Zero or more information items in its [children] property. Child element
information items SHOULD be namespace qualified.

NOTE: namespace qualified elements tend to produce messages whose
interpretation is less ambiguous than those with unqualified elements.
The use of unqualified elements is therefore discouraged.

* * * * * 
  
[email]
357specn/aEditorialDesignClosedMicah Dubinko
Title: Fault names
Description:
e) [Part1 5.4.6 SOAP Fault Codes]
Please change the name of the "DataEncodingUnknown" fault code to the more
accurate "SOAPEncodingUnknown".

f) [Part1 5.4.8 SOAP mustUnderstand Faults]
The name "Misunderstood" suggests that the processor incorrectly attempted
to do something. "NotUnderstood" is a more accurate name.
[email]
Proposal:
Resolution:
For e) we chose to maintain the name "DataEncodingUnknown" as
"SOAPEncoding" can be misunderstood to refer to the specific encoding
provided in SOAP 1.2 part 2. The fault code in question can be used with
any encoding scheme used.

For f) we agreed with the proposal and changed the name to
"NotUnderstood".
  
[email]
358specn/ametaDesignClosedMicah Dubinko
Title: URI length
Description:
g) [Part1 6. Use of URIs in SOAP]
"SOAP receivers SHOULD be able to deal with URIs of at least 2048 characters
in length"
We request that this be a MUST requirement.
[email]
Proposal:
  Gudge's proposal: this is a duplicate of closed issue 336.
  See Henrik's proposal
Resolution:
The XMLP WG has decided to close issue 358 without taking any action.
This was a duplicate of issue 336 [2], the resolution text was:

<_336>
 The XML Protocol WG considered issue 336 today, an issue that you raised
 on the SOAP spec's statements about the length of URIs.  Rather than
 having some statement containing overlapping SHOULDs (SHOULD support
 URIs of arbitrary length and SHOULD support URIs of length 2048), it
 was felt that the existing text already provided appropriate motivation
 for handling URIs of arbitrary length.  Therefore, no change is being
 made to the specification.
</_336>

Quoting directly from an email[3] on the xml-dist-app list:

<furtherReasoning> 
1) We don't enforce any max number of URIs to be used in a SOAP message 
which could then be interpreted as saying that we require infinite buffering 
on a SOAP node.

2) Related to 1), we don't enforce any max size on a SOAP message itself 

3) The current text makes it clear that "Any SOAP node MUST be able to 
handle the length of any URI that it publishes" so we do have a MUST 
requirement for any given SOAP node.  
</furtherReasoning>
  
[email
359specn/ametaDesignClosedMicah Dubinko
Title: SOAP 1.1 to 1.2 transition non normative section
Description:
h) [Part1 A. Version Transition From SOAP/1.1 to SOAP Version 1.2]
This section states that SOAP nodes receiving SOAP/1.1 messages either:
1 "MAY process the message as a SOAP/1.1 message (if supported), or"
2 "MUST generate a version mismatch SOAP fault based on a SOAP/1.1 message
construct following SOAP/1.1 semantics."
Either way, a reference to SOAP/1.1 ([19] in the current document) is
required. Since that appendix is not specifically marked "non-normative",
the reference would have to be normative, and thus all conforming SOAP/1.2
processors also must implement a portion of SOAP/1.1. Please ensure that
conformance to this section of SOAP/1.1 is considered a "feature" for
purposes of exit criteria.
[email]
Proposal: See email, and email.
Resolution:
At the SOAP WG F2F meeting on October 30th, the WG agreed to resolve issue
359 by adopting the text in

http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0170.html
[email]
360specn/ametaDesignClosedMicah Dubinko
Title: Modularization - separate docs
Description:
i) [Part2 Sections 2-4 & Appendix A (re: SOAP encoding and RPC
Representation)]
We request that these optional sections be moved into a separate document.
We note the success with which XHTML, SVG, CSS, and XPointer have done
similar modularization.

As written, these optional sections contain optional subsections (and even
required subsections), which is unnecessarily complex. As a separate
document, the conformance requirements for RPC SOAP can be more clearly
spelled out, and the result will be smaller, simpler SOAP specifications.
[email]
Proposal: Gudge's proposal:
  This issue is a duplicate of earlier issue 198[2]. I propose we close it
  with no action.
  
Resolution:
The XMLP WG decided to close issue 360 which you raised with no action
taken as this issue is a duplicate of issue 198 [2], which was closed 
before last call [3].
    
[email]
361specn/aEditorialDesignClosedMicah Dubinko
Title: Part 2 - Change ItemType AII to childItemType
Description:
j) [Part2 2.3 Values]
We agree with the editorial note which suggests removing "generics".

k) [Part2 3.1.4.1 itemType Attribute Information Item]
Please change the name of this to "childItemType".
[email]
Proposal:
Resolution:
The specific requests that we included in this issue, and their resolution
are:

> j) [Part2 2.3 Values]
> We agree with the editorial note which suggests removing "generics".

The workgroup has decided to accept your suggestion and remove generics
from the design.  The only compound values supported will be arrays and
structs.

> k) [Part2 3.1.4.1 itemType Attribute
> Information Item] Please change the
> name of this to "childItemType".

The members of the XML protocol workgroup have decided that itemType is on
balance a better name, and have therefore decided not to adopt your
suggestion in this area.
    
[email]
362specn/ametaDesignClosedMicah Dubinko
Title: ref/ifref (part 2)
Description:
l) [Part2 3.1.5.2 ref Attribute Information Item]
Please change the name of this to "idref". This not only more closely
represents the type of the attribute (xs:IDREF), but also avoids cognitive
dissonance with the XForms attribute 'ref' (which bears an XPath
expression).

m) [Part2 3.2 Decoding Faults]
id->idref constraint violations are serious problems. Please change 'SHOULD'
to 'MUST' on the requirement to signal a fault under these conditions.
[email]
Proposal: Gudge's proposals: for 1 st partsecond part:
  If we decide to close issue 326 by qualifying attribute I think part
  A of this issue can be closed with no action as the XForms ref
  attribute is unqualified ( and ours will then be qualified ). If we do
  decide to leave our ref attribute unqualified then we should probably
  think about changing the name.

  I propose that we close part b of this issue with no action. The
  id/idrefs in question are those found in SOAP encoding. The rule does
  not apply to general ID/IDREFs. In fact, we can't detect general
  ID/IDREF without schema validation, which is optional anyway.
  
Resolution:
We divided the issue into two related parts:

Part I:
"l) [Part2 3.1.5.2 ref Attribute Information Item]

The Protocols Workgroup has recently decided to add namespace qualification
to all of our attributes, and in particular to the attribute formerly known
as "ref".  We believe that the resulting qualified attribute is
sufficiently distinct as to not cause confusion with XForms.  In general,
we name our attributes by their purpose, not their type, and so
respectfully decline to use IDREF as the localname of the attribute.

Part II:
"[Part2 3.2 Decoding Faults]

We note that SOAP processing never depends on validation [3]:

"SOAP does not require that XML Schema processing (assessment or
validation) be performed to establish the correctness or 'schema implied'
values of element and attribute information items defined by this
specification."

Indeed, the soapenc:ref and soapenc:id attributes (the new names) are
provided for SOAP's own purposes.  We note further that there are many
reasonable situations in which checking for a match of id and idref might
be inappropriate.  For example, the application might determine, perhaps by
processing a header, that it has no need to inspect the encoded data at
all.  Making the check a MUST would require the node to check the ID/IDREF
pairs, regardless of whether the data is needed by the application.  We
therefore believe that SHOULD is the best description of our intent, which
is that in most cases the correctness of the reference should be checked.
In any case, we specifically decline to associate such checking with a need
to do XML Schema or DTD validation:  such validation is allowed as if the
application so desires, but is never required and is considered
non-normative. [4]
[email]
363specn/ametaDesignClosedRobert Van Engelen
Title: RPC return accessor
Description:
1. It is our opinion that the SOAP RPC return value accessor is ambiguous
   and imposes unnecessary processing complexities. For details on this  
   issue, please refer to earlier message
[email]
Proposal:
Resolution:
The XMLP WG has decided to close issue [1] "RPC return accessor" without
taking any action.  This issue has been subsumed by the fact that we have
dropped the RPC array representation [2].
  
[email]
364specn/ametaDesignClosedRobert Van Engelen
Title: id and ref emutually xclusive
Description:
Section 3.1.5.3 in "SOAP 1.2 Adjuncts" forbids id and ref attribute
information items to appear in the same element information item.
It is our opinion that this constraint unnecessarily limits the
object graph data model. The resulting admissible data model does
not allow for "pointer chain" graphs. Details can be found in 
earlier message
[email]
Proposal: see email
Resolution:
 
The XMLP WG has decided to close issue 364 (that you raised about 
id and ref attributes being mutually exclusive) with no changes to the
specification. The rationale is explained in [2].
    
[email]
365specn/ametaDesignClosedRobert Van Engelen
Title: Generics
Description:
To comment on the Editor's request for comments on "generics":

  It is our opinion that generics should be kept in the specification.
  Generics are useful mainly from a practical point of view because
  generics do not widen the gap between SOAP RPC and SOAP DOC/LIT
  data models. We believe that abolishing generics only widens this
  data modeling gap, thereby unnecessarily limiting the expressiveness
  of the data model of SOAP RPC.
[email]
Proposal:
Resolution:
You also asked that generics be kept in the SOAP specification.

The XMLP WG earlier decided to close Issue 297 by removing 
generics. The entire rationale for removing generics is available 
at [1], but an abreviated version is given here for ease of access.

Essentially, the XMLP WG is of the opinion that generics are 
unnecessary in the Data Model. The issue was discussed among the 
implementors and among the xml-dist-app community without 
reaching any obvious consensus. In addition, feedback was asked 
by an ednote in Part 2, Section 2.3. The prevalent feedback was 
that generics be removed. Finally, XMLP WG implementors have 
confirmed they would welcome removing generics (with the 
exception of WebMethods, which prefered to keep generics but did 
not oppose the decision).
  
[email]
366specn/ametaDesignClosedRobert Van Engelen
Title: Generic type for struct and array
Description:
We do not oppose the array representation of SOAP RPC invocation. 
However, we do strongly suggest the use of generic types to support
both struct and array parameter paradigms. In fact, it is our
opinion that generics should be the ONLY parameter marshalling type.
In that way, polymorphic remote methods and remote methods with
variable number of parameters can be supported, while providing a
similar functionality as parameter marshallings based on structs
and arrays.
[email]
Proposal:
Resolution:
You asked that SOAP 1.2 include a generic type for structs and 
arrays.

The XMLP WG earlier decided to close Issue 297 by removing 
generics. The entire rationale for removing generics is available 
at [1], but an abreviated version is given here for ease of access.

Essentially, the XMLP WG is of the opinion that generics are 
unnecessary in the Data Model. The issue was discussed among the 
implementors and among the xml-dist-app community without 
reaching any obvious consensus. In addition, feedback was asked 
by an ednote in Part 2, Section 2.3. The prevalent feedback was 
that generics be removed. Finally, XMLP WG implementors have 
confirmed they would welcome removing generics (with the 
exception of WebMethods, which prefered to keep generics but did 
not oppose the decision).
  
[email]
367specn/ametaDesignClosedKirill Gavrylyu
Title: QA - Scope of the spec.
Description:
There is no dedicated section that would explain what is in scope and 
what is explicitly left out of scope of the specification.
[email, report]
Proposal: See email and following thread
Resolution:
Issue 367, we have introduced a Conformance section as requested, see 
[1].
  
[email
368specn/ametaDesignClosedKirill Gavrylyu
Title: QA - Conformance section
Description:
There is no dedicated Conformance section that would 

o       Define what is the object of the spec (SOAP Processor) and what
is it.

o       when an implementation could claim conformance to the SOAP 1.2
spec, and what does it mean.

o       clearly state that Part I is obligatory and any adjunct from the
Part II is optional. What combinations of the adjuncts in Part II are
allowed. 

o       State explicitly, does the implementation of the Part I that
does not use any of the adjunct of the Part II still conform to the SOAP
1.2 specification.
[email, report]
Proposal: See email and following thread
Resolution:
Issue 368,  within the new conformance section:
-- we describe what constitutes (the scope of) an implementation, see also
"SOAP node" in the glossary [4].
-- we say when an implementation can say it conforms
-- we clarify the requirements for implementing Parts 1 and 2
  
[email
369specn/ametaDesignClosedKirill Gavrylyu
Title: QA - Not clear if the implementation is required to implement any of the adjuncts from the Part 2
Description:
Embedded in the issue 368. Not clear if the implementation is
required to implement any of the adjuncts from the Part 2 in order to
conform to the SOAP 1.2 specification. 
[email, report]
Proposal: See email and following thread
Resolution:
Issue 369, covered under resolution of #368
  
[email
370specn/ametaDesignClosedKirill Gavrylyu
Title: QA - No definition of SOAP Processor
Description:
Embedded in the issue 368. 
Not defined what can be called a "SOAP Processor". 
[email, report]
Proposal:
  Proposal: The term "SOAP processor" is a leftover from old terminology
  and should be changed to "SOAP node". It occurs in the status section of
  part 1 and throughout part 2.
  
[email]
Resolution:
The XMLP WG has decided to close issue 370 with a text change.  As you
pointed out "SOAP processor" is not defined.  The term "SOAP processor" is a
leftover from old terminology and will be changed to "SOAP node" throughout
Part 1 and Part 2.
    
[email]
371specn/ametaDesignClosedKirill Gavrylyu
Title: QA - Multiple Choice Assertions
Description:
For some of the multiple-choice assertions, it is not explicitly
defined whether the choice must be consistent by the SOAP Node or not.
For example, in the section 2.4, assertion regarding mustUnderstand SOAP
headers that allows to either process the Header marked as
MustUnderstand or generate a Fault message. It is not clear under which
circumstances the behavior of the SOAP Node MUST remain consistent.
[email, report]
Proposal: See proposal and following thread.
Resolution:
 The XMLP WG decided to close issue 371 you raised by adding a
 sentence to section 2.6 of Part 1.

 Original Text:
 "In all cases where a SOAP header block is processed, the SOAP node MUST
 understand the SOAP header block and MUST do such processing in a manner
 fully conformant with the specification for that header block."

 Modified Text:
 "In all cases where a SOAP header block is processed, the SOAP node MUST
 understand the SOAP header block and MUST do such processing in a manner
 fully conformant with the specification for that header block. The
 successful processing of one header block does not guarantee successful
 processing of another block with the same fully qualified name within
 the same message: the specification for the header block determines the
 circumstances in which such processing would result in a fault."
  
[email]
372specn/aEditorialDesignClosedDavid Costanzo
Title: Typographical comments on "SOAP Version 1.2 Part 0: Primer"
Description:
The following comments apply to the document at:

   http://www.w3.org/TR/soap12-part0/

   This seems to be more recent the "editor's latest
   draft".  However, many of the typos are in both
   documents.

   There are several inconsistent uses of the article "a"
   and "an" when they precede acronyms or abbreviations
   that begin with a vowel sounding letter.

   * There are about ten instances of "a RPC" and three
   instances of "an RPC".  To me, "an RPC" reads better.
   * There are four instances of "a URI" and one instance
   of "an URI".  To me, "a URI" reads better.
   * There is one instance of "an URL".  To me, "a URL
   reads better".

   Section 2.2.2.  In the phrase "... where the purpose
   appear to be ...", "appear" should be changed to
   "appears".

   Section 2.2.2.  In the phrase "... the RPC response is
   returned in the body element of a SOAP message, with
   is modelled as a ...", "with" should be "which".

   Section 2.2.2.  In the phrase "... which is an
   enumeration with potential values of 'confirmed', and
   'pending' ...", the comma just before "and" should be
   removed.

   Section 2.2.2.  In the phrase "... thereby making the
   RPC inependent of any underlying transfer mechanism.",
   the word "inependent" should be corrected to
   "independent".
[email]
Proposal:
Resolution:
This comment has been incorporated into the editor's copy of the Primer
[email]
373specn/aEditorialDesignClosedMartin Duerst
Title: Character Model - text normalization
Description:
At our editorial meeting last week, the I18N WG realized that
some important points were missing from our last call review
of SOAP 1.2.

In the last call review of the Character Model by the XML Protocol
WG, the XML Protocol WG and the I18N WG/IG have been discussing
how text normalization should apply to SOAP. For a compact
summary of the decisions arrived, see:
http://www.w3.org/International/Group/2002/charmod-lc/#C062

However, we have not found any text in the SOAP specs that says
that the envelope/headers have to be normalized, nor that it is
the responsibility of the payload provider to provide a suitably
normalized payload.
[email]
Proposal:
Resolution:
The SOAP WG has decided to close issue 373 - Normalisation of text in
envelope/header/body.

Previous discussions with I18N led the SOAP WG to decide that we would not
require normalization of text.
See the discussion at
http://www.w3.org/International/Group/2002/charmod-lc/#C062
  
[email]
383specn/ametaDesignClosedHervé Ruellan
Title: Part 2 - Table 17 discrepancies
Description:
While reading Section 7.5.1 [1] and Section 7.5.2 [2] of part 2, it 
seems that Table 17 [3] is not fully in sync with what the SOAP receiver 
might generate.
A SOAP receiver might generate a 400 HTTP Status code either in its Init 
state or in its Receiving state. In the first case, the HTTP response 
contains no SOAP fault and accordingly, the SOAP requestor should 
transition to the Fail state, while in the second case, the HTTP 
response may contain a SOAP fault and if this is the case, the SOAP 
requestor should transition to the Sending+Receiving state.
[email]
Proposal:
  The proposal is to change the 400 line in Table 17 to take into account 
  both these cases:
  <proposal>
  400  Bad Request

  If the media type does not correspond to a SOAP message, indicates a 
  problem with the received HTTP request message. This operation SHOULD 
  NOT be repeated with the same message content. The message exchange is 
  regarded as having completed unsuccessfully.
  Instantiated Property       Value
  context:FailureReason       "fail:BadRequest"
  Next State: Fail

  If the media type corresponds to a SOAP message, indicates a problem 
  with the received SOAP message. This operation SHOULD NOT be repeated 
  with the same message content. The local binding instance continues to 
  receive the incoming message.
  Instantiated Property       Value
  context:FailureReason       "fail:BadRequest"
  Next State: Sending+Receiving
  </proposal>
  
See also email,email.
Resolution:
Rationale for changes:

400 and 500 could both be generated by a server with or without a SOAP 
fault in the body of the response: table 23 defines responses including 
SOAP faults for both of these status codes, a HTTP server could also 
generate either prior to SOAP processing. The current text assumes that 
400 will not have a SOAP fault in the body and 500 will have a SOAP 
fault in the body

Proposed changes:

Paragraph before table 17.

<current>
Table 17 details the transitions that take place when a requesting SOAP 
node receives an HTTP status line and response header. Table 17 refers 
to some but not all of the existing HTTP/1.1 [RFC 2616] status codes. 
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.
</current>

<proposed>
Table 17 details the transitions that take place when a requesting SOAP 
node receives an HTTP status line and response header. <new>For some 
status codes there are two possible next states: Fail and 
Sending+Receiving. <FriendlyAmendment>
In these cases the transition is dependent on whether a SOAP message is
present in the HTTP response. If a SOAP message is present, the next
state is "Sending+Receiving"; otherwise the next state is "Fail".
<FriendlyAmendment> </new>

Table 17 refers to some but not all of the existing HTTP/1.1 [RFC 2616] 
status codes. 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.
</proposed>

Table 17 row for 400, adding Sending+Receiving as a possible next state

<current>
Indicates a problem with the received HTTP request message. The problem 
can be malformed XML in the request message envelope. This operation 
SHOULD NOT be repeated with the same message content. The message 
exchange is regarded as having completed unsuccessfully.
</current>

<proposed>
Indicates a problem with the received request message.
</proposed>

Table 17 row for 500, adding Fail as a possible next state

<current>
Indicates that the response message contained in the following HTTP 
response entity body may contain a SOAP fault. Other internal server 
errors may be the cause of this status code. The local binding instance 
continues to receive the incoming message.
</current>

<proposed>
Indicates a server problem or a problem with the received request 
message.
</proposed>
  
[email]
384specn/ametaDesignClosedMark Baker
Title: Are gateways SOAP intermediaries?
Description:
The current definition of a SOAP intermediary says;

  "A SOAP intermediary is both a SOAP receiver and a SOAP sender and is 
  targetable from within a SOAP message. It processes the SOAP header 
  blocks targeted at it and acts to forward a SOAP message towards an 
  ultimate SOAP receiver."

"SOAP message path" is defined as;

  "The set of SOAP nodes through which a single SOAP message passes.  
  This includes the initial SOAP sender, zero or more SOAP 
  intermediaries, and an ultimate SOAP receiver.

"Ultimate SOAP receiver" includes this in its definition;

  "An ultimate SOAP receiver cannot also be a SOAP intermediary for the 
  same SOAP message"

The second definition suggests that the ultimate SOAP receiver cannot
itself be a SOAP intermediary.  The third point explicitly says this,
though with the qualification "for the same SOAP message" (which is
unclear).  But the first, in the first sentence, would seem to include
gateways in its definition, as they meet all three criteria; SOAP
receiver, SOAP sender, targettable.

At this late stage, I'm only going to ask that the specification be
clear about how gateways fit, or don't, as the case may be.

P.S. section 2.1 redefines "SOAP intermediary" in the second sentence of
the first paragraph, differently than in section 1.4.3.  I suggest it be
removed from 2.1.
[email]
Proposal:
Resolution:
In response to issue 384, the WG has decided to say that SOAP
gateways are not SOAP intermediaries and therefore not to introduce the
notion of a SOAP gateway into the SOAP spec. The reason is that a SOAP
intermediary is defined in terms of a SOAP receiver and a SOAP sender
which the WG did not associate with traditional gateway functionality.
The WG recognizes that there may be gateways at the level of underlying
protocols but the SOAP spec does not provide an architecture for talking
about such gateways (see also [1] (Member only)).

The WG agrees with your editorial suggestion and will fix the spec
accordingly.
[email]
385AF docn/ametaDesignClosedKirill Gavrylyuk
Title: Add a conformance clause
Description:
1. Conformance clause should be added that would 

-  describe the subject of conformance (a binding specification)

-  summarizes what does it mean to conform to this specification

-  List dependencies: describe what other parts of SOAP
1.2 specification/other specifications a binding must conform to in
order to conform to this specification
[email]
Proposal: See email
Resolution:
The XMLP WG has agreed to resolve issue 385
by adding a new Conformance section to the Attachment Feature
document containing the following text:

"This document describes an attachment feature which is an abstract
model, and conformance is a property of binding specifications or
modules that use this model.

A binding specification or a module using this model is conformant if it
follows all the requirements of this specification (see in particular 6.
Implementation)."
  
[email]
386AF docn/ametaDesignClosedKirill Gavrylyuk
Title: Prefix att is not defined
Description:
2. Prefix att is not defined. QNames of the form att:* are used, but
prefix att is not associated with any namespace. Would be good to
explicitly associate it in the prose with the URI
http://www.w3.org/2002/06/soap/features/attachment
[email]
Proposal: See proposal.
Resolution:
As the consequence of the resolution of another issue, the "att" Prefix 
is no more used as a Namespace prefix in this document (this is not yet 
reflected in the spec). Accordingly, the Working Group has decided to 
solve issue 386 by taking no action.
  
i[email]
387AF docn/ametaDesignClosedKirill Gavrylyuk
Title: Change "can" to "may" (...) to conform to RFC 2119
Description:
3. Sec 2 - Change "can" to "may" in the "Protocol binding specifications
can use this URI"  to conform to RFC 2119. Unless there is a good
reason, we suggest to even change it to "should", so that there is not
ambiguity on whether the specific binding uses the soap1.2 attachment
feature.
[email]
Proposal: See proposal.
Resolution:
The working group has agreed to close this issue by changing section 2 
to be:
<section2>
2. SOAP Feature Name

This Attachment Feature is identified by the URI (see [SOAP Part 1] SOAP 
Protocol Binding Framework):
     * "http://www.w3.org/2002/06/soap/features/attachment".
</section2>
[email]
388AF docn/ametaDesignClosedKirill Gavrylyuk
Title: explicitly reference the equivalence rules used for the URIs
Description:
4. Section 6: We suggest to explicitly reference the equivalence rules
used for the URIs when the message parts are identified. (We believe
editors meant the URI equivalence rules specified in the URI spec [3]).
The fact that XML namespace spec uses different equivalence rules for
namespace URIs then the original URI spec causes a confusion among
developers on which rules to use in each case of the URIs use. 
[email]
Proposal: See proposal
Resolution:
You raised the following last call issue against the XML Protocol
Attachment Feature document:

  "4. Section 6: We suggest to explicitly reference the equivalence rules
  used for the URIs when the message parts are identified. (We believe
  editors meant the URI equivalence rules specified in the URI spec [3]).
  The fact that XML namespace spec uses different equivalence rules for
  namespace URIs then the original URI spec causes a confusion among
  developers on which rules to use in each case of the URIs use."

Section 6 of SOAP 1.2 Part 1 discusses uses of URIs in SOAP including 
determination of a base URI for relative URIs and URI equivalence 
rules.  We propose to resolve your issue by adding a reference to this
section to the AF document (without duplicating text between Part 1 and the 
AF specification).  The revised text reads:

      *  A mechanism by which each part is identified using one (or more) 
    URI(s), see (ref to SOAP Part 1, 6. Use of URIs in SOAP). The URI 
    scheme used MAY but need not be the same for all parts. The URI scheme 
    used for multiple identifiers of a single part MAY but need not be the 
    same.

    Note: the ability to identify a single part with multiple URIs is 
    provided because, in general, the Web architecture allows such multiple 
    names for a single resource. It is anticipated that most bindings will 
    name each part with a single URI, and through the use of base URIs, 
    provide for absolute and/or relative URI references to that URI.
[email]
389specn/aEditorialDesignClosedJacek Kopecky
Title: Possibly editorial problem in Data Model and Encoding
Description:
The section 2 [1] - SOAP Data Model - speaks (among others) about simple
and compound values, terminal and non-terminal graph nodes, structs and
arrays. It says that a simple value is a terminal graph node and that a
compound value is a non-terminal graph node. The latter need not be
true, consider an empty struct or array - both are terminal nodes but
certainly not simple values.

Further, the distinction between terminal and non-terminal graph nodes
brings confusion when combined with the newly agreed-on attribute name
'nodeType' (created for issue 231 [2] resolution) because while section
2.2 differentiates terminal and non-terminal nodes and single- and
multi-reference nodes while this nodeType attribute introduces a third
differentiation.

Since the terminal vs. non-terminal node distinction is only used in
places where it is used (mostly?) improperly and where what matters is
the difference between a simple value and a compound value, represented
by a struct node or an array node (these names are introduced in section
2.3), I think the terminal and non-terminal distinction should be
removed or replaced by the compound vs. simple value distinction.

My opinion is that this would be an editorial change because it only
simplifies terminology used in a few places in section 2 and 3 of the
Adjuncts.
[email]
Proposal: See proposal.
Resolution:
The Working Group has decided to close the editorial issue 389 using
the proposed text [2] (amended in [3]).

The issue deals with the distinction of terminal and non-terminal nodes
in the Data Model and Encoding in the Last Call draft of SOAP 1.2, which
was only used in places where it was unnecessary and/or incorrect.

The resolution basically removes the distinction.
[email
390AF docn/ametaDesignClosedHugo Haas
Title: usage of URIs for identifying secondary parts
Description:
The motivation for the usage of URIs for identifying secondary parts
is incomplete. It seems apparent for performance and other reasons
that a part will be a representation of a resource. And packaging will
enable higher performance. We recommend the XML Protocol Working Group
to document the motivations for using the SOAP Attachment Feature,
for example with a set of usage scenarios.

In some cases, it seems likely a move from use of a resource on the
web to adding a part to the package could result in a need to modify
the representation of any reference to that resource. For example, a
reference in a SOAP element might be <http://example.com/Sound.wav>.
My SOAP application now uses some SOAP attachment feature, perhaps
MIME. The representation is now identified by
<cid:someidentifierforSoundwav>. I have to change the SOAP message to
use the new URI. It would seem cleaner if the reference stayed the
same, and the SOAP application did not have to modify these
references.

To avoid this problem, we recommend specifically calling out the DIME
features allowing an included part to be identified using its existing
URI. For MIME, the text should discuss the inclusion of a
content-location header to server the same purpose. This would allow a
recommendation along the lines of "applications SHOULD avoid a need to
convert references as parts are added to a SOAP message."
[email]
Proposal: See email
Resolution:
The first part of the issue is a general request to explain why and
when using the attachments (rather than links to resources):
    " We recommend the XML Protocol Working Group
    to document the motivations for using the SOAP Attachment Feature,
    for example with a set of usage scenarios."

In AF's doc introduction [1], the 3 bullets give use cases of attachments
from a SOAP point of view. An attachment is a particular part of the
SOAP message. We don't see any further need to give use cases of attachment
along with some particular implementations and particular bindings.
The attachment feature was designed initially to complete the SOAP 
specification. 
 
 The second part of the issue asks clarifications about how resources
 on the web (referenced by a URI) are added as a part (how a change of
 reference is handled): 
	" For example, a reference in a SOAP element might be 
	<http://example.com/Sound.wav>. My SOAP application now uses some 
	SOAP attachment feature, perhaps  MIME. The representation is now 
	identified by <cid:someidentifierforSoundwav>. "

We claim that the semantics is not the same when you refer to an external
URI than when you attach a particular representation of that resource (a
snapshot). We allow both external and internal reference to           
a resource, which are different usages, but we do not preclude any.
 
 Wrt referencing attachment in general, it is a binding problem and not
 an attachment feature issue. It is possible to refer either to external 
 URIs, either to parts of the secondary bag. The way the URI is resolved
 is certainly not in scope of the Attachment feature.
[email]
391AF docn/ametaDesignClosedHugo Haas
Title: how IDREF/URIs would be dereferenced
Description:
The SOAP encoding allows references by IDREFs inside the SOAP
envelope. A natural and common way to reference something on the Web
is to use a reference to a resource using an http: URI. The
Attachment Feature document suggests that such references are to be
handled by the Attachment Feature (example 3 in section 6).

It is unclear, with the current SOAP Version 1.2 specification, how
such URIs would be dereferenced, i.e. as part of the HTTP binding,   
by the SOAP processor, etc. Some clarity about this example is
desired.

Also, in such a case where the secondary parts do not travel along
with this message, the term "attachment" is awkward to talk about those
resources that need to be dereferenced.
[email]
Proposal: See email
Resolution:
At the SOAP WG F2F meeting on October 30th, the WG agreed to resolve this
issue by adopting the proposal in [3].
  
[email]
392AF docn/ametaDesignClosedHugo Haas
Title: Intermediaries and secondary parts
Description:
We are concerned about the interaction of URI addressing schemes to
secondary parts and the SOAP execution model which permits various
SOAP headers to be inserted and deleted by intermediaries under
appropriate conditions (roles must match, software modules must exist,
etc.). Are there similarly conditions under which intermediaries may
insert and delete secondary parts? For example, are they allowed to
create "dangling URIs"?

Secondly, is it clear which URI schemes are impervious to insertion,
deletion, and modification of secondary parts? For example, might
there be a uniqueness problem with IDREFs?
[email]
Proposal: See proposal
Resolution:
You raised earlier issue 392. The issue contains two parts:

[P1] You asked whether intermediaries are allowed to add/remove 
secondary parts. More generally, you wondered whether there 
should be an equivalent to our well-known processing model, but 
one that would apply to secondary parts, not header blocks.

[P2] You wondered whether some URI schemes are better adapted to 
insertion, deletion, and modification of secondary parts.

The XMLP WG considers that this issue should be addressed by the 
AF specification and has decided to incorporate the text below.

Regarding part 2, the WG considers that particular URI schemes 
should not be prescribed or rejected by the abstract AF 
specification, but by concrete attachment specifications only.

[New section in AF document]

Intermediary Considerations
===========================
A SOAP message can travel through zero or more SOAP
intermediaries. This sections describes the requirements posed on
SOAP intermediaries supporting this specification.

A SOAP intermediary MUST be able to access any secondary part.

A forwarding SOAP intermediary MUST in general forward every
secondary parts contained in the incoming SOAP message, except
when the specification for a processed SOAP header block calls 
for the part to be removed or changed. An active SOAP 
intermediary MAY change or remove any secondary part even in the 
absence of such a mandate.

A SOAP intermediary MAY insert new secondary parts.

The integrity of references (i.e. URIs) to secondary parts MUST 
be maintained accross SOAP intermediaries. That is, a URI which 
resolves to a secondary part in an inbound SOAP message MUST 
continue to resolve to that part in the outbound message, unless 
that part was removed by the SOAP intermediary.
  
[email]
393AF docn/ametaDesignClosedHugo Haas
Title: Concrete attachment specification
Description:
The Web Services Architecture Working Group encourages the XML
Protocol Working Group to produce a concrete packaging (attachment)
specification to validate the SOAP/1.2 Attachment Feature
specification. A normative standard for a concrete specification is
also important for reference from other standards and specifications
and is considered a high priority by the WSAWG.

The XML Protocol Working Group  may be the most appropriate venue for
this work; if not, the Web Services Architecture Working Group will
probably recommend that a new Working Group be chartered to do this in
the near future because the lack of a concrete specification that can
be the basis for interoperable SOAP attachments implementations is a
hole in the Web services architecture that needs to be addressed as
soon as possible.
[email]
Proposal: See proposal
Resolution:
The XML Protocol WG has agreed in principle to investigate the
creation of a normative specification of a concrete instantiation of
the SOAP/1.2 Attachment Feature.  It will proceed by conducting due
diligence with respect to IPR issues, gathering requirements, etc.  It
is anticipated that existing specifications will provide a reasonable
starting point.  The timing of this activity will take into account
the higher priority of getting the primary SOAP 1.2 specifications to
recommendation.
[email]
394specn/ametaDesignClosedNoah Mendelsohn
Title: Some unprocessed headers should stay
Description:
The Problem
-----------

Among the reasons that we have the "next" role is for headers that
carry information to be available to all downstream nodes.  One of the
simplest scenarios would be to have such a header that would travel
with the message, to be available to those nodes that "understand" the
header, and to be ignored and passed on by nodes that do not
understand it.  As a simple example, I might want to put in the header
indicating the time at which the message was originally sent. More
substantively, I might wish to put in a digital signature, to be
checked by those who care, and ignored but retained by others.

SOAP 1.2 as proposed cannot support these simple scenarios. Why?
Because section 2.7.1[1] makes clear that a forwarding intermediary
MUST remove from the message all headers targeted to it, and can
trigger reinsertion only by processing and understanding a header.  In
the case where you don't understand the header, you must remove it.
It's essential to note that we are considering the case of
mustUnderstand='false'; there is no problem with the 'true' case.

Approaches to Resolving the Problem
-----------------------------------

Discussion of this problem has been going on at a low level for
awhile, in part because some of us have been trying to decide whether
the existing specification can somehow be made to do the right thing.
Given that we are in last call, that would obviously be a desirable
approach.  So, here I briefly outline some of the approaches that were
considered, and then in the next section I propose one that seems to
some of us to be the best.

It is tempting to ask whether a user might be able to design specific
headers and/or roles that would meet the need.  In other words: if I
define a role and some headers to use with it, then I could say that
you wouldn't assume that role unless you knew the specification for at
least one of the headers, and that specification would implement a
feature to change the relay rules for that role.  My personal
conclusion is that this is possible in principle, but would not be
practical when one considers the way that most SOAP software will in
fact be built.  Reason: the core rules regarding the relaying of
headers are baked into section 2.7.1, and in practice will often be
implemented by general-purpose SOAP middleware.  The key point is that
such middleware will in general be written to treat all user-defined
roles identically.  Allowing particular roles to change the relay
rules requires that such middleware have pluggable handlers that key
on specific role names, and this is something that few of us
anticipate doing.

There is another alternative which is also coherent, and indeed is
more powerful than the one proposed below, but which seems to be
overkill and would probably take us back to last call.  That
alternative would be to introduce a new attribute for use on header
entries along the lines of relayIfNotProcessed='true'.  Thus:

        <soap:Header>
                <nrm:myHeader role="..any role you like..."
	                                mustUnderstand="false"
	                                relayIfNotProcessed="true">
                        ...
                </nrm:myHeader>
       </soap:Header>

This seems to work, and has the capability of working with any role.
It just seems like more power and complexity than we need to deal with
the specific use case.  If we were to get serious about this proposal,
there would be several details requiring refinement, but for now I am
just suggesting that this is not the direction to go.

Another possibility that has been raised would be to change the
default behavior to be: "leave in place any header entries that are
not processed".  Optionally, we could additionally define a
relayIfProcessed override if the group felt it to be worth the
trouble.  My impression is that some who have considered changing the
default rules like the idea, but some feel that it doesn't meet a need
to have headers that do indeed disappear when unprocessed.  For the
record, I quite like the idea, but (a) am not ready to take the lead in
pushing it in the face of any significant opposition and (b) would not
want to go back to last call if this were deemed a serious change--
I'm not sure it is.
[email]
Proposal:
Anyway, having done the above analysis, several of us conclude that:

* The use case is important that we must find a way to meet it
* The draft as written doesn't give explanation of how
* We need a simple, minimally invasive fix to what we have

We propose one new builtin role to be called:
http://www.w3.org/2002/06/soap-envelope/role/relay .  In most
respects, this role would be like any other.  Any intermediary or
ultimate receiver MAY choose to assume this role.  The one significant
difference, and it is one that we believe has to be baked into the
specification from day one (I.e. would be an incompatible change if
made later) is that section 2.7.1 will be changed as follows:

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

In addition, forwarding SOAP intermediaries MUST also
obey the specification for the SOAP forwarding feature
being used. The specification for such a feature MUST
describe the required semantics, including the rules
describing how the forwarded message is
constructed. Such rules MAY describe placement of
inserted or reinserted SOAP header blocks. Inserted
SOAP header blocks might be indistinguishable from one
or more of the header blocks removed above.
</original>

<proposed>
Forwarding SOAP intermediaries MUST process the message
according to the SOAP processing model defined in
2.6 Processing SOAP Messages. In addition, when
generating a SOAP message for the purpose of forwarding,
they MUST:

* For any processed SOAP header block, as well as for
  ignored SOAP header blocks targeted to the node
  using a role other than
  http://www.w3.org/2002/06/soap-envelope/role/relay:
  remove the header block prior to forwarding

* Retain all SOAP header blocks that were targeted at
  the forwarding node using the role
  "http://www.w3.org/2002/06/soap-envelope/role/relay"
  but ignored during processing.

In addition, forwarding SOAP intermediaries MUST also obey the
specification for the SOAP forwarding feature being used. The
specification for such a feature MUST describe the required semantics,
including the rules describing how the forwarded message is
constructed. Such rules MAY describe placement of inserted or
reinserted SOAP header blocks. Inserted SOAP header blocks might be
indistinguishable from one or more of the header blocks removed above.
</proposed>
[email] + See following thread. [New proposal]
Resolution:
The XMLP WG recognises this is an important issue. It has decided 
to introduce a new "relay" attribute. This attribute lets nodes 
explitely specify which header block should be forwarded. More 
precisely, it indicates which unprocessed header blocks, 
targetted at a node assumed by an intermediary, must be forwarded.

In your email, you outlined a similar solution 
("relayIfNotProcessed"), although you recommended adopting a 
simpler proposal ("relay" role) at this late stage of the 
recommandation process.

After carefull consideration and intense discussion, the WG 
decided to go for the more elaborate solution, for the following 
reasons:

1) The concepts of targetting and forwarding are separate and 
should remain so.

2) With your proposed solution, it would be impossible to target 
a header block at a user-defined role. A relayable block would 
have to always be targetted at the "relay" role, which defeats 
the whole purpose of the "role" attribute.

3) Both solutions would result in about the same amount of 
changes to the spec anyway.

Since your initial email, you have indicated during at least two 
different teleconferences that you would indeed prefer the more 
general solution; we thus trust that you will agree with the WG's 
resolution. Please let us know asap if you think otherwise.

The WG has also taken this opportunity to introduce a new table 
which clarifies and summarizes when and how nodes are allowed to 
forward messages.
    
[email]
395specn/ametaDesignClosedNoah Mendelsohn
Title: Check in HTTP binding that we are prohibiting DTDs.
Description:
Log potential issue: Check in HTTP binding that we prohibit DTDs.
See F2F minutes, irc log
Proposal:
Resolution:
  In response to XML Protocol Last Call issue 395, the WG has decided
  to adopt the resolution stated in [2]
[email]
418AF docn/ametaDesignClosedMartin Gudgin
Title: Comments on SOAP 1.2 Attachment Feature
Description:
1.      The att:SOAPMessage property should be described as being an XML
Infoset ( this is the abstract structure of a SOAP message )

2.      The att:SecondaryPartBag should be a sub-property of the
att:SOAPMessage, that is it, and the representations it contains,
should be contained entirely within the XML Infoset of the SOAP message.

In general, the notion of information being outside the SOAP envelope
seems to be problematic, given that the processing model[2] of SOAP is
defined in terms of an XML Infoset.
[email]
Proposal:
Resolution:
The WG has decided to deprecate the attachment feature document and will be
taking no action with respect to this issue.
[email]
468mtomn/aeditorialDesignClosedHugo Haas
Title: SOAP-specificity of the HTTP Transmission Optimization Feature name
Description:
While working on MTOM and XOP description, we realized that the name
"HTTP Transmission Optimization Feature" was confusing.

It is a SOAP feature, i.e. it cannot be used without sending SOAP
messages. Yet, its name is very general and doesn't reflect that.

It is particularly confusing when considering that one could define a
feature which would provide XOP optimization for arbitrary XML over
HTTP, which one would probably want to call Generic HTTP Transmission
Optimization Feature, or maybe even HTTP Transmission Optimization
Feature too.

We would appreciate to have this SOAP-specificity reflected in its
name.

As a matter of comparison, the SOAP Web Method Feature defined in the
Part 2 Recommendation, which arguably has a scope of application which
is broader than just SOAP, had a name which was pointing out
SOAP-specificity.
[email]
Proposal:
Resolution:
You raised an issue 468[1] on the MTOM specification[2]. The editors
have changed 'Abstract Transmission Optimization Feature' to 'Abstract
SOAP Transmission Optimization Feature' and 'HTTP Transmission
Optimization Feature' to 'HTTP SOAP Transmission Optimization Feature'. 
[email]
469XOPn/aeditorialDesignClosedMark Nottingham
Title: Examples in XOP LC Draft
Description:
The examples in the XOP Last Call Draft use the 'text/xml' media 
type for the XOP Document, and in the type parameter of the package's 
media type. Instead, a XOP-specific media type should be used.

Also, I don't find a direct RFC2119 requirement to use a XOP-specific 
media type in a XOP Package, which I don't think reflects the wishes of 
the Working Group. An appropriate place might be item 5 in section 3.1.
[email]
Proposal:
Resolution:
The editors have corrected the spec, chaning 'text/xml' to 
'application/soap+xml' in examples and adding 'XOP-specific' to 
Section 3.1 Bullet 5.
[email]
470XOPn/ametaDesignClosedGraham Klyne
Title: text/xml for root multipart/related element
Description:
Section 1.2:
text/xml for root multipart/related element

The choice of a text/... MIME type for this purpose seems rather, er, 
perverse to me.  The intent of text/... MIME types is for data content that 
can reasonably be read as such by a human user [1].  text/html is regarded 
by at least one of MIME's designers as a mistake [2].  I really don't think 
that an XML SOAP envelope falls into the category of human-readable 
text.  I suggest:
(a) use application/xml, or
(b) register a new application/...+xml MIME type for this purpose.

I see in section 5 you describe application/soap_xop+xml, so I guess that's 
just a typo in the examples?

Section 5:

Looking at:
[[
For example, if the format identified by "application/soap+xml" is to be 
packaged as XOP serializations, then a XOP-specific media type (e.g., 
"application/soap_xop+xml") MUST be registered. A XOP Package using the 
Multipart/Related packaging mechanism and serializing such an Infoset would 
have a package media type of "multipart/related" and a root media type of 
"application/soap_xop+xml".
]]

This seems a bit awkward to me.  Has any consideration been given to 
defining a single MIME content-type, say application/xop+xml, having a 
parameter to specify the original MIME type; hence:
     Content-type: 
application/xop+xml;original-content-type="application/soap+xml"

Among other things, I think this would make it easier to implement a 
completely generic XOP serializer/deserializer since no special knowledge 
of any specific MIME type (other than application/xop+xml) would be required.
[email]
Proposal:
Resolution:
The Working Group today resolved to take a modified approach, outlined  
below, whereby the type parameter contains a content-type instead of a  
media type (i.e., it can contain parameters). This allows such  
parameters to "show through" both the root part's type parameter as  
well as the package's start-info parameter. It does mean that some  
escaping may be necessary, but that was thought an acceptable cost in  
exchange for the simplicity of the approach.

* Section 1.2 Example
In Example 2, change:
[[[Content-Type: Multipart/Related;boundary=MIME_boundary;
                
type=application/soap_xop+xml;start="<mymessage.xml@example.org>"]]]
to:
[[[Content-Type: multipart/related;boundry=MIME_boundary;
		type="application/xop+xml";start="mymessage.xml@example.org>";
		startinfo="application/soap+xml;action=\"http://www.example.com/ 
myAction\""]]]

Change:
[[[Content-Type: application/soap_xop+xml; charset=UTF-8]]]
to:
[[[Content-type: application/xop+xml; charset=UTF-8;  
type="application/soap+xml;action=\"http://www.example.com/ 
myAction\""]]]

* Section 3.1 Creating XOP Packages
In bullet 5, change "appropriate XOP-specific media type" to  
"application/xop+xml media type"

* Section 4.1 MIME Multipart/Related XOP Packages
Replace the second paragraph with:
"""The root MIME part is the root of the XOP Package, and MUST be a  
serialisation of the XOP Infoset using any W3C Recommendation-level  
version of XML (e.g., [XML 1.0], [XML 1.1]), and MUST be identified  
with a media type of "application/xop+xml" (as defined below). The  
"start-info" parameter of the package's media type MUST contain the  
content type associated with the content's XML serialisation (i.e., it  
will contain the same value as that of the root part's "type"  
parameter)."""

* Section 5 Identifying XOP Packages
Replace the section with: """
XOP Documents, when used in MIME-like systems, are identified with the  
"application/xop+xml" media type, with the required "type" parameter  
conveying the original XML serialisation's associated content type.  
Note that when the type parameter contains reserved characters, it  
needs to be appropriately quoted and escaped.

For example, a XOP Package using MIME Multipart/Related packaging to  
serialise a SOAP 1.2 message [SOAP1.2] with an action parameter of  
"http://www.example.com/foo" would label the package itself with the  
"multipart/related" media type; the root part's media type is  
"application/xop+xml", with a "type" parameter containing  
"application/soap+xml;action=\"http://www.example.net/foo\"".


5.1 Registration
MIME media type name:
	application
MIME subtype name:
	xop+xml
Required parameters:
	* "type"
	This parameter conveys the content type associated with the XML  
serialisation of the XOP Infoset, including parameters as appropriate.
Optional parameters:
	* "charset"
	 This parameter has identical semantics to the charset parameter of  
the application/xml media type as  specified in RFC 3023 [RFC 3023].
Encoding Considerations:
	 Identical to those of application/xml as described in RFC 3023 [RFC  
3023], section 3.2.
Security Consideration:
	In addition to application-specific considerations, XOP has the same  
security considerations described in RFC 3023  [RFC 3023], section 10.
Interoperability Considerations:
	There are no known interoperability issues.
Published Specification:
	This document.
Applications which use this media type:
	No known applications currently use this media type.
Additional Information:
	File extension:
		XOP
	Fragment Identifiers:
		Identical to that of application/xml as described in RFC3023 [RFC3023]
	Base URI:
		As specified in RFC 3023 [RFC 3023], section 6.
	Macintosh File Type code:
		TEXT
Person and email address to contact for further information:
	Mark Nottingham <mnot@pobox.com>
Intended usage:
	COMMON
Author/Change controller:
	The XOP specification is a work product of the World Wide Web  
Consortium's XML Protocol Working Group. The W3C has change control  
over this specification.
"""
[email]
471XOPn/aeditorialDesignClosedGraham Klyne
Title: Typo in RFC 2557 Authors' name.
Description:
B.1 References:

The reference to RFC 2557 mis-spells one of the authors' name (J Palme).
[email]
Proposal:
Resolution:
You raised an issue 471[1] on the XOP specification[2]. This error has
been corrected in the latest editor's copy.
[email]
472XOPn/ametaDesignClosedJacek Kopecky
Title: term definition
Description:
1) Section 1.1 defines the term Optimized Content and does not define
the term Extracted Content; the rest of the spec uses the latter term in
multiple places, I think these terms should be consolidated or the
latter defined as different from the former.
[email]
Proposal:
Resolution:
You raised an issue 472[1] on the XOP specification[2]. The WG has
agreed to use the term Optimized Content rather than a mixture of
Extracted Content and Optimized Content.
[email]
473XOPn/ametaDesignClosedJacek Kopecky
Title: white space and base64
Description:
2) the example in section 1.2 contain white space around the base64
characters, and same below around the xop:Include element, should that
be removed? Or should it be pointed out somewhere that such space is in
fact insignificant per some spec? Section 3.1 specifies bullet 3 says no
space allowed preceding, inline or following the content...
[email]
Proposal:
Resolution:
The WG will clarify that elements to be optimized must only contain 
character information items. The WG will also amend the example to fix
the whitespace problems by removing whitespace around the 
<xop:Include> element and the base64 characters.
[email]
474XOPn/ametaDesignClosedJacek Kopecky
Title: XOP Infoset / Package
Description:
3) Section 3.1, last sentence, should XOP Infoset be changed to XOP
Package here? Content is not encoded into the XOP Infoset after all,
it's extracted from it. 8-)
[email]
Proposal:
Resolution:
You raised an issue regarding XOP. The WG agree with your
suggestion that XML Infoset should read XML Package in the last sentence
of Section 3.1 and will make this change.
[email]
475XOPn/ametaDesignClosedJacek Kopecky
Title: packaging and root part
Description:
4) Section 4 says any packaging mechanism can be used, but the spec
refers to the "root part" in multiple places - should it be said that
any packaging mechanism has the notion of a root part?
[email]
Proposal:
Resolution:
You raised an issue[1] regarding XOP[2]. The WG agrees with your
concern regarding XOP consistency when describing XOP packaging 
requirements and the notion of a root part. The working group will 
change the text in Section 4, paragraph 1 to read:

"Such packaging mechanisms MUST be able to represent, with full fidelity 
all the parts created according to 3 XOP's Processing Model (see 3.1 
Creating XOP Packages), and MUST be used in a manner that provides a 
means of designating a distinguished root part."
[---]
From Jacek Kopecky
I'd suggest a small friendly amendment here:

Such packaging mechanisms MUST be able to represent, with full fidelity 
all the parts created according to 3 XOP's Processing Model (see 3.1 
Creating XOP Packages), and MUST be used in a manner that provides a 
means of designating a distinguished root (main, primary etc.) part.

Just added the parenthesized part of the last line to explain better
that it need not be called "root" part, but XOP calls it that. 8-)
[---]
From Michael Mahan (on behalf of XMLP WG)
The WG has agreed to accept your friendly amendment.
[email, email, email]
476XOPn/ametaEditorialClosedJacek Kopecky
Title: Editorial LC comments on XOP
Description:
1) just before 1.1, decapitalize the section numbers in the overview -
instead of Section Four say Section four.

2) in 1.1, drop second reference to XML InfoSet

3) xop:Includeelement add space, in multiple places in the spec, same
with hrefattribute in multiple places and other similar spacing problems
- suggest searching for the pair >< in the XML or for a letter and <
with no space in between, I guess.
 
4) Section 1.2, [media type] link should be filled in

5) Section 1.3 add spacing and/or padding to table to make it more
readable

6) Section 2 heading: XOP Infosets Constructs - drop first plural - XOP
Infoset Constructs

7) Sections 2.1, 2.2, xop:Include element MUST have the name of Include?
Oh, please! 8-) I suggest taking the approach from Representation header
spec.

8) Section 2.1 third bullet: ... It MUST NOT change the semantics...
"it" is ambiguous, I suggest using "the element"

9) Section 2.1 fourth bullet: hrefattribute information items - space
missing, drop 's' at the end (plural items)

10) consolidate spacing in references rfcxxxx and rfc xxxx (with/out
space)

11) also, I believe some references are not properly pointing to their
destinations (rfc reference in 2.2, third bullet), may be related to the
problem above

12) Section 2.2 fourth bullet: its owner must be a xop:include element.
period.

13) Section 3 heading: XOP's processing model - drop possessive -> 
"XOP processing model"

14) Section 3.2 ... has as its [children] a xop:Include... - mismatch of
plural [children] and singular element, suggest a bit more verbose
version that says that is the only child.

15) Section 3.2: ... replace its [children] with a char info items ... -
drop indefinite article 'a'

16) Section 4.1 says the media type of the root part must be specific to
XOP encoding of the actual data, 5 mentions application/soap_xop+xml,
the example in 1.2 uses text/xml though, should use
application/soap_xop+xml

17) Section 6.1 contains unbalanced parenthesis
[email]
Proposal:
Resolution:
You raised an issue 476 on the XOP specification. The editors have
made the following changes(reflected in latest editors copy)

> 1) just before 1.1, decapitalize the section numbers in the overview -
> instead of Section Four say Section four.

Changed to use Section 4 rather than Section Four ( see[3] )

> 2) in 1.1, drop second reference to XML InfoSet

Done.

> 3) xop:Includeelement add space, in multiple places in the spec, same
> with hrefattribute in multiple places and other similar spacing
problems
> - suggest searching for the pair >< in the XML or for a letter and 
<> with no space in between, I guess.

Done.
 
> 4) Section 1.2, [media type] link should be filled in

Done. 

> 5) Section 1.3 add spacing and/or padding to table to make it more
> readable

Done. Made the table 3 columns wide.

> 6) Section 2 heading: XOP Infosets Constructs - drop first plural - XOP
> Infoset Constructs

Done

> 7) Sections 2.1, 2.2, xop:Include element MUST have the name of Include?
> Oh, please! 8-) I suggest taking the approach from Representation header
> spec.

Done.

> 8) Section 2.1 third bullet: ... It MUST NOT change the semantics...
> "it" is ambiguous, I suggest using "the element"

Fixed. 

> 9) Section 2.1 fourth bullet: hrefattribute information items - space
> missing, drop 's' at the end (plural items)

Fixed.

> 10) consolidate spacing in references rfcxxxx and rfc xxxx (with/out
> space)

Done. ( They now always have a space )

> 11) also, I believe some references are not properly pointing to their
> destinations (rfc reference in 2.2, third bullet), may be related to the
> problem above

Fixed.

> 12) Section 2.2 fourth bullet: its owner must be a xop:include element.
> period.

Done.

> 13) Section 3 heading: XOP's processing model - drop possessive ->
> "XOP processing model"

Fixed.

> 14) Section 3.2 ... has as its [children] a xop:Include... - mismatch of
> plural [children] and singular element, suggest a bit more verbose
> version that says that is the only child.

Language amended.

> 15) Section 3.2: ... replace its [children] with a char info items ...
-
> drop indefinite article 'a'

Langage amended.

> 16) Section 4.1 says the media type of the root part must be specific to
> XOP encoding of the actual data, 5 mentions application/soap_xop+xml,
> the example in 1.2 uses text/xml though, should use
> application/soap_xop+xml

Fixed.

> 17) Section 6.1 contains unbalanced parenthesis

Fixed.
[email]
477MTOMn/ametaDesignClosedJacek Kopecky
Title: Canonical / non-canonical
Description:
Section 2.3.2 says receivers must not convert non-canonical
representations to canonical, but do they actually have the opportunity?
I think this text should be dropped as I don't think it's a good example
for the rule before it.
[email]
Proposal:
Resolution:
The WG agree with your suggestion that the last sentence 
of paragraph 2 of Section 2.3.2 should be removed and
 will make this change.
[email]
478MTOMn/ametaEditorialClosedJacek Kopecky
Title: Editorial LC comments on MTOM
Description:
1) just before section 2.3.2 add text ...MUST not be optimized >>by
implementations of this feature<<

2) 2.3.2 should say "should generate a fault" instead of "should fault"

3) 4.3.1.1 content-tranfer-encoding - missing 's' in transfer

4) 4.3.2 2nd paragraph says "The remaining of this section describes the
perturbations", first it should be the "remainder", second there seem to
be such formal perturbations, like the ones described in the table in
4.3.1.1
[email]
Proposal:
Resolution:
You raised an issue 478[1] on the MTOM specification[2]. The editors
have made the following changes(reflected in latest editors copy[3])

> 1) just before section 2.3.2 add text ...MUST not be optimized >>by
> implementations of this feature<<

Done.

> 2) 2.3.2 should say "should generate a fault" instead of "should fault"

Done. 

> 3) 4.3.1.1 content-tranfer-encoding - missing 's' in transfer

Done.

> 4) 4.3.2 2nd paragraph says "The remaining of this section describes the
> perturbations", first it should be the "remainder", second there seem to
> be such formal perturbations, like the ones described in the table in
> 4.3.1.1

The latter half of Section 4.3.2 has been amended to address this
problem.
[email]
479Representationn/ametaDesignClosedJacek Kopecky
Title: LC comments on Resource Representation header
Description:
1) section 1.2 needs to be filled

2) Section 2.1 talks about extracted content but makes no reference to
XOP or MTOM, a reader new to these specs and starting with
Representation header would have no idea what is being talked about. 

3) Representation header is not a SOAP module, I think it would be
beneficial for describing the messages (say in WSDL) if it had a formal
name.

4) in section 2.2, should it be said that namespace-qualified elements
and attributes on Rep elements must not be in Rep namespace?

5) section 2.3 should probably be marked informative

6) section 2.3.3, the example should probably be inside
rep:Representation element
[email]
Proposal:
Resolution:
> 1) section 1.2 needs to be filled

It has been filled, see the editors' copy

> 2) Section 2.1 talks about extracted content but makes no reference to
> XOP or MTOM, a reader new to these specs and starting with
> Representation header would have no idea what is being talked about.

Fixed, "extracted content" has been replaced by "resource"

> 3) Representation header is not a SOAP module, I think it would be
> beneficial for describing the messages (say in WSDL) if it had a formal
> name.

Fixed, the document now defines a SOAP Feature and a SOAP Module. The name 
of the specification has been changed to reflect that, it is now "Resource 
Representation SOAP Header Block"

> 4) in section 2.2, should it be said that namespace-qualified elements
> and attributes on Rep elements must not be in Rep namespace?

The schema has been changed to reflect that, see [3]

> 5) section 2.3 should probably be marked informative

Done (by mean of stating that it is an example)

> 6) section 2.3.3, the example should probably be inside
> rep:Representation element

Done.
[email]
480Representationn/ametaDesignClosedJacek Kopecky
Title: Editorial LC comments on Resource Representation header
Description:
1) Section 2.1, Representation header is not required, but may be
useful, when multiple references...

2) Section 2.1 should the space around base64 characters in the example
be dropped?

3) Section 2.3.2: does reinsert have the [specified] prop w/value
"true"? I believe not.

4) 2.3.2 Example Example - the link to the example should probably be
titled otherwise 8-)
[email]
Proposal:
Resolution:
You raised an issue (#480) [1] regarding the Representation header [2] 
LC doc. The WG agreed to classify the issue as editorial and directed 
the editors to address your comment.

Details:

 >1) Section 2.1, Representation header is not required, but may be
 >useful, when multiple references...

The sentence in question in section 2.1 has been changed to read:
  "The Representation header block is also useful when multiple 
references to the same resource are required but duplication of the 
resource is undesirable."

 >2) Section 2.1 should the space around base64 characters in the example
 >be dropped?

The space around the base64 characters has been removed.

 >3) Section 2.3.2: does reinsert have the [specified] prop w/value
 >"true"? I believe not.

Section 2.2.3 (and not 2.3.2) is _not_ changed. The [specified] property 
value is indeed 'true'. This requires the attribute to be specified and 
not defaulted.

 >4) 2.3.2 Example Example - the link to the example should probably be
 >titled otherwise 8-)

The sentence is question is now changed to:
"An example of this usage is shown in Example 1."
[email][email]
481XOPn/ametaDesignClosedAlex Danilo
Title: MIME boundaries not checked during XOP serialisation
Description:
The creation of a XOP package as described in section 3.1 and
illustrated in the example 1.2 converts original base64 encoded
data into raw binary octets.

It is entirely likely that a large enough sample of binary data
will result in content that encodes the same sequence of octets
that mark a MIME boundary for the output package.

Such aliasing of MIME boundary octets will result in a broken
XOP package that cannot be decoded back into the original XML
infoset.

Proposed solutions:
1) Scan and detect serialised binary data for the chosen MIME
   boundary separator and define an escaping mechanism to
   recode the binary data.
2) Scan and detect serialised binary data for the chosen MIME
   boundary separator and on detection choose a different
   MIME boundary string and rescan all binary attachments
   iteratively until no aliasing is detected.
3) Mandate use of the 'Content-Length:' header field in the
   binary part of the XOP package.

[email]
Proposal:
Resolution:
The XML Protocol has decided to close issue 481[1] with no action, 
because the issues you raise are well-understood and documented 
consequences of using MIME multipart packaging. Such discussion is more 
appropriate in a primer or other documentation.
[email]
482XOPn/ametaDesignClosedJun Fujisawa
Title: Reference to Base64 specification
Description:
Section 1, the specification of base64 encoding in XOP is described in terms
of base64Binary of XML Schema Part 2, and the definition of base64Binary data
type refers to RFC 2045.

Since more formal description of base64 has recently been provided as RFC
3548, I propose to use RFC 3548 as the primary reference specification of
base64 encoding in XOP.
[email]
Proposal:
Resolution:
The XMLP working group declined to adopt your suggestion as XOP
requires a canonical form of base64 and RFC3548 does not define such
a form. The XML Schema Part 2 specification does define such a form
which is why we reference that specification rather than RFC3548.
[email]
483XOPn/ametaDesignClosedJun Fujisawa
Title: XOP: Why element content only?
Description:
Section 1, it is stated that "As a result, only element content can be
optimized". However, the reason why the attribute value cannot be optimized is
not clear from the context.
[email]
Proposal:
Resolution:
You raised an issue, number 483[1] regarding langauge in section 1 of
the XOP specification[2]. The working group agrees that it is not clear
from the context why attribute content cannot be optimized. The reason,
that an element is used to indicate where content has been optimized, is
present in Paragraph 2 of Section 1, but the language you refer to is in
Paragraph 5. The two intervening paragraphs make the context unclear.
The Working Group will remove the text 'As a result,' from Section 5 so
that it reads:

"Only element content can be optimized; attributes,
non-base64-compatible character data, and data not in the canonical
representation of the base64Binary datatype cannot be successfully
optimized by XOP."
[email]
484XOPn/ametaEditorialClosedJun Fujisawa
Title: XOP: Identification of each example
Description:
Section 1.2, assigning an identification number to each example (e.g.
Example 1, Example 2...) will greatly help the reader of the printed
specification to locate the right example from the description like "Example
shows..".
[email]
Proposal:
Resolution:
You raised an issue, number 484[1], regarding numbering of examples in the XOP
specification[1]. The editors have numbered the examples 1, 2 and 3 and
used these numbers when refering to the examples.
[email]
485XOPn/ametaEditorialClosedJun Fujisawa
Title: Avoid using SOAP in examples
Description:
Examples in Section 1.2, I propose to use an XML vocabulary other than SOAP
(such as SVG or XHTML) in order to show that XOP does not depend on SOAP
(common misunderstanding).
[email]
Proposal:
Resolution:
You raised an issue[1] regarding examples in the XOP specification[2].
The latest editor's copy contains an example that uses text/xml. I
trust this addresses your concern.
[email]
486XOPn/ametaDesignClosedJun Fujisawa
Title: XOP namespace declaration in Original Infoset
Description:
In the first example, a namespace declaration for XOP is provided on the root
soap:Envelop element. I don't think this is good because Original Infoset
should not know anything about XOP (xop:Include element never occurs in
Original Infoset).

Also, "xmlmime:content-type" should be replaced by "xmlmime:contentType".
[email]
Proposal:
Resolution:
You raised an issue, number 486[1] regarding presence of the XOP
namespace declaration on the root element in an example in the XOP
specification[1]. The Working Group agrees that the example is unclear
and will amend the example so that the namespace declaration appears on
the Include element. The working group does note however, that it is
possible for an original infoset to contain a namespace declaration for
the XOP namespace, provided it does NOT contain any Include elements.
[email][email]
487XOPn/ametaDesignClosedJun Fujisawa
Title: Clarification on format change
Description:
Section A.3, it is stated that "Change to the format MUST be identified by a
new namaspace URI (i.e., they MUST define a new Include element information
item in another namespace)." On the other hand, an extension to xop:Include
element to add a namespace qualified child element or attribute is allowed
according to Section 2.1. It is not clear such an extension is considered to
be a "format change" mentioned in Section A.3 or not.
[email]
Proposal:
Resolution:
You raised an issue, number 487[1] regarding language in Section A.3 of
the XOP specification[1]. The Working Group decided that use of the word
'format' in the second sentence was incorrect and that the word
'semantics' should be used instead as in the first sentence. The text
will be amended to read:

"XOP Documents allow extensions to the xop:Include element when they do
not change its semantics. Changes to the semantics MUST be identified by
a new namespace URI (i.e., they MUST define a new Include element
information item in another namespace)."
[email]
488Representationn/ametaDesignClosedJacek Kopecky
Title: WS-Description WG's LC comment
Description:
the WS-Description WG has reviewed the Last Call drafts of XOP, MTOM and
Resource Representation Header specs and has two comments.

1) the Resource Representation header [1] is not a SOAP module and
therefore does not have a formal name by which it can be referred (other
than the element qname). We feel that making the header into a full
module with its identification URI will help us describe applications
that use it.
[email]
Proposal:
Resolution:
The XMLP WG had decided to close issue 488 
by adding a new section for the description of a SOAP module as proposed 
in [3].
email
489MTOMn/ametaDesignClosedJacek Kopecky
Title: WS-Description WG's LC comment
Description:
the WS-Description WG has reviewed the Last Call drafts of XOP, MTOM and
Resource Representation Header specs and has two comments.

2) we have discussed the ednote in section 4.3.1 in MTOM [2] on bindings
that will reject some infosets and even though it doesn't affect our
ability to describe SOAP services using MTOM, there was significant
sentiment that an escaping mechanism for XOP elements be added in XOP or
MTOM. 

It was noted that such escaping mechanism would only be used by nodes
that cannot otherwise guarantee that xop:Include isn't present in their
SOAP infosets; and such nodes, in order to be conformant, would have to
scan the infosets for the presence of xop:Include elements before using
MTOM. We don't think that performing the escaping would be a significant
(show-stopping) addition to the overhead of the scan.
[email]
Proposal:
Resolution:
The WG has decided to take no further action with respect to this comment.
[email]
490MTOMn/ametaDesignClosedJonathan Marsh
Title: Describing which blobs are to be optimized
Description:
Last week we approved this resolution of our Issue 207, which was to ask
you to add a reference to the Media Type Description note and
specifically mention that the expectedMediaType annotation could provide
a source of information for determining which blobs are to be optimized.
The specific text proposal below, and its position in the MTOM spec, are
of course examples useful in reaching consensus on the issue within our
group and you may find a better way to indicate this information in your
spec.
[..]
> Ask the XMLP WG to augment the paragraph in MTOM
> [http://www.w3.org/TR/soap12-mtom/#aof-sending] as indicated {{thus}}:
>
> "Note: the means of identifying element information items that contain
> base64 encoded data in canonical lexical form are
> implementation-dependent. Some implementations can identify such element
> information items by construction (e.g., because a certain API may
> create only canonical forms); others may check the characters prior to
> sending{{, others may rely on information in the description such as the
> presence and/or value of the xmlmime:expectedMediaType schema annotation
> [reference to XMLMIME]}}.  Because of the need to exactly preserve the
> characters in the transmitted Infoset, non-canonical representations
> MUST NOT be optimized."
[email]
Proposal:
Resolution:
The WG has added the text you requested, appending the 
additional phrase 'if a schema is available'.
[email]
491MTOMn/ametaDesignClosedMartin Gudgin
Title: ContentID in MTOM
Description:
I was under the impression that in resolving issue
451 that we were mandating the use of the cid: URI scheme ( and the
corresponding ContentID MIME header ) when referencing MIME parts from
xop:Include/@href. However, I can find no mention of this in XOP or
MTOM. XOP in fact allows both Content-ID and Content-Location to be
used ( see[4] ), but I thought at the MTOM level we were restricting to
Content-ID only.

I note that in private mail, several other members have the same
recollection as me.
[email]
Proposal:
Resolution:
the XMLP WG agreed to resolve it by mandating the use of the
"cid:"  URI scheme in MTOM.
[email]
492MTOM,XOP,Representationn/ametaEditorialClosedSusan Lesch
Title: Bibliography
Description:
A comment for your three Last Calls ending 29 June: SOAP Message 
Transmission Optimization Mechanism [1], SOAP Resource Representation 
Header [2] and XML-binary Optimized Packaging [3].

On the whole the drafts look nice but for some reason the References 
sections have no links. The W3C Bibliography Extractor writes 
references in W3C style very quickly from a list of URIs.
[email]
Proposal:
Resolution:
You raised an issue[0] regarding links in the bibliography sections for
XOP[1], MTOM[2] and Representation header[3] specs. This problem has
been addressed in the latest editor's copies of these documents[4,5,6]
[email]
493XOPn/ametaEditorialClosedJun Fujisawa
Title: On the use of "binary" transfer encoding
Description:
In the second example in Section 1.2, "Content-Transfer-Encoding: binary"
is specified. It should be mentioned that the value of "binary" cannot be used
for many protocols including SMTP which assume 7 bits transfer.
[email]
Proposal:
Resolution:
The XML Protocol Working Group has closed issue 493 with no action, 
because the semantics and proper use of Content-Transfer-Encoding are 
felt to be well-understood and documented by the MIME specifications.
[email]
494XOPn/ametaDesignClosedJun Fujisawa
Title: XOP Schema should be normative
Description:
Section 1.3, the XML Schema definition of "xop" namespace is marked as
non-normative. I think "xop" schema should be normative considering the fact
that "rep" schema is also normative.
[email]
Proposal:
Resolution:
The XMLP WG rationale to differentiate the normative nature of these namespaces 
stems from the introduction of XML 1.1 and its impact upon XMLP specifications (See 
Rec Issue 20 [4]). Since the Representation Header specification and the rep 
namespace is SOAP specific, only XML 1.0 applies and hence the we define this rep 
namespace as normative. However, XOP is NOT SOAP specific and thus needs to allow for 
either XML 1.0 or 1.1. Thus we have defined the xop namespace as non-normative.
[email][email]
495XOPn/ametaDesignClosedJun Fujisawa
Title: Suggestion on XOP media type
Description:
Section 5, the need for XOP-specific media type (e.g.
application/soap_xop+xml) is described. I don't think such an approach is
feasible since registering a new media type is a very expensive process. I
suggest to use "start-info" parameter of "multipart/related" type instead to
indicate that the content is encoded in XOP:

Content-Type: multipart/related;type=application/soap+xml;
               start="<mymessage.xml@example.org>";
               start-info="http://www.w3.org/2003/12/xop/include"
[email]
Proposal:
Resolution:
The XMLP WG has considered issue 495 which you raised [1]. Your suggestion
to use the start-info parameter has already been made in the context of the
WG's resolution to issue 470 [2], and the WG is considering this
suggestion.

Issue 495 duplicates issue 470, and so it will be closed.
[email]
496MTOMn/ametaEditorialClosedJun Fujisawa
Title: Updated reference to requirements
Description:
Section 1.2, the reference to "SOAP Attachment Requirements" should be
updated to point to "SOAP Optimization Serialization Use Cases and
Requirements".
[email]
Proposal:
Resolution:
You raised an issue, number 496[1] regarding an incorrect reference in
the MTOM specification[1]. The editors have corrected the reference to cite the
"SOAP Optimized Serialization Use Cases and Requirements" as you suggested.
[email]
497MTOMn/ametaEditorialClosedJun Fujisawa
Title: "mime/multipart-related" media type
Description:
Section 4.3.1, the value of "Content-Type" field in the table should be
"multipart/related", not "mime/multipart-related".
[email]
Proposal:
Resolution:
The editors have corrected the error, changing 'mime/multipart-related' 
to 'multipart/related' as you suggested.
[email]
498MTOMn/ametaEditorialClosedJun Fujisawa
Title: "Content-Transfer-Encoding" header in HTTP/1.1
Description:
Section 4.3.1, it is stated that "Each MIME part that is refered to by
xop:Include MUST have a Content-Transfer-Encoding header field". On the other
hand, HTTP/1.1 itself does not normally use Content-Transfer-Encoding header
field altogether (19.4.5 No Content-Transfer-Encoding). I think more
explanation is needed to justify this restriction.
[email]
Proposal:
Resolution:
Closed with no action
[email][email]
499Representationn/ametaEditorialClosedJun Fujisawa
Title: The content of rep:Data element
Description:
Section 2.2.4, the value of a rep:Data element is described as just
"a base64 encoded representation" of a Web resource. I think this
should be "a base64 encoded representation in the canonical lexical
form".
[email]
Proposal:
Resolution:
During its July 14 meeting, the XMLP WG decided that it was
unnecessary to say that the lexical form must be the canonical form,
because this header is independent of MTOM.  So this will not result
in any change to the Representation Header specification.
[email]

Table Legend

id
Issue number
Title
Short title/name of the issue
Spec
Document referred to in issue (AM = Abstract Model, Spec = XMLP/SOAP Specification
Description
Short description of issue, possibly including link to origin of issue
Req
Link to XML Protocol Requirement that motivated this issue
Topic
Rough topic categorisation, one of: env(elope), rpc, enc(oding), meta(issue), bind(ing), fault
Class
Design or Editorial
Status
One of: Unassigned, Active, Closed, Postponed
Proposal
Current proposal for resolution of issue, possibly including link to further text
Resolution
Short description of resolution, possibly including link to a more elaborate description
Raised by
Person who raised the issue
Owner
XML Protocol WG Member responsible for the issue

Maintained by Carine Bournez.
Maintained by Yves Lafon.