This spec needs more explicit statement of some use cases, and this is 
causing some confusion expressed in various weblogs and on the TAG 
mailing list.  For example, some are calling it "tunneling HTTP over 
SOAP over HTTP".  There would be no need for a Representation Header in 
an open HTTP environment where the recipient could dereference any 
links in a SOAP message, but this (perhaps overwhelmingly obvious) 
point is not made anywhere in the spec.

Some use cases that come to mind (based on my hazy recollection of 
discussions when I was on the XMLP WG) would be:

- A SOAP message that references Web resources needed to process it is 
received by an HTTP gateway and then passed over a proprietary 
messaging system (e.g. MQ) to a system that is not on the Web.

-- A SOAP message that references Web resources needed to process it  
is received by the DMZ outside a high-security environment.  All 
arbitrary Web links must be dereferenced and vetted outsize the 
high-security environment and passed inside for processing.

- - A SOAP message that references Web resources needed to process it 
is received by a performance-critical system; tasks that can be easily 
parallelized (such as HTTP GETs on the links) are done simultaneously, 
and the results combined and passed downstream to a process that must 
consider them all.

Do these make sense, or am I also missing the point here?

W3C Working Draft 09 February 2004

Section 4.3.1 Sending a SOAP message

The XOP package is constructed as described in 3. An Optimized MIME Multipart 
Serialization of SOAP Messages with the following restriction:

*      Each optimized Node MUST generate exactly one extracted binary part in
the resulting package, i.e., extracted binary parts MUST NOT be referenced 
with more than one xop:Include in the SOAP message part.

If transmission optimization is the goal of this effort, why do you
specifically disallow reuse of a binary package that has been isolated in
the document?  I realize this may make some processing models more complex but
the potential benefit is very significant.  Messaging in military systems 
tends to have repeated information (the exact value of which is not 
predictable in advance but which reoccurs daily in many messages of all types).
When a value (such as GPS, time, call-sign, unit-id) is used it is often 
repeated.  While XML design considerations might allow reuse of the 
information via ID and IDREF, the influence of legacy systems (an environment 
that would not accommodate such referential complexity very well) continues 
to make such an alternative infeasible.

Independent of my operational concerns for the Army, it does seem that you 
would want to recognize that an optimization of the message transmission 
should allow the potential for re-use of a defined binary representation when 
an opportunistic optimizer "discovers" it.

In the fifth paragraph of the XOP working draft (http://www.w3.org/TR/2004/WD-xop10-20040209/) I think you have a minor typo:

XOP is designed to carry sufficient information to reconstruct with full 
fidelity the supplied Data Model, including the return value of the 
dm:string-value accessor for each Node in the Data Model, except that the 
type property and the return value of the dm:typed-value accessor are 
generally not preserved. The type of base64Binary Element Bodes that were 
optimized is in fact conveyed, but the type of other Element Nodes as well as 
the type of Attribute Nodes is in general not preserved.

In the last sentence I think that the "Bodes" reference could either have 
been a mistyped "Bodies" or "Nodes".  But it leads me to a perfect word for 
some research I have been involved in with XML message types in the DOD.  
As I use it, "Bode" is a binary node hung in an XML tree that represents a 
reference to a payload digest element.  I think that you will want to modify 
the online document but your word is perfect for covering a concept I had 
come up with for dynamic message compression.  I guess this is a case of 
"thanks for the error!"

During last teleconference, I took an action to open issues
regarding requirements R9 and R7, to ensure that they are actually 
met by the MTOM/XOP specifications.

--
R9 
The specification must describe its points of extensibility.

See Use Cases and Requirements and M.Mahan's email.

During last teleconference, I took an action to open issues
regarding requirements R9 and R7, to ensure that they are actually 
met by the MTOM/XOP specifications.

--
R7 
The URI identification scheme must be robust under the addition and deletion of 
parts -- i.e., it must not require that URIs to other parts be altered, it must 
be relatively easy to avoid URI conflicts, etc.


See Use Cases and Requirements and M.Mahan's email.

Just out of curiosity: what happens with whitespace in base64Binary 
data? as i understand it, canonical base64Binary data may not contain 
any whitespace. is this intentional, because i think that many 
base64Binary does contain the linefeed characters required by rfc 2045. 
whitespace certainly would disappear in xop, and as i understand it, it 
cannot be reconstructed in the reconstituted dm. not that i think this 
would be a requirement, but i think this whole issue of whitespace in 
base64Binary data should be mentioned in the document.

When designing xml schemas, i usually avoid using xml schema built-in 
types and create a layer of my own simple types, which then are used in 
instances. i do this to be able to restrict all simple types, for 
example with length facets. wouldn't it be desirable to be able to 
optimize base64Binary and restricted subtypes, rather than base64Binary 
only? as i currently understand xop, my xml instances would not be 
optimized at all, because they use types derived from base64Binary. or 
would this be a requirement for my own type augmentation software, to 
generate the appropriate type information so that xop optimization works 
for base64Binary and derived subtypes?

In section 4.1 (creating xop packages) shouldn't it be left to an 
implementation to decide whether creating a part is worth the effort? as 
i understand them, the current rules specify that every base64Binary 
node must be optimized, which can increase rather than decrease message 
size for small binary parts.

During last teleconference, I took an action to open issues
regarding requirements R9 and R7, to ensure that they are actually 
met by the MTOM/XOP specifications.

--
R9 
The specification must describe its points of extensibility.

--
R7 
The URI identification scheme must be robust under the addition and deletion of 
parts -- i.e., it must not require that URIs to other parts be altered, it must 
be relatively easy to avoid URI conflicts, etc.


See Use Cases and Requirements and M.Mahan's email.

Now that XML 1.1 is a recommendation, and allows characters not allowed in
XML 1.0, it seems to me we need a review of our entire recommendation, as
well as XOP and MTOM drafts, to make sure we are clear on issues such as:

   Are the new control characters allowed by XML 1.1 allowed in XML SOAP 
   Envelope infosets?  If so, do you indicate this in the version of the 
   Infoset Document Information item?  
   If allowed, I don't see how the HTTP binding would send them using the 
   usual RFC 3203-based serialization, which my quick reading shows as XML 
   1.0.  
   We refer in the rec to XML 1.0 whitespace, but XML 1.1 allows NEL (x85) 
   as whitespace.  Are we at least clear as to what is whitespace and what 
   isn't for SOAP?  
   Is it legal to write a new binding or media type that sends the new 
   control chars, perhaps using XML 1.1 serialization?  This would seem to 
   break the equivalence among bindings.  
   We should similarly make sure XOP and MTOM are clear on these issues.

The current resolution of issue 442 [1] allows extensions to provide
protocol-dependent metainformation and context, but nothing is defined.
An extension for HTTP (the most common case) or a subset of MIME-based
protocol.
One use case is an automatic update of a mesh of HTTP caches where a
notification can carry a HTTP entity body and all meta-information (and
context) needed for a HTTP cache.

- Context
Currently, section 3.1 [2] of MTOM [1] states:
<current>
For use with this serialization, the type property MUST be set to 
xs:base64Binary only for those Element Nodes known to be in the 
canonical lexical form for that type. The type property for all other 
Element Nodes MUST be set to xdt:untypedAny.
</current>

- Problem 1
In the last sentence, "all other" refers to Element Nodes whose content 
is not base64-encoded data in canonical lexical form.

I think that the current constraint on those Element Nodes is too 
strong: the only thing we need to ensure is that for those "other" 
Element Nodes, their type property is not set to xs:base64Binary.

A use case where the current constraint is inconvenient is when a user 
wishes to send a full fledged Data Model with precise type information 
on all the Element Nodes (for example a Data Model resulting from a 
query in a database). In such a case, with the current formulation, the 
user would have to remove all type information from his Data Model 
(expect for xs:base64Binary typed Element Nodes) before sending it with 
an optimized SOAP binding.

- Problem 2
Moreover I think that the first sentence may be somewhat unclear about 
our real intent. I think we want to allow for Element Nodes with 
base64-encoded content in canonical lexical form NOT to be tagged with 
an xs:base64Binary type. In such a case, the Element Node will not be 
optimized.

- Proposal
Therefore I propose to remove those two sentences as I think that 
sufficient constraints are described in 2.3.1 which is refered to just 
before those sentences.

This relates in part
to issue 442 and to the proposed resolution [2].

The proposed resolution must be augmented, IMO, to describe its use of the
SOAP processing model.   I believe this will result in our specfying some
rules for when a conforming implementation may use the representation
header to resolve a retrieval request for a resource.

Consider and example of an original sender, final destination and two
intermediaries:

S -> A -> B-> D

If a representation header is addressed to the final destinatino D (default
SOAP role), should a retreival request at A use it?  I would think not, as
that would be circumventing the usual mustUnderstand mechanisms of SOAP.

If I want to specifically cause two different representations, of the same
media type for the same resource, to be sent to A and B respectively, can I
safely use multiple representation headers that differ in their soap:roles
to do this?  I would think so.

In any case, I believe we must decide on and document the rules we want.
The current proposal refers a bit to mustUnderstand, but doesn't really
cover the rules in detail.  I propose that we open a new issue to track
this question. 

I had always assumed that in Miffy, all the parts except the root would be
octet streams, probably labeled as application/octet-stream and sent in
8-bit format.  Anish mentioned on the call today his assumption that a
range of representations would be allowed on the wire, providing that
content-transfer-encoding would be correctly set to indicate the
representation used.

The tradeoffs appear to be:  a) variability is more flexible b) variability
requires that all receivers/interpreters be capable of decoding all
encodings if universal interop is to be achieved c) neither of us was sure
whether the decision to fix the representation might be taken as a misuse
of MIME.

4) Consideration of packaging multipart payloads via use of the
   'multipart/multiplexed' mechanism in RFC 3391 should be considered
      as a valid MIFFY encoding mechanism.

In some use cases, it is desirable to interleave the base XML
document data with its referenced content.

A mechanism for doing so is described in RFC 3391.  It is our
opinion that the mechanism described in RFC 3391 be a valid encoding
mechanism for MIFFY encoded documents.  It presents little overhead
for decoders and has the desirable benefit of facilitating streamed
content with multiple referenced parts.

3) Addressing the 'data:' URI directly in the MIFFY specification
   is desirable.

As currently defined, MIFFY may only optimise base64 data found as 
element content. In order to accommodate common practice in a number of
vocabularies, notably SVG where it is a frequent occurrence, we believe
that there would be great value in supporting data: URIs (RFC 2397) in 
MIFFY, through the addition of appropriate markup to your vocabulary.

This would effectively allow us to use MIFFY directly, without
requiring  any backwards-incompatible change to SVG. We understand
that XMLP may wish to without this feature in the SOAP context, but
it appears to us that MTOM could profile MIFFY to eliminate it if
you are so inclined.

2) The referencing mechanism via 'Content-Type' and 'http' URI
   presents an ambiguous referencing mechanism and may require removal.

The process of encoding a SOAP packet into an aggregated MIME
multipart specifies two alternate encodings for referenced content.
One uses the well-known 'cid:' URI which references the MIME sub-part
by use of 'Content-Id' in the sub-part.

An alternate referencing mechanism by use of an 'http:' URI and
specification in the MIME sub-part by use of the 'Content-Location'
field.

This latter mechanism seems to present a potential ambiguity in
its semantics.

Firstly, if the process is a recoding mechanism, it is entirely
unclear why two alternate schemes are needed.  The 'cid:' referencing
mechanism is well known and functional.  An encoder can unambiguously
encode content via this mechanism.

The second mechanism via the use of 'http:' seems to be semantically
incorrect.  The specification of an 'http:' address in the XML content
in the root part of the MIME package implies that an 'http:' request
should be made to retrieve the referenced content.  This is clearly
not the desired behaviour.  A greater concern is in malformed encodings
where a matching MIME sub-part cannot be found.  Should the decoder
attempt to fetch the resource via 'http:'?  If so, the message itself
is in error, as the resources are not present in the packaged message.
Also, should a decoder check if the referenced content is up to date,
or just use the encapsulated MIME sub-part instead?

The use of 'http:' as a referencing mechanism seems to be
at odds with what the encoding represents.  Placing a 'Content-Location'
header field in the MIME sub-part is possibly useful as metadata,
however we would suggest that the 'cid:' referencing mechanism be
mandatory.

1) Referenced parts MUST include the 'Content-Transfer-Encoding' field
   and should include the 'Content-Length' field.

The MIFFY description as presented in the above referenced document
presents a sound approach to encoding of compound or multipart payloads.
It appears that the described encoding mechanism from SOAP data into
MIME encoded multipart will produce arbitrary binary data for the
encoded MIME sub-parts.   In particular, when control characters,
i.e. less than 32 decimal are encoded in base64, they will decode into
raw control characters in the MIME part.  The NUL (0x00) character in
particular will very probably be problematic.

MIME sub-parts encoded in such a manner assume an 8-bit clean
transmission channel, which may not be available for general application
of such an encoding.

In the presence of an 8-bit clean channel, there must be a workable
mechanism to allow the inclusion of arbitrary binary data.  Such
binary data may by its very nature include a valid MIME part delimiter.

The mechanism for inclusion of arbitrary binary data inside a MIME
sub-part is addressed in RFC 2045 by use of the
'Content-Transfer-Encoding' field with a parameter specified as
'binary'. In the case of using the 'binary' encoding, the MIME header
MUST include a 'Content-Length' field indicating the number of bytes
of raw binary data present in the sub-part (as specified in RFC 2543
etc.).

It is our suggestion that the 'Content-Transfer-Encoding' and
'Content-Length' fields be present in all MIME sub-parts encoded using
the MIFFY encapsulation.  At minimum the contained data should be
analysed for compatibility with non-binary transport gateways and the
sub-part encoded using a well specified 'Content-Transfer-Encoding',
be that base64, etc.

For simplicity of encode/decode we would suggest that
'Content-Transfer-Encoding' and 'Content-Length' be mandatory in a
MIFFY encoded sub-part and that the encoding be 'binary'.

Note, that the CIP4 group using JDF already use such a scheme for
transmission of multipart aggregated print jobs in pre-press production
areas.

In the absence of an 8-bit clean transmission channel, MIFFY
should specify a preferred encoding mechanism for the sub-parts,
most probably base64.  In any case, transcoding at gateways should
be possible.

Can a message contain multiple representations of the same resource 
using the MTOM representation mechanism. E.g. can a message contain 
JPEG and PNG renditions of the same resource using the MTOM 
representation mechanism.

What is the extensibility and versioning strategy
for mtom elements?   Do we allow extensibility of attributes and/or
elements, and if so, what is the processing model for extensions?  What is
the policy related to the miffy namespace name for future elements and/or
attributes?

I have some thoughts on the right way to do this at
http://www.w3.org/2001/tag/doc/versioning-20031003

As requested at the f2f, this note is to remind us that we (should) have an
open issue to determine how a SOAP HTTP implementation, receiving whatever
content type we eventually decide on for MTOM, will make the determination
to do MTOM processing.  We must then make suitable updates to the HTTP
section of the MTOM document.

When the scope of MTOM was SOAP-only, it seemed that the likely rule would
be:

      Don't use xbinc:include in the SOAP envelope, it's for use by
      bindings.

Now that we are considering miffy, there are questions about including one
miffy-based format in another.  Here's a concrete if somewhat contrived
example:

a) imagine a vcard-like XML format that allows inclusion of someone's
picture.  Enable that for miffy so that the picture can be carried
efficiently.
b) Question:  can you carry such a vcard as part of the content of a soap
body or header?  What are the miffy processing rules of that SOAP envelope
is itself Miffy encoded?

This seems to be an example of a more general issue, relating to the
combination of miffy-enabled formats.  Of course, this is all somewhat
complicated by the somewhat strange relationship of the
application/soap_mtom_xml media type to the surrounding multipart/related.

The name "Miffy" is copyright by "Mercis bv", see http://www.miffy.com/. I
recommend that after completing its technical work, the XMLP WG choose a
non-encumbered name to replace "Miffy".

In Sept. I sent an email to distApp announcing that the data model
formulation of MTOM was ready for consideration by the XMLP Workgroup [1].
Subsequently, the workgroup agreed to adopt the DM formulation.  In the
email, I raised some concerns that should have turned into issues, but
apparently we never formally added them to the list.  Specifically, see the
paragraph that says:

"At least one set of details remains to be resolved if the DM formulation
is to be used: the current draft does not discuss all of the accessors
provided by the data model. For example, element nodes [5] provide a
base-uri [6], which in principle can vary for each element. Future versions
of the draft would need to explain that, like type information, such base
URI and similar information is not transmitted. This limitation is
consistent with the general philosophy that MTOM will transform the input
data model to a different (but predictably different) output data model at
the receiver. In general, the transmission will exactly preserve certain
information, will lose other information such as base URI and type, and
will not add or synthesize other information, except as directly follows
from the losses (e.g. typed values change in the obvious way when type
information is lost.)"

So, as suggested on our telcon of today, this is a request to open an
issue.   I suggest that the issue be relatively broad, along the lines of
"Do a thorough review of the DM, MTOM and if appropriate Miffy specs to
ensure that all interdependency issues, including those raised in [1], have
been dealt with in an appropriate manner."

By media-typing I mean providing the media type as defined by RFC 2045
and 2046.

In July, I proposed [1] a new section to be added to our document, that
would cover PASWA [2] sections 3, 7 and appendix I. I basically copied
the appropriate text from PASWA. Mark Nottingham reacted [3] to that by
presenting a few different options for providing media types to binary
data in XML. On a related topic, Philippe le Hegaret summarized a few
different approaches [4] for the WS-Description WG. Subsequently, the
WS-Description WG has agreed to do some work in this area.

Media-typing binary data in XML is going to be useful (IMO necessary)
for the Representation header work we're about to start. As the actual
media-typing specification work has moved to the WS-Desc WG, I suggest
that we collect the requirements we have on the media-typing spec. Below
is a first-cut list of requirements that I gathered from what I think
Representation header will need:

     1. It must be possible to indicate unambiguously the media type of 
     a piece of binary data that's present as base64-encoded 
     character content of an element information item.  
     
     2. It must be possible to indicate in XML Schema what media type 
     the character content of an element ii will have.  
     
     3. It should be possible to specify a set of such media types, see 
     the HTTP Accept header (RFC 2616).  
     
All this can be done specifically for the Representation header if it 
turns out a generic solution is too contentious or just not useful. 8-)

I took an action item to write up a strawman proposal for metadata and
the Representation header. Here it is:

1.  For each MIME header create an attribute information item in the
[attributes] of the Representation element information item 

2.  Set the [local name] of the AII to the name of the MIME header 

3.  Set the [namespace name] of the AII to
http://www.w3.org/2003/11/soap/metadata (actual URI TBD). 

4.  Set the [normalized value] of the attribute is the value of the
MIME header.

Note that this is just a strawman to start discussion. 

My own take is that this approach is actually the reverse of what we
actually want. I suggest that we actually start by deciding what
metadata we care about in two cases:

a. On a Representation element information item

b. On an arbitrary element information item whose content is in
canonical base64

and then define a mapping from that metadata to the appropriate MIME
headers.

On today's call [Wed Oct 1], we adopted a proposal that says:

" there is no property explicitly suggesting what to optimize.  The rule is
that a binding MAY optimize any, all or none of the items that are of
dm:type xsd:base64binary.  We agree to discuss later whether data to be
optimized must be in canonical form, and if so what canonical."
[...]

So, we need to discuss whether to indicate that only canonical forms can be
optimized by MTOM.  If yes, we need to decide whether to adopt the canical
form suggested in the errata to XML schema or some other form.

It occurs to me that in certain use cases the identical large binary might
logically serve as content to multiple leaf nodes.  This could in principle
be done by reference to headers, but that changes the vocabularies and is
not in all cases natural.  I wonder whether we should allow a smart MTOM
implementation to point multiple xbinc:Includes to the same mime part (I.e.
use the same URI)?  Seems like a win to me, and I can quite easily imagine
implementations that would know from the construction of the DOM or similar
structure that the content was identical.

In any case, I think we should open an issue to make clear what the rule
is, even if we just clarify that you must not link a given mtom part from
more than (or perhaps less than?) a single xbinc:Include.  My current
leaning would be to allow flexibility in both directions.  Multiple
xbinc:Includes should be able to ref the same content, and it should be
possible to carry content that is not referenced at all (e.g. to avoid the
need for reference counting, or to maintain certain kinds of signatures,
even if a header with a reference is removed.)  That said, I wouldn't
expect many implementations to avail themselves of the permission to send
large useless content,  but I think the sharing makes sense.

> Given that the type rule is extensible by IANA, it seems most sensible
> 
> to NOT enumerate the current types. This leaves us with:
> 
>     [a-zA-Z0-9!#$%^&\*_-\+{}\|'.`~]+/[a-zA-Z0-9!#$%^&\*_-\+{}\|'.`~]+

Unless the working group/task force has reason to believe that the IANA
is going to change its long-standing policy of conservatism in the
approval of new types, this statement is not quite correct.

One new type has been added since the publication of the four MIME RFCs
("model").  There is good reason to suggest that an enumeration of types
is preferable to an open content model: what are you going to do with a
type you don't recognize?  The reluctance of IANA to approve new types
is another factor, as is the reasoning behind it: new types are avoided
because they require changes to deployed software.

So, I would think that it would be better to enumerate, with an escape
to vendor-defined or random types.  But the enumeration is valuable,
signalling the set of types that processors should (in some fashion)
support.

1. Should MTOM accommodate encodings/optimizations other than base64?
    a. If so, should the list be open-ended (i.e., extensible)?

MTOM/PASWA can be used to carry encapsulated documents in SOAP.  Such
encapsulated documents may contain relative URIs. The workgroup must
determine the rules for establishing base URIs for resolving such relative
references (and if there are any other uses of base URIs, for them too.)
Among other things, we need to decide whether the requirements are
different for content carried as children of a Representation element 

[1] vs. for other Paswa content (Note that other Paswa content is not in
general distinguishable by inspection of the SOAP infoset.)

-- derived from 431 --
are intermediaries required to preserve optimization/non-optimization of
element content?
--
should we say anything about the responsibility of intermediaries?

-- derived from 432 --
Another question that came up is how does a receiver determine which
elements were optimized which led to discussion of a receiver side
property 'OptimizedElements'. This may be worth recording as a separate
issue.

2: "How does the binding determine which nodes to serialize as 
attachments ?"

1: "What are the semantics of attachments w.r.t. SOAP intermediaries. 
E.g. do we expect intermediaries to preserve what is serialized as 
attachments and what is serialized inside the SOAP envelope."

there are two questions we identified on the PASWA proposal:

1) does the application see xbinc:Include? 
2) does the SOAP processing model see xbinc:Include?

Everyone seems to agree that the application should not see
xbinc:Include.

The second question can be re-framed as whether we want smart protocol
bindings or whether bindings can be ignorant of xbinc:Include.

The PASWA proposal is designed to be able to work with bindings ignorant
of it, using the DoInclude header. On the other hand there is much
appeal in creating smart protocol bindings that would hide xbinc:Include
processing completely.

So the issue is: do we allow protocol bindings to optimize transmission
of SOAP Envelope infoset using the xbinc:Include technique? Even
further, do we require that bindings take care of xbinc:Include and that
the SOAP Processing model never sees an infoset with xbinc:Include
element information items?

[4th part of closed issue 375]

  "The compound SOAP structure model does not require that a SOAP receiver
   process, dereference, or otherwise verify any secondary parts of a compound 
   SOAP structure. It is up to the SOAP receiver to determine, based on 
   the processing context provided by the primary SOAP message part, which 
   operations must be performed (if any) on the secondary part(s)."

This paragraph troubles me deeply. I think that I understand the 
motivation behind the text, but I think it misses the point, at least from my 
perspective.
See the second bullet above regarding what I perceive are the receiving
SOAP node's responsibilities. I think that we need to be careful in the 
language that we choose.

From SOAP1.2 part 1:

 "SOAP node
 The embodiment of the processing logic necessary to transmit, receive, process 
 and/or relay a SOAP message, according to the set of conventions defined by 
 this recommendation. A SOAP node is responsible for enforcing the rules that 
 govern the exchange of SOAP messages (see 2. SOAP Processing Model). It 
 accesses the services provided by the underlying protocols through one or more 
 SOAP bindings."

I think that we need to be very careful about articulating the responsibilities 
of a SOAP node with respect to any features that are defined. According to the 
definition above, a SOAP node's responsibilities include 'processing' which I 
believe we now mean to include the application-level processing.

From SOAP 1.2 part 1 section 2.6:

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

I believe that what the wording:
  "The compound SOAP structure model does not require that a SOAP
   receiver process, dereference, or otherwise..." 
is intended to mean that, just as the SOAP spec says nothing about what a 
receiving SOAP node does with the contents of a SOAP header block or the SOAP 
body, this feature imposes no requirement that the representations of the 
resources actually *be* processed, dereferenced or otherwise validated, etc. 
However, it DOES have a responsibility to provide for the means by which 
the references can be resolved in the event that the application-level 
processing determines that a particular reference be resolved.

[1st part of closed issue 375:]

"Compound SOAP structure
    A compound SOAP structure consists of a primary SOAP message part 
    and zero or more related secondary parts."

I'm a little concerned that the term 'part' used in this spec will be
confused with the term 'part' as used in WSDL. It isn't clear to me that a 
'part' in WSDL would equate to a 'part' as described in this spec.

The term 'part' as used in this context equates to MIME or DIME message
'part', which is certainly one way to look at this, but IMO, not the only way 
to view it.

[2nd part of closed issue 375:]

"Compound SOAP structure

I'm also a little concerned with the use of the term 'compound SOAP
structure'. The serialization of a SOAP message that contains references 
external to the SOAP envelope may be as a compound structure, but that again 
is just one way of achieving the objective of making the referents available 
to the receiving node(s). I look at the serialization of a SOAP message
and its referents using MIME or DIME as an optimization that should be 
(nearly) invisible to both the sending and receiving application, not as its 
inherent structure.

[3rd part of closed issue 375:]

 "4. Compound SOAP Structure Model 
    A compound SOAP structure consists of a primary SOAP message part and 
    zero or more related secondary parts that are distinct from the primary 
    SOAP message but related to it in some manner. 
    Secondary parts can be used to contain data that naturally represents a 
    resource in its own right or which is cumbersome to represent within the 
    primary SOAP message part. The latter can be due to the size, type, or 
    format of the data--a secondary part may be an audio clip, an image, or 
    a very large view of a database, for example."

Again, I look at the problem a little differently. A SOAP message may
contain references to resources that are external to the SOAP envelope itself. 
The references themselves define the semantics of the relationship between the 
SOAP message and the referent resource. It is outside the scope of this 
specification to attribute specific semantic relationship between the SOAP 
message and its constituent parts (SOAP header blocks and the contents of 
the SOAP body) and the resources to which these may refer.

[This is the last part of closed issue 374:]

On the technical front I wonder whether the spec should require/specify 
support for at least the CID[3] referencing scheme, rather than punting 
this completely to the packaging spec specification. This wouldn't 
preclude a packaging spec introducing additional referencing schemes 
but would provide at least a minimum of functionality common to all 
packaging specs.

[This is the second part of closed issue 374:]

I would also recommend that the bibliography entries for WS-Attachments, 
WS-Security and SOAP with Attachments be moved to a new section; "Non-normative 
References" in line with approach taken for parts 1 and 2 of the spec.

[This is the first part of closed issue 374:]

On the editorial front I would like to recommend redressing the balance 
between MIME and DIME by adding a reference to the SOAP with 
Attachments note[1] rather than just MIME itself. 

"Compound SOAP structure
    A compound SOAP structure consists of a primary SOAP message part 
    and zero or more related secondary parts."

I'm a little concerned that the term 'part' used in this spec will be
confused with the term 'part' as used in WSDL. It isn't clear to me that a 
'part' in WSDL would equate to a 'part' as described in this spec.

The term 'part' as used in this context equates to MIME or DIME message
'part', which is certainly one way to look at this, but IMO, not the only way 
to view it.

I'm also a little concerned with the use of the term 'compound SOAP
structure'. The serialization of a SOAP message that contains references 
external to the SOAP envelope may be as a compound structure, but that again 
is just one way of achieving the objective of making the referents available 
to the receiving node(s). I look at the serialization of a SOAP message
and its referents using MIME or DIME as an optimization that should be 
(nearly) invisible to both the sending and receiving application, not as its 
inherent structure.

 "4. Compound SOAP Structure Model 
    A compound SOAP structure consists of a primary SOAP message part and 
    zero or more related secondary parts that are distinct from the primary 
    SOAP message but related to it in some manner. 
    Secondary parts can be used to contain data that naturally represents a 
    resource in its own right or which is cumbersome to represent within the 
    primary SOAP message part. The latter can be due to the size, type, or 
    format of the data--a secondary part may be an audio clip, an image, or 
    a very large view of a database, for example."

Again, I look at the problem a little differently. A SOAP message may
contain references to resources that are external to the SOAP envelope itself. 
The references themselves define the semantics of the relationship between the 
SOAP message and the referent resource. It is outside the scope of this 
specification to attribute specific semantic relationship between the SOAP 
message and its constituent parts (SOAP header blocks and the contents of 
the SOAP body) and the resources to which these may refer.


 "It is important to note that the compound SOAP structure model does not
  modify or supersede the message envelope concept defined by SOAP. Nor 
  does it define a processing model for any of the parts of a compound SOAP 
  structure including the primary SOAP message part. The processing model 
  for the primary SOAP message part is defined by SOAP. The application-defined 
  semantics of the SOAP message provides the processing context for the 
  secondary part(s)."

Actually, I believe that there *is* a processing model and that this 
specification SHOULD articulate that processing in the abstract (not in 
terms of specific bindings to a particular technology such as MIME or DIME). 
To an extent, this is discussed in section 6, but it is not characterized in 
the manner that I believe it should be.

I believe that the processing model should be as follows:
    - a sending SOAP node implementing this feature must serialize the 
    referents of any references in accordance with the chosen "packaging" technology.
    - a receiving SOAP node implementing this feature must provide necessary 
    functionality that enables any resources referenced within the SOAP 
    message to be resolved (dereferenced, whatever term of art is chosen to 
    mean make the bytes of the representation(s) of the identified resource is 
    made available to the application).

I believe that that is the essence of this feature in a nutshell.

  "The compound SOAP structure model does not require that a SOAP receiver
   process, dereference, or otherwise verify any secondary parts of a compound 
   SOAP structure. It is up to the SOAP receiver to determine, based on 
   the processing context provided by the primary SOAP message part, which 
   operations must be performed (if any) on the secondary part(s)."

This paragraph troubles me deeply. I think that I understand the 
motivation behind the text, but I think it misses the point, at least from my 
perspective.
See the second bullet above regarding what I perceive are the receiving
SOAP node's responsibilities. I think that we need to be careful in the 
language that we choose.

From SOAP1.2 part 1:

 "SOAP node
 The embodiment of the processing logic necessary to transmit, receive, process 
 and/or relay a SOAP message, according to the set of conventions defined by 
 this recommendation. A SOAP node is responsible for enforcing the rules that 
 govern the exchange of SOAP messages (see 2. SOAP Processing Model). It 
 accesses the services provided by the underlying protocols through one or more 
 SOAP bindings."

I think that we need to be very careful about articulating the responsibilities 
of a SOAP node with respect to any features that are defined. According to the 
definition above, a SOAP node's responsibilities include 'processing' which I 
believe we now mean to include the application-level processing.

From SOAP 1.2 part 1 section 2.6:

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

I believe that what the wording:
  "The compound SOAP structure model does not require that a SOAP
   receiver process, dereference, or otherwise..." 
is intended to mean that, just as the SOAP spec says nothing about what a 
receiving SOAP node does with the contents of a SOAP header block or the SOAP 
body, this feature imposes no requirement that the representations of the 
resources actually *be* processed, dereferenced or otherwise validated, etc. 
However, it DOES have a responsibility to provide for the means by which 
the references can be resolved in the event that the application-level 
processing determines that a particular reference be resolved.

Bottom line for me is that we should define this feature in terms of SOAP, 
not in terms of the anticipated technology that might implement the feature.

On the editorial front I would like to recommend redressing the balance 
between MIME and DIME by adding a reference to the SOAP with 
Attachments note[1] rather than just MIME itself. I would also 
recommend that the bibliography entries for WS-Attachments, WS-Security 
and SOAP with Attachments be moved to a new section; "Non-normative 
References" in line with approach taken for parts 1 and 2 of the spec.

On the technical front I wonder whether the spec should require/specify 
support for at least the CID[3] referencing scheme, rather than punting 
this completely to the packaging spec specification. This wouldn't 
preclude a packaging spec introducing additional referencing schemes 
but would provide at least a minimum of functionality common to all 
packaging specs.

2) It isn't clear that we should not adopt the fragment identifier
meaning associated with application/xml. I don't think that
we want to preclude use of fragment identifiers.

    7. Fragment identifiers

    No meaning is associated with fragment identifiers for content
    described by the "application/soap+xml" media type.

3) Base URI is not addressed and should be IMO (it is in RFC3023).
 From section 6 of [SOAP12P1]:
        SOAP does not define a base URI but relies on the mechanisms
        defined in XML Base[11] and RFC 2396[6]  for establishing a
        base URI against which relative URIs can be made absolute.

Suggest that a section entitled "Base URI" be added to the ID
and suitable text (possibly directly from the spec, or maybe
just referencing where in the spec this is defined) be added.

(Added during TBTF teleconf of 15 Apr 2002: Check also encoding supported (UTF-8, etc...)

Has the WG considered whether to give advice about/dictate handling of 
the 'no-transform' cache-control directive, as well as the '214 
Transformation applied' warning-value in the HTTP binding? It may be 
prudent to do so.

Many moons ago, Paul Denning, David Clay, and myself took an action to start
writing up a "module template" to essentially describe the framework for
writing a SOAP 1.2 extension.  For various reasons, this work fell by the
wayside, but I note that we haven't come back to it or replaced it with
anything else.

I think it's critical that we have some section somewhere offering some
guidance as to how to do this, since this is ostensibly going to be one of the
major extensibility mechanisms by which a lot of people build on the platform
we are creating.

At a minimum, I would think such a section would indicate that a SOAP extension
spec/module:

* MUST identify itself with a URI (this becomes really critical when trying to
describe services with something like WSDL, or when doing negotiation with an
unknown party)

* MUST clearly specify the content and semantics of the header blocks used to
implement the behavior in question

* MUST clearly specify any known interactions with other extensions in terms of
semantics or sequence (for instance "this encryption extension will encrypt the
contents of the body.  On the receiving end, it MUST run before other
extensions which rely on the unencrypted contents of the body.")

* MAY indicate that the extension functions as an implementation of a SOAP
feature as defined in sec 3 of part 1.  In this case, the spec must also
clearly specify the relationships (if appropriate) between any abstract
properties defined in the feature spec (as described in sec 5 of part 2) and
concrete instantiations in the SOAP envelope

* SHOULD have a well-defined name of EITHER "SOAP extension" OR "module" :)

The current definition of SOAP Intermediaries in section 2.7.1 [1] takes 
into account only the case where the forwarding of the message is 
requested by one (or more) SOAP blocks or by the MEP.

I think that some SOAP nodes may decide to forward a SOAP message using 
other criteria. Nevertheless, I think that those nodes MUST act in the 
role of a SOAP intermediary. I think in particular that that might be 
the case for active intermediaries.

"An ultimate SOAP receiver MUST correctly process the immediate children 
of the SOAP body (see 5.3 SOAP Body). However, Part 1 of this 
specification (this document) mandates no particular structure or 
interpretation of these elements, and provides no standard means for 
specifying the processing to be done."
 
We introduced this formulation during the great debate over body 
interpretation.  In the non-fault case, I think I am happy with it.  I 
think it also implies that ascribing semantics to a body containing a 
fault is optional (or, conversely, you might view the first and second 
sentences as contradictory in this respect.)

In the case of faults, first of all, it contradicts the rest of the 
specification in claiming that we mandate no structure for the body.  I 
suspect we should open an issue at least on that.  My guess is that (with 
apologies in advance to Mark Baker) many of us had assumed that we wanted 
to mandate not just the structure, but also the interpretation in the case 
that a fault was received.  Maybe the issue should be expanded to include 
that question as well, though knowing Mark's views, it may not be easy to 
achieve quick consensus on a resolution.

We should talk about whether we want to support two mechanisms for specifying "action" or not. If we want or need to support both, we should define what happens if they're both used at the same time. We also need to specify how the RequiredSOAPActionURI property interacts with the action parameter in this case.

There are three major usage modes or ways to think about SOAP. 

1. as a very generic messaging framework, as described in part one of
the specification.

2. as a remote procedure call mechanism as in Part 2, Section 5.

  2 a) An encoding for parameter values
  2 b) A method calling syntax

3. as an extension mechanism for HTTP, as discussed in 6

[... (cut, see email for full details) ...]

I propose, therefore that SOAP be split, as XSL was split, into
languages with unique names. I propose SOAP-Messaging, SOAP-RPC and the
SOAP HTTP Binding. Arguably SOAP-RPC could also be split into the SOAP
encoding and SOAP-RPC but it may not be helpful to slice that finely

No, it is not an acceptable resolution but I did not expect an
acceptable resolution. I am just trying to be a good citizen in trying
to influence the specifications rather than merely criticize them.

You've referred me to an internal URI which I unfortunately cannot
access. Nevertheless, let me reiterate that there is widespread
confusion about what SOAP is. I think that this is in large part because
under the one name there are very different technologies. The last
specification I can remember that bundled so many diverse, seemingly
independent pieces under one name was HyTime. Be afraid. Be very afraid.
[...]

I want to raise an issue with the model for RPC invocations and
responses defined in Section 5, Using SOAP for RPC, of SOAP 1.2 Part 2.

Specifically, mandating the "result" element from the
"http://www.w3.org/2001/12/soap-rpc" namespace as the accessor for an
RPC call's return value is problematic because that element is defined
as being of anyType.

I don't beleive that the schema as it stands allows for the encodingStyle 
attribute to appear on the Envelope or Header elements, whilst the prose allow
for that situation, however my understanding of XSD is shakey enough that i
could be wrong. Shouldn't the Envelope and Header complex types include an 
attributeGroup reference to the encodingStyle attribute group ? Also is there
any reason why encodingStyle uses an attribute group ?

<quote where="Section 2.6 Processing SOAP Messages, bullet 5">
In the case of a SOAP intermediary, and where the message is to
be forwarded further along the message path, remove all SOAP
header blocks targeted at the node, and possibly insert new SOAP
header blocks.
</quote>

I went over the binding framework and the HTTP binding and noticed a
problem; no where is it stated how SOAP processors should recognize
faults.

The issue is that sometimes a SOAP node may want to send a message
that includes a Fault, but is not intended to be processed as a
Fault.  An example would be if a SOAP node is asked, perhaps via a
debugging interface, to return the last fault it sent.

Using HTTP as an example, the HTTP response code is used as the
authoritative determinant of the intent; if it's a 2xx response, then
the Fault is not processed as a Fault.  If it's a 4xx or 5xx, then it
is.

The original is incoherent. A message with a DTD
is not a SOAP message. Legal bindings don?t even accept infosets
that contain DTDs for transmission.  How could one be received?"

<quote where="soap12-part1.html#soapenv">
On receipt of a SOAP message containing a Document Type
Declaration, a SOAP receiver MUST generate a fault (see 4.4 SOAP
Fault) with a fault code of "DTDNotSupported".
</quote>

We can't keep applications from requiring
validation for their own content.  How can we keep applications
from supplying defaults for their own purposes? We even do it for
our own attributes."

<quote>
Therefore, SOAP REQUIRES that all attribute information items,
whether specified in this specification or whether they belong to
a foreign namespace be caried in the serialized SOAP envelope.
</quote>

During the F2F I was actioned to raise an Issue with respect to the first
Ednote in SOAP 1.2 Part 2 section 7.4.1.2.1, part of the HTTP binding.

The ednote states:
<quote>
As described this model tends to hide a malformed message from the local
SOAP Node and handle the malformation in the binding - basically because it
would not be possible to instantiate the CurrentMessage to pass up for
processing. An alternate formulation might be to allow CurrentMessage to
carry badly formed messages and let the SOAP processor/node deal with it. As
presented here we can have define the bindings behaviour with respect to
particular failures. 
</quote>

The issue that the ednote raises is two fold:

1) From a descriptive point of view where do we place the responsibility to
describe behaviour associated with the receipt of poorly formed SOAP
messages? Malformations might include: XML that is not-well formed;
Unsupported envelope version; some unsupported message encapsulation (eg
MIME/DIME etc).

2) From a more practical point-of-view, is it right that a binding
implementation 'hide' the receipt of such 'broken' messages from the SOAP
processor/node. This may be more moot, because it probably makes
inappropriate assumptions about the structure of an implementation.

At the recent face-to-face it came to light that more prose was needed
around the id and ref attributes in the SOAP Encoding section of
Part 2

Specifically the uniqueness constraint needs to be made explicit. We cannot
refer to XML Schema for this, because the uniqueness constraint is defined
in XML Schema Part 1 as part of a validation episode and SOAP requires
that no such episodes be mandated.

 This is an issue that was brought up a few times but never 
really discussed.
 In SOAP Encoding (and the Data Model) we have the notion of a 
compound type which contains some members. The members may be 
accessed via their names or ordinal position or both.
 We have three or four ways of accessing the members:
 A) 1) by name, 2) by position, 3) by both;
 B) 1) by name, 2) by position, 3) by name and then by position,
4) by position and then by name.

 I assume B is the case because IMO there are enough differences
between B3 and B4 to make them distinct and I claim that B3
together with B4 cover all the useful cases of A3 and that there
is no overlap between them.  The "useless" cases of A3 not
covered by B3 and B4 are the cases where the application changes
its approach significantly and arbitrarily while processing a
single multistruct.

 In B1, the order of members in the XML serialization is 
completely insignificant, the names carry information.
 In B2, the names of members in the XML serialization are 
completely insignificant, the order carries information.
 In B3, the relative order of two elements with the same name is
significant, while the relative order of two elements with
different names is disregarded; the names are significant.
 In B4, the order of all the elements is significant, so are all 
the names.

 Let's see an example of a serialized multistruct:

   <multistruct>
     <a>1</a>
     <b>2</b>
     <a>3</a>
     <c>4</c>
     <a>5</a>
   </multistruct>

 The difference between B3 and B4 is in the order of choosing by
the position and by the name if a service wants a member with the
name 'a' and position 2.
 B3: choose all 'a's, then choose the second one. Result:  
<a>3</a>.
 B4: choose the second member (<b>2</b>) and ensure it's an 'a'. 
(Actually, a more real scenario would be to get the second 
member, choose the action based on its name, then process the 
value.)

 My opinion is that in B3, the multistruct would be better 
described as a structure containing array of 'a's, array of 'b's 
and an array of 'c's.
 In B4, the natural mapping of the data (on the data-model 
level) would be to an array of tuples {name, value}.

 Both remappings would mean complicating the XML serialization
but the data would be so much more clear about their meaning.  
(Ultimately this is the same for representation of sparse arrays
and partially transmitted arrays and references to attachments or
other stuff, since we removed the incomplete arrays and hrefs.)

 Asir's given me the argument that with the current syntax (same
for B3 and B4) the receiver can choose to approach the data
differently from how the sender approaches them. But this is
hairy because if the sender has data modeled as B3, it will view
my first example and the following one as equal and may choose a
random one, whereas a B4 receiver will see them as different and
will possibly treat them differently with different results -
how's that for interoperability? It's like if an application was
free to treat a struct like an array - same ordering issues.
 The second example:
   <multistruct>
     <a>1</a>
     <a>3</a>
     <a>5</a>
     <b>2</b>
     <c>4</c>
   </multistruct>

SOAP Encoding schema declares several elements whose type is a complex
type derived from XML legacy types:

(a) <xs:element name="NMTOKEN" type="tns:NMTOKEN" />
(b) <xs:element name="NMTOKENS" type="tns:NMTOKENS" />
(c) <xs:element name="ID" type="tns:ID" />
(d) <xs:element name="IDREF" type="tns:IDREF" />
(e) <xs:element name="ENTITY" type="tns:ENTITY" />
(f) <xs:element name="IDREFS" type="tns:IDREFS" />
(g) <xs:element name="ENTITIES" type="tns:ENTITIES" />
(h) <xs:attribute name="NOTATION" type="tns:NOTATION" /> (an attribute decl)

Per XML 1.0, all these types are attribute types. XML Schema specifies
that [3], for compatibility these types should be used only on attributes.
But, SOAP specs do not specify any such health warning.

        <a foo="bar" id="1">blah</a>
        <b foo="baz" href="#1"/>

Part 2, section 4.1 'Rules for Encoding Types in XML' [1], rule 8 says that
"SOAP arrays MUST contain a enc:arrayType attribute whose value specifies
the type of the contained elements as well as the dimension(s) of the array"
Plus,

Part 2, section 4.1 'Rules for Encoding Types in XML' [1], rule 2 says that
"MUST .. the containing element instance is itself contained within an
element containing a (possibly defaulted) enc:arrayType attribute or "

In brief, an array MUST contain an enc:arrayType attribute. And, this
attribute specifies the type and other related information.

XML Schema types can be broadly classified into two categories: named types
and anonymous types. Using this example, I demonstrated that the SOAP
encoding does not consider anonymous types as first class types. And, in
general, not just the array, SOAP encoding does not consider anonymous types
as first class types 'cos it is not possible to compute the value of
xsi:type attribute either.

SOAP uses encodingStyle attribute to indicate the encoding rules used for
serializing parts of a SOAP message. encodingStyle attribute is a whitespace
delimited list. Each item in the list is type anyURI, XML Schema built-in
type. And, specification says that sets of rules should be listed in the
order most specific to least specific.

I think we need to say a bit about which such URI's are guaranteed 
derferenceable, and which not.  We may need to say that the answer depends 
on features supported and/or binding.   For example, I hope it's 
guaranteed that with SOAP+Attachements (a potential feature), references 
to attachements are guaranteed to resolve.  On the other hand, I certainly 
wouldn't expect a similar guarantee for a reference to w3.org, if I'm 
processing the message on a Palm Pilot that is currently disconnected from 
the rest of the Web.  The text you give is ambiguous, but could lead 
readers to believe that Web connectivity is required to do conforming 
processing of SOAP messages.

So I think we should add some wording to say how exactly types
are described in XML Schema and what to do with schemas that
don't map back to our encoding (for example complex types
containing application-defined attributes.)

The conclusion here is that multi-reference representation's 'id' attribute
is not a real XML 1.0 ID. This means,

(a) Implementations must use additional code to simulate XML 1.0 ID
(b) It fails to satisfy Usage Scenario S21 [5]. 'Cos, implementations must
parse the entire document to construct an id and bearing element information
item table.

Production rules [1] for arrayType value information use an unfamiliar
notation, ABNF from RFC 2616. This confuses many first time readers.

Because SOAP is XML based and for consistency, I suggest that we use the
notation from XML 1.0.

Part 2, section 4.1 'Rules for Encoding Types in XML' [1], rule 8 says that
each array member element is encoded as an independent element. In the
previous terminology section item 11, spec says that
an independent element is any element appearing at the top level of a
serialization and all others are embedded elements.

This is a disconnect. 'Cos, examples in section 4.4.2 'Arrays' use embedded
elements to represent array members.

Regardless, what is the rational for encoding array members as independent
elements?

Secton 4.3.1
  While both SOAP Header and SOAP Body are defined as independent
  element information items, they are in fact related. The
  relationship between a SOAP body block and a SOAP header block
  is as follows: a SOAP body block is semantically equivalent to a
  SOAP header block targeted at the default actor and with a SOAP
  mustUnderstand attribute information item with a value of "true".
  The default actor is indicated by omitting the actor attribute
  information item (see 4.2.2 SOAP actor Attribute).

This last sentence implies that people "should" omit the actor
attribute when in fact they MUST omit it, right?  I think this last
sentence should be removed it could lead to some confusion.  Oh wait,
is the last sentence talking about headers or the body - I thought
it meant the body - but now that I reread it perhaps we're talking
about headers.  If we're talk about headers then we should change
it to something like:
  On headers, the default actor is indicated by...

Section 4.1.1
  ...Each item in the list identifies a set of serialization
  rules that can be used to deserialize the SOAP message.
  The sets of rules should be listed in the order most specific
  to least specific.
"can be used" or "MUST be used"?
Also, we have lists of serialization rules, does it mean that
a value on an element overrides any previously mentioned value
or that it just extends the list?  It sounds like it replaces
it - we should be prefectly clear on this.

Section 2.5 - bullet #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 [targeted for this node that
  are] identified as mandatory.
Please add the "targeted for this node that are". Also, the
")" is missing from the "see 4.4 SOAP Fault".

Section 2.4 - 1st paragraph
  ...increased flexibility in processing order as long as all SOAP
  messages, SOAP faults and application-level side effects are
  equivalent to those that would be obtained by direct implementation
  of the following rules [in order].
Please add the "in order".

Section 2.4 - 2nd paragraph
  ...local name and namespace name of the outer-most element
  information item of that block; or not process the SOAP message
  at all, and fail (see 4.4 SOAP Fault).
"and fail" - shouldn't it be "and generate a fault".

Section 2.3 - 2nd paragraph
  We say that a SOAP block is targeted to a SOAP node if the SOAP 
  actor (if present) on the block matches (see [10]) a role played
  by the SOAP node, or in the case of a SOAP block with no actor 
  attribute information item (including SOAP body blocks), if the  
  SOAP node has assumed the role of the anonymous SOAP actor.
This is quite a change from 1.1 - to me this says that the "actor"
attribute is the *only* way to target blocks - in 1.1 we said
"The XMLP/SOAP actor global attribute can be used to indicate the
XMLP/SOAP node at which a particular XMLP/SOAP header block is
targeted" - notice the "can be used" - I read that to say that 
there may be other means of deciding which blocks are targeted 
for a node.  Also, in section 4 (when we repeat actors and nodes!)
we say "can".  I think we should remove this section in favor of
section 4.

Section 2.2 SOAP Actors and SOAP Node
  The roles assumed MUST be invariant during the processing of an
  individual SOAP message; because this specification deals only
  with the processing of individual SOAP messages, no statement is
  made regarding the possibility that a given piece of software
  might or might not act in varying roles when processing more than
  one SOAP message.
"invariant" - so if during the processing of a message a SOAP node
determines that it should also assume additional "roles", this would
be illegal?  I think this should be allowed.  We've been talking
about an issue very much along these lines on the mailing list
but I can't remember what it's resolution was - so this might have
already been resolved.

  A SOAP node receiving a SOAP message MUST perform processing
  [according to the SOAP processing model], generate SOAP faults,
  SOAP responses, and if appropriate send additional SOAP messages,
  as provided by the remainder of this specification.
1 - please add the text in []
2 - Does it really have to be able to generate SOAP responses?
    What if all it does it is log the soap message - that's still a
    valid SOAP node.  I believe the key is the processing model not
    whether it generates a repsonse or not.  Perhaps just move the
    "if appropriate" so we have instead:
  A SOAP node receiving a SOAP message MUST perform processing   
  according to the SOAP processing model and if appropriate generate
  SOAP faults,  SOAP responses, and send additional SOAP messages,
  as provided by the remainder of this specification.

  These four parts are functionally orthogonal. In recognition
  of this, the envelope and the encoding rules are defined in
  different namespaces.

" A SOAP message SHOULD NOT contain processing
 instruction information items."

[email] re 4.4.1 SOAP Fault Codes.

Table speaks of 'Client' faults and 'Server' faults. I think that this is the only place where the notion of 'Client' and 'Server' arise. Concepts of 'Client' and 'Server' are not developed anywhere in the document.

It seems to me that 'Client' is more akin to 'Sender' and 'Server' is more akin to 'Recipient'. Regardless, I'm not sure personnally that 'Client' and 'Server' are appropriate distinctions to make in a generic SOAP messaging framework.

4.4.1 SOAP Fault Codes: [Editorial/Technical]
        '..."http://www.w3.org/2001/06/soap-envelope." Use of this namespace
is recommended (but not required) in the specification of methods defined
outside the present specification."

        Two things:
                1)      the use of the word 'method' seems to have
                        carried through probably from SOAP 1.0 and
                        is tied to the notion of faults arising from
                        method/RPC invocations.

                2)      I think that the RPC TF have gone against the
                        (not required )recommentation in defining a new
                        namespace for rpc related faults. Does this remain
                        our recommendation?

4.3 SOAP Body [Technical]
        "Each SOAP body block element information item:
                MAY be namespace qualified
                MAY have an encodingStyle attribute information item"
      

I think that the first of these MAY's should be a MUST. 4.2 states that Header block element info items *MUST* be namespace qualified. Also, 4.3.1 describes the semantic relationship between bodies and headers which is to say that bodies are semantically equivalent to headers targetted at the default/anon actor. If that is indeed the case the need for NS qualification on bodies arises from this semantic equivalence.

[email]

See also the first discussion.

From email:

The issue is that there are applications such as encryption and
compression in which intermediaries may need to replace header or body   
blocks that are not targeted at the intermediary.  The text as stated
indicates, for example, that "relayed SOAP messages MUST contain all
SOAP header blocks and the SOAP body blocks from the original SOAP
message, in the original order."  Some of the potential resolutions
of this include:
1) keep the wording and disallow such applications.  This is problematic
   since such applications may be essential for security and efficiency.
2) keep the spirit of the processing model. but change the change the
   wording to allow such "encoding transformations" as long as the
   abstract infoset remains the same.  This seems tricky since the targeting
   of these blocks may need to be changed back and forth, but may be workable.
3) soften the MUST in the sentence to SHOULD, indicating that the normal
   state of affairs is that intermediaries will not transform the parts of the
   message not targeted at them, but allowing exceptional cases.
4) formally define a standard processing model as given in this paragraph,
   but define a mechanism to allow applications to employ alternative models.

Section 3 states;

"[A SOAP Application] MUST discard messages that have incorrect
namespaces"

Shouldn't this say that it MUST generate a Fault?

Also, 'unsupported' seems more appropriate than 'incorrect'. Same
language in 4.4.1.

Finally, considering our versioning model, does it make sense to
upgrade

"A SOAP application SHOULD include the proper SOAP namespace on all
elements and attributes defined by SOAP in messages that it
generates."

to MUST, and strike

"... MAY process SOAP messages without SOAP namespaces as though they had
the correct SOAP namespaces."

This is in the context of all SOAP namespaces, not just the envelope,
but it seems prudent to clarify in some fashion.

[email]:We need to address any implications of XML Base on the value of the href attribute if it isn't expressed as an absolute URI.

The gist of the problem is that the current HTTP binding uses HTTP POST
requests. However, sending an HTTP POST requests to a URI have precise
semantics[4]:

[..]

SOAP messages carried in an HTTP POST request may have the semantics
of an HTTP GET request for example, and using HTTP POST in that way
can be inappropriate.

Moreover, one of the Web architecture axiom is[5]:

   In HTTP, anything which does not have side-effects must use GET

Another aspect is that doing RPC requests over HTTP POST targetted to
a generic resource (say <http://example.com/genericSoapProcessor>) is
also incompatible with the REST principles.

Issue reported by Aaron Swartz, Mark Baker (see links from email).

It would appear that the accessor is "phoneNumbers" and not
    "phone-numbers" in the example introductory text.

Soap 1.2 says [1] :
   
"SOAP naturally follows the HTTP request/response message model by
providing a SOAP request message in a HTTP request and SOAP response
message in a HTTP response"

The only formally defined notion of "Response" in the remainder of the spec
is in chapter 7, and is specific to method-style RPC.

So, there is a potential ambiguity as to whether the HTTP binding, as
written, allows non-RPC responses to be sent as HTTP responses.  This
should, perhaps, be tracked as an issue.

I will note that my personal preference would be to introduce a simple but
somewhat more clearly architected notion of message exchange patterns, with
the spec providing specific definitions for one-way and request-response,
including any implications for fault handling, etc.   Should that prove too
ambitious, we might want to at least clarify the http binding.

 In SOAP, fault codes are defined to be qualified names. The
specification lists four predefined codes. Then it also adds that
the fault codes are extensible by separating more and less
general identifiers with a dot character.
          
 I have a couple of issues with this approach to extensibility.

 1) from the XML viewpoint Client and Client.Authentication are
completely different identifiers. From an XML perspective it is
impossible to say that "Client.Authentication" is still a "Client"
fault.

 2a) The specification seems to say that these extended identifiers
will still be in the SOAP envelope namespace. Does this mean that
anybody can arbitrarily extend the W3C SOAP envelope namespace?

 2b) If the new, extended fault codes are to be in a different
namespace, there is again no way to know that
{some-namespace}Client.Authentication is actually also a
{soap-envelope-namespace}Client fault.

 3) There already is a <detail> element in the fault which might
be a good place to put the detail information into.

I think W3C specs should leverage what XML already provides (like
qnames and hierarchical data) and minimize parsing that must be
done above what XML processor does. This comment is actually also
valid on the SOAP encoding array attributes. 8-)

See also Paul Gibbons's email.

This issue should be considered in conjunction with issue 16.

From email, "how are void returns represented in the *presense* of [out] and/or [inout] parameters eg. for void MyProc(p1Type *p1)?"

"2.Enable support for matching response messages to request messages for cases in which matching is not provided by the underlying protocol binding.

Section 7.2 states that a correlation ID is an example of the use of a SOAP header element. This does not seem to be a normative part of the specification and no rules are placed on the form of such a transaction ID.

"3.The ability to specify the parameters to a call in a request message and the results of a call in a reply messages."

"4.Provisions for specifying errors in a reply message (see also 703a and 703b)"

[email]

[RPC5] Should there be a predefined set of fault codes that apply specifically to RPC? Examples would include errors for missing parameters, out of range values, etc.

"Where possible, an attempt will be made to leverage any related work done by the IETF."

Use of the data model and encoding style described in this section is encouraged but not required; other data models and encodings can be used in conjunction with SOAP (see section 4.1.1).

For simple types, SOAP adopts all the types found in the section "Built-in datatypes" of the "XML Schema Part 2: Datatypes" Specification, both the value and lexical spaces.

SOAP arrays are defined as having a type of "SOAP-ENC:Array" or a type derived there from (see also rule 8). Arrays are represented as element values, with no specific constraint on the name of the containing element (just as values generally do not constrain the name of their containing element).

The representation of the value of an array is an ordered sequence of elements constituting the items of the array. Within an array value, element names are not significant for distinguishing accessors. Elements may have any name.

Arrays can contain elements which themselves can be of any type, including nested arrays.

1st design issue is use of port 80, 2nd design issue is 12, 3rd design issue is 14

Will likely be considered in conjunction with issue 78

This issue should be considered in conjunction with issue 113.

Should multiref be top level or inline?

Refer also to issue 121 for a more detailed description.

First, we will tackle point 2.

Will likely be considered in conjunction with issue 16

• The "mustUnderstand" attribute represents a contract from the sender to the destination of a particular header, but in a wider sense it represents some extension in the message which MUST be understood if the whole message is going to succeed in its purpose. Therefore, if endpoints ignore headers that missed their destinations, the originator of those headers has NO WAY of knowing that processing failed. This is at best a source of confusion, if not serious problems.
• The "actor" attribute takes precedence over everything else in the processing model. The base protocol shouldn't care about headers which didn't get processed by intermediaries. Routing is a higher-layer issue, and if people wish to use the extensibility mechanism to implement routing checks and such, that's up to them. This streamlines the processing model for everyone, and doesn't require special code which acts differently at endpoints/intermediaries.

See also the discussion between Doug and Hugo and its followup.

(this description is taken from the cited e-mail message) Although SOAP messages are fundamentally one-way, the HTTP binding serves as an example of the possibility for transport bindings to introduce higher level message patterns such as request/response. Presumably, other bindings could also support a request response model, but the SOAP specification does not mandate any particular relation between request/responses implemented by HTTP for example and SMTP (I think it should).

Interestingly, the request/response model is explicitly exploited in a transport independent way by the RPC specification in chapter 7. The specification does not state, but strongly implies that RPC responses will indeed be returned to the originator of the request, and that the transport binding will be responsible for doing the necessary addressing. Certainly the HTTP binding does this.

The relationship of faults to message patterns is even more subtle, and perhaps will need improvement or clarification. Specifically, section 4.4 of the SOAP specification gives information about what must be in a fault message. However, since messages are fundamentally one-way, and since there is no general-purpose notion of a request/response or other higher level pattern, nothing is stated in general as to where if at all faults are delivered. In this respect, the specification is nearly vacuous: it mandates that a fault message be constructed in certain manner, but it allows it to be dropped on the floor before anyone sees it.

That's what the spec says. Reading between the lines, here's what I think it is really trying to say:

"Although SOAP messages are fundamentally one-way, SOAP supports the construction of higher level message patterns on top of that. In addition to one-way, this specification includes a well architected notion of request/response, which certain applications and SOAP processors may choose to use when sending SOAP messages. SOAP transport bindings are responsible for supporting the request/response abstraction (always? optionally?). Transport bindings that support request/response are responsible for providing the ability for an intermediary or SOAP end point to return response or fault messages back to the originator of a request. Response messages can be assumed to take the exact reverse path of requests; so response and fault messages can be inspected if desired by the same actors the processed the outbound request {not sure about that..maybe we should make request/resp apply only to the endpoints?}. SOAP RPC uses the request/response message pattern, and is therefore usable only on with transport bindings that support request/response.

The delivery rules for Fault messages are message pattern specific. The rules for the two message patterns supported by this version of the SOAP specification are:

• For one way messages, no mandatory behavior is given for generating or routing fault messages, except that if delivered they must be in the form of section 4.4.
• Faults generated during the transmission and processing of a request message in a request/response pattern are delivered on a best-effort basis to the originator of the entire message sequence (which may or may not be the insertion point of the header that caused the fault), passing as for all responses along the reverse of the same path as the request. Transport bindings that implement the request/response pattern are responsible for either eventually delivering the response or fault, or else eventually reporting a broken connection to the requester. No specific time limit for such reporting is given. The faults generated by problems with the response message itself are treated in the same manner as faults in a one-way message: no mandatory behavior is given for generating or routing fault messages generated by such failed response.

The SOAP specification contains statements such as "A SOAP application receiving a SOAP message MUST process that message by performing the following actions in the order listed below: ... Identify all parts of the SOAP message intended for that application (see section 4.2.2)", etc. and also "The SOAP actor global attribute can be used to indicate the recipient of a header element. The value of the SOAP actor attribute is a URI. The special URI "http://schemas.xmlsoap.org/soap/actor/next" indicates that the header element is intended for the very first SOAP application that processes the message. This is similar to the hop-by-hop scope model represented by the Connection header field in HTTP. Omitting the SOAP actor attribute indicates that the recipient is the ultimate destination of the SOAP message"

SOAP thus makes clear that in certain circumstances, the same actor can have more than one URI identifier (e.g. as "next" and also something explicit). The SOAP specification should be clarified to remove all ambiguities relating to such aliases. For example, the specification should be unambiguous regarding the processing of mustUnderstand headers, generation of faults, etc. Furthermore, the specification should make clear whether users can or cannot choose to create their own aliases, and if so what processing rules apply.

A special case of this issue arises at the end of the message path. It seems that this point can be addressed by at least two means, an explicit "next" and the more common absence of an actor. Can there be other user supplied names that also are acted upon by the end point?

<complexType name="Fault" final="extension">
  <element name="faultcode" type="qname" />
  <element name="faultstring" type="string" />
  <element name="faultactor" type="uri-reference" minOccurs="0" />
  <element name="detail" type="tns:detail" minOccurs="0" />
</complexType>