1. Name of the TC

   OASIS Advanced Message Queuing Protocol (AMQP) Technical Committee

2. Statement of Purpose

   The purpose of the Advanced Message Queuing Protocol (AMQP) Technical Committee (TC) is to define an open internet protocol for business messaging. Salient business messaging requirements are:

   • Ubiquity
     • Open internet protocol standard supporting unencumbered (a) use, (b) implementation, and (c) extension.
     • Clear and unambiguous core functionality fe6 or business message routing and delivery within internet infrastructure - so that business messaging is provided by infrastructure and not by integration experts.
     • Low barrier to understand, use and implement.
     • Fits into existing enterprise messaging applications environments in a practical way.
   • Safety
     • Infrastructure for a secure and trusted global transaction network.
       • Consisting of business messages that are tamper-proof.
       • Supporting message durability independent of receivers being connected, and
       • Message delivery is resilient to technical failure.
     • Supports business requirements to transport business transactions of any financial value.
     • Sender and receiver roles are mutually agreed upon by counter parties - no possibility for injection of spam.
   • Fidelity
     • Well-stated message queuing and delivery semantics covering: at-most-once; at-least-once; and once-and-only-once aka 'reliable'.
     • Well-stated message ordering semantics describing what a sender can expect (a) a receiver to observe and (b) a queue manager to observe.
     • Well-stated reliable failure semantics so all exceptions can be managed.
   • Applicability
     • As TCP subsumed all technical features of networking, we aspire for AMQP to be the prevalent business messaging technology (tool) for organizations so that with increased use, ROI increases and TCO decreases.
     • Any AMQP client can initiate communication with, and then communicate with, any AMQP broker over TCP.
     • Any AMQP client can request communication with, and if supported, negotiate the use of alternate transport protocols (e.g. SCTP, UDP/multicast), from any AMQP broker.
     • Provides the core set of messaging patterns via a single manageable protocol: asynchronous directed messaging, request/reply, publish/subscribe, store and forward.
     • Supports hub and spoke messaging topology within and across business boundaries.
     • Supports hub to hub message relay across business boundaries through enactment of explicit agreements between broker authorities.
     • Supports Peer to Peer messaging across any network.
   • Interoperability
     • Stable core (client-broker) wire protocol so that brokers do not require upgrade during 1.x feature evolution: Any 1.x client will work with any 1.y broker if y >= x.
     • Stable extended (broker-broker) wire protocol so that brokers do not require upgrade during 1.x feature evolution: Any two broker versions 1.x, 1.y can communicate using protocol 1.x if x<y.
     • Layered architecture, so features & network transports can be independently extended by separated communities of use, enabling business integration with other systems.
   • Manageability
     • Binary wire protocol so that it can be ubiquitous, fast, embedded (XML can be layered on top), enabling management to be provided by encapsulating systems (e.g. O/S, middleware, phone).
     • Scalable, so that it can be a basis for high performance fault-tolerant lossless messaging infrastructure, i.e. without requiring other messaging technology.
     • Interaction with the message delivery system is possible, sufficient to integrate with prevailing business operations that administer messaging systems using management standards.
     • Intermediated: supports routing and relay management, traffic flow management and quality of service management.
     • Decentralized deployment with independent local governance.
     • Global addressing standardizing end to end delivery across any network scope.
3. Scope of Work

   The TC will accept as input the v1.0 Final version of the AMQP wire level protocol specification [1] and will produce OASIS Standard versions of the AMQP core specification including necessary XML renderings.

   Features of the AMQP core specification [2] include:

   • Types - A wire-efficient encoding system involving:
     • "Primitive" type encodings for basic types present in most programming languages
     • "Described" type encodings consisting of descriptor and Primitive type for user defined custom types
     • Format codes for fixed width, variable width, compound, and array type data categories
     • Composite types (encoded either as a described list or a described map) for encoding structured data such as frame bodies
   • Transport - A layered, peer-to-peer transport protocol involving:
     • The following entities:
       • Nodes as named entities for the safe storage/delivery of messages
       • Containers as named entities containing one or more Nodes
       • Unidirectional Links between Nodes, over which messages flow
       • Links over bidirectional Sessions
       • Sessions consisting of two unidirectional Channels flowing in opposing directions
       • Channels over Connections
       • Connections providing connectivity between two Containers
       • Frames for carrying data over Connections.
     • Protocol version negotiation
     • Connection operation including opening, pipelined open, pipelining, closing, simultaneous close, and other connection management mechanisms
     • Session operation including establishing, ending, simultaneous ending, session flow control, session errors, and other session management mechanisms
     • Link operation including naming, establishing, resuming, detaching, reattaching, closing, flow control, synchronous get, asynchronous notification, stopping, link errors, and other link management mechanisms
     • Message operation including sections, fragments, transfers, resuming, and large message transfer.
   • Messaging - Providing interoperable messaging capabilities involving:
     • Message formatting, transfer states, message states, message states at distribution nodes, and behavior at sources and targets
   • Transactions - Coordination, operation, and error handling of transactions
     • Local transactions
     • Multiple transactions per Session
     • Transaction over multiple Sessions
   • Security - Ability to establish an authenticated and/or encrypted transport
     • Use of AMQP in a TLS environment
     • Use of AMQP in a SASL environment

   The TC will also accept technical contributions on extensions to the AMQP core specification [2] and produce OASIS Standard versions of the same, including necessary XML renderings.

   A core extension defines semantics of AMQP endpoints not previously defined by the AMQP core specification. Extensions may be defined in the form of dedicated endpoints, addresses or defined message formats. Extensions must not require the creation of new performatives in the AMQP core transport. The availability or otherwise of a given extension must be expressed through the use of the extension capability mechanisms defined in the AMQP core specification.

   Examples of core extensions may include, but are not limited to:

   • Distributed transactions - support for the coordination of AMQP messaging transactions by an external transaction coordinator.
   • Global addressing - definition of a URI-based addressing scheme and messaging forwarding semantics to enable a global message delivery network.

   Out of scope: Any work not reasonably covered by the Scope of Work section is deemed to be out of scope. Bindings of the AMQP core protocol to alternative transports and mapping from programming language APIs to the AMQP core protocol are deemed to be out of scope and are expected to be covered by a separate TC. Contributions to this TC which are out of scope for this charter may be accumulated and taken into consideration for potential development of a charter for another technical committee that may be created to address future extensions or modifications.

4. Deliverables

   The TC will produce OASIS Standard versions of the AMQP core specification, and core extension specifications, and may then advance them to ISO/IEC JTC 1 through the JTC 1 PAS Transposition Process. The TC expects to produce the OASIS Standard version of some of those specifications by December 2013.

   The TC will maintain previously adopted deliverables and provide minor revisions of those deliverables, in order to clarify ambiguities, inconsistencies, and obvious errors.

5. IPR Mode

   This TC will operate under RF on RAND Terms IPR mode as defined in the OASIS Intellectual Property Rights (IPR) Policy effective 21 June 2012.

6. Anticipated Audience

   The anticipated audience for this work includes:

   • Business messaging users
   • Business messaging middleware vendors
7. Language

   TC business will be conducted in English.

References

[1] Advanced Message Queuing Protocol (AMQP) v1.0 Final https://www.amqp.org/resources/download.

[2] OASIS AMQP Version 1.0 Specification http://docs.oasis-open.org/amqp/core/v1.0/amqp-core-complete-v1.0.pdf.