Principles of Operation and Frequently Asked Questions for UT Austin SPEEDE Server
Table of Contents
I. What Purpose?
II. Regional Focus?
III. Delivery Medium
IV. Timing
V. Prerequisite Checklist
VI. How to Send
VII. How to Receive
VIII. Testing
IX. Registration
X. Cost
XI. Security
XII. Software Location
XIII. User Actions
XIV. Translation Software
XV. Participant Table
XVI. Standards Constraints
XVII. Code Sharing
XVIII. Obtaining & Using MIME
XIX. Obtaining PGP
XX. Rules of Usage
XXI. How to Get Internet Access
XXII. Production and Implementation
XXIII. Glossary
XXIV. Changes to Server 11/95-4/96
XXV. Changes to Server 4/96-8/96
XXVI. Notes on Volume
I. What purpose?
Go to top
The intent of this project was to provide a simple yet secure way to send SPEEDE/ ExPRESS transcripts via the Internet (and thereby eliminate cost hurdles). Without/before the Server, to send via the Internet, one had generally to do one FTP or send one e-mail attached file per institution to receive transcripts. When sending to a Value Added Network (VAN), one puts all the transcripts in a single file (with the appropriate headers/trailers), and the VAN puts the transcripts in the appropriate mailbox(es). The UT Austin Internet Server supports a similar method:
1) User Action: The user prepares a file of SPEEDE/ExPRESS transcripts (or other EDI transaction sets) just like the VAN file was prepared (1 or more ISA/IEA "envelopes" of documents per institution).
2) Server Action: File is be processed programmatically to translate the ISA origination and destination codes into internet destinations, and deliver the packets using FTP or a MIME-compliant e-mail message with file attachment.
3) Delivery of ANSI ASC X12 files improves since the Server will:
1. Support both FTP and MIME attachments.
2. Allow Sender and Recipient Modes to be different.
3. Allow one easy delivery in either mode.
4. Generate supporting messages, such as Problem Notification via
system-generated e-mail.
5. Support digest mode feature of temporary storage, holding all files until X time before delivery.
6. Support "Send immediately" override ability.
7. Produce status and activity reports.
8. Support a temporary hold on delivery (rather than rejection) while (unregistered) recipient info can be obtained and added to internal table.
9. Support encryption for privacy & added authentication.
II. Regional Focus?
Go to top
By no means is service restricted to Texas. Texas received mor attention in the proposal because of the VAN system which the old TXETN used. This server is available to all educational institutions which need it, can get to it, and agree to play by the "rules" (section XX). are proud of the Texas usage, but (in 4/99) nearly half the activity was from Iowa, Arizona, Florida, South Carolina, and other states. For example, consider the University of Miami, a private school excluded from FIRN usage. Miami-Dade Community College, Kendall Campus (home of SPEEDE legend J. Tom Stewart) sends a transcript to the Florida Department of Education, which converts it from the old proprietary FASTER format (developed for Florida in the mid-80's) to the ANSI ASC X12 SPEEDE TS130 format and forwards it to the Server in Austin, which then routes it to UM. Miami then sends a TS131 back to the Server, which sends it to the Miami-Dade address at the Florida Department of Education, which sends it to Miami-Dade via the Florida Information Resource Network. By taking a free ride of 2,000 miles, it travels the two miles to the University of Miami. The same scenario works for Maricopa County Community College and Arizona State University.
III. Delivery Medium
Go to top
This system is set up to support delivery of ANSI ASC X12 standard envelopes using either FTP or MIME attachments to SMTP mail. Media for sender and receiver may be mixed (e.g., I may use FTP to deliver packets to 12 schools, 3 of which chose to receive via FTP and 9 of which elect to receive in MIME attachments to e-mail messages).
Why do we want to support FTP when MIME exists? (1) For a mainframe student records and translation site, it seems to us that FTP provides a very attractive and much faster way for a school to send a single megafile, with all packets for all recipients, to a single location (the server). (2) Some mailers (like that on the UT Austin administrative mainframe) don't currently support MIME (how easily could that be changed?). We wouldn't want to shut doors unnecessarily. (3) With FTP, we can tell immediately whether our delivery was successful (a bigger benefit than we first anticipated).
IV. Timing
Go to top
Availability is now.
V. Prerequisite Checklist
Go to top
1. Ability to produce EDI documents consistent with ANSI ASC X12
standards.
2. FTP or INTERNET E-mail with MIME
3. PGP execute capability (if you plan to encrypt)?
4. E-mail for inquiries and notification
5. Agreement to terms (see section XX).
VI. How to Send
Go to top
1. Register with the Server (see IX), providing receipt medium, delivery address and parameters, and notification address. Get intended recipients and senders to register as well. If using encryption, give a copy of your public key to the Server. Obtain and store the public key of the Server.
2. Prepare ANSI ASC X12 compliant files with proper ISA envelopes.
3. If using PGP encryption on files sent, encrypt the file using the public key of the Server. Use of the signature option is highly recommended. Encrypted files may be sent via FTP or as MIME attachments.
4. If using e-mail, send files to the following address:
texserv@ediserver.reg.utexas.edu.
5. If using FTP, deliver to an individualized subdirectory pre-specified for your institution. File name doesn't really matter, but having your school's initials as part of the file makes sense, and you might wish to incorporate date or time to avoid the possibility of overlaying a file delivered earlier.
VII. How to Receive
Go to top
1. Register with the Server (see IX), providing receipt medium, delivery address and parameters, and notification address. Get intended recipients and senders to register as well. If using encryption, give a copy of your public key to the Server. Obtain and store the public key of the Server.
2. Watch for personal e-mail (delivered to address specified in #1) notifying you of delivery to the transcript e-mail address or FTP location. Or just wait until the time specified for delivery.
3. If you requested (in your profile, #1) that the Server use PGP encryption on files sent to you, use PGP to decrypt the file FTP'd or the file attached via MIME.
4. Pass the file to your acknowledgement, translation, and processing routines.
VIII. Testing
Go to top
Testing works just like production, but we need to know that you are not yet in production status. For testing with the Server (and UT Austin) via FTP, deliver files (w. recognizable names) to our node (which is ediserver.reg.utexas.edu), and specify the directory to be /usr/local/tran/ftp/testftp. Use testftp (all lower case as your userid, and use TestFTP (4 caps - it is case sensitive) as your password). If you wish to specify an alternate address for delivery of test data, we'll watch the value of the ISA15 variable for "T" (= test), and direct the data to that alternate address.
IX. Registration
Go to top
To register your institution for use of the Server, send the following information to regist@ediserver.reg.utexas.edu:
1. A 2-character code taxonomy qualifier and the code for your institution within that taxonomy. Most postsecondary schools use code qualifier 22 (for FICE). These would be the codes used in the ISA envelope (X12 Data Elements I05 and I06: example 24/6882 for ATP (Admissions Testing Program, used by Educational Testing Service to deliver SAT scores to postsecondary recipients) code set, University of Texas at Austin).__ / _____________
2. Institution Name: ___________________________________
3. Name and phone number of contact person:
Name: _______________________________________________
Phone: ______________________________________________
4. To warn institutions against unknowingly sending production transcripts to a school not yet fully ready to receive, process, and acknowledge, we have added a "test-only message" switch. This causes "*** test only **" to display on the Registrant List (updated weekly on the UT Austin SPEEDE website). Test Only Msg.: _______ (Y/N)
5. We need your public key if PGP encryption is desired. This key exchange can occur after the initial registration. E-mail is recommended for delivery of the public key - if sent via e-mail, your key must be extracted using ASCII armor (see PGP documentation). Even though later PGP versions may not automatically include it, you must use RSA rather than DSS/Diffie-Hellman keys. When you deliver it, we will set your PGP switch and send test files. See section XIX.
6. Preferred time for deliveries to be made to your system by the Server (example 18:30 for 6:30 P.M.). You may specify immediate delivery if you wish. This would cause most deliveries to be in separate physical files unless you specify the append option in #12.f.(2). Or, you may specify a range of times, such as 0400-1100.
Preferred time: __:__ __ (AM or PM) Time Zone: ____or
Acceptable Range: _______ thru ________.or
Quick Delivery: _______ (Y/N)
7. If you wish the Server to never deliver your files to an institution which does not use encryption, please so specify. In this one event, if you ask it to, the Server will enforce your institutional decision (see XXV.(2)). Enforce PGP:__________ (Y/N)
8. Specify whether you wish to receive via e-mail or FTP.
E-mail _________ FTP __________ SFTP_______ FTPS_________
9. Y or N for whether you want e-mail notification of receipt of each transmission by the Server._____ (Y/N)
10. E-mail address for notifications, acknowledgements, correspondence, and problems.___________________________________________
11. If e-mail:
a. receive via MIME attachment? ________ (Y/N)
b. e-mail address for data file delivery ______________________________________
c. alt. e-mail addr for EXPRESS ___________________________________________
d. alt. e-mail addr for test files (ISA15=T): ___________________________________________
e. alt. e-mail addr for Adm Applications (TS189): ___________________________________________
12. If FTP:
a. machine name or IP address ________________________________________
b. user id (for server)________________________________________
c. password (to be used by server) ________________________________________
d. account if VM machine ________________________________________
e. directory (optional)________________________________________
f. file name preferred (server to append a counter)
(1) 6-char. name: ____________________ (unique ctr added)
or (2) file name: _______________________ (new files appended)
g. any other needed information ________________________________________
h. alternate file name for EXPRESS/K-12: ___________________________________________
i. alternate file name for test files (ISA15=T): ___________________________________________
j. alternate file name for adm apps (TS189): ___________________________________________
13. Pending instructions from legal counsel, we feel we may need some sort of signed waiver, as explained in section XX. We will follow with that when we know more.
14. For received files (especially if using a PC), you may specify end-of-line convention.
--- 1.) Line Feed (the default)
--- 2.) Carriage Return
___ 3.) Line Feed + Carriage Return
___ 4.) Carriage Return + Line Feed
___ 5.) Neither Line Feed nor Carriage Return
15. For received files, you may specify record length convention.
___ 1.) Variable length records (the default)
___ 2.) Fixed length (specify record length)
If you wish to see some of your own registrant information, or to determine which other schools are signed on to the Server, you may check http://www.utexas.edu/student/giac/speede/ , where a new table is posted weekly, early every Friday morning. We also post a file of all registrant entries which have changed within the last month.
X. Cost
Go to top
Despite some generous offers to share the cost - most notably by Texas A&M, we have decided that the simplest solution would be for The University of Texas at Austin to bear all costs of the Server. Savings on VAN charges for the Texas ETN could quickly offset expenses. Maintenance of the registrant table becoming a burden would be a great problem to have, as it would indicate an increased level of participation in SPEEDE/ExPRESS - an occurrence which allows much more efficient processing of transcripts and applications at UT Austin. We feel that the SPEEDE/ExPRESS project will offer assistance if expansion to other transaction sets creates administrative burdens. We have received offers of support from several sources.
XI. Security
Go to top
1. Logon limits on Server.
2. Known entity (trading relationship with server).
3. Functional acknowledgement or notification similar to transaction set 997 is possible.
4. E-mail notices about files received, sent.
5. Encryption option for privacy.
6. System activity logs and notifications.
7. Limited exposure - Server to be used for nothing else.
8. Added authentication via PGP private key encryption. Aside: INTERNET SECURITY -- OXYMORON OR ACTUAL FACT? William Cheswick, a senior researcher at Bell Labs, thinks the Internet is risky business and a "bad neighborhood," in which "hackers can eavesdrop on the packet flow ... It is past time for the deployment of encrypted sessions." But investment banker and consultant Ted Prince says: "What we have is a tiny number of hacker incidents that have been blown out of proportion by the tabloid technoliterati ... You have more chance of getting your credit card number stolen in a restaurant or on a phone in Grand Central Station than you do of having it stolen on the Internet." (Computerworld 5/29/95 p. 96, via EDUPAGE 6/2/95).
Q: We're concerned that the UT Austin Server may suddenly be forced to shut down. How will we continue?
10/96 Contracts were signed to have the University System of Georgia maintain this backup site. This will protect users in the event of a natural disaster in Texas and reassure against the unlikely event that UT Austin might decide to get out of the Internet EDI Server business. Without this, the hassle of maintaining codes in additional but separate "look-alike" sites increases exponentially with the number of sites.
XII. Software Location
Go to top
The software which runs the UT Austin Server is resident on the server itself. Users of the server will need to have installed software to support FTP or MIME, and perhaps PGP. PGP software is available (see XIX), as is MIME (see XVIII), but will need to be installed by us. Placement of the software is an important consideration. If the software lived on the originating institution's system, the administrative burden (of running the server) would be greatly reduced. However, the program would have to run on a large number of different platforms, and development and/or support would be very difficult to manage. Living on a central system as it does, only one version of the program is required will require at least some maintenance.
XIII. User Actions
Go to top
An institution sends to the Server a single file, with multiple ISA-IEA envelopes within - one per intended recipient. Each may contain many transcripts, requests, acknowledgements, or other EDI transactions. The Server sends to the specified recipient a file containing one or more ISA envelopes from different schools. The file would be either a MIME attachment or an outward FTP (to a pre-certified delivery address, as a hedge against having to authenticate on the fly).
XIV. Translation Software
Go to top
This server deals only with the delivery of packets. It does not assist with the creation of a flat file from the student data base at the sending institution, nor assist with the mapping of that file into the appropriate ANSI ASC X12 format. The Server expects all this will already be done to create the ISA-IEA envelopes.
XV. Participant Table
Go to top
SPEEDE/ExPRESS has long maintained that a national Participant Table is necessary, and that it must be maintained by a central authority capable of authenticating institutional entries. It carries considerable identifying and operational information. It is also the primary source of the certified acknowledgement address. This should be readily available in an online manner, such as the website of the Postsecondary Electronic Standards Council (www.standardscouncil.org). Direct programmatic inquiry would also be extremely useful.
The UT Austin Server will maintain a separate Registrant Table to show (1) registered schools capable of sending or receiving, (2) ISA codes to identify recipients to the Server (we may include multiple ISA codes which can serve as aliases), (3) an indicator of whether the school uses encryption, and (4) Production or Test Status. This information is prominently displayed, on the UT Austin SPEEDE website, which is updated weekly. The Server itself has additional operational information stored internally. Changes in the last month are displayed in a separate file there.
XVI. Standards Constraints
Go to top
This server will run with no conscience, and it will not attempt to impose its morals on those who use it. Aside from asking for ISA envelopes and compliance with ANSI ASC X12 standards, it will not get involved in the question: What should actually be sent within the (fairly permissive and flexible) framework of the standard? We anticipate only this limited syntax checking. We will have a few constraints, such as mime compliance OR ftp, but only to render the system secure and our task as simple as possible –simplifying assumptions are the only kind to have.
XVII. Code Sharing
Go to top
Questions have been asked, such as: "If using your services were, for some reason, unacceptable but sharing your code looked like a deal how might we move forward on that point?"
Our first answer is that working together would be great. In fact, code listings obtained (4/95) from Les Pennington (Washington) were very helpful to us.
That said, we feel it might be bad if every state developed a server of its very own, unless that server added significant benefit for the users. Each institution would need to be registered on each server in order to be reachable via it, and this could complicate delivery, in addition to multiplying the cost of the server - unless some extra value-added features unique to a state or region (such as with the Florida Information Resource Network or the Maryland Repository). We would encourage distant schools to first try this server and see which services could not be directly obtained from it. We could then work on collaborative efforts to provide them. We have no installation manuals and no routine procedure for forwarding modifications, and it took us a nearly a year to make the Server operational.
*To secure against an eventual shut-down of the Texas Server, we signed a contract with the University System of Georgia for maintenance of a hot backup site, with operational code stored and tested there on a separate machine. That said, we plan to be in the business for the long haul. SEE XI.
XVIII. Obtaining & Using MIME
Go to top
MIME = Multi-media Internet Mail Extensions. MIME is already available with many mailers, such as Eudora. MIME capability may be included via MPACK and MUNPACK, both of which are available from ftp.andrew.cmu.edu in directory pub/mpack. Extended MIME protocols are found in Internet document RFC 1767 -- MIME Encapsulation of EDI Objects (Proposed Internet Standard), D.Crocker: available from ds.internic.net in directory rfc, as file rfc1767.txt.
The server will specify "application/EDI-X12" as the content-type when attaching files of ISA envelopes - encrypted or not - via MIME for delivery to institutions. This Server should serve as a test site for the proposed standard.
Note that as of 5/99, FTP seems the preferred medium by schools using the Server.
XIX. Obtaining PGP
Go to top
How to acquire PGP software at no expense.
PGP freeware is available from MIT at http://web.mit.edu/network/pgp.html for many platforms, including Macintosh, DOS, and UNIX. Check there first for a freeware version of PGP 2.6.2 for your platform. MIT no longer distributes PGP via FTP. MIT distributes PGP versions 2.6.2 and higher for Macintosh, DOS, and UNIX, for non-commercial use in the U.S. only - it may not be exported. For the Mac and DOS-based versions, executable files are provided which must simply be un-packed and moved to appropriate folders or directories.
A note on PGP 5.0 and 6.0.2: The server uses PGP 2.6.2, so you must use a version of PGP capable of generating RSA keys to be compatible. It appears that the freeware versions of PGP 5.0 and 6.0.2 are not able to generate RSA keys. If these are the only versions available for your platform, you may have to buy a copy from Network Associates, formerly PGP, Inc. at http://www.pgp.com. The business version costs around $100. Make sure you obtain the wRSA version!
PGP for MVS is a product of Neon Systems, Inc. See their Web site at http://www.neonsys.com or call them at (800)505-6366 for information. We have done some compatibility testing of this product with the server, and it seems to work. We'd be glad to add information here about other PGP products that you might call to our attention.
The documentation that comes with PGP includes complete instructions for installing and using PGP. The book PGP, by Simson Garfinkel of O'Reilly and Associates, Inc., is another good reference. Cecily Allmon is our PGP resource person, and she can be reached at (512)475-7598 or nrcea@utxdp.dp.utexas.edu.
Give it a shot. Call if you need to. UT Austin has adopted an internal policy requiring encryption when we send our own transcripts over the "open" Internet (outside the area covered by THENET, which uses a single carrier). We will still receive an unencrypted transcript which another institution chooses to deliver to us. We also do not impose these values on the Server - it has capability to encrypt, but no noticeable conscience.
XX. Rules of Usage
Go to top
UT Austin has approved the Server but is reviewing this proposal to see what types of contracts and liability disclaimers may be needed. Please regard these rules as tentative. We do feel comfortable with the philosophy of the contents herein, though.
1. Users (those who send documents via this system) are required to first (i) register with the UT Austin Server, (ii) provide operational info (for inclusion in internal Registrant Table), (iii) verify suitability of platform, and (iv) perform test exchanges for evaluation of procedures and syntax.
2. UT Austin plans not to charge for basic educational documents exchanged between educational institutions.
3. UT Austin will not allow unauthorized persons access to any files while they are stored within this system.
4. UT Austin will never look inside an electronic packet except to parse it, count it, take the specified action, or investigate problems with the above.
5. UT Austin will not be held liable for damages deemed to have been caused by use of this system.
6. UT Austin reserves the right to deny access for a number of reasons, including failure to follow protocol, use for profit, and use outside the education arena if it results in significant additional administrative requirement.
XXI. How to get Internet Access
Go to top
Q: I either don't have any Internet access, or my mailer does not support MIME and PGP. How can my institution play in this game?
A: (to answer this question, commercial online Internet services were researched by a freshman employee, who also is a Son-of-a-Registrar - the expletive of the 90's, perhaps). "Out of the four online services I surveyed (AOL, Compuserve, Sprint, and Network MCI), Compuserve will probably be your best bet for a national online service provider. The rates ($9.95 for 5 hours a month + $2.95 each additional hour) are comparable to AOL's rates. Compuserve has also not been tarnished by some of the customer service problems seen by other providers. Sprint doesn't offer an online dial-up service, and MCI only offers their Network MCI package where a client must pay a $39.95 software fee, $18.95 registration fee, $9.95/mo. access fee, and a $5.95/hr online fee..this is more business-oriented, not really for online usage. Both AOL and Compuserve offer the ability to send MIME attachments and both offer FTP access through their software packages." dkb. 2/96
XXII. Production and Implementation
Go to top
1.) Can we receive files as soon as they are transmitted to the server?
Yes. Immediate delivery rather than once per day is an option.
2.) Are there naming conventions for files dropped off on the server?
No. Any name is acceptable when dropped off via ftp.
3.) What is the naming convention for files delivered from the server via ftp?
If the "append" option is chosen then any file name may be used. Otherwise the file name will have a 2-digit counter appended to the name to prevent overlaying files. The name may not exceed 6 characters. It may include an extension.
Example:
ABCDEF - files will be delivered as ABCDEF01 - ABCDEF99
ABCDEF.DAT - file names will be ABCDEF01.DAT - ABCDEF99.DAT
4.) Can the server deliver files to a GDG (Generation Data Group)?
Yes.
5.) Can the server deliver SPEEDE & ExPRESS files separately?
Yes, if one e-mail address or file name is specified for SPEEDE while a separate one is specified for ExPRESS. (Likewise w/ separating prod from test data by the end of this month)
6.) How much trouble is it to change registration information?
Very little. Generally changes such as changing from e-mail delivery to ftp delivery are completed within a day.
7.) Will we be notified when data is delivered to our institution?
Yes. A notification message is sent to the e-mail address specified whenever the server delivers to the institution. If the delivery is made via ftp the message will list the file name & directory.
8.) What is the IP address of the server?
146.6.62.4 is the front end server at this time, but this is not fixed for all time. That is, it could possibly be changed. Our back end server is 146.6.62.5.
9.) How can I separate test files from production files?
Data element ISA15 may be set to 'T' for, test, 'P' for production. You may specify a separate testing address for the Server to use to deliver files with ISA15 set to 'T'. This will happen behind the scenes, another value added service of the Server.
10.) Has the server changed Internet names?
Not really, but we have a new alias, and we will publicize the use of EDISERVER.REG.UTEXAS.EDU rather than (the original name) REG034.REG.UTEXAS.EDU.
XXIII. Glossary
Go to top
Intro to Important Internet & EDI Terms
There are two main flavors of Internet, namely FTP and SMTP.
FTP stands for file transfer protocol, and involves a direct logon to the site at which the file is being delivered (or picked up). FTP connections can move files extremely fast if both machines have quick data connections.
SMTP is simple mail transfer protocol, or just e-mail. It has great (pronounced S-I-M-P-L-E) addressing features. Both use the same data lines to deliver their goods. More installations (hosts) support SMTP than FTP.
MIME (Multipurpose Internet Mail Extensions), is a protocol which runs on top of (with) SMTP and allows the mail message to be broken into distinct parts, including address, header text, and various attached files. This allows a computer system to recognize the types of data in attached files and treat them in special ways. The attached files have labels such as "binary data". Why is MIME Important? Naked Internet e-mail works well, effectively delivering packets to their intended destinations. However, MIME has an advantage over straight SMTP in that: (1) It allows recognition and proper processing of mixed traffic. (2) It allows separation of addressing from encryption, (3) It allows e-mail to carry packets which look like those delivered via FTP, which enables those processes to converge quickly on both the sending and receiving end, and (4) MIME seems to protect against splitting of large files - something which happens frequently with some e-mail software.
IETF. The Internet Engineering Task Force (IETF), via document (request for comment) RFC1767 and at the behest of SPEEDE/ExPRESS, has endorsed the use of SMTP for conducting EDI on the Internet, but with an expanded set of codes for the MIME attachments. The expanded set of labels includes: (1) ANSI ASC X12 packet, (2) United Nations EDIFACT packet, and (3) other EDI packet.
PGP, Pretty Good Privacy, is a program which encrypts mail. It's available without charge via the Web, and runs on the following platforms: DOS, the Macintosh, OS/2, Unix (all varieties), VMS, the Atari ST, the Commodore Amiga and windows.
TENET. Texas Education NETwork, owned by TEA and provided for use by public schools (pre-K thru 12) in Texas, but available for use by Texas colleges in exchanging transcripts. TENET runs on an Internet backbone, and it has MIME capability. It could be used by a college as a jumping off point for the UT Austin Server.
EDI - Electronic Data Interchange (computer to computer)
ANSI ASC X12 - voluntary, open accreditation body for EDI standards. American National Standards Institute (ANSI); Accreditation Standards Committee (ASC). X12 is that branch which deals with EDI standards, as opposed to light bulbs, tires, bolts, etc.. Transaction Set - ANSI ASC X12 standard format for single application, such as an invoice or a purchase order, . . . or a transcript.
XXIV. Changes to Server 11/95-4/96
Go to top
1. We added Section XXI to this FAQ to explain options for obtaining an Internet account through a private provider.
2. One may specify immediate delivery as an alternative to once per day.
3. The server can deliver files to a GDG (Generation Data Group).
4. The server can deliver SPEEDE & ExPRESS files separately if the recipient/registrant specifies one e-mail address or file name for SPEEDE while a separate one is specified for ExPRESS.
5. Who is using the Server? Check the UT Austin SPEEDE website at http://www.utexas.edu/student/giac/speede/ the UT Austin Internet EDI Server Registrant list. This is refreshed weekly. It now flags institutions involved only in a test mode.
6. The Server will separate test files from production files. Data element ISA15 may be set to 'T' for, test, 'P' for production. You may specify a separate testing address for the Server to use to deliver files with ISA15 set to 'T'. This will happen behind the scenes, another value added service of the Server.
7. The Server has a new alias, and we will publicize the use of EDISERVER.REG.UTEXAS.EDU rather than (the original name) REG034.REG.UTEXAS.EDU.
XXV. Changes to Server 4/96-8/96
Go to top
The UT Austin Server continues to function, with more schools registering, testing, and using it in production mode. Some new functionality has been added to the system software, thanks to the continued dedication of my team, including Jean McArthur, Wally Reeves, Cecily Allmon, Lisa Barden, and Tom Yu. Developments are:
1. To protect institutions from unknowingly sending production transcripts to a school not yet fully ready to receive, process, and acknowledge, we added a "test-only" switch. This causes "*** test only **" to display on the Registrant List (updated weekly).
2. Some schools wish to not send over the Internet to schools not using encryption. While they can tell from the Registrant List whether an institution uses PGP, they are afraid that the PGP status might change from use to disuse without their knowing. We have added a PGP-only switch which will enforce their wish, notifying them that an ISA envelope of data was not delivered due to non-use of PGP by the intended recipient. That is, while the Server itself has no conscience, it will permit users to exercise their own rules. (** note: we are watching to see whether the institution which requested this feature will actually use it.)
3. We have improved the internal logging by the Server so that it more accurately counts ST-SE transactions, rather than records (and some schools have used one record per segment, while others used one per transaction). This will support our ability to produce meaningful counts and more meaningful reports of activity.
4. We have found that, especially with e-mail deliveries, some files arrive using end-of-line conventions (ranging from line feed carriage return, line feed and carriage return, to nothing at all which cause problems for their processes. We will now allow institutions to specify to the Server the end-of-line convention to use when delivering to them. This should be especially helpful to (and also protect others against) those schools writing their own translation software. Expect this by mid-September, '96. See Section IX for options.
5. Similarly, a wide variety of blocking schemes are used for the files. PC's typically use 80-character records, while mainframe systems use various specifications for record length and blocking. Some terminate a record whenever the segment ends; others do not. Some use blank fill on the remainder of the (usually 80) characters; others do not. We will allow recipients to specify their preferences for blocking. (*** A caveat: we can't control what your mailer does with the file once we deliver it. Your system might convert it a second time, so we'll want to test the output, and possibly modify your selected parameter.). Added mid-September, '96.
6. This is exciting. We have a formal agreement with the University System of Georgia that they install and maintain a copy of the Server software and tables, allowing them to step in should the UT Austin Server be struck by disaster - natural or un-. Unless calamity strikes, though, they will actually use the UT Austin Server for their exchanges, which makes the delivery and registration process far simpler. Hopefully, this will soothe the nerves of those who want to be sure the Server will still exist when they come to use it.
XXVI. Volume
Go to top
http://www.utexas.edu/student/giac/speede/server/logrpts/usage2003.txt