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

 


Help: OASIS Mailing Lists Help | MarkMail Help

amqp-comment message

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


Subject: 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
   <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



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