CR112, CR144, and everything

OK, here is a try at issue CR112 [1], a proposal to make editorial
changes to a text approved in CR144 [2], and some other
recommendations/comments.

My action item mentions "come up with a more detailed proposal for CR112
if possible". Yes, I believe it is possible, but certainly not easy.
Hopefully, this  proposal makes some sense. Readers should read the
entire proposal before judging each recommendation. I copied a lot of
text from the specification to simplify the task of reviewing the
changes.



5. WSDL SOAP Binding Extension
[[
A subset of the HTTP properties specified in the HTTP binding extension
defined in section 6. WSDL HTTP Binding Extension are present in a SOAP
binding when the SOAP binding uses HTTP as the underlying protocol, for
example, when the value of the {soap underlying protocol} property of
the Binding component is
"http://www.w3.org/2003/05/soap/bindings/HTTP/". These properties MUST
NOT be used unless the underlying protocol is HTTP.† The properties that
are allowed are the ones that describe the underlying protocol (HTTP):

 * {http location} and {http location ignore uncited} on Binding
Operation components, as defined in 6.5 Binding Operations and 6.8.2.2.2
Controlling the serialization of the query string in the request IRI,
respectively.
]]

RECOMMENDATION: Do nothing. This is good.

5.10 WSDL SOAP 1.2 Binding
5.10.2 Description
[[
When the SOAP Message Exchange Pattern is the SOAP 1.2 Response MEP and
the underlying protocol is HTTP, the Binding Operation may use the {http
location} property defined in section 6.4 Binding Operations. When this
property is present on the Binding Operation component, the Endpoint
component also follows the rules for constructing the address from the
{address} property and the {http location} property values.
]]

RECOMMENDATION: we should remove the paragraph entirely. The first
sentence is a repeat of what is in section 5 (see previous
recommendation) and is misleading anyway since we use {http location}
for all SOAP MEPs (see section 5.10.4 below). In the second sentence, I
don't know what it means for the "Endpoint component to follow a rule"
and again the combination of {address} and {http location} are mentioned
in 5.10.4 for the
"http://www.w3.org/2003/05/soap/mep/ImmediateDestination" property.

5.10.3 SOAP 1.2 Binding Rules
[[
HTTP IRI Generation. [...] If the SOAP MEP selected is
"http://www.w3.org/2003/05/soap/mep/soap-response/" then the value of
the SOAP "http://www.w3.org/2003/05/soap/mep/ImmediateDestination"
property MUST be generated using the HTTP binding extension's rules for
generating an IRI for HTTP GET (see 6.8.1 Serialization of the instance
data in parts of the HTTP request IRI). The input serialization format
of application/x-www-form-urlencoded is the only supported serialization
format for HTTP GET in the SOAP Response Message Exchange Pattern.
]]

QUESTION: We map all WSDL MEPs into the SOAP Request-Response MEP in
section 5.10.4, but we stay silent at mapping them into the SOAP
Response MEP. Is that intentional? How do one map the WSDL In-Out MEP
into the SOAP Response MEP? It seems to me that the text we have for
HTTP IRI Generation is in fact meant to define partially that mapping.

NOTE: the remark on application/x-www-form-urlencoded is very subtle.
Section 6.8.1 includes that "Additional rules for the serialization of
the HTTP request IRI MAY be defined by a serialization format" and the
remark triggers the application of section 6.8.2. It also implies that
we don't apply 6.8.2 for other SOAP MEPs since we never mention a
serialization format for them. I don't believe (hope?) we need to change
anything here but readers better read the specification carefully.

5.10.4 Binding WSDL 2.0 MEPs to SOAP 1.2 MEPs

5.10.4.1 WSDL In-Out to SOAP Request-Response
5.10.4.1.1 The Client
[[
The SOAP "http://www.w3.org/2003/05/soap/mep/ImmediateDestination"
property takes the value of the WSDL {address} property, modified by the
{http location} property following the rules described in section 6.8.1
Serialization of the instance data in parts of the HTTP request IRI.
]]
We find the same text in the following sections:
5.10.4.2 WSDL In-Out to SOAP SOAP-Response
5.10.4.3 WSDL In-Only to SOAP Request-Optional-Response
5.10.4.4 WSDL In-Only and Robust-In-Only to SOAP Request-Optional-Response

RECOMMENDATION: Rename section 5.10.4.4 to "WSDL Robust-In-Only to SOAP
Request-Optional-Response"

RECOMMENDATION: the notion of SOAP Request-Optional-Response as a SOAP
MEP doesn't exist as far I know and we map them all to the SOAP
Request-Response anyway. So we should use "SOAP Request-Response"
instead of "SOAP Request-Optional-Response" in the title of sections
5.10.4.3 and 5.10.4.4.

RECOMMENDATION: the text should indicate that {address} is used as a
base URI. Using the new section 6.4.6, I propose the following for each
MEP mapping:
[[
The SOAP "http://www.w3.org/2003/05/soap/mep/ImmediateDestination"
property takes the value of HTTP Request URI, as defined in 6.4.6 HTTP
Request URI, and modified as described in section 6.8.1 Serialization of
the instance data in parts of the HTTP request IRI.
]]

6. WSDL HTTP Binding Extension
6.4 HTTP Binding Rules

RECOMMENDATION: I propose to add a new section 6.4.6 HTTP Request IRI as
follows:
[[
6.4.6 HTTP Request IRI

When formulating the HTTP request, the HTTP Request IRI is an absolute
IRI reference and is the value of {http location} property, resolved
using the value of the {address} property of the Endpoint component as
the base URI (see section 5 of [IETF RFC 3986]).† If the {http location}
property is absent, the HTTP Request IRI is the value of the {address}
property of the Endpoint component. Input serializations may define
additional processing rules to be applied to the value of {http
location} before applying the process of reference resolution, ie before
combining it with the {address} property to form the HTTP Request IRI.
For example, the three serialization formats defined in section 6.8
Serialization Format of Instance Data define a syntax to use the {http
location} as a template using elements of the instance data.

If the HTTP Request IRI uses the https scheme, then HTTP over TLS [IETF
RFC 2818] is used to secure the HTTP connection.

The HTTP Request IRI identifies the resource upon which to apply the
request and is transmitted using the Request-URI, and optionally the
Host header field, as defined in [IETF RFC 2616].
]]

NOTE: the last paragraph was triggered by the following text in section
5.2 of RFC 2616: "   An origin server that does differentiate resources
based on the host requested (sometimes referred to as virtual hosts or
vanity host names) MUST use the following rules for determining the
requested resource on an HTTP/1.1 request: 1. If Request-URI is an
absoluteURI, the host is part of the Request-URI. Any Host header field
value in the request MUST be ignored."

6.5 Binding Operations
6.5.2 Relationship to WSDL Component Model
[[
{http location} OPTIONAL. An xs:anyURI, to the Binding Operation
component. It MUST contain an IRI reference and MUST NOT include a
fragment identifier component.† If this IRI is a relative reference, the
value of the {address} property of the Endpoint component is used as a
base URI to resolve it, as defined in section 5 of [IETF RFC 3986].† As
a consequence, if this IRI is an absolute IRI, the {address} property of
the Endpoint component is ignored. Input serializations may define
additional processing rules to be applied to the value of {http 5. WSDL
SOAP Binding Extension
[[
{http location} and {http location ignore uncited} on Binding Operation
components, as defined in 6.5 Binding Operations and 6.8.2.2.2 location}
before combining it with the {address} property of the endpoint element
to form the HTTP request IRI. For example, the three serialization
formats defined in section 6.8 Serialization Format of Instance Data
define a syntax to use the {http location} as a template using elements
of the instance data.

If the resulting IRI uses the https scheme, then HTTP over TLS [IETF RFC
2818] is used to send the HTTP request.
]]

RECOMMENDATION: This should now read:
[[
{http location} OPTIONAL. An xs:anyURI, to the Binding Operation
component. It MUST contain an IRI reference and MUST NOT include a
fragment identifier component.† 
]]

6.8.1 Serialization of the instance data in parts of the HTTP request
IRI
6.8.1.1 Construction of the request IRI using the {http location}
property

SIDE COMMENT: Do we really need to have a subsection if there is only
one?

[[
Each encoded template (encodedTemplate production in the grammar above)
NOT preceeded in the {http location} property by a "?" or a "#"
character, is encoded as follows:
  [...]

Each uncited element (i.e. each element not referenced in a template),
OR each encoded template (encodedTemplate production in the grammar
above) preceeded in the {http location} property by a "?" or a "#"
character, is encoded as follows:
]]

RECOMMENDATION: Do nothing. I don't think it's good design to have ? or
# in the {address} property and it would complicate the description too
much to be able to describe this, so let's stick with {http location}.

6.8.2.2.3 Serialization in the request IRI
[[
If the {http location} property is not present, or if it is present and
its value does not contain a "?" (question mark) character, one is
appended to the request IRI. If it does already contain a question mark
character, then the value of the {http query parameter separator}
property, if present, or the value of the {http query parameter
separator default} property otherwise, is appended.
]]

RECOMMENDATION: Do nothing. I don't think it's good design to have ? or
# in the {address} property and it would complicate the description too
much to be able to describe this, so let's stick with {http location}.


Philippe

[1] http://www.w3.org/2002/ws/desc/5/cr-issues/#CR112
[2] http://www.w3.org/2002/ws/desc/5/cr-issues/#CR144

Received on Wednesday, 14 February 2007 23:04:15 UTC