This document is a strawman proposal for an abstract model for XML Protocol.

The challenge of crafting a protocol specification is to create a description
of behaviour that is not tied to any particular approach to implementation.
There is a need to abstract away from some of the messy implementation details of
buffer management, data representation and specific APIs. However, in order to
describe the behaviour of a protocol one has to establish a set of (useful)
concepts that can be used in that description. An abstract model is one way to
establish a consistent set of concepts. An abstract model is a tool for the
description of complex behaviour – it is not a template for an implementation...
although it should not stray so far away from reality that it is impossible to
recognise how the required behaviours would be implemented.

This document is the work of the Abstract Model Subgroup of the XML Protocol
Working Group listed above. The work has benefited numerous discussions on the xml-dist-app@w3.org
mailing list and from discussions with other members of the XML Protocol Working
Group.

This document is not a W3C Technical Report. It is to be considered a work in
progress and does not imply endorsement by the W3C membership nor by the XML
Protocol WG.

As a work in progress this document represents the current state of the
discussion within the Abstract Model Subgroup and should not be regarded as
representing a position of full consensus amongst the membership of the
subgroup. It is currently under review and discussion by the XML Protocol
WG.

Issues

Many of the terms defined in section 1.1 clone
and/or overlap with terms also defined within the glossary of the
requirements document. The intention is that the definitions and meanings of
these terms will converge and that the definitions will be kept and
maintained in a single document in a way that has yet to be decided upon by
the WG. Duplicated terms have been highlighted by a grey background.

Henrik is concerned that section 3 appears to him
like the definition of an API rather than as an abstract description of a
wire protocol. The concern is not to as whether an abstract description
should be produced or not - it certainly does bring value.

The concern is that rather than taking a
"wire-protocol" approach for defining the abstract model, section
3 seems to take an approach that is more targeted a particular
implementation model. An alternative description of the abstract model could
be cast in terms of XML Protocol concepts such as "XML Protocol
Blocks", "XML Protocol Handlers", and "XML Protocol
Modules" rather than in terms of events.

In addition, Henrik has concerns that the current
model seems to call out specific message exchange patterns like
request/response special cases of interactions instead of providing an
abstraction of how multiple message exchange patterns can be supported
within the XML Protocol.

Fault Handling: Section 3 includes ideas on fault
handling. These are really seeds for discussion and subject to change as the
discussion matures.

The concept of a UNICODE normalisation
intermediary suggest that we might indeed want to allow intermediaries to
modify message content.

The Subgroup feels that the Abstract Model should
be mapped against the various scenario's presented in the requirements
document. This work will not be started before the February F2F.

Fig 2.1 suggest a one-one correspondence between
handlers and blocks. Are handlers allowed to process multiple blocks? (yes)
Is a given block allowed to be processed by multiple handlers? (Yes).

The generation of UnitData.confirm (now
UnitData.status) might need further explanation.

The use of intermediaries in a response path is
not illustrated.

A direct single hop interaction is not shown. This
may give the impression that all operations pass through intermediaries,
which is not the case.

Figure 2.1: would like the handlers to be given
some concrete purposes: eg. Signature generator, Signature checker, Path
handler...

The relation between the terms XMLP Module, XMLP
Block and XMLP Handler may need more work.

ToDo's

Incorporate more terminology from the intermediaries discussion the
section on message paths.

Probably want to condense the use of the prefix "XML protocol xxxx"
throughout.

Paths and Targetting probably need more work. I've left things such that
we could define paths (OrigPath, ActualPath) or so that XMLP
applications can specify ImmediateDestinations which is kind-of
single hop with appilcation based routing.

An abstract model is a useful means to develop a description of a system. It
abstracts away from practical details such as specific API definitions, data
representation, and buffer management. It provides a way to give a precise
description of the externally visible behaviour without being prescriptive of
implementation architecture.

The intended audience for this document initially is the XML Protocol WG
itself. In the longer term it is hoped that the material in this document will
serve as a useful overview and introduction to the XML Protocol and its
framework.

This document makes use of terms defined in the [XMLPReqs].
Additional terms introduced in this document are defined locally in this
section, however, in the long term we anticipate that they will be incorporated
into a single glossary for all documents produced by the WG.

A client or user of the services provided by
the XML Protocol Layer. An XML Protocol
Application may act in the initiating or responding role with respect
to two-way request response operations and in the sending or receiving
roles with respect to one-way operations. XML Protocol Applications may
also act in an intermediary role with respect to both two-way and one-way
operations.

Figure 2.1 shows 5 nodes. Host I, III and V each contain XML protocol application
components, which use the services of the XML
protocol layer, and XML protocol layer components which provide the
services of the XML protocol layer. The services of the XML protocol layer are
abstracted at the upper layer boundary and consist of three operations which
will be described in detail in Section 3.

Two of these operations, XMLP_DATA and XMLP_UNITDATA correspond
to the exchange of messages using two-way request/response and one-way only
message patterns respectively. These two operations are available to sending and
receiving XML protocol applications, such as at Hosts I and V in figure
2.1. The
third operation, XMLP_INTERMEDIARY, provides explicit support for intermediary
XML protocol nodes such as Host III in figure
2.1.

Hosts II and IV are intermediaries that operate within
underlying protocol layers such as HTTP proxies, SMTP message routers and
arguably even IP routers and 802.1 MAC layer bridges.

Figure 2.1 can be used to discuss a number of message exchange
scenarios. For example, the XML protocol Processor at Host III is bound to two, possibly
different, underlying protocols. It could serve merely as a 'helper' to
transition an XML protocol message from one underlying protocol to another in
circumstances where the initiating processor is bound to a different underlying
protocol infrastructure than the receiving or responding node, say Host V in
figure 2.1. A similar scenario arises if Host III is part of an XML Protocol
Firewall that controls the ingress and egress of messages from a given organisation.
In both these circumstances the XML Protocol Handler(s) within the XML protocol application
at Host III need not be present.

If we turn our attention to the operation of the XML protocol applications above the
XML protocol layer boundary. We have a scenario in which
the application at Host I has some XML protocol blocks to deliver to Host V. In addition the application at
Host I needs to trigger Intermediary
functionality at Host III by the inclusion of several XML Protocol Blocks.
"XML Protocol Block 1" is targeted at "XML protocol handler (e)
" within the application on Host V. Block 2 is targeted at handler (h)
and handler (c) which
replaces Block 2 with Block 3. Also, the XML protocol application at Host III
inserts Block 4 into the message forwarded from Host III to Host V. Blocks
3 and 4 are targeted at handlers (f) and (g).

Henrik is concerned that section 3
appears to him like the definition of an API rather than as an abstract
description of a wire protocol. The concern is not to as whether an abstract
description should be produced or not - it certainly does bring value.

The concern is that rather than taking
a "wire-protocol" approach for defining the abstract model, section 3
seems to take an approach that is more targeted a particular implementation
model. An alternative description of the abstract model could be cast in terms
of XML Protocol concepts such as "XML Protocol Blocks", "XML
Protocol Handlers", and "XML Protocol Modules" rather than in
terms of events.

In addition, Henrik has concerns that
the current model seems to call out specific message exchange patterns like
request/response special cases of interactions instead of providing an
abstraction of how multiple message exchange patterns can be supported within
the XML Protocol.

This section focuses on the definition of an abstract interface
between the XML protocol applications and the XML protocol layer. In needs to be
remembered that the layer interface described in this section is abstract - its
purpose is to enable description, not to constrain implementation.

The services provided by the XML protocol layer are modelled as
three operations. Two operations, XMLP_DATA and XMLP_UNITDATA provide services
to the XML Protocol nodes that originate and terminate the exchange of XML
Protocol messages. XMLP_DATA and XMLP_UNITDATA support two-way request/response
and one-way message exchanges respectively.

The third operation, XMLP_INTERMEDIARY provides explicit support
for intermediary XML protocol applications to provide value added services to
messages in transit.

XMLP_Data is a best effort two-way request/response operation which is
modelled by four primitives (events). Each primitive models a transmission, reception
or status event at interface between an XML protocol application and an XML protocol Processor:

The operation is best effort which means that it can fail silently with the
loss of the message in transit. A lost message may have been partially processed
at one or more intermediary XML protocol applications. It may even have reached
the responding XML protocol application and the response may have been
lost on its return path. Both the success or failure of the operation is
reported via the XMLP_Data.confirm primitive. However, there can be
circumstances in which the failure is silent and the XMLP_Data.confirm primitive
fails to be invoked to complete the operation.

XMLP_Data.request: Invoked
by the initiating XML protocol application and directed at the local initiating XML protocol Processor
to start a two-way request/response operation.

XMLP_Data.indication: Invoked
by the responding XML protocol processor and directed at a local responding
XML protocol application to deliver the outbound XML protocol
message.

This primitive is invoked as a result of the arrival of an XML protocol message
from the initiating XML protocol processor (via the underlying protocol layers).

XMLP_Data.response:
Invoked by the responding XML protocol application and directed at the local
responding XML protocol processor to return a response message
to the initating XML protocol application. From the point-of-view of the
responding XML application the operation has completed once this primitive has
been invoked.

Upon receipt of this primitive by the responding XML protocol processor an XML
protocol message is the transferred from the responding XML protocol processor
toward the initiating XML protocol processor (possibly via intermediary XML
protocol processors).

XMLP_Data.confirm:
Invoked by the initiating XML protocol processor and directed at the
initiating XML protocol application.

This primitive is normally invoked to deliver the response message to the initiating
XML protocol application as a result of the arrival of an XML protocol message from the
responding XML protocol processor (via the underlying protocol layers) .

This primitive may also be used to inform of the failure of the
operation in those circumstances when a failure can be reported - some failures
may be silent. From the point-of-view of the initiating XML application the
operation has completed once this primitive has been invoked.

An XML protocol application may engage in multiple concurrent operations with the same or
different intermediary and responding XML protocol applications. These concurrent operations are independent and the
order in which they are processed by the responding and intermediary
applications may be
different from the order in which they are invoked or complete at the initiator.

Failures that arise during message processing at intermediary and responding XML protocol applications result in the inclusion of Faults in both .indication
and .confirm.

Assumes that non-fatal failures at intermediaries are fed
forward so that they can also be fed back as part of the response to initiating
applications. Fault handling remains a open topic of discussion.

This operation may be implemented over HTTP, HTTPS, SSL/TCP, TCP and SMTP.

XMLP_UnitData is a best effort one-way message transfer operation which is
modelled by three primitives (events). Each primitive models a transmission, reception
or status event at interface between an XML protocol application and an XML protocol processor:

The operation is best effort which means that it can fail silently with the
loss of the message in transit. A lost message may have been partially
processed at one or more intermediary XML protocol applications. Both the
success or failure of the operation is reported via the XMLP_UnitData.status primitive. However, there can be circumstances in which the failure is silent
and the XMLP_UnitData.status primitive fails to be invoked to complete the
operation. In these circumstances it may not be possible to determine whether
the message has been delivered to the receiving XML protocol application.

XMLP_UnitData.send:
Invoked
by the sending XML protocol application and directed at the local sending XML protocol processor
to start a one-way transfer operation.

XMLP_UnitData.receive: Invoked
by the receiving XML protocol processor and directed at a local
receiving XML protocol application to deliver a received XML protocol
message.

This primitive is invoked as a result of the arrival of an XML protocol message
from the sending XML protocol processor (via the underlying protocol layers).

XMLP_UnitData.status:
Used to report on the delivery status of the operation to the sending XML protocol application. This primitive may be
used to report to the sending XML protocol application on the success or failure to deliver a message to the receiving
XML protocol application. In general, it is not possible to assert that a
message has been delivered to the intended recipient without engaging in further
interactions. With care it is possible to assert definite failure to deliver
provided that there is no chance of subsequent delivery. From the point-of-view
of the initiating XML application the operation has completed once this
primitive has been invoked.

An XML protocol application may engage in multiple concurrent operations with the same or
different intermediary and receiving XML protocol applications. These concurrent operations are independent and the
order in which they are processed by the receiving and intermediary applications may be
different from the order in which they are invoked or complete at the sending XML protocol application.

Failures that arise during message processing at intermediary XML protocol applications may result in the inclusion of Faults in .indication
and .status primitives.

Assumes that non-fatal failures at intermediaries are fed
forward. Fault handling remains a open topic of discussion.

This operation may be implemented over HTTP, HTTPS, SSL/TCP, TCP and SMTP.

It may be the case that this operation would be better
described by integrating it with the XMLP_Data and XMLP_UnitData operations as
say, XMLP_Data.int_indication, XMLP_Data.int_resend,
XMLP_UnitData.int_indication and XMLP_UnitData.resend. However this would lead
to 4 or even 6 events rather than 2 albeit with the operationType parameter.

The XMLP_Intermediary operation is used at intermediary XML protocol applications to invoke local intermediary processing of the message and to xxxx

The path related parameters are not in the
resend primitive, because... if we do have path as a 1st class notion then they
will be updated en-route by the XML protocol processor and not by the intermediary
application. Likewise, we could prevent the application from updating the
Payloads by not allowing it to return them in the .resend. They are all present
in the .indication so that the intermediary can inspect them. DO WE WANT TO
DEFINE INTERMEDIARIES SO THAT THEY ARE NOT ALLOWED TO MODIFY PAYLOADS?

Figure
3.3 below illustrates the normal use of these primitives at an intermediary
XML protocol application.

This operation effectively interposes the intermediary XML protocol application
in the path between sending/initiating and receiving/responding XML protocol applications.

XMLP_Intermediary.indication: Invoked
by an intermediary XML protocol processor and directed at a local
intermediary XML protocol application to provide the intermediary XML protocol application
the opportunity to perform intermediary processing on a message
in transit.

This primitive is invoked as a result of the arrival of an XML protocol message
at an intermediary XML protocol processor from the underlying protocol layers.

XMLP_Intermediary.resend: Invoked
by an intermediary XML protocol application once it has completed intermediary
processing of a message in transit and directed at the local intermediary XML protocol processor. The intermediary
XML protocol application may
report fatal or non-fatal failure via the Status parameter.

A fatal error in the request leg of an XMLP_Data operation (two-way/request
response) results the premature termination of the operation and the return of
any accumulated (non-fatal errors) and partially processed XML protocol message
toward the initiating XML protocol application.

A fatal error in the response leg of an XMLP_Data operation results in the
silent failure of the operation and the loss of the response message.

Non-fatal errors during intermediary processing result in the accumulation of
faults into the XML Protocol message prior to onward transmission. In an
XML_Data operation, non-fatal faults are delivered to the responding XML protocol application
and may be propagate along the response path back to the
initiating XML protocol application.

The fatal/non-fatal fault handling does not represent
any consensus from the sub-group. It is present merely to start some discussion
of how fault processing might happen in the presence of intermediaries.

Figure 3.4 shows the normal behaviour of an XML_Data
operation through an intermediary in the absence of fatal failures. The three
vertical lines at represent the local XML protocol layer boundaries and the
small arrows above denote the up/down orientation of the boundary. Figure
3.5 below shows and alternate representation of the same scenario.

The scenario depicted in figures 3.4.and 3.5
show just a single intermediary interposed in the operation. Also note that the
path taken by a response does not pass through an intermediary, although it
could.

In a request/response operation it may be necessary to
constrain the intermediaries visited by a response to some subset of those
visited by the request - because the request constructed the channel through
which the response is expected to flow.

Figure 3.6 and 3.7 below offer a similar treatment of
the XMLP_UnitData operation conducted through intermediaries.

It is worth noting that the XMLP_UnitData.status is generated from within
the XML protocol layer. It may indicate anything from the mere fact that the initial
message has been sent by the sending node, that its has been received and/or
sent from the intermediary node or that it has indeed been delivered to the
receiving node. What it means in a given circumstance will depend upon the
capabilities of the underlying communications protocols used to construct the
message path.

This section describes the operation parameters used in the operation
primitives described above.

ImmediateDestination, OrigPath and ActualPath are all
concerned with message routing through Intermediaries. ImmediateDestination is
the means by which Sending/Initiating and intermediary XML protocol applications
can denote the destination of the next hop of a message path - enabling XML
Modules to be defined in the future that can implement path semantics. OrigPath
and ActualPath accomodate the alternate view that path support must be explicit
and visible.

To

An identifier that denotes the XML protocol application
that a message was originally sent to by the initiating or
sending XML protocol application.

.response primitives do not carry a To parameter because the
intended recipient of the response is implicitly the initiating XML protocol application.

From

An identifier that denotes the sending XML protocol application in .indication,
.receive, .status and .confirm primitives.

In .indication and .receive primitives this parameter makes the identity of
the sending/initiating XML protocol application available to the receiving/responding
XML protocol application.

[Intermediaries may
obscure this or we may require that they don't... discuss!]

In the XMLP_Data.confirm primitive this parameter conveys the
identity of the receiving/responding XML protocol application after any redirections that may have
been imposed by underlying protocols.

[Again possibly obscured
by intermediaries...]

In the XMLP_UnitData.status primitive, this parameter conveys the
identity of the XML protocol application to which an XML protocol message was sent after any
redirections imposed by underlying protocols. NB. Further redirections may
occur that cannot be reported.

ImmediateDestination

An identifier that denotes the immediate
destination of an XML protocol message. If unspecified the default value for this
parameter is the value of the To parameter. This enables
sending/initiating, intermediary and responding XML protocol applications
to address the message to the next intermediary on route.

OrigPath

A list of identifiers that denote, in order, the path of intermediaries
that the originating XML protocol application wishes to process a message prior to
delivery to the intended recipient.

We may wish to support the concepts of both strict and
loose sourcerouting of XMLP messages as well as implicit XMLP message
routing. The full route taken by a message may be different from that
requested and not fully known to either initiating or responding
applications. Depending on actual design it may not be possible to
preserve the value of this parameter from .request, .send through to
.indication, .receive.

ActualPath

A list of identifiers that denote the actual path of intermediaries
used between sending/initiating and receiving/responding XML protocol applications. This may differ for
OrigPath due to redirections imposed by underlying protocols. During
two-way operations the full round-trip path may be recorded.

The actual path taken by a message may only be partially
reported and may be entirely inaccesible.

Faults

An optional list of Faults that may accumulate
as a message passes through multiple intermediary XML protocol applications, a responding
XML protocol application and at further
intermediary XML protocol applications on the response leg of a two-way
operation.

Headers

A container for XML protocol blocks that
are intended to be processed by intermediaries.

Bodies

A container for XML protocol blocks that are
intended to be processed solely by the receiving, responding or initiating
XML protocol application.

Attachments

This is a list of attachments that are required to accompany the
message. These attachments are regarded as opaque byte arrays whose
content is preserved between neighbouring XML protocol applications.

Where the underlying protocol(s) natively support attachments these
native facilities will be used in accordance with the appropriate binding
specification. Where there is no native support for attachments in the
underlying protocol, an XML friendly character based transformation will
be applied to carry the attachments within the XML protocol envelope.

From the point-of-view of abstract service definition the actual
mechanism used to transfer attachments is immaterial, however particular
bindings may employ more efficient mechanisms than others.

[NB. This places an obligation on XML protocol binding
specifications to specify how attachments are to be carried.]

BindingContext

This parameter references an abstract structure that carries
information pertinent to the underlying protocol binding(s). For example
it may carry certificates, ids and passwords to be used by the
sending/initiating XML protocol application to authenticate itself and/or to establish a secure channel. At
the responding XML protocol application it may carry the authenticated id
of the principal on whose behalf the operation is being conducted.

If the information present in the BindingContext is inadequate for the
execution of a given service primitive the invocation of that primitive
will fail with a result that indicates why progress was not possible.

BindingContext is optional and if not supplied the local default
binding will be used. In the case of multiple bindings being available,
inbound BindingContext indicates how an inbound message was received and
outbound BindingContext constrains the choice of binding used for a given
operation.

[NB This concept places another obligation on XML protocol binding specifications in that they must enumerate what binding
specific information they require in an outbound BindingContext and what
binding specific information they provide in inbound
BindingContexts.]

Status

In .confirm and .status primitives this parameter indicates
the disposition of the request operation which may be: MessageSent,
MessageDelivered, Unknown and FailedAtIntermediary. The
interpretation of a status value may be augmented by information carried
in the Faults parameter and the BindingContext.

In the XMLP_Intermediary.resend primitive, the Status parameter may
take on the values: Ok, NonFatalFailure and FatalFailure.

OperationType

In XMLP_Intermediary.indication primitives,
this parameter indicates the type of operation being intercepted by the
intermediary. It can take on the values of: UnitData, Request and Response
to denote a XMLP_UnitData operation or the request and response legs
of an XML_Data operation.

4. XML Protocol Applications

An XML protocol application is an entity that makes use of the core messaging
services of the XML protocol. XML protocol applications may initiate, respond or
act as intermediaries in XML protocol operations. Logically, an XML protocol application
contains a number of XML protocol handlers that are responsible for
the applying the processing rules associated with one or more XML protocol
modules. The unit of exchange between XML protocol handlers are XML protocol
blocks.

XML protocol blocks are aggregated into XML protocol messages and may be
targetted at particular XML protocol handlers (see Section 4.2).
Targetted XML protocol blocks are delivered together with the rest of the XML
protocol message which encapsulates them (and its attachments if any)
first to the XML protocol application that contains the targeted handler. The XML protocol application
is then responsible for identifying and dispatching the
targeted XML protocol handlers.

Each handler may succeed, fail non-fatally or fail fatally. It is the
responsibility of the XML protocol application to determine the overall result
of the actions of any XML protocol handlers it invokes and to augment any Faults
structure carried in the ongoing message. In cases where there are multiple
influences on the ImmediateDestination, it is also the responsibility of the XML protocol application
resolve any conflicts.

XML protocol modules are the unit of extension within the XML protocol.
Within this abstract model XML protocol modules reside as components of an XML protocol application. An XML protocol module encapsulates the syntactic
constructs if an extension, known as XML protocol blocks, and the behavioural
rules associated with the generation and processing of an XML protocol
block, which are realised in XML protocol application components known as XML
protocol handlers.

Thus the definition of an XML protocol module requires the definition of the
syntactic structure and semantics of one or more XML protocol blocks and the
definition of the behavioural rules (if any) that apply to the generation and
handling of those XML protocol blocks. An XML protocol handler may provided
support for multiple XML protocol modules.

The XML protocol abstract model for module processing borrows heavily from
the SOAP model. If we go with the current XML protocol terminology, I
would recommend substituting the term "module" for the SOAP term
"actor" in the prose below. I stuck with "actor" here
to maintain familiarity with SOAP.

An XML protocol message consists of zero or more header blocks and one
body block. The main distinction between the header blocks and body
block is that the module that processes the body block has the
responsibility of generating responses if necessary for the message.

SOAP: Same.

Each header has an optional associated id (identifier), an optional
actor and an optional mustUnderstand flag. The body has
an optional associated id (identifier) and an optional actor.
The body must be understood. The id is an ID that identifies the block
for the purposes of reference by other blocks. The actor is a URI used
by the XML Protocol Processor for determining which module to apply to the
block. The mustUnderstand flag has value "1" if the
matching module must carry out the intended semantics of the block or fault
and "0" (the default) if it can silently fail.

SOAP: SOAP is ambiguous as to whether actor URI's are to be
interpreted extensionally as destinations/nodes/places or intensionally as
applications/modules/capabilities.

There are reserved actor URI's with special significance: http://.../none
// matches no module (i.e., an untargeted header)
http://.../next //
matches a default module at the next processor
http://.../final //
matches a default module at the final processor
http://.../body //
matches the module selected at the final processor (can be used as a target
for headers)

An empty actor defaults to http://.../body.

SOAP: An empty SOAP actor in a header "indicates that the
recipient is the ultimate destination of the SOAP message," and a
"body entry is semantically equivalent to a header entry intended for
the default actor." This is SOAP talking rather extensionally, as
though there were only one reasonable default module at the destination.
This is what http://.../final designates.
There is no correspondent in SOAP for none
or body. next
is the same as for SOAP. It appears that the actor for a SOAP body
always defaults in the receiver. This is not as flexible as permitting
the message to specify an actor (a module) for processing the body.
Since headers can be targeted to http://.../body,
it might be wise syntactically to ensure that the body actor is known
earlier than the body header, perhaps as an envelope attribute.

When a header is selected for processing by a module at an intermediary,
the header is removed from the envelope. The process API enables a
module to add zero or more headers that will replace the processed header in
the same relative position in the message.

SOAP: Similar, but SOAP doesn't specify where the new headers are to be
inserted.

The XML protocol message blocks are ordered. By using that same
ordering for processing the locally targeted blocks, a limited facility for
specifying sequential constraints is provided. An extensibility
mechanism is available for more complex orderings and constraints.
Headers can function as manifests to direct further processing. The
"manifest module" associated with such a header can refer to other
blocks by their id's. The processor API allows a such a "manifest
module" to access other headers by id and to process a header with a
specified module. Blocks can be shared among several modules by
having these modules reference them by id. [An open question is
whether referenced blocks must be untargeted (have actor http://.../none)
or whether they could also be targeted. If a targeted block is
processed by its actor and removed at an intermediary, it would create a
dangling reference for any unprocessed header that linked to it.
Untargeted headers would not be subject to automatic removal. It is
another open question as to whether the processor API should permit a module
to remove an untargeted header.]

SOAP: The SOAP spec doesn't make it clear, but apparently headers with
no actor can be referenced via links from other headers and they are not
removed at intermediaries which reference them. Using that mechanism,
headers can be effectively shared among modules, even at different nodes.
The body can only be processed by the ultimate recipient.

The processing of a header may result in a fault or a successful
evaluation. A fault terminates processing and causes a return message
containing the fault to be generated if a return path is available. It
is possible for a module that processes a header to have status information,
non-fatal errors, or other results incorporated into the return value
generated by the ultimate recipient. It can accomplish this by
inserting headers which are targeted to http://.../body.

SOAP: Similar.

The composition of modules is an important property. For example,
independent modules might do decompression, decryption, and some
application-specific computation. Let M1(M2(H)) represent the
application of module M1 to the result of applying M2 to header H. The
sender wants to specify the composition of applyX(decryption(decompression(H))).

One mechanism for accomplishing M1(M2(H)) is to have M2(H) replace H with a
header H' targeted at actor M1. This fails, however, if M1 and M2 are
both implemented at the same node. One solution is to immediately
process any headers targeted at modules of the current node before
continuing to process the remaining blocks.

SOAP: SOAP does not permit module composition at the same node.

The above approach to composition suffers from requiring the cooperation
of M2 for targeting M1 at its result. M2 might not always be followed
by M1. It would be preferable to allow the original sender who knows
how the header data was constructed to specify the composition. One
way to do this is via a manifest that describes the composition.

Within the XML protocol there are two entities that need to be addressed or
targeted. XML protocol applications and XML Protocol Handlers. It will be
apparent from the preceding discussion that within this abstract model XML
protocol handlers are deemed to reside within or operate as part of an XML protocol application. This implies that the targeting of a particular XML
protocol block at a particular XML protocol handler, implicitly targets the XML
protocol message at the XML protocol application that contains the targeted
handler.

There are several ways in which an XML protocol block may be targeted at an
XML protocol handler:

Needs to use some terms here that arise from the
intermediaries thread Martin started

A XML protocol mesage path can be viewed as the sequence of handlers that an
XML protocol message passes through between initiating/sending XML protocol application
and receiving responding XML protocol application. With reference to
figure 2.1, the diagram in figure
5.2 depicts the message path of the corresponding XML protocol message under
the XML_UnitData operation.

The path in figure 4.2 shows sequential handler
processing at the sending node, Node I, while the handler processing at Nodes
III and V is concurrent (at least logically). Combinations of handlers that can
be invoked concurrently from within an XML protocol application are said to be
mutually orthogonal.

5. Underlying Protocol Bindings

It is the intent that the XML protocol be capable of being bound to a variety
of underlying communication protocols. The XML protocol working group will
define a binding to HTTP. It is anticipated that others will create bindings to
SMTP, TCP, SSL, BEEP and others.

This entire subsection is new and has not be subject of
significant debate. It should be regarded as a work in progress.

5.1.1. Introduction

This section presents an abstract service model that XML protocol bindings
will supply to the upper XML protocol layer. The intent is to describe the
interactions between the XML protocol processor and underlying protocol bindings
and to demonstrate how these interactions are correographed to enable multiple
message exchange patterns. This model is intended to provide a framework in
which the development of concrete binding specifications can be discussed. This
is not intended as an API specification.

The diagram below shows a logical layered view of the binding model with the XML protocol processor
being bound to four underlying transports.

This document concerns itself with the interactions at the solid black line
between the XML protocol processor and a given binding.

5.1.2. Service Primitives

5.1.2.1 Message Exchange

There are two primitives associated with message exchange: MSG.req
and MSG.ind. A MSG.req
primitive is sent from the XML protocol processor to the binding in order to
cause the binding to send a message. A MSG.ind
primitive is sent from the binding to the XML protocol processor to indicate
arrival of a message.

[Question: do we also need a MSG.confirm to primitive
sent from the binding to the XML protocol processor to indicate successful
transmission or is ERR.ind sufficient for informing of failure]

5.1.2.2 Message Correlation

In order to support message exchange patterns that are more complex than the
simplest one-way exchange, some form of message correlation is required. For
example, in a request-response message exchange there must be some means of
correlating the request with the response. In this document a single instance of
a message exchange pattern is referred to as an XML protocol processor operation
or just operation for short.

There are four pairs of primitives associated with operation delineation and
hence message correlation:

OP.start-req and OP.start-conf

A OP.start-req primitive is sent from the XML protocol processor
to the binding to request initialisation of a new correlated message
exchange. The binding responds with a OP.start-conf
primitive.

OP.start-ind and OP.start-resp

A OP.start-ind primitive is sent from the
binding to the XMPL layer to indicate that a new correlated message exchange
is being requested. The XML protocol processor responds with a OP.start-resp
primitive.

OP.end-req and OP.end-conf

An OP.end-req primitive is sent from the XML protocol processor
to the binding to terminate a correlated message exchange. The binding
responds with an OP.end-confprimitive. Whilst
the OP.end-conf is outstanding, the XML protocol processor
must be prepared to continue to receive MSG.inds

OP.end-ind and OP.end-resp

An OP.end-ind primitive is sent from the
binding to the XML protocol processor to indicate that a correlated message
exchange is to be terminated. No further MSG.ind
will be delivered as part of the corresponding operation, however the XML protocol processor
receiving the OP.end-ind primitive may
continue to issue MSG.req primitives to
complete operation in progress. Once all MSG.req
primitives associate with the operation have been issued the XML protocol processor
concludes the operation by with the invocation of an OP.end-resp
primitive."

The actual correlation mechanism is underlying protocol and implementation
specific. e.g. A OP.start-confmay carry some
unique identifier that must be provided with any subsequent MSG.req(s)
and is included with any subsequent MSG.ind(s).

There is no retained state within the binding between operations although
there may be during operations.

5.1.2.3 Errors

The final primitve ERR.ind is sent from the
binding to the XML protocol processor when an error occurs. E.g. if a MSG.req
cannot be honoured then an ERR.ind is generated.
Errors are correlated to a particular message exchange using the mechnanism
described above.

5.1.3. Message Exchange Patterns

The following sections illustrate the correography of XML protocol binding
primitives for a number of different message exchange patterns.

5.1.3.1 One Way Message

Sender

OP.start-req, OP.start-conf,
MSG.req, OP.end-req,
OP.end-conf.

Receiver

OP.start-ind, OP.start-resp,
MSG.ind, OP.end-ind,
OP.end-resp.

Comments

Note that depending on the underlying protocol the primitives at sender and
receiver may not operate in lock-step. In particular, the OP.start-ind
may not be delivered to the receiving XML protocol processor until the sending XML protocol processor
has issued the MSG.req or even the OP.end-req.
An alternative way of saying this is that a binding may choose to delay making
an underlying protocol connection until a message needs to be sent.

5.1.3.3 Request and n Responses

5.1.4. Sample Mappings

5.1.4.1 HTTP

The following tables show how the binding primitives might map onto the HTTP
protocol actions on the initiator and responder for a request-response message
exchange, time increases moving down the tables.

[These would probably be better as diagrams]

Initiator

Binding Primitive

Binding Action

OP.start-req

Confirm address validity

OP.start-conf

MSG.req

Send POST data

Receive POST results

MSG.ind

OP.end-req

Close connection

OP.end-conf

Responder

Binding Primitive

Binding Action

Receive POST data

OP.start-ind

OP.start-resp

MSG.ind

MSG.req

Send POST results

Receive connection close

OP.end-ind

OP.end-resp

The above assumes use of the HTTP Connection:
keep-alive header

5.1.4.2 SMTP

The following tables show how the binding primitives might map onto the SMTP
protocol actions on the initiator and receiver for a simple one-way message
exchange, time increases moving down the tables.

[Again, these would probably be better as diagrams]

Initiator

Binding Primitive

Binding Action

OP.start-req

OP.start-conf

MSG.req

Send mail message

OP.end-req

OP.end-conf

Responder

Binding Primitive

Binding Action

Receive mail message

OP.start-ind

OP.start-resp

MSG.ind

OP.end-ind

OP.end-resp

5.1.5. Binding Considerations

Underlying protocols may provide various levels of functionality to the
binding. It is the responsibility of the binding to implement a mapping between XML protocol
service primitives and underlying protocol primitives. The mapping should make
the best use of the facilities of the underlying protocol and maximise
efficiency where possible. E.g. connection setup is generally an expensive
operation - bindings for connection oriented protocols should attempt to
minimise the number of connections made for a given message exchange pattern. In
particular, when defining a mapping the following need to be specified:

Protocol

The binding should identify the exact protocol to which XML protocol is
being bound including a version. Examples might be HTTP/1.1 or SMTP[RFC821].

Addressing

The binding needs to show how to specify an XML protocol processor's
address with an URL. 3) Message Passing The binding needs to specify
unambiguously how to use the underlying protocol to pass a whole XML
Protocol message (or a MIME envelope) to a node specified by a given
address. Depending on the underlying protocol capabilities, the
specification may need to detail the following:

Use of underlying protocol primitives for sending and receiving
messages.

Use of underlying protocol headings and/or MIME headings.

Underlying protocol connection management including roles of initiator
and responder, how to handle abnormal terminations, can responder
terminate connection, etc.

Message Exchange Pattern(s)

The binding needs to specify how underlying protocol sessions are used in
common message exchange patterns including one-way and request-response. [Question:
what other message exchange pattern should we specify here ?]

Here, protocol session means a unit of communication in the underlying
protocol, in HTTP this maps to a single request/response, in SMTP a session
only covers a single act of sending a message or a single act of receiving a
message. In BEEP the session would possibly map to a channel that would be
capable of many different message exchange patterns.

Message Ordering Characteristics

The binding needs to specify what message ordering characteristics the
underlying protocol supports. e.g. If two messages are sent in the same
direction in the same session is their order or arrival guaranteed to be the
same as the order in which they were sent.

Error Handling

The binding needs to specify how errors in the underlying protocol will be
handled. A non-exhaustive list of things to consider here is: connection
errors, addressing errors, message transmission errors, abnormal
termination. [Question: what other types of error do
we need to consider ?]

5.2 BindingContext

Each of these underlying protocols supports different features and
capabilities and it is not plausible or desirable to provide a detailed
abstraction that captures the full range of diversity. The core of XML protocol
in respect of the exchange of XML protocol messages takes a lowest common
denominator approach by regarding the underlying channel as potential lossy and
capable of mis-ordering and duplication. Underlying protocols may offer better
assurances of delivery probability, delivery ordering and at-most once delivery
behaviour.

In the service abstraction provided above, an abstract parameter known as
BindingContext is introduced. The primary purpose of BindingContext is to act as
a collecting 'bucket' for parameters that control the functionality of the
particular set of underlying protocols available at any given node.

It is expected that the authors of XML Protocol binding specifications will
add structure beneath BindingContext to cover the features and capabilities of
the underlying protocol being bound. This may also include a descriptor of the
ordering, loss and duplication properties of the underlying protocol, although
this should be treated with caution in multi-hop scenarios.

Some BindingContext extensions may be of more general applicability than just
a single binding. For example, the references to user ids, private keys and
public certificates necessary for SSL and HTTPS could be shared between both
bindings (were they to exist).

One would therefore expect the structure under BindingContext to grow along
the lines of:

The manipulation of fields within the BindingContext may be driven from
within, for example, an intermediary XML protocol application on the basis of
constructs carried as XML protocol message blocks within the message being
carried.

Hopefully this captures the general idea behind BindingContext...
the details will evolve over time... indeed they will evolve as bindings get
described.

5.3 Attachment of Arbitrary Content

This topic is subject to active discussion and the view
presented here is *very* preliminary. There is likely be considerable diversity
of viewpoints that are not captured let alone resolved here.

Another role of an XML protocol binding is to invoke the services of
underlying protocols and to introduce any mechanism required to map between the
semantics of the underlying protocol and those of the XML protocol core message
delivery operations XMLP_Data and XMLP_UnitData. The attachment of arbitrary
content to an XML protocol message is one facet of this mapping.

The core XML protocol messaging services intrinsically handle arbitrary
attachments through the use of the Attachments parameter. The expectation is
that the design of XML protocol WILL specify a means for encoding arbitrary
content and carrying it within an XML protocol envelope. This mechanism will leverage
any
pre-existing work within XML Schema, and will also provide mechanisms for
embedding complete, arbitrary, XML documents within the outer XML protocol
message envelope (itself an XML construct).

Some underlying protocols will support more efficient ways of carrying
arbitrary content and or multiple XML documents. The normative bindings to an
underlying protocol MUST define the mechanism used by that binding to carry
attachments containing arbitrary content. In the absence of any statement to the
contrary in the definition of a particular protocol binding, the default XML
based encoding for arbitrary content attachments will be taken as having been
specified. Any other scheme specified for a particular binding must have
functional capabilities at least as capable as the default XML based encoding
scheme, in particular it must be possible to reference the individual
attachments from within the XML protocol message envelope.

There is an issue as to whether something like SOAP1.1 over
HTTP and SOAP 1.1 with attachments over HTTP constitute two distinct bindings or
whether they should be amalgamated as a single binding over HTTP. XML protocol
will likely have to face the same question. A distinction would be, in the case
of a combined binding, the inbound side of the binding at least would have to
support both forms, although the outbound side could make a fixed
(implementation dependent) choice one way or the other. If we choose the two
distinct bindings route we have two no-interoperable bindings - ie. there would
need to be an interworking (helper) unit of some description in the
message path translate the underlying protocol envelope between bindings. By
analogy, an XMLP 1.0 over HTTP would not be capable of directly ingesting an
XMLP 1.0 with Attachments envelope without help.