Title: 	ULCS CF State Table - atomic ASEs

PDR Reference: 				M2020001

Originator Reference: 			US-SV4-02-01

SARPs Document Reference:		4.3.3.1.2.1 Note c
						4.3.3.1.2.2
						state table

Status: 					RESOLVED

Impact:					C

PDR Revision Date: 			11 Jun 2002 (PROPOSED -> RESOLVED)
						23 Apr 2002 (revised proposal)
						05 Apr 2002 (ACCEPTED -> PROPOSED)
						28 Feb 2002 (SUBMITTED -> ACCEPTED)

PDR Submission Date:  			14/02/2002

Submitting State/Organization:	USA

Submitting Author Name: 		James Moulton

Submitting Author E-mail Address: 	moulton@ons.com

Submitting Author Supplemental Contact Information:
	22636 Glenn Dr Suite 305
	Sterling, VA 20164
	USA

SARPs Date: 				Edition 3 (Mar 2002)

SARPs Language:  				English

Summary of Defect:

The referenced note (sub-point 2) states "the new state that the CF enters
after the action has been performed." While the following paragraph
specifies that embedded ASEs are treated as atomic entities, and "the CF
responds to any resulting output events from the ASE ...".  In the state
table cell STA0 and D-START req - "if p0 & ~p6: STA1 A-ASSOC req"

If processing through the ACSE ASE is followed, the CF will process the
P-DATA req before returning to the CF and therefore will be in the wrong
state.


Assigned SME:  				Tony Kerr, SV4 SME (tony.kerr@cival.co.uk)

SME Commentary:

Discussed at ATNP/SGB2 meeting, Phuket 13 Mar 2002.
Working literally through the CF provisions (either State Table
(4.3.3.1.2.1.c.2) or text), state transitions occur AFTER the action has
been performed.  For example, a typical action is: "Invoke the A-ASSOCIATE
Request primitive" in 4.3.3.3.2.2.1.h. and then change state from NULL to
ASSOC-PENDING. In this example, the ACSE processing could be assumed to
occur immediately upon invocation, i.e. BEFORE the CF state change to
ASSOC-PENDING.  The ACSE processing would result in an AARQ APDU being
emitted (via P-CONNECT req), which is invalid in the NULL state.

This potential problem has existed since the CF was first specified, and has
not caused implementation problems until now.  The simplest solution would
seem to be a clarification that "invoking" a primitive is not like a
procedure call; rather, it conceptually adds an event to a queue, for
processing at the end of the current thread.

Proposed SARPs amendment:

In 4.3.3.1.2.2, REPLACE:

<<For the purpose of specifying CF behaviour, embedded ASEs (ATN-App ASE and
ACSE) shall be treated as atomic entities, such that when an input event is
invoked by the CF, that event is processed to completion by the ASE and the
CF responds to any resulting output events from the ASE, all within the same
logical processing thread.

Note:-	This provision avoids the need to specify further transient states
within the CF.  It does not imply any particular implementation
architecture.>>

WITH:

<<When interacting with embedded ASEs (ATN-App ASE, Security ASO or ACSE)
and the specified action is to invoke an ASE request or response primitive,
the CF shall behave as though:

a) the primitive invocation causes an input event to be generated for
subsequent processing by the ASE;

b) the CF processing continues as described in the remainder of the clause,
and any CF state transition is performed before any action is taken by the
ASE in response to the invoked primitive;

c) the ASE then behaves atomically, such that the input event is processed
to completion by the ASE;

d) the CF then responds to any resulting output events from the ASE before
any other CF input events are processed.

Note:-	This provision avoids the need to specify numerous transient states
within the CF.  It describes a model of the CF in order to achieve the
required external behaviour; it does not imply any particular implementation
architecture.>>



Impact on Interoperability: 	None, but a literal implementation of the
existing CF provisions would be unable to establish dialogues.

PDR Validation Status: 		Review of the proposed text.

SME Recommendation to CCB: 	RESOLVED

CCB Decision:		RESOLVED after review period expired.