DR074: ASN.1 tolerance

"John H. Dale" <jdale@tango.cos.com> Thu, 07 January 1993 19:08 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06072; 7 Jan 93 14:08 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06068; 7 Jan 93 14:08 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa17873; 7 Jan 93 14:08 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.05741-0@haig.cs.ucl.ac.uk>; Thu, 7 Jan 1993 18:05:01 +0000
Received: from cos.com by bells.cs.ucl.ac.uk with Internet SMTP id <g.29578-0@bells.cs.ucl.ac.uk>; Thu, 7 Jan 1993 18:04:41 +0000
Received: from tango.cos.com by coincd4000.cos.com id SMTP-0012b4c70eb018290; Thu, 7 Jan 93 13:05:31 -0500
Received: from twiddle.cos.com by tango.cos.com (4.1/SMI-4.1) id AA14931; Thu, 7 Jan 93 13:02:37 EST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "John H. Dale" <jdale@tango.cos.com>
Message-Id: <9301071802.AA14931@tango.cos.com>
Subject: DR074: ASN.1 tolerance
To: Christian Huitema <Christian.Huitema@sophia.inria.fr>
Date: Thu, 7 Jan 93 13:01:50 EST
Cc: OIW DS SIG <dssig@ics.uci.edu>, osids <osi-ds@cs.ucl.ac.uk>
In-Reply-To: <199301070813.AA16450@mitsou.inria.fr>; from "Christian Huitema" at Jan 7, 93 9:13 am
X-Mailer: ELM [version 2.3 PL6]

Christian writes:
> 
> Humm. I believe we have a different reading of ASN.1 + of the "be
> tolerant with what you receive" pragma. The decoding routine generated
> by the MAVROS compiler incorporate the following features:
> 
I don't know of any "be tolerant with what you receive" pragma for
OSI.  On the contrary, the specifications often require you to check
stuff that (I  doesn't matter, and to take specific action if
it is not what it should be.  I looks like people developing
various OSI application layer standards have learned that this
is not always a good thing, and are sneaking needed "tolerance" into 
the standards, e.g., the rules of extensibility we are dicussing.

The 1988 presentation standard, however, requires you to do
a presentation provider abort when you receive an "invalid PPDU".
I assume that this is the basis of some of the presentation layer
conformance tests I mention below.

> * Verify the presence of all Mandatory elements in SET or SEQUENCE, and
>   report an error if one such element is missing.
> 
> * Verify the syntax of all Mandatory and Optional elements which happen
>   to be present.
> 
> * Complain if a SET includes two occurences of a tagged element, or if
>   a SEQUENCE contains unexpected elements before the last mandatory
>   element has been decoded.
> 
I think you are requred to do a presentation provider abort in this case.
The DUA conformance test suite requires this for two occurances of a set 
element. (pu_tc_1.4.3)

> * IGNORE, and skip over, unexpected tagged elements within sets or at
>   the end of sequences.
> 
I think you are requred to do a presentation provider abort in this
case also, under the 1988 directory and presentation specifications.
This is also in the DUA test suite (pu_tc_1.4.1).

> This was programmed before the "extensibility" rules were defined. I
> presume that in order to comply with this new rules, we should somehow
> pass to the application the unexpected elements, instead of merely
> ignoring them.
>
The 1988 DSA extensibility rules say that you "...shall ignore all tag
values not defined in the abstract syntaxes ...".  (Note that this
conflicts a bit with a earlier interpretation of mine.)  It is proposed
that these rules apply to DUAs.

> The rationale is simple: unexpected elements "don't hurt" as long as
> all mandatory elements are present -- the message still "makes sense".
> As a consequence, the 88 DUAs generated with the MAVROS compiler, e.g.
> SNI's "DIR-X" or E3X "Pizarro", will gracefully support the 1992
> extensions to X.500.
> 
> Christian Huitema
> 
-- 
John H. Dale  fax +1-703-846-8590  COS, 8260 Willow Oaks Corporate Dr.,
jdale@cos.com tel +1-703-205-2742  Suite 700, Fairfax, VA  22031