> 
> Message-Id: <9301061914.AA11150@tango.cos.com>
> Subject: Defect report 074 for DUA abstrct syntax
> Date: Wed, 6 Jan 93 14:13:58 EST
> X-Mailer: ELM [version 2.3 PL6]
> 
> This defect report would have a bearing on the draft ISP
> being submitted by the workshops.  I supect that the proposed
> proposed solution, a change to the 1988 standard, would require 
> changes to DUAs that would, in many cases, be non-trivial.  
> Following is material extracted from the defect report, then 
> some comments. 
> 
> Defect Report 9594/074
> Source: Australia (SAA)
> Defect report concerning: X.519 and (9594-5)
> Qualifier: Omission
> References: 7.5 (see Tech. Corr. 3)
> Nature of Defect:
> Technical Corrigendum 3 specifies rules for DUAs and DSAs
> that allow these systems to interwork with later edition
> systems that use extended protocols.  However, the only
> rules specified for DUAs concern unknown attribute types
> and values, and unknown errors.
> The 1992 extensions to X.500/9594 make it possible for a
> DUA to receive unknown elements in SETs, specifically
> matchedSubType in CompareResult, and incompleteEntry
> in EntryInformation.  These may be returned to a 1988
> DUA through the operation being processed by a 1992 DSA.
> Solution Proposed by the source:
> To a void a 1988 DUA treating these 'unexpected' additional
> protocol elements as protocol errors, we propose that the
> DUA support the same rules of extensibility as specified
> for DSAs in 7.5.2.2.
> 
> Now my comments:
> 
> The problem is real and cannot be ignored.  However, I
> wonder if the solution proposed will be feasible to implement
> in all 1988 DUAs.  The rules of extensibilty that have
> been made mandatory for 1988 DSAs require that all unknown
> tags be ignored.  Essentially, if somebody sends you a
> PDU with a tag than is not in the ASN.1 defintions, you must
> ignore the ASN.1 element, rather than aborting the association, 
> as was the case in the original 1988 standard.  This will
> will probably require changes in the ASN.1 decoders, perhaps
> in the complilers.  

   I must agree with you. Unless ASN.1 has undergone a big change in this
   regard (which is possible I suppose) you are not allowed to just ignore
   tagged types that don't match. People have no doubt spent a great deal of
   effort (coding and testing) trying to get ASN.1 parsers to pick up
   all these types of problems and correctly report a decoding problem.

   This appears very wrong, it appears that a standards group is trying to
   change the meaning of another standards groups work just to solve their
   own specific problems. Surely this is illegal. Otherwise we could have
   a different version of ASN.1 for each protocol! This defeats the whole
   purpose of having ASN.1 as a seperate and *independant* standard.

   I submit that intended and much better method to solve their problems
   is to set aside another bit in the Versions field of the Bind for 1992
   extensions. If you can negotiate the 1992 Version you can send the extended
   PDUs otherwise you can't.

   If people wish to push the altering the ASN.1 interpretation they had
   better proceed through an alteration to the ASN.1 standards.

> 
....
> - -- 
> 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
> 

	Andrew Worsley
CSIRO, Division of Information Technology (Melbourne),     Phone +61 3 282 2614
723 Swanston St.                                           Fax   +61 3 282 2600
Carlton, Vic, 3053, Australia                   Email:worsley@mel.dit.csiro.au