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 <type name="null" class="primitive"/>

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...@lists.oasis-open.org Unsubscribe: amqp...@lists.oasis-open.org List help: amqp...@lists.oasis-open.org List archive: http://lists.oasis-open.org/archives/amqp-comment/ Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: http://www.oasis-open.org/maillists/guidelines.php Committee: http://www.oasis-open.org/committees/amqp Join OASIS: http://www.oasis-open.org/join/