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
- Christian Huitema
- DR074: ASN.1 tolerance John H. Dale