RE: Does the current eSNACC compiler support parameterised types and information object classes?

["David Lowndes" <David.Lowndes@xxxxxxxxxxxxxxx>]

Title: Does the current eSNACC compiler support parameterised types and information object classes?

OK, thanks for the clarification Richard.

 

Dave

---

From: Nicholas, Richard (US SSA) [mailto:Richard.Nicholas@xxxxxxxxxxxxxxxxx]
Sent: 14 July 2006 13:34
To: imc-snacc@xxxxxxx
Cc: David Lowndes
Subject: RE: Does the current eSNACC compiler support parameterised types and information object classes?

David,

 

The current eSNACC compiler, version 1.7, does not support the latest ASN.1 syntax.  In particular, information objects, parameterized types, and most constraints are not currently supported.

 

Our plan is to include support for those syntax elements in eSNACC v2.0.  However, work on eSNACC v2.0 has been on hold recently as our customer has other higher priority tasks for us.  We're not sure when the v2.0 version of eSNACC will be completed and released.

 

- Rich

----------------------------------
Richard E. Nicholas
Secure Systems Consultant
BAE Systems Information Technology
Richard.Nicholas@xxxxxxxxxxxxxxxxx

---

From: owner-imc-snacc@xxxxxxxxxxxx [mailto:owner-imc-snacc@xxxxxxxxxxxx] On Behalf Of David Lowndes
Sent: Friday, July 14, 2006 7:03 AM
To: imc-snacc@xxxxxxx
Subject: Does the current eSNACC compiler support parameterised types and information object classes?

I'm trying to compile the set of ASN.1 sources for X.420 1999 and get errors like this:

IPMSInformationObjects.asn(32) : parse error at symbol "{"

IPMSInformationObjects.asn(108) : parse error at symbol "EXTENSION"

&&@&&&&&&&&&&
Parsing errors---cannot proceed

Line 32 seems to be an indicator for a parameterised type "content-body-part{}":

IMPORTS
  content-body-part{}
    FROM IPMSForwardedContentBodyPartType {joint-iso-itu-t mhs(6) ipms(1)
      modules(0) forwarded-content-body-part-type(15)}

And line 108 is:

IPMPerRecipientEnvelopeExtensions EXTENSION ::=
  {blind-copy-recipients | body-part-encryption-token |
   forwarded-content-token, ...}

Which is defined (and exported) from another module as:

EXTENSION ::= CLASS {
  &id           ExtensionType UNIQUE,
  &Type         OPTIONAL,
  &absent       &Type OPTIONAL,
  &recommended  Criticality DEFAULT {}
}
WITH SYNTAX {
  [&Type
   [IF ABSENT &absent],]
  [RECOMMENDED CRITICALITY &recommended,]
  IDENTIFIED BY &id
}

The OSS C++ compiler doesn't have any similar problems with these same sources.

Regards
David Lowndes