W3CArchitecture DomainXML Protocol WG

XML Protocol WG Issues List

Last update: $Date: 2004/05/27 12:58:22 $

This issue list is only for documents that are NOT in Last Call. Please refer to the Last Call issue list (XML source)

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.

Summary List of Outstanding Issues

idStatusSpecTopicClassReqTitle

Detailed List of Issues

idSpecReqTopicClassStatusRaised ByOwner
1Specn/aencDesignClosedEric SmithETF
Title: Escaping illegal characters
Description: Need description of how to escape properties with illegal characters for XML in SOAP.
Proposal: From PaulC: see Subclause 5.1 "Mapping SQL <identifier>s to XML Names" from ftp://sqlstandards.org/SC32/WG3/Progression_Documents/Informal_working_drafts/wd-xml-2001-06.pdf.

See the proposed resolution.

Resolution: The proposed resolution has been adopted [resolution text].
2Specn/aEditorialClosed bryan_murray@HP.COM
Title:
Description: Follow-up: Whats wrong with attributes?
Proposal:
Resolution: Dup of issue 1
3Specn/aEditorialCloseddavec@progress.com marting@develop.com
Title: xml schema revision
Description: Update syntax of "*" to "unbounded" in SOAP schema according to latest Schema language syntax.
Proposal:
Resolution: Update completed in SOAP 1.2 WD, July 9, 2001
4Specn/aenvDesignClosedLarry MasinterMarc Hadley
Title: Handling DTDs, PIs
Description: Lack of clarity and design choices in SOAP's HTTP protocol binding.
Proposal:

See the proposed resolution by Marc Hadley.

Resolution:

The resolution text shows stricter replacement text:

A SOAP message MUST NOT contain a Document Type Declaration. On receipt of a SOAP message containing a Document Type Declaration, a SOAP receiver MUST generate a fault (see 4.4 SOAP Fault) with faultcode of "Client.DTD". A SOAP message SHOULD NOT contain processing instruction information items. A SOAP receiver MUST ignore processing instruction information items in SOAP messages it receives.

See the reply from the originator.

After discussion, issue 4 has been closed and a new issue, issue 145 has been opened regarding XML declarations.

5Specn/aEditorialClosedlars@LARS.COM marting@develop.com
Title: examples
Description: Problem in some examples.
Proposal:
Resolution: Update completed in SOAP 1.2 WD, July 9, 2001
6Specn/aEditorialClosedmarek@ICSD.MOT.COM marting@develop.com
Title: examples and schema
Description: Bugs in examples and question of consistency between text and schema.
Proposal:
Resolution: Update completed in SOAP 1.2 WD, July 9, 2001
7Specn/aEditorialClosed bernhard.dorninger@SCCH.AT marting@develop.com
Title: xml schema revision
Description: Need to update with respect to to latest XML schema spec.
Proposal:
Resolution: Update completed in SOAP 1.2 WD, July 9, 2001
8Specn/aenvDesignClosedmnot@akamai.com
Title: clarify processing model
Description: Lack of clarity in SOAP processing model. Various issues?
Proposal:
Resolution: This is redundant with other issues. [resolution]
9Specn/aEditorialClosedmarek@ICSD.MOT.COM marting@develop.com
Title: schema ns declarations
Description: Bug in example - need declarations of xsd and xsi namespaces
Proposal:
Resolution: Update completed in SOAP 1.2 WD, July 9, 2001
10Specn/aEditorialClosedTim SawyerEditors
Title: <xml version>
Description: Lack of clarity of when to use XML Version info.
Proposal: Duplicate of issue 145.
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email]
11Specn/aDesignClosedLarry MasinterMark Nottingham
Title: various
Description: Lack of clarity and design choice in SOAP protocol binding to HTTP, for example, use of port 80, HTTP status codes, and use of MUST/SHOULD/MAY is inconsistent.

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

Proposal:

This issue has not been resolved. A summary was prepared for Dinard, but not presented.

Resolution:

Mark Nottingham is going to draft some text to warn about the use of default ports.

From the resolution text: We resolved this at our most recent face-to-face, and have inserted text that gives guidelines regarding default ports into what will become the framework for transport bindings. We will incorporate such wording into the HTTP binding itself as its development progresses.

12Specn/abindDesignClosedLarry MasinterStuart Williams
Title: HTTP error codes
Description: SOAP and HTTP status codes (200 vs. 500 etc.).
Proposal:

From Stuart:

"This issue has not been addressed at all and is still outstanding."

The scope for resolving this issue lies wholly within the definition of the
SOAP HTTP binding. Discussion of this issue tends to be polarised and has
lead to threads that have become 'exausted' without conclusion eg. [2,3].

I also believe that viewspoints on the resolution of this issue are linked
with the viewpoints on the SOAP as a 'cameleon' protocol that takes on the
'character' of what it is bound to or as a 'platform' protocol that provides
messaging services that are largely independent of the underlying protocol.
This  theme also leads to lenghty threads eg. [4]

Broadly, I think the resolution of this issue is also tied up with the work
of the TBTF although I don't think that TF has an explicit action to propose
resoulution for this particular issue.

[2] "Issue #12: HTTP Status Codes 500 v 200"

[3] "another approach to status codes, etc. in HTTP binding"

[4] "A tale of two bindings"

Two proposals will be reviewed: proposal 1 and proposal 2.

See the new text from Chris.

Resolution: See resolution text from Chris and response from originator, and followup by Chris, and resolution text
13Specn/abindDesignClosedCharles F McDevittMark Nottingham
Title: http port number
Description: SOAP and HTTP on port 80.
Proposal: Duplicate of 11?
Resolution:

Mark Nottingham is going to draft some text to warn about the use of default ports.

From the resolution text: At our most recent face-to-face, we inserted text into the draft which addresses the issues of the use of default ports.

14Specn/aenvDesignClosedLarry MasinterMartin Gudgin
Title: SOAP versioning
Description: SOAP versioning model. See also, 66
Proposal: This issue was resolved indirectly by the WG's decision at the Dinard F-T-F to change the SOAP namespace URI and provide a description of how versioning should be achieved ( Appendix C. Version Transition From SOAP/1.1 to SOAP Version 1.2[1] )
Resolution:

At a face-to-face meeting back in February the Working Group decided to change the SOAP namespace URI and describe how versioning from SOAP 1.1 to SOAP 1.2 should be managed. [resolution email]

See also the response to the resolution text and the response from the Working Group.

15Specn/aDesignClosedLMM@acm.org
Title: (Dupe)
Description: Some protocol requirements labeled as 'MUST' in the SOAP 1.1 spec seem to require implementation etails that have no explicit interoperability requirements. What is the fallback for encodingStyle and confusion about SOAPAction.
Proposal:
Resolution: Duplicates 11
16Specn/arpcDesignClosedBryan MurrayFrank DeRose
Title: Void return type
Description: The RPC mapping is not clear on how a method with a void return type and no out arguments should be mapped onto the SOAP protocol.

Will likely be considered in conjunction with issue 78

This issue should be considered in conjunction with issue 113.

Proposal:
Resolution:
  Issue 16 [1] is closed as proposed in this message.

 In a nut shell, the following explanation and the examples below captures
the resolution. For more details, read this message.

 The existence of a return value is signified by the presence of a
namespace-qualified accessor named 'result' with the namespace identifier
"<http://www.w3.org/2001/12/soap-rpc>" and void returns are not expected to
have the above named accessor. 
[email]
17Specn/aEditorialClosedBryan MurrayETF
Title: Section 5 usage
Description: Discussion needed as to when and why to use the section 5 encoding.
Proposal:
Resolution:
A) Change the introductory text in section 2 from

"The SOAP data model represents information as a graph of typed nodes.
The type system used in the SOAP data model is a generalization of the
common features found in type systems in programming languages,
databases and semi-structured data. A type is either a simple (scalar)
type or is a compound type constructed as a composite of several other
typed parts. Examples of simple types are "string," "integer,"
enumeration, etc. Compound types are described as follows:"

To

"The SOAP data model represents information as a graph of typed nodes.
The type system used in the SOAP data model is a generalization of the
common features found in type systems in programming languages,
databases and semi-structured data.

The purpose of the data model is not to introduce a programming model in
SOAP but rather to provide a mapping of non-XML based instance data to
some wire representation. It is important to note that use of the SOAP
data model and the SOAP data encoding is optional. Applications which
already model data in XML, for example using W3C XML schema, may never
have any need for using the SOAP data model. Because of the optionality
of using the SOAP data model and encoding, it is NOT a requirement to
implement it as part of a SOAP node.

A type is either a simple (scalar) type or is a compound type
constructed as a composite of several other typed parts. Examples of
simple types are "string," "integer," enumeration, etc. Compound types
are described as follows:"

B) Change first paragraph in part 2, section 3 from

"SOAP encoding describes how to serialize instances of data that conform
to the data model described in 2 The SOAP Data Model for inclusion in
SOAP messages."

To

"SOAP encoding describes how to serialize instances of data that conform
to the data model described in 2 The SOAP Data Model for inclusion in
SOAP messages. Note that nothing precludes the specification of
different encodings based on other data models, or indeed that make
different use of the SOAP data model. The SOAP encodingStyle attribute
information item (see SOAP Encoding Attribute) can be used to
indicate the encoding used."

C) The last part of the edit is to remove the paragraph:

"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 SOAP Encoding Attribute)."

as we already address this in section 2.
[email]
18Specn/aenvDesignClosedHenrik Frystyk NielsenETF
Title: "top-level" is unclear
Description:

Should multiref be top level or inline?

Refer also to issue 121 for a more detailed description.

Proposal:

This issue is a duplicate of issue 121. When closing the issue, get back to Paul Kulchenko, the originator of issue 121 as well.

See also the summary of the SOAPBuilders discussion.

Resolution: Hi, the WG has decided to close the issue #18 with the resolution as presented in this email, generally by removing the terms "top-level of serialization" and "independent elements" and thus also allowing embedded multiref elements.
19Specn/afaultDesignClosedBryan MurrayHenrik Frystyk Nielsen
Title: Ns of Fault children
Description: The SOAP spec currently does not require any namespace for the children elements of the Fault element; namely, faultcode, faultstring, detail, and faultactor. These elements are therefore in the default namespace.
Proposal:

See email from Henrik:

Reporters comment:

Certainly, if the consensus is to leave the children of SOAP Fault unqualified, that is what should be done.

I am surprised that given a chance to fix this potential problem that more people are not interested in doing so. Faults are an area that is likely to be fairly localized in most existing implementations and would not be difficult to change. Work needs to be done just to adapt to the new namespace, why not add a namespace to these 4 elements? My understanding is that it is likely there will be additional changes to the spec before it transitions from a working draft to a proposal, this would be yet another small change.

Henrik's proposal:

It seems that other than convention there is no strong argument for why using unqualified sub-elements breaks or limits what one can do in any way.

Resolution: The Working Group has decided not to change the specification regarding this matter. See the resolution text and the add-on to the resolution text.
20Specn/aencDesignClosedsjm@APTEST.COM pcotton@microsoft.com
Title: clarify schema usage
Description: Propose to have 'xsd:string' as the default type for the standard encoding style and how schemas are to be used

First, we will tackle point 2.

Proposal:
Resolution: The issue originator agrees that his original issue was actually about the XML Schema schemaLocation attribute rather than XMLP/SOAP, see email (member-only).
21Specn/aenvDesignClosed jlapp@WEBMETHODS.COM
Title: packaging app payloads
Description: Related issues regarding the SOAP messaging model and how it works with packaging
Proposal:
Resolution: See the resolution text.
22Specn/abindDesignClosedHenrik Frystyk NielsenHenrik Frystyk Nielsen
Title: SOAPAction header
Description: There is nothing that says what to do in the HTTP protcol binding if there is a SOAPAction header field but no SOAP in the HTTP request entity body
Proposal: See proposal
Resolution: The Working Group decided during the September 2001 face-to-face meeting that, whether a SOAPAction header is presence or not, a SOAP Client fault must be generated if the SOAP message is missing [resolution text].
23Specn/aDesignClosedMarc Hadley
Title: (Dupe)
Description: Be more specific when and when not PIs and the like is allowed. Duplicates issue 4
Proposal:
Resolution:
24Specn/aenvDesignClosederikc@microsoft.comDavid Fallside
Title: allow same ns for mutiple headers
Description: It should be allowed to have multiple headers using the same namespace (multiple signatures for example) in a single SOAP message. The current SOAP envelope schema doesn't allow this
Proposal:

The SOAP envelope schema defines the type for the Header element as having a content model of: <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> This allows multiple qualified elements from any namespace except http://www.w3.org/2001/06/soap-envelope to appear.

See Hugo's tracking on August 27th.

Resolution: The current specification already allows that. See acknowledgement by the originator.
25Specn/aenvDesignClosedYves LafonHugo Haas
Title: Status of trailers
Description: What is the status of footers/trailers? The SOAP/1.1 spec is somewhat ambiguous on the matter as it allows "other stuff" after the body but doesn't say what to use it for or what the processing model is.
Proposal: Trailers will be removed from the specification, with a note saying that we have done so to let a chance to people who really want it to let us know.
Resolution: [resolution email] Trailers have been removed from the specification, and an editorial note has been inserted to warn people about the removal of trailers.
26Spec400DesignClosed pcotton@microsoft.com
Title: (Req Met) Data encapsulation and representation are orthogonal
Description: [email] SOAP/1.1 provides a data model and a proposed serialization of that model using the encoding provided in section 5 [1] . Both the data model and the data serialization is orthogonal to the data encapsulation (the SOAP envelope [2] ). In [1] it is stated that the two are orthogonal:

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

The SOAP envelope provides a mechanism in form of the "encodingStyle" envelope attribute [3] that allows other data models and data serialization mechanisms to be used,
Proposal: Requirement Met
Resolution: The WG agrees with the commentator that the requirement is met for the reasons given
28Spec401DesignClosed pcotton@microsoft.com
Title: (Req Met) Data representation must support XML Schema simple and complex types
Description: [email] SOAP/1.1 adopts all simple types defined by XML Schema as described in [4] :

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.

The SOAP/1.1 data model supports the use of XML schema complex types although it does not support the use of attributes for carrying instance values. The reason is that the SOAP/1.1 serialization mechanism reserves attributes for book keeping of the serialization and does not allows the application to otherwise use attributes. Therefore, XML instances using attributes for carrying instance data do not follow the SOAP serialization. There are two ways around this: generate a schema as described in the comment of R402 or not to use the SOAP serialization model. As one of the goals of the SOAP serialization is to limit the ways instance data can be encoded, the limitation of attributes is not considered as a disadvantage.
Proposal: Requirement Met
Resolution: SOAP/1.1 supports simple types and support complex types with the exception of attributes which are reserved for the SOAP serialization. The perceived benefit of this limitation is that it provides a simpler mapping to common programming language constructs. It is therefore judged that this requirement is met given the stated limitation.
29Spec402encDesignClosedPaul CottonETF
Title: Exist non-serialisable data models?
Description: [email] SOAP/1.1 states that given any data model that can be expressed using the SOAP/1.1 data model consisting of simple types, complex types, and references, it is possible to create an XML schema representing that model. Next, given a particular instance of values (for example a graph) expressed using that XML schema, it is possible to create an XML instance representing those values. This XML instance is what is being transferred within a SOAP message. The recipient of a SOAP message can given the XML schema and the XML instance recreate the original value (for example a graph)
Proposal: The current SOAP/1.1 model seems to be capable of representing directed graphs as well as object graphs and enable a recipient to deserialize an XML instance to recreate those graphs. It is not clear whether there are other data models that potentially are interesting to serialize but not representable within the SOAP data model.

See discussion thread started by PaulC.

Resolution:
Serialisations of non-syntactic data models can be transported in the
envelope of SOAP messages. For example, RDF graphs can be transported using
RDF's XML encoding, and MOF/UML models can be transported using an XMI
encoding. We have no evidence of non-syntactic data models that cannot be
transported using an XML serialisation.
[email]
30Spec403encDesignClosedPaul CottonETF
Title: Refs to data outside serialisation
Description: [email] The SOAP/1.1 encoding uses the "id" and "href" attributes to name and refer to resources or sub-parts of resources. The format of the href attribute is of type "uri-reference" as defined by XML schema. The "id" attribute is of type "ID" as defined by XML/1.0. There are no restrictions on the value of a URI used as value in a href attribute.
Proposal: SOAP/1.1 covers this requirement although it is not explicitly stated that URIs can in fact point to anything.
Resolution: See resolution email
31Spec404DesignClosed pcotton@microsoft.com
Title: (Req Met) Arrays, nested
Description: [email] Comment: The SOAP/1.1 data model defines an array type [5] :

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

as well as the encoding mechanism defines a serialization of that array type:

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.

and can be nested:

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

Proposal: Requirement Met
Resolution: The WG agrees with the commentator for the reasons stated.
32Spec307metaDesignClosedDavid EzellStuart Williams
Title: Support usage scenarios (simple deployment)
Description: [email] It cannot be proven that SOAP1.1 would not address this requirement; however, the requirement calls out usage scenarios as tools to prove suitability. Since the usage requirements themselves are under consideration, we can only suggest that the XML Protocol R307 will help outline requirements which are more widely "suitable" than those used in the design of SOAP1.1, and further suggest that SOAP1.1 might fall short of fulfilling these requirements. More specifically, SOAP1.1 has only limited usage scenarios, and as such falls short of R307.
Proposal: From Marwan: The R 307 is to insure that SOAP 1.2 is suitable for widespread use across organizational boundaries. This implies that the complexity of the SOAP 1.2 specifications is kept to a minimum.

I think we all agree that SOAP 1.2 is a simple protocol, given that there exist over 46 implementations.

From 14 November 2001 teleconference: Stuart Williams will produce resolution text.

Resolution: Work currently in progress [2] illustrates how each of these scenarios may be realised using SOAP 1.2 and therefore demonstrate the suitability of SOAP 1.2 for use across organisational boundaries. [resolution text]
33Spec308metaDesignClosedDavid EzellTBTF
Title: Support modularity/layering
Description: [email] The SOAP1.1 specification succeeded to some extent in supporting modularity, especially modularity in terms of unforeseen architectural components which can be supported through constructs such as the "Header" and "Body" elements, or in SOAP encoding rules. However, this modularity seems weaker than that specified in the XML Protocol requirements. Further, SOAP1.1 doesn't appear to have much support for "layering". Such support arguably requires a clear architecture, promised in XML Protocol requirements (R300) but missing in SOAP1.1.
Proposal: From Marwan: The R 308 argues for modularity and layering in the design of SOAP 1.2. SOAP 1.2 achieves the modularity goal through the use of header blocks and XML namespaces. The SOAP 1.2 binding framework specifies how SOAP 1.2 binds to different transport protocols such as HTTP, HTTPS, SMTP, etc. Also, SOAP 1.2 makes no assumptions with regards to the protocol used for transport. (Except for SoapAction)
Resolution: At the face-to-face in Cannes, the WG voted to accept the proposed resolution described below for issue #33. No changes to the specs are necessary to close this issue.
Modularity at the Top
---------------------
The SOAP 1.2 processing model, combined with the ability to add arbitrary extensions to the protocol via the header mechanism, allows spec writers and implementors to cleanly implement pieces of additional functionality in an extremely modular fashion. While it remains the case that some "best practices" documentation with regard to designing SOAP 1.2 "modules" would be useful, the spec itself has been carefully designed to allow for the composition of an almost infinite set of extensions authored by the W3C or any other parties.
Modularity at the Bottom
------------------------
The Binding Framework in section 5 of part 1 of the spec lays out an architecture for designing transport bindings which may provide for an arbitrary number of "binding features", which may be characterized as semantic extensions to the base SOAP protocol which are provided by the binding/transport. Bindings may be authored for any existing or future underlying protocol, and the framework allows SOAP nodes to utilize arbitrary feaures of any such protocol.

It is the opinion of the TBTF that these factors provide for sufficient modularity in the design of SOAP 1.2 to satisfy the 
requirement, and that issue 33 should therefore be closed.
[email]
    
34AM300metaDesignClosedDavid EzellMarwan Sabbouh
Title: Scope of "semantics" definition in AM, SOAP/XMLP, out-of-scope
Description: [email] In SOAP1.1, "1. Introduction", SOAP specifically declines to define an architecture, abstract or otherwise: "SOAP does not itself define any application semantics... or implementation semantics...; rather it defines ... a modular packaging model and encoding mechanisms...". The semantics mentioned are some of the key elements in the abstract models which are being introduced. Clearly, SOAP1.1 doesn't satisfy XML Protocol requirements in this regard. Please note that these semantics are also the focal point of the ongoing "usage scenario" work being done by the WG. Also note that "application" semantics are clearly out of scope (as they are for SOAP1.1), whereas "operational" semantics of a messaging system are in scope.
Proposal: From Marwan: The R 300 states that SOAP 1.2 not addresses application semantics. The issue is the "operational semantics" introduced by the AM document. The semantics mentioned in the AM document are in the context of SOAP 1.2 data flow processing and SOAP 1.2 header blocks. This is not to be confused with application semantics, since SOAP 1.2 does not define any application semantics. Find out the status on the AM?
Resolution:
The XMLP WG decided to close issue 34 you raised in relation to the
Abstract Model WD with no action taken.  SOAP 1.2 meets the R300
requirement and does not address application semantics.  The semantics
mentioned in the AM document are in the context of data flow processing and
header blocks, or operational semantics, not application semantics.
Further, the AM is now a Working Draft no longer in development.
Refinement of the AM is therefore not in the WG's current scope of work.
    
[email]
35Spec301DesignClosed David_E3@Verifone.Com
Title: (Req Met) Simplicity
Description: [email] SOAP1.1 conforms
Proposal: Requirement Met
Resolution: The XMLP WG believes that the SOAP 1.1 specification meets this requirement.
36Spec301ametaDesignClosedDavid EzellMarwan Sabbouh
Title: Clarify nature of conformance
Description: [email] Since SOAP1.1 defines only a "modular packaging model" and "encoding mechanisms", conformance with SOAP1.1 can be viewed as "validation" conformance (as in DTD or Schema validation). "XML Protocol requirements" is suggesting a more rigorous conformance test which includes semantics defined in in-scope usage scenarios, i.e. certain types of behavior.
Proposal: From Marwan: This issue highlights the need for a conformance draft document. The WG will make available a draft document that specifies conformance requirement.

During the 14 November teleconference, the Working Group decided to postpone this issue until a test suite is produced and the issue will then be closed.

Resolution:
The XMLP WG today decided to publish - as part of Last Call -  a Test
Collection Working Draft. A draft version of this document is today
available at [1], and this draft is believed to be close to the version
that is published at Last Call. Per the decision documented in the issue
list, the WG deicded to postpone resolution of this issue until the WG
had decided to publish a document like [1]. With today's decision, the WG
believes it has fulfilled the issue.
[email]
37Spec302envDesignClosed David_E3@Verifone.Com
Title: is SOAP extensibility sufficient?
Description: [email] SOAP1.1 defines a vocabulary with certain types of extensibility. XML Protocol requirements declare a need for extensibility which supports "decentralized extensibility without prior agreement". It's not clear whether the types of extensiblity in SOAP are adequate for this requirement.
Proposal:
Resolution: See resolution text.
38Spec304metaDesignClosedDavid EzellMarwan Sabbouh
Title: Support usage scenarios (simple apps)
Description: [email] A central point of R304 is really that the WG will define certain usage scenarios as in-scope. It is not yet certain whether SOAP1.1 will be adequate for these scenarios. SOAP1.1 does appear to support the RPC flavor of exchange. Other scenarios are not so clear. (See comments in R307).
Proposal: From Marwan: The issue here is whether SOAP 1.2 supports in-scope usage scenarios, especially those usage scenarios relating to simple message exchanges on top of SOAP 1.2. The SOAP 1.2 specification makes it easy to exchange one way and two-way messages. It also provided support for more advanced delivery semantics.
Resolution: The SOAP 1.2 specification makes it easy to exchange one way and two-way messages. It also provided support for more advanced delivery semantics [resolution text].
39Spec306metaDesignClosedDavid EzellMarwan Sabbouh
Title: Ease-of-deployment
Description: [email] SOAP1.1 does not directly address deployment issues; but may indeed satisfy this requirement, with the qualification that it does not address a "full spectrum" of deployment environments. Rather, it addresses the HTTP common web-server/web-browser situation.
Proposal: From Marwan: The issues here are: 1) To ensure that SOAP 1.2 apps work in a variety of environments. Such environments include resource-constrained applications. SOAP 1.2 uses other W3C standards. In this fashion, SOAP 1.2 is easy to deploy. 2) SOAP 1.2 make use of XML standards where appropriate. Such standards include XML namespaces, and XML schemas.

See Henrik's comment.

Resolution: SOAP 1.2 make use of XML standards where appropriate. Such standards include XML namespaces, and XML schemas [resolution text].
40Spec309metaDesignClosedDavid EzellMark Baker
Title: Support resource constrained devices
Description: [email] While SOAP1.1 may indeed be adequate for some simple exchanges usable on small systems, hopefully XML Protocol will do a better job of addressing these needs explicitly.
Proposal: From Marwan: The issues here are: 1) To ensure that SOAP 1.2 apps work in a variety of environments. Such environments include resource-constrained applications. SOAP 1.2 uses other W3C standards. In this fashion, SOAP 1.2 is easy to deploy. 2) SOAP 1.2 make use of XML standards where appropriate. Such standards include XML namespaces, and XML schemas.

See Henrik's proposal.

R309 has been revised during the 14 November teleconference and Mark Baker will write a resolution text.

Resolution: "The ability to use SOAP in a particular environment will vary by the actual constraints, choice of tools, processing model, and nature of the messages being exchanged. The XML encoding of SOAP has dependencies on a minimum number of other specifications (XML Base, XML Schema Datatypes, XML 1.0, and XML Namespaces), none of which has prohibitive processing requirements. SOAP 1.2 also excludes some of XML 1.0's features, which could help lower processing requirements -- see the "Relation to XML section of Part 1, the Messaging Framework. Also, limiting use of SOAP to small messages instead of arbitrarily-sized messages and using a few specific message types instead of implementing generalized SOAP encoding could significantly lower processing requirements." See [email]
41Spec200envDesignClosedvidur@netscape.com RPCTF
Title: no normative target uri
Description: [email] [RPC1] The target (program, service or object) URI (TBD) is not mentioned in any normative way in the SOAP envelope. While this does not conflict with the requirements, I believe it's an important (and possibly debatable) decision. This decision precludes sending an RPC invocation through an intermediary that uses different protocol bindings for sending and receiving XP messages. See also mail thread
Proposal:
Resolution:
The following text is an extract from a proposal produced by Stuart
Williams as part of two longer threads that you may want to look
though for background. The WG adopted the resolution text with the
understanding that it NOT be incorporated into the SOAP 1.2 spec as such
although it of course is a permanent reference for the XML Protocol WG
issues list.

SOAP 1.2 does not provide any normative means to carry the identity ofthe
ultimate recipient within a SOAP envelope. SOAP 1.2 does provide a meansto
identify the roles that a SOAP header block is targetted to.
 
SOAP 1.2 does not provide any normative means for the expression of a
message path with a SOAP envelope. However, it does provide means for the
development of SOAP extensions that provides for such expression withinSOAP
header blocks. [Work to define a message routing extension for SOAP may be
the subject of future WG activity within the W3C.]
[email
42Spec200rpcEditorialClosedvidur@netscape.com RPC task force
Title: clarify "object" and "method" in rpc
Description: [email] [RPC2] The SOAP 1.1 spec uses words like "object" and "method" to refer to the end-points of an RPC operation. More generic words (or better qualification of these terms) that do not bias the reader towards expectations of full-fledged object systems on both sides are necessary.
Proposal:

1. The terms "object" and "method" are replaced by the terms "service" and "procedure", RPC task force minutes

.

2. The wording in SOAP 1.2 (and subsequent) clarifies the usage of the terms.

Resolution: Proposal (2) is accepted by the originator of the issue.
43Spec200DesignClosedvidur@netscape.comvidur@netscape.com
Title:
Description: [email] [RPC3] The requirements state that the "procedure or method to be called" should also be represented using URI syntax. I believe this is an error in our document - the requirements should place no restrictions on the form of a procedure or method name.
Proposal:
Resolution: As the initiater and owner of on our XMLP Issues List, I'd like to suggest that we close it. R200 in the XMLP Requirements document states that a procedure or method name in a RPC call must be represented "using URI syntax". The SOAP 1.1 spec states that procedure or method name is represented as a qualified name. While a qualified name is not syntactically equivalent to a URI, it does contain a namespace URI and does, as such, share the same properties with respect to uniqueness.
44Spec200rpcDesignClosedvidur@netscape.comjkay@ENGENIA.COM
Title: correlation when not supported in binding
Description: [email] [RPC4] Regarding

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

Section 7.1 describes how elements in the body of a SOAP envelope can be used to represent parameters in an invocation and return values (and out parameters) in a response.

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

Section 7.1 states that a "method fault is encoded using the SOAP Fault element".
Proposal: This was first listed as a transaction ID but the group has recast it as a correlation ID as this seems to be what is meant.
Resolution: At the Cannes F2F, the WG decided to accept the following resolution text for issue #44, which arose out of our requirement 200. No edits to the specs are necessary as a result. The TBTF has already defined a message exchange pattern which provides for this type of correlation, and an instance of an HTTP binding which expresses this feature natively in the underlying protocol. We have additionally described the fact that features [4] may be expressed either by binding specifications (either within or outside the purview of the underlying protocol itself) or by SOAP extensions (modules). Although we have not taken on this piece of work directly, we believe we have demonstrated it is possible to write a SOAP module specification which will implement the simple request-response feature via SOAP headers, and therefore provide a transport-neutral realization of the feature. We are confident that this work will occur, and that the results will likely end up in some form "blessed" by an appropriate standards group, however we will not normatively specify such an implementation in SOAP 1.2. [email]
45Spec200rpcDesignClosedVidur ApparaoHugo Haas
Title: RPC fault codes
Description:

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

Proposal:

See proposal.

An RPC fault section has been added to the specification. However, there is still an editorial note saying that the current text conflicts with the definition of SOAP fault codes; clarification has been sought: Marc Hadley will tweak the text in the SOAP faults section to change "this specification" into "part 1 of this specification" and remove the editorial notes.

The issue has been reopened due to a comment regarding the text added to the RPC section, namely whether the order of precedence of the rules is ascending or descending.

Resolution:

A section on RPC faults has been added to the RPC convention:

The RPC representation introduces additional SOAP fault codes to those described in [1]Fault Codes. The namespace identifier for these SOAP faultcode element information item values is "http://www.w3.org/2001/06/rpc" and the namespace prefix rpc: is used in this section to indicate association with this namespace. [resolution]

The specification now specifies that the order of precedence is decreasing.

46Spec200DesignClosedvidur@netscape.com fallside@us.ibm.com
Title:
Description: [email] [RPC6]

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

The SOAP 1.1. spec does not directly reference the IETF work on RPC [ 2 ]. Is the quoted RFC out-of-date? Should more attention have been paid to IETF activity?
Proposal:
Resolution: The working group is chartered with taking the SOAP 1.1. specification as its base. The charter also allows the working group to modify that specification to meet its requirements where the existing specification falls short. In cases where such modifications are necessary, the working group may make use of and/or reference IETF technology. To date, the working group has not made any such modifications. However, we are conscious of keeping in touch with the IETF if such modifications are necessary. In particular, we have at least one person on the working group who is aware of relevant IETF work, we invited a presentation on IETF technology at our f2f meeting, and our W3C staff contacts provide an additional link via a regular W3C/IETF co-ordination call. David Fallside, for the XML Protocol Working Group
47Spec201encEditorialClosedVidur ApparaoETF
Title: Data model vs. encoding
Description: [email] [RPC7] SOAP 1.1 describes its notion of a "data model" in a section describing an encoding system. The notion of a data model should probably be separated from the actual physical representation.
Proposal: [see also discussion thread] SOAP defines in section 5 a datamodel that contains constructs like "struct", "array", "multi-struct", and simple types. The RPC convention in section 7 is cast in terms of the data model and not in terms of a specific representation within the SOAP message. That is, it is possible in SOAP to use another actual representation while still using the SOAP data model as well as using some other data model entirely. We (the WG) makes a note that we should ensure the destinction is made in the XML Protocol spec. We leave it to later to actually decide how we might best tackle this in the design phase. Discussion will take place in email.
Resolution: Issue resolved by agreeing to the text proposed as content for the data model section of SOAP part 2. [email]
48Spec202DesignClosedVidur ApparaoETF
Title: Custom encoding styles
Description: [email] The SOAP encodingStyle attribute [5] can be used to used to indicate arbitrary serialization rules within a SOAP message. Section 5 [3] of the specification also states that "use of the data model and encoding style described in [the section describing the default SOAP encoding] is encouraged but not required; other data models and encodings can be used in conjunction with SOAP."
Proposal: [see discussion thread]
Resolution: See resolution text.
The issue has bee reclosed again on Tue, 12 Mar 2002, see:

You raised an issue to the XML Protocol WG pertaining to the use of
custom data encodings in SOAP. The issue was originally closed in 
November 2001 but during the Feb 2002 F2F meeting the issue was 
reopened and closed as follows.

(i) An implementation of SOAP could be conformant without
supporting the SOAP encoding. i.e. Support of the SOAP encoding is
optional in implementations.
(ii) The SOAP encoding is dependent on the SOAP data model
and that the RPC convention is dependent on the SOAP data model *but* 
*not* the SOAP encoding.
(iii) Tests would be provided for implementations claiming conformance
with the SOAP encoding.

To resolve issue 48 we agreed to the following two actions:

(a) Instructing the editors of the SOAP specification to clarify the
optional nature of the SOAP encoding in the specification and to clearly
describe the dependencies between SOAP, the SOAP data model, SOAP
encoding and RPC convention.
(b) Instructing the conformance subgroup to include tests for SOAP
encoding conformance, but to note the optional nature of the SOAP
encoding in the test suite. i.e. SOAP implementations may choose not to
implement the SOAP encoding, but if they claim conformance with the SOAP
encoding they must pass all of the SOAP encoding conformance tests.
[email
49Spec500DesignClosed john_ibbotson@uk.ibm.com
Title: (Req Met)Support programming models
Description: [email] The introduction to the SOAP specification states that: SOAP provides a simple and lightweight mechanism for exchanging structured and typed information between peers in a decentralized, distributed environment using XML. SOAP does not itself define any application semantics such as a programming model or implementation specific semantics; rather it defines a simple mechanism for expressing application semantics by providing a modular packaging model and encoding mechanisms for encoding data within modules. This allows SOAP to be used in a large variety of systems ranging from messaging systems to RPC. Therefore the SOAP 1.1 specification mainly supports R500. Issue: There is a common belief that SOAP is intended for, and only supports the RPC programming model. The XP WG should emphasise the neutrality of its specification to programming models and illustrate its applicability to them via a wide range of use cases.
Proposal: Requirement Met
Resolution: The WG accepts the commentator's evaluation. Regarding the related-issue mentioned by the commentator, the WG notes that it is adopting use cases and believes these satisfy the issue mentioned.
50Spec501metaDesignClosedJohn IbbotsonTBTF
Title: Consider bindings other than HTTP
Description: [email] The SOAP 1.1 specification defines a binding to HTTP only. Therefore it only partially supports requirement R501.
Proposal: From Marwan: The issue is to unsure that SOAP 1.2 supports (but not define) binding to protocols other than HTTP. The SOAP 1.2 Part 1 has a section Transport Binding Framework [2] that describe how SOAP 1.2 may use protocols other than HTTP. [2]: http://www.w3.org/TR/2001/WD-soap12-part1-20011002/
Resolution: At the Feb 2002 FtF, the XMLP Working Group decided to close issue #50, accepting the new SOAP Email Binding as its resolution. [email]
51Spec502envDesignClosed john_ibbotson@uk.ibm.com
Title: support different message patterns
Description: [email] The SOAP 1.1 specification partially supports requirement R502. There are no explicit examples in the SOAP 1.1 specification to support this requirement. The XP specification must provide a broader set of patterns and scenarios.
Proposal: The XML Protocol Usage Scenarios Working Draft contains some 20 scenarios and patterns illustating the use of SOAP 1.2. The provision of this document resolves the concern of issue 51. [email]
Resolution: the SOAP WG has decided to close issue 51 with the proposed resolution. [email]
52Spec503DesignClosed john_ibbotson@uk.ibm.com
Title: (Non-Issue)Group co-ordination
Description: [email] Requirement R503 is a procedural requirement placed on the XP WG and is not influenced by the SOAP 1.1 specification.
Proposal: Non-Issue
Resolution: The WG accepts the commentators assertion that this is not actually an issue.
53Spec504envDesignClosedJohn Ibbotson
Title: Orthogonal extensions
Description: [email] The SOAP 1.1 specification provides a lightweight framework with extensibility via namespace defined header elements. The SOAP Body provides a mechanism for exchanging mandatory information (Section 4.3). This provides only part of the extensibility requirements implied by R504. Therefore the SOAP 1.1 specification partly fulfils R504.
Proposal: From John Ibbotson: When this requirement and the resulting issue were generated, it was at a time when the real scope of the WG was being established. It was uncertain whether the WG would define any extension headers in addition to the core specification. The optional parts referred to in the requirement relate to any optional extension header that the WG may have defined. The mandatory part refers to the core specification. In the light of the current WG activities and direction (we are not defining any extension headers), I think the issue is no longer valid and we can remove it from the list.
Resolution: The optional parts referred to in the requirement relate to any optional extension header that the WG may have defined. The mandatory part refers to the core specification. In the light of the current WG activities and direction (we are not defining any extension headers), the issue is no longer valid. [resolution text]
54Spec505metaDesignClosedJohn IbbotsonMark Baker
Title: How much is "without a priori knowledge"?
Description: [email] The SOAP 1.1 specification does not support this requirement. At the minimum, there has to be an implicit assumption that the communicating parties will understand the SOAP protocol. The protocol does not provide a mechanism for submitting a SOAP request to a generic HTTP (or other protocol) server.
Proposal: From Marwan: R 505 states that the SOAP 1.2 spec must be suitable for use between communicating parties with no apriori knowledge of each other. This req. is ill worded and should be changed! Typically, two programs needs to agree on the transport binding protocol, method of invocation, encoding, etc. in order for them to communicate successfully!
Resolution:
While it is true that not all uses of SOAP meet requirement R505, the
specification itself can be used in a manner that meets the requirement.
When SOAP is used such that it inherits the semantics of the underlying
protocol, and if that protocol provides the necessary a priori
agreement, then SOAP also inherits it.

This is the case for the default HTTP binding.  It is not required there
be a priori agreement about the use of SOAP, as HTTP provides the
necessary features by which support, or lack thereof, is communicated.
Also, SOAP does provide a "mechanism for submitting a SOAP request to
a generic HTTP (or other protocol) server", as any HTTP URI can have a
SOAP message POSTed to it, and both sender and receiver can coordinate
the view of the success or failure of that POST with existing HTTP
features.  Other protocols that provide similar capabilities will allow
SOAP to inherit them when bound in this way.
[email]
55Spec506EditorialClosedJohn IbbotsonETF
Title: Examples needed for encoding/encapsulation
Description: [email] The SOAP 1.1 specification partially fulfils this requirement. It provides one mechanism for encapsulation and encoding of data with limited examples of extensibility. The XP specification must broaden these mechanisms via use cases.
Proposal: Given that: * The SOAP 1.2 spec provides a modular mechanism by which it is possible to use multiple representations of user data including plain schema based (document literal), using the SOAP encoding provided in part 2, or some other encoding entirely, potentially involving data carried outside the envelope (we at least do not claim to preclude this). * The usage scenario WD [4] contains several examples of encoding data both using document literal and the SOAP 1.2 encoding. * The primer [5] provides several documented examples and use cases of both document literal and the SOAP encoding. would it be reasonable to suggest that we may at the current time cover the call for multiple mechanisms brought forward and close the issue? [email]
Resolution: Proposal accepted. [email]
56Spec600envDesignClosedohurley@iona.com
Title: transport neutrality
Description: [email] SOAP 1.1 has an implicit dependency on a synchronous request/response transport protocol to achieve correlation. It has a further implicit dependency on SOAP processor endpoint information being transport protocol endpoint information.
Proposal:
Resolution: As a result of the Transport Binding Framework in SOAP 1.2, we have separated out the concept of request/response correlation from a particular transport instance (HTTP) into an abstract "feature", whose specification may be found in the Adjuncts section of our spec. As described in the framework text, features may be implemented in a variety of ways, including but not limited to transport-specific representations thereof. Although we have not gone so far as to define an entirely transport-neutral correlation mechanism (such as might be accomplished with SOAP headers), we believe we have demonstrated that such a mechanism is possible. These aspects of our work have removed the "hard-wired" dependence on HTTP correlation mechanisms.

In answer to the second part of the issue, namely that SOAP processor endpoint information must be transport protocol endpoint information, I would posit that this was never really the case. The "actor" attribute in SOAP 1.1 was defined as an arbitrary URI, just like actors/roles in SOAP 1.2. If I am reading the issue correctly and the problem was with node identifiers (i.e. actors) vs. endpoint identifiers (i.e. transport URLs), I think this distinction has been made even more clear in SOAP 1.2.

[email

57Spec604bindDesignClosedOisin HurleyTBTF
Title: Usage scenario over multiple transports
Description: [email] Not relevant to SOAP 1.1, so not addressed.
Proposal: From Marwan: The R 604 suggests that there is no info loss when a SOAP 1.2 message is routed over multiple transports. SOAP 1.2 Action Header may be problematic here, because it is a function of HTTP.

Result of the 14 November teleconference: postponed and assigned to TBTF.

Resolution: This issue is resolved by the SOAP binding to Email, as well as updates to the Transport binding framework text. Within the Transport Binding text, recommendations are given regarding the use of SOAPAction as well as transport based features. [email]
58Spec608metaDesignClosedOisin HurleyTBTF
Title: Must not preclude security binding
Description: [email] Not specifically addressed by SOAP 1.1, although limited extension facilities may be used to help achieve this goal.
Proposal: From Marwan: R 608 states that SOAP 1.2 should not preclude bindings to protocol that provides security. The SOAP 1.2 binding framework specifies how to bind SOAP 1.2 to transport protocols. These protocols can include HTTPS and S/MIME. There are SOAP 1.2 implementations that support HTTPS. Using this implementation, you can encrypt part of the SOAP message; e.g. the body and not the header.
Resolution: XMLP working group decided to formally close issue 58, accepting the proposed resolution text sent on xml-dist-app@w3.org. [email]
59Spec609i18nDesignClosedOisin Hurley
Title: Mandate particular character encoding
Description: [email] Not specifically addressed.
Proposal:
Resolution:
 The transport binding framework will additionally say, that it
is the responsibility of transport bindings to specify how the
infoset is being transfered to and reconstituted by the binding
at the receiving node. Such a binding, if using XML 1.0
serialization of the infoset, may mandate that a particular
character encoding or set of encodings be used.

 The normative HTTP binding will state that it mandates that the
receiver at least supports the UTF-8 and UTF-16 encodings. The
indication and negotiation of used character encodings will be
done using standard HTTP and XML mechanisms.
[email]
60Spec612metaDesignClosedOisin HurleyMarwan Sabbouh
Title: Provide HTTP binding
Description: [email] A binding to a synchronous request/response protocol is implicit in the SOAP 1.1 specification, so a normative binding to HTTP is not addressed.
Proposal: This issue requires SOAP 1.2 to define a normative binding to HTTP. SOAP 1.2 Part 2 [3] does just that! [3] http://www.w3.org/TR/2001/WD-soap12-part2-20011002/
Resolution: SOAP Version 1.2 Part 2 defines a normative binding to HTTP [resolution text].
61Spec700aenvDesignClosedohurley@iona.com
Title: external payload reference
Description: [email] This requirement is partially addressed by SOAP 1.1, which provides a SOAP:Header extension element that may be used to add arbitrary XML to a SOAP:Envelope. SOAP 1.1 does not include defined mechanisms to carry and reference payloads outside the SOAP:Envelope, nor does it address carrying non-XML formatted information.
Proposal:
Resolution:
the WG decided that a document
describing an Attachments binding feature:
(i) be created by the WG's Transport Binding Task Force (TBTF) during the
Last Call review period as part of their work for the WG
(ii) be published by the WG although not as a normative part of the
specification, and as a document type to be decided. Candidate document
types include text document, W3C Note, Internet Draft, etc.
(iii) claims to be a first draft of an Attachments feature description.
(iv) the description to include the concept of an attachment (e.g. the
relation between an attachment and a SOAP envelope, the processing
obligation of a SOAP processor to an attachment, etc), what an attachment
feature means in the context of our framework, and possibly other topics to
be decided
(v) must not prejudice any particular attachment scheme such as SOAP with
Attachments, DIME, etc.
[email]
62Spec700benvDesignClosedOisin HurleyOisin Hurley
Title: mU for extensions
Description: [email] The SOAP 1.1 mustUnderstand attribute scheme satisfies this requirement for the SOAP:header extension mechanism only. XML Protocol specific extension mechanisms will require a similar attribution to satisfy this requirement.
Proposal: From Oisin: This issue I believe to be resolved. The core of the issue was that XMLP extension mechanisms should have a 'mustUnderstand' style of attibute to indicate mandatory processing. I understand this to be the case.
Resolution: The core of the issue was that XMLP extension mechanisms should have a 'mustUnderstand' style of attibute to indicate mandatory processing. This is the case for SOAP Headers, which are the XMLP extension mechanism. [resolution text]
63Spec700cenvDesignClosedOisin HurleyOisin Hurley
Title: standard failure for extensions
Description: [email] Partially addressed by the simple semantics of SOAP:fault categories
Proposal: From Oisin: This is a follow-on issue to 62 and I believe this to also be resolved in the current draft. The core of this issue is a standard failure model for extensions and I think that while we don't have a very rich failure model, having a mustUnderstand code is enough to satisfy this requirement.
Resolution: The core of this issue is a standard failure model for extensions and the mustUnderstand fault code is enough to satisfy this requirement. [resolution text]
64Spec701aenvDesignClosedohurley@iona.com
Title: envelope specification
Description: [email] The SOAP 1.1 Enveloping scheme satisfies this requirement if taken in isolation. Given the context of other XML Protocol requirements and the context of binary content discussions, the SOAP 1.1 scheme may only partially satisfy this requirement.
Proposal:
Resolution: Resolution text: "The schema for the SOAP envelope describes the outermost syntactical construct or structure within which all other syntactical elements of the message must be enclosed. [resolution email]
65Spec701benvDesignClosedohurley@iona.com
Title: define processing model
Description: [email] Is only slightly addressed by the concept and categorisation of faults and so is not satisfied by the SOAP 1.1 specification.
Proposal:
Resolution: "SOAP 1.2 does define a processing model." see resolution email
66Spec702envDesignClosedOisin HurleyMartin Gudgin
Title: xmlp revision mechanism
Description: [email] SOAP 1.1 provides simple envelope versioning through the use of XML namespaces and provides a specific faultcode for a failure in this area. As such it may be said to satisfy this requirement, but in a very unsophisticated manner. See also 14
Proposal: Same resolution as issue 14.
Resolution: At a face-to-face meeting back in February the Working Group decided to change the SOAP namespace URI and describe how versioning from SOAP 1.1 to SOAP 1.2 should be managed. [resolution email]
67Spec703afaultDesignClosedohurley@iona.com
Title: convey error information
Description: [email] SOAP 1.1 provides a fault entity, but also has an implicit dependence on HTTP for delivery, so it partially satisfies this requirement. Again, it is in a fairly unsophisticated manner as the faultcode semantics are limited.
Proposal: Issue 67 [1] "convey error information" appears to partly duplicate of Issue 102 [2] "Clarify rules for delivering fault messages". The resolution of issue 102 [3], that places a responsibility on MEPs specifications to define the disposition of faults during their operation, largely closes Issue 67. The protocol binding framework makes provision for the reporting of errors arising from an operational failure of a protocol binding or its underlying protocol to the local SOAP node. [email]
Resolution: During the W3C XMLP WG Telcon on 6th March 2002 [1] the WG agreed to close Issue 67 by accepting the proposed resolution of the issue. [email]
68Spec703benvDesignClosedohurley@iona.com
Title: convey status information
Description: [email] Not satisfied in SOAP 1.1
Proposal:
Resolution: [email] - The WG has decided to close this issue with the resolution that we don't call out or otherwise define any status information and so status information is handled as any other information that is not fault information. The group believes this covers the requirement.
69Spec803bindDesignClosedMark Nottinghan
Title: HTTP binding bias
Description: [email] The relationship between the transport binding and message is implied in "Using SOAP in HTTP". SOAP doesn't have a firm conception of a protocol binding or the requirments placed upon it - HTTP is assumed.
Proposal:

From Mark: I think we're on the road to satisfying this with the specification of a binding framework, combined with the separation out into 'adjuncts'. I think we should wait until the binding framework is more concrete before we close this, but based on what I know about the direction we're going in, I consider this satisfied.

Resolution: The XML Protocol WG has decided to close issue 69 by noting that the SOAP 1.2 Working Draft now contains a Binding Framework section that describes an abstract framework that can be used to define arbitrary transport bindings. By providing the Framework, the WG believes it has resolved the issue and its underlying Requirement 803. [email]
70Spec811envDesignClosedMark Nottingham
Title: Define processing intermediaries
Description: [email] SOAP accommodates processing intermediaries, but does not define them. See also R806 and R808.
Proposal:

See the proposed resolution text.

Resolution:

The definition of SOAP Intermediary in the glossary addresses this issue. [resolution text]

71Spec806envDesignClosedMark NottinghamHugo Haas
Title: Identifying blocks for processing
Description: [email] SOAP allows targeting through the "actor" attribute. The value of the attribute may be underspecified; currently, there is no standard way to refer to intermediaries with a URI. Additionally, it may be desireable to target an XP Block by means other than direct reference or 'hop-by-hop', as described. Also, SOAP's processing model does not dictate the order in which multiple headers should be processed, if targetted at the same processor.
Proposal:

See Hugo's tracking on August 27th.

Mark's clarification: This issue has not been resolved. The actor 'next' is defined. However, the abstract model also suggests 'final' and 'none' Others, such as 'any' have been discussed.

Mark Nottingham will draft some text for the definition of the 'none' actor.

Resolution:

During the 29 August 2001 telcon, it was decided that the third part of the issue (re. the order in the processing model) was already addressed in the specification.

The Working Group decided during the September 2001 face-to-face meeting to create a "none actor". See resolution text.

72Spec808DesignClosedmnot@akamai.com
Title: (Req Met)PI generation of error/status messages
Description: [email] SOAP provides error and status reporting through SOAP Faults The 'faultactor' subelement satisfies this requirement. See notes in R806 regarding the value of this element. Also, it should be noted that the mechanism for communicating a SOAP Fault is necessarily transport binding-dependent.
Proposal: Requirement Met
Resolution: The WG accepts the commentators assertion that the 'faultactor' element satisfies this requirement.
73Spec802envDesignClosedMark NottinghamMark Nottingham
Title: Identifying blocks for i/mediaries
Description: [email] SOAP does not explicitly address this requirement, but it should be addressed by the 'actor' attribute, in that XP Blocks which were not targetted could be skipped over, depending on the processor implementation.
Proposal:

From Mark: This issue is a little fuzzy, in that there was debate of the meaning of 'processing'. Despite this, this requirement seems to be met by the current envelope and processing model; suggest it be considered resolved.

Resolution: From the resolution text: The working group has closed issue 73, as the requirement is satisfied by the current design of SOAP, in particular the Header/Body distinction.
77Specn/aenvDesignClosedAndy NeilsonMark Nottingham
Title: handling midstream errors
Description: What happens when a response turns bad midstream? What are the possible ways to handle this?
Proposal:

This issue seems to be a combination of issue 12 (status codes) and clarification of when it's appropriate to use a Fault.

Resolution: After discussion, the Working Group has decided that the text in the current draft is sufficient to address this problem without specifically calling it out, as SOAP requires Faults to be represented in certain ways, and for message processing to occur in the manner specified. SOAP applications which encounter recoverable errors (e.g., a missing row in a database) should define conventions that indicate them without the use of Faults. [resolution text]
78Specn/arpcDesignClosed sfell@streetfusion.comFrank DeRose
Title: ordering of structs
Description: [ email ] Clarification on how to use the SOAP root attribute. See thread on soapbuilders

Will likely be considered in conjunction with issue 16

Proposal: [email]
Resolution:
 We rephrase the long paragraph in section 3.7  into:
 >>The root attribute information item is used to mark element
information items that are true roots of a serialised graph.  
Element information items that are true roots MUST be labelled
with a root attribute information item with a logical value of
"true". If the attribute information item is missing or has the
value of "false", the element is not a true serialization root.<<

 In section 4.1  - RPC and SOAP Body says that "the
invocation is viewed as a single struct" and "the response is
viewed as a single struct". We will make it more explicit:
 >>The invocation and response structs are the only true
serialization roots.<<
[email]
79Specn/aDesignClosed
Title:
Description: [ email ] Use of actors, mustUnderstand, and faults. Part of a long discussion on soapbilders
Proposal:
Resolution: Split into issues 99 and 100
80AMn/aDesignClosed skw@hplb.hpl.hp.comwsadiq@vitria.com
Title:
Description: The AM doc states that the relationship between targeting XML protocol blocks and XML message routing is still an area of significant debate
Proposal:
Resolution: The first two issues are called out in the AM doc issues section, the group felt these issues needed to be brought back to the WG, they are unassigned. Issue 1 refers to the debate about the role of targeting blocks/processing WITHIN the envelope, and whether routing is a function handled within the envelope or not. How does routing happen? Waqar - commented, volunteered. See response
81AMn/aDesignClosed skw@hplb.hpl.hp.com jones@research.att.com
Title:
Description: The AM doc states that the terms XML protocol module and XML protocol handler continues to be problematic along with the model for mechanism to dispatch XML protocol blocks to the appropriate entity.
Proposal:
Resolution: Discussion from last week may have resolved issue 2. He will clarify enough for AM spec to reach publication.
82Specn/aenvDesignClosedMark JonesMark Jones
Title: Header/block distinction
Description: [email, email, email, email, email, email, email] Not so much an AM issue as a design issue, but there are threads having to do with whether the design should syntactically separate Header and Body blocks or allow them to be intermingled as they are generated (e.g., in a common Blocks element). SOAP does the former; there were several messages that offered support for the latter. The bifurcation of blocks has consequences for serialization of inserted blocks by multiple handlers in a sender or in a receiver for the reply message; buffering may be required. There are usage scenarios (e.g., S21) which emphasize the need for incremental generation and processing of messages, particularly for memory-limited devices. On the other hand, R802 says that intermediaries should be able "to locate and process blocks intended for them without processing the entire message". This might imply a Header and Body organization or some other mechanism for locating appropriate blocks.
Proposal: Requirements R307 and R308 call for simplicity, which would argue for eliminating a distinction between header and body blocks if one is not warranted. This is particularly true if that distinction poses a problem for resource-constrained devices, which requirement R309 reminds us to consider and which are implicated in usage scenario S21. Furthermore, the Abstract Model currently makes no semantic distinction between header and body blocks. The primary support for maintaining a distinction comes from requirement R802 and existing practice in SOAP 1.1. A workaround exists for memory-limited handlers/processors that need to produce intermingled header and body blocks. The body blocks can instead be produced as header blocks and then referenced in a later small body block. This has the drawback that the large body blocks in the header may not be easily skipped by intermediaries, which re-raises the R802 problem again. It is recommended that the design activity reconsider the SOAP 1.1 syntax for header and body blocks in light of the above issues.
Resolution:

On today's conference call, the XMLP WG voted to close issue 82 [1] according to the resolution proposed in [2].

[email]
83AMn/aDesignClosed NAKAMURY@jp.ibm.comvidur@netscape.com
Title:
Description: [ email , email ] The AM doesn't say anything about message construction. For example, when a handler inserts a block, can it specify where to insert it in the message? Also, the XMLP_UnitData.send primitive takes a Message as an argument. Must the message be fully formed in advance or can it be generated on the fly?
Proposal:
Resolution: See response on list
84AMn/aDesignClosed moreau@crf.canon.fr jones@research.att.com
Title:
Description: [ email ] Suggestion to make discussion in section 4.2 more abstract
Proposal:
Resolution:
85AMn/aEditorialClosed moreau@crf.canon.fr jones@research.att.com
Title:
Description: [ email , email ] Editorial suggestions regarding figures and textual ordering.
Proposal:
Resolution: Mark volunteers to take this issue, STUART may have already have a resolution
86AMn/aDesignClosedChris FerrisHenrik Frystyk Nielsen
Title: Recipients of intermediates' faults
Description: [email, email] Should faults that arise from blocks which are introduced by intermediaries be reported to the intermediary or to the sender?
Proposal: Paul/Henrik to write up an explanation of the "out of scope" resolution to this issue
Resolution:
The XMLP WG decided to close issue 86 you raised with no action
taken.  The AM is now a Working Draft no longer in development.  Refinement
of the AM to detail fault handling in intermediate scenarios is therefore
not in the WG's current scope of work.
    
[email]
87AMn/aEditorialClosedChris FerrisStuart Williams
Title: Clarify correlation message reference parm
Description: [email, email, email, email, email, email] There is unclarity in the definition of the Correlation.MessageRef parameter and how to interpret it.
Proposal: Stuart to perform editorial clarification for .messageref parameter desc.
Resolution:
The XMLP WG decided to close issue 87 with no action taken.  The AM
is now a Working Draft no longer in development.  Refinement of the AM is
therefore not in the WG's current scope of work.
	
88AMn/aEditorialClosed chris.ferris@east.sun.com jones@research.att.com
Title:
Description: [ email , ] Section 4.2 needs to more precisely define what it means to "process" a block. Also, clarify "terminate processing" in concept #7.
Proposal:
Resolution:
89AMn/aEditorialClosedChris FerrisMarc Hadley
Title: Reconcile correlation descriptions
Description: [email, email, email, email] Is the correlation in section 5 the same as in section 3? Section 5.3 needs to clean up the description of OP, MSG and ERR. The nesting of bindings needs to be described more fully.
Proposal:
Resolution:
The XMLP WG decided to close issue 89 you raised with no action
taken.  The AM is now a Working Draft no longer in development.  Refinement
of the AM is therefore not in the WG's current scope of work.
    
[email]
90AMn/aDesignClosedRay DenenbergRay Whitmer
Title: Is response required for UnitData?
Description: [email, email] Is a "response-required" parameter needed for UnitData?
Proposal: David/Mark call for clarification on this issue, it is from Ray. Ray - I felt that it might be a weakness in the model to abandon guidelines for request/response actions to model RPC and other messaging patterns, there is no explicit RPC support through the description of the unitdata primitives only, aside from correlation and causality (one message arises as a result of another.) This does not encompass the deterministic nature of RPC, where if you send a request, you MUST have a CORRESPONDING RESPONSE, or you have no RPC. The XMLP layer does not have any way of requiring a resultant message. Henrik - you could have semantics requiring a non 1-to-1 message exchange requirement, or any open ended requirement structure. It would be a high level function to REQUIRE resultant messages. Ray - the XMLP layer is not "aware" of such requirements, it does not know. Henrik - the semantic of the application knows. Ray - then XMLP does not know whether to keep the connection open, for example. David F. - Doesn't RPC sit "above" XMLP? Henrik - we decided that RPC is a module, no? David F. - who will own this? Ray - I can own this.
Resolution:
The XMLP WG decided to close issue 90 you raised with no further
action.  The Abstract Model  is now a Working Draft no longer in
development, with further refinement of the AM not in the WG's current
scope of work. Further, the XMLP_UnitData Operation construct predated MEPs
and is not incorporated into SOAP 1.2, which does not define the protocol
service layer.
    
[email]
91AMn/aEditorialClosed NAKAMURY@jp.ibm.com jones@research.att.com
Title:
Description: [ email ] Section 4 variously talks about blocks targetted at handlers and at processors. The terminology needs to be reconciled within the document and with the revised glossary definitions approved in the April 4 telcon.
Proposal:
Resolution:
92AMn/aEditorialClosed NAKAMURY@jp.ibm.com jones@research.att.com
Title:
Description: [ email ] How does Handler d at an intermediiary in Figure 2.1 get invoked? It is not associated with any block in the message.
Proposal:
Resolution:
93Specn/aenvDesignClosedPaul KulchenkoDoug Davis
Title: mU at client
Description: [email] mustUnderstand on client side. See also thread
Proposal:

See Doug's proposal.

Resolution: See the resolution text:
It is believed that the processing model clearly states what the
client should do - it must process the incoming message (from the
server) according to the SOAP processing model - which will include
noticing and correctly processing MU headers.  If there is an error
then a Fault MUST be generated - the spec is, for the most part,
silent on what happens with the Fault since that will be a choice
based on the application semantics and the Transport Binding.  The
spec does talk about it in specific cases, like the server side of
RPC [2], but you asked about the client side.  8-)
94Specn/aEditorialClosed frystyk@microsoft.com marting@develop.com
Title: typos
Description: Typo in example in SOAP/1.1 section 5.4.2
Proposal:
Resolution: Update completed in SOAP 1.2 WD, July 9, 2001
95Specn/abindDesignClosedHenrik Frystyk NielsenHenrik Frystyk Nielsen
Title: SOAPAction header
Description: [email, email, email] Use of the SOAPAction Header field. There has been several discussion on the lists regarding the use of SOAPAction header field. This issue is to ensure that we clarify the use of the header field in the spec
Proposal: See proposal.
Resolution: The Working Group decided during the September 2001 face-to-face meeting to integrate the following text in the specification:
(part 2) 6.1.1 The SOAPAction HTTP Request Header Field

   Some  SOAP Receivers using this binding might need certain information
   to  be  readily available within the underlying protocol. This binding
   uses   the  SOAPAction  HTTP  request  header  field  to  supply  this
   information.
     
   soapaction = "SOAPAction" ":" <"> URI-reference <">
     
   The  value  of  this  request  header  field can be any URI reference,
   including  absolute  URIs  and  relative  URIs,  in  which  case it is
   interpreted relative to the Request-URI.
   
   SOAPAction's  presence in this binding's request messages is OPTIONAL.
   SOAP Receivers MAY use it as a hint to optimise processing, but SHOULD
   NOT require its presence in order to operate.
   
   If  a  SOAP  Receiver  does  require SOAPAction's presence in order to
   operate,   it  MUST  respond  to  requests  which  either  contain  an
   unrecognised  SOAPAction  header  value or do not contain a SOAPAction
   header  with  a  427  "SOAPAction Required" HTTP response status code.
   Such  response  messages  MAY  contain  a  'Required-SOAPAction'  HTTP
   response header field, whose value is the URI which can be used in the
   SOAPAction request header field to re-submit the request.
   
   req-soapaction = 'Required-SOAPAction' ":" <"> URI-reference <">
                                       
   Support for SOAPAction is OPTIONAL in implementations. Implementations
   SHOULD   NOT  generate  or  require  SOAPAction  UNLESS  they  have  a
   particular  purpose for doing so (e.g., a SOAP Receivers specifies its
   use).

See resolution text and its explanation.

96AMn/aDesignClosedStuart Williams
Title: Map AM to SOAP 1.1, Reqs
Description: The Subgroup feels that the Abstract Model should be mapped against the various scenario's presented in the requirements document and against the SOAP 1.1 and SOAP with Attachments Notes. This work is in progress but has not been completed.
Proposal:
Resolution:
The XMLP WG decided to close issue 96 you raised with no further
action.  The AM is now a Working Draft no longer in development.  Mapping
the XMLP requirements, SOAP 1.1 and SWA to the AM is therefore not in the
WG's current scope of work.
    
[email]
97Specn/aencDesignClosedAndrew LaymanETF
Title: echo base64
Description: [email] Remove discrepancy between SOAP/1.1's description of base64 encoded binary data (the comment regarding line length) and the latest XML Schema spec
Proposal:
Resolution: SOAP Encoding embraces base64 type as defined in XML Schema - Datatypes together with the errata to the document. [email]
98Spec811envDesignClosedtexin@progress.com david.clay@oracle.com
Title: content based routing
Description: [ email ] Content based routing of unormalized payloads. For example, if it is needed to specify that any payload that includes the term FOO-BAR be sent to a particular location, and if the payloads can contain unnormalized variations of FOO-BAR, then some of the payloads may not be routed to the right places. (At least by some definitions.
Proposal:
Resolution: Routing is not within the scope of SOAP 1.2, but can specified using the extension mechanisms provided by SOAP 1.2. If normalization is required for content-based routing extensions to work properly, then the specifications for content-based routing extensions must ensure normalization. This appears to be feasible by defining a SOAP header block (with mustUnderstand="true") whose semantics would imply that the SOAP envelope (and its descendants) be normalized before applying a content-based routing function. In addition, a related extension feature could use a SOAP header block to indicate explicitly that a SOAP envelope has not yet been normalized; such a header block can be removed after the envelope has been normalized. To reiterate, extensions for routing and normalization are not within the scope of the SOAP 1.2 specifications. [email]
99Specn/aenvDesignClosed gdaniels@macromedia.com gdaniels@macromedia.com
Title: detail returned from mU fault
Description: [ email ]The SOAP spec indicates that a processor must return a MustUnderstand fault if it does not understand any headers marked mustUnderstand="1". However, it does not go into any further detail about the structure or content of the fault information, except for stating that the "detail" element may NOT be used to convey information about header-related faults.
Proposal: The normative "Misunderstood" header in SOAP 1.2 fully resolves issue 99.
Resolution: The XMLP WG accepted this resolution [minutes]
100Specn/aenvDesignClosed gdaniels@macromedia.com gdaniels@macromedia.com
Title: scope of mU
Description: There are two proposed processing models here. In the first, the processor receives a message, decides which pieces are for them (via the actor attribute and some magic which lets them know out-of-band whether or not they are an intermediary or the ultimate destination), and then applies the rest of the SOAP semantics (mustUnderstand in particular) to ONLY those pieces. For this model, no fault will occur if a mustUnderstand header for some other actor arrives at the endpoint. In the second model, an ultimate destination should do a consistency check to make sure all extension contracts were fulfilled before the message arrived there. If it sees a mustUnderstand header for some other actor, it should fault. The viewpoints on this seem to coalesce to these two:
  • 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.
Note that this discussion gets pretty quickly into the distinction between targeting and routing, the function of the mustUnderstand attribute, and potentially other issues.
Proposal:

See Hugo's tracking on August 27th.

Resolution: The originator proposed a rewording to address the issue which was incorporated in the specification (see Hugo's tracking on August 27th). [closure notification]
101Specn/aenvDesignClosedNoah_Mendelsohn@lotus.com
Title: Special status of body
Description: SOAP Spec: 4.3.1 Relationship between SOAP Header and Body [email] SOAP implies that Body is just syntactic sugar for a header entry with no actor, but there is some implication that Body is the preferred way of carrying whichever request represents the primary function of the message. Some clarification may be useful. For example, if multiple headers are sent to the default actor, is there any defined processing order relative to the body? If a header calls for "logging", for example, can it be processed after the body itself?

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

Proposal: See the proposed solution and its revised version.
Resolution: Issue has been closed during the 05/12/2001 teleconference with the proposed text from Noah [email]
102Specn/aenvDesignClosedNoah_Mendelsohn@lotus.comTBTF
Title: Clarify rules for delivering fault messages
Description: SOAP Spec: 4.4 SOAP Fault [email] SOAP very clearly indicates situations in which a fault must be generated, but only sometimes is it clear whether and how and to whom to deliver the fault. Some of that looseness is intentional, but more clarity is needed in the explanation. (see fuller analysis in the document attached to the referenced e-mail.)
Proposal:
Resolution: During the W3C XMLP-WG tecon on 13-Feb-2002 the WG resolved to close issue 102 with the resolution proposed in [1], which proposed the following amendment to SOAP Part 1 Section 5.3 "Binding Framework" [2]: The third item in the number list Section 5.3 be amended as follows: <proposedText> 3. The information transmitted from node to node, and in the case of MEPs, any requirements to generate additional messages (such as responses to requests in a request/response MEP)>> and rules for the delivery or other disposition of SOAP faults generated during the operation of the MEP<<. </proposedText> We trust that this resolution now close Issue 102. [email]
103Specn/aenvDesignClosedNoah_Mendelsohn@lotus.comTBTF
Title: Precisely describe message path semantics
Description: SOAP Spec: 2. The SOAP Message Exchange Model [email] The SOAP specification says: "Regardless of the protocol to which SOAP is bound, messages are routed along a so-called "message path", which allows for processing at one or more intermediate nodes in addition to the ultimate destination." As discussed in the referenced e-mail, "SOAP does refer to a message path, which appears to be post facto the ordered locations and processing (there is vagueness here) that actually were visited in processing the message. There is at least an attempt to associate special behavior with the "end" of the path, where header entries with no actor are processed. The details of all this need to be stated more precisely." This is related to the suggestion that the notion of message pattern (e.g. request/response) also be clarified. This issue needs to be revisited after TBTF concludes its work
Proposal:
Resolution:
The introductory paragraphs of section 2 in will be rewritten as:

SOAP provides a distributed processing model that assumes that a SOAP
message originates at an initial SOAP sender and is sent to an ultimate
SOAP receiver via zero or more SOAP intermediaries.

The SOAP distributed processing model can support many message exchange
patterns including but not limited to one-way messages, request/response
interactions, and peer-to-peer conversations.

This section defines the SOAP distributed processing model. Section 5
defines a framework for describing how message exchange patterns as well
as additional features such as routing, reliability and security
interact with the distributed processing model.

In addition, there are some minor changes in the terminology section:

1) In the definition of "SOAP message path" replace "the ultimate SOAP
receiver" with "an ultimate SOAP receiver" resulting in:

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

2) In the definition of "SOAP intermediary" replace "towards the
ultimate" with "towards an ultimate" resulting in:

A SOAP intermediary is both a SOAP receiver and a SOAP sender and is
target-able from within a SOAP message. It processes a defined set of
SOAP header blocks in a SOAP message along a SOAP message path. It acts
in order to forward the SOAP message towards an ultimate SOAP receiver.

3) In the definition of "Ultimate SOAP receiver", remove the first
sentence and modify resulting in the following text:

The ultimate SOAP receiver is responsible for processing the contents of
the SOAP body. Normally the ultimate receiver is the last SOAP node
along the SOAP message path. As described in section 2, a SOAP ultimate
receiver cannot also be a SOAP intermediary. In certain circumstances, a
SOAP message may not reach the ultimate recipient because of a SOAP
fault generated by a SOAP node along the SOAP message path.
[email]
104Specn/aenvDesignClosedNoah Mendelsohn
Title: Use Infoset to define messages?
Description: SOAP Spec: 4. SOAP Envelope [email] >(this may be a bit more than a clarification) The SOAP specification currently says that "A SOAP message is an XML document that consists of a mandatory SOAP envelope...". There may be advantages to a formulation along the lines of: "Each SOAP message is defined as an XML document Infoset. Although many bindings, such as the HTTP binding provided herein, will use the serialized form of XML provided by the XML 1.0 Recommendations as augmented by the Namespaces recommendation, other bindings can adopt other serializations. In other words: this specification describes each message in the form of abstract XML Element and Attribute information items. Many protocol bindings will transmit this information in the form of the corresponding XML 1.0 documents, but other on-the-wire representations can be used by particular bindings if desired. For example, some bindings may use compressed representations."
Proposal: See proposed resolution text accepted by the originator.
Resolution: See resolution text: SOAP Version 1.2 Part 1 provides an Infoset definition of the SOAP Envelope.
105Specn/aenvDesignClosedNoah_Mendelsohn@lotus.comTBTF
Title: Clarify message patterns (e.g. Request/Response)
Description: SOAP Spec: 2. The SOAP Message Exchange Model [email]

(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.
Proposal: Proposition is to close this issue and focus on fault handling, which is a dupe of #102
Resolution: Issue 105 discusses certain ambiguities in SOAP 1.1 relating to message patterns such as request/response, one-way, etc. For example, in SOAP 1.1 it is unclear whether a non-RPC message could be sent as an HTTP response. An overalapping issue 102 questions the rules for delivering faults, and suggests that the answer may depend on message patterns. SOAP 1.2 introduces a formal notion of message pattern and clarifies its relation to bindings. The specific question of faults has not yet been considered in detail. Accordingly, the WG proposes to close issue 105 and leave issue 102 open. The WG believes that, with the exception of the fault-related questions raised in 102, issue 105 has been addressed by the latest published WD. [email, email]
106Specn/aenvDesignClosedNoah_Mendelsohn@lotus.com
Title: Check all must understands first & process atomically?
Description: SOAP Spec: 4.2.3 SOAP mustUnderstand Attribute SOAP Spec: 2. The SOAP Message Exchange Model [emailemail] Various readers of the SOAP specification have interpreted it to say either (1) a given actor must check that it understands all mustUnderstand headers before attempting any processing and must roll back any side effects of early MU headers if later ones fail due to application level problems or (2) that MU headers can be discovered, processed, and checked individually. Not only does this require clarification, it seems to affect the suitability of MU as the basis for certain extension features (i.e. those which must be noticed before other features are used).
Proposal: The SOAP processing model states that a SOAP node's processing of the MU checks needs to "appear" to be done before any processing occurs [1]. This is to guarantee that no undesirable side-effects will occur as a result of noticing an unknown MU header too late.
Resolution: The XMLP WG accepts the proposal [minutes]
107Specn/aenvDesignClosedNoah MendelsohnHugo Haas
Title: Clarify the terms application, actor & related notions of identity.
Description: SOAP Spec: 4.2.2 SOAP actor Attribute SOAP Spec: 2. The SOAP Message Exchange Model [email]

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?

Proposal:

A proposal was put forward by Eric Jenkins [email] in reference to SOAP 1.2, 9 July 2001 WD to wrap up resolution of the issue. In summary:

(i) change section 4.2, 3rd encoding rule to read "The SOAP actor attribute (see section 4.2.2) and SOAP mustUnderstand attribute (see section 4.2.3) MAY be used to indicate which SOAP module will process the SOAP header block, and how it will be processed (see section 4.2.1) respectively."

(ii) add the following sentence to the end of section 4.2.2 "The processing rules regarding mustUnderstand and the generation of faults apply to all headers, whether the ACTOR is implicitly or explicitly defined, and whether or not the ACTOR value is user-created."

(iii) add the following sentence to the end of the last paragraph in section 2.2 "There are no restrictions on the URIs that may be used as the value of an ACTOR attribute, other than those implied by the use of the special SOAP actor named "http://www.w3.org/2001/06/soap-envelope/actor/next".

(iv) add the following sentence to section 2.2 (at the end of paragraph 1 ?) "Any SOAP node, even the ultimate SOAP receiver, may be addressed by a user-created SOAP actor name."

Eric asked whether there should not be a better defn of "SOAP application". He took an action to propose such a defn.

The XMLP WG decided, (using numbering schema in proposal, above): (i) accepted, (ii) will be covered by editor's resolution of sections 2 and 4.2.2 overlap, (iii) as (ii), (iv)rejected

See Hugo's tracking on August 27th and status enquiry.

Resolution:

The modifications done by the Working Group in sections 2 and 4.2.2 address this issue. The crafting of a new definition of "SOAP Application" is being address in issue 139.

Issue 107 has therefore been closed. [resolution text]

108Specn/aenvDesignClosedSpec Editors
Title: QName sufficiency for understanding
Description: Should we specifically state that the determination of whether a SOAP node understands a block is made purely based on the entry QNAME, or should we leave it flexible.
Proposal:
Resolution: Issue 108 has been addressed by the following text in section 2.4 of the SOAP 1.2 spec: "It is likely that specifications for a wide variety of header functions will be developed over time, and that each SOAP node MAY include the software necessary to implement one or more such extensions. A SOAP header block is said to be understood by a SOAP node if the software at that SOAP node has been written to fully conform to and implement the semantics conveyed by the combination of local name and namespace name of the outer-most element information item of that block." [email]
109Specn/abindDesignClosedChris Ferris
Title: HTTP Extension Framework
Description: The specification preserves the HTTP Extension Framework binding although it is an experimental specification of the IETF with no standing. I'd like to see this binding removed as I believe that it has the potential for creating interoperability problems.
Proposal:

See Hugo's tracking on August 27th.

Resolution: The HTTP Extension Framework section has been removed from the specification. [closure notification]
110Specn/aEditorialClosedSpec EditorsEditors
Title: Normative & Non-Normative sections in the spec
Description: The specifications make little or no distinction between what is normative and what is not. A W3C specification must make this distinction.
Proposal:
The editors' revision of the SOAP 1.2 spec provides the following in
order to distinguish between what is normative and what is not:

1) All examples are explicitly marked as examples

2) Sections that are non-normative are marked as such in the section
heading

3) The sections "Notational Conventions" [1][2] contains the paragraph:

        With the exception of examples and sections explicitly
        marked as "Non-Normative", all parts of this
        specification are normative.
[email]
Resolution: The WG today decided to accept this proposal as resolution to issue 110 (how to distinguish normative and non-normative parts of the spec). [email]
111Specn/afaultDesignClosedSpec Editors
Title: Open/closed content model for fault element
Description: The SOAP/1.1 schema defined a closed content model for the fault element:
<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>
However the prose in section 4.4 describes it as an open content model "Other Fault subelements MAY be present, provided they are namespace-qualified". The issue is whether the content model should be open or closed.
Proposal:

See Hugo's tracking on August 27th.

Resolution: [resolution] A closed model was chosen. from the specification. [closure notification]
112Specn/afaultDesignClosedRPC task force of XMLP Working Group
Title: Encoding faultcode
Description: Should there be a faultcode for situations in which a receiver does not understand the encoding of a message> See for example email
Proposal:

See the proposed resolution.

Resolution:

The SOAP Version 1.2 specification resolves this issue by defining a DataEncodingUnknown fault. [resolution text]

113Specn/arpcdesignClosedStuart WilliamsRPCTF
Title: representing void returns in presence* of parms
Description:

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)?"

Proposal:
Resolution:
 In a nut shell, the following explanation and the examples below captures
the resolution. For more details, read this message.

 The existence of a return value is signified by the presence of a
namespace-qualified accessor named 'result' with the namespace identifier
"<http://www.w3.org/2001/12/soap-rpc>" and void returns are not expected to
have the above named accessor. 
[email]
114Specn/aEditorialClosedYasser Shohoud
Title: Specification uses xsi:null="1" instead of xsi:nil="true"
Description: See email. Also reported by Paul Kuchenko.
Proposal:
Resolution: Fixed in the editors' copy. [resolution]
115Specn/aEditorialClosedPaul Kulchenko
Title: Specification only allows mustUnderstand=1/0
Description: See email: mustUnderstand is fixed to allow '1/0/true/false' (boolean in schema), but specification explicitly says only about '1' and '0'. Also reported by Hugo Haas.
Proposal:

Appears to be fixed in the latest editors' copy (Hugo)

See Hugo's tracking on August 27th.

Resolution: This has been fixed in the specification. [closure notification]
116Specn/aEditorialClosedPaul Kulchenko
Title: Example 7 specifies faultcode as Name instead of QName
Description: See email.
Proposal: Should be env:MustUnderstand instead of MustUnderstand. See Gudge's response.
Resolution: Fixed in the editors' copy. [resolution]
117Specn/aencEditorialClosedPaul KulchenkoETF
Title: Clarification of the use of enc:offset and enc:position
Description: See email: 5.1.8 says: 'A SOAP array member MAY contain a "enc:offset"' and use enc:offset and enc:position in the same context, whereas refers to [5.4.2.1 Partially Transmitted Arrays] which says about enc:offset on Array element itself. Schema shows enc:offset on Array element also.
Proposal: See Gudge's response and Paul Kuchenko's reply.
Resolution: The issue #117 about the need for clarification of use of attributes enc:position and enc:offset is closed because the accepted resolution to issue #144 removes these attributes. [email]
118Specn/aEditorialClosedPaul Kulchenko
Title: Specification only allows root=1/0
Description: See email.
Proposal:

Appears to be fixed in the latest editors' copy (Hugo)

See Hugo's tracking on August 27th. Clarification still needed.

Resolution: This has been fixed in the specification. [closure notification]
119Specn/aEditorialClosedPaul KulchenkoEditors
Title: Upgrade extension example request
Description: See email: Appendix C says: 'The upgrade extension contains an ordered list of namespace identifiers of SOAP envelopes that the SOAP node supports in the order most to least preferred.', but doesn't give any examples on how to do it for more than one envelope supported and I can't figure it out from the text.
Proposal:
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email]
120Specn/aEditorialClosedPaul KulchenkoEditors
Title: Schema changes incomplete: change from ur-type to anyType missing
Description: See email: D.2 Schema changes doesn't reflect changes from ut-type to anyType (anySimpleType).
Proposal: See Gudge's response: The ur-type didn't change. All that happened was the schema-for-schemas now has a definition of the ur-type called 'anyType'. That said I should have noted in the table that the element decl and complex type named 'ur-type' had been replaced with an element decl called 'anyType'.
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email]
121Specn/aenvEditorialClosedPaul Kulchenko
Title: Clarification of the meaning of 'top level of serialization'
Description: See email: There is no definition of "top level of serialization" and maybe it's a common term, but I couldn't find it and spec doesn't have any examples on multiref serialization. There should be at least one (better two, one of them should show multirefs shared between Header and Body).
Proposal: Looks like a duplicate of issue 18. (Hugo)
Resolution: This issue is a duplicate of issue 18.
122Specn/aEditorialClosedFennivelHugo Haas
Title: Missing reference to augmented Backus-Naur Form (BNF)
Description: See email: 1st. Section 1.2: "This specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2616 [5]." the reference is missing linked.
Proposal:

The reference *does* look ok. Should go back to the author (Hugo)

See Hugo's tracking on August 27th.

Asked for clarification; issue will be closed if no clarification is received.

Resolution: No clarification has been received. The Working Group has decided on the 5 September teleconference to close the issue. [resolution]
123Specn/aEditorialClosedFennivelHugo Haas
Title: Typo in section 1.3
Description: See email: 2nd. Section 1.3: the last notations should be "see section 6" instead of "see section section 6".
Proposal:

Seems to be fixed in the editors' copy (Hugo).

See Hugo's tracking on August 27th.

Resolution: Fixed in the specification. [closure notification]
124Specn/aEditorialClosedDavid Olson
Title: Error in example 31: Array containing other arrays
Description: See email: enc:arrayType="xs:string[2]" should be enc:arrayType="xs:string[3]".
Proposal:
Resolution:

Addressed in the editors' copy [resolution]

125Specn/aEditorialClosedOliver BeckerEditors
Title: Meaning of "SOAP"
Description: See email: is there intentionally no explanation of the acronym SOAP in this document?
Proposal:
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email]
126Specn/aEditorialClosedHugo HaasEditors
Title: Use of example.org for examples in the specification
Description: See email: It would be preferable to use www.example.org (or stockserver.example.org) instead of www.stockquoteserver.com.
Proposal: www.stockquoteserver.com was changed. http://electrocommerce.org/abc#MyMessage is still present [email].
Resolution: Resolution: The drafts have been updated accordingly.
127Specn/aEditorialClosedHugo HaasEditors
Title: Avoid the use of "we" in the specification
Description: See email: in section 2.3 and 2.4, "we" is used.
Proposal:
Resolution: Fixed in the editors' copy [resolution text].
128Specn/aEditorialClosedHugo HaasEditors
Title: Use more precise language in versioning model section
Description: See email: Since this section talks about versioning, I think that it should be clear that it talks about SOAP Version 1.2, especially because it mentions SOAP/1.1 [..].
Proposal:
Resolution: Fixed in the editors' copy [resolution text].
129Specn/aencEditorialClosedHugo HaasETF
Title: Section 5.1 Rules for Encoding Types in XML does not have any example
Description: See email.
Proposal:
Resolution: The WG has decided to close the issue 129 because while the first subsection of the Encoding section doesn't still have any examples, it's been considerably shortened by resolutions to other issues, therefore we feel that the examples present in the following subsections are adequate and sufficient. [email]
130Specn/afaultDesignClosedJacek Kopecky
Title: Extensibility of SOAP faults
Description: See email:
 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.

Proposal:
Resolution: The XML Protocol Working Group has resolved Issue 130, regarding the 'dot' notation in SOAP Fault codes by removing the 'dot' notation from the specification. Thus SOAP Fault codes as defined by the specification are simply QNames. Several such faults are defined in the spec e.g. {http://www.w3.org/2001/09/soap-envelope}VersionMismatch and {http://www.w3.org/2001/09/soap-envelope}MustUnderstand. The specification may define more fault codes than it does currently before reaching recommendation. [resolution text]
131Specn/abindDesignClosedNoah Mendelsohn
Title: Possible ambiguity regarding non-RPC responses in HTTP
Description: See email:
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.
Proposal:
Resolution: This issue requests clarification of the notions of "response" and "request/response". The WG believes that this is resolved by the inclusion on the latest wording drafts of a formal notion of message pattern and specifically the formalization of request/response as such a pattern. [email]
132Specn/aEditorialClosedJeff KrausEditors
Title: Typo in example 34: Schema fragment for array of phone numbers embedded in a struct
Description: See email:
It would appear that the accessor is "phoneNumbers" and not
    "phone-numbers" in the example introductory text.
Proposal:
Resolution:

Addressed in the editors' copy [resolution]

133Specn/aDesignClosedHugo Haas
Title: SOAP and the Web architecture
Description: See email:
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).

Proposal:
Resolution: The net of the resolution is: That the HTTP binding we offer in SOAP 1.2 Part 2 Adjuncts continue to use the HTTP POST method in the manner established in SOAP 1.1 and to note in the HTTP binding described in part 2: 1) that the HTTP binding in Part 2 Adjuncts is 'an' HTTP binding rather than 'the' HTTP binding and that our binding framework makes it is possible to define additional HTTP bindings. 2) that the HTTP binding that we define on Part 2 Adjuncts *can* be used in a manner that preserves POST semantics, but that it's up to the developer to use it that way. In addition, the WG resolved *not* to develop an HTTP binding that makes use of HTTP methods other than POST was part of its activity to deliver the SOAP 1.2 specification.
134Specn/aenvDesignClosedChris FerrisHugo Haas
Title: Support of XML Base / Use of relative URIs
Description:

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

Proposal:

See Noah's proposal and the discussion around it; continuation of the discussion.

Resolution: XML Base is fully supported by SOAP Version 1.2 [resolution text].
135Specn/aenvDesignClosedMark NottinghamHugo Haas
Title: Discarding incorrect namespaces / Envelopes without namespaces
Description: [email]:
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.
Proposal: This seems to have changed [email]. The Working Group needs to decide if it was/is desired.
Resolution: The use of MUST has been ratified by the Working Group and the use of a different namespace triggers a version mismatch fault. [resolution text]
136Specn/aEditorialClosedHugo HaasSpec Editors
Title: Misc editorial comments
Description: See email.
Proposal: Changes made to the editors' copy by Jean-Jacques.
Resolution: [email]
137Specn/aDesignClosedMark Jones
Title: Intermediaries relaying SOAP messages without modifying them
Description:

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.
Proposal:
Resolution: Issue 137 is closed with the proposed resolution. The resolution calls out two different types of intermediary which the working group believes addresses this issue. [email]
138Specn/abindDesignClosedMURATA Makoto
Title: Use of text/xml for SOAP is incorrect
Description:

[email]

See also the first discussion.

Proposal: See the discussion during the 17 October teleconference: not using text/xml anymore. See also the modification of the editors' copy of the spec. See a first reply to the originator.
Resolution: While the XML Protocol WG has not yet made a decision regarding the details of the internet media type(s) which may be used to describe a SOAP message, we have agreed that text/* types should not be used. [email]
139Specn/aEditorialClosedEric JenkinsChris Ferris
Title: Definition of SOAP Application
Description: Resolution of issue issue 107 showed that there is no definition of SOAP application in the specification [email]
Proposal: Chris and Eric have been instructed to come up with a definition of SOAP Application. See also a list of proposal.
Resolution: [resolution text] The following text was inserted in the specification (decision taken at the 10 October teleconference):
SOAP Application

A software entity that produces, consumes or otherwise acts upon
SOAP messages in a manner conforming to the SOAP process model.
140Specn/aenvDesignClosedStuart Williams
Title: How does a SOAP node determine if it is the anonymous actor?
Description: [email]: There is an assumption that with respect to a given message an SOAP Node is able to determine whether it plays the role of the default/anonymous actor. For other actors there is an explicit actor URI string on which to make the determination of whether you are that actor. WRT to the default/anon actor... there is *no* discussion of the basis on which a SOAP Node determines that it plays role of default/anon actor with resect to a given received message. It seems to me at the moment that this determination is currently (in the HTTP context) based on information *outside* the message.
Proposal:

See discussion.

Resolution: From the resolution text: This issue has be resolved with the proposal [2] to include the following text SOAP 1.2, Part 1, Section 2 (probably 2.2):
"Except for next, and none, etc. this specification does not prescribe the
criteria by which a given node determines the (possible empty) set of
roles in which it acts on a given message.  For example, implementations
can base this determination on factors including, but not limited to:
hardcoded choices in the implementation, information provided by the
transport binding (e.g. the URI to which the message was physically
delivered), configuration information made by users during system  
installation, etc. "

The issue about how an actor know how it is the ultimate decision is discussed in issue 146.

141Specn/aenvDesignClosedStuart Williams
Title: Body block elements may be namespace qualified (should be must?)
Description: [email]:
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.

Proposal:
Resolution: Resolution text: "SOAP body block element information items MUST be namespace qualified." an editorial note has been added to the specasking implementors for feedback on this change. [resolution email].
142Specn/aenvDesignClosedStuart WilliamsWG
Title: Namespace for SOAP fault codes
Description: [email]:
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?
Proposal:
Resolution: he editors believe that this issue has been dealt with as the section no longer contains the word 'method' or the sentence about namespaces. [email]
143Specn/aEditorialClosedStuart WilliamsEditors
Title: Use of 'Client' and 'Server' in section 4.4.1
Description:

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

Proposal: See discussion thread.
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email]
144Specn/aencDesignClosedJacek KopeckyETF
Title: Array information is not XML-ish
Description: [email] The arrayType, offset and position attributes' values are hiding non-atomic data (lists of numbers, type references) in a mangled form in a string.
Proposal:
Resolution: The issue #144 about the form of metainformation on SOAP Encoding arrays is being closed by accepting the rewrite in [1], amended by [2] and [3]. [email
145Specn/aenvEditorialClosedLarry MasinterEditors
Title: XML declarations in SOAP messages
Description: [email]: I'm not sure that the wording is precise enough to be unambiguous:
" A SOAP message SHOULD NOT contain processing
 instruction information items."
I cannot tell, from this statement, whether the (recommended) XML declaration is not recommended in SOAP messages. http://www.w3.org/TR/xml-infoset/#infoitem.pi says "The XML declaration and text declarations for external parsed entities are not considered processing instructions." even though syntactically XML 1.0 defines the "<?xml version="1.0"?>" as a processing instruction. (I think the idea is that the XML declaration is just omitted from the infoset, but this is probably an issue with the XML Infoset Proposed Recommendation).
Proposal: Duplicate of issue 10.
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email]
146Specn/aenvDesignClosedWorking Group
Title: Does a SOAP Message Path always terminate at the default actor, anonymous actor, ultimate recipient or SOAP endpoint?
Description: This issue originated from issue 140. See the October 10 teleconference minutes and the clarification by Stuart.
Proposal:
Resolution: The following text: "A SOAP Node that acts in the role of the anonymous actor with respect to a particular SOAP message becomes the ultimate recipient of that SOAP message. Such a SOAP node is responsible for processing all parts of the message intended for the anonymous actor, including the body, according to the rules described in this section. The SOAP message path for that message ends at the ultimate recipient. However, the ultimate recipient may delegate all or part of its responsibility to other entities. The ultimate recipient may happen to use distinct SOAP message exchanges to interact with such entities. Nevertheless, responsibility for the processing of parts of a SOAP message targetted at the anonymous actor rests with the ultimate recipient of that message" was inserted in the specification. [resolution text]
147Specn/aEditorialClosedDoug DavisEditors
Title: How part 2 is referred to from part 1
Description: [email] In part 1 we talk about what's in part 2 with very specific details - by that I mean we list the current set of items in there. It seems like it would be better to just say that there's a part 2 with additional/optional things - much like we just used the term "adjunts" instead of listing all of 'em.
Proposal:
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email]
148Specn/aEditorialClosedDoug DavisEditors
Title: Too detailed introduction
Description: [email] The last sentence of the intro states:
  These four parts are functionally orthogonal. In recognition
  of this, the envelope and the encoding rules are defined in
  different namespaces.
This seems out of place since we haven't talked about the role of namespaces yet so the reader will probably not get the point of it.
Proposal:
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email]
149Specn/aEditorialClosedDoug DavisEditors
Title: Refining the design goals text
Description: [email] 1.1 Design goals, IMHO, need a sentence stating that while these four items listed are not part of the spec, it is not because they can not be done, but rather are just outside the scope of the spec at this time. (maybe leave off "at this time"??)
Proposal:
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email]
150Specn/aEditorialClosedDoug DavisEditors
Title: Wording in section 1.3
Description: [email] Section 1.3: The header block contains the parameters... We can't call them 'parameters' that implies we know how they are used and we don't - perhaps "subelements" or "xml blocks" would be better.
Proposal:
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email]
151Specn/aenvEditorialClosedDoug DavisEditors
Title: Definition of SOAP Block
Description: [email] Do we want to limit this to just SOAP blocks? By that I mean just env, header and body and their immediate children or can any xml chunk (i.e. <foo> <bar/> </foo> = 2 SOAP blocks) be called "SOAP blocks" ? The definition of "SOAP Block" isn't clear to me.
Proposal:
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email]
152Specn/aenvEditorialClosedDoug DavisEditors
Title: Wording in the processing model
Description: [email] Section 2.1 - 2nd paragraph
  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.
Proposal:
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email]
153Specn/aEditorialClosedDoug DavisEditors
Title: Relationship between section 2.2. and section 4
Description: [email] Section 2.2 SOAP Actors and SOAP Nodes This section seems to be repeated in section 4 - do we really need both? I would be in favor of removing this section and leaving section 4.
Proposal: See editors' proposals.
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email]
154Specn/aDesignClosedDoug Davis
Title:
Description: [email]
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.
Proposal:
Resolution:
Section 2.6 of SOAP Version 1.2 Part 1 now states:

  "This section sets out the rules by which SOAP messages are processed. 
  Unless otherwise stated, processing must be semantically equivalent to 
  performing the following steps separately, and in the order given. Note 
  however that nothing in this specification should be taken to prevent 
  the use of optimistic concurrency, roll back, or other techniques that 
  might provide 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 the order shown below.

  1. Determine the set of roles in which the node is to act. The contents 
  of the SOAP envelope, including header blocks and the body, MAY be 
  inspected in making such determination."
  ...

Summarised, this resolution states that a node is explicitly allowed to
inspect the message contents when deciding on the set of roles it is to
play. A node is also allowed to change the set of roles it plays after
starting to process blocks provided that the outcome of this is
"semantically equivalent to performing the following steps separately,
and in the order given".
[email]
155Specn/aenvDesignClosedDoug Davis
Title: How to target blocks
Description: [email]
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.
Proposal:
Resolution: As described in 2 SOAP Message Exchange Model, not all parts of a SOAP message may be intented for the ultimate SOAP receiver. The actor attribute information item is to be used to indicate the SOAP node at which a particular SOAP header block is targeted. See the thread on xml-dist-app@w3.org
156Specn/aenvEditorialClosedDoug DavisEditors
Title: What does "fail" mean?
Description: [email]
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".
Proposal:
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email]
157Specn/aEditorialClosedDoug DavisEditors
Title: Section 2.4 wording
Description: [email]
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".
Proposal:
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email]
158Specn/aenvEditorialClosedDoug DavisEditors
Title: Section 2.5 wording
Description: [email]
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".
Proposal:
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email]
159Specn/aencDesignClosedDoug DavisETF
Title: Wording in section 4.1.1
Description: [email]
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.
Proposal:
Resolution: the XMLP WG has decided to close the issues #159 and #166 with the following resolution: In section 4.1.1 the paragraph before the example shall be changed to the following: "The encodingStyle attribute information item is of type anyURI in the namespace http://www.w3.org/2001/XMLSchema. Its value identifies a set of serialization rules that can be used to deserialize the SOAP message." The schema for SOAP Envelope shall be updated to reflect this. [email]
160Specn/aenvDesignClosedDoug Davis
Title: Clarification about the omission of the SOAP actor attribute
Description: [email]
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...
Proposal:
Resolution: Issue 160 has been addressed with the following proposal: Remove the text in question and keep section 4 primarily the infoset description of the envelope with a reference to section 2 for the specifics of how to use the "actor" attribute. [email]
161Specn/aencDesignClosedAsir S VedamuthuETF
Title: Array Member as an Independent Element
Description: Excerpt from the email:
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?
Proposal:
Resolution: The issue #161 about a possible misunderstanding of the array encoding rules is closed because the XMLP WG believes the issue is not anymore an issue after the rewrite of the text in resolution to issue #144. [email]
162Specn/aencEditorialClosedAsir S VedamuthuETF
Title: arrayType Production Rules
Description: [email]
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.
Proposal:
Resolution: The text which the issue is concerned about has been removed by the rewrite of array serialization that was accepted by the WG during the F2F meeting. [resolution text]
163SpecS21encDesignClosedAsir S VedamuthuETF
Title: Multi-reference 'id' attribute - NOT a real ID
Description: [email]
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.
Proposal:
 1) we have agreed in resolving issue 186 that we'll explicitly
define the uniqueness constraints on the attributes id and ref
(so yes, in implementations there will have to be code that
handles this), which makes us no longer dependent on XML Schema 
or DTD processing,
 2) point (b) is true for our ID as well as for the "real ID"  
and for every possibly-forward linking mechanism, and it is
therefore irrelevant to the issue of our ID not being a "real
ID".
[email]
Resolution: Summary of the resolution: in resolution to issue 186 we have agreed to add the description of constraints on the id and ref attributes which makes us independent of XML Schema or DTD processing. This does indeed mean that applications will probably get little support from existing XML processing libraries. [email]
164Specn/aencDesignClosedJacek KopeckyETF
Title: Describing arrays with XML Schema
Description: [email]
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.)
Proposal: "The WG has decided to keep the status quo as the issue is lessened by the resolution of issue 144 and the expected course of WSDL resulting thereof; and no other substantial need for in-spec specification of the mapping of SOAP Data Model schema to XML Schema has been presented." [email]
Resolution: The issue #164 is being closed by accepting the proposal and keeping the status-quo [email]
165Specn/aenvDesignClosedNoah Mendelsohn
Title: Deferencability of URIs
Description: [email]
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.
Proposal:
Resolution: Issue 165 was raised by me in anticipation of our need to consider architectures such as SOAP+Attachments. The underlying concern was that many SOAP messages will processed in environments which are disconnected, in the sense that much of the web is inaccessible. In such situations, many URI's will fail to resolve. Some proposed attachement architectures, such as SOAP+Attachments and DIME, exist to provide a means of carrying information that will be guaranteed available during processing of a SOAP message. The issue suggests that we need to provide an architectural framework that will clarify the means by which attachment (or other architectures) can establish that certain URI's (presumably those referencing attachments) WILL resolve during processing of a SOAP message. The XML Protocols workgroup proposes to consider the above concerns during the development of future versions of SOAP, and specifically to consider inclusion of attachment procesing in the next revision to the workgroup's charter. Accordingly, and because our existing charter doesn't specifically call for consideration of attachments, the workgroup proposes to close issue 165 without making any changes or additions to the SOAP 1.2 working drafts. [email]
166Specn/aencDesignClosedAsir S Vedamuthu
Title: Most to least specific encodingStyles, HOW?
Description: [email]
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.
Proposal:
Resolution: In section 4.1.1 the paragraph before the example shall be changed to the following: "The encodingStyle attribute information item is of type anyURI in the namespace http://www.w3.org/2001/XMLSchema. Its value identifies a set of serialization rules that can be used to deserialize the SOAP message." The schema for SOAP Envelope shall be updated to reflect this. [email]
167Specn/aencDesignClosedAsir S Vedamuthu
Title: Support for XML Schema Types
Description: [email]
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.
Proposal:
Resolution: Recent work on the SOAP Data Model and SOAP Encoding sections of Part 2 of the spec has clarified the relationship between SOAP and XML Schema by taking a layered approach. Part of this clarification concerns the meanign of xsi:type in the SOAP specification. The XML Protocol Working Group considers this issue to now be closed. If you disagree please let the Working Group know as soon as possible. [email]
168Specn/aencDesignClosedJacek KopeckyETF
Title: Type of referenced external data
Description: [email] When using the SOAP Encoding referencing mechanism, the hrefs can point to external data. What is the type of the data? Should it depend on the MIME type of the data? What if no MIME type is available for this resource? (I don't remember anything stating that data identified by a URI must have a MIME type.) NOTE: resolution of this issue is dependent on the resolution of issue 170
Proposal:
Resolution: The resolution is that we add a text into the encoding section (probably near the encoding rule #2) to this effect: "In case the receiving node cannot determine the xsi:type of a node, for example because it doesn't follow a schema during deserialization and the types are expressed in a schema, the node MAY generate a fault with the faultcode of env:Sender and the subcode of enc:UntypedValue." [email]
169Specn/aencDesignClosedJacek KopeckyETF
Title: Forward references
Description: [email] Some people felt forward references might be bad, other felt my original proposal disallowed forward references. I propose to keep forward references because they allow references from headers to body, which might be necessary for things like XMLDSIG, although any other referencing mechanism (most probably XML IDREF) could be used instead of SOAP Encoding referencing.
Proposal:
Resolution: the WG has decided to close the issue #169 by keeping the status quo - allowing forward references in the serialized form of data structures. The WG is of the opinion that this does not place an unnecessary burden on either the writers or readers of SOAP Encoded data structures.
170Specn/aencDesignClosedJacek KopeckyETF
Title: Referencing data that can be stripped out from the message
Description: [email] References from body to headers and references among headers may lead to situations where the referenced data is removed from the message. NOTE: resolution of issue 168 should be considered after resolution of this issue
Proposal:
Resolution: The XMLP Working Group has closed the issue 170 (referencing missing data) with the following text being incorporated in the spec: "When SOAP Encoding data is being deserialized and a reference to a missing ID is found, the application SHOULD generate a fault with faultcode env:Sender and subcode enc:MissingID." [email]
171Specn/aencDesignClosedJacek KopeckyETF
Title: attribute clashes on references
Description: [email] For illustration of the problem:
        <a foo="bar" id="1">blah</a>
        <b foo="baz" href="#1"/>
The problem is what is the value of b?
Proposal:
Resolution: The XML Protocol working group is closing issue 171 by adding the following text to part 2 of the SOAP 1.2 specification. " The serialization rules of SOAP permit the use of xsi:type attribute to represent the type of an element, and hence also the type of the corresponding graph node. The use of xsi:type to denote element types is described in XML Schema Structures [2]. Although SOAP does not mandate the use of any particular schema notation, all SOAP processors MUST recognize xsi:type references if present and MUST associate the corresponding type with the deserialized nodes. The use of xsi:type attribute on referencing accessors (I.e. those that use the href="..." construction) is subtle and it is recommended they be used with caution. Note that, per the rules of the XML Schema Specification for xsi:type, the existence of xsi:type attribute on referencing accessors does not indicate the type of the referred element, and hence does not affect the type of the corresponding node." " [email]
172Specn/afaultDesignClosedNoah Mendelsohn
Title: Version faults vs. client faults
Description: Issue 135 raised a general issue relating to faults. A thread of discussion led to tentative agreement among the correspondents that we should clarify the use of version vs. client faults in the particular case that incorrect namespace qualification is used in a SOAP envelope.
Proposal: "Once the receiver has established that the sender is sending a SOAP 1.2 envelope (by checking the namespace on the root element) then any malformation of the envelope would be a "Client" fault. This would include things like wrong element names, multiple "Header" or "Body" elements, etc."
Resolution: "Version mismatch faults are generated only if the root element namespace doesn't match. Client faults occur if the root element namespace is known, but there is any other "malformation" of the message structure (envelope not named "envelope", body or header missing, perhaps due to bad namespaces, etc.)" [resolution text]
173Specn/afaultDesignClosedHenrik Frystyk Nielsen
Title: Support for multiple fault codes
Description: How to support multiple fault codes The assumption is that we want a homogeneous mechanism for conveying multiple levels of fault codes. [email]
Proposal: base fault code which can be understood by all SOAP 1.2 nodes and one or more fault codes that are "application specific". This is likely to make life easier for general SOAP nodes and intermediaries. [email][dist-app thread]
Resolution: Closed with the adoption of a new schema for the structure of the env:Fault/faultcode element as described in xml-dist-app. [email]
174Specn/afaultDesignClosedNoah Mendelsohn
Title: simple type terminology for envelope attributes
Description: For envelope attributes, we should use the proper XML Schemas simple type terminology, carefully indicate when we are referring to lexical vs. value space, and if a subtype is used (e.g. a boolean that only accepts lexical form "1"), make clear that we are doing so. [email]
Proposal:
Resolution: "attributes in the SOAP envelope described by "Part 1: Framework" are are of types from XML Schema: Datatypes (e.g. mustUnderstand is a boolean). Unless otherwise stated, all lexical forms are supported for each such attribute, and lexical forms representing the same value in the XML Schema value space are considered equivalent for purposes of SOAP processing. Thus, the boolean lexical forms "1" and "true" [ref to boolean datatype in the schema spec] are interchangeable. For brevity, text in this specification refers only to one lexical form for each value (e.g. "if the value of mustUnderstand is "true"). Unless otherwise stated, such references implicitly cover all forms corresponding to the same value in the value space. See [email]
175Specn/afaultDesignClosedNoah Mendelsohn
Title: contradictory text regarding removal of blocks by intermediaries
Description: Section 2.6 of the latest editors' draft retains the text: "If the SOAP node is a SOAP intermediary, the SOAP message pattern and results of processing (e.g. no fault generated) MAY require that the SOAP message be sent further along the SOAP message path. Such relayed SOAP messages MUST contain all SOAP header blocks and the SOAP body from the original SOAP message, in the original order, except that SOAP header blocks targeted at the SOAP intermediary MUST be removed (such SOAP blocks are removed regardless of whether they were processed or ignored)." This is known to conflict with the ability to implement encrypting or compressing intermediaries; such intermediaries will presumably remove blocks NOT targeted to that intermediary, and do other seemingly prohibited manipulations. [email]
Proposal:
Resolution: Closed as duplicate of issue 137 [email]
176Specn/aencodingDesignClosedNoah Mendelsohn
Title: Canonicalization/rewrite of headers
Description: had assumed that a SOAP intermediary relaying an unprocessed header would preserve its contents character-for-character, probably including whitespace, but certainly preserving the exact form of attribute values, namespace prefices, etc. Henrik made the case that many SOAP processors will parse a message into abstract form, with the result that relayed headers may for example change: mustUnderstand="1" to mustUnderstand="true" Essentially, the question is how much of XML canonicalization may be done by an intermediary relaying a header [email]
Proposal:
Resolution:
The text outlined in [this message] was adopted as the resolution text to the issue
with proposed modifications by yourself and taking into account the
accepted resolution to issue 137. It should be noted that the mail
proposed resolution went through considerable discussion and was
discussed at the Feb 2002 WG f2f (to be posted).

At the f2f, the WG instructed the editors to exercise some amount of
editorial discretion in order to avoid duplication or requirements and
description of the SOAP message construct in general. 
[email]
177Specn/aencodingDesignClosed Jacek Kopecky
Title: missing elements same as nils?
Description: In SOAP Encoding in structures and in arrays, accessors can be omitted. The current WD says: (section 4.2, rule #9) "A NULL value or a default value MAY be represented by omission of the accessor element. A NULL value MAY also be indicated by an accessor element containing the attribute xsi:nil with value '1 or true' [...]" (section 4.5) "An omitted accessor element implies either a default value or that no value is known. The specifics depend on the accessor, method, and its context." This text applies to both arrays and structs. Wwhat does an omitted accessor really mean? [email]
Proposal:
Resolution: the issue 177 was closed with the resolution proposed in this message. The resolution is, in short, to simplify rule #8 in section 3.1 to only speak about NULL values, and to remove (or downgrade) section 3.6 which talks about default values. [email]
178Specn/ametaDesignClosedRaj Nair
Title: requirements imposed by end-to-end features
Description: Text is needed to clarify the requirements on binding imposed by end-to-end features. An example is an end-to-end security association that an intermediate node is not able to participate in. [email]
Proposal: (1) Noah proposed that we make it the responsibility of the next hop on the path of a message to ensure that the hop after it can support the feature; (2) Glen proposed that we specify text that limits the scope of the binding contract to each hop. (3) Raj had originally proposed text that requires an intermediary to generate a fault if it is not able to accept a SOAP message without violating existing end-to-end conditions of the message.
Resolution:
We delete the last sentence of the last paragraph in part 1, section
5.1 and add an explanatory note. The result is:

"The combination of the SOAP extensibility model and the SOAP binding
framework provides some flexibility in the way that particular features
can be expressed: they can be expressed entirely within the SOAP
envelope (as blocks), outside the envelope (typically in a manner that
is specific to the underlying protocol), or as a combination of such
expressions.

Note: Certain features may require end-to-end as opposed to hop-to-hop
processing semantics. While the 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. 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). It is recommended that, where practical, end-to-end
features be expressed as SOAP header blocks, so that SOAP's processing 
rules can be employed."
[email]
179Specn/ametaDesignClosedMarc Hadley
Title: One-way messaging in SOAP 1.2
Description: In Part 1, section 5.3 we find: "Every binding specification MUST support the transmission and processing of one-way messages as described in this specification. A binding specification MAY state that it supports additional features, in which case the binding specification MUST provide for maintaining state, performing processing, and transmitting information in a manner consistent with the specification for those features." This paragraph is potentially confusing, either we mean: (i) All bindings must support a one-way MEP, in which case there are two issues: (a) we currently don't define a one way MEP in the specification (b) the HTTP binding we do define doesn't support a one-way MEP or (my reading) (ii) All bindings must at a minimum define how to move a message from one node to another, in which case I would propose that we add a clarification along the lines of "Note, this does not mean that all bindings must support a one way MEP, only that they MUST define how to move a message from one SOAP node to another". [email]
Proposal:
Resolution: during the 25th-26th February face to face meeting, the XML Protocol WG has decided to close issue 179 [1] following the proposed text in this message with the exception that "MUST support" was changed to "MUST enable". [email]
180Specn/aRPCDesignClosedMartin Gudgin
Title: Parameter ordering in Section 4.1
Description: In the editors copy of Part 2[1], section 4.1[2] states of [in] and [in/out] parameters in the request that; 'These appear in the same order as in the procedure or method signature.' For [out] and [in/out] parameters in the response it states; 'The return value accessor SHOULD be first, followed by the accessors for the parameters which SHOULD be in the same order as they appear in the procedure or method signature.' Why the inconsistency? I think we should say the same thing for both request and response. I don't have a *strong* opinion about whether we should enforce order or not, but I'd tend to lean toward lining up the response description with the description of the request. [email]
Proposal:
Resolution: The XMLP WG has resolved to close issue 180 with this proposal. Briefly, this proposal states that RPC requests and responses can map parameters into struct or array accessors that provide access to parameter values by name or by position respectively. [email]
181Specn/aFaultDesignClosedJean-Jacques Moreau
Title: Incostitency between section 4.4.3 and section 2
Description: I think this whole discussion is pointing out an inconsistency between section 4.4.3 "SOAP faultactor Element" and section 2 (with or without the ed's proposed rewrite). Specifically, section 2 introduces the notion of roles, which nodes play. IMO, this section places a greater emphasis on roles than on nodes. In contrast, section 4.4.3 is mute about roles (see quote below), which I find quite disturbing since a node is allowed to play multiple roles. I would be tempted to say that the faultactor attribute really ought to identify not just the node that faulted (coarse-grained), but the exact role in which that node operated (fine-grained). "faultactor [...] is intended to provide information about which SOAP node on the SOAP message path caused the fault to happen [...]. It is similar to [...] SOAP actor [...] but instead of indicating the target of a SOAP header block, it indicates the source of the fault. The value of [...] faultactor [...] identifies the source of the fault. [email]
Proposal:
Resolution: Issue 181[1] is closed with this resolution text. Essentially the fault element now allows both faultactor and faultrole elements to be provided. [email]
182Specn/aFaultDesignClosedMarc Hadley
Title: Fault Code restriction
Description: Part 1, Section 2.6 contains the following paragraph: "If processing is unsuccessful, exactly one fault MUST be generated by the node. Header-related faults other than mustUnderstand faults (see 4.4 SOAP Fault) MUST be SOAP Sender or DataEncodingUnknown faults (see 4.4.5 SOAP Fault Codes) and MUST conform to the specification for the corresponding SOAP header block. Faults relating to the body MUST be SOAP Sender or DataEncodingUnknown faults (see 4.4.5 SOAP Fault Codes)." The restrictions on the type of faults that may be generated seems strange. E.g. why couldn't header processing lead to a Receiver fault (out of memory etc...). [email]
Proposal: "If processing is unsuccessful, exactly one fault MUST be generated by the node. Header-related faults other than mustUnderstand faults MUST conform to the specification for the corresponding SOAP header block."
Resolution:
During the W3C XMLP WG Telcon on 6th March 2002 the WG agreed to close
Issue 182 by making the amendment to Part 1 section 2.6 proposed by Marc
with final wording as amended by Stuart/Henrik in email and on the call to:

  "Failure is indicated by the generation of a fault.  SOAP message
   processing MAY result in the generation of at-most one fault.
   Header-related faults other than mustUnderstand faults  MUST conform to
   the specification for the corresponding SOAP header block."

[email]
183Specn/aenvDesignClosedHenrik Frystyk Nielsen
Title: Default values of SOAP header block attributes
Description: Section 4 defines the semantics of omitting both the actor/role attribute and the mustUnderstand attribute: 1) Section 4.2.2 says: "Omitting the SOAP actor attribute information item implicitly targets the SOAP header block at the ultimate SOAP receiver. An empty value for this attribute is equivalent to omitting the attribute completely, i.e. targeting the block at the ultimate SOAP recipient." 2) Section 4.2.3 says: "Omitting this attribute information item is defined as being semantically equivalent to including it with a value of "false"." However, neither of the statements above provides any guidance as whether the attributes should lexically appear in the SOAP message when they have their default values. Later in the section, we find the following statement: 3) Section 4.2.1 says: "SOAP header block attribute information items MUST appear in the SOAP message itself in order to be effective; default values which may be specified in an XML Schema or other description language do not affect SOAP processing (see 3.1 XML Schema)." While it might seem that these statements are contradictory, the intention of the 3) is not to disallow omitting the SOAP header block attributes but to state that SOAP modules can not default their values. For example, a SOAP security module can not set the default mU value to true in the schema definition for the header blocks that it defines. Currently, the vast majority (if not all?) of existing SOAP implementations do not generate SOAP header block attributes with their default values. In addition, 4) Section 3.1 says: "A SOAP message MUST NOT impose any XML schema processing (assessment and validation) requirement on the part of any receiving SOAP node. 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." Section 3.1 seems to go too far in the requirement of not requiring schema processing. The only piece that we can possible talk about is that schema processing MUST NOT be required in order to correctly process a SOAP message according to the SOAP processing model in section 2. I don't think we have anything to say about whether application-defined data relies on schema processing or not. [email]
Proposal: Whenever we have a choice in what can be generated by a sender and what must be accepted by a receiver, it seems useful to invoke the general Robustness Principle "Be liberal in what you accept, and conservative in what you send". The proposal consists of three main parts and a minor part: A) Clarify the paragraph in section 4.2.1 to remove the apparent contradiction. B) Add a sentence to the two paragraphs mentioned the semantics of omitted SOAP header block attributes that indicated the guidelines for handling default attribute values. C) Clarify section 3.1 to say that it only applies to SOAP processing as defined by section 2. D) In addition, I would suggest that we add a paragraph in the introduction of part 1 (for example as part of section 3 explicitly calling out the Robustness Principle as a general principle for SOAP processors. [email]
Resolution: During the W3C XMLP WG Telcon on 6th March 2002 the WG agreed to close Issue 183 by making the amendments proposed by Henrik and amended by Noah. [email]
184Specn/aencDesignClosedAsir S Vedamuthu
Title: XML Legacy Types in SOAP Encoding Schema
Description:
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.
Proposal: [Resolution 1] Remove these element declarations and related complex types from the SOAP Encoding schema. 'Cos, I do not see any uses cases for representing any part of the SOAP Data Model using these element decls or complex types. OR [Resolution 2] Include the health warning in XML Schema by reference
Resolution:
Issue 184 is closed with the following resolution;

1.    The NOTATION type will be removed from the encoding schema

2.    A health warning will be added to the encoding schema and Part 2 of
the specification stating that the XML 1.0 types should be avoided as they
are only intended for use in attribute values.
[email]
185Specn/aencDesignClosedJacek Kopecky
Title: SOAP Encoding multistructs
Description:
 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>
Proposal: I) remove multistructs completely (keeping structs and arrays whose combinations can be used to model any B3 and B4 multistructs and arguably any A3 multistructs) and only allow accessing members either by name or by position, not both, II) distinguish between B3 and B4 multistructs just like we distinguish between structs and arrays, for example by mandating that B3 multistructs have type descended from enc:Multistruct, and B4 multistructs have type descended from enc:DocumentOrderStruct.
Resolution: This issue was closed with Last Call issue 297, see email
186Specn/aencDesignClosedMartin Gudgin
Title: Uniqueness and reference constraints of id and ref
Description:
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.
Note that this issue is linked to issue 163 [email]
Proposal: Add the following text to Section 3 of Part 2
Constraints on id and ref attribute information items

The value of a ref attribute information item MUST also be the value of
exactly one id attribute information item
Resolution:
3.1.4.3 Constraints on id and ref attribute information items

The value of a ref attribute information item MUST also be the value of
exactly one id attribute information item.

A ref attribute information item and an id attribute information item MUST
NOT appear on the same element information item.
[email]
187Specn/aprocDesignClosedStuart Williams
Title: Handling badly formed SOAP Messages
Description:
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.
[email]
Proposal:
Resolution: At the XML Protocol WG meeting of Mar 27, the WG decided to resolve Issue 187 "Handling badly formed SOAP Messages" by adopting the solution in [1] and as amended by the following addition editorial item:
"the editors should check that the binding framework says that binding
specification writers should ensure that bindings can handle all
failures that may be anticipated within the binding."
[email]
188Specn/aencDesignClosedNoah Mendelsohn
Title: When should xml declarations appear in examples?
Description: SOAP messages are XML Infosets. Examples in the specification sometimes have an XML declaration. Should such declarations be ommitted?
Proposal: The attribute found in the XML declaration, namely version, encoding and standalone are modelled in the infoset as the [version], [character encoding scheme] and [standalone] properties of the Document Information Item. Having XML declarations in examples is thus completely coherent.
Resolution:
The attributes found in the XML declaration, namely version, encoding and
standalone are modelled in the infoset as the [version], [character encoding
scheme] and [standalone] properties of the Document Information Item. Having
XML declarations in examples is thus completely coherent.

I would also note that the latest editor's copy[2] makes explicit reference
to the infoset properties listed above.
[email]
189Specn/aencDesignClosedNoah Mendelsohn
Title: What version number of XML should SOAP 1.2 specify?
Description: Does putting <?xml version='1.0' ?> in our examples imply that the SOAP 1.2 spec is tied to XML 1.0 and cannot be used with a future version.
Proposal: The attribute found in the XML declaration, namely version, encoding and standalone are modelled in the infoset as the [version], [character encoding scheme] and [standalone] properties of the Document Information Item. Having XML declarations in examples is thus completely coherent.
Resolution:
Enchance the description of the Envelope encoding to
include discussion stating that the values of the [version], [character
encoding scheme] and [standalone] infoset properties are unimportant as far
as SOAP is concerned.
[email]
190Specn/ametaDesignClosedNoah Mendelsohn
Title: How can we keep applications from supplying defaults for their own purposes?
Description:
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>
[email]
Proposal: Except where this specification mandates a default value for an attribute, SOAP messages must carry explicit values for all attribute information items required by this recommendation.
Resolution: The XMLP WG has decided to close issue #190 with the resolution at [1]. Specifically, the WG feels this issue has already been addressed by the resolution of issue #183 [2]. [email]
191Specn/ametaDesignClosedNoah Mendelsohn
Title: Reception of SOAP message with a DTD?
Description:
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>
[email]
Proposal: SOAP nodes MUST NOT transmit, and transport bindings MUST NOT provide for transmission of SOAP messages with Internal Subset DTDs.
Resolution: Issue 191 [1] was opened by me as a request to clarify the treatment of DTDs by SOAP and by SOAP protocol bindings. A comprehensive analysis and proposal for a solution was presented by me at [2]. Minor refinements were proposed by Henrik Frystyk Nielsen [3]

This note is to formally announce that the workgroup has decided to close issue 191 in the manner proposed by me, as amended by Henrik.

[email]
192Specn/ametaDesignClosedMark Baker
Title: When is a Fault a Fault?
Description:
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.
[email]
Proposal:
1) update the binding framework to state that each binding should
declare that the authoritative determinant of whether a message is a
fault or not should be the underlying protocol

2) update the default HTTP binding to state that a SOAP Fault MUST
only be processed as a SOAP Fault if the response code is 4xx or 5xx.
Resolution:
The WG has reviewed and accepted the proposed resolution described in
[2] with the following amendment to part 1) of the proposal which the
editors have been instructed to incorporate:

"Senders must not send messages that has a Fault element in the body and
also additional elements. If a receiver receives such a message, the
implications are undefined."
[email, email]
193Specn/aeditEditorialClosedJean-Jacques Moreau
Title: Missing reference from section "2.6 Processing SOAP Messages" to section "2.7 Relaying SOAP Messages"
Description:
<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>
Proposal:
originalAuthor="Noah" amendedBy="Jean-Jacques"
In the case of a SOAP intermediary, and where the SOAP message
exchange pattern and results of processing (e.g. no fault
generated) require that the SOAP message be sent further along
the SOAP message path, relay the message as described in Section
2.7 Relaying SOAP Messages.
Resolution:
        In the case of a SOAP intermediary, and where the
        SOAP message exchange pattern and results of
        processing (e.g. no fault generated) require that
        the SOAP message be sent further along the SOAP
        message path, relay the message as described in
        section 2.7 Relaying SOAP Messages.
email
194Specn/aencDesignClosedSimon Fell
Title: encodingStyle on soap:Header/soap:Body
Description:
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 ?
[email, from original comment]
Proposal:
Resolution:
The encoding style attribute MUST NOT appear in ANY element defined in
the envelope namespace
[email]
195Specn/aencDesignClosedTim Ewald
Title: mandating local name and namespace name of EII representing result outbound edge a bad idea
Description:
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.
(Comment: The commentator would prefer that we just mandate the local name, leaving the namespace name and type properties to be defined by some higher layer) [email]
Proposal: Mandate that the local name be 'result' but that the namespace name may be determined by means not specified in SOAP 1.2
Resolution:
The XMLP WG has decided to close issue #195 with the resolution
at [1]. Essentially,  QNames are used to identify the result.
Please let us know immediately if you disagree with this
resolution.
[email]
196Specn/aencDesignClosedJean-Jacques MoreauTBTF
Title: HTTP binding/status code
Description: I would like to raise the following issue: two tables[1,2] in the HTTP binding contain the strings "??" and "???". The meaning of these characters is ambiguous: it could either mean "any status code is valid", or "we haven't though about this problem yet; work in progress". Also, it is not clear whether only a certain subset of the HTTP status code is acceptable, instead of all possible HTTP status code.
Proposal:
Resolution:
As a result of the discussion, I think the table will look like this:

      env:VersionMismatch                 500 [see a] 
      env:MustUnderstand                  500 [see b]  
      env:Sender                          400 [see c]
      env:Receiver                        500 [see d]

[a] Similar to HTTP/1.1's 505 "HTTP Version Not Supported"
[b] Similar to HTTP/1.1's 501 "Not Implemented"
[c] Similar to HTTP/1.1's 400 "Bad Request"
[d] Similar to HTTP/1.1's 500 "Internal Server Error"
[e] Because the sender sends something that the receiver can't accept
[email]
197Specn/aencDesignClosedYves LafonTBTF
Title: Negotiation of features in HTTP Binding
Description: In 7.1, it says :HTTP applications MUST use the media type "application/soap+xml" according to [12] when including SOAP 1.2 messages in HTTP exchanges. However, this does not apply if attachments are sent along with the document. Also, what is the best way to negotiate the content-type? Trial and error? doing an idempotent (ie: GET) to get the server capabilities? Only in the description of the service?
Proposal:
Resolution:
"Conforming implementations of this binding:

1. MUST be capable of sending and receiving messages serialised using
media type application/soap+xml whose proper use and parameters are
described in [12].

2. MAY send requests and responses using other media types providing
that such media types provide for at least the transfer of SOAP XML Infoset.

3. MAY, when sending requests, provide an HTTP Accept header. This header:

   (i)  SHOULD indicate an ability to accept at minimum
        application/soap+xml

   (ii) MAY additionally indicate willingness to accept other media
        types that satisfy 2 above."

[...]
[email, email]
198Specn/aediEditorialClosedPaul Prescod
Title: Split part 2
Description:
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
[email] After the first resolution sent by the WG, Paul replied with this:
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.
[...]
[email]
Proposal:
Resolution: The WG has already split the original SOAP 1.1 specification into two parts (Part 1 and Part 2). The WG considers that this is sufficient for now, and does not want to split the specification any further (although the WG reserves the right to split the specification further in the future if it so desires). [email].

On 27 March 2002, the WG considered Paul Prescod's response to this WG's stated resolution, and the WG decided to stay with its resolution

199Specn/aencSpecClosedNoah Mendelsohn
Title: allow xml:lang on faultString?
Description: * Section 5.4.2: Should we allow xml:lang on faultString? This will probably be a concern for the internationalization folks. [email]
Proposal:
1.  Add the following to the top of the envelope schema[1];

 <xs:import namespace='http://www.w3.org/XML/1998/namespace' />

2.  Add a type definition as follows;

 <xs:complexType name='faultstring' >
    <xs:simpleContent>
      <xsd:extension base='xs:string' >
        <xs:attribute ref='xml:lang' />
      </xs:extension>
    </xs:simpleContent>
 </xs:complexType>

3. Amend the Fault type as follows;

 <xs:complexType name="Fault" final="extension" >
   <xs:annotation>
    <xs:documentation>
     Fault reporting structure
    </xs:documentation>
   </xs:annotation>
   <xs:sequence>
    <xs:element name="faultcode" type="tns:faultcode" />
    <xs:element name="faultstring" type="tns:faultstring" />
    <xs:element name="faultactor" type="xs:anyURI" minOccurs="0" />
    <xs:element name="faultrole" type="xs:anyURI" minOccurs="0" />
    <xs:element name="detail" type="tns:detail" minOccurs="0" />
   </xs:sequence>
  </xs:complexType>

4. Amend the description of faultstring as follows;

The faultstring element information item has:

  A [local name] of faultstring .
  A [namespace name] which has no value.
  An optional attribute information item with a local name of lang and
namespace name of http://www.w3.org/XML/1998/namespace ( see [ref to
http://www.w3.org/TR/REC-xml.html#sec-lang-tag] )
      
[email]
Resolution: The WG has reviewed and accepted the proposed resolution. [email]
200Specn/abindSpecClosedChris Ferris
Title: SOAPAction header and "action" parameter on media type
Description: IIRC, we agreed to place the "action" parameter on the application/soap+xml media type. Section 7.5 of the latest version of part 2 of the specification doesn't talk about this at all, it only talks about the use of the SOAPAction header.

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.

[email]
Proposal:
1) I would say that we should only have it in one place and like the
direction of moving it entirely into the media type definition as a
parameter.

2) This is the trickiest part - one of the important reasons for having
a known content type is to indicate that *this* is a SOAP message. If
two parties are not using a known content type then that information
clearly is not there anymore. I can think of two ways to go:

2.A) We leave it entirely up to the media type being used to indicate in
some manner that this is a SOAP message.

2.B) We maintain the SOAPAction in some manner (for example in an
appendix) that allows is to be used with content types other than
"application/soap+xml" indicating that this is a SOAP message.

3) The spec editors should add a note to the spec that we know that this
is an ID with no standing.

4) This was carefully put together as the resolution [6] of issue 95
[5]. While some of the details regarding the status codes used will be
changed slightly as a result of it being a media-type parameter, and
that its value can't be relative, the overall resolution still stands.
[email]
Resolution:
The WG has reviewed and accepted the proposed resolution described in
[1] with the "2.A" option and not "2.B".
[email]
201Specn/ametaSpecClosedNoah Mendelsohn
Title: Inconsistency in the spec regarding structure of the body
Description:
"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.
[email]
Proposal:
Resolution:
"An ultimate SOAP receiver MUST correctly process the immediate
children of the SOAP body (see 5.3 SOAP Body). However, with the
exception of SOAP faults (see ....), 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."
[email]
202Specn/ametaDesignClosedHerve Ruellan
Title: Definition of intermediaries
Description:
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.
[email]
Proposal:
I think that a small change in section 2.7.1 would suffice to solve this 
problem by making clear that any SOAP node forwarding a message must act 
in the role of a SOAP intermediary.

<original>
The semantics of one or more SOAP blocks in a SOAP message, or the SOAP 
message exchange pattern used MAY request that the SOAP message be 
forwarded to another SOAP node on behalf of the initiator of the inbound 
SOAP message. In this case, the processing SOAP node acts in the role of 
a SOAP intermediary.
</original>

<proposal>
When a SOAP node forwards a SOAP message received from another SOAP 
node, it MUST acts in the role of a SOAP intermediary. Such forwarding 
may be requested by the semantics of one or more SOAP blocks in the SOAP 
message, by the SOAP message exchange pattern used or by any other means.
</proposal>
Resolution:
During the 24th April telcon, the XML Protocol Working Group has decided 
to close issue 202 [1] with the resolution proposed in [2].
[email]
203Specn/ametaDesignClosedGlen Daniels
Title: SOAP module specification
Description:
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" :)
[email]
Proposal:
Resolution:
3.2 SOAP Modules

A SOAP module is a feature which is expressed as SOAP headers.

A module specification follows the following rules.  It:

* MUST identify itself with a URI.  This enables the module to be unambiguously
  referenced in description languages or during negotiation.

* MUST clearly and completely specify the content and semantics of the header
  blocks used to implement the behavior in question, including if appropriate
  any modifications to the SOAP Processing model.

* MAY utilize the property conventions defined in section 5 of part 2 in
  describing the functionality that the module provides.  If these conventions
  are followed, the module specification MUST clearly describe the relationship
  between the abstract properties and their representations in the SOAP
  envelope.  Note that it is possible to write a feature specification purely
  in terms of abstract properties, and then write a separate module
  specification which implements that feature, mapping the properties defined
  in the feature spec to SOAP header blocks in the module.

* 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 body and inserts
  a header containing a checksum and an indication of the encryption mechanism
  used.  The spec for such a module would indicate that the decryption
  algortihm on the receiving side must run *prior* to any other modules which
  rely on the contents of the body.
[email]
204Specn/abindingDesignClosedMark Nottingham
Title: HTTP transcoding
Description:
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.
[email]
Proposal:
Resolution:
In [1] you ask whether the WG has considered the various cache-control
directives and in particular "no-transform" and how that applies to
SOAP. The WG discussed the issue and came to the following conclusion:
Any HTTP implementation should certainly take advantage of the features
provided by HTTP. However, there is nothing particularly special
about how the various cache-control directives apply to SOAP - they are
defined in an entirely orthogonal manner and so the WG didn't see a
reason for why the binding should say.
[email]
205Ext:MTn/abindingDesignClosedChristopher Ferris
Title: Media type (application/soap+xml)
Description:
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...)

[email]
Proposal:
Resolution:
1. with regard Fragment-Identifiers in the text of the SOAP 1.2
   specification, include a reference to RFC-3023
2. with regards XML-Base in the text of the SOAP 1.2 specification, state
   that SOAP 1.2 uses XML Base and include a reference to the W3C XML Base
   Recommendation
[email]
374specn/ametaDesignClosedMarc Hadley
Title: Comment on Attachment Feature WD - CID support
Description:
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.
[email]
Proposal:
Resolution:
This issue is now covered by issues 376, 377 and 378
    
[email]
375specn/ametaDesignClosedChristopher Ferris
Title: Comments on Attachment Feature WD - Compound Structure, part,...
Description:
"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.
[email]
Proposal:
Resolution:
This issue is now covered by issues 379, 380, 381 and 382
    
[email]
376specn/ametaDesignClosedMarc Hadley
Title: Comment on Attachment Feature WD - Add a ref to SOAP Attachment Note
Description:
[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. 
[email]
Proposal:
Resolution:
During the 11 September 2002 telcon, the WG has decided to close issue 
376, "Add a ref to SOAP Attachment Note" with the following resolution:

A reference to the "SOAP Messages with Attachments" note will be added 
to the AF spec.
[email]
377specn/ametaDesignClosedMarc Hadley
Title: Comment on Attachment Feature WD - move bib refs
Description:
[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.
[email]
Proposal:
Resolution:
During the 11 September 2002 telcon, the WG has decided to close issue 
377, "move bib refs" with the following resolution:

The reference section will be split in two subpart, the first one being 
normative, and the second one being informative. The second subpart will 
contain the references to WS-Security, WS-Attachments, SOAP with 
Attachments.
    
[email]
378specn/ametaDesignClosedMarc Hadley
Title: Comment on Attachment Feature WD - CID support
Description:
[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.
[email]
Proposal:
Resolution:
During the 11 September 2002 telcon, the WG has decided to close issue 
378, "CID support" with the following resolution:

The AF spec will no require/specify support for the CID referencing scheme.

Rationale:
It is up to each particular binding (implementing AF) to chose which URI 
scheme(s) to use. One of the reason is that the 'natural' URI scheme to 
use will depend on the means used to move the attachments.

However, the WG also decided to add some clarification that a secondary 
part can have multiple URIs, that a binding can use one or more URI 
schemes and that both absolute and relative URIs can be used.
[email]
379specn/ametaDesignClosedChristopher Ferris
Title: Comments on Attachment Feature WD - Concern over the term "part"
Description:
[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.
[email]
Proposal:
Resolution:
During the 11 September 2002 telcon, the WG has decided to close issue 
379, 'Concern over the term "part"' with the following resolution:

A note will be added in section 3. Terminology to clarify that the use 
of the term 'part' is independent of its use in other specifications.
[email]
380specn/ametaDesignClosedChristopher Ferris
Title: Comments on Attachment Feature WD - Concern over the term "Compound Structure"
Description:
[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.
[email]
Proposal:
Resolution:
During the 11 September 2002 telcon, the WG has decided to close issue 
380, 'Concern over the term "Compound Structure"' with the following 
resolution:

The paragraph in section 6. Implementation starting with "Note: The 
compound SOAP structure model...", will be changed from a note to more 
normative prose by removing the term 'Note' at the beginning of the 
paragraph.
[email]
381specn/ametaDesignClosedChristopher Ferris
Title: Comments on Attachment Feature WD - specifying relationships between primary and secondary parts"
Description:
[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.
[email]
Proposal:
Resolution:
During the 11 September 2002 telcon, the WG has decided to close issue 
381, 'specifying relationships between primary and secondary parts' with 
the following resolution:

The paragraph from section 4. Compound SOAP Structure Model starting 
with "Secondary parts can be used to contain data..." is not intended as 
normative prose but rather as an example. To make this explicit, the 
words 'For exmample,' will be added at the beginning of this paragraph.
[email]
382specn/ametaDesignClosedChristopher Ferris
Title: Comments on Attachment Feature WD - Clarification of SOAP nodes'responsibilities
Description:
[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.
[email]
Proposal:
Resolution:
During the 11 September 2002 telcon, the WG has decided to close issue 
382, 'Clarification of SOAP nodes'responsibilities' with the 
following resolution:

The WG thinks the AF specification about SOAP nodes' responsibilities is 
clear enough. Therefore no action will be undertaken.
[email]
429paswan/ametaDesignClosedJacek Kopecky
Title:
Description:
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?
[email]
Proposal:
We should allow xbinc:Include element to reach the SOAP Processing model
and specify (if the proposal isn't clear enough already) how DoInclude
header works and how the processing model doesn't change (e.g. it
doesn't have to be re-run).

We should also explicitly say that protocol bindings may be built which
use xbinc:Include themselves, in which case the SOAP processor doesn't
ever see xbinc:Include elements (or the DoInclude header).
Resolution:
We have resolved that our interest in xbInc:Include, as proposed in [2]
is at most for use in bindings. It should not in general be visible to
applications, and if present is in general to be interpreted by bindings
prior to application of the SOAP processing model.
[email]
431paswan/ametaDesignClosedMarc Hadley
Title: semantics of attachments wrt intermediaries
Description:
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."
[email]
Proposal:

Resolution:
Marc, you raised an issue (logged as #431, see
http://www.w3.org/2000/xp/Group/xmlp-issues#x431) regarding the semantics
of attachments with regard intermediaries. The XMLP WG yesterday agreed to
close the issue using the text in
http://lists.w3.org/Archives/Public/xml-dist-app/2003Aug/0025.html.
[email]
432paswan/ametaDesignClosedMarc Hadley
Title: which nodes to serialize
Description:
2: "How does the binding determine which nodes to serialize as 
attachments ?"
[email]
Proposal:

Resolution:
The XMLP WG has closed this issue by stating that data to be 
optimized MUST be in the canonical form of base64 as defined by XML Schema. 
So a binding is free to optimize any nodes that have such a lexical form.
    
[email]
435mtomn/ametaDesignClosedMartin Gudgin
Title: how does a receiver determine which elements were optimized
Description:
-- 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.
[email]
Proposal:

Resolution:
During the 22 Oct 2003 teleconference, the XMLP WG has decided to close
this issue with the following resolution:

"SOAP receiver cannot determine which elements were optimized"
    
[email]
436mtom/paswan/ametaDesignClosedMartin Gudgin
Title: should we say anything about the responsibility of intermediaries?
Description:
-- derived from 431 --
are intermediaries required to preserve optimization/non-optimization of
element content?
--
should we say anything about the responsibility of intermediaries?
[email]
Proposal:

[see also email and following thread]
    
Resolution:
The WG has decided that this issue is now closed, having been
adequately addressed by the closure text for Issue 431 at

http://lists.w3.org/Archives/Public/xml-dist-app/2003Aug/0025.html and 
which now exists in sections 2.4.3 and 2.4.4 of the SOAP MTOM Editors Copy at

http://www.w3.org/2000/xp/Group/3/06/Attachments/OptimizationMechanism.html.
email
437mtom/paswan/ametaDesignClosedNoah Mendelsohn
Title: How to establish base URI?
Description:
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.)
[email]
Proposal:
Resolution:
During the 29 Oct 2003 teleconference, the XMLP WG has decided to close
this issue by adopting Jacek's proposal [1] inlined here:

<<<
For the general case of optimized pieces of data we should note that if
the optimized data contains a relative URI, the base URI is the same as
if the data wasn't optimized. In particular if we decide to identify
optimized parts using some kind of URIs, these URIs don't affect the
base URI of relative URIs in the optimized data.

For the Representation (header) element (or whatever equivalent we come
up with) we should say that it does in fact establish a base URI for
relative URIs contained in the actual representation and that the base
URI is the URI used by the Representation element to identify the
resource whose representation it carries.
>>>
[email]
438mtomn/ametaDesignClosedMark Nottingham
Title: Optimizations other than Base64
Description:
1. Should MTOM accommodate encodings/optimizations other than base64?
    a. If so, should the list be open-ended (i.e., extensible)?
[email]
Proposal:
Resolution:
The XMLP WG has decided to close issue 438 by declining at the
moment to include other types than base64 because no other types are
necessary for the fulfillment of our usecases and requirements.
    
[email]
439n/ametaDesignClosedAmy Lewis
Title: regex for media types
Description:
> 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.
[email]
Proposal:
Resolution:
Amy,

The Working Group has conferred and believes that these issues have 
already been considered.
    
[email] DISSENT: email
440n/ametaDesignClosedNoah Mendelsohn
Title: Sharing MTOM parts for identical leaf nodes
Description:
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.
[email]
Proposal:
    See also:
    
[email, discussion, discussion]
Resolution:
The XMLP WG has resolved this issue as follows:

XOP will allow unreferenced MIME parts
MTOM and HTTP binding will allow unreferenced MIME parts but such MIME
parts play no part in SOAP processing.

XOP will allow multiple refs per binary part MTOM will allow multiple
refs per binary part HTTP binding will allow only one ref per binary
part
    
[email] Not for objection but for the record: Noah's email
441mtomn/ametaDesignClosedNoah Mendelsohn
Title: Canonical forms in MTOM
Description:
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.
[email]
Proposal:
Resolution:
The XMLP WG has closed this issue by stating that data to be optimized MUST 
be in the canonical form of base64 as defined by XML Schema.
    
[email]
442mtomn/ametaDesignClosedMartin Gudgin
Title: Representation header
Description:
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.
[email]
Proposal: [email (Yves), email (Jacek)]
Resolution:
the WG has decided to close issue 442 by accepting my proposal [2]
with the friendly amendment stating that the Representation header can
be used multiple times in one message if multiple representations are to
be carried with that message.

We expect to open an issue on providing an extension to this header that
will enable full HTTP caching behavior of recipients. We also expect to
open an issue on clarifying how the Representation header should play
with the SOAP processing model, specifically with respect to roles and
mustUnderstand.

Providing media type information for the data in the Representation
header is still an open issue - 443.
443mtomn/ametaDesignClosedJacek Kopecky
Title: Media-typing binary data in XML
Description:
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-)
[email]
Proposal:
Resolution:
The XMLP WG has closed issue 443 by stating the following:

"We have the 'Assigning Media Types to Binary Data in XML' document. 
That provides the xmlmime:ContentType attribute to indicate the media 
type of content in XML and a schema annotation for indicating acceptable 
media types in a schema description."

The Assigning Media Types to Binary Data in XML' is located at [2].
Please note that the attribute name used in [2] is 'mediaType' and not 
'ContentType'; this will be changed in a newer version of the 'Assigning 
Media Types to Binary Data in XML' document.
[email]
444mtomn/ametaDesignClosedNoah Mendelsohn
Title: MTOM and Data Model Details
Description:
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."
[email]
Proposal:
Resolution:
The issue basically calls for XMLP to ensure that
our specification of data model accessors in XOP is complete and accurate.
We believe this was attended to at the San Francisco face to face [2], and
the intention is that the editors will reflect details of that resolution
in future working drafts
[email]
445miffyn/ametaEditorialClosedDavid Fallside
Title: the name "Miffy"
Description:
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".
[email]
Proposal:
Resolution:
the WG has decided today at its telcon to change the name of the MIFFY
spec to XOP - XML binary Optimized Packaging, thus resolving issue 445.
    
[email]
446miffyn/ametaDesignClosedNoah Mendelsohn
Title: Miffy content in Miffy content
Description:
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.
[email]
Proposal:
Resolution:
You raised issue 446 regarding whether MIFFY/XOP can serialize a data
model that already contains xop:Include elements. The XMLP WG adopted
the following text into Section 3 of the XOP document:

        Note that the data model used as input to XOP processing MUST
	NOT contain any element nodes with a dm:node-name
	{http://www.w3.org/2003/06/soap/features/binary-inclusion;Include};
	data models containing such elements cannot be serialized using XOP.
[email]
447mtom/miffyn/ametaDesignClosedNoah Mendelsohn
Title: recognizing and processing MTOM/Miffy in the HTTP Binding
Description:
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.
[email]
Proposal:
Resolution:
You raised an issue, give the number 447[1] with respect to how an
MTOM/XOP aware SOAP node will make the determination as to whether or
not to perform MTOM/XOP processing. The XMLP working group have decided
that such processing will be triggered by the media type of the outer
package, which in the MTOM case will be application/soap_xop+xml
[email]
448mtomn/ametaDesignClosedDavid Orchard
Title: extensibility/versioning in mtom elements
Description:
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
[email]
Proposal:
Resolution:
The xop:Include element allows extension attributes and child elements, 
as long as they may be safely ignored during processing. See the 
current Editors' Draft for the exact wording the WG intends.
[email]
449mtomn/ametaDesignClosedMarc Hadley
Title: Multiple representations of a single resource
Description:
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.
[email]
Proposal:
Resolution: It's OK for two Representation headers in a message to have the same URI and role and decided to add a note saying that such headers would typically have different metadata. [email]
450miffyn/ametaDesignClosedChris Lilley
Title: Referenced parts MUST include the 'Content-Transfer-Encoding' field and should include the 'Content-Length' field.
Description:
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.
[email]
Proposal:
Resolution: Closed with no action [email]
451miffyn/ametaDesignClosedChris Lilley
Title: referencing mechanism via 'Content-Type' and 'http' URI
Description:
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.
[email]
Proposal:
Resolution: The XMLP WG have resolved this issue by mandating that the cid: scheme must be used. [email]
452miffyn/ametaDesignClosedChris Lilley
Title: Addressing the 'data:' URI directly in the MIFFY specification
Description:
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.
[email]
Proposal:
Resolution: the XMLP WG has decided at its face-to-face meeting last week to close issue 452 regarding optimizing data: URIs in attributes by declining to add support for this in XOP. We don't consider data: URIs a good use case to design our optimization mechanism for. [email]
453miffyn/ametaDesignClosedChris Lilley
Title: Packaging multipart payloads via use of the 'multipart/multiplexed' mechanism in RFC 3391 should be considered as valid MIFFY encoding mechanism
Description:
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.
[email]
Proposal:
Resolution: The XMLP WG has resolved this issue by deciding that XOP will allow use of RFC3391 although it will not define such a serialization. MTOM will mandate use of multipart/related. To use RFC3391 in SOAP, an RFC3391 based 'MTOM' spec would need to be written. [email]
454miffyn/ametaDesignClosedNoah Mendelsohn
Title: variability of encoding in Miffy
Description:
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.
[email]
Proposal:
Resolution: The XMLP WG have resolved this issue by saying that in the MTOM HTTP binding each binary part MUST have a content-transfer encoding of binary. [email]
455mtomn/ametaDesignClosedNoah Mendelsohn
Title: SOAP processing model and Representation Header
Description:
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. 
[email]
Proposal:
Resolution:

The text describing the Representation Header will state:

1. "The type of the reinsert attribute information item is xs:boolean .
When this attribute is specified on the Representation header block with a
value of "true", it indicates that a SOAP forwarding intermediary node
processing the header block must reinsert the header block. This means
that when used in conjunction with the relay attribute, defined in [SOAP
Part 1] 5.2.4 SOAP Relay Attribute, with a value of "true", the
Representation header block will always be relayed by a SOAP forwarding
intermediary. When this attribute is specified on the Representation
header block with a value of "false", the behavior of the SOAP node
processing the header block is the same as that when the attribute is not
specified, and normal SOAP processing rules apply. The presence of this
attribute has no effect on the processing of a Representation header by a
SOAP endpoint."

2. The reinsert attribute is not namespace qualified.

3. "Such Representation header blocks SHOULD NOT have the same metadata
(such as media-type). If such Representation header blocks have the same
metadata then any one of them may be used."

4. Implementations MAY need to process Representation header blocks BEFORE
other header blocks that might dereference URIs.
[email]
456mtomn/ametaDesignClosedHerve Ruellan
Title: constraints on nodes types
Description:
- 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.
[email]
Proposal:
Resolution:
The XMLP WG agreed to remove the sentence 
"The type property for all other Element Nodes MUST be set to xdt:untypedAny."
from the spec. 
    
[email]
457mtomn/ametaDesignClosedYves Lafon
Title: Extension required for the Representation header
Description:
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.
[email]
Proposal: See email
Resolution: The XMLP WG decided to close issue 457 by adopting the proposal at [email] and including it in the Representation header. [email]
458mtom/xop + RECn/ametaDesignClosedNoah Mendelsohn
Title: impact of XML 1.1
Description:
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.
[email]
Proposal: [email to kick off discussion, with links to details]
Resolution:
a) that the infoset for a SOAP message may use any recommendation level
   version of XML ( which at the time of writing encompasses XML 1.0 and
   XML 1.1 ). 

b) that bindings may restrict themselves to a particular version ( or
   versions ) of XML for serialization.

c) that the application/soap+xml media type ( and hence the SOAP 1.2
   HTTP binding ) will be restricted to XML 1.0 serialization. only.

d) that the application/soap_xop+xml media type ( and hence the MTOM
   binding ) is similarly restricted to XML 1.0 serialization.
[email]
459mtom/xopn/ametaDesignClosedCarine Bournez
Title: Requirements R9 and R7
Description:
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.
[email]
Proposal:
Resolution: Closed and splitted in issue 463 and 464. [email]
460xopn/ametaDesignClosedErik Wilde
Title: let the implementation decide to create a part?
Description:
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.
[email]
Proposal:
Resolution:
You raised an issue, 460[1], with respect to allowing implementations to
choose when to optimize. The working group are amending the text you
commented on to address this issue, amongst others.

As an aside, I would note that the notion of starting with base64 and
optimizing to binary is a specification convention. We actually expect
that people will often start with the binary data and that it is just at
the logical level that the base64 characters exist. 
[email]
461xopn/ametaDesignClosedErik Wilde
Title: restricted subtypes of base64Binary
Description:
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?
[email]
Proposal:
Resolution: You raised an issue, 461, with respect to optimizing types that are subtypes of xs:base64binary. The working group plan to amend the text of the spec to address this issue, amongst others. Specifically in this case, the spec will no longer talk about types in terms of value space, but will talk about the character children of a given element being in the canonical lexical form of xs:base64Binary. As any subtypes of xs:base64Binary can be serialized in this form, we trust this addresses your concern. [email]
462xopn/ametaDesignClosedErik Wilde
Title: Whitespace in base64Binary
Description:
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.
[email]
Proposal:
Resolution:
In XMLP issue 462 you are concerned with base64 data in the infoset
that contains whitespace; and the handling of such data in XOP. The WG
has resolved to close your issue by accepting the following explanation
and adding it where appropriate in the specs' introduction chapters.

The primary use-case for XOP is that an application wants to include a
chunk of binary data (that the application has as an octet stream, not
encoded for example as base64) in an XML document in some optimized
form. Where XOP requires canonical base64 data, that is only a
conceptual requirement, it is expected that any implementation will skip
encoding the original data into the infoset (or data model) but will
pass the data directly to the XOP layer which will put it directly into
the MIME envelope. Conceptually therefore, the data may be viewed as
present in the infoset in base64 canonical, even if the implementation
doesn't contain any base64-encoding code.

For the other use cases where the base64 form is actually used, we must
choose one unambiguous form (because we are required to reconstruct the
precise infoset at the receiving end), and we chose to reuse XML
Schema's canonical form (yet to be published?).
[email]
463mtom/xopn/ametaDesignClosedCarine Bournez
Title: Requirements R7
Description:
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.
[email]
Proposal:
Resolution: The XMLP WG decided to close issue 463 since it is straightforward to generate unique identifiers for each part (given the use of the cid: scheme to identify each part). [email]
464mtom/xopn/ametaDesignClosedCarine Bournez
Title: Requirements R9
Description:
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.
[email]
Proposal:
Resolution:
The XML Protocol Working Group has closed issue 464 ("Requirements  
R9")  by adding an appendix documenting XOP's relationships to  
other specifications, including its extensibility mechanisms.
[email]
465xopn/ametaEditorialClosedFrank Mabry
Title: XOP: spelling error or new term?
Description:
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!"
[email]
Proposal:
Resolution:
The WG resolved to take no action since the text to which you referred
no longer exists in the current XOP document.
[email]
466xopn/ametaDesignClosedFrank Mabry
Title: MTOM: Counter intuitive requirement
Description:
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.

[email]
Proposal:
Resolution:
You raised an issue[1] regarding XOP and the cardinality of binary parts
to xop:Include elements. The text you highlighted is no longer in the
XOP specification, hence the restriction no longer applies in XOP
itself. While such a restriction does exist in the MTOM specification at
the level of the HTTP binding, other bindings of XOP can be constructed
that do not have the restriction.
[email]
467Representationn/ametaDesignClosedMichael Champion
Title: SOAP Representation Header, use cases needed.
Description:
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?
[email]
Proposal:
Resolution:
The XMLP WG considered your comment on their telephone
conference this week and decided to amend the first paragraph of Section
2.1 to read:

"The Representation header block is designed to allow applications to
carry a representation of a Web resource in a SOAP message. Applications
of this header include cases where the receiver has limited ability to
get the representation using other means, for example because of access
restrictions or because the overhead would be unacceptable. The
representation header is also required when multiple references to the
same extracted content are required but duplication of extracted content
is undesirable. See UC 2 and UC 6 for details."

where UC2 and UC6 will be bibliographic references to our use cases document.
[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.