Title:	PER encodings should use full-encoding OCTET STRING choice 

PDR Reference:				97110002

Originator Reference: 			UL-DR 123

SARPs Document Reference: 		ULCS SARPs, 4.3.2.6.4

Status: 					SUBMITTED

PDR Revision Date: 			

PDR Submission Date:			13/11/97

Submitting State/Organisation: 		Logica

Submitting Author Name: 		FIELDHOUSE, D

Submitting Author E-mail Address: 	fieldhouse@logica.com

Submitting Author Supplemental 		Tel +44 171 637 9111
Contact Information:			Fax: +44 1932 869107

SARPs Date:				Proposed ICAO Version 2.0
					(WG3 Thailand, Mar 97) 
SARPs Language:			English

Summary of Defect:

1) ISO/IEC 8825-2 section 7.9 states that PER encoded data sent across the presentation boundary shall use full encoding with the OCTET STRING choice.  The ULCS SARPs specify use of full encoding with the BIT STRING choice.

2) The SARPs text quotes full encoding with a different SIZE constraint from the ISO presentation efficiency Amd. 

3) Elsewhere ULCS allows P-CONNECT user data to be directly encoded ACSE PDUs without full encoding.


Assigned SME:				Sub-Volume 4 SME

SME Comment:

1) This was originally an oversight by WG3/SG3, who didn't spot that sentence in the PER standard when deciding to use full encoding.  (The original intention was to specify simple encoding with a separate context id).  So there is a discrepancy between the PER standard and the ULCS SARPs.
The ULCS SARPs also go beyond the ISO standards in pre-defining the p-ctx ids, and in wrapping the ACSE apdus in fully-encoded-data.

2) The ULCS SARPs specify a simplified, but compatible, efficiency constraint as there will never be more than one element in the SEQUENCE OF for the foreseeable future.  This simplifies matters for some compilers.
The difference is that the ULCS SARPs specify
    Fully-encoded-data ::= SEQUENCE SIZE (1, ...) OF PDV-list
whereas 8823-1 Amd 1 specifies (in 8.2)
    Fully-encoded-data ::= SEQUENCE SIZE (1, ..., 2..MAX) OF PDV-list

The same is true for Presentation-context-identifier.

This is not a problem, but perhaps should be explained in the Guidance Material.

3) The reason for this is that anything on P-CONNECT has to be an ACSE apdu, so the "top level choice" offered by full encoding is redundant, and a few bits (20 or more) of overhead are saved. 

Discussion:

Is ISO/IEC 8825-2 justified in imposing such blanket restrictions on users of the presentation protocol?

There are several known areas where the SARPs do not conform to base standards, so this is not necessarily a defect that needs to be fixed.

Strictly speaking, the ULCS should conform to the requirement in 8825-2 and make everything which crosses the presentation service boundary fully-encoded using the OCTET STRING choice.  However, it might be better to live with the non-compliance rather than disrupt the ATN upper layers.


Proposed SARPs amendment:


SME Recommendation to CCB: 		APPROVE the PDR and pass to SME4 group.

CCB Decision:				SUBMITTED (14/11/97)