re: DR074 DUA abstract syntax

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

> 
> 
> > 
> > Message-Id: <[e-mail]>
> > 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.
> 
Technical nit: The only place I've noticed such a constraint is
in the definition and handling of "invalid" PPDUs.  And the 92 X.500
solution is even in technical conformance with that constraint,
because what they have done is, in my interpretation, extended
the abstract syntax (note the title of X.519 clause 7) to include
all possible tags.  It just happens that this abstract syntax
cannot be completely expressed in ASN.1, at least a variety with 
which I am familiar, at least without additional notes in the comments.
I don't think ASN.1 is not fully a formal notation.  Many things
in ASN.1 comments are normative parts of the abstract syntax, 
e.g., the number of attribute value in an Attribute.

>    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.
> 
Simply adding another version would not solve the problem.  Think
about distributed operations.  I'm sure that there are other possible
solutions, but I think the 1992 X.500 team designed a good one, in
that it appears the original design required these rules of
extensibility for 1988 DSAs, but not DUAs.  DSA implementors
seem to recognize that this needs to be done.  I think the time
for discussion about using these rules of extensibilty in DSAs
in long past.

My concern is solely with applying the same rules to DUAs.  DUAs
might more often be implemented with tool kits and embedded in
other applications, where they share more traditional ASN.1
decoder functions.  If so, it might be impractical to get the DUA
community to upgrade before we START deploying 1992 DSAs.
IF that is the case, I suggest the community consider using
an approach that can be implemented in the traditional
BER decoder environment.  That is, add the specific additional
tags to the 88 abstract syntax, and allow, but do not require,
the 88 DUAs to implement the full rules of extensibility.  
of course, the purchasers of such DUAs need to realize that
long term, they me need DUAs that have full BER extensibility.

> 	Andrew Worsley
> CSIRO, Division of Information Technology (Melbourne),     Phone [phone]
> 723 Swanston St.                                           Fax   [phone]
> Carlton, Vic, 3053, Australia                   Email:[e-mail]
> 
-- 
John H. Dale  fax [phone]  COS, 8260 Willow Oaks Corporate Dr.,
[e-mail] tel [phone]  Suite 700, Fairfax, VA  22031