OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oasis-charter-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [oasis-charter-discuss] OASIS Advanced Message Queuing Protocol(AMQP) Technical Committee


I note that under deliverables it states:

"...Following that, the TC may advance the OASIS Standard version of the AMQP wire level protocol specification to ISO/IEC JTC 1 through the JTC 1 PAS Transposition Process."

Yet this charter does not mention anything about testing. One would hope that some testing deliverables are planned before going to OS and proceeding to JTC1!
I would like to see the charter elaborate on this topic please.

Cheers,
  Martin.

> -----Original Message-----
> From: Chet Ensign [mailto:chet.ensign@oasis-open.org]
> Sent: 10 August 2011 18:41
> To: tc-announce@lists.oasis-open.org; oasis-charter-discuss@lists.oasis-
> open.org; members@lists.oasis-open.org
> Cc: Staff; oasis-board-comment@lists.oasis-open.org; OASIS TAB
> Subject: [oasis-charter-discuss] OASIS Advanced Message Queuing Protocol
> (AMQP) Technical Committee
> 
> To OASIS Members:
> 
> A draft TC charter has been submitted to establish the OASIS Advanced
> Message Queuing Protocol (AMQP) Technical Committee (below). In
> accordance with the OASIS TC Process Policy section 2.2:
> (http://www.oasis-open.org/committees/process-2009-07-30.php#formation)
> the proposed charter is hereby submitted for comment. The comment
> period shall remain open until 11:45 pm ET on 24 August 2011.
> 
> OASIS maintains a mailing list for the purpose of submitting comments
> on proposed charters. Any OASIS member may post to this list by
> sending email to: oasis-charter-discuss@lists.oasis-open.org. All
> messages will be publicly archived at:
> http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members
> who wish to receive emails must join the group by selecting "join
> group" on the group home page:
> http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/.
> Employees of organizational members do not require primary
> representative approval to subscribe to the oasis-charter-discuss
> e-mail.
> 
> A telephone conference will be held among the Convener, the OASIS TC
> Administrator, and those proposers who wish to attend within four days
> of the close of the comment period. The announcement and call-in
> information will be noted on the OASIS Charter Discuss Group Calendar.
> 
> We encourage member comment and ask that you note the name of the
> proposed TC ("AMQP") in the subject line of your email message.
> 
> ===
> 
> (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:
> 
> - Ubiquity
>        - 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.
> 
> - 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.
> 
> (c) 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 an OASIS Standard
> version including necessary XML renderings.
> 
> Features of the AMQP wire protocol specification [1] 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 scope of work for the OASIS Standard version of the AMQP wire
> protocol specification is limited to:
>        - Technical refinements to features defined in v1.0 Final
> version of the AMQP wire level protocol specification [1] arising from
> demonstrable interoperability problems.
>        - Non-technical changes aimed at improving quality of the input
> specification such as better documentation.
> 
> The TC shall conduct business as described in the OASIS Technical
> Committee Process and will take advantage of the services provided by
> OASIS, including e-mail lists and archives, and web servers for
> tracking progress. E-mail archives will be visible to the public.
> 
> Out of scope: Any work not mentioned in the Scope of Work section is
> deemed to be out of scope. 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.
> 
> (d) Deliverables
> 
> The TC shall produce the OASIS Standard version of the v1.0 AMQP wire
> level protocol specification before July 2012. Following that, the TC
> may advance the OASIS Standard version of the AMQP wire level protocol
> specification to ISO/IEC JTC 1 through the JTC 1 PAS Transposition
> Process.
> 
> Maintenance:
> 
> Once the TC has successfully produced the deliverables, the TC will
> enter into a maintenance mode.
> 
> The purpose of the maintenance mode is to provide minor revisions to
> previously adopted deliverables, in order to clarify ambiguities,
> inconsistencies, and obvious errors.  The maintenance mode will not
> functionally enhance a previously adopted deliverable, or extend its
> functionality.
> 
> The TC will collect issues raised against the deliverables and
> periodically process those issues. Issues that require extended or
> enhanced functionality shall be recorded and set aside for potential
> development of a charter for another technical committee that may be
> created to address them. Issues that result in the clarification or
> non-substantive correction of the deliverables shall be processed. The
> TC shall maintain a list of the adopted clarifications and shall
> create a new minor revision of the deliverables incorporating those
> adopted clarifications.
> 
> (e) IPR Mode
> 
> This TC will operate under RF on RAND Terms IPR mode as defined in the
> OASIS Intellectual Property Rights (IPR) Policy effective 15 October
> 2010.
> 
> (f) Anticipated Audience
> 
> The anticipated audience for this work includes:
>        - Business messaging users
>        - Business messaging middleware vendors
> 
> (g) Language
> 
> TC business will be conducted in English.
> 
> References
> 
> [1] Advanced Message Queuing Protocol (AMQP) v1.0 Final
> https://www.amqp.org/resources/download - This link contains the
> latest version; the final version is expected soon.
> 
> (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 AMQP TC will be a face-to-face meeting to be
> held in New York on October 14, 2011 from 9 AM ET to 5 PM ET. This
> meeting will be sponsored by JPMorgan Chase Bank N.A.
> 
> (c) On-Going Meeting Plans & Sponsors
> 
> It is anticipated that the AMQP TC will meet via teleconference every
> week for 60 minutes at a time determined by the TC members during the
> TC's first meeting. It is anticipated that the AMQP TC will meet
> face-to-face every 2-3 months at a time and location to be determined
> by the TC members.  The actual pace of face-to-face and teleconference
> meetings will be determined by TC members. One of the proposers, as
> listed below, will sponsor the teleconferences unless other TC members
> offer to donate their own facilities.
> 
> (d) Proposers of the TC
> 
> John O'Hara, john.ohara1@baml.com, Bank of America
> Abbie Barbir, abbie.barbir@bankofamerica.com, Bank of America
> Andreas Moravec, andreas.moravec@deutsche-boerse.com, Deutsche Börse AG
> Hanno Klein, hanno.klein@deutsche-boerse.com, Deutsche Börse AG
> Andreas Mueller, am@iit.de, IIT Software GmbH
> Matthew Arrott, marrott@novgp.com, Individual Member
> Bijan Sanii, bijans@inetco.com, INETCO Systems Ltd.
> Angus Telfer, angus.telfer@inetco.com, INETCO Systems Ltd.
> Allan Cornish, acornish@inetco.com, INETCO Systems Ltd.
> Allan Beck, allan.beck@jpmorgan.com, JPMorgan Chase Bank N.A
> Robert X. Godfrey, robert.godfrey@jpmorgan.com, JPMorgan Chase Bank N.A
> Laurie M. Bryson, laurie.m.bryson@jpmorgan.com, JPMorgan Chase Bank N.A
> John Fallows, john.fallows@kaazing.com, Kaazing
> Brian Albers, brian.albers@kaazing.com, Kaazing
> David Ingham, david.ingham@microsoft.com, Microsoft
> Ram Jeyaraman, ram.jeyaraman@microsoft.com, Microsoft
> Xin Chen, xinchen@microsoft.com, Microsoft
> Alexandros Kritikos, alex.kritikos@my-channels.com, my-Channels
> Colin MacNaughton, cmacnaug@progress.com, Progress Software
> Jaime Meritt, jmeritt@progress.com, Progress Software
> Carl Trieloff, cctrieloff@redhat.com, Red Hat
> Gordon Sim, gsim@redhat.com, Red Hat
> Mark Little, mlittle@redhat.com, Red Hat
> Rafael Schloming, rafaels@redhat.com, Red Hat
> Prasad Yendluri, prasad.yendluri@softwareag.com, Software AG
> Ross Cooney, ross.cooney@stormmq.com, StormMQ Limited
> Raphael Cohn, raphael.cohn@stormmq.com, StormMQ Limited
> Winston Bumpus, wbumpus@vmware.com, VMware, Inc.
> Alexis Richardson, arichardson@vmware.com, VMware, Inc.
> Adrian Colyer, acolyer@vmware.com, VMware, Inc.
> Paul Fremantle, paul@wso2.com, WSO2
> 
> (e) Statement of Support
> 
> Abbie Barbir, abbie.barbir@bankofamerica.com, Bank of America - As the
> OASIS Primary Representative for Bank of America, I am pleased to
> offer our support for the creation of the OASIS AMQP Technical
> Committee.
> 
> Andreas Moravec, andreas.moravec@deutsche-boerse.com, Deutsche Börse
> AG - As the Primary Representative for Deutsche Börse AG, I am pleased
> to offer our support for the creation of this Technical Committee.
> 
> Andreas Mueller, am@iit.de, IIT Software GmbH - As the Primary
> Representative for IIT Software GmbH, I am pleased to offer our
> support for the creation of this Technical Committee.
> 
> Angus Telfer, angus.telfer@inetco.com, INETCO Systems Ltd. - As the
> Primary Representative for INETCO, I am pleased to offer our support
> for the creation of this Technical Committee.
> 
> Allan Beck, allan.beck@jpmorgan.com, JPMorgan Chase Bank N.A - As the
> Primary Representative for JPMorgan Chase Bank, I am pleased to offer
> our support for the creation of this Technical Committee.
> 
> John Fallows, john.fallows@kaazing.com, Kaazing - As Primary
> Representative for Kaazing, I am pleased to offer our strong support
> for the creation of this Technical Committee.
> 
> Ram Jeyaraman, ram.jeyaraman@microsoft.com, Microsoft - As the Primary
> Representative for Microsoft, I am pleased to offer our support for
> the creation of this Technical Committee.
> 
> Alexandros Kritikos, alex.kritikos@my-channels.com, my-Channels - As
> the Primary Representative for my-Channels, I am pleased to offer our
> support for the creation of the OASIS AMQP Technical Committee.
> 
> Jaime Meritt, jmeritt@progress.com, Progress Software - As the Primary
> Representative for Progress Software, I am pleased to offer our
> support for the creation of the OASIS AMQP Technical Committee.
> 
> Mark Little, mlittle@redhat.com, Red Hat - As the Primary
> Representative for Red Hat, I offer our support for the creation of
> this Technical Committee.
> 
> Prasad Yendluri, prasad.yendluri@softwareag.com, Software AG - As the
> Primary Representative for Software AG, I am pleased to offer our
> support for the creation of this Technical Committee.
> 
> Ross Cooney, ross.cooney@stormmq.com, StormMQ Limited - As the Primary
> Representative for StormMQ Limited, I am pleased to offer our support
> for the creation of this Technical Committee.
> 
> Winston Bumpus, wbumpus@vmware.com, VMware, Inc. - As Primary
> Representative for VMware, Inc., I am pleased to offer our strong
> support for the creation of this Technical Committee.
> 
> Paul Fremantle, paul@wso2.com, WSO2 - As Primary Representative for
> WSO2, I am pleased to offer WSO2's strong support for the creation of
> this Technical Committee.
> 
> (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 be affiliated with the AMQP Member
> Section.
> 
> (h) List of anticipated contributions
> 
> Advanced Message Queuing Protocol (AMQP) v1.0 Final
> https://www.amqp.org/resources/download - This link contains the
> latest version; the final version is expected soon.
> 
> (i) Frequently Asked Questions (FAQ) relating to the planned scope of the TC
> 
> None
> 
> (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
> 
> 
> --
> 
> /chet
> ----------------
> Chet Ensign
> Director of Standards Development and TC Administration
> OASIS: Advancing open standards for the information society
> http://www.oasis-open.org
> 
> Primary: +1 973-378-3472
> Mobile: +1 201-341-1393
> 
> Follow OASIS on:
> LinkedIn:    http://linkd.in/OASISopen
> Twitter:        http://twitter.com/OASISopen
> Facebook:  http://facebook.com/oasis.open
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]