🚀 go-pugleaf

First, some background;

ASMEC is a design consultancy specialising in COMMS/OSI related
topics within the Industrial and Scientific fields of the European
Computer Industry.  We are currently engaged in the implementation of
a full function OSI stack on Stratus hardware for ICL Network Systems
Ltd (part of ICL/Fujitsu) to be used as the backbone for an X.400
message handling system. 

Having previously ported ISODE onto other ICL UNIX based kit, we are
grafting the Presentation and Application layers onto the Stratus OSI
session layer server.

Now the questions; The following is little lengthy, so I apologise to
anyone who is good natured enough to wade through it. In brief they
concern some questions we have with regard to ACSE and PEPY. Being
new to this conferance I'm not sure whether they should be aired here
or on bug-ISODE, so I have copied this to both for good measure.
However we would be very interested and gratefull for any help and/or
comments anyone would care to make.



Association Control User Data
=============================

Are  there  any  further details or documentation on the use of the
User Data fields in the AcAssocRequest and  AcAssocResponse  calls? 
>From  the  code  this seems  to  be an array of PEs, but there is no
details as to what form these should  take.  Moreover,  the 
AcAssocRequest  code  specifically rejects  PEs  with  the pe_context
field set to PE_DFLT_CTX as in the following fragment from
AcAsynAssocRequest.c:-


if (data) {
   register int i;
   register PE  *pep;

   for (pep = data, i = ndata; i > 0; pep++, i--)
       if ((*pep) -> pe_context == PE_DFLT_CTX)
           return acsaplose (aci, ACS_PARAMETER, NULLCP,
              "default context not allowed for user-data at slot %d",
                        pep - data);
}

PE_DFLT_CTX,  however, is the only value defined for this field in
the psap.h header.  We are confused.  Has anyone actually used  User 
Data during  association  control? The method of calculation of the
slot value in the error message would suggest that this message is
rarely if ever seen. 

We have our own ideas on implementing ACSE User Data but don't wish
to lock ourselves out of future releases of the code.


PEPY Problem No. 1
==================

How does one use the pepy MODULE include feature mentioned all too
briefly in the documentation?


PEPY Problem No. 2
==================

It  would  appear that PEPY has a problem with ASN.1 definitions
which define a CHOICE construct as an OPTIONAL member of another 
construct.  The  example  below illustrates this with respect to the
ContType data element, being part of the X.411 MTS:-


ContType ::= CHOICE {
       built-in BuiltInContType,
       external ExternalContType }

RepDlvryArg ::= SET {
        subj-subm-id SubjSubmId,
        cont-id ContId OPTIONAL,
        cont-type ContType OPTIONAL,
        origin-eits OriginEITs OPTIONAL,
        per-recip-flds SEQUENCE OF PerRecipRepDlvryFlds (1..ub-recips),
        returned-cont [0] Cont OPTIONAL }


The PEPY produced code for the RepDlvryArg construct is as follows. 
Please ignore the asn1_ prefix and _f suffix to the function calls.
These are present to aid the Stratus build system (Oh for make under
VOS!!).


int encode_P3_RepDlvryArg_f (PE *pe , int explicit , integer len , char *buffer , struct type_P3_RepDlvryArg *parm )
{
        struct choice_P3_0 *choice_P3_0;
        struct element_P3_0 *element_P3_0;
    
    PE  p10_z = NULLPE;
    register PE *p10 = &p10_z;

    if  ( ( (*pe) = asn1_pe_alloc_f(PE_CLASS_UNIV, PE_FORM_CONS, PE_CONS_SET)) == NULLPE) {
        asn1_advise_f(NULLCP, "RepDlvryArg: %s", PEPY_ERR_NOMEM);
        return NOTOK;
    }
    {
                choice_P3_0 = parm -> member_P3_0;
                element_P3_0 = parm -> per__recip__flds;
            
    }


****** Intervening code removed for brevity *****

     (*p10) = NULLPE;


********* 
          The  following section encodes the ContType data element and
          should be dependant upon the  presence  of  the  choice_P3_0
          pointer.  
*********

    {
        int     p11;

        switch  (p11 =  (choice_P3_0 -> offset)) {
            case 1:     /* built-in */
                {
                    if  (encode_P3_BuiltInContType_f(p10, 0, NULLINT, NULLCP, choice_P3_0 -> un.built__in ) == NOTOK)
                        return NOTOK;

#ifdef DEBUG
                     (void) asn1_testdebug_f( (*p10), "built-in");
#endif

                }
                break;
            case 2:     /* external */
                {
                    if  (encode_P3_ExternalContType_f(p10, 0, NULLINT, NULLCP, choice_P3_0 -> un.external ) == NOTOK)
                        return NOTOK;

#ifdef DEBUG
                     (void) asn1_testdebug_f( (*p10), "external");
#endif

                }
                break;

            default:
                asn1_advise_f(NULLCP, "member %s%d", PEPY_ERR_INVALID_CHOICE, 
                        p11);
                return NOTOK;
        }

#ifdef DEBUG
         (void) asn1_testdebug_f( (*p10), "member");
#endif

    }
    if  ( (*p10) != NULLPE)
        if  (asn1_set_add_f( (*pe),  (*p10)) == NOTOK) {
            asn1_advise_f(NULLCP, "RepDlvryArg %s%s", PEPY_ERR_BAD_SET,
                    asn1_pe_error_f( (*pe) -> pe_errno));
            return NOTOK;
        }
     (*p10) = NULLPE;

****** Intervening code removed for brevity *****

    return OK;
}


It will be seen that as things stand the section of code which
encodes the  ContType  element  will  be processed regardless.  What
should be present is an if statement as follows:-

    if (choice_P3_0)
    {
        int     p11;

        switch  (p11 =  (choice_P3_0 -> offset)) {

which will provide the desired result.



PEPY Problem No. 3
==================

Another problem from the following ASN.1 definition for the MTS:-

PerRecipientReportDeliveryFields::= SET{
     actual-recipient-name [0] ActualRecipientName,
     report-type [1] ReportType,
     converted-encoded-information-types
                         ConvertedEncodedInformationTypes OPTIONAL,
     originally-intended-recipient-name [2]
                         OriginallyIntendedRecipientName OPTIONAL,
     supplimentary-information [3]
                         SupplimentaryInformation OPTIONAL,
     extensions [4] EXTENSIONS CHOSEN FROM {
          redirection-history,
          physical-fowarding-address,
          recipient-certificate,
          proof-of-delivery} DEFAULT {}}

ReportType::= CHOICE{
     delivery [0] DeliveryReport,
     non-delivery [1] NonDeliveryReport}

DeliveryReport::= SET{
     message-delivery-time [0] MessageDeliveryTime,
     type-of-MTS-user [1] TypeOfMTSUser DEFAULT public}

NonDeliveryReport::= SET{
     non-delivery-reason-code [0] NonDeliveryReasonCode,
     non-delivery-diagnostic-code [1] NonDeliveryDiagnosticCode OPTIONAL}


One the things PEPY does when dealing with CHOICE constructs which
are members  a  higher  level  constructs  is to 'pull up' the type
of the CHOICE to the type which references them, in this case a SET. 
In this case, therefore, the data element structure should be as
follows:-

SET (PerRecipientReportDeliveryFields)
 |
 +-> [0] actual-recipient-name ActualRecipientName 
      |
     [1] report-type SET (ReportType)
      |               |
      |               +-> either [0] SET DeliveryReport 
      |                       or [1] SET NonDeliveryReport
     Other members.

Actually,  being  a SET, the members can appear in the encoded data
in any order.

The  decode  function  produced  by PEPY, having found the
report-type member, correctly  expects  to  see  a  SET  constructor 
(ReportType) followed  by  another  SET  constructor representing the
member of the CHOICE construct. If this is not the case there is a
clash of the context specific tags.

Unfortunately  the  corresponding PEPY encode function does not
produce the first SET constructor for the report-type  element, 
possibly because both of the potential members of report-type are
themselves of the SET type, though we have done no investigation to
confirm this.


So, the questions are;

1.  Has anyone encountered the same or similar problems and, if so,
are there any solutions, particularly with the PEPY problems.

2.  Are there any other related problems with PEPY we should be aware
of?

3.  Is there any later releas of PEPY (> Rel 6.0) available?


Thank you for your perserverance if you have got this far. We look
forward to any comments with interest.