Call for Participation: Rechartered Advanced Message Queuing Protocol (AMQP) TC
The OASIS Advanced Message Queuing Protocol (AMQP) Technical Committee has approved  a revised charter, included below. The TC name, statement of purpose, scope, list of deliverables, audience, IPR mode and language specified in the revision below will constitute the TC's official charter.
The TC will hold its first meeting under the revised charter on 20 November 2012 at 08:00 Pacific time. Submissions of technology for consideration by the TC, and the beginning of technical discussions, may begin no sooner than this first meeting.
OASIS and the TC welcome participation by all interested parties. The eligibility requirements for becoming a participant in the TC at the first meeting are:
(a) you must be an employee of an OASIS member organization or an individual member of OASIS, and
(b) you must join the Technical Committee after the revised charter is published to the TC's home page on 13 November 2012, which members may do by using the Roster "join group" link on the TC's home page at .
Note that everyone who wishes to participate must explicitly join the TC as described in (b) above. Membership under the original charter does not automatically carry over.
Non-OASIS members who wish to participate may contact us about joining OASIS . Instructions for joining the Technical Committee can be found at the "Join This TC" link on the TC's public home page 
Please feel free to forward this announcement to any other appropriate lists. OASIS is an open standards organization; we encourage your participation in our work.
 recharter ballot:
 TC web page:
--- Revised Charter
(1) Charter of the Technical Committee
(a) Name of the TC
OASIS Advanced Message Queuing Protocol (AMQP) Technical Committee (TC)
(b) 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:
- Open internet protocol standard supporting unencumbered (a) use, (b) implementation, and (c) extension.
- Clear and unambiguous core functionality for 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.
- 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.
- 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.
- 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.
- 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 xhttps://www.amqp.org/resources/download.
 OASIS AMQP Version 1.0 Specification http://docs.oasis-open.org/amqp/core/v1.0/amqp-core-complete-v1.0.pdf.
(2) Non-normative information regarding the startup of the TC
(a) Similar Work
Some of the existing messaging protocol standards include ebXML, Web Services Reliable Exchange (WS-RX), and XMPP.
Some of the defining characteristics of AMQP as compared to those protocols are:
- It is a binary protocol that operates directly over TCP (instead of over HTTP).
- It incorporates efficient binary encodings of the protocol (as opposed to XML).
Some of the general characteristics of AMQP are:
- It is API agnostic, but has been designed for integration into existing mainstream messaging and integration technologies including Java Message Service and Microsoft Windows Communication Foundation, so that interoperability between them is possible.
- It has been designed to be used with a broker; providing a safe place to exchange messages with 3rd party systems, and to store and forward messages when the recipient is unavailable.
- It brings together frequently used combinations of message exchange patterns in one protocol (asynchronous publish/subscribe and direct delivery patterns such as queuing) that incorporates message level flow control.
In summary, AMQP sets out to provide efficient, high performance, internet scale business messaging. This translates into: a reliable binary transport for sending and receiving messages over WAN and LAN, that integrates with existing messaging products, but can scale to the needs of modern environments such as "cloud applications".
(b) Date, Time, and Location of First Meeting
The first meeting of the TC will be held by teleconference on Nov 20, 2012 during 8-9am PT. This meeting will be sponsored by Microsoft.
(c) On-Going Meeting Plans & Sponsors
It is anticipated that the TC will meet weekly via teleconference and if needed meet face-to-face every 2-3 months at a time and location to be determined by the TC members. At its first meeting, the TC will setup an on-going meeting schedule and determine who will sponsor these meetings.
(d) Proposers of the TC
(e) Statement of Support
(f) TC Convener
The TC Convener for the first meeting will be Angus Telfer from INETCO Systems Ltd.
(g) Affiliation to Member Section
It is intended that the AMQP TC will continue its affiliation with the AMQP Member Section.
(h) List of anticipated contributions
(i) Frequently Asked Questions (FAQ) relating to the planned scope of the TC
(j) Proposed working title and acronym for the specification(s) to be developed by the TC
Proposed title of the specification: Advanced Message Queuing Protocol
Proposed acronym of the specification: AMQP