Abstract

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.

Status of this Document

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.

Discussion of this document will take place on the public <xml-dist-app@w3.org> mailing list (Archives) as indicated by the email communiation rules provided in the WG charter.

Table of Contents

Issues

1. 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. 

2. 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.

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

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

5. 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. 

6. 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).

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

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

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

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

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

ToDo's

1. Incorporate more terminology from the intermediaries discussion the section on message paths.
2. Probably want to condense the use of the prefix "XML protocol xxxx" throughout.
3. 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 appication based routing.

@@@

1.    Introduction

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.

1.1    Definition of Terms

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

2.    XMLP Abstract Model Overview.

Figure 2.1 below presents an overview of the XML Protocol abstract model. 

Figure 2.1 XML Protocol Model Overview

Figure 2.1 shows 5 nodes. Node 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 xx.

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 Nodes I and V in figure 2.1. The third operation, XMLP_INTERMEDIARY, provides explicit support for intermediary XML protocol nodes such as Node III in figure 2.1.

Nodes 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 Processor at Node 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 Node V in figure 2.1. A similar scenario arises if Node 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 Node 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 Node I has some XML protocol blocks to deliver to Node V. In addition the application at Node I needs to trigger Intermediary functionality at Node III by the inclusion of several XML Protocol Blocks. "XML Protocol Block 1" is targeted at "XML protocol handler (e) " within the application on Node V. Block 2 is targeted at handler(c) which replaces Block 2 with Block 3. Also, the XML protocol application at Node III inserts Block 4 into the message forwarded from Node III to Node V.  Blocks 3 and 4 are targeted at  handlers (f) and (g).

3    XML Protocol Layer Service Definition

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.

3.1.    XMLP_Data Operation

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 layer entity and an XML Protocol Processor:

XMLP_Data.request( To, [ImmediateDestination], [OrigPath], [{Headers}], [{Bodies}], [{Attachments}], [BindingContext]);

XMLP_Data.indication( To, From, [OrigPath], [ActualPath], [{Faults}], [{Headers}], [{Bodies}], [{Attachments}], [BindingContext]]);

XMLP_Data.response( [ImmediateDestination], [OrigPath], [{Faults}], [{Headers}], [{Bodies}], [{Attachments}], [BindingContext]]);

XMLP_Data.confirm( From, Status, [ActualPath], [{Faults}], [{Headers}], [{Bodies}], [{Attachments}], [BindingContext]);

All parameters are detailed in Section 3.4

Figure 3.1 below illustrates the normal use of these primitive at initiating and responding XML protocol applications.

Figure 3.1 XMLP_DATA Operation

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.

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

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.

3.2.    XMLP_UnitData Operation

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 layer entity and an XML Protocol Processor:

XMLP_UnitData.send( To, [ImmediateDestination], [OrigPath], [{Headers}], [{Bodies}], [{Attachments}], [BindingContext]);

XMLP_UnitData.receive( To, From, [OrigPath], [ActualPath], [{Faults}], [{Headers}], [{Bodies}], [{Attachments}], [BindingContext]]);

XMLP_UnitData.status( Status, [{Faults}], [BindingContext]);

All parameters are detailed in Section 3.4

Figure 3.2 below illustrates the normal use of these primitive at the sending and receiving XML protocol applications.

Figure 3.2 XMLP_DATA Operation

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.

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

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.

3.3   XMLP_Intermediary Operation

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

XMLP_Intermediary.indication( To, From, OperationType, [OrigPath], [ActualPath], [{Faults}], [{Headers}], [{Bodies}], [{Attachments}], [BindingContext]]);

XMLP_Intermediary.resend( [ImmediateDestination], Status, [{Faults}], [{Headers}], [{Bodies}], [{Attachments}], [BindingContext]]);

All parameters are detailed in Section 3.4

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 XMLP 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.

Figure 3.3 XMLP_Intermediary Operation

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 Normal XML_Data operation through an intermediary

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.

Figure 3.5 Normal XML_Data operation through an Intermediary (alternate treatment)

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.

Figure 3.6 Normal XMLP_UnitData operation through an Intermediary

Figure 3.7 Normal XMLP_UnitData operation through and Intermediary (alternate treatment)

It is worth noting that the XMLP_UnitData.status is generated from within the XMLP 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.

Section 3.4 Operation Parameters

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.

5.    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 5.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. 

Figure 5.1 XML Protocol Application

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.

5.1    XML Protocol Modules

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.

5.2    XML Protocol Message Routing and Targetting 
        aka Naming and Addressing :-)

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.

Figure 5.2 XML Message Path

The path in figure 5.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.

6.    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.

6.1    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:

BindingContext.Shared    //A substructure for information shared by several bindings
BindingContext.HTTP      //A substructure for information related to HTTP
BindingContext.SMTP      //....

....and so on.

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.

6.2    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.

7.    Security

The XML protocol operates on top of a number of underlying protocols that intrinsically support authentication and/or privacy eg. HTTPS, S/MIME,  SSL/TCP and  IPSEC. Where these underlying capabilities can be controlled fields in the BindingContext may be used to provide the relevant ids, keys and other parameters that may be crucial to the correct operation of the underlying security capabilities.

In addition, higher level techniques may also be used to digitally sign and/or encrypt, check and decrypt  components of an XML protocol message within an XML protocol application (whether sending, receiving or intermediary). We fully envisage the development of XML protocol modules for these purposes.

This section is a bit of a placeholder until we can develop a more robust statement