Disposition of public review comments on OASIS AMQP Version 1.0 CSPRD01

The AMQP TC carefully evaluated the various public review comments (see email below) on OASIS AMQP 1.0 CSPRD01 and has addressed them as follows:

· Disposition of comment #1: http://tools.oasis-open.org/issues/browse/AMQP-70

· Disposition of comment #2: http://tools.oasis-open.org/issues/browse/AMQP-62, http://tools.oasis-open.org/issues/browse/AMQP-73

· Disposition of comment #3: http://tools.oasis-open.org/issues/browse/AMQP-68

· Disposition of comment #4: http://tools.oasis-open.org/issues/browse/AMQP-66

· Disposition of comment #5: http://tools.oasis-open.org/issues/browse/AMQP-63

· Disposition of comment #6: http://tools.oasis-open.org/issues/browse/AMQP-64

· Disposition of comment #7: http://tools.oasis-open.org/issues/browse/AMQP-65

-----Original Message-----
From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com]
Sent: Wednesday, March 28, 2012 4:29 PM
To: Martin Chapman; amqp-comment@lists.oasis-open.org
Cc: OASIS TAB
Subject: RE: [amqp-comment] Comments on OASIS AMQP Version 1.0 CSPRD01

Hello Martin,

Thank you for the comments!

The purpose of this note is to acknowledge receipt of your comments.

The TC will review your comments and post the disposition of each comment at the end of the public review period.

Thanks again!

-----Original Message-----

From: Martin Chapman [mailto:MARTIN.CHAPMAN@ORACLE.COM]

Sent: Thursday, March 22, 2012 7:46 AM

To: amqp-comment@lists.oasis-open.org

Cc: OASIS TAB

Subject: [amqp-comment] Comments on OASIS AMQP Version 1.0 CSPRD01

Comments with respect to:

http://docs.oasis-open.org/amqp/core/v1.0/csprd01/amqp-core-complete-v1.0-csprd01.pdf

Note that these comments are provided by me as an individual member of the TAB, and do not necessarily represent the consensus of the TAB.

1. General - Template

This specification does not currently use an approved template, as required by the TC Process, section2.18 (1). Approved templates can be found via http://docs.oasis-open.org/templates/ If the TC does not want to use one of the current approved templates, the TC must work with TC Admin to get the template authorized and registered. The following MUST be taken into account by the TC and TC Admin during this process:

a) there needs to be authoritative and editable source for the cover pages, bolierplate and table of contents. As is stands I have no idea where this is being generated from.

b) there needs to be an authoritative and editable source that declares precisely what document parts make up the specification. In other words how does someone know which parts to include in gerenating the pdf for example.

c) the mechanism, tools and scripts required to generate the pdf and html must be documented and made available on http://docs.oasis-open.org/templates/

In terms of consistency with other oasis specifications, I recommend dropping Part titles. To me a specification broken down into parts implies differing conformance for each part, whereas the useage here is just a mechanism for sectional and file breakdown.

2. General/page 115

What is the role of the DTD with respect to the normative requirements defined in the document? If there are none, and its is just to document the template, then please remove as point 1) addresses this.

Saying that, it is unclear to me what the xml snippets in the documet mean wrt conformance. Throughout 1.2 (type encodings) xml snippets are provided despite encoding being defined in a bnf style e.g. 1.2.1 contains:

Type:null

As an additional example 2.7 contains many complec type definions in xml. Does the xml get serialized somehow - if so that is really not clear.

Please clarify why the xml snippets are provided and how they relate to wire encoding.

3. General. Please line number a pdf to make it easier in reviewing!

4. 0.1.1 terminology. Throughout the document lower case keywords can be found. RFC 2119 make no distinction bewteen upper and lower case. Please review all lower case occurences of keywords and either make them upper case, or find a non-rfc2119 equivalent (can for must, could for may etc)

5. 0.1 Conformance is weak. What constitutes an implementation? Is it node, a network? Assuming it's a node, Section 2 talks about nodes, sources and targets. Must all of these roles be implented and supported by a implementaion claiming to be an ampq node?, must containers be supported etc. Please clarify.

What is the intended conformance target of the messaging layer i.e. who generates and recieves messages so that they should follow this specification. Is the sender and reciver different from a node? does an impl have to support both sending and reciving roles?

Does part 4 have to be supported, or is this entirely optional?

Similaryly does part 5 have to be supported by all impls.

6. Part 2.1, Para 1. 2nd sentence - messages can orginate - should be Messasges can originate.

7. 2.1 What is the relationship between links, connections, channels, and sessions?

Please add some clarification text and a possibly a diagram to better explain the relationship between the concepts (figure 2.4 doesn't explain much to me at the moment).

I did read the rest of the document (honest) but without a real indepth analysis I am not in a position to comment on the procotols, formats, state machines etc.

Cheers,

Martin.

Martin Chapman

Standards Professional

Mobile: +353 87 687 6654

ORACLE Ireland

Oracle is committed to developing practices and products that help protect the environment

This publicly archived list offers a means to provide input to the OASIS Advanced Message Queuing Protocol (AMQP) TC.

In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting.

Subscribe: amqp-comment-subscribe@lists.oasis-open.org

Unsubscribe: amqp-comment-unsubscribe@lists.oasis-open.org

List help: amqp-comment-help@lists.oasis-open.org