Re: CR112, CR144, and everything

Overall, this looks good (and quite detailed!). I mostly have or 2 minor 
questions.

Comments inside.

JJ.

Philippe Le Hegaret wrote:
> 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.
>   
+1
> 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.
>   
+1
> 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.
>   
Isn't the text you quote above already covered elsewhere (e.g. 
5.10.4.xxx)? Can't we simply drop it?
> 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"
>   
DONE. This was a left-over from a previous editing session.
> RECOMMENDATION: the notion of SOAP Request-Optional-Response as a SOAP
> MEP doesn't exist as far I know
Indeed. (For the curious: the expression Req-Opt-Resp is present in the 
introduction the PR for SOAP 1.2 SE, but was removed in a subsequent 
editor draft.)
> and we map them all to the SOAP Request-Response anyway.
But not to the exact same Req-Resp MEP! (although they share the same 
URI and, probably?, the same behaviour) See my earlier message [3].

[3] http://lists.w3.org/Archives/Public/www-ws-desc/2007Feb/0096.html
> 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.
> ]]
>   
+1
> 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].
> ]]
>   
+1
> 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.† 
> ]]
>   
+1 (assuming you mean replacing the 1st paragaph and deleting the 2nd 
and 3rd).
> 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}.
>   
You mean: keep the above 2 paragraph as is? If so +1.
> 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}.
>   
Ibid. +1 if no change.

JJ.
>
> 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 Thursday, 15 February 2007 14:03:07 UTC