Standards to Support National Cooperation in Applying Technology to VET
Electronic mail is a fundamental means of communication in many workplaces and between VET sector participants, including learners, teachers, trainers, administrators and student-support counsellors. It provides a powerful communication mechanism in both one-to-one and one-to-group modes. Email is rapid and reliable, is unaffected by distance and has very low costs. It is ideal for distance education and the group communication which is so important in most educational activities and in many workplaces.
The value of email for rapid, asynchronous communication between two individuals is well known. This analysis places special emphasis on the use of mailing-lists, both for classes and for communication between VET professionals with common interests.
It is assumed that the learner needs email communications for research, for communicating with other learners and VET staff and/or for continuing their educational work from home or from the workplace. While it cannot be assumed that every learner wants or needs email, or needs to study from home, it could be argued that both email and Web access should be considered as a basic resource and skill-set for much vocational educational training, not just those involving flexible delivery to learners at remote locations or those fields of work which directly involve computers.
Firstly, email supports easy communication to the class, from the teacher/trainer or from any of the learners, which is not usually feasible with paper or telephone based forms of communication. It is low-cost, does not require the other person to be available at any particular time, allows carefully considered responses with easy quoting of the original text and works with electronic text which can be stored, printed and forwarded to others. Secondly, email is a valuable means of communicating with other learners in the same class, as well as with the teacher/trainer. Finally, email is increasingly part of many working environments, so email skills are of direct vocational value.
At the email workshop, Claire Hughes of the Canberra Institute of Technology, said: "Email is a fundamental tool for any kind of collaborative endeavour. It is vital for professional development and class work." She added that it is needed not just for students working from home, but for those who study on site, because email provides a better (in some respects at least) means of communicating with teachers, and because due to time pressures, "teachers find it very difficult to have an open door policy".
The LANs used in VET institutes generally provide some form of Internet connectivity - often with restrictions due to security or for the economic reason of reducing traffic to and from the Internet. LANs typically run the TCP/IP protocols of the Internet, but may also carry traffic using older networking systems, such as Novell's.
VET institute email systems interwork with the Internet, but some of these systems, such as those of Microsoft, Novell and Lotus, were initially designed to work over proprietary LAN protocols and to carry proprietary message formats. The way these systems interwork with the Internet is the source of significant technical and operational difficulty, for the users of such systems and for Internet users who receive their emails. It appears that all these systems are technically capable of respecting Internet standards and supporting Internet usage. The difficulties arise when they are installed in a manner with inappropriate configuration settings.
Ideally, teachers and learners who have email accounts at the VET institute should be able to access those accounts freely from anywhere outside the institute, but this capability is not always provided. Users within the institutes are typically capable of accessing their email accounts on servers external to the institute. This depends on the configuration of the institute's firewall to allow POP3, and ideally IMAP4 traffic.
The current status of technology deployment is shown in the following table:
|
Application Objectives |
Key Success Factors |
No. of students |
No. sites |
Metro/ Regional ? |
Existing Technology/ Standards |
|
| NSW TAFE | Staff/student interaction & information exchange | Student use | Approx 27,000 full time 270,000 part time |
Metro & Regional | MS Exchange (for staff)
MS Exchange client version 5 for student pilot |
|
| SA DETAFE | Universal and economical email communication and attachments | Minimal maintenance
Economical transparent |
Approx 2000 | 60+ Internet | 50/50 | SMTP/MIME POP3 Eudora MS Mail (move to Exchange being assessed) |
| ACT/ CIT | Staff/student interaction and information exchange. | Student Use | 7 | MS Exchange
NT4.0 |
||
| TAS Flexible Learning Centre | Tutor-student feedback/ interaction | Timely assistance | 350 | 22 | Intrastate
Interstate Overseas |
Novell Groupwise 5.2 POP3 IMAP4 |
| Vic TAFE | Included in Groupwise | SMTP adopted | ||||
| WA | Novell Groupwise 4.1 and 5.2 MS Mail |
The ascendancy of the Internet and its SMTP approach to email is assured - over proprietary protocols and the X.400 approach to addressing and forwarding mail. Similarly MIME as a method of attaching files is gaining universal acceptance.
The importance of email for many purposes of communication, including many educational purposes is well recognised. Email is likely to become at least as valuable as telephony for many of those who can access it.
POP3 is the most established protocol for clients accessing incoming email from the account's server, but the IMAP4 protocol is increasingly being adopted in place of POP3 or, more commonly, as an alternative. IMAP4 provides improved security and a much more sophisticated functionality which enables a user to maintain some or all of their mail, in separate mailboxes, at the server. This enables users to access incoming emails and past emails from multiple computers. IMAP4 support in client software is growing - notably with the full support offered by the Messenger email client within Netscape's web browser.
There are a number of ways in which mail-clients and mail-servers communicate, and a number of ways in which mail-servers communicate with other mail servers. For instance proprietary networks and office/groupware suites may implement email client and server functionality in ways which make sense within that suite, but which are awkward or incompatible with email to and from the Internet.
Globally, the primary approach to email addressing and forwarding is SMTP (Simple Mail Transport Protocol). This is a 1982 standard from the Internet Engineering Task Force - RFCs 821 and 822. SMTP is used by the client when sending to its server, and by that server to the recipient's server.
POP3 and IMAP4 are also Internet standard protocols. They both enable a client program to retrieve emails from the server on which the user's account resides. Like SMTP, the server and client can be located anywhere in the world, rather than the proprietary approaches which only work on particular networks, or with particular software or operating systems.
POP3 typically, though not necessarily, downloads all emails and deletes them from the server. IMAP is a more sophisticated "client-server" approach in which emails are typically accessed from, and managed and stored for long periods at the server in response to commands from a remote client program. POP3's authentication method is a security problem since the user's password is sent directly over the Internet, while IMAP4 uses a cryptographic challenge-response system which has no obvious security flaws.
The other major approach to addressing, routing and delivering email globally is X.400. This is a formal ISO (International Standards Organisation) standard, which is used by some organisations, primarily in Canada and Europe. Such organisations typically have email gateways to the Internet's SMTP system.
When a larger file or multiple files are stored and sent as email attachments, it is often most convenient to compress the file(s) into a single, more compact archive. There are three major approaches to this on the three major types of operating system platform. On the Macintosh, Stuffit is most commonly used. On MSDOS/Windows machines, PK-ZIP has long been the standard. On Unix systems, the Free Software Foundation's GNU-ZIP format is most widely used.
Such programs perform two or three functions:
Compression is important for longer text, word-processing and spread-sheet documents. For instance one of the most reliable ways of transferring a Word document is to convert it to Rich Text Format, but the result can be a very large file indeed - especially if the document contains graphics. Such files can typically be compressed a great deal, and so be faster to send and receive, and so they fit within size limits imposed by some servers, user mailboxes and mailing list servers.
Fortunately anyone using archiving is likely to be sending the archive to a recipient with the same operating system - so there are fewer interoperability problems. In an environment where Windows, Macintosh and Unix are widely used, the file compression problems are typically solved by the recipient having software capable of handling both PK-ZIP and GNU-ZIP - but there are still problems for many users, especially when receiving Macintosh Stuffit archives on Windows or Unix systems.
A second issue relates to how files are attached to emails. Existing approaches include:
Of these, only one is used almost universally and is an accepted, open-ended, global standard: MIME from the Internet Engineering Task Force. MIME uses Base 64 encoding, amongst others, in a clearly defined manner which enables an email to have multiple sections, each of which can be text, a file or material in a particular format, such as HTML. An attached file will typically be encoded with Base 64, which uses about 1.4 characters per byte of the file.
All email users must be able to reliably and easily send and receive files as email attachments, email to the groups of people of interest to them, and receive such email from members of those groups. Thus email can be used as a basic form of "groupware", without the need for any special software.
While basic email usage is quite straightforward, the most valuable, sophisticated uses require significant skills, organisation and appropriate software or services. Advanced use of email, such as participating in several busy email-lists and keeping a record of all received and sent emails, requires client software with functionality such as being able to filter incoming email automatically into particular mailboxes, based on the contents of headers, and the ability to sort and search mailboxes in a variety of ways.
Unfortunately there has been increased adoption of email clients, or email systems, which do not send emails in the form they appear to the sender as they are being written - or at least standard email clients of recipients are not guaranteed to be able to reconstruct what the sender wrote. In some cases this is caused by the sender's client enabling fancy text formatting - and sending the email as HTML or RTF, perhaps with a plain text version as well. However few recipient clients are capable of interpreting HTML or RTF, and the plain text version does not convey what the sender thought they were sending. Another problem relates to clients or email systems which display the email to be sent with a certain line length on screen, but actually send the text after wrapping it to a different line length, or with each paragraph as an arbitrarily long line.
In all these cases confusion results because firstly the recipient sees something different from what the sender wrote, and secondly the sender is typically unaware of this.
Operational guidelines and related email client functionality are discussed in greater detail in the following sections. Generally it is assumed that the email server does not alter the message at all, and that the sender and their client software is entirely in control of the message which is sent. In some systems, such as Lotus ccMail or Novell Groupwise, the client and server do not follow this model, do not use Internet standards and do not necessarily follow the conventions and standards of Internet email. In those cases compatibility with Internet standards may be handled by a third item of software - a gateway. Thus there can be problems of a significant difference between what the sender sees when they write the email (which is probably similar to how it appears to recipients in their office), and what is actually sent to Internet recipients.
The operational guidelines include both what users should do, and how their "client" software - or in the case of non Internet email systems, the combination of client, server and gateway - should be configured.
Users of Internet compliant software sometimes disparage the continued use of proprietary systems such as Novell Groupwise or Lotus Notes, based on the awkward or hard-to-read emails they sometimes receive from these systems. However their continued use is inevitable since within their own system they provide additional powerful "groupware" functionality which is valuable to larger organisations and which cannot currently be provided with standard Internet protocols. All these systems can be configured to respect Internet technical standards and conventions (although perhaps not in a way which the sender can see or control) - the problem is that they are sometimes mis-configured by default, creating difficulties for all their users.
For simplicity this discussion is based on the Internet model of email, in which a client sends an email to a server, and that server performs no changes on the content of the email, but sends it to one or multiple other servers where the recipients' accounts reside. Finally each recipient's email client software retrieves the email from their server. Other than converting quoted-printable encoded text into 8 bit ASCII, the servers do not alter the content of any email which complies with SMTP.
Proprietary LAN-based email systems may operate in a different manner. The client and server may not use Internet protocols at all, nor may they messages they send comply with SMTP or follow accepted Internet email practice. A third item of software - a gateway - may translate the internal format into an SMTP compatible form for sending to the servers of Internet recipients. This raises problems of the outgoing email having been changed from what the sender wrote on screen, without the sender realising.
It is not possible to discuss in detail how such proprietary email systems should function internally (in terms of their clients, servers and gateways) in order to best support communication with Internet users. The goal in choosing and configuring such proprietary systems should be that the sender can easily write an email in a form which is compatible with Internet standards (such as not showing fancy formatting which cannot be conveyed in plain text) and that the system should send the email to the Internet in that form, without transformations to the content which are not visible to the sender.
Two other architectural variations are sometimes used by VET institutes. Firstly a program which behaves as an email client, and perhaps server as well, but which functions as a web server so that remote users interact with it via standard HTML and/or a downloadable Java applet. Secondly the use of a "Windows Terminal" program, where remote users operate an email client program of some sort which is actually running on a server at the VET institute. The remote user can do this via the Internet or a dial-up modem connection, using special software or using a Java applet in a web browser - using a computer running Windows, Unix or the Macintosh operating system. In both these cases the client is really at the central server, and the protocols by which users operate that client are not important to the functionality of the email system - provided they pass through any firewall at the institute, and any firewall at the site where the user is situated (such as their workplace).
There are several areas in which technical and operational factors affect the ability of the user to communicate clearly and efficiently with email:
Some operational matters – such as line-length and quoting style – if standardised, would make email easier and more reliable to use. These are discussed in the section on client program functionality. Successful outcomes in these fields depend on several factors:
Some of the approaches discussed below relate to Internet technical standards and others relate to features of the email-client program which best support the group communications which VET participants will be using as part of flexible delivery. (This focus on the client assumes that the server is a standard SMTP server, such as "sendmail" or "qmail", which does not alter the content of the email.)
The provision of email discussion-list servers does not involve standards, other than the choice of which software package is most suitable, but it would be advantageous if operational guidelines could be developed to help new users productively participate in email-list discussions.
Cost is not necessarily an issue in choosing software with the optimal characteristics. Robust, widely used server software for providing email services on Unix systems is available without cost. Full-function standalone freeware client programs for Windows and Macintosh are also available - such as Pegasus Mail - and both Microsoft's and Netscape's browsers have built-in email clients.
The cost of commercial email clients and servers for Windows and other operating systems, or broader systems such as Groupwise or Notes, may be justified by their consistency of user-interface and integration with office-suite applications. However the difficulties which some of these monolithic proprietary systems may present when sending email to Internet recipients should be considered when estimating their total contribution to productivity.
A VET institute system's email should be capable of sending and receiving email, including email with MIME attachments, to and from all Internet email servers in order to support distance education and the many other purposes for which email will be used. Therefore it should exchange email with Internet servers using the SMTP protocol.
Except in the case of proprietary systems as discussed above, SMTP is the only option for sending email from the client to the server.
Traditionally all email servers would accept an email from any client or server, but the abuse of this by commercial mass mail "spam" advertisers has forced a change in the standard configuration of servers. Accepted practice for mail servers is now to only accept email from client programs running on computers on the network which is owned by the organisation which runs the server. This is a reasonably effective means of preventing misuse of the server by unauthorised people. Such is the problem of such abuse of mail servers that some system administrators are configuring their servers to refuse to accept email from servers which still allow relaying of email from computers outside a trusted network. Therefore there are good reasons why VET institutes should not allow their servers to be accessible for relaying email from outside their networks. The workshop did not discuss this as a standard or operational guideline, and it is evident that many VET institutes are restricting relay access to their servers appropriately.
Consequently a standard or operational guideline for servers to communicate with all other Internet servers using SMTP does not include the requirement to accept email relayed from clients outside the institutes network.
POP3 is the most widely used protocol for accessing email from the server, and should certainly be supported. IMAP4 enables more sophisticated email use for the user who must access their account from several computers, including those which they do not own themselves. A perfect example of such a user is a VET learner who uses one machine at work, another at home, one or more at various locations in the VET institute - and perhaps a laptop with a GSM phone as well.
The most widely used, and freely available, packages on Unix systems for both POP3 and IMAP4 are the following from the University of Washington (http://www.washington.edu/imap/ )
Server
Clients
Further details can be found at: http://www.washington.edu/imap/
A separate issue is the accessibility of the POP3/IMAP4 server from various Internet locations. A server which is only accessible to clients within an institute's network makes it impossible for users to access incoming email when they are at home or at their workplace.
There are difficult questions regarding the cost of bandwidth to support externally accessible email accounts. Ideally accounts should be accessible externally with both POP and IMAP4, but there may need to be limits on storage capacity (in the case of IMAP especially, where users typically leave their mail in mailboxes at the server) and bandwidth. On the other hand, imposing limits on mailbox capacity may result in bounced emails which further add to traffic, cause loops in mailing lists and disrupt communications.
One approach to bandwidth management is to impose a limit on the size of emails - perhaps with different limits depending on the time of day. It would be desirable to establish a national standard on what the lowest limit is, so that all VET users can send emails which are below this limit without concern about them being rejected. A 1 Megabyte limit was chosen by the workshop.
It is valuable to standardise minimum client functionality and to develop operational guidelines for configuring the software and for general email usage.
To maximise communication and minimise confusion, it is necessary to specify certain guaranteed functionality at the recipient client, and to ensure that the sender's client enable the sender to easily compose an email which will display without alteration in the recipient's client environment. Any disparity between what the sender sees on their screen before they send the email, and what the recipient sees on screen or on paper, will cause confusion to the recipient - and so from the sender's point of view will invisibly interfere with communication.
As discussed above, a necessary requirement for email clients is the ability to send and receive MIME attachments. However the clients may be capable of sending in other formats, so it is desirable to establish an operational guideline that MIME should always be used when sending attached files.
Where there is a need to archive and compress several files together for attachment, a problem arises because of difficulties in extracting the files on Mac, PC and other systems.
As discussed in Section 5, the most popular formats are: PK-ZIP format, Stuffit and GNUZip. Fortunately, widely used programs such as Stuffit and WinZip are capable of extracting files from the other formats - but this can be tricky for the user. While it may be desirable to establish a usage guideline for archiving files before attachment, the workshop did not decide on a system to standardise upon.
While Internet security threats are easily overstated, there will often be a need to encrypt and/or digitally sign text and files which are sent via email. The most widely used program for doing this is PGP - Pretty Good Privacy - which is available (free for individual users) for Windows, Mac and Unix machines. The recently released version 5 of PGP is very much easier to use than its predecessors. Email clients are likely to integrate more closely with this program.
PGP can also be used to attach digital signatures to emails. Digital signatures enable the recipient to check the entire email with the sender's public key to verify that the message is genuinely from that person and has not been corrupted. Since it is easy for impostors to send email so that the sender seems to be someone else, digital signatures are a valuable method of detecting and discouraging such practices.
These fields - encryption, signatures and the Public Key
Authentication Framework (PKAF) for validating signatures - are
rapidly evolving and the workshop decided that it is premature to
set standards for them at this time. A valuable resource for
email security is:
http://www.imc.org/mail-standards.html,
which mentions the Open PGP and S/MIME standardisation work.
Flexible delivery using email involves not just one-to-one communication, but the ability for a member of the class, whether a learner or a teacher/instructor, to email to all members of the class. One approach is for all class members to have an address list in their email program, but this is difficult to manage and update.
A far better approach is to use an automated email-list server. The freeware Unix program MajorDomo (http://www.greatcircle.com/majordomo/ ) or MajorDomo 2 (http://www.hpc.uh.edu/majordomo/) is most often used for this purpose. It can support moderated mailing-lists - where an editor checks what is posted to the list members - or it can forward all emails from members immediately. MajorDomo and other mailing-list programs such as Listserv must run on a Unix machine which is operating as a mail server. A Unix list server requires some expertise to set up, but is relatively easy to administer. Each list can have separate administrators and moderators, and all interaction with administrators takes place via email, or via a web interface. The list server provides a single address for list members to use, and enables changes in the membership of the class to be handled by the list administrator and/or for participants to join and alter their addresses themselves.
Some shareware Windows 95/98/NT mail server programs include mailing-list functions, for instance FTGate (http://www.floosietek.com/). A useful extension of an email-list server is to make the list's activity available as an archive on a Web site, typically password protected so that only the list members can access it. If this is done by a program which automatically structures the threads of the class discussions, then the resulting archive is a valuable resource for all class members, especially those who join the discussion after its commencement, or who are unable to keep up with the discussion for a period. Ideally the archive would be searchable. Software is available (for Unix and other systems) to create thread-structured web-based archives of mailing lists, for instance MHonArc, which also decodes MIME attachments and makes them available as clickable links. Search engines for such archives include Glimpse and Wilma. These three programs are freely available via the MajorDomo 2 site mentioned above.
Email-lists are valuable for almost any group of people with common interests. A good example would be a mailing-lists for VET teachers, instructors and course creators who are involved in a specific subject area.
One approach to supporting these mailing-lists and any related Web-based archives is for a special site and administrator on a state or national basis to be devoted to this task. A more decentralised approach would involve multiple sites and administrators around the country, who could assist each other by communicating via a mailing-list.
The technical experts agreed that mailing lists were extremely valuable and in high demand. It is beyond the scope of the current project to recommend how it can be achieved, but it is clear that VET education, especially that involving flexible delivery, would be greatly facilitated by all teachers having an easy way to establish and manage mailing lists. This involves the provision of servers and Internet connectivity - with the technical staff to manage them and to support all those who want to establish and run mailing lists.
The question of operational guidelines and any technical standards for mailing lists has not been considered here.
The following sections include the formal outcomes of the workshop.
Since LDAP directories represent a target for automated systems of identifying people and building lists of email addresses for unsolicited and unwanted email, a staff member's prior consent should gained before their email address or other contact details are made available in such a directory.
(This is a functionality for LDAP directories, as well as for the LDAP capabilities of clients. The privacy issue is arguably an operational guideline but has important ramifications for personal privacy, so it is stated with the functionality it relates to.)
While it was recognised as being desirable for a VET institute to provide email accounts for all teachers and all students who wanted them, and for those accounts to be accessible (via the Internet using POP3 and/or IMAP4) from outside the institute, a number of barriers to achieving this were identified:
Email mailing lists are an important and easily accessible form of "groupware" for classes and groups of people with common interests, such as teachers in different institutes - and in other countries - who teach the same subject. Since a mailing list involves some technical expertise to establish, and must be run from a mail server, it would be desirable for institutes or states to provide resources for the staff and servers so that any teacher who wanted to establish a mailing list could do so. The staff would technically support the mailing list and potentially its searchable password-protected web archives, and support the list owners - who would be responsible for the membership and potentially the moderation of their lists.
POP3 is a simple protocol which has security problems because it sends the password in cleartext to the server. It's functionality is adequate when the user is accessing their email account with one computer, or for low volumes of mail via multiple computers. IMAP 4 is a secure protocol which enables the user to maintain some or all of their email on the server, with multiple mailboxes and with powerful search, sort and filtering facilities under direct control of the client. Suitable email clients (such as that of Netscape Communicator 4.5) can access these mailboxes at the server as well as maintaining mailboxes on the client computer and transferring emails between them.
The functionality of IMAP4 is essential for serious email users who must access their account from multiple computers. Email server software and combined IMAP4/POP3 software to access the server's email accounts is freely available for Unix systems. Server computers which support IMAP4 will typically require greater storage for user's multiple mailboxes, and users are likely to generate more traffic with the server than if they were simply retrieving the email with POP 3.
[Home page] [Copyright statement] [Feedback]
Last modified on May 05, 1999.