Title:  PER encodings should use full-encoding OCTET STRING choice
     
PDR Reference:                          97110002
     
Originator Reference:                   UL-DR 125
     
SARPs Document Reference:               ULCS SARPs, 4.3.2.6.4
     
Status:                                 REJECTED
     
PDR Revision Date:                      30-Mar-98
     
PDR Submission Date:                    13-Nov-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:
     
There are three distinct issues:
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 ACSE apdus sent via P-DATA in fully-encoded-data.
2) 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 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 same 
is true for Presentation-context-identifier.
This is not a problem, but perhaps should be explained in the Guidance 
Material.
3) ULCS requires P-CONNECT user data to consist of directly encoded ACSE 
PDUs without a full encoding wrapper.  The reason for this is that anything 
on P-CONNECT can only 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 exactly to base 
standards, so these discrepancies are not necessarily defects that need 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.
There is also a gap in the ULCS SARPs, as it is only implicitly stated how 
P-CONNECT User-Data shall be encoded.
     
Following discussions in the SME team (Email exchanges and WG3/SG3 meeting 
on 18.02.98) it is proposed that this PDR should be REJECTED, since no SARPs 
changes are required, but that appropriate Guidance Material should be 
generated to explain the apparent discrepancy with ISO standards and to 
explain how P-CONNECT User-Data is encoded.
     
Proposed SARPs amendment:
     
None.  It is proposed to generate appropriate Guidance Material for 
inclusion in the CAMAL.
     
Proposed GM text:
     
The PER standard (ISO/IEC 8825-2 section 7.9) states that: "When carried in 
OSI presentation protocol, the 'full encoding' (as defined in ISO/IEC 
8823-1) with the OCTET STRING choice alternative shall be used".  This 
requirement does not apply in the case of ATN upper layers, where the ULCS 
provisions specify use of full encoding with only the BIT STRING choice 
being allowed.  Unlike the most general case covered by the ISO standard, a 
great deal of a priori knowledge is assumed for ATN application 
associations.
     
The ULCS provisions also go beyond the ISO standards in pre-defining the 
presentation context identifiers, and in wrapping ACSE apdus sent via P-DATA 
in fully-encoded-data.
     
The ULCS provisions implicitly state how P-CONNECT user-data is to be 
encoded.  ULCS requires P-CONNECT user data to consist directly of 
PER-encoded ACSE PDUs with no full encoding wrapper.  The reason for this is 
that any data on P-CONNECT can only 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.
     
The ULCS provisions require ASN.1 full encoding with a different SIZE 
constraint compared with the ISO presentation efficiency amendment.  The 
difference is that the ULCS provisions 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 ULCS provisions 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 same is true for Presentation-context-identifier.
     
     
     
SME Recommendation to CCB:      REJECTED, with additions to ULCS Guidance 
Material.
     
CCB Decision:   REJECTED (CCB/5  13-Mar-98)