University Directory (a.k.a. Demographic Database) Meeting Notes
May 19, 1999 Conference Call
06/04/99 DRAFT
Participants:
Arlene Allen (SB), Mark Apodaca (LA), Christi Bengard (SC), Dan Maria Cui (SF), Jim Dolgonas (OP), Kathy Keller (OP), Debbie Lauriano (DV), Helen Lee (BK), Bob Merryman (SD), Benny Min (OP), Caroline Rider (IR), Judy Sims (RV), Michael Strizich (SF), Vance Vaughan (BK), Jerry Wilcox (OP)
Draft minutes:
Previous meeting's draft minutes approved.
Telecom Interface Issues:
- it was reaffirmed that the existing annual hardcopy, directory interface process be retained for this calendar year (1999), but that this would be the final year that the current process would be retained
- SD requested clarification over the objectives of the telecom data:
one objective is to serve as a source for the annual hardcopy, directory interface process (starting next year)
another objective is to use the telecom data as a source for
a single universitywide website that provides telecom information; thus, rather than having to search for someone at multiple UC telecom sites, a search could be launched at this new, single UC telecom site
telecom data will further be used in conjunction with supporting Employee Self Service applications, e.g., email addresses may be used for sending confirmations such as for an employee's home address change
- RE: the utility program to be developed at OP which would
basically generate a campus' daily input file by "comparing" a current,
full-volume telecom file with the previous day's full-volume telecom file- given
that a number of campuses indicated they intended to use it, SD then proposed
that the utility program instead be run locally at OP rather than having those campuses electing to use it, run the utility locally;
this would, however, further entail dropping the Record Code field from
the telecom specs (1st column) altogether and also, mandating that all campuses provide full-volume telecom data on each submission, i.e., full-volume transmissions would be required, not optional; it was also noted that this might
lessen data integrity issues over the long-term
it was reiterated that submission times inherent in full-volume data transmissions over the network should be relatively minimal; however, it was suggested that the frequency of the transmissions be flexibile; that is, each campus could elect not to provide the interface on a daily basis;
this would entail their providing a schedule of how often they would be providing the telecom interface; for example, a Monday-Wednesday-Friday schedule would mean that full-volume telecom data would be provided on those 3 days while no data would be provided on the 2 other days (Tuesday, Thursday)
post meeting note: while daily interfaces are not required,
for those campuses electing not to pass the interface on a daily basis,
the ramifications of such a decision should be noted, e.g., the "single universitywide website" could correspondingly be "out of synch" until the next regularily scheduled transmission or supporting data utilized by ESS applications could correspondingly be "out of synch" until the next regularily scheduled transmission
- as an additional transmission confirmation enhancement, it was agreed that header and trailer records should be provided on the telecom data transmission (specs on their respective formats to be provided by OP)
- August 2, 1999 (M) was cited as the due date for the first day to
generate/transmit full-volume telecom data
campuses were asked to confirm by June 2, 1999 (2 weeks after the conference call meeting) that they have no further comments on the interface specs and further, that this schedule could be met
Student Interface Issues:
- it was agreed that the student data should be passed to OP as full-volume transmissions (without the Record Code field) just as had been proposed for the telecom data
- LA proposed either dropping the 4 date fields or making them optional as well as replacing the Student Status field values with 2 values: A (active) and I (inactive); after a lengthy discussion, it was agreed to retain the specifications as they were last drafted and presented to the Campus Registrars (except for dropping the Record Code whose change was deemed acceptable) with the following field definition clarifications:
- "invalid" SSN data should not be passed (hashed) in the SSN field, i.e., though some campuses may include "invalid" SSN data in their local systems, it should be explicitly stated in the student specs that such "invalid" SSNs should not be passed as it will cause reconcilation/matching problems with data from the Payroll interface
- definition of Admitted (A) students for the Student Status field should be clarified to specifically cite inclusion of Student with Intent to Register (SIR), i.e., these students should be passed with a value A
- Student Term Begin Date and Student Term End Date definitions should be clarified to cite specifically the term in which the student is enrolled in, i.e., for what term the student data is applicable for
- somewhat analogous to processing of the telecom interface, it was agreed that campuses may elect to pass the Student Last Name and Student First Name data in mixed case; however, unlike the telecom interface, this would be optional, not mandatory, given that not all campus student systems currently support mixed case processing
it was reiterated that should subsequent, substantive revisions to the student specs be required, then such proposals must again be presented to the Campus Registrars for approval
- OP reported that the SHA-1 algorithm would be the "one-way hash" algorithm employed for hashing the Student ID and SSN fields on the student specs; it was added that the federal government supports usage of this algorithm and it is considered more secure than alternatives such as MD-5
note: OP also reported that it had successfully installed PERL code running on AIX (IBM UNIX) to execute this algorithm and that should any campus request this code, OP could provide the url for downloading; further, a request was made to see if the module could possibly be provided as a callable object on OS/390 (IBM mainframe); OP will attempt to provide such a module
it was further agreed that to avoid ASCII/EBCDIC conflicts, the hashed values themselves would not be converted/translated further upon execution of the SHA-1 algorithm, other than to eliminate intermediary blank spaces; thus, both the hashed Student ID and SSN fields will be passed as 40 byte fields (with intermediate blank spaces, the output field is 44 bytes in length)
- as an additional transmission confirmation enhancement, it was agreed that header and trailer records should be provided on the student data transmission (specs on their respective formats to be provided by OP)
- September 1, 1999 (W) was cited as the due date for the first day to
generate/transmit full-volume student data
campuses were asked to confirm by June 2, 1999 (2 weeks after the conference call meeting) that they have no further comments on the interface specs and further, that this schedule could be met
Next Steps:
- incorporate (if any) post-meeting revisions approved by the group
- distribute updated "official" specifications for telecom and student interface specs
note: unless otherwise requested, the May 19 conference call meeting will be the last time for awhile that the University Directory Technical Workgroup will be called together, though the listserv will remain open, should any issues arise
Return to Meeting Agendas & Minutes Page