Defect report 074 for DUA abstrct syntax

["John H. Dale" <[e-mail]>]

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'm not questioning the need for DSAs
to work this way.  But I'm wondering how likely it is that
we will see such a change extended to the DUA and DUA toolkits
before 1992 DSAs begin to be deployed. If it is feasible
to make this modification to DUAs, then we should make the
this changes to the standard as soon as possible.  If
it is not feasible, we should consider fixes that might
be more feasible, e.g.: (a) preventing 1992 DSAs from sending
out the new tags except when handling requests that can't
come from a 1992 DSA, or (b) adding the specific
tags which cause the problem to the 1988 syntax, but allowing
1988 DUAs to ignore the values.  
Alternative  (a) appears to be the original intent of the
developers of the 1992 edition of the standerd.  Alternative
(b) would require changes to the DUAs that might be much
easier than the proposed solution.  However, the proposed
solution would put us in a much better position to accomodate
the future evolution of the directory standard than would
either of the alternatives mentioned.  (I'm not so sure
that (a) is feasible for matchedSubtype.)

I suggest that those involved in developing DUAs and deploying
DUAs speak up about impact or lack of impact on the deployment
of the directory, to assist those making these decisions.  (No,
I'm not involved.)

As for the ISP, it seems to me that this will make it wise
to delay the DUA ISP (ADI11), since about the only things needed in
the DUA ISP seem to be this and perhaps a bit on authentication.
This has no impact on the 1988 DSA ISP.
-- 
John H. Dale  fax [phone]  COS, 8260 Willow Oaks Corporate Dr.,
[e-mail] tel [phone]  Suite 700, Fairfax, VA  22031