RE: [client requirements] HTTP properties

something i'm not clear on is how these properties will be reused across 
bindings in which HTTP is being employed.
 
presumably if they are all expressed using F&Ps they can be equally applied 
to the SOAP 1.1 and 1.2 HTTP bindings as well as the HTTP binding ?
 
would it make sense to split the binding into being a combination of
a serialisation and a transport components given most bindings have similar 
layering - i.e. have a common HTTP transport component which can be reused 
in all the bindings which use HTTP as a protocol (application or transport) ?
 
Paul

 -----Original Message----- 
 From: www-ws-desc-request@w3.org on behalf of Jonathan Marsh 
 Sent: Thu 06/05/2004 21:30 
 To: www-ws-desc@w3.org 
 Cc: 
 Subject: FW: [client requirements] HTTP properties
 
 


 At today's telcon, we organized the "probably useful" into two buckets.
 The second bucket represents items that allow a client to determine
 whether or not it can communicate with the Web service - in other words,
 these items describe the requirements a client must follow to
 communicate with the Web service.
 
     - Authentication (and related parameters)
     - SSL
     - Cookies
     - Content Negotiation ?
 
 There was no objection to the idea of describing these requirements in
 WSDL.  The next step is to examine specific proposals for their support.
 
 -----Original Message-----
 From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
 Behalf Of David Orchard
 Sent: Thursday, April 29, 2004 2:56 AM
 To: www-ws-desc@w3.org
 Subject: HTTP properties
 
 
 This message contains a list of HTTP properties that may be of interest
 to WSDL description.  I have provided some starter comments on the
 relative utility of being described by WSDL.  The categories that I used
 are: described by WSDL 2.0, probably useful, probably not useful, not
 useful or applicable (n/a).  In summary, I found roughly: 4 properties
 that are described by WSDL 2.0, 9 probably useful categories, 2 probably
 not useful, and 8 not useful/application.
 
 The properties typically related to messages.  Some may also be related
 to the sender or receiver role and these have generally been noted, ie
 httpversion is property of message sender, and ssl cyphersuite is a
 property of a receiver.  These sender/receiver related properties will
 then be realized in messages in property dependent manner.
 
 In doing this work, I had some insights.  Firstly, there is a
 relationship between a property in a wsdl definition and a property in
 the message for a given feature, ie request-URI.  I'm not sure if WSDL
 would need to describe both in the context of HTTP.   Secondly, HTTP is
 designed for run-time negotiation.  In other words, it is designed as if
 WSDL, or something similar, is not available for a web site and related
 resources.  As a result, various properties that a receiver may wish to
 advertise are covered by run-time negotiation, ie content-type and
 allows.
 
 List of HTTP properties:
 
 Request-Method - described by wsdl 2.0 binding operation webmethod
 property
 
 Request-URI - described by a portion of the wsdl 2.0 binding location
 property
 
 HTTP Version - probably useful to describe in an httpversion property.
 HTTP's version field indicates the version of the message and the
 capabilities of the message sender.  From rfc 2616 "The protocol
 versioning policy is intended to allow the sender to indicate the format
 of a message and its capacity for understanding further HTTP
 communication, rather than the features obtained via that
 communication".  Given that HTTP 1.1 is backwards compatible with HTTP
 1.0, the interesting case is where a receiver wants to advertise that it
 only supports 1.0 features.  See also rfc 2145
 
 Response Status - probably useful to describe only for redirection
 support.  In general, it seems more useful to bind the status to the
 SOAP Fault infoset than to describe in WSDL 2.0.  The case that may be
 interesting from a WSDL perspective is redirection, see below.
 
 Content coding(Accept-Encoding and Content-Encoding) - probably useful
 to describe as the encoding of the content before and after transfer is
 significant to applications. 
 
 Transfer Codings(Chunked encoding) - These is probably useful to
 describe for sending of compressing messages.   WSDL could allow
 definition of codings of input and output messages.  For example, a
 Purchase order submission service that allowed gzip coded message in an
 HTTP PUT could advertise that it accepts either normal or gzip coded
 messages.  Without this feature, a sender that understands gzip would
 have to gzip the PUT and send it, and if it is an error then it send it
 coded normal.  The ability to describe alternate encodings allows
 avoidance of this classic failure followed by retry using downgraded
 message message pattern that has known network performance problems.
 Also, it may be useful to describe support for chunked request bodies so
 that a sender can have a more efficient implementation.
 
 Persistent connections - This is default but not required behaviour of
 HTTP 1.1.  It is probably not useful to describe in WSDL.  For example,
 what should a client do differently for services that support persistent
 connections versus those that don't that is helped by being described by
 WSDL? Though this could be used to advertise "policy" of connections, ie
 the receiver will process N requests and then drop the connection, for
 helping clients optimize.
 
 Redirection - probably useful to describe.  A sender is probably
 interested in design-time knowledge on whether redirection is supported
 by a service. 
 
 Authentication - probably useful to describe, particularly the various
 parameters of authentication.  For example, Basic vs. Digest vs.
 extension mechanism, various parameters such as realm, etc.  There seems
 to be a possible overlap with WS-Security.
 
 SSL - probably useful to describe, but it is probably sufficiently
 described by using URIs with https.  It may be useful if WSDL described
 the properties of SSL, such as cyphersuites and certificate authorities.
 
 From - probably not useful to describe.  WSDL could describe that a From
 field is required in a request, though this doesn't seemed used very
 often.  The HTTP spec specifies that From header SHOULD be a mailto:
 address of the human operator, but it may be interesting to generalize
 this for Web services. 
 
 Caching (Vary, etc.) - probably useful to describe.  This seems
 potentially useful for caching the results of safe retrieval, ie GET
 operations.  WSDL could provide description of the caching properties of
 a service.  The knowledge that the operation results are cacheable could
 be used by a client application for client-side caching.  However, this
 may not be very useful.  If a Web service provides a cacheable
 operation, then the client will know from the resulting http headers.
 This seems like metadata to help a client implementation and the service
 deployment, but is not required for interoperability. 
 
 Content Negotiation (Content-Type and Accept) - probably useful to
 describe, particularly useful for indicating use of the MTOM mechanism.
 An HTTP Web service may want to describe the types that it will return
 for a given URI and then a client can set the accept.  This would
 provide design time information to the client.  However, this doesn't
 seem too useful in general from a Web services perspective.  This allows
 a client and server to negotiate a hypertext format for exchange without
 knowing ahead of time what formats are available.  In Web services, a
 service that wants to return format X versus format Y for a given
 request will typically create multiple methods, ie getX and getY.  It
 might be possible for WSDL to allow the "normal" description of
 operations, ie getX and getY, and then binding operation that binds to
 the two operations to the same binding operation and setting the Accept
 header to either X or Y.  In the case of HTTP GET, the only parameter of
 the operation would be the type requested, and this would be sent as the
 accept header.  Perhaps the binding operation would have an "accept"
 property?  There is also a mismatch between HTTP's use of MIME types and
 WSDL's use of XML Qnames for types.  The Content-type is potentially
 tricky as it be the differentiator on the return, so the receiver would
 have to use it to determine which operation was invoked.  This is
 somewhat similar to function return overloading.
 
 Host - described by a subset of the wsdl location property. 
 
 Content-Range - not useful to describe.
 
 If-* - not useful to describe.  Meant for cache validation of existing
 content, so can't be specified in WSDL.
 
 Max-Forwards - not useful to describe.
 
 Expect - not useful to describe.  The same functionality is provided in
 SOAP. But would it make sense for someone in the SOAP infoset to want to
 put in an Expect that alters HTTP behavior? How much of the transport do
 we want to leak through into the SOAP infoset?
 
 Upgrade - not useful to describe.  This duplicates WSDL functionality of
 bindings where a client can request a different protocol for subsequent
 interactions.
 
 Via - not useful to describe.  This is a run-time informational report
 of what intermediaries a message has passed through.
 
 Warning - not useful to describe. 
 
 Allow - probably not useful to describe.   This seems to duplicate some
 of WSDL functionality as this allows a server to indicate which
 operations are allowed on a given resource.  A service could generate
 Allow headers for resources that WSDL has described as there will be
 sufficient information in the WSDL binding to populate this header.
 This implies the client does not have the WSDL and so this seems of
 limited utility.
 
 Content-Language, Content-Location, Content-MD5, Date, Etag, Expires,
 Last-Modified, Referrer, Retry-After - not useful to describe.
 
 Server, User-Agent - probably not useful to describe.  It might be
 useful to have the software used to implement the Web service identified
 in the messages.
 
 Partial Content - not useful to describe. 
 
 Content-disposition - probably not useful to describe.
 
 PICS, P3P - not useful to describe.  These are straight Policy.
 http://lists.w3.org/Archives/Public/public-p3p-spec/2004Apr/0016.html

 
 SoapAction - described in WSDL SOAP binding.  WSDL SOAP Binding
 SOAPAction property
 
 Cookies - probably useful to describe.  Description could be used to
 indicate support or requirements for the use of HTTP stateful cookies.
 
 WebDAV - probably not useful to describe.   Not used with Web services
 currently, though perhaps it should be.
 
 Delta Encoding - ?

Received on Friday, 7 May 2004 03:52:56 UTC