W3C home > Mailing lists > Public > public-ws-addressing@w3.org > March 2005

Sketch for request/reply/alternate

From: David Hull <dmh@tibco.com>
Date: Thu, 17 Mar 2005 07:55:17 -0500
To: "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>
Message-id: <42397E35.6020208@tibco.com>
This is mostly like what I've mentioned before, but it puts the reply 
endpoint on the wire as <wsa:ReplyTo> and likewise for [fault endpoint].

    * Instead of [reply endpoint] and [fault endpoint] MAPs, we have an
      [endpoints] MAP (or whatever we want to call it).  This is a set
      of /(qname, /EPR) pairs (not (IRI, qname)).  We pre-define
      wsa:ReplyTo and wsa:FaultTo, which we tie to the usual semantics.
    * Instead of ReplyEndpoint and FaultEndpoint properties in the SOAP
      1.2 module, we have an Endpoints (or whatever) property with the
      same value as the [endpoints] MAP.  I believe the same approach
      used to back-port the current 1.2 module to SOAP 1.1 will work
      here, mutatis mutandis.
    * The Endpoints SOAP property is mapped to one header per pair,
      using the qname element of the pair as the header name.  So the
      wsa:ReplyTo entry becomes the wsa:ReplyTo header, the wsa:FaultTo
      entry becomes the wsa:FaultTo header, and the alt:AlternateReplyTo
      entry becomes the alt:AlternateReplyTo header.
    * Headers other than the pre-defined wsa:ReplyTo and wsa:FaultTo
      carry an attribute identifying them as endpoints.  This allows the
      receiver (and intermediaries) to reconstitute the
      [endpoints]/Endpoints properties without any special knowledge.
Received on Thursday, 17 March 2005 12:55:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:28:24 UTC