Section 2.2.4, the value of a rep:Data element is described as just "a base64 encoded representation" of a Web resource. I think this should be "a base64 encoded representation in the canonical lexical form".[email]
During its July 14 meeting, the XMLP WG decided that it was unnecessary to say that the lexical form must be the canonical form, because this header is independent of MTOM. So this will not result in any change to the Representation Header specification.[email]
Section 4.3.1, it is stated that "Each MIME part that is refered to by xop:Include MUST have a Content-Transfer-Encoding header field". On the other hand, HTTP/1.1 itself does not normally use Content-Transfer-Encoding header field altogether (19.4.5 No Content-Transfer-Encoding). I think more explanation is needed to justify this restriction.[email]
Closed with no action[email][email]
Section 4.3.1, the value of "Content-Type" field in the table should be "multipart/related", not "mime/multipart-related".[email]
The editors have corrected the error, changing 'mime/multipart-related' to 'multipart/related' as you suggested.[email]
Section 1.2, the reference to "SOAP Attachment Requirements" should be updated to point to "SOAP Optimization Serialization Use Cases and Requirements".[email]
You raised an issue, number 496[1] regarding an incorrect reference in the MTOM specification[1]. The editors have corrected the reference to cite the "SOAP Optimized Serialization Use Cases and Requirements" as you suggested.[email]
Section 5, the need for XOP-specific media type (e.g.
application/soap_xop+xml) is described. I don't think such an approach is
feasible since registering a new media type is a very expensive process. I
suggest to use "start-info" parameter of "multipart/related" type instead to
indicate that the content is encoded in XOP:
Content-Type: multipart/related;type=application/soap+xml;
start="<mymessage.xml@example.org>";
start-info="http://www.w3.org/2003/12/xop/include"
[email]
The XMLP WG has considered issue 495 which you raised [1]. Your suggestion to use the start-info parameter has already been made in the context of the WG's resolution to issue 470 [2], and the WG is considering this suggestion. Issue 495 duplicates issue 470, and so it will be closed.[email]
Section 1.3, the XML Schema definition of "xop" namespace is marked as non-normative. I think "xop" schema should be normative considering the fact that "rep" schema is also normative.[email]
The XMLP WG rationale to differentiate the normative nature of these namespaces stems from the introduction of XML 1.1 and its impact upon XMLP specifications (See Rec Issue 20 [4]). Since the Representation Header specification and the rep namespace is SOAP specific, only XML 1.0 applies and hence the we define this rep namespace as normative. However, XOP is NOT SOAP specific and thus needs to allow for either XML 1.0 or 1.1. Thus we have defined the xop namespace as non-normative.[email][email]
In the second example in Section 1.2, "Content-Transfer-Encoding: binary" is specified. It should be mentioned that the value of "binary" cannot be used for many protocols including SMTP which assume 7 bits transfer.[email]
The XML Protocol Working Group has closed issue 493 with no action, because the semantics and proper use of Content-Transfer-Encoding are felt to be well-understood and documented by the MIME specifications.[email]
A comment for your three Last Calls ending 29 June: SOAP Message Transmission Optimization Mechanism [1], SOAP Resource Representation Header [2] and XML-binary Optimized Packaging [3]. On the whole the drafts look nice but for some reason the References sections have no links. The W3C Bibliography Extractor writes references in W3C style very quickly from a list of URIs.[email]
You raised an issue[0] regarding links in the bibliography sections for XOP[1], MTOM[2] and Representation header[3] specs. This problem has been addressed in the latest editor's copies of these documents[4,5,6][email]
I was under the impression that in resolving issue 451 that we were mandating the use of the cid: URI scheme ( and the corresponding ContentID MIME header ) when referencing MIME parts from xop:Include/@href. However, I can find no mention of this in XOP or MTOM. XOP in fact allows both Content-ID and Content-Location to be used ( see[4] ), but I thought at the MTOM level we were restricting to Content-ID only. I note that in private mail, several other members have the same recollection as me.[email]
the XMLP WG agreed to resolve it by mandating the use of the "cid:" URI scheme in MTOM.[email]
Last week we approved this resolution of our Issue 207, which was to ask
you to add a reference to the Media Type Description note and
specifically mention that the expectedMediaType annotation could provide
a source of information for determining which blobs are to be optimized.
The specific text proposal below, and its position in the MTOM spec, are
of course examples useful in reaching consensus on the issue within our
group and you may find a better way to indicate this information in your
spec.
[..]
> Ask the XMLP WG to augment the paragraph in MTOM
> [http://www.w3.org/TR/soap12-mtom/#aof-sending] as indicated {{thus}}:
>
> "Note: the means of identifying element information items that contain
> base64 encoded data in canonical lexical form are
> implementation-dependent. Some implementations can identify such element
> information items by construction (e.g., because a certain API may
> create only canonical forms); others may check the characters prior to
> sending{{, others may rely on information in the description such as the
> presence and/or value of the xmlmime:expectedMediaType schema annotation
> [reference to XMLMIME]}}. Because of the need to exactly preserve the
> characters in the transmitted Infoset, non-canonical representations
> MUST NOT be optimized."
[email]
The WG has added the text you requested, appending the additional phrase 'if a schema is available'.[email]
the WS-Description WG has reviewed the Last Call drafts of XOP, MTOM and Resource Representation Header specs and has two comments. 2) we have discussed the ednote in section 4.3.1 in MTOM [2] on bindings that will reject some infosets and even though it doesn't affect our ability to describe SOAP services using MTOM, there was significant sentiment that an escaping mechanism for XOP elements be added in XOP or MTOM. It was noted that such escaping mechanism would only be used by nodes that cannot otherwise guarantee that xop:Include isn't present in their SOAP infosets; and such nodes, in order to be conformant, would have to scan the infosets for the presence of xop:Include elements before using MTOM. We don't think that performing the escaping would be a significant (show-stopping) addition to the overhead of the scan.[email]
The WG has decided to take no further action with respect to this comment.[email]
the WS-Description WG has reviewed the Last Call drafts of XOP, MTOM and Resource Representation Header specs and has two comments. 1) the Resource Representation header [1] is not a SOAP module and therefore does not have a formal name by which it can be referred (other than the element qname). We feel that making the header into a full module with its identification URI will help us describe applications that use it.[email]
The XMLP WG had decided to close issue 488 by adding a new section for the description of a SOAP module as proposed in [3].email
Section A.3, it is stated that "Change to the format MUST be identified by a new namaspace URI (i.e., they MUST define a new Include element information item in another namespace)." On the other hand, an extension to xop:Include element to add a namespace qualified child element or attribute is allowed according to Section 2.1. It is not clear such an extension is considered to be a "format change" mentioned in Section A.3 or not.[email]
You raised an issue, number 487[1] regarding language in Section A.3 of the XOP specification[1]. The Working Group decided that use of the word 'format' in the second sentence was incorrect and that the word 'semantics' should be used instead as in the first sentence. The text will be amended to read: "XOP Documents allow extensions to the xop:Include element when they do not change its semantics. Changes to the semantics MUST be identified by a new namespace URI (i.e., they MUST define a new Include element information item in another namespace)."[email]
In the first example, a namespace declaration for XOP is provided on the root soap:Envelop element. I don't think this is good because Original Infoset should not know anything about XOP (xop:Include element never occurs in Original Infoset). Also, "xmlmime:content-type" should be replaced by "xmlmime:contentType".[email]
You raised an issue, number 486[1] regarding presence of the XOP namespace declaration on the root element in an example in the XOP specification[1]. The Working Group agrees that the example is unclear and will amend the example so that the namespace declaration appears on the Include element. The working group does note however, that it is possible for an original infoset to contain a namespace declaration for the XOP namespace, provided it does NOT contain any Include elements.[email][email]
Examples in Section 1.2, I propose to use an XML vocabulary other than SOAP (such as SVG or XHTML) in order to show that XOP does not depend on SOAP (common misunderstanding).[email]
You raised an issue[1] regarding examples in the XOP specification[2]. The latest editor's copy contains an example that uses text/xml. I trust this addresses your concern.[email]
Section 1.2, assigning an identification number to each example (e.g. Example 1, Example 2...) will greatly help the reader of the printed specification to locate the right example from the description like "Example shows..".[email]
You raised an issue, number 484[1], regarding numbering of examples in the XOP specification[1]. The editors have numbered the examples 1, 2 and 3 and used these numbers when refering to the examples.[email]
Section 1, it is stated that "As a result, only element content can be optimized". However, the reason why the attribute value cannot be optimized is not clear from the context.[email]
You raised an issue, number 483[1] regarding langauge in section 1 of the XOP specification[2]. The working group agrees that it is not clear from the context why attribute content cannot be optimized. The reason, that an element is used to indicate where content has been optimized, is present in Paragraph 2 of Section 1, but the language you refer to is in Paragraph 5. The two intervening paragraphs make the context unclear. The Working Group will remove the text 'As a result,' from Section 5 so that it reads: "Only element content can be optimized; attributes, non-base64-compatible character data, and data not in the canonical representation of the base64Binary datatype cannot be successfully optimized by XOP."[email]
Section 1, the specification of base64 encoding in XOP is described in terms of base64Binary of XML Schema Part 2, and the definition of base64Binary data type refers to RFC 2045. Since more formal description of base64 has recently been provided as RFC 3548, I propose to use RFC 3548 as the primary reference specification of base64 encoding in XOP.[email]
The XMLP working group declined to adopt your suggestion as XOP requires a canonical form of base64 and RFC3548 does not define such a form. The XML Schema Part 2 specification does define such a form which is why we reference that specification rather than RFC3548.[email]
The creation of a XOP package as described in section 3.1 and illustrated in the example 1.2 converts original base64 encoded data into raw binary octets. It is entirely likely that a large enough sample of binary data will result in content that encodes the same sequence of octets that mark a MIME boundary for the output package. Such aliasing of MIME boundary octets will result in a broken XOP package that cannot be decoded back into the original XML infoset. Proposed solutions: 1) Scan and detect serialised binary data for the chosen MIME boundary separator and define an escaping mechanism to recode the binary data. 2) Scan and detect serialised binary data for the chosen MIME boundary separator and on detection choose a different MIME boundary string and rescan all binary attachments iteratively until no aliasing is detected. 3) Mandate use of the 'Content-Length:' header field in the binary part of the XOP package.[email]
The XML Protocol has decided to close issue 481[1] with no action, because the issues you raise are well-understood and documented consequences of using MIME multipart packaging. Such discussion is more appropriate in a primer or other documentation.[email]
1) Section 2.1, Representation header is not required, but may be useful, when multiple references... 2) Section 2.1 should the space around base64 characters in the example be dropped? 3) Section 2.3.2: does reinsert have the [specified] prop w/value "true"? I believe not. 4) 2.3.2 Example Example - the link to the example should probably be titled otherwise 8-)[email]
You raised an issue (#480) [1] regarding the Representation header [2] LC doc. The WG agreed to classify the issue as editorial and directed the editors to address your comment. Details: >1) Section 2.1, Representation header is not required, but may be >useful, when multiple references... The sentence in question in section 2.1 has been changed to read: "The Representation header block is also useful when multiple references to the same resource are required but duplication of the resource is undesirable." >2) Section 2.1 should the space around base64 characters in the example >be dropped? The space around the base64 characters has been removed. >3) Section 2.3.2: does reinsert have the [specified] prop w/value >"true"? I believe not. Section 2.2.3 (and not 2.3.2) is _not_ changed. The [specified] property value is indeed 'true'. This requires the attribute to be specified and not defaulted. >4) 2.3.2 Example Example - the link to the example should probably be >titled otherwise 8-) The sentence is question is now changed to: "An example of this usage is shown in Example 1."[email][email]
1) section 1.2 needs to be filled 2) Section 2.1 talks about extracted content but makes no reference to XOP or MTOM, a reader new to these specs and starting with Representation header would have no idea what is being talked about. 3) Representation header is not a SOAP module, I think it would be beneficial for describing the messages (say in WSDL) if it had a formal name. 4) in section 2.2, should it be said that namespace-qualified elements and attributes on Rep elements must not be in Rep namespace? 5) section 2.3 should probably be marked informative 6) section 2.3.3, the example should probably be inside rep:Representation element[email]
> 1) section 1.2 needs to be filled It has been filled, see the editors' copy > 2) Section 2.1 talks about extracted content but makes no reference to > XOP or MTOM, a reader new to these specs and starting with > Representation header would have no idea what is being talked about. Fixed, "extracted content" has been replaced by "resource" > 3) Representation header is not a SOAP module, I think it would be > beneficial for describing the messages (say in WSDL) if it had a formal > name. Fixed, the document now defines a SOAP Feature and a SOAP Module. The name of the specification has been changed to reflect that, it is now "Resource Representation SOAP Header Block" > 4) in section 2.2, should it be said that namespace-qualified elements > and attributes on Rep elements must not be in Rep namespace? The schema has been changed to reflect that, see [3] > 5) section 2.3 should probably be marked informative Done (by mean of stating that it is an example) > 6) section 2.3.3, the example should probably be inside > rep:Representation element Done.[email]
1) just before section 2.3.2 add text ...MUST not be optimized >>by implementations of this feature<< 2) 2.3.2 should say "should generate a fault" instead of "should fault" 3) 4.3.1.1 content-tranfer-encoding - missing 's' in transfer 4) 4.3.2 2nd paragraph says "The remaining of this section describes the perturbations", first it should be the "remainder", second there seem to be such formal perturbations, like the ones described in the table in 4.3.1.1[email]
You raised an issue 478[1] on the MTOM specification[2]. The editors have made the following changes(reflected in latest editors copy[3]) > 1) just before section 2.3.2 add text ...MUST not be optimized >>by > implementations of this feature<< Done. > 2) 2.3.2 should say "should generate a fault" instead of "should fault" Done. > 3) 4.3.1.1 content-tranfer-encoding - missing 's' in transfer Done. > 4) 4.3.2 2nd paragraph says "The remaining of this section describes the > perturbations", first it should be the "remainder", second there seem to > be such formal perturbations, like the ones described in the table in > 4.3.1.1 The latter half of Section 4.3.2 has been amended to address this problem.[email]
Section 2.3.2 says receivers must not convert non-canonical representations to canonical, but do they actually have the opportunity? I think this text should be dropped as I don't think it's a good example for the rule before it.[email]
The WG agree with your suggestion that the last sentence of paragraph 2 of Section 2.3.2 should be removed and will make this change.[email]
1) just before 1.1, decapitalize the section numbers in the overview - instead of Section Four say Section four. 2) in 1.1, drop second reference to XML InfoSet 3) xop:Includeelement add space, in multiple places in the spec, same with hrefattribute in multiple places and other similar spacing problems - suggest searching for the pair >< in the XML or for a letter and < with no space in between, I guess. 4) Section 1.2, [media type] link should be filled in 5) Section 1.3 add spacing and/or padding to table to make it more readable 6) Section 2 heading: XOP Infosets Constructs - drop first plural - XOP Infoset Constructs 7) Sections 2.1, 2.2, xop:Include element MUST have the name of Include? Oh, please! 8-) I suggest taking the approach from Representation header spec. 8) Section 2.1 third bullet: ... It MUST NOT change the semantics... "it" is ambiguous, I suggest using "the element" 9) Section 2.1 fourth bullet: hrefattribute information items - space missing, drop 's' at the end (plural items) 10) consolidate spacing in references rfcxxxx and rfc xxxx (with/out space) 11) also, I believe some references are not properly pointing to their destinations (rfc reference in 2.2, third bullet), may be related to the problem above 12) Section 2.2 fourth bullet: its owner must be a xop:include element. period. 13) Section 3 heading: XOP's processing model - drop possessive -> "XOP processing model" 14) Section 3.2 ... has as its [children] a xop:Include... - mismatch of plural [children] and singular element, suggest a bit more verbose version that says that is the only child. 15) Section 3.2: ... replace its [children] with a char info items ... - drop indefinite article 'a' 16) Section 4.1 says the media type of the root part must be specific to XOP encoding of the actual data, 5 mentions application/soap_xop+xml, the example in 1.2 uses text/xml though, should use application/soap_xop+xml 17) Section 6.1 contains unbalanced parenthesis[email]
You raised an issue 476 on the XOP specification. The editors have made the following changes(reflected in latest editors copy) > 1) just before 1.1, decapitalize the section numbers in the overview - > instead of Section Four say Section four. Changed to use Section 4 rather than Section Four ( see[3] ) > 2) in 1.1, drop second reference to XML InfoSet Done. > 3) xop:Includeelement add space, in multiple places in the spec, same > with hrefattribute in multiple places and other similar spacing problems > - suggest searching for the pair >< in the XML or for a letter and <> with no space in between, I guess. Done. > 4) Section 1.2, [media type] link should be filled in Done. > 5) Section 1.3 add spacing and/or padding to table to make it more > readable Done. Made the table 3 columns wide. > 6) Section 2 heading: XOP Infosets Constructs - drop first plural - XOP > Infoset Constructs Done > 7) Sections 2.1, 2.2, xop:Include element MUST have the name of Include? > Oh, please! 8-) I suggest taking the approach from Representation header > spec. Done. > 8) Section 2.1 third bullet: ... It MUST NOT change the semantics... > "it" is ambiguous, I suggest using "the element" Fixed. > 9) Section 2.1 fourth bullet: hrefattribute information items - space > missing, drop 's' at the end (plural items) Fixed. > 10) consolidate spacing in references rfcxxxx and rfc xxxx (with/out > space) Done. ( They now always have a space ) > 11) also, I believe some references are not properly pointing to their > destinations (rfc reference in 2.2, third bullet), may be related to the > problem above Fixed. > 12) Section 2.2 fourth bullet: its owner must be a xop:include element. > period. Done. > 13) Section 3 heading: XOP's processing model - drop possessive -> > "XOP processing model" Fixed. > 14) Section 3.2 ... has as its [children] a xop:Include... - mismatch of > plural [children] and singular element, suggest a bit more verbose > version that says that is the only child. Language amended. > 15) Section 3.2: ... replace its [children] with a char info items ... - > drop indefinite article 'a' Langage amended. > 16) Section 4.1 says the media type of the root part must be specific to > XOP encoding of the actual data, 5 mentions application/soap_xop+xml, > the example in 1.2 uses text/xml though, should use > application/soap_xop+xml Fixed. > 17) Section 6.1 contains unbalanced parenthesis Fixed.[email]
4) Section 4 says any packaging mechanism can be used, but the spec refers to the "root part" in multiple places - should it be said that any packaging mechanism has the notion of a root part?[email]
You raised an issue[1] regarding XOP[2]. The WG agrees with your concern regarding XOP consistency when describing XOP packaging requirements and the notion of a root part. The working group will change the text in Section 4, paragraph 1 to read: "Such packaging mechanisms MUST be able to represent, with full fidelity all the parts created according to 3 XOP's Processing Model (see 3.1 Creating XOP Packages), and MUST be used in a manner that provides a means of designating a distinguished root part." [---] From Jacek Kopecky I'd suggest a small friendly amendment here: Such packaging mechanisms MUST be able to represent, with full fidelity all the parts created according to 3 XOP's Processing Model (see 3.1 Creating XOP Packages), and MUST be used in a manner that provides a means of designating a distinguished root (main, primary etc.) part. Just added the parenthesized part of the last line to explain better that it need not be called "root" part, but XOP calls it that. 8-) [---] From Michael Mahan (on behalf of XMLP WG) The WG has agreed to accept your friendly amendment.[email, email, email]
3) Section 3.1, last sentence, should XOP Infoset be changed to XOP Package here? Content is not encoded into the XOP Infoset after all, it's extracted from it. 8-)[email]
You raised an issue regarding XOP. The WG agree with your suggestion that XML Infoset should read XML Package in the last sentence of Section 3.1 and will make this change.[email]
2) the example in section 1.2 contain white space around the base64 characters, and same below around the xop:Include element, should that be removed? Or should it be pointed out somewhere that such space is in fact insignificant per some spec? Section 3.1 specifies bullet 3 says no space allowed preceding, inline or following the content...[email]
The WG will clarify that elements to be optimized must only contain character information items. The WG will also amend the example to fix the whitespace problems by removing whitespace around the <xop:Include> element and the base64 characters.[email]
1) Section 1.1 defines the term Optimized Content and does not define the term Extracted Content; the rest of the spec uses the latter term in multiple places, I think these terms should be consolidated or the latter defined as different from the former.[email]
You raised an issue 472[1] on the XOP specification[2]. The WG has agreed to use the term Optimized Content rather than a mixture of Extracted Content and Optimized Content.[email]
B.1 References: The reference to RFC 2557 mis-spells one of the authors' name (J Palme).[email]
You raised an issue 471[1] on the XOP specification[2]. This error has been corrected in the latest editor's copy.[email]
Section 1.2:
text/xml for root multipart/related element
The choice of a text/... MIME type for this purpose seems rather, er,
perverse to me. The intent of text/... MIME types is for data content that
can reasonably be read as such by a human user [1]. text/html is regarded
by at least one of MIME's designers as a mistake [2]. I really don't think
that an XML SOAP envelope falls into the category of human-readable
text. I suggest:
(a) use application/xml, or
(b) register a new application/...+xml MIME type for this purpose.
I see in section 5 you describe application/soap_xop+xml, so I guess that's
just a typo in the examples?
Section 5:
Looking at:
[[
For example, if the format identified by "application/soap+xml" is to be
packaged as XOP serializations, then a XOP-specific media type (e.g.,
"application/soap_xop+xml") MUST be registered. A XOP Package using the
Multipart/Related packaging mechanism and serializing such an Infoset would
have a package media type of "multipart/related" and a root media type of
"application/soap_xop+xml".
]]
This seems a bit awkward to me. Has any consideration been given to
defining a single MIME content-type, say application/xop+xml, having a
parameter to specify the original MIME type; hence:
Content-type:
application/xop+xml;original-content-type="application/soap+xml"
Among other things, I think this would make it easier to implement a
completely generic XOP serializer/deserializer since no special knowledge
of any specific MIME type (other than application/xop+xml) would be required.
[email]
The Working Group today resolved to take a modified approach, outlined
below, whereby the type parameter contains a content-type instead of a
media type (i.e., it can contain parameters). This allows such
parameters to "show through" both the root part's type parameter as
well as the package's start-info parameter. It does mean that some
escaping may be necessary, but that was thought an acceptable cost in
exchange for the simplicity of the approach.
* Section 1.2 Example
In Example 2, change:
[[[Content-Type: Multipart/Related;boundary=MIME_boundary;
type=application/soap_xop+xml;start="<mymessage.xml@example.org>"]]]
to:
[[[Content-Type: multipart/related;boundry=MIME_boundary;
type="application/xop+xml";start="mymessage.xml@example.org>";
startinfo="application/soap+xml;action=\"http://www.example.com/
myAction\""]]]
Change:
[[[Content-Type: application/soap_xop+xml; charset=UTF-8]]]
to:
[[[Content-type: application/xop+xml; charset=UTF-8;
type="application/soap+xml;action=\"http://www.example.com/
myAction\""]]]
* Section 3.1 Creating XOP Packages
In bullet 5, change "appropriate XOP-specific media type" to
"application/xop+xml media type"
* Section 4.1 MIME Multipart/Related XOP Packages
Replace the second paragraph with:
"""The root MIME part is the root of the XOP Package, and MUST be a
serialisation of the XOP Infoset using any W3C Recommendation-level
version of XML (e.g., [XML 1.0], [XML 1.1]), and MUST be identified
with a media type of "application/xop+xml" (as defined below). The
"start-info" parameter of the package's media type MUST contain the
content type associated with the content's XML serialisation (i.e., it
will contain the same value as that of the root part's "type"
parameter)."""
* Section 5 Identifying XOP Packages
Replace the section with: """
XOP Documents, when used in MIME-like systems, are identified with the
"application/xop+xml" media type, with the required "type" parameter
conveying the original XML serialisation's associated content type.
Note that when the type parameter contains reserved characters, it
needs to be appropriately quoted and escaped.
For example, a XOP Package using MIME Multipart/Related packaging to
serialise a SOAP 1.2 message [SOAP1.2] with an action parameter of
"http://www.example.com/foo" would label the package itself with the
"multipart/related" media type; the root part's media type is
"application/xop+xml", with a "type" parameter containing
"application/soap+xml;action=\"http://www.example.net/foo\"".
5.1 Registration
MIME media type name:
application
MIME subtype name:
xop+xml
Required parameters:
* "type"
This parameter conveys the content type associated with the XML
serialisation of the XOP Infoset, including parameters as appropriate.
Optional parameters:
* "charset"
This parameter has identical semantics to the charset parameter of
the application/xml media type as specified in RFC 3023 [RFC 3023].
Encoding Considerations:
Identical to those of application/xml as described in RFC 3023 [RFC
3023], section 3.2.
Security Consideration:
In addition to application-specific considerations, XOP has the same
security considerations described in RFC 3023 [RFC 3023], section 10.
Interoperability Considerations:
There are no known interoperability issues.
Published Specification:
This document.
Applications which use this media type:
No known applications currently use this media type.
Additional Information:
File extension:
XOP
Fragment Identifiers:
Identical to that of application/xml as described in RFC3023 [RFC3023]
Base URI:
As specified in RFC 3023 [RFC 3023], section 6.
Macintosh File Type code:
TEXT
Person and email address to contact for further information:
Mark Nottingham <mnot@pobox.com>
Intended usage:
COMMON
Author/Change controller:
The XOP specification is a work product of the World Wide Web
Consortium's XML Protocol Working Group. The W3C has change control
over this specification.
"""
[email]
The examples in the XOP Last Call Draft use the 'text/xml' media type for the XOP Document, and in the type parameter of the package's media type. Instead, a XOP-specific media type should be used. Also, I don't find a direct RFC2119 requirement to use a XOP-specific media type in a XOP Package, which I don't think reflects the wishes of the Working Group. An appropriate place might be item 5 in section 3.1.[email]
The editors have corrected the spec, chaning 'text/xml' to 'application/soap+xml' in examples and adding 'XOP-specific' to Section 3.1 Bullet 5.[email]
While working on MTOM and XOP description, we realized that the name "HTTP Transmission Optimization Feature" was confusing. It is a SOAP feature, i.e. it cannot be used without sending SOAP messages. Yet, its name is very general and doesn't reflect that. It is particularly confusing when considering that one could define a feature which would provide XOP optimization for arbitrary XML over HTTP, which one would probably want to call Generic HTTP Transmission Optimization Feature, or maybe even HTTP Transmission Optimization Feature too. We would appreciate to have this SOAP-specificity reflected in its name. As a matter of comparison, the SOAP Web Method Feature defined in the Part 2 Recommendation, which arguably has a scope of application which is broader than just SOAP, had a name which was pointing out SOAP-specificity.[email]
You raised an issue 468[1] on the MTOM specification[2]. The editors have changed 'Abstract Transmission Optimization Feature' to 'Abstract SOAP Transmission Optimization Feature' and 'HTTP Transmission Optimization Feature' to 'HTTP SOAP Transmission Optimization Feature'.[email]
1. The att:SOAPMessage property should be described as being an XML Infoset ( this is the abstract structure of a SOAP message ) 2. The att:SecondaryPartBag should be a sub-property of the att:SOAPMessage, that is it, and the representations it contains, should be contained entirely within the XML Infoset of the SOAP message. In general, the notion of information being outside the SOAP envelope seems to be problematic, given that the processing model[2] of SOAP is defined in terms of an XML Infoset.[email]
The WG has decided to deprecate the attachment feature document and will be taking no action with respect to this issue.[email]
Log potential issue: Check in HTTP binding that we prohibit DTDs.See F2F minutes, irc log
In response to XML Protocol Last Call issue 395, the WG has decided to adopt the resolution stated in [2][email]
The Problem
-----------
Among the reasons that we have the "next" role is for headers that
carry information to be available to all downstream nodes. One of the
simplest scenarios would be to have such a header that would travel
with the message, to be available to those nodes that "understand" the
header, and to be ignored and passed on by nodes that do not
understand it. As a simple example, I might want to put in the header
indicating the time at which the message was originally sent. More
substantively, I might wish to put in a digital signature, to be
checked by those who care, and ignored but retained by others.
SOAP 1.2 as proposed cannot support these simple scenarios. Why?
Because section 2.7.1[1] makes clear that a forwarding intermediary
MUST remove from the message all headers targeted to it, and can
trigger reinsertion only by processing and understanding a header. In
the case where you don't understand the header, you must remove it.
It's essential to note that we are considering the case of
mustUnderstand='false'; there is no problem with the 'true' case.
Approaches to Resolving the Problem
-----------------------------------
Discussion of this problem has been going on at a low level for
awhile, in part because some of us have been trying to decide whether
the existing specification can somehow be made to do the right thing.
Given that we are in last call, that would obviously be a desirable
approach. So, here I briefly outline some of the approaches that were
considered, and then in the next section I propose one that seems to
some of us to be the best.
It is tempting to ask whether a user might be able to design specific
headers and/or roles that would meet the need. In other words: if I
define a role and some headers to use with it, then I could say that
you wouldn't assume that role unless you knew the specification for at
least one of the headers, and that specification would implement a
feature to change the relay rules for that role. My personal
conclusion is that this is possible in principle, but would not be
practical when one considers the way that most SOAP software will in
fact be built. Reason: the core rules regarding the relaying of
headers are baked into section 2.7.1, and in practice will often be
implemented by general-purpose SOAP middleware. The key point is that
such middleware will in general be written to treat all user-defined
roles identically. Allowing particular roles to change the relay
rules requires that such middleware have pluggable handlers that key
on specific role names, and this is something that few of us
anticipate doing.
There is another alternative which is also coherent, and indeed is
more powerful than the one proposed below, but which seems to be
overkill and would probably take us back to last call. That
alternative would be to introduce a new attribute for use on header
entries along the lines of relayIfNotProcessed='true'. Thus:
<soap:Header>
<nrm:myHeader role="..any role you like..."
mustUnderstand="false"
relayIfNotProcessed="true">
...
</nrm:myHeader>
</soap:Header>
This seems to work, and has the capability of working with any role.
It just seems like more power and complexity than we need to deal with
the specific use case. If we were to get serious about this proposal,
there would be several details requiring refinement, but for now I am
just suggesting that this is not the direction to go.
Another possibility that has been raised would be to change the
default behavior to be: "leave in place any header entries that are
not processed". Optionally, we could additionally define a
relayIfProcessed override if the group felt it to be worth the
trouble. My impression is that some who have considered changing the
default rules like the idea, but some feel that it doesn't meet a need
to have headers that do indeed disappear when unprocessed. For the
record, I quite like the idea, but (a) am not ready to take the lead in
pushing it in the face of any significant opposition and (b) would not
want to go back to last call if this were deemed a serious change--
I'm not sure it is.
[email]
Anyway, having done the above analysis, several of us conclude that: * The use case is important that we must find a way to meet it * The draft as written doesn't give explanation of how * We need a simple, minimally invasive fix to what we have We propose one new builtin role to be called: http://www.w3.org/2002/06/soap-envelope/role/relay . In most respects, this role would be like any other. Any intermediary or ultimate receiver MAY choose to assume this role. The one significant difference, and it is one that we believe has to be baked into the specification from day one (I.e. would be an incompatible change if made later) is that section 2.7.1 will be changed as follows: <original> Forwarding SOAP intermediaries MUST process the message according to the SOAP processing model defined in 2.6 Processing SOAP Messages. They MUST also remove from the SOAP message all SOAP header blocks targeted at themselves, prior to forwarding, regardless of whether these header blocks were processed or ignored. In addition, forwarding SOAP intermediaries MUST also obey the specification for the SOAP forwarding feature being used. The specification for such a feature MUST describe the required semantics, including the rules describing how the forwarded message is constructed. Such rules MAY describe placement of inserted or reinserted SOAP header blocks. Inserted SOAP header blocks might be indistinguishable from one or more of the header blocks removed above. </original> <proposed> Forwarding SOAP intermediaries MUST process the message according to the SOAP processing model defined in 2.6 Processing SOAP Messages. In addition, when generating a SOAP message for the purpose of forwarding, they MUST: * For any processed SOAP header block, as well as for ignored SOAP header blocks targeted to the node using a role other than http://www.w3.org/2002/06/soap-envelope/role/relay: remove the header block prior to forwarding * Retain all SOAP header blocks that were targeted at the forwarding node using the role "http://www.w3.org/2002/06/soap-envelope/role/relay" but ignored during processing. In addition, forwarding SOAP intermediaries MUST also obey the specification for the SOAP forwarding feature being used. The specification for such a feature MUST describe the required semantics, including the rules describing how the forwarded message is constructed. Such rules MAY describe placement of inserted or reinserted SOAP header blocks. Inserted SOAP header blocks might be indistinguishable from one or more of the header blocks removed above. </proposed>[email]
The XMLP WG recognises this is an important issue. It has decided
to introduce a new "relay" attribute. This attribute lets nodes
explitely specify which header block should be forwarded. More
precisely, it indicates which unprocessed header blocks,
targetted at a node assumed by an intermediary, must be forwarded.
In your email, you outlined a similar solution
("relayIfNotProcessed"), although you recommended adopting a
simpler proposal ("relay" role) at this late stage of the
recommandation process.
After carefull consideration and intense discussion, the WG
decided to go for the more elaborate solution, for the following
reasons:
1) The concepts of targetting and forwarding are separate and
should remain so.
2) With your proposed solution, it would be impossible to target
a header block at a user-defined role. A relayable block would
have to always be targetted at the "relay" role, which defeats
the whole purpose of the "role" attribute.
3) Both solutions would result in about the same amount of
changes to the spec anyway.
Since your initial email, you have indicated during at least two
different teleconferences that you would indeed prefer the more
general solution; we thus trust that you will agree with the WG's
resolution. Please let us know asap if you think otherwise.
The WG has also taken this opportunity to introduce a new table
which clarifies and summarizes when and how nodes are allowed to
forward messages.
[email]
The Web Services Architecture Working Group encourages the XML Protocol Working Group to produce a concrete packaging (attachment) specification to validate the SOAP/1.2 Attachment Feature specification. A normative standard for a concrete specification is also important for reference from other standards and specifications and is considered a high priority by the WSAWG. The XML Protocol Working Group may be the most appropriate venue for this work; if not, the Web Services Architecture Working Group will probably recommend that a new Working Group be chartered to do this in the near future because the lack of a concrete specification that can be the basis for interoperable SOAP attachments implementations is a hole in the Web services architecture that needs to be addressed as soon as possible.[email]
The XML Protocol WG has agreed in principle to investigate the creation of a normative specification of a concrete instantiation of the SOAP/1.2 Attachment Feature. It will proceed by conducting due diligence with respect to IPR issues, gathering requirements, etc. It is anticipated that existing specifications will provide a reasonable starting point. The timing of this activity will take into account the higher priority of getting the primary SOAP 1.2 specifications to recommendation.[email]
We are concerned about the interaction of URI addressing schemes to secondary parts and the SOAP execution model which permits various SOAP headers to be inserted and deleted by intermediaries under appropriate conditions (roles must match, software modules must exist, etc.). Are there similarly conditions under which intermediaries may insert and delete secondary parts? For example, are they allowed to create "dangling URIs"? Secondly, is it clear which URI schemes are impervious to insertion, deletion, and modification of secondary parts? For example, might there be a uniqueness problem with IDREFs?[email]
You raised earlier issue 392. The issue contains two parts: [P1] You asked whether intermediaries are allowed to add/remove secondary parts. More generally, you wondered whether there should be an equivalent to our well-known processing model, but one that would apply to secondary parts, not header blocks. [P2] You wondered whether some URI schemes are better adapted to insertion, deletion, and modification of secondary parts. The XMLP WG considers that this issue should be addressed by the AF specification and has decided to incorporate the text below. Regarding part 2, the WG considers that particular URI schemes should not be prescribed or rejected by the abstract AF specification, but by concrete attachment specifications only. [New section in AF document] Intermediary Considerations =========================== A SOAP message can travel through zero or more SOAP intermediaries. This sections describes the requirements posed on SOAP intermediaries supporting this specification. A SOAP intermediary MUST be able to access any secondary part. A forwarding SOAP intermediary MUST in general forward every secondary parts contained in the incoming SOAP message, except when the specification for a processed SOAP header block calls for the part to be removed or changed. An active SOAP intermediary MAY change or remove any secondary part even in the absence of such a mandate. A SOAP intermediary MAY insert new secondary parts. The integrity of references (i.e. URIs) to secondary parts MUST be maintained accross SOAP intermediaries. That is, a URI which resolves to a secondary part in an inbound SOAP message MUST continue to resolve to that part in the outbound message, unless that part was removed by the SOAP intermediary.[email]
The SOAP encoding allows references by IDREFs inside the SOAP envelope. A natural and common way to reference something on the Web is to use a reference to a resource using an http: URI. The Attachment Feature document suggests that such references are to be handled by the Attachment Feature (example 3 in section 6). It is unclear, with the current SOAP Version 1.2 specification, how such URIs would be dereferenced, i.e. as part of the HTTP binding, by the SOAP processor, etc. Some clarity about this example is desired. Also, in such a case where the secondary parts do not travel along with this message, the term "attachment" is awkward to talk about those resources that need to be dereferenced.[email]
At the SOAP WG F2F meeting on October 30th, the WG agreed to resolve this issue by adopting the proposal in [3].[email]
The motivation for the usage of URIs for identifying secondary parts is incomplete. It seems apparent for performance and other reasons that a part will be a representation of a resource. And packaging will enable higher performance. We recommend the XML Protocol Working Group to document the motivations for using the SOAP Attachment Feature, for example with a set of usage scenarios. In some cases, it seems likely a move from use of a resource on the web to adding a part to the package could result in a need to modify the representation of any reference to that resource. For example, a reference in a SOAP element might be <http://example.com/Sound.wav>. My SOAP application now uses some SOAP attachment feature, perhaps MIME. The representation is now identified by <cid:someidentifierforSoundwav>. I have to change the SOAP message to use the new URI. It would seem cleaner if the reference stayed the same, and the SOAP application did not have to modify these references. To avoid this problem, we recommend specifically calling out the DIME features allowing an included part to be identified using its existing URI. For MIME, the text should discuss the inclusion of a content-location header to server the same purpose. This would allow a recommendation along the lines of "applications SHOULD avoid a need to convert references as parts are added to a SOAP message."[email]
The first part of the issue is a general request to explain why and
when using the attachments (rather than links to resources):
" We recommend the XML Protocol Working Group
to document the motivations for using the SOAP Attachment Feature,
for example with a set of usage scenarios."
In AF's doc introduction [1], the 3 bullets give use cases of attachments
from a SOAP point of view. An attachment is a particular part of the
SOAP message. We don't see any further need to give use cases of attachment
along with some particular implementations and particular bindings.
The attachment feature was designed initially to complete the SOAP
specification.
The second part of the issue asks clarifications about how resources
on the web (referenced by a URI) are added as a part (how a change of
reference is handled):
" For example, a reference in a SOAP element might be
<http://example.com/Sound.wav>. My SOAP application now uses some
SOAP attachment feature, perhaps MIME. The representation is now
identified by <cid:someidentifierforSoundwav>. "
We claim that the semantics is not the same when you refer to an external
URI than when you attach a particular representation of that resource (a
snapshot). We allow both external and internal reference to
a resource, which are different usages, but we do not preclude any.
Wrt referencing attachment in general, it is a binding problem and not
an attachment feature issue. It is possible to refer either to external
URIs, either to parts of the secondary bag. The way the URI is resolved
is certainly not in scope of the Attachment feature.
[email]
The section 2 [1] - SOAP Data Model - speaks (among others) about simple and compound values, terminal and non-terminal graph nodes, structs and arrays. It says that a simple value is a terminal graph node and that a compound value is a non-terminal graph node. The latter need not be true, consider an empty struct or array - both are terminal nodes but certainly not simple values. Further, the distinction between terminal and non-terminal graph nodes brings confusion when combined with the newly agreed-on attribute name 'nodeType' (created for issue 231 [2] resolution) because while section 2.2 differentiates terminal and non-terminal nodes and single- and multi-reference nodes while this nodeType attribute introduces a third differentiation. Since the terminal vs. non-terminal node distinction is only used in places where it is used (mostly?) improperly and where what matters is the difference between a simple value and a compound value, represented by a struct node or an array node (these names are introduced in section 2.3), I think the terminal and non-terminal distinction should be removed or replaced by the compound vs. simple value distinction. My opinion is that this would be an editorial change because it only simplifies terminology used in a few places in section 2 and 3 of the Adjuncts.[email]
The Working Group has decided to close the editorial issue 389 using the proposed text [2] (amended in [3]). The issue deals with the distinction of terminal and non-terminal nodes in the Data Model and Encoding in the Last Call draft of SOAP 1.2, which was only used in places where it was unnecessary and/or incorrect. The resolution basically removes the distinction.[email
4. Section 6: We suggest to explicitly reference the equivalence rules used for the URIs when the message parts are identified. (We believe editors meant the URI equivalence rules specified in the URI spec [3]). The fact that XML namespace spec uses different equivalence rules for namespace URIs then the original URI spec causes a confusion among developers on which rules to use in each case of the URIs use.[email]
You raised the following last call issue against the XML Protocol
Attachment Feature document:
"4. Section 6: We suggest to explicitly reference the equivalence rules
used for the URIs when the message parts are identified. (We believe
editors meant the URI equivalence rules specified in the URI spec [3]).
The fact that XML namespace spec uses different equivalence rules for
namespace URIs then the original URI spec causes a confusion among
developers on which rules to use in each case of the URIs use."
Section 6 of SOAP 1.2 Part 1 discusses uses of URIs in SOAP including
determination of a base URI for relative URIs and URI equivalence
rules. We propose to resolve your issue by adding a reference to this
section to the AF document (without duplicating text between Part 1 and the
AF specification). The revised text reads:
* A mechanism by which each part is identified using one (or more)
URI(s), see (ref to SOAP Part 1, 6. Use of URIs in SOAP). The URI
scheme used MAY but need not be the same for all parts. The URI scheme
used for multiple identifiers of a single part MAY but need not be the
same.
Note: the ability to identify a single part with multiple URIs is
provided because, in general, the Web architecture allows such multiple
names for a single resource. It is anticipated that most bindings will
name each part with a single URI, and through the use of base URIs,
provide for absolute and/or relative URI references to that URI.
[email]
3. Sec 2 - Change "can" to "may" in the "Protocol binding specifications can use this URI" to conform to RFC 2119. Unless there is a good reason, we suggest to even change it to "should", so that there is not ambiguity on whether the specific binding uses the soap1.2 attachment feature.[email]
The working group has agreed to close this issue by changing section 2
to be:
<section2>
2. SOAP Feature Name
This Attachment Feature is identified by the URI (see [SOAP Part 1] SOAP
Protocol Binding Framework):
* "http://www.w3.org/2002/06/soap/features/attachment".
</section2>
[email]
2. Prefix att is not defined. QNames of the form att:* are used, but prefix att is not associated with any namespace. Would be good to explicitly associate it in the prose with the URI http://www.w3.org/2002/06/soap/features/attachment[email]
As the consequence of the resolution of another issue, the "att" Prefix is no more used as a Namespace prefix in this document (this is not yet reflected in the spec). Accordingly, the Working Group has decided to solve issue 386 by taking no action.i[email]
1. Conformance clause should be added that would - describe the subject of conformance (a binding specification) - summarizes what does it mean to conform to this specification - List dependencies: describe what other parts of SOAP 1.2 specification/other specifications a binding must conform to in order to conform to this specification[email]
The XMLP WG has agreed to resolve issue 385 by adding a new Conformance section to the Attachment Feature document containing the following text: "This document describes an attachment feature which is an abstract model, and conformance is a property of binding specifications or modules that use this model. A binding specification or a module using this model is conformant if it follows all the requirements of this specification (see in particular 6. Implementation)."[email]
The current definition of a SOAP intermediary says; "A SOAP intermediary is both a SOAP receiver and a SOAP sender and is targetable from within a SOAP message. It processes the SOAP header blocks targeted at it and acts to forward a SOAP message towards an ultimate SOAP receiver." "SOAP message path" is defined as; "The set of SOAP nodes through which a single SOAP message passes. This includes the initial SOAP sender, zero or more SOAP intermediaries, and an ultimate SOAP receiver. "Ultimate SOAP receiver" includes this in its definition; "An ultimate SOAP receiver cannot also be a SOAP intermediary for the same SOAP message" The second definition suggests that the ultimate SOAP receiver cannot itself be a SOAP intermediary. The third point explicitly says this, though with the qualification "for the same SOAP message" (which is unclear). But the first, in the first sentence, would seem to include gateways in its definition, as they meet all three criteria; SOAP receiver, SOAP sender, targettable. At this late stage, I'm only going to ask that the specification be clear about how gateways fit, or don't, as the case may be. P.S. section 2.1 redefines "SOAP intermediary" in the second sentence of the first paragraph, differently than in section 1.4.3. I suggest it be removed from 2.1.[email]
In response to issue 384, the WG has decided to say that SOAP gateways are not SOAP intermediaries and therefore not to introduce the notion of a SOAP gateway into the SOAP spec. The reason is that a SOAP intermediary is defined in terms of a SOAP receiver and a SOAP sender which the WG did not associate with traditional gateway functionality. The WG recognizes that there may be gateways at the level of underlying protocols but the SOAP spec does not provide an architecture for talking about such gateways (see also [1] (Member only)). The WG agrees with your editorial suggestion and will fix the spec accordingly.[email]
While reading Section 7.5.1 [1] and Section 7.5.2 [2] of part 2, it seems that Table 17 [3] is not fully in sync with what the SOAP receiver might generate. A SOAP receiver might generate a 400 HTTP Status code either in its Init state or in its Receiving state. In the first case, the HTTP response contains no SOAP fault and accordingly, the SOAP requestor should transition to the Fail state, while in the second case, the HTTP response may contain a SOAP fault and if this is the case, the SOAP requestor should transition to the Sending+Receiving state.[email]
The proposal is to change the 400 line in Table 17 to take into account both these cases: <proposal> 400 Bad Request If the media type does not correspond to a SOAP message, indicates a problem with the received HTTP request message. This operation SHOULD NOT be repeated with the same message content. The message exchange is regarded as having completed unsuccessfully. Instantiated Property Value context:FailureReason "fail:BadRequest" Next State: Fail If the media type corresponds to a SOAP message, indicates a problem with the received SOAP message. This operation SHOULD NOT be repeated with the same message content. The local binding instance continues to receive the incoming message. Instantiated Property Value context:FailureReason "fail:BadRequest" Next State: Sending+Receiving </proposal>See also email,email.
Rationale for changes: 400 and 500 could both be generated by a server with or without a SOAP fault in the body of the response: table 23 defines responses including SOAP faults for both of these status codes, a HTTP server could also generate either prior to SOAP processing. The current text assumes that 400 will not have a SOAP fault in the body and 500 will have a SOAP fault in the body Proposed changes: Paragraph before table 17. <current> Table 17 details the transitions that take place when a requesting SOAP node receives an HTTP status line and response header. Table 17 refers to some but not all of the existing HTTP/1.1 [RFC 2616] status codes. In addition to these status codes, HTTP provides an open-ended mechanism for supporting status codes defined by HTTP extensions (see [RFC 2817] for a registration mechanism for new status codes). HTTP status codes are divided into status code classes as described in [RFC 2616], section 6.1.1. The SOAP HTTP binding follows the rules of any HTTP application which means that an implementation of the SOAP HTTP binding must understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response must not be cached. </current> <proposed> Table 17 details the transitions that take place when a requesting SOAP node receives an HTTP status line and response header. <new>For some status codes there are two possible next states: Fail and Sending+Receiving. <FriendlyAmendment> In these cases the transition is dependent on whether a SOAP message is present in the HTTP response. If a SOAP message is present, the next state is "Sending+Receiving"; otherwise the next state is "Fail". <FriendlyAmendment> </new> Table 17 refers to some but not all of the existing HTTP/1.1 [RFC 2616] status codes. In addition to these status codes, HTTP provides an open-ended mechanism for supporting status codes defined by HTTP extensions (see [RFC 2817] for a registration mechanism for new status codes). HTTP status codes are divided into status code classes as described in [RFC 2616], section 6.1.1. The SOAP HTTP binding follows the rules of any HTTP application which means that an implementation of the SOAP HTTP binding must understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response must not be cached. </proposed> Table 17 row for 400, adding Sending+Receiving as a possible next state <current> Indicates a problem with the received HTTP request message. The problem can be malformed XML in the request message envelope. This operation SHOULD NOT be repeated with the same message content. The message exchange is regarded as having completed unsuccessfully. </current> <proposed> Indicates a problem with the received request message. </proposed> Table 17 row for 500, adding Fail as a possible next state <current> Indicates that the response message contained in the following HTTP response entity body may contain a SOAP fault. Other internal server errors may be the cause of this status code. The local binding instance continues to receive the incoming message. </current> <proposed> Indicates a server problem or a problem with the received request message. </proposed>[email]
At our editorial meeting last week, the I18N WG realized that some important points were missing from our last call review of SOAP 1.2. In the last call review of the Character Model by the XML Protocol WG, the XML Protocol WG and the I18N WG/IG have been discussing how text normalization should apply to SOAP. For a compact summary of the decisions arrived, see: http://www.w3.org/International/Group/2002/charmod-lc/#C062 However, we have not found any text in the SOAP specs that says that the envelope/headers have to be normalized, nor that it is the responsibility of the payload provider to provide a suitably normalized payload.[email]
The SOAP WG has decided to close issue 373 - Normalisation of text in envelope/header/body. Previous discussions with I18N led the SOAP WG to decide that we would not require normalization of text. See the discussion at http://www.w3.org/International/Group/2002/charmod-lc/#C062[email]
The following comments apply to the document at: http://www.w3.org/TR/soap12-part0/ This seems to be more recent the "editor's latest draft". However, many of the typos are in both documents. There are several inconsistent uses of the article "a" and "an" when they precede acronyms or abbreviations that begin with a vowel sounding letter. * There are about ten instances of "a RPC" and three instances of "an RPC". To me, "an RPC" reads better. * There are four instances of "a URI" and one instance of "an URI". To me, "a URI" reads better. * There is one instance of "an URL". To me, "a URL reads better". Section 2.2.2. In the phrase "... where the purpose appear to be ...", "appear" should be changed to "appears". Section 2.2.2. In the phrase "... the RPC response is returned in the body element of a SOAP message, with is modelled as a ...", "with" should be "which". Section 2.2.2. In the phrase "... which is an enumeration with potential values of 'confirmed', and 'pending' ...", the comma just before "and" should be removed. Section 2.2.2. In the phrase "... thereby making the RPC inependent of any underlying transfer mechanism.", the word "inependent" should be corrected to "independent".[email]
This comment has been incorporated into the editor's copy of the Primer[email]
For some of the multiple-choice assertions, it is not explicitly defined whether the choice must be consistent by the SOAP Node or not. For example, in the section 2.4, assertion regarding mustUnderstand SOAP headers that allows to either process the Header marked as MustUnderstand or generate a Fault message. It is not clear under which circumstances the behavior of the SOAP Node MUST remain consistent.[email, report]
The XMLP WG decided to close issue 371 you raised by adding a sentence to section 2.6 of Part 1. Original Text: "In all cases where a SOAP header block is processed, the SOAP node MUST understand the SOAP header block and MUST do such processing in a manner fully conformant with the specification for that header block." Modified Text: "In all cases where a SOAP header block is processed, the SOAP node MUST understand the SOAP header block and MUST do such processing in a manner fully conformant with the specification for that header block. The successful processing of one header block does not guarantee successful processing of another block with the same fully qualified name within the same message: the specification for the header block determines the circumstances in which such processing would result in a fault."[email]
Embedded in the issue 368. Not defined what can be called a "SOAP Processor".[email, report]
Proposal: The term "SOAP processor" is a leftover from old terminology and should be changed to "SOAP node". It occurs in the status section of part 1 and throughout part 2.[email]
The XMLP WG has decided to close issue 370 with a text change. As you
pointed out "SOAP processor" is not defined. The term "SOAP processor" is a
leftover from old terminology and will be changed to "SOAP node" throughout
Part 1 and Part 2.
[email]
Embedded in the issue 368. Not clear if the implementation is required to implement any of the adjuncts from the Part 2 in order to conform to the SOAP 1.2 specification.[email, report]
Issue 369, covered under resolution of #368[email
There is no dedicated Conformance section that would o Define what is the object of the spec (SOAP Processor) and what is it. o when an implementation could claim conformance to the SOAP 1.2 spec, and what does it mean. o clearly state that Part I is obligatory and any adjunct from the Part II is optional. What combinations of the adjuncts in Part II are allowed. o State explicitly, does the implementation of the Part I that does not use any of the adjunct of the Part II still conform to the SOAP 1.2 specification.[email, report]
Issue 368, within the new conformance section: -- we describe what constitutes (the scope of) an implementation, see also "SOAP node" in the glossary [4]. -- we say when an implementation can say it conforms -- we clarify the requirements for implementing Parts 1 and 2[email
There is no dedicated section that would explain what is in scope and what is explicitly left out of scope of the specification.[email, report]
Issue 367, we have introduced a Conformance section as requested, see [1].[email
We do not oppose the array representation of SOAP RPC invocation. However, we do strongly suggest the use of generic types to support both struct and array parameter paradigms. In fact, it is our opinion that generics should be the ONLY parameter marshalling type. In that way, polymorphic remote methods and remote methods with variable number of parameters can be supported, while providing a similar functionality as parameter marshallings based on structs and arrays.[email]
You asked that SOAP 1.2 include a generic type for structs and arrays. The XMLP WG earlier decided to close Issue 297 by removing generics. The entire rationale for removing generics is available at [1], but an abreviated version is given here for ease of access. Essentially, the XMLP WG is of the opinion that generics are unnecessary in the Data Model. The issue was discussed among the implementors and among the xml-dist-app community without reaching any obvious consensus. In addition, feedback was asked by an ednote in Part 2, Section 2.3. The prevalent feedback was that generics be removed. Finally, XMLP WG implementors have confirmed they would welcome removing generics (with the exception of WebMethods, which prefered to keep generics but did not oppose the decision).[email]
To comment on the Editor's request for comments on "generics": It is our opinion that generics should be kept in the specification. Generics are useful mainly from a practical point of view because generics do not widen the gap between SOAP RPC and SOAP DOC/LIT data models. We believe that abolishing generics only widens this data modeling gap, thereby unnecessarily limiting the expressiveness of the data model of SOAP RPC.[email]
You also asked that generics be kept in the SOAP specification. The XMLP WG earlier decided to close Issue 297 by removing generics. The entire rationale for removing generics is available at [1], but an abreviated version is given here for ease of access. Essentially, the XMLP WG is of the opinion that generics are unnecessary in the Data Model. The issue was discussed among the implementors and among the xml-dist-app community without reaching any obvious consensus. In addition, feedback was asked by an ednote in Part 2, Section 2.3. The prevalent feedback was that generics be removed. Finally, XMLP WG implementors have confirmed they would welcome removing generics (with the exception of WebMethods, which prefered to keep generics but did not oppose the decision).[email]
Section 3.1.5.3 in "SOAP 1.2 Adjuncts" forbids id and ref attribute information items to appear in the same element information item. It is our opinion that this constraint unnecessarily limits the object graph data model. The resulting admissible data model does not allow for "pointer chain" graphs. Details can be found in earlier message[email]
The XMLP WG has decided to close issue 364 (that you raised about
id and ref attributes being mutually exclusive) with no changes to the
specification. The rationale is explained in [2].
[email]
1. It is our opinion that the SOAP RPC return value accessor is ambiguous and imposes unnecessary processing complexities. For details on this issue, please refer to earlier message[email]
The XMLP WG has decided to close issue [1] "RPC return accessor" without taking any action. This issue has been subsumed by the fact that we have dropped the RPC array representation [2].[email]
l) [Part2 3.1.5.2 ref Attribute Information Item] Please change the name of this to "idref". This not only more closely represents the type of the attribute (xs:IDREF), but also avoids cognitive dissonance with the XForms attribute 'ref' (which bears an XPath expression). m) [Part2 3.2 Decoding Faults] id->idref constraint violations are serious problems. Please change 'SHOULD' to 'MUST' on the requirement to signal a fault under these conditions.[email]
If we decide to close issue 326 by qualifying attribute I think part A of this issue can be closed with no action as the XForms ref attribute is unqualified ( and ours will then be qualified ). If we do decide to leave our ref attribute unqualified then we should probably think about changing the name. I propose that we close part b of this issue with no action. The id/idrefs in question are those found in SOAP encoding. The rule does not apply to general ID/IDREFs. In fact, we can't detect general ID/IDREF without schema validation, which is optional anyway.
We divided the issue into two related parts:
Part I:
"l) [Part2 3.1.5.2 ref Attribute Information Item]
The Protocols Workgroup has recently decided to add namespace qualification
to all of our attributes, and in particular to the attribute formerly known
as "ref". We believe that the resulting qualified attribute is
sufficiently distinct as to not cause confusion with XForms. In general,
we name our attributes by their purpose, not their type, and so
respectfully decline to use IDREF as the localname of the attribute.
Part II:
"[Part2 3.2 Decoding Faults]
We note that SOAP processing never depends on validation [3]:
"SOAP does not require that XML Schema processing (assessment or
validation) be performed to establish the correctness or 'schema implied'
values of element and attribute information items defined by this
specification."
Indeed, the soapenc:ref and soapenc:id attributes (the new names) are
provided for SOAP's own purposes. We note further that there are many
reasonable situations in which checking for a match of id and idref might
be inappropriate. For example, the application might determine, perhaps by
processing a header, that it has no need to inspect the encoded data at
all. Making the check a MUST would require the node to check the ID/IDREF
pairs, regardless of whether the data is needed by the application. We
therefore believe that SHOULD is the best description of our intent, which
is that in most cases the correctness of the reference should be checked.
In any case, we specifically decline to associate such checking with a need
to do XML Schema or DTD validation: such validation is allowed as if the
application so desires, but is never required and is considered
non-normative. [4]
[email]
j) [Part2 2.3 Values] We agree with the editorial note which suggests removing "generics". k) [Part2 3.1.4.1 itemType Attribute Information Item] Please change the name of this to "childItemType".[email]
The specific requests that we included in this issue, and their resolution
are:
> j) [Part2 2.3 Values]
> We agree with the editorial note which suggests removing "generics".
The workgroup has decided to accept your suggestion and remove generics
from the design. The only compound values supported will be arrays and
structs.
> k) [Part2 3.1.4.1 itemType Attribute
> Information Item] Please change the
> name of this to "childItemType".
The members of the XML protocol workgroup have decided that itemType is on
balance a better name, and have therefore decided not to adopt your
suggestion in this area.
[email]
i) [Part2 Sections 2-4 & Appendix A (re: SOAP encoding and RPC Representation)] We request that these optional sections be moved into a separate document. We note the success with which XHTML, SVG, CSS, and XPointer have done similar modularization. As written, these optional sections contain optional subsections (and even required subsections), which is unnecessarily complex. As a separate document, the conformance requirements for RPC SOAP can be more clearly spelled out, and the result will be smaller, simpler SOAP specifications.[email]
This issue is a duplicate of earlier issue 198[2]. I propose we close it with no action.
The XMLP WG decided to close issue 360 which you raised with no action
taken as this issue is a duplicate of issue 198 [2], which was closed
before last call [3].
[email]
h) [Part1 A. Version Transition From SOAP/1.1 to SOAP Version 1.2] This section states that SOAP nodes receiving SOAP/1.1 messages either: 1 "MAY process the message as a SOAP/1.1 message (if supported), or" 2 "MUST generate a version mismatch SOAP fault based on a SOAP/1.1 message construct following SOAP/1.1 semantics." Either way, a reference to SOAP/1.1 ([19] in the current document) is required. Since that appendix is not specifically marked "non-normative", the reference would have to be normative, and thus all conforming SOAP/1.2 processors also must implement a portion of SOAP/1.1. Please ensure that conformance to this section of SOAP/1.1 is considered a "feature" for purposes of exit criteria.[email]
At the SOAP WG F2F meeting on October 30th, the WG agreed to resolve issue
359 by adopting the text in
http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0170.html
[email]
g) [Part1 6. Use of URIs in SOAP] "SOAP receivers SHOULD be able to deal with URIs of at least 2048 characters in length" We request that this be a MUST requirement.[email]
Gudge's proposal: this is a duplicate of closed issue 336. See Henrik's proposal
The XMLP WG has decided to close issue 358 without taking any action. This was a duplicate of issue 336 [2], the resolution text was: <_336> The XML Protocol WG considered issue 336 today, an issue that you raised on the SOAP spec's statements about the length of URIs. Rather than having some statement containing overlapping SHOULDs (SHOULD support URIs of arbitrary length and SHOULD support URIs of length 2048), it was felt that the existing text already provided appropriate motivation for handling URIs of arbitrary length. Therefore, no change is being made to the specification. </_336> Quoting directly from an email[3] on the xml-dist-app list: <furtherReasoning> 1) We don't enforce any max number of URIs to be used in a SOAP message which could then be interpreted as saying that we require infinite buffering on a SOAP node. 2) Related to 1), we don't enforce any max size on a SOAP message itself 3) The current text makes it clear that "Any SOAP node MUST be able to handle the length of any URI that it publishes" so we do have a MUST requirement for any given SOAP node. </furtherReasoning>[email
e) [Part1 5.4.6 SOAP Fault Codes] Please change the name of the "DataEncodingUnknown" fault code to the more accurate "SOAPEncodingUnknown". f) [Part1 5.4.8 SOAP mustUnderstand Faults] The name "Misunderstood" suggests that the processor incorrectly attempted to do something. "NotUnderstood" is a more accurate name.[email]
For e) we chose to maintain the name "DataEncodingUnknown" as "SOAPEncoding" can be misunderstood to refer to the specific encoding provided in SOAP 1.2 part 2. The fault code in question can be used with any encoding scheme used. For f) we agreed with the proposal and changed the name to "NotUnderstood".[email]
d) [Part1 5.3.1 SOAP Body child Element] Child elements "MUST have a [namespace name] property which has a value, that is, be namespace qualified." We request removing this restriction for the following reason: Many XML Forms use non-namespaced instance data, and we expect SOAP to become a common source of instance data for such Forms. Thus, a requirement for namespaces would put an unnecessary burden on adoption of both SOAP and XForms.[email]
The XML Protocol WG has decided to close issue 356 by changing the MUST requirement for namespace qualification of SOAP Body content to a SHOULD with a descriptive note explaining the reason for the SHOULD. The resolution text which will be applied to Part1 5.3.1 "SOAP Body child Element" is the following: * * * * * Zero or more information items in its [children] property. Child element information items SHOULD be namespace qualified. NOTE: namespace qualified elements tend to produce messages whose interpretation is less ambiguous than those with unqualified elements. The use of unqualified elements is therefore discouraged. * * * * *[email]
c) [Part1 5. SOAP Message Construct] May a SOAP infoset legally contain comment information items? If yes, where? Please clarify.[email]
The WG resolved this by saying that comments are allowed anywhere in the [document element] but not before or after that element. There are some restrictions in the processing model WRT when comments can be added and/or removed. [2].[email]
a) [Part0 3. Using various protocol bindings] "...an encrypted form." Can you clarify in the text whether you mean 'a fill-out form' vs. "the mode in which a thing exists"? [dictionary.com] b) [Part0 3.1.1. SOAP HTTP GET usage] Please mention that to use an XML SOAP envelope as XForms external instance data, HTTP GET usage (SOAP Response Message Exchange Pattern) is required. At the editors' discretion, you might also mention other similar cases, such as document() in XSLT, etc.[email]
Comment a) has been incorporated into the editor's copy of the Primer[email]