Doodle of  an HTTP Binding

1    Supported Transport Message Exchange Patterns

This binding supports the following transport message exchange patterns

1.1    One way Correlated

Properties Referenced:

I like this - good start. I'm wondering if it may be better to separate this list into the properties available in each message in the binding (e.g. in your "HTTP client to HTTP server operation" section), rather than lumping them all together. For example, the userref and passwordref properties are only available on the HTTP request message, not the response.

Alternatively, we could define the semantics of each property as "available on messages from the client to the server", but IMHO this will cause more fragmentation of properties and also forces us to have a somewhat rigid framework describing "client" and "server".

The next step, of course, is to define what the semantics behind these identifiers are.

This MEP makes use of the HTTP POST method to exchange SOAP messages and attachments between SOAP processors (Nodes?) resident layered above HTTP client and HTTP server entities.

1.1.1    HTTP Client to HTTP Server Operation

At the HTTP Client:

An HTTP POST request is formed as follows:

POST <requestUri> HTTP/1.1
Host: <requestHost>
Content-Type: text/soap+xml (or whatever)

<entityBody>

Again, I would caution against sections like this unless they're VERY clearly labeled as illustrative; 2616 is authoritative here, and we should allow it to determine how to correctly form a HTTP message. By way of example, there was discussion at the IETF APPS area open meeting in London regarding doing a revision to HTTP, to clean up, clarify, and compact the language there, based on experience. While I doubt that those changes will be evident in this example, they aren't ruled out. We shouldn't assume any authority over how underlying messages are formed.

<requestUri> is derived from the .../msg-prop/message/immediateDestination property.

<requestHost> is the TCP/IP hostname associated with the <requestUri>

<entityBody> is generated as follows.

nit: Instead of generating our own <identifiers>, why not just call out the appropriate sections, and appropriate terms/BNF, from the underlying protocol's specification?

  1. The attachments (if any) held in the value of the ...msg-prop/message/attachments property are transformed into an XML Element Information Item with a localname of "Attachments" and a namespace name of "http://www.w3.org/.../soap/extensions/xml-attachments" according to the conventions defined in [Ref to xml-attachments extension].
  2. An XML Infoset is formed by cloning the Message XML Infoset carried in the value of the  .../msg-prop/message/message property and appending any Attachments Element Information Item that arose in the first step as the last element (document order) contained within the Body Element Information item of the cloned XML Infoset.

    [There is an issue about the representation of the abstract link structure between message and attachments and between attachments, but I'm ducking my head on that]
  3. The resulting XML Infoset is serialised to become the value carried in <entityBody>
  4. The value of the .../msg-props/message/localMsgID is retained for use in processing any resulting HTTP POST response

In the event of a communication failure of the underlying HTTP/TCP infrastructure.... [need some property based  model for reporting failure - generic failure 'code' plus binding specifics for this that really want to know].

In the event that HTTP Basic Authentication is required, the values of the Realm, UserRef and PasswordRef MAY be used to attempt to authenticate the HTTP client.

In the event that [other authentication schemes....]

If an HTTP POST response with a status code of 200 is received as follows:

HTTP/1.1 200 OK
Content-Type: text/soap+xml (or whatever)

<entityBody>

A new message property set is formed from the received <entityBody> as follows:

  1.  .../msg-props/message/attachments is set to NULL
  2. If the XML Infoset carried in the <entityBody> contains an XML Element Information Item with a local name of "Attachments" and a namespace name of "http://www.w3.org/.../soap/extensions/xml-attachments" then the value of the .../msg-prop/message/attachments property is generated from the content of the Attachments Element Information Item according to the conventions defined in  [Ref to xml-attachments extension].
  3. The .../msg-props/message/message property is cloned from the XML Infoset carried in the received <entityBody> having had any included Attachments Element Information Item first removed.
  4. The .../msg-props/messsage/causalMsgId property is set from the value of the .../msg-props/message/localMsgID retained in step 4 above.

At the HTTP Server

...

1.1.2    HTTP Server to HTTP Client Operation

At the HTTP Client

At the HTTP Server

1.2    Request-Response

2       HTTP Intermediary Issues