[Sis-ams] summary of Red Book changes

[Scott Burleigh]

Hi, AMS fans.  Here is a recap of all the changes to the Red-2 AMS spec (posted on CWE in December) that I believe we agreed to at the AMS WG meetings in Arlington last week.  Let me know if I got any of this wrong, as I plan to be making these changes and re-posting the spec in May and then asking for a final Agency review.  If no major problems are uncovered in that review, and if we succeed in completing a formal interoperability test between two independently developed implementations of the AMS protocols by late this year, then I believe we will be in position to ask CESG to certify the spec as a Blue Book by early 2009.

1.	We considered adding a flag in the headers to disambiguate between AMS and MAMS PDUs, so that a single primary transport service endpoint could be used for reception of both.  But it would only be possible to do so by adding at least one byte to each header, which would (a) somewhat increase protocol overhead and (b) break word alignment in both headers, possibly requiring the insertion of another byte (or perhaps even three bytes) to recover alignment, at even greater cost in overhead.  Since the downside of providing this flag would be a recurring cost in every transmission, and the cost of omitting it is that developers need to be aware of its absence when designing implementations (and use a separate, dedicated primary transport protocol endpoint for MAMS traffic, so that -- in effect -- the transport protocol endpoint identifier disambiguates between the two traffic flows), we finally decided to omit the flag.  However, a note will be added to the spec stating clearl
y that the use of different endpoints for AMS vs MAMS traffic is strongly recommended, and why.

2.	On reception of a you_are_dead message, the AMS node will emit a new Node_is_dead service indication to notify the application of this event.

3.	(3.1.2.16)  The value of the "term" parameter that is used to indicate "wait indefinitely until a reply is received" will be changed from zero to -1.  A zero value for this parameter will have the effect of making a Query pseudo-synchronous rather than synchronous: processing of inbound AMS messages will not be suspended at all.

4.	The spec changes flagged with comments indicating that confirmation from Stuart Fowell (the RID author) is required are all approved.

5.	(4.2.2)  When communication with the configuration server is lost and the registrar begins looking for a replacement configuration server, the search will always begin at the *first* location in the CS location list, not the one immediately following the location of the most recently authoritative configuration server.

6.	(4.2.3)  In response to a msg_space_query, if no cell specs are to be reported (i.e., the source of the msg_space_query is the only cell in the message space) then a cell_spec MPDU will be returned with unit number set to zero.  The registrar receiving the cell_spec will interpret this as meaning "no other cells in the message space besides you".

7.	We will add the concept of "inappropriate" MPDUs (MPDUs that are received when the receiving entity is in a state in which they are meaningless in terms of the protocol) in addition to "ill-formed" MPDUs (MPDUs whose format does not conform to the AMS specification).  Both ill-formed and inappropriate MPDUs will simply be discarded.

8.	A note will be added to emphasize that registrars never alter any of the data in any MPDUs that they forward from nodes, except as specifically prescribed by the spec.  Also, the "sender" identified in an MPDU is always the original source of the MPDU except as specifically noted in the spec.

9.	A Fault.indication shall be delivered whenever a Transport.request service request fails.

10.	(6.1.2)  An informative reference will be added for those interested in reading more about AMQP.

11.	A note will be added at the start of 1.3.3.3 advising the reader to read section 2 first, referring back to 1.3.3.3 as terms are introduced.

12.	Provisions of the protocol procedures that are currently in bulleted lists will be numbered for easier reference.

13.	Fields that are labeled "spare" in tables 5-4 and 5-5 will be re-labeled "reserved", with comments inserted to the effect that these reservations may be revised in future versions of the protocol.

14.	A note will be added at the start of section 4 pointing out that the AMS spec defines *three* distinct protocols and briefly describing what each one is and does.  The "AMS" protocol will be renamed "Application Asynchronous Message Service" (AAMS) to bring it into parity with "MAMS" and "RAMS", so that this specific protocol can be readily distinguished from the overall "AMS" architecture.  The term "AMS" will be used to refer to the specification and the architecture as a whole, not to any specific protocol.

Scott