RE: WSDL 2.0 LC Comments

See below:

> -----Original Message-----
> From: public-ws-desc-comments-request@w3.org [mailto:public-ws-desc-
> comments-request@w3.org] On Behalf Of Jonathan Marsh
> Sent: Friday, May 27, 2005 3:37 PM
> To: public-ws-desc-comments@w3.org
> Subject: RE: WSDL 2.0 LC Comments
> 
> 
> We accept the resolutions to all of the issues except the 5 noted
> below:
> 
> > > -----
> > > Section 2.4.2 RPC Style is unclear as to whether local element
> > > children
> > > may contain extension attributes.  Such attributes should be
> > > explicitly
> > > allowed; for instance as identifiers to enable the element to be
> > > signed
> > > (xml:id, wsu:Id).
> >
> > The WG does not believe the current text precludes extension
> > attributes and closed this issue (LC75f) [9] without action.
> >
> > [9] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC75f
> 
> Our issue text was apparently not very clear.  We commonly sign the
> children of <soap:Body>, and to do this requires the ability to add
> @wsu:Id.  The statement "The complex type that defines the body of an
> input or an output element MUST NOT contain any attributes" precludes
> this.  Please allow at least extension attributes to be added.

The Working Group agreed to modify this requirement as follows:

"The complex type that defines the body of an input or an output
element MUST NOT contain any local attributes.  Namespace-qualified
attributes are allowed for purposes of managing the message
infrastructure (e.g. adding identifiers to facilitate digital
signatures).  These attributes must not be considered as part of the
application data that is conveyed by the message. Therefore, they are
not included in the description of a signature by using wrpc:signature."

> > > -----
> > > Section 2.1.1 and 2.1.2 say that the fault message must be
> > delivered.
> > > This implies that the endpoint does not have the option to
> generate
> > > but
> > > not send the fault.  While always useful for debugging, faults are
> > > sometimes logged but not sent to prevent information disclosure
> and
> > > denial of service attacks.  SOAP 1.2 allows this.
> >
> > The WG agreed to incorporate the proposal at [36] to address this
> > issue (LC76c) [37].
> >
> > [36] http://lists.w3.org/Archives/Public/www-ws-
> desc/2004Nov/0054.html
> > [37] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC76c
> 
> The text in 2.1 Fault Propagation Rules sounds like a best effort must
> be made to deliver the fault. However, as a security consideration, we
> need to allow our customers to turn off all faults.  It's not obvious
> that this constitutes a "best effort."  Please allow a specific
> exemption for security measures.

The WG agreed to add a section on Security Considerations, which you can
find in the text just above
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/att-0128/2005072
0-ws-desc-minutes.html#action03.

> > > -----
> > > Section 3.1: The Application Data Feature should be replaced by a
> > > construct similar to the SOAP header binding extension in WSDL
> 1.1:
> > >
> > > * The intended semantic of the AD property URI suggests an
> > > architectural
> > > commitment beyond any required by SOAP -- application versus some
> > > other
> > > processing layer?  Such distinctions are premature at this point
> in
> > > Web
> > > service development and have unclear implications on
> > interoperability.
> > >
> > > * Wrapping the name of the XML Schema element for a header block
> > with
> > > two elements and two attributes provides little additional
> > > information,
> > > sacrifices readability, and introduces opportunities for errors in
> > > WSDL
> > > generation and parsing.
> > >
> > > * The dataHeaders header block introduces descriptive markup in
> SOAP
> > > messages.  Description languages should not introduce significant
> > > markup
> > > in the instances they describe.
> > >
> > > * The dataHeaders header block implies that endpoints will not be
> > able
> > > to successfully exchange messages unless they agree on a WSDL 2.0
> > > description.  XML Schema does not impose this restriction on the
> use
> > > of
> > > XML.  WSDL 1.1 does not impose this restriction on SOAP messages.
> > > WSDL
> > > 2.0 should not impose this restriction either.
> > >
> > > * The rules for when to include the dataHeaders block and what to
> > > include in it are underspecified.
> > >
> > > * While both the SOAP Module and the missing SOAP header construct
> > > declare a name for a header block (the former a URI and the latter
> a
> > > URI:local name pair), SOAP Module does not provide a structural
> > > description of the header block (e.g., an XML Schema element).
> This
> > > precludes tooling and intermediaries from serializing,
> > deserializing,
> > > and/or validating the header without external header-specific
> > > knowledge.
> > > Such processing has proved useful for the SOAP Body and should be
> > > enabled for SOAP headers too.
> > >
> > > * The declaration of SOAP 1.1 and 1.2 headers in WSDL is currently
> > in
> > > use.  (Microsoft supports this in ASMX.)  We expect this useful
> > > practice
> > > to continue going forward.
> >
> > The WG agreed to replace the AD feature with wsoap:header as
> specified
> > at [38] to address this issue (LC76d) [39].
> >
> > [38] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-
> > adjuncts.html#soap-headers-decl
> > [39] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC76d
> 
> We are generally pleased with the wsoap:Header construct. However, we
> don't see the utility of the mustUnderstand attribute.  Why would you
> put the header in the WSDL if the service didn't understand it?
> Please
> explain or remove this attribute.

The WG was unable to reach consensus to remove this attribute.  David
Orchard has an action to respond to you explaining its rationale.
Please stay tuned.

Received on Monday, 25 July 2005 14:02:56 UTC