Title: D-ABORTreq received as D-P-ABORTind
     
PDR Reference:97060025
     
Originator Reference: UL-DR 116
     
SARPs Document Reference:  ULCS SARPs
     
Status: REJECTED
     
PDR Revision Date: 27/06/97
     
PDR Submission Date:  27/06/97
     
Submitting State/Organization: ATNP/WG3/SG2
     
Submitting Author Name:  PICARD, F
     
Submitting Author E-mail Address: PICARD_Frederic@stna.dgac.fr
     
Submitting Author Supplemental Contact Information:
      
SARPs Date: 14/03/97 (Phuket)
     
SARPs Language:  English
     
Summary of Defect:  
 
If a user of the Dialogue Service invokes D-ABORT request before the dialogue has been fully established, then the peer user can receive a D-P-ABORT indication, rather than the expected D-ABORT indication.  Any user data on the D-ABORT request will be lost.

Assigned SME:  Kerr
 
SME Comment:

We are in a null encoding / short connect scenario.

App A issues A-ASSOCIATE req, ACSE A goes into Awaiting AARE state.  App A decides not to wait for A-ASSOC cnf and issues A-ABORT req.  ACSE A send an ABRT APDU as user data on P-U-ABORT req.  As the CF is not yet in the DATA TRANSFER state, it must map the P-U-ABORT req straight through to the supporting Presentation service.  PPM A issues S-U-ABORT req with no SS-user-data.  (In fact, the PPM attempts to follow clause 6.4.4.1 and send an ARU PPDU, but this is not conveyed over the p-connection, as we are in null encoding - 5.4bis.4 of 8823-1 AM2).  The text in 8823-1 AM2 could do with being tightened up in this area.  SPM A issues T-DISCONNECT req with the first octet of user data set to 01.  (7.84.1 of 8827-1 AM2).

SPM B receives T-DISCONNECT ind with the first octet of user data set to 01, and therefore issues S-U-ABORT ind.  PPM B receives S-U-ABORT ind with no SS-user-data, interprets this as an ARP PPDU, and issues P-P-ABORT ind.  (6.4.4.6 on 8823-1 AM 2).  ACSE B receives P-P-ABORT ind and issues A-P-ABORT ind.

Thus, what started off as an ACSE-user abort at A is reported as an ACSE-provider abort at B.  Any user-data that was in the A-ABORT req is, of course, lost.

This strange behaviour arises because the receiving PPM (B in this case) cannot distinguish whether the abort originated in the peer PPM or the peer PS-user.  As we are in a null-encoding regime, the presentation entities cannot communicate any PCI to resolve this.  (The session layer cheats by adding one octet to the T-DISCONNECT user-data).

It could be argued that the PS-provider is incapable of honouring the user abort request, so it does the next best thing and aborts the association on behalf of the user.

The abort mechanism should be seen as a "crash close" and the user should not be trying to convey subtle semantics depending upon the originator of the abort.

Proposed SARPs amendment:
      
No change is required to the ULCS SARPs.

The application SARPs should not depend on a D-ABORT req issued during the connection phase necessarily causing a D-ABORT ind at the peer.  (If the app waits for the end of the connection phase, then all is well, as the ULCS SARPs will map the ABRT + any user data onto a P-DATA req).

The ULCS GM will be updated to explain this.

SME Recommendation to CCB:  REJECTED
     
CCB Decision:  REJECTED  (30/10/97)