andy@asmec.UUCP (Andy Sykes) (08/14/90)
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.