CORPORATE EXTERNAL GATEWAY

DOCUMENT INTERCHANGE
SYSTEM 

SPECIFICATIONS FOR DIRECT CONNECT USERS

	  	Version:			11.27

		Date Issued:		30 Oct 2012

		Contact:			Dennis Pinner
						Australian Taxation Office
						Ph:	(02) 6216 4697

		Document Reference:	DISV11R27.RTF

NOTICE TO READERS

This specification is current at the latest date shown in the 'Summary of changes' (next page), but it may be amended at any time without prior notice. Only those persons and companies who have been sent copies by the Australian Taxation Office (ATO) will be notified of changes.

The ATO is not responsible for the quality or merchantability of software developed on the basis of this specification and the ATO does not support such software.

Copyright © Australian Taxation Office, 2012 with all rights reserved

This document is the property of the ATO.  No part of this document may be copied and used in other publications unless ATO authorship is acknowledged

Date	Summary of Changes
1/12/92	Draft release for review and comment
8/2/93	Version 9.1 released
18/1/01	Version 10.3 released
27/8/02	First IP draft - Version 11.0 
30/4/04	Version 11.2 released
19/10/04	Version 11.21 released
29/10/04	Version 11.22 released (preliminary)
2/12/04	Version 11.22 released
29/7/05	Version 11.23 released
9/9/05	Version 11.24 released (preliminary)
23/9/05	Version 11.24 released
10/9/07	Version 11.25 released
2/5/08 	Version 11.26 released
30/10/12	Version 11.27 released

ATTENTION
This specification supersedes, and has some minor differences from Version 11.26.  Access to DIS for the 2013/14 financial year will require an implementation based on Version 11.27 (access thru AnyConnect).  However, Version 11.26 (access thru old VPNClient) may still be available depending on client upgrades and fixes.

Changes in 11.27
The main change is the replacement of VPNClient with AnyConnect VPNClient for the establishment of the secure communications (VPN) tunnel.  Also the minimum application password length has increased to 12, other password edit checks remain the same.  Please also note that Internet VPN connectivity now uses DNS rather than an explicit IP address. 

Changes in 11.26
 Increased the maximum .ZIP file name length to 99 characters.

Changes in 11.25
a)	Two additional features have been added to VT00 test functions.  These are to assist software developers in testing password changes.   Ctrl P forces DIS to generate a D14 (password used before) when changing the password in AUTELS mode only.  Ctrl I forces DIS to generate a D15 error when changing the password.
b)	Maximum filename length has been increased to 120 characters.
c)	Updated to VPN Client version 4.8.02.0010 and added the VPN Client versions into Appendix E.  The Glossary now becomes Appendix F.
d)	Updated password encryption recommendation to reflect latest ACSI33 requirements.
e)	Added a lower case check for all alpha characters as an additional suggested edit check for Dial IP password and access code 2. 
f)	Some minor errors corrected, some rewording to improve clarity and some minor reformatting.

1	Preface
1.1	Overview of DIS
1.2	Using this specification
1.3	Other specifications and information
1.4	Where to get help
2	Communication Requirements
2.1	Overview
2.2	Hardware
2.3	Preliminary requirements
2.4	Software requirements
2.5	Trouble-shooting requirements
2.6	Security
2.7	CEG access
2.8	Connection failure categories
2.9	Secondary lodgment
2.10	Validation report reconciliation
3	Communication Setup Menus and Screens
3.1	Overview
3.2	Setup menus
4	Connecting to ATO
4.1	Overview
4.2	Connecting to the local modem
4.3	Connecting to the Network
4.4	Connecting to the VPN concentrator
4.5	Connecting to the Corporate External Gateway
4.6	Selecting the operating mode
4.7	Logging-in to DIS
4.8	System Bulletins
4.9	Logging-out
4.10	Unexpected disconnection
5	DIS Manual mode - VT100 emulation
6	The AUTELS Protocol
6.1	Overview
6.2	AUTELS operation
6.3	AUTELS message formats
6.4	AUTELS State Tables
7	Reports Sent to Users by DIS
7.1	Overview
7.2	Transmission Reports
7.3	ELS Validation Reports
8	Testing Facilities For Software Producers
8.1	Overview
8.2	Test systems
8.3	VT100 test functions
9	Appendices
9.1	Appendix A - Error messages
9.2	Appendix B - Example of connection to CEG
9.3	Appendix C - Single byte checksum
9.4	Appendix D - Firewall configuration
9.5	Appendix E - Glossary

1	Preface
1.1	Overview of DIS
The Australian Taxation Office (ATO) provides the Document Interchange System (DIS) facility for the receipt and transmission of data over IP networks.  The computer systems running DIS are collectively called the Corporate External Gateway (CEG).

The DIS system is considered generic in as much as it can receive many different form types and potentially any form type.  For example, individual returns and superannuation returns.

Typically Tax Agents use a PC and a broadband Internet connection or a modem to access and use DIS.  There are four DIS systems known as Brisbane (BR), Sydney (SY), Melbourne (ME) and Adelaide (AD).  Ordinarily Tax Agents use the system closest to their geographic locale.  In the event of a system outage, Tax Agents may transmit to any of the four systems, the only restriction being that they must pick up validation reports from the system on which the data was lodged.  Access control information is synchronized across the four DIS systems, so the same login credentials can be used on all four.

To connect to DIS, Tax Agents must login to the IP network, authenticate to the VPN concentrator, connect to a CEG system, and login to the DIS application.  Access to DIS is available over the Dial IP and the Internet networks.  Dial IP is a Private Network provided to the ATO by Telstra for ELS.  It has no connection to the Internet, and includes security features and auditing facilities not available on the Internet.  It can be considered to be a secure network to the ATO.

Information traveling to and from DIS may be either control or data, for example, change password or lodge forms.  Each exchange of information is built into a message and sent.  In all cases the format and content of all messages are specified by the AUTELS protocol, the specification of which is contained in this documentation.  Manual mode DIS is available, but cannot be used to transfer files (lodge forms or collect reports).  It is useful for trouble shooting and has some useful facilities for software developers testing their software.

After connecting to an ELS lodgment service, a Tax Agent must first collect any information being held for them by the ATO.  This may include: bulletin reports (to advise system outages or other ELS events); transmission reports (to advise which forms have been received); validation reports (to advise which forms have been accepted, which rejected and why); ATO client reports.  When these reports are generated is detailed below.

After collecting any information held by the ATO, the Tax Agent is free to lodge fresh forms.  Tax forms are first prepared into a special format called ELS tag format.  Usually on the Tax Agent's PC each form is stored as a separate file.  Any number of forms up to the current limit (1,000) may be combined into a single form group by using PKZIP compression.  The form group (compressed file) can then be transmitted to DIS as a single message.  The name selected by Tax Agent's software for a form group should not resemble an individual's name or other details.

On receipt of a form group message, DIS will assign the form group an ascending three digit transmission number.  The transmission number starts at 1, ascends to 999 and wraps back to zero.  Each DIS system independently generates its transmission numbers depending upon the number of lodgments on that system for each user.

The DIS system then prepares a transmission report which indicates which forms (files) were received within a form group (compressed file).  This is a confirmation of the receipt of particular data.  The Transmission report is sent back as a file to the Tax Agent contained within a compressed file.  The name of the transmission report file includes the transmission number and DIS system (e.g. TRANS_ME.001).  The content of the transmission report indicates the names of forms received in the transmission.

Once DIS has generated a transmission report, it then validates the form group that has been received and generates a validation report.  The validation report, which will also be sent as a single file contained within a compressed file, has the same transmission number for a particular form group (e.g. VALID_ME.001).

The validation report contains a list of those forms which have passed validation and consequently have been successfully lodged.  It also contains a list of forms, which have been rejected by validation, including reference to the edit checks that each form has failed.  These forms must be corrected and re-submitted.

Every form group (compressed file) transmission to DIS must contain a special form called TXID.  The TXID form (file) contains various details about the Tax Agent and the software package.

Compressed files are sent to and received from DIS within an AUTELS type 9 message.  When DIS prepares a compressed file to be sent to a user it will include all outstanding transmission and validation reports as well as potentially other files such as bulletins and client lists.

A test DIS system is provided for the exclusive use of software developers.

1.2	Using this specification 
Scope of these specifications
These specifications describe the Document Interchange System (DIS) which runs on the ATO's Corporate External Gateway (CEG) and the requirements for software communicating with DIS.
Who should read this specification
This document is written for persons developing software for users of the ATO's Document Interchange System.
These specifications may also be of interest to persons investigating problems with communications software and to persons using such software.
How to use this specification
Chapter 1 contains an overview and other useful information.
Chapter 2 specifies a number of preliminary requirements for software intending to communicate with DIS.  All developers should read this chapter.
Chapter 3 describes the communication setup menus and screens to be used by software for displaying communication parameters.
Chapter 4 describes establishing a connection with DIS and a typical communications session.
Chapter 5 describes DIS Manual mode, accessible by Telnet VT100 emulation.
Chapter 6 specifies the AUTELS protocols for conducting communications with dis.  All DIS software must comply with the interface specifications in this chapter. 
Chapter 7 describes the reports sent to users by DIS.  This chapter is intended to assist developers who wish to process the data in these reports.
Chapter 8 describes testing facilities available to software developers.  This chapter is informative and is not part of the formal specification.
Appendices provide additional details as required.

1.3	Other specifications and information
ATO documents
This specification deals solely with mechanisms used to transfer messages between a user's computer and the ATO's Corporate External Gateway (CEG). It assumes that the messages comply with the relevant ATO specifications.  Software developed for use by persons registered as ELS users must conform to the current year Electronic Lodgment Service (ELS) Specifications.
Software developers developing software for applications other than els must contact the relevant sections within the ATO to obtain the necessary specifications for the messages to be transmitted.
The ATO publishes for the benefit of Tax Agents the ELS Tax Agents Guide.
The ATO will prepare other specifications and directions from time to time and distribute them to registered software producers.
Information from other sources
Communications software requires compliance with the file compression specification as outlined in the PKZIP Application.  Note: This software can be downloaded from the Internet at the PKZIP web site - http://pkzip.com.
Information on the Cisco VPN concentrator 3000 series is available for download from http://cisco.com.  The most important document for software developers is VPN Client Administrator Guide, chapter 4 deals with 'Using the VPN Client Command-Line Interface'.
Information on the authentication protocols used by RADIUS servers, which applies to both Dial IP and Internet connectivity, can be found at http://rfc.sunsite.dk/rfc.  CHAP (Challenge Handshake Authentication Protocol) is RFC 1994 and RFC 2484.  MS CHAP (Microsoft PPP CHAP extension) is RFC 2759.
Additional information on Dial IP can be found at the Telstra web site http://telstra.com.au/dialip.
Information on Australian Government security standards can be obtained from the DSD web site http://www.dsd.gov.au.

1.4	Where to get help
If you have problems while using these specifications, or if you discover errors or inconsistencies, please contact the ato as indicated below.

ELS software registration and testing
	Help Desk		1800 11 24 66
	els-takeon@ato.gov.au

Technical requirements
	Raja Suppiah	02 6216 8236
	Raja.suppiah@ato.gov.au

Technical problems
	Dennis Pinner 	02 6216 4697
	dennis.pinner@ato.gov.au

ESD Help Desk (for client difficulties)
	13 72 86 fast key code 3.5
2	Communication Requirements
2.1	Overview
This chapter describes the basic requirements that must be met by computer hardware and software communicating with dis.
Chapter 3 - Communications Setup Menus and Screens specifies how software using AUTELS should display and/or change parameter values.

2.2	Hardware
The communications hardware needed to communicate with ELS will vary depending upon the end-user’s network access method, generally one of Broadband, ISDN, ADSL, wireless or asynchronous modem.  Dial IP access is by ISDN or dial-up. The hardware requirements for asynchronous modems only are specified here. 
Asynchronous communications port
Character mode connection to the IP network requires a computer with an asynchronous communications port.  Character framing for the asynchronous port should be set to:
8 data bits, no parity, 1 stop bit.
Modem
Modems must be capable of full-duplex, asynchronous operation.  For example, 33.3K bps, 56K bps.

2.3	Preliminary requirements
Software developers and CEG users must be registered users of DIS and must have access to either Telstra Dial IP or the Internet. All custom communications software must be tested, certified and registered with the ATO.
Connecting to the IP Network
Users must be registered with the network provider to obtain a network User Identification and password.  Each registered user will have a unique User ID and password to authenticate them to the network.  This User ID and password pair is different to that used to authenticate to either the VPN concentrator or DIS.  You must login to the network before you can authenticate to the VPN concentrator and make a connection to DIS.
ELS registration
Users must be registered with the ATO to obtain their ELS approval number.  The ELS approval number is preceded by a user type character and forms the user's ELS User Identity.  Initially the user's ELS password is set to a randomised string.  The user must change this password when they make their first login to DIS.  It is important for users to understand that they should do this as soon as possible, even if they are not ready to lodge tax forms yet, they should check connectivity and change their initial ELS password.
Software tests
To obtain dis registration, software developers must be registered with the ATO as participating developers.  In addition, software must be tested in accordance with procedures specified by the ATO (see Test Procedures for ELS Tax Agent Communication Software.)
Tests of communications software require successful transmission of test data from a site nominated by the software supplier (for example, the software supplier's office or the office of a nominated agent) to a dis test facility. See Chapter 7 — Testing Facilities for Software Developers.

2.4	Software requirements
An IP stack capable of supporting IP version 4 and optionally version 6.  At this time both the VPN tunnel and connection through the tunnel require IPv4.  We are looking to provide IPv6 capability for the tunnel but the connection through to the application is expected to remain IPv4.  Developers are free to use any mechanism to drive their IP stack.  
A file compression program compatible with the zip utility is required.  Files sent uncompressed will not be accepted by dis.

Systems supported by Cisco AnyConnect product
Below is a list of some of the operating systems which are supported by the Cisco AnyConnect product.  There are other operating systems which are also supported but this list contains those operating systems for which the ATO will provide support for in terms of product problem resolution.	

WINDOWS
	Windows 7 x86 (32−bit) and x64 (64−bit)
	Windows Vista SP2 x86 (32−bit) and x64 (64−bit)
	Windows XP SP3 x86 (32−bit) and x64 (64-bit)
Note: The Network Access Manager portion of AnyConnect does not support Windows XP SP3 x64 (64-bit).
	System Requirements
	Pentium class processor or greater.
	100 MB hard disk space.
	Microsoft Installer, version 3.1

	MAC
	Mac OS 10.5 (32-bit, Intel CPU only)
	Mac OS 10.6.x (32-bit and 64-bit)
	Mac OS X 10.7 (Lion 32-bit and 64-bit)
	System Requirements
	50MB of hard disk space

	LINUX
	Red Hat Enterprise Linux 5 Desktop (32-bit; 64-bit available but not supported by Cisco)
	System Requirements
	x86 instruction set.
 	32-bit or biarch 64-bit processor.
 	32 MB RAM.
 	20 MB hard disk space.
 	Superuser privileges are required for installation.
	libstdc++ users must have libstdc++.so.6(GLIBCXX_3.4) or higher, but below version 4.
 	Java 5 (1.5) or later. Iced Tea is the default Java package on Fedora 8. The only version that works
	for web installation is Sun Java. You must install Sun Java and configure your browser to use that
	instead of the default package.
 	zlib.
 	gtk 2.0.0,
	gdk 2.0.0,
	libpango 1.0.
 	iptables 1.2.7a or later.
 	tun module supplied with kernel 2.4.21 or 2.6.

Communication modes
The only mode of communication that can be used to lodge forms through DIS version 11.27 is AUTELS.  Manual mode can be accessed by a telnet connection to the DIS port (7586 - not the Telnet port) but there are no menu options to send or receive files.
Manual mode is primarily for software developer testing, it includes a number of options designed to make it easier to test client software (see Section 8.3 VT100 test functions). 
Communications log file
All software packages must keep a record of the last transmission. This record is called the Communications log file, or just the log file.
Only a single log file needs to be kept — the one log file can be overwritten during the next communications session.
Various sections of this specification indicate messages, actions, responses, etc that need to be logged. The following message types, actions and responses are typical of what should be recorded:
Current procedure messages 
These indicate the procedures performed by the agent’s system; for example,  Connecting to network is the current procedure message indicating that the user’s system is attempting to connect to the network.
Actions
Each procedure consists of one or more actions taken by the user’s system. An example of an action is one of the AT commands used to control the modem.
Responses
Most actions require a response. The response indicates whether the action was successful or not.
Error messages
When a response indicates an error, an error message must be logged.
This specification indicates the minimum requirement for the communications log file.
Communications setup menus
AUTELS software must provide a series of menus or commands that allow the agent to display a number of communications parameters.
The communications setup menus are described in Chapter 3.
These menus should provide the user with a number of sub-menus and functions.
Transferring messages
All forms sent to DIS must be compressed using PKZIP file compression or its equivalent.  The filename of the compressed file must have a suffix of '.ZIP', the rest of the file name is arbitrary except for the naming restrictions below.
Each form needs to be included for compression as an individual file.  The ATO will accept only one form per file, but there may be multiple forms (files) within a compressed file.
It is not advisable to attempt to transmit extremely large compressed files because there is then a relatively high probability the transmission will be interrupted and the entire file will have to be retransmitted.  This may cause difficulties to users, particularly those using dial up, trying to transmit a large file repeatedly without success.
Recursive compression is not allowed - i.e. directories and/or .ZIP files must not be included in the compressed file.  If directories are present in the compressed file, it will be rejected and there will be an error message in the Transmission Report.  Files with the extension .ZIP in the original (uncompressed) filename will also be rejected and deleted by DIS.
Duplicate file names within a compressed file are not sensible and should not be sent.  A duplicate file name will cause one file to be overwritten, and there may or may not be a warning message in the Transmission Report.
When the user's software wishes to send a compressed file containing forms, it uses the Type 9 AUTELS message for embedded data.
After sending forms, users must first receive any reports waiting to be returned by DIS.  Users are then able to send more forms.
Naming files sent to DIS
All compressed files sent to DIS must have the suffix .ZIP in the filename.  If DIS receives a file with a filename without the .ZIP suffix, the file will be rejected and deleted by DIS, and there will be an error message in the Transmission Report.  All files sent by DIS will have a filename suffix of .ZIP. 
The file name of the .ZIP file has a maximum length of 99 characters.  This is limited by the 2 character space reserved for the file name length in the Type 9 AUTELS string.  The file names of the messages contained in the .ZIP must be a unique identifier made up of no more than 120 characters.  The file name may be any numeric or alphabetic character, the full stop or the underscore character. The filename does not have to begin with an alphabetic character and must not begin with a full stop.
Only the following characters may be used in a valid file name:
a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9 _  .
Invalid file names may cause the file name to be changed or the file deleted.
Files received with a file name of the form  TRANS_aa.nnn, VALID_aa.nnn, BULL_aa.nnn or  RPTaannn  will be deleted. The aa and nnn in the file name format represent alpha and numeric characters respectively.  This restriction is imposed because these forms of name are reserved for files sent by DIS to users registered as ELS users.
The following are examples of valid names for files to be sent to dis:
A12345	ABCDEFGH.123	
A_TEST_CASE.TRUST	A.TEST.CASE.IND	
Naming of files sent to users by DIS
All compressed files sent to the user's system have the file name suffix of .ZIP.  ZIPPED.ZIP is a file created by DIS which contains either, or both of, Transmission Report(s) and Validation Report(s).  Other files with a suffix of .ZIP contain messages from other ATO systems.
Some messages sent to users by DIS have a site identifier in the file name. This is a two-character identifier as follows
AD	Adelaide CEG 
ME	Melbourne CEG 
SY	Sydney CEG
BR	Brisbane CEG 
NO	National Office CEG 
G2	Test  CEG 2 (simulates production lodgment service)
G1	Test CEG 1 (simulates production lodgment service)

All DIS users receive a Transmission Report after sending a transmission.  The filename is TRANS.ss.nnn where ss is the site identifier and nnn is the transmission number. The transmission numbers are consecutive for each CEG and each registered user.    
The file names of System Bulletins are  BULL_ss.nnn,
where ss  is the site identifier and  nnn  is a sequence number. The sequence numbers will not necessarily be consecutive.
Other messages will also be sent to users by DIS.  The file names of these messages are dependent on the application, and in some cases are not specified.
ELS registered users will also receive a Validation Report for every valid transmission.  The file name is VALID_ss.nnn, where ss is the site identifier and nnn is a sequence number.  They may also receive messages with file names RPTttnnn, where tt represents the report type (e.g. CL for client lists, DL for due lodgment), and nnn is the sequence number of the report.

2.5	Trouble-shooting requirements
Technical support of the AnyConnect VPN Client requires the ability to test connectivity manually.  Consequently it must be possible, either using a desktop icon or from the program menu, to run the AnyConnect VPN Client manually using the GUI interface. 
It is very useful to be able to run both a ping and a telnet session manually also.  The ping can be used to check connectivity to a VPN concentrator, but you cannot ping the DIS application.  A telnet connection to one of the CEG systems on port 7586 can be used to check connectivity through to the DIS application.
				
2.6	Security
User authentication is a tri-level process, firstly identifying to the network (RADIUS server logon), then the VPN concentrator (ATO access codes), and finally the DIS application (ELS User ID and password).  The VPN client provides encryption and restricted network access.  Encryption prevents data being viewed whilst in transit.  Restricted network access prevents unauthorised access between the network and PC through the IPSec tunnel.
If the user is gaining access to the ATO from Dial IP then their Network User ID, ATO access code1, and ELS User ID will all be similar.  If they are gaining access to the ATO from the Internet then just their ATO access code1 and ELS User ID will be similar.  In these cases the first character varies but the rest of the User ID is the user's ELS approval number.  For Dial IP users the first character of their Network User ID is 'D'.  For both Dial IP and Internet access, the first character of their ATO access code1 is 'V', and the first character of their ELS User ID depends upon their ELS classification (usually ‘A’).  If the user is gaining access to the ATO from the Internet then their Network User ID will be assigned to them by their ISP.
It is a requirement that passwords and ATO access code2 are not stored on disk in the clear, an encryption technique must be used.
Software can display Network User ID, ATO access code1, and ELS User ID.  Further, on the rare occasion that a user manually changes their Network password, ATO access code2, or ELS password, its content should not be displayed, but obscured, unless the user is authorised to display passwords.  To ensure that the password is what the user believes they have typed they must enter it again and a check run to ensure they match.
The user should be prohibited from setting their Network password or ELS password to the same value as ATO access code2.  This is only an issue if the user enters these passwords.  If the passwords are separately randomly generated then the chance of a clash is remote.
Network User ID and password
These must conform to the requirements of the network provider.  If connecting to either Dial IP or the Internet the CHAP (Challenge Handshake Authentication Protocol) protocol can be used to authenticate the user.  CHAP is RFC 1994 and RFC 2484.  MS CHAP (Microsoft PPP CHAP extension) is RFC 2759.  See 1.3 'Other documents and specifications'.
ATO access codes
The first of these codes is 'V' followed by the Tax Agent's ELS approval number.  The second will be supplied by the ATO.  Users, or their software, are not required to change their ATO access codes so it is especially important that this information not be disclosed.  When stored on disk passwords must be encrypted.  The encryption algorithm and keys are not specified by the ATO but selected by the software developer.  “Strong” encryption (triple DES or AES, as specified in ACSI33, is recommended) is required.  ACSI33 can be obtained from the DSD web site http://www.dsd.gov.au.
Suggested edit checks for ELS authentication information.
The Dial IP Network User ID starts with a ‘D’ followed by 5 numeric digits.
ATO access code 1 starts with a ‘V’, followed by 5 numeric digits.
When the user changes their ELS User ID this only invalidates the application password if the user changes it to a value other than what was previously present.
When the user has finished their changes to the authentication information that the application checks that the last 5 digits of: the Dial IP Network User ID, ATO access code 1, and ELS User ID are all the same.
Indeed it is possible to deduce Dial IP Network User ID and ATO access code from the user’s ELS User ID.  These could be presented without the user having to enter them.
The Dial IP Network password is 8 characters long, all alpha characters are lower case.
The ATO access code 2 is 10 characters long (no zeros or ones), all alpha characters are lower case.
Information is presented using the same glossary of terms as in the DIS specification.

2.7	CEG access
To access any CEG via Telstra Dial IP or the Internet, a VPN tunnel must be established to the ATO.  The profile name varies depending upon whether using the Dial IP or Internet networks, whether UDP or TCP protocols are required, and which CEG systems Sydney/Brisbane, Adelaide/Melbourne, or the test systems, access is required to.  If the wrong VPN client profile file is used, the call will be automatically re-directed to a bulletin service.  See section 4 'Connecting to ATO' for more detail.
The production profile files are provided to software developers by the ATO for inclusion with their product.  It is suggested that software packages support Transparent Tunneling over both UDP and TCP, with TCP the default, and provide some means for the user to change the default.
CEG addresses
Currently there are four ATO CEGs, and each has a specific IP address.  The IP address can be used directly.  It is not necessary to obtain an address from a symbolic name using DNS.
When users are first registered on the CEG, they are assigned the use of a primary CEG.  This is the CEG where users are first registered and will be the CEG where all or most of that user's messages are transmitted. A CEG user may also send to a secondary CEG  if the primary CEG is out of service or is fully loaded.
Software producers may also code the IP addresses into their packages according to the connection rules set out in Section 2.9 —Secondary lodgment.  Software must be able to store the addresses of all four CEGs.
The DIS application is available on IP port 7586.
ELS User ID
An ELS User ID is stored on all ATO CEGs. Users must send a correct ID to DIS before access to a CEG is allowed.
User IDs are six characters long, the last 5 digits being the user’s ELS approval number.
A user cannot change the ID stored by DIS; it is issued and controlled by the ATO.
If user IDs are stored on the user's computer, it must be possible to change them. In fact, any default User ID must be changed to match the ID assigned by the ATO.
ELS password
As with User IDs,  ELS passwords are stored on all ATO CEGs.
An ELS password must be at least 12 characters long but not more than 16 characters, must contain at least one alpha, at least one numeric character,  cannot have more than 3 characters of the same value, and no more than 2 characters of the same value in the same position.  Lower case characters are converted to upper  case, so the password is not case sensitive.  Only printable characters are acceptable in ELS passwords (0x20 - 0x7e inclusive).
Attention:	Once used by a particular user, an ELS password cannot be used ever again.	

DIS users (or their software) must change passwords every 30 days. If the password is changed on the user's computer, it must also be changed in DIS.  A new password can re-use no more than two characters, in the same position, from the current password.
The method for changing a dis password is specified in Section 6.4 — AUTELS  State tables.  

2.8	Connection failure categories
AUTELS software should be able to identify the following categories of problems:
Dial UP only:
Category 1 is a failure to obtain connectivity to the local modem.  This is a local telephone, modem, cabling or computer system issue.
Category 2 is a failure to obtain modem synchronization.
Category 3 is a failure to authenticate to the network.
Dial UP and permanent connections:
Category 4 is a failure to correctly initialize the AnyConnect VPN client.
Category 5 is a successful initialization of the AnyConnect VPN client but failure to connect to a lodgment service. 
Category 6 is identified by the Site name being NO in the AUTELS Type 0 message.  If the user is connected to a NO system, AUTELS software can receive the System Bulletin as a compressed file and log out.  It is not possible to send any forms to a NO system.  The user may then send to a secondary lodgment service (any of the other production CEG systems).  
Category 7 is a failure to authenticate to the DIS application.
All of the above categories of failure with the exception of Categories 1,2,3 can potentially be circumnavigated.  For problems in categories 4, 5 and 6 it is necessary to disconnect from the CEG (category 6 only) and terminate the VPN tunnel before attempting connection to another CEG.  It is not necessary to logout of the network or drop the modem connection.  

2.9	Secondary lodgment
Each ELS user has a primary CEG.  If a primary CEG is unavailable (for a specific user or in general) a user can use any of three secondary CEGs for lodgment.  Any ELS user can send forms to their primary or any secondary CEG.  
You may elect to cater for just one, two, or three secondary lodgment services.
A user's primary CEG is determined from the user's ELS approval number (characters 2-6 in the ELS User ID) as follows:

ELS Approval numbers		Primary CEG system	Lodgment service ID (Site)	DIS service IP address		Required Cisco AnyConnect VPN profile	
						Internet	Dial IP	
10000 - 29999		Adelaide	AD	203.202.43.2		IMelAde	MelAde	
30000 - 49999		Brisbane	BR	203.202.43.3		ISydBri	SydBri	
50000 - 69999		Melbourne	ME	203.202.43.1		IMelAde	MelAde	
70000 - 89999		Sydney	SY	203.202.43.4		ISydBri	SydBri	
90000 - 99999		Test	G2	203.202.43.5		Test	N/A	
90000 - 99999		Test	G1	203.202.43.5		Test	N/A	

Users normally should lodge using their primary CEG, they should only use a secondary if their primary is unavailable.  Some messages from the ATO (e.g. Client Lists) are only sent to a user's primary CEG.  If the user never connects to their primary CEG they may fail to collect this additional information sent by the ATO.   
When a user's primary lodgment CEG service (AD,BR,ME,SY) is unavailable, or inaccessible, the ATO may connect them to a bulletin service (NO) and provide a bulletin informing them of the situation.  You cannot lodge returns on a bulletin service.  The switch to a bulletin service is automatic and may occur at any time a connection to a lodgment service is attempted.  Do not use the connected IP address to determine whether you are connected to a lodgment or bulletin service, use the supplied system ID on the opening banner (see 6.3 - AUTELS message formats, Type 0, for more information).  If when you target a lodgment service you are switched to a bulletin service you may elect to lodge to a secondary CEG.

Users should connect to secondary CEGs in the order listed below.  Their current ELS User ID, ELS password and ATO access codes are synchronized for access to any CEG so there is no difference in authentication whichever CEG lodgment service is used (bulletin services do not check the validity of authentication details).  When a switch to a secondary lodgment service occurs the user must be informed that this is happening, including which secondary is being used.  A display to how much time has elapsed, and how many secondary connections have occurred, since the last connection to the user's primary lodgment system, is recommended.
Primary	Connect to secondary CEGs in this order
Sydney	Adelaide	Brisbane	Melbourne

Melbourne	Brisbane	Adelaide	Sydney

Brisbane	Melbourne	Sydney	Adelaide

Adelaide	Sydney	Melbourne	Brisbane

A file can be deemed to be received by the ATO when an acknowledgment is received for the Type 9 AUTELS string containing it.  Record which lodgment service the data has been deposited on so that if you do not receive a transmission and/or validation report you know where to return to collect them. 
You will not know whether the forms within the file sent have been accepted as valid until you receive the corresponding transmission and validation reports.  If a user is unable, within a few hours, to obtain a validation report for a particular lodgment they may elect to lodge the data using a different lodgment service.  Because the receipt of a particular form is replicated across all lodgment systems the new lodgment may fail as a duplicate.  If the new lodgment fails as a duplicate then the forms have been received.  In this case the initial validation report is unavailable until the lodgment service holding it becomes available again.
See section 8.2 - Test systems, for more information.

2.10	Validation report reconciliation
It is the responsibility of ELS software to reconcile validation reports with lodged forms.  Both transmission and validation reports have file names which indicate which lodgment system they are from.
There is no guarantee that a validation report, or a transmission report, will be received within the same session as a lodgment, although usually they will be.  There may be a backlog of lodgments requiring validation or a circuit may be unexpectedly disconnected.  Within a compressed file, whatever transpires, there should never be more than one transmission report (referring to your latest transmission), however, more than one validation report may be received.  Further, more than one compressed file may be received within a single session even if only one lodgment is made.  This is because some reports arrive asynchronously (to the clients session dialogue) in users outbound mailboxes. 
If a validation report is not received within the same session as the forms are lodged a subsequent connection to the lodgment service where the forms were deposited is necessary to collect the validation report (this applies whether it is the user's primary or a secondary lodgment system).  Software must connect to a secondary CEG to receive any Transmission or Validation Reports for forms lodged on the secondary that were not received during the same connection. 
Software must provide information so that a user can determine, after lodgment, which lodgment service has been used for a particular form.
3	Communication Setup Menus and Screens
3.1	Overview
All software specifically designed to access DIS services must provide a series of menus or commands that allow the user to display — and change if appropriate — a number of communications parameters.  These menus or commands have been designed such that they will be standardized across all software packages.  This is of great assistance to the ATO help desk personnel when resolving communications problems.  
The top-level menu (or command) must be called Communications Setup. This menu/command will lead to other sub-menus or sub-commands as follows:

Communications
Setup	
			
Connection Options	Security
Setup	Diagnostics	

The order of presentation of the sub-commands is not important, but the above names must be used. The means for presenting these commands is also optional — there is no restriction on interface design.
Each sub-command presents a screen that displays the communications parameters (and allows them to be changed if appropriate), and provides diagnostic functions as listed in the following sections.
A print screen command associated with the communications setup functions must be available with each screen.
The names of the communications parameters must be listed as shown in the following sections. The listing order must be preserved also.
It is indicated below and elsewhere in this specification that passwords must not be displayed.  This is the behavior if the current user is not privileged.  Passwords can be displayed both on entry and for later inspection if the user has administration privileges within the software package.  This means, to display passwords, some concept of normal user versus administration user must exist, as well as some security arrangement for granting administration user privilege.
 
3.2	Setup menus

A user must be informed when a secondary lodgment occurs, and must also be able, subsequent to the event, to determine which system a lodgment occurred on. 
Connection Options
Elements of the connection options menu are:
Dial IP
Internet
The 'Dial IP' and 'Internet' options are mutually exclusive.  Although the 'Dial IP' and 'Internet' options could be combined, they should not be.

If the user attempts to change any default setting they should be warned that to proceed may disable an agent’s ability to lodge.
Security setup
The security setup menu is provided to allow users to display User IDs and addresses and change, if appropriate, any of the following security parameters.  Password details being entered should not be displayed and passwords must be stored on the disk using an encryption technique.  Users should be prompted to confirm any change to the security parameters.
The VPN concentrator address is stored in the VPN client profile file.  The ATO will provide software developers pre-configured VPN client profile files.  There will be eight production files: to connect to the VPN concentrator for private IP network access to Sydney/Brisbane using TCP or UDP; to connect to the VPN concentrator for private IP network access to Melbourne/Adelaide using TCP or UDP; to connect to the VPN concentrator for Internet access to Sydney/Brisbane using TCP or UDP; to connect to the VPN concentrator for Internet access to Melbourne/Adelaide using TCP or UDP.  The VPN concentrator address is not part of the security parameters, but is in effect changed by selecting different VPN client profile files.

Elements of the security setup menu are:
The Network access number (optional, not necessary if o/s dialer used)
The Network User ID (optional, not necessary if o/s dialer used)
The Network password (optional, not necessary if o/s dialer used)
ATO Access code1
ATO Access code2
Lodgment service selection order
ELS User ID
ELS password
The Network access number — display and change the current copy of the phone number used to access the Network provider’s modem bank.  For Dial IP users this is 0198 303 290.  For Internet users this number is provided by the ISP.
The Network User ID — display and change the current copy of the Network User ID stored on the user's system, and display the date and time it was last changed.
This copy of the Network User ID should be changed only after the user is assigned a User ID by the network provider after registering to use the IP network, and should not otherwise be changed (unless the network provider changes the User ID).
If the network is Dial IP then the Network User ID will be 'D' followed by the user's ELS approval number.  If the network is the Internet then the Network User ID is allocated by the ISP.
The Network password — change the current copy of the Network password stored on the user’s system, and display the date and time it was changed. The password must not be displayed unless the current user has such privilege.
The user’s copy of the Network password should be changed only to match a change made by the network provider or in accordance with the network provider’s password policy.
If the network is Dial IP then the password is allocated by the ATO.  If the network is the Internet then the Network password and maintenance policy is determined by the ISP.
ATO Access code1 — display and change the current value of the user's first ATO access code.  This access code is the Tax Agents ELS approval number, once correctly configured it should not be necessary to change it.
In all cases the ATO access code1 is 'V' followed by the user's ELS approval number.
ATO Access code2 — change the current value of the user's second ATO access code.  This access code, which in effect is a strong password, will be provided to each user by the ATO.  It must not be displayed unless the current user has such privilege.
The same two ATO access code values are required irrespective of which CEG system the user wishes to connect to.
Lodgment service selection order — display and change the order lodgment services are attempted for lodgment (refer to Section 2.9 —Secondary lodgment)
It is no longer required that users be able to change the IP addresses assigned to each lodgment system.  The addresses can be displayed for information purposes.
Suggested presentation for an Adelaide primary user (10000 - 29999):

Lodgment order for ELS approval no 12345	
Lodgment service name	IP address (information only)	Use lodgment services in this order 	
Adelaide	203.202.43.2	1	
Sydney	203.202.43.4	2	
Melbourne	203.202.43.1	3	
Brisbane	203.202.43.3	4	

Suggested presentation for a Brisbane primary user (30000 - 49999):

Lodgment order for ELS approval no 32345	
Lodgment service name	IP address (information only)	Use lodgment services in this order 	
Brisbane	203.202.43.3	1	
Melbourne	203.202.43.1	2	
Sydney	203.202.43.4	3	
Adelaide	203.202.43.2	4	

Suggested presentation for a Melbourne primary user (50000 - 69999):

Lodgment order for ELS approval no 52345	
Lodgment service name	IP address (information only)	Use lodgment services in this order 	
Melbourne	203.202.43.1	1	
Brisbane	203.202.43.3	2	
Adelaide	203.202.43.2	3	
Sydney	203.202.43.4	4	

Suggested presentation for a Sydney primary user (70000 - 89999):

Lodgment order for ELS approval no 72345	
Lodgment service name	IP address (information only)	Use lodgment services in this order 	
Sydney	203.202.43.4	1	
Adelaide	203.202.43.2	2	
Brisbane	203.202.43.3	3	
Melbourne	203.202.43.1	4	

ELS User ID — display and change the current copy of the ELS User ID stored on the user's system, and display the date and time it was changed
This copy of the ELS User ID should be changed only after the user is assigned an ELS User ID by the ATO, and should not otherwise be changed (unless the ATO changes the User ID).
The ELS User ID is a single character identifying the class of ELS user (usually 'A') followed by the user's ELS approval number.
ELS password — change the current copy of the ELS password stored on the user’s system, and display the date and time it was changed. The password must not be displayed unless the current user has such privilege.
The user should always be informed when the password is changed, it is up to the software developer how a new password is entered or generated.  The rules for acceptable passwords are specified in 2.7 - CEG access.
Diagnostics
The purpose of the diagnostics menu is to provide diagnostic tools for identifying communications problems.  The last session is always logged.
Note: Where passwords are stored in a log file each character should be replaced with a # simply indicating that a character position was occupied.  The Network password, ATO access code2, and ELS password should never be written to the log file.  However, it is accepted that some system trace facilities if turned on will capture all traffic.
Elements of the diagnostics menu are:
View last communications log
Print last communications log
View last comms log — display the last communications log file on screen, this should include a trace of connecting to the modem, Network, VPN concentrator, and DIS application.
This log file has historically proven very helpful in diagnosing problems experienced by clients.
Print last comms log — print the last communications log file
Refer to Communications log file in Section 2.4 — Software requirements.
4	Connecting to ATO

4.1	Overview
This chapter describes a typical communications session with DIS.
The software package must provide the necessary screens and menus and communicate by means of the AUTELS procedures and protocols described in Chapter 6 — The AUTELS protocol.
If you introduce static routes onto a client system for VPN concentrator addresses it is suggested you use host routing.  That is a subnet mask of 255.255.255.255 which effectively identifies the concentrator as being on a network consisting of one address only.
A communications session proceeds through the following steps:
If required - Connect to the local (user’s ) modem
If required - Connect to the Network
Establish VPN tunnel.
Connect to the CEG 
Select operating mode: AUTELS
Log-in to DIS
Exchange files
Log out (exit DIS)
Tear down VPN tunnel.
Hang-up modem.

While logged into DIS, a user can access the following services:
Receive the System Bulletin file
Receive new messages with embedded data (e.g. transmission report)
Send messages with embedded data
Display transmission status
Receive other messages (e.g. old transmission reports)
Change ELS password
Chapter 7 —Reports sent to users by DIS describes files sent by DIS to users.
Conventions used in this Chapter
In the following sections, a number of conventions have been used to assist the reader:
•	Messages and prompts displayed by DIS are indented and shown in a special typeface — like this
•	A bold face type is used for required input by the user’s system — like this
•	Variable responses are enclosed in brackets like this:  [ ]
•	<CR> means to press the Return key (and send the carriage return character)

4.2	Connecting to the local modem
Software may use system provided facilities for the modem connection.  If developers wish to write this aspect of the system it should operate in the following manner.
Software must send industry standard (AT) commands to the modem connected to the user’s computer (the local modem).
Detailed information on AT commands is available from modem suppliers.
When beginning a communications session, must display and log the following message:  Connecting to Modem.
All actions and responses must be logged.
When an AT command is sent, the user’s system must check the response.

4.3	Connecting to the Network
Software may use system provided facilities for the Network connection and login.  If developers wish to write this aspect of the system it should operate in the following manner.
The user’s system instructs the modem to call the appropriate telephone number to connect to the Network.  For Dial IP users this is 0198 303 290.  For Internet users this number is provided by the ISP.  A modem at the network provider answers the call and attempts to synchronize the two modems.
Once the modems are synchronized, any data sent to the user’s modem is received by the Network modem.
At the beginning of this procedure, the software must display and log:  Connecting to the Network.

If during this procedure there is no response or an invalid response then the user's software must display and log an appropriate modem error message. 

4.4	Connecting to the VPN concentrator
4.4.1	Cisco AnyConnect API

The Cisco API is the recommended solution for establishing and removing the VPN tunnel.  

Three CDs are provided to assist you in developing an appropriate solution for the AnyConnect VPNClient.  Essentially one CD contains the AnyConnect product for end user installation, one contains API development information including code examples and documentation, and the final one contains API kits for MAC and Linux plus some release notes.

The rest of this section relates to Windows solution development.  For all operating systems more complete information is provided on the CDs.

On the API CD image, there is a directory named: 
…\version 3.0\anyconnect-win-vpnapi-3.0.08057 

This is the main directory that contains the sample code and the libraries.  Within this, there is a directory named: doc_COM that contains a bare-bones description of the APIs that can be called via COM.  These are implemented in the DLL (vpnapi.dll) thus AnyConnect must be installed on any computer that you want to test on.

CppComSample

An example program which connect and disconnect a VPN tunnel from your application in C++ is located here:

…\version 3.0\anyconnect-win-vpnapi-3.0.08057\examples\CppComSample

Before you can build the sample program you need to copy the vpnapi.dll file somewhere in the build machine (such as the same directory as the CppComSample.sln file).  This is required so that the type library can be extracted from the dll to help the build process.  There are some important details about the sample code in the file: ReadMe_First.htm

Then you can import this program: CppComSample.sln into Visual Studio and build it.

Within this sample application, CppComSampleDlg.cpp is the file that contains most of the logic of interest in terms of interacting with the APIs.

This program presents a dialogue window to the user and allow them to select various options around connect and disconnect.  It’s probably sensible to build this program without modification and test it so you can ensure everything that is required is in place and all is functioning correctly.

The program as it stands is unlikely to be what you need as users are required to input various parameters which your program would probably supply.  However, it is not difficult to modify passing in parameters as required.

If you are unable to progress because you cannot get the sample program to function or you believe the supplied software is not working as expected then please let us know and we will endeavor to assist you.  Under no circumstances will we develop a solution for you, but we will ensure you receive support from Cisco for the proper functioning of the supplied API, and we will provide limited assistance to you to support development of your solution.

We are not encouraging the use of the CLI.  Our suggestion is that if you wish to invoke connect and disconnect from the command line that you write programs based on the API example to do this for you.  However, if you do this please be mindful of security consideration especially in how you pass information to your programs (using command line parameters for password must be avoided).

4.4.2	Connection profile files 

An AnyConnect client profile is an XML file with client parameters represented as XML tags which define how to establish VPN sessions and enable client features.  They are not updated in the same manner as the old VPNClient profiles, for example with a user credentials when a connection is established.  

The location of the profile file for Windows XP is: 

C:\Documents and Settings\All Users\Application Data\Cisco\Cisco AnyConnect VPN Client\Profile

For other versions of Windows the profile file is located at:

C:\Program Data\Cisco\Cisco AnyConnect VPN Client\Profile

The ATO will provide software developers with ten VPN client profile files:

Profile name	Establishes VPN tunnel to access	
ELS-SydBri-TCP.xml	Sydney or Brisbane using Telstra Dial IP with TCP (SSL).	
ELS-MelAde-TCP.xml	Melbourne or Adelaide using Telstra Dial IP with TCP (SSL).	
ELS-SydBri-UDP.xml	Sydney or Brisbane using Telstra Dial IP with UDP (IPSec).	
ELS-MelAde-UDP.xml	Melbourne or Adelaide using Telstra Dial IP with UDP (IPSec).	
ELS-ISydBri-TCP.xml	Sydney or Brisbane using the Internet with TCP (SSL).	
ELS-IMelAde-TCP.xml	Melbourne or Adelaide using the Internet with TCP (SSL).	
ELS-ISydBri-UDP.xml	Sydney or Brisbane using the Internet with UDP (IPSec).	
ELS-IMelAde-UDP.xml	Melbourne or Adelaide using the Internet with UDP (IPSec).	
ELS-Test-TCP.xml	Test systems (G1, G2 and NO) using the Internet with TCP (SSL).	
ELS-Test-UDP.xml	Test systems (G1, G2 and NO) using the Internet with UDP (IPSec).	

These profile files, in conjunction with the user's ATO access codes have all the information necessary to establish a secure VPN tunnel to the ATO. 
We recommend the use of TCP as default.
Please note that it is not possible to connect to the Melbourne or Adelaide Gateways using profile files SydBri-xxx or ISydBri-xxx, and it is also not possible to connect to the Sydney or Brisbane Gateways using profile files MelAde-xxx or IMelAde-xxx.  Any attempt to do this will be automatically re-directed to an NO system.  Software configuration edits should prevent users from configuring their system in such a way that this can occur.
Split tunneling is turned on for both Dial IP and Internet connections.  Thus end user systems which have established a VPN connection to the ATO are able to communicate with other devices on their local LAN.  It is also possible to communicate directly with devices on remote LANs as long as there is no address conflict and appropriate routing is configured.   However, the ATO does strongly recommend that appropriate firewall technology be used for any connection via the Internet.

4.4.3	Packaging AnyConnect VPNClient and profile files

Each software developer is asked to include the supplied AnyConnect product and necessary profile files to their clients for use with your product.  
Clients will need to install the AnyConnect VPNClient on their system in order for your AnyConnect API solution to function.  Clients will not ordinarily use the Cisco supplied AnyConnect VPNClient UI other than for trouble shooting.  It should be noted that the Cisco GUI and API enabled programs are mutually exclusive, you can only use one at a time.  So if a client starts the Cisco GUI it must be completely shut down for your program which uses the API to then function, conversely the API must be completely shutdown for the GUI to work.
It is recommended that you test your client install sequence to ensure that all aspects of the solution install correctly and function without conflict.

4.5	Connecting to the Corporate External Gateway
There are two situations in which a connection can be made to a CEG system - VPN over Dial IP, and VPN over the Internet.  In both cases the IP address that is used to connect to the CEG system is the same.
Once successfully authenticated to the VPN concentrator, you must connect to a CEG system and login to the DIS application using the ELS User ID and password.  Note: you must have used the correct VPN profile to establish a secure tunnel to gain access to a CEG.
DIS will allow five (5) attempts to login before locking an account against access even with the correct password.
All actions and responses must be logged.
If the connection is successful the DIS welcome screen is sent to the user.
If during this procedure, there is an error, then the user’s system must log and display it.
See 2.7 - CEG access, and 2.9 - Secondary lodgment, for IP port number and addresses.  See 3.2 - Setup menus, for the Dial IP phone number, and 4.4 -Connecting to the VPN concentrator, for details on VPN client profile files.

4.6	Selecting the operating mode
After connecting to the CEG, the DIS log-in screen (in which there is an embedded AUTELS message) is sent to the user’s system:

11.45 am               14 January 2005              Friday
************************************************************

AUSTRALIAN TAXATION OFFICE MELBOURNE

CORPORATE EXTERNAL GATEWAY

                         OOO         This service is for ATO
         AAAA            OOOO        authorised clients only. 
        AAAAAATTTTTTTTTTTOOOOOO      By continuing, you are
       AAA AAATTTTTTTTTTTOOO OOO     representing yourself
      AAA  AAA    TTT    OOO  OOO    as an authorised user.
     AAA   AAA    TTT    OOO   OOO   The system is monitored,
    AAAAAAAAAA    TTT    OOO    OOO  and any misuse will be
   AAAAAAAAAAA    TTT    OOO     OOO reported to the appropriate
  AAA      AAA    TTT     OOO   OOO  authority.
 AAA       AAA    TTT      OOOOOOO   
                            OOOOO    
                             OOO     
                              O
******************* ESC to disconnect ********************MEE

At this point the user (or user’s software) selects the operating mode (AUTELS) or disconnects by sending an <ESC>.
To select AUTELS mode, the user’s software must send the response indicator:
<Ctrl B>*****5 <CR> (where  5  is the checksum for this message)
If an invalid response or no response at all is received within the time–out period of 25 seconds, DIS sends the log-in screen again.  DIS sends this screen five (5) times before disconnecting the user.
If the user has experienced a transmission failure during the previous communications session (transmission is interrupt), an error message will be sent to the users the next time they log in.

4.7	Logging-in to DIS
The ID and initial password are issued by the ATO to the user as part of client registration. See Section 2.6 — Security for details.  The password first issued by ATO must be changed at the first log-in.
Warning:	If an invalid User ID or password is typed, the connection to DIS is cleared.
If the user's software sends an incorrect password six (6) times without a correct password login, the account is locked to prevent access and DIS sends a  D03  message.
When a user’s account is locked, even logins using the correct password will fail and a  D05  message sent.
If this happens, the user must contact the relevant ATO Tax Agent Support Centre for assistance.	

4.8	System Bulletins
The significance of a bulletin as of DIS Version  11.22 and later depends upon whether the user is connected to a lodgment (AD,BR,ME,SY) or bulletin (NO) service.  See section 6.3 - AUTELS message formats, Type 0, for the location of the service identity (Site).  If you receive a bulletin when connected to a lodgment service this is general information and is ordinarily only received once.  This information may relate to due dates for lodgment, scheduled outages, or other periodic information of use to the Tax Agent.  
If you receive a bulletin from a bulletin service then the bulletin contains static information, and will be received each and every time a connection is made to a bulletin service.  This information suggests to the agent that they lodge on a secondary CEG, or wait, as there is an issue in availability of the targeted lodgment system for the user (may be network or system related and may affect one or many users).
Bulletins from a lodgment service must be available for users to view and the developed software must warn them that a new Bulletin has been received.  It is not necessary to display it at the time it is sent by DIS, but it must be stored and brought to the attention of the user.  Lodgment service bulletins are named  BULL_ss.nnn, where  ss identifies the CEG site and nnn is a sequence number. Each System Bulletin is sent to each user once only.
Bulletins from a bulletin service can be displayed immediately, they do not need to be stored for perusal by the tax agent at a later time because they apply to the difficulty the agent is having there and then.  If an automatic switch to a secondary lodgment service will occur it is not necessary to display the bulletin service bulletin at all.  Bulletin service bulletins are always named  BULL_NO.1.

4.9	Logging-out
After users have completed a session, they exit and DIS logs them out.
When users exit, DIS disconnects the TCP connection at the ATO end.    Software must disconnect the TCP connection to DIS on the PC before closing down the VPN tunnel and disconnecting from the IP network.  If the PC does not disconnect the TCP connection, the circuit will remain open until it times out, and will cause a D02 error if the user attempts to log in again before the timeout occurs.
Connections to Dial IP must not be held open un-necessarily.
 
4.10	Unexpected disconnection
If you have established a connection to the DIS application (even if you have not yet authenticated to the application), and you do not logout in an orderly fashion then you will be unable to establish a new connection to either the VPN concentrator or the application for at least 3 minutes.
For dial up connections it may take almost a minute to establish another connection.  However, for clients with a permanent connection this is not the case and another connection can be attempted almost immediately.  Most unsolicited disconnections occur because the modem connection has aborted.  Permanent connections are less likely to be unexpectedly disconnected.
A simple solution to this issue is to delay 3 minutes after an unexpected disconnect.  If you attempt to re-connect sooner after an unexpected disconnection you will be unable to establish a connection to the VPN concentrator or the application as the previous connection has not yet been cleared.
5	DIS Manual mode - VT100 emulation

You can access DIS by using Telnet, or a similar terminal emulation package, by connecting to the DIS port on one of the CEG systems.  Thus by connecting to a CEG IP address using the DIS port you will receive VT100 mode screens.  The standard Windows Telnet supports VT100 and other terminal emulations.
It is not possible to transfer files, either by sending forms in, or by retrieving reports, using manual mode.   Manual mode should only be used for testing or troubleshooting.
The Main Menu
DIS displays the main menu after log-in or after the System Bulletin and any current error screen is shown.  The screen seen by the user varies depending upon whether the user’s ELS password has expired.
This condition is indicated by a status message displayed in reverse video directly below the screen title.  Users are forced to change passwords if their password has expired.  In the following example the status message is a warning only not an insistence the password be changed immediately, that screen follows.
The following screen shows an example main menu screen:

11.45 am                12 January 2007             Friday
***********************************************************
AUSTRALIAN TAXATION OFFICE MELBOURNE

CORPORATE EXTERNAL GATEWAY

MAIN MENU

Your Password will expire in [n] days

					C  Change password
					D  Display transmission status

					X  Exit

		Please type your selection:

Note [n] can be any number from 1 to 30.  
Software producers can select six other ‘hidden’ items that are described in 'VT100 test functions'.  Except for <Ctrl R><CR>  (resend last screen), users should not be informed of these hidden options; they are designed to assist software producers to find errors in their programs.
The user types the character that corresponds to the service required:
User enters:	Then DIS:	
 C	Displays ‘Change Password’ screen	
 D	Displays ‘Transmission Status’ screen	
 X	Logs out the user and clears the call to the ceg 	
Any incorrect menu selection results in an error message:
Invalid selection - please re-type selection
Main menu — change password
In the following example, the user’s ELS password has not changed for 30 days or more, and the only valid menu items are to change the password or exit DIS:

11.45 am                 12 January 2007            Friday ************************************************************

AUSTRALIAN TAXATION OFFICE MELBOURNE

CORPORATE EXTERNAL GATEWAY

MAIN MENU

Your password has expired. Please change your password

		C  Change password

		X  Exit

	Please type your selection:

The user types the character that corresponds to the service required:
User enters:	Then DIS:	
 C	Displays ‘Change Password’ screen	
 X	Logs out the user and clears the call to the ceg 	
Any incorrect selection results in an error message:
Invalid selection - please re-type selection
Display Transmission Status
This screen shows the current status of transmissions sent by users which are still stored on the ceg and awaiting processing. There may be more than one page to a Transmission Status report:

11.45 am            12 January 2007  			Friday             
*************************************************************
AUSTRALIAN TAXATION OFFICE MELBOURNE

CORPORATE EXTERNAL GATEWAY

TRANSMISSION STATUS

34 transmissions awaiting processing

    TRANS. NO.	DATE/TIME SUBMITTED	STATUS
    ---------	-------------------	------
	15	11/01/2007 13:03:52	WAITING FOR PROCESSING
	14	11/01/2007 14:04:32	WAITING FOR PROCESSING
	13	11/01/2007 15:01:44	WAITING FOR PROCESSING
	11	11/01/2007 14:57:00	WAITING FOR PROCESSING
	10	11/01/2007 15:51:32	WAITING FOR PROCESSING

           Press Return key to continue

This example shows that 34 transmissions are waiting to be processed.  There are two status states that may be displayed:
WAITING FOR PROCESSING	Messages have been received but haven't yet been processed (not yet validated)	
BEING PROCESSED	Messages are being processed (validated but not yet delivered to internal ATO processing systems).  In this case you may or may not have collected the validation report.	

DIS does not process messages, it only checks for certain errors. When a transmission number no longer appears on the transmission status screen, the messages in that transmission have been transferred to other ATO machines for processing.
To continue the communication session, the user presses the Return key. If there is more than one page in a report, pressing the Return key displays the extra pages before continuing.
Change Password 
This screen allows users to change passwords:

11.45 am                12 January 2007              Friday
************************************************************

AUSTRALIAN TAXATION OFFICE MELBOURNE

CORPORATE EXTERNAL GATEWAY

CHANGE PASSWORD

Your password must be at least 8 characters long
but not more than 16 characters.
Use at least one upper case letter: A - Z
and at least one number : 0 - 9
------------------------------------------------------------
Type old password:
Type new password:
Re-type new password for confirmation:

DIS prompts the user to type the old (current) password. Users type the old password and press the Return key:
Type old password: [OLDPSWD]<CR>
DIS then prompts the user to type a new password:
Type new password: [NEWPSWD]<CR>
A third prompt next appears at the bottom of the screen asking the user to confirm the new password:
Re-type new password for confirmation: [NEWPSWD]<CR>
If all is correct, DIS displays the following message:
Password has been changed - Press Return key to continue
If the old password is incorrect or new passwords do not match, dis displays the following message:
Passwords do not match (D06)
Your password was not changed
Press Return key to continue
If a dis error occurs, which prevents the password being changed, dis displays the following message:
ATO file system problem (D04)
Your password was not changed
Press Return key to continue
If the new password is invalid (more than 16 characters or less than 12 characters, or contains illegal characters, or does not contain at least one alpha and one numeric character), or contains more than two characters, in the same position, from the old password, DIS displays the following message:
Password is invalid (D15)
Your password was not changed
Press Return key to continue
If the password has been used before, DIS displays the following message:
Password has been used before (D14)
Your password was not changed
Press Return key to continue
ATO software error screen
This screen is displayed after an ATO software error occurs during a session (in AUTELS mode, the ‘D07’ message is sent by DIS). This event should be reported to the ATO immediately:

11.45 am                12 January 2007             Friday
************************************************************

AUSTRALIAN TAXATION OFFICE MELBOURNE

CORPORATE EXTERNAL GATEWAY

ATO SOFTWARE ERROR

An error has occurred in the on-line transmission program

Please contact the Corporate External Gateway Helpdesk

DO NOT ATTEMPT TO LOG-IN AGAIN UNTIL ADVISED BY THE
ATO CORPORATE EXTERNAL GATEWAY ADMINISTRATOR

Press the Return key to log-out

The user must press the Return key to log out.
Logging-out
A user can logout by using the Exit option on the main menu.
6	The AUTELS Protocol
6.1	Overview
AUTELS is designed for fully automated communication with the ATO DIS (Document Interchange System).
DIS is not sensitive to the way AUTELS messages are processed by the user's system. To DIS, all AUTELS software looks alike.

6.2	AUTELS operation
User's systems and DIS communicate by passing AUTELS messages to each other. The messages sent by DIS contain action indicators and the messages sent by the user's system contain response indicators.
AUTELS messages are described in Section 6.3. Their meaning is described in the State Tables of Section 6.4.  Action indicators correspond to menu items and response indicators correspond to user selection.  Other action indicators result from errors detected by DIS. 
There are eight States all together.
The user’s system always starts a communication session in
State 0. It waits to receive an action indicator from DIS.  When the message arrives, the user’s system checks for corruption using the algorithm set out in Appendix C.
If there is no error, the user’s system then searches for the action indicator in the table for the current State.  It decides on the next request and sends the corresponding response indicator to DIS.  The response indicator chosen may result in a change of State for the user’s system as indicated in the State Table for the selected response indicator.
After log-in, the user's system moves to State 1 and waits for the next action indicator message sent by DIS.
DIS and the user’s system pass from State to State as they send messages to each other.
The following paragraphs briefly describe each State. They are described in numerical order for convenience; the sequence of States never occurs in this order during a communications session.

State 0 (Log-in):
DIS sends the log-in screen, which contains the action indicator  *****  requesting the user’s system to select an operating mode. The user’s system responds by sending the response indicator  *****.
The user’s system then sends the ELS User ID and password in response to action indicators from DIS.  Both systems remain in State 0 until log-in is completed.
State 1 (Main menu):
The user’s system waits for an action indicator message.  When it is received, the user’s system selects one of the responses listed against the action indicator, sends the corresponding response indicator, changes its current State to that indicated in the State Table, and performs the next action.
State 2 (Change password):
The user’s system waits for an action indicator message.  When it is received, the user’s system inserts password information into a Type 6 response message.  The information to be sent — old or new password — is defined by the action indicator.
State 3 (Display transmission status):
The user’s system waits for an action indicator message.  When it is received, the user’s system extracts the status of one transmission from a status record action indicator message.  Each message has to be acknowledged with a Type 5 response message.  DIS sends a last status record action indicator when no more status records are available.  After the last status record message is acknowledged, both systems return to State 1.
State 4 (Select old messages):
The user’s system waits for an old message record action indicator message.  When it is received, the user’s system extracts information on old messages from a Type 3 action indicator message.  Each message must be acknowledged and DIS sends a last old message record action indicator when no more old messages are available.
The user’s system selects messages by returning a make selection of old messages  response indicator message.
State 5 (Send messages):
The user’s system waits for a Type 1 action indicator message. When the user’s system receives the ready to receive messages action indicator, it can send a Type 9 AUTELS message with embedded data in it. When the message has been transferred, both systems return to State 1.
State 6 (Receive new messages):
The users' system receives a type 9 AUTELS message with embedded data.  When the message has been received, both systems return to State 1.  If the message is not received successfully the user's system rejects the message with an error message.
State 7 (Receive other messages):
The user’s system waits for an action indicator message. When it receives the ready to send other messages indicator from DIS, it receives messages.  When the messages have been exchanged, both systems return to State 1.

AUTELS Error handling
If the user’s system finds a check digit error, it responds with a request resend response indicator.
The user’s system should wait a maximum of 60 seconds for a message. If none arrives, the user’s system requests the message to be resent.
If the user’s system cannot find an action indicator in the current State Table, it performs one of the actions listed against protocol violation in the State Tables.  That is, the user’s system requests a system reset, or disconnects. If a reset message is sent, both parties return to State 0 and the user’s system selects the operating mode and logs-in again.  All protocol violations must be logged by the user’s system.
The ATO recommends the use of a retry counter.  If five request reset response indicators are sent, the user’s system should disconnect.
When DIS does not receive or recognize a response indicator message, it sends a Type 4 message that includes an error code, a State and the previous action indicator message.  The user’s system must display and/or log the error message corresponding to the error code, go to the State indicated in the State field, and then use the previous Type 4 message as if it were received as a normal action indicator message, unless the state indicated is state 1.  If the state indicated in the State field is 1, the user’s system should send a “request status” response indicator.
DIS waits 25 seconds for a response from the user’s system before re-sending the previous action indicator in a Type 4 message; in this case it contains a no response error code, but the State is not changed and the user’s system can simply ignore this action indicator.
DIS re-sends a Type 4 message 6 times.  If no valid response is received, the user is logged out.
Transmission error handling
Transmission errors and procedures for dealing with them are described in Chapter 7 —Reports Sent to Users by DIS.

6.3	AUTELS message formats
There are nine message types (0,1,2,3,4,5,6,7,9).  All start with the Header character <Ctrl B> and end with the Checksum  character and the Eol character  <CR>.
The general format of an AUTELS message is:
	<Ctrl B>, 5 indicator chars, information chars, 1 Checksum char, <CR>
Checksum
All indicator messages include a single byte checksum character immediately preceding the <CR> the last character in the message. It ensures that the message has arrived without corruption.
Note that the AUTELS type 9 string is an exception in that the checksum only relates to the header.
When an action indicator is received, the user's system calculates a checksum for this message and compares it with the checksum inserted by DIS.  If they do not match, then the message has been corrupted and the user’s system should send a Request resend response indicator message.
Appendix C — Single byte checksum describes the algorithm for calculating checksums.
Type 0 — Action indicator
Sent by	DIS
Purpose	to request the user’s system to select an operating mode (only AUTELS can be used to send and receive files).
The Type 0 indicator message is different from all others in that it is embedded in the last line of the Log-in screen.
Field Name	Description	Type	Size	
Header	<Ctrl B>Indicates start of AUTELS message	alphanumeric	1 byte	
Indicator	Indicates type of AUTELS message	alphanumeric	5 bytes	
Site	CEG Site, one of: 'AD' (Adelaide), 'ME' (Melbourne), 'SY (Sydney)', 'BR (Brisbane)', 'NO (National Office)', 'G2 (test)', 'G1 (test)'	alphanumeric	2 bytes	
Chk	Single byte checksum.	alphanumeric	1 byte	
EOL	<CR> Indicates end of AUTELS message.	alphanumeric	1 byte	
Example:
*****Press Return key to log-in, or Esc key to disconnect ***<Ctrl B>*****MEE<CR>
Where
<Ctrl B>*****MEE  are the last characters in the log-in prompt
And
<Ctrl B>	header
*****	Login action indicator message
ME	Melbourne ceg identification
E	checksum
<CR>	Eol

Type 1 — Action indicator
Sent by	DIS
Purpose	to send an action indicator and the date/time that the indicator is sent.
Field Name	Description	Type	Size	
Header	<Ctrl B>Indicates start of AUTELS message	alphanumeric	1 byte	
Indicator	Indicates type of AUTELS message	alphanumeric	5 bytes	
Date/Time	Date and time this message was sent, format is: DD MMM CCYY HH:MM:SS	alphanumeric	20 bytes	
Chk	Single byte checksum.	alphanumeric	1 byte	
EOL	<CR> Indicates end of AUTELS message.	alphanumeric	1 byte	
Example:	
<Ctrl B>1111104 Jan 1997 11:45:477<CR>
Where
<Ctrl B>	header
11111	ready to receive
04 Jan 1997 11:45:47	date/time message sent
7	checksum
<CR>	Eol

Type 2 — Action indicator plus transmission status information
Sent by	DIS
Purpose	to send an action indicator and transmission status information.
Field Name	Description	Type	Size	
Header	<Ctrl B>Indicates start of AUTELS message	alphanumeric	1 byte	
Indicator	Indicates type of AUTELS message	alphanumeric	5 bytes	
Date/Time	Date and time this message was sent, format is: DD MMM CCYY HH:MM:SS	alphanumeric	20 bytes	
Transmission number	Number of topic or file, range 1-999, right justified, leading spaces.	alphanumeric	3 bytes	
Date	Date that the transmission referred to by the transmission number was submitted. Left justified, trailing spaces, format is: DD/MM/CCYY.	alphanumeric	10 bytes	
Time	Time that the transmission referred to by the transmission number was submitted. Left justified, trailing spaces, format is: HH:MM:SS.	alphanumeric	8 bytes	
Status	Status of the transmission referred to by the transmission number.  One of 'WAITING FOR PROCESSING nnnn[N]' (Waiting for validation), or 'BEING PROCESSED' (Validated not yet delivered to processing).  Left justified with trailing spaces. nnnn is the number of requests in the processing queue. [N] is an optional 'N' if the processing program is not running.  Transmission(s) in other states will not appear.	alphanumeric	28 bytes	
Chk	Single byte checksum.	alphanumeric	1 byte	
EOL	<CR> Indicates end of AUTELS message.	alphanumeric	1 byte	
Example:
<Ctrl B>)))))04 Jan 1997 11:45:50 1003/01/199713:03:52BEING PROCESSED             4<CR>
Where
<Ctrl B>	header
)))))	action indicator for ‘status record’
04 Jan 1997 11:45:50	date/time message sent
10	transmission number
03/01/1997	date transmission submitted
13:03:52	time transmission submitted
BEING PROCESSED	status of transmission
4	checksum
<CR>	Eol

Type 3 — Action indicator plus old file information
Sent by	DIS
Purpose	to send an action indicator and information for selecting old files.
Field Name	Description	Type	Size	
Header	<Ctrl B>Indicates start of AUTELS message	alphanumeric	1 byte	
Indicator	Indicates type of AUTELS message	alphanumeric	5 bytes	
Date/Time	Date and time this message was sent, format is: DD MMM CCYY HH:MM:SS	alphanumeric	20 bytes	
Sequence 1	Sequence number for selecting filename, range 1-30, right justified, leading spaces.  If there are less than 3 sets of <sequence> and <filename> the unused fields are space filled.	alphanumeric	2 bytes	
FileName 1	Left justified, trailing spaces	alphanumeric	12 bytes	
Sequence 2	Sequence number for selecting filename, range 1-30, right justified, leading spaces.  If there are less than 3 sets of <sequence> and <filename> the unused fields are space filled.	alphanumeric	2 bytes	
FileName 2	Left justified, trailing spaces	alphanumeric	12 bytes	
Sequence 3	Sequence number for selecting filename, range 1-30, right justified, leading spaces.  If there are less than 3 sets of <sequence> and <filename> the unused fields are space filled.	alphanumeric	2 bytes	
FileName 3	Left justified, trailing spaces	alphanumeric	12 bytes	
Chk	Single byte checksum.	alphanumeric	1 byte	
EOL	<CR> Indicates end of AUTELS message.	alphanumeric	1 byte	
Example:
<Ctrl B>=====04 Jan 1997 11:45:47 7VALID_ME.16 8VALID_ME.17 9TRANS_ME.17 Y<CR>
Where
<Ctrl B>	header
=====	action indicator for ‘old messages'
04 Jan 1997 11:45:47	date/time message sent
 7	sequence number
VALID_ME.16	filename of old message
 8	sequence number
VALID_ME.17	filename of old message
 9	sequence number
TRANS_ME.17	filename of old message
Y	checksum
<CR>	Eol

Type 4 — Error message sent by DIS
Sent by	DIS
Purpose	to resend an action indicator and the previous message after an invalid response.
Field Name	Description	Type	Size	
Header	<Ctrl B>Indicates start of AUTELS message	alphanumeric	1 byte	
Indicator	Indicates type of AUTELS message	alphanumeric	5 bytes	
Error code	See below.	alphanumeric	3 bytes	
State	The users system must return to this State, range 1-7.	numeric	1 bytes	
Body of previous message	Left justified, trailing spaces, previous message excepting header, chk and eol.  If the previous message is a type 9 message the File Data field is omitted, only the header is included.	alphanumeric	variable length	
Chk	Single byte checksum.	alphanumeric	1 byte	
EOL	<CR> Indicates end of AUTELS message.	alphanumeric	1 byte	

Error codes:
D01	= Invalid User ID or password
D02 	= This User ID is in use by someone else
D03 	= Too many failed log-in attempts, account LOCKED
D04 	= ATO file system problem
D05 	= Access to this account is locked against any access (failed logins)
D06 	= Passwords do not match
D07 	= ato software error
D08 	= Protocol violation
D09 	= No response
D10 	= Transmission error
D11	= Access to this account is locked against Dial IP access (CNI agreement needed)
D12 	= Invalid network calling address
D13 	= Checksum error
D14 	= Password has been used before
D15 	= Your password is invalid
D16	= Parity error
See Appendix A for full explanation of errors

Example: 
<Ctrl B>!!!!!D0611111104 Jan 1997 11:45:479<CR>
Where
<Ctrl B>	header
!!!!!	action indicator for ‘response error’
D06	error type
1 	next state
1111104 Jan 1997 11:45:47	type 1 indicator message 
9	checksum
<CR>	Eol

Type 5 — Response indicator
Sent by	user’s system
Purpose	to respond to an action indicator
Field Name	Description	Type	Size	
Header	<Ctrl B>Indicates start of AUTELS message	alphanumeric	1 byte	
Indicator	Indicates type of AUTELS message	alphanumeric	5 bytes	
Chk	Single byte checksum.	alphanumeric	1 byte	
EOL	<CR> Indicates end of AUTELS message.	alphanumeric	1 byte	

Example:
<Ctrl B>AAAAA&<CR>
Where
<Ctrl B>	header
AAAAA	response indicator for ‘send messages’
&	checksum
<CR>	Eol

Type 6 — Response indicator plus ID, password, file selection information, ack position in file, and error message
Sent by	user’s system
Purpose	to send a response indicator, ID and password
	or, to send a response indicator and message selection information
	or, to send a response indicator and an error message to indicate a file
	     sent by DIS has been rejected by the user’s system
Field Name	Description	Type	Size	
Header	<Ctrl B>Indicates start of AUTELS message	alphanumeric	1 byte	
Indicator	Indicates type of AUTELS message	alphanumeric	5 bytes	
Information	Password, message selection information, or error message.  Variable length.	alphanumeric	Variable, up to 500 bytes	
Chk	Single byte checksum.	alphanumeric	1 byte	
EOL	<CR> Indicates end of AUTELS message.	alphanumeric	1 byte	

Example: 
<Ctrl B>666661,2,5,6A<CR>

Where
<Ctrl B>	header
66666	response indicator ‘select old messages’
1,2,5,6	select messages 1,2,5 and 6
A	checksum 
<CR>	Eol

Type 7 — Action indicator plus password information
Sent by	DIS
Purpose	to send an action indicator, password information and the date/time that message is sent
Field Name	Description	Type	Size	
Header	<Ctrl B>Indicates start of AUTELS message	alphanumeric	1 byte	
Indicator	Indicates type of AUTELS message	alphanumeric	5 bytes	
Date/Time	Date and time this message was sent, format is: DD MMM CCYY HH:MM:SS	alphanumeric	20 bytes	
Password life	Life of password in days, range 1-30, right justified, leading spaces.	alphanumeric	2 bytes	
Chk	Single byte checksum.	alphanumeric	1 byte	
EOL	<CR> Indicates end of AUTELS message.	alphanumeric	1 byte	

Example: 
<Ctrl B>[[[[[04 Jan 1997 11:45:47 5^<CR>
Where
<Ctrl B>	header
[[[[[	action indicator ‘log-in successful’
04 Jan 1997 11:45:47	date and time message sent
 5	lifetime, in days, of current password
^	checksum
<CR>	Eol

Type 9 — Message with embedded data
Sent by		DIS and users system
Purpose		to send a file with a date/time stamp
Field Name	Description	Type	Size	
Header	<Ctrl B>Indicates start of AUTELS message	alphanumeric	1 byte	
Indicator	Indicates type of AUTELS message	alphanumeric	5 bytes	
Date/Time	Date and time this message was sent, format is: DD MMM CCYY HH:MM:SS	alphanumeric	20 bytes	
Sub type	Indicates the type of file:
Sub type 0 – pkzip format file.
Sub type 1 – message that must be displayed on the screen and manually acknowledged by the user, ASCII text.
Sub type 2 – pkzip format file containing smime encoded message with a digital signature (not currently supported). 	numeric	1 bytes	
Length of filename	Length of the filename in bytes.  Right justified, leading spaces.	alphanumeric	2 bytes	
Filename	The name of the compressed file.	alphanumeric	variable length, specified by length of filename	
Length of file	Length of the compressed file in bytes.  Right justified, leading spaces.	alphanumeric	9 bytes	
Chk	Single byte checksum for header, includes indicator, date/time, type, length of filename, filename, length of file.	alphanumeric	1 byte	
File Data	The content of the file in the format specified by Sub type.  See Note below.	binary	variable length, specified by length of file	
EOL	<CR> Indicates end of AUTELS message.	alphanumeric	1 byte	

Note: There is a current maximum of 1,000 forms within a pkzip compressed file contained within a type 9 AUTELS string.  This is a limit imposed by Validation.
6.4	
AUTELS State Tables
State Tables have two sections. The first section describes the action indicators and corresponding message Types that are sent by DIS while the two systems are in this State. The second section describes the allowable responses by the user’s system.
State 0 — Log-in screen
DIS	User's system	
Description	Action Indicator	Message Type	Action	Response Indicator	Message Type	Next  State	Next Action	
Log-in Screen	*****
See Note1	0	Select AUTELS	*****	5	0	Wait	
Enter  User_ID	%%%%%	1	Send User ID	%%%%%	6	0	Wait	
Enter Password	(((((	1	Send
Password	(((((	6	0	Wait	
Agreement needed	]]]]]
See Note2	9	Agreed
Declined	]]]]]
!!!!!	5
5	0
0	Wait
Wait	
Log-in successful	[[[[[	7	Acknowledge	[[[[[	5	1	Wait	
Logging
you out	&&&&&	1	Acknowledge	&&&&&	5	0	Exit	
Error message	!!!!!	4	Extract State and previous message			0	Use previous message	
Chk error	corrupted indicator		Request resend	YYYYY	5	0	Wait	
Protocol violation	indicator not found		Disconnect					

Note1: The action indicator is embedded in the character string in the last line of the log-in screen; for example, the Melbourne CEG sends:
********Press Return key to log-in***<Ctrl B>*****MEE<CR>

Note2: On receipt of a ‘]]]]]’ Agreement needed indication the ASCII text file contained within the type9 string will contain the message to be displayed to the user.
When the ATO determines an agreement is required, no special action is required of the software other than to display the message sent and obtain a reply from the user.
If the user agrees, the software responds with the Agreed indicator (]]]]]) otherwise with the Declined indicator (!!!!!).  DIS will then proceed, on the basis of the response, to log the user in or otherwise log them out.  If the declined indicator is received DIS will send a type 4 string with a D11 error code before logging out the user.
This facility is intended primarily for the purpose of obtaining agreement from the user for the ATO to record their telephone number (CNI).  The content of the ASCII text file for CNI agreement is: 
I/We give my/our consent pursuant to National Privacy Principle No. 2 of the Privacy Act 1988 (see below) to Telstra to provide the ATO with the Call Number Identification (your telephone number including the STD code), the time of the call and its duration whenever connection with the ATO Network is made by me or my nominee via Telstra Dial IP.

NATIONAL PRIVACY PRINCIPLE NO. 2
Solicitation of personal information from individual concerned  
Where:
(a)	a collector collects personal information for inclusion in a record or in a 				generally available publication; and
(b)	the information is solicited by the collector from the individual concerned; 			the collector shall take such steps (if any) as are, 
		in the circumstances, reasonable to ensure that, before the information is  			collected or, if that is not practicable, as soon as   practicable after the 				information is collected, the individual concerned is generally aware of:
(c)	the purpose for which the information is being collected;
(d)	if the collection of the information is authorised or required by or under 				law—the fact that the collection of the information is so authorised or 				required; and
(e)	any person to whom, or any body or agency to which, it is the collector’s usual practice to disclose personal information of the kind so collected, and (if known by the collector) any person to whom, or any body or agency to which, it is the usual practice of that first-mentioned person, body or 	agency to pass on that information.

If the ATO has a requirement to introduce a replacement or new message the content of such will be discussed with software developers prior to its release.

State 1 — Main menu
DIS	User's system	
Description	Action Indicator	Message Type	Action	Response Indicator	Message Type	Next State	Next  Action	
Ready to receive	11111	1	Send returns
Change password
Display stats
Select old messages
Request status	AAAAA
CCCCC
DDDDD
EEEEE
WWWWW	5
5
5
5
5	5
2
3
4
1	Wait
Wait
Wait
Wait
Wait	
			Exit	XXXXX	5	0	Wait	
Ready to	22222	1	Receive new messages	BBBBB	5	6	Wait	
Send			Change password
Display stats
Select old messages	CCCCC
DDDDD
EEEEE	5
5
5	2
3
4	Wait
Wait
Wait	
			Exit	XXXXX	5	0	Wait	
Password expired	88888	1	Change password
Exit	CCCCC
XXXXX	5
5	2
0	Wait
Wait	
De-registered	99999	1	Receive new messages
Change password
Display stats
Select old messages
Exit	BBBBB
CCCCC
DDDDD
EEEEE
XXXXX	5
5
5
5
5	6
2
3
4
0	Wait
Wait
Wait
Wait
Wait	
Logging you out	&&&&&	1	Acknowledge	&&&&&	5		Exit	
Error message	!!!!!	4
See Note1	Request status	WWWWW	5	1	Wait	
Chk error	corrupted indicator		Request resend	YYYYY	5	1	Wait	
Protocol violation	indicator not found		Request reset 	ZZZZZ	5	0	Wait	

Note1: Request status (‘WWWWW’) is a new response indicator as at DIS Version 11.2 and later.  It has been introduced to improve error recovery and to improve efficiency of waiting for Validation reports.  For example, if the user receives a D10 error while in state 5, the type 4  message will indicate to change to state 1.  However, the user’s system does not know if DIS is ready to send or to receive, and thus the set of possible response indicators is unknown.  By sending a ‘WWWWW’ response indicator, DIS will respond with either ‘11111’ or ‘22222’ and the set of possible response indicators is then known.  A similar problem (and solution) arises when an attempt to change the password fails.
The ‘WWWWW’ response indicator can be sent in response to a ‘11111’ action indicator from DIS when in state 1 if the user’s system is waiting for a Validation report.  This is a much more efficient way of checking if a Validation report has arrived than sending ‘DDDDD’, going into state 3, and then returning to state 1.  Bear in mind that DIS will time out and log the user out if it receives more than six ‘WWWWW’ response indicators in a row. 

State 2 — Change password
DIS	User's system	
Description	Action Indicator	Message Type	Action	Response Indicator	Message Type	Next State	Next  Action	
Enter old password	33333	1	Send old password	33333	6	2	Wait	
Enter new password	44444	1	Send new password	44444	6	2	Wait	
Confirm new password	55555	1	Send new password	55555	6	2	Wait	
Change the
Password now	00000	1	Change password on the users system and then return to Main Menu	00000	5	1	Wait	
Error message	!!!!!	4	Extract state and previous message			as sent	Use previous message	
Chk error	corrupted indicator		Request resend	YYYYY	5	2	Wait	
Protocol violation	indicator not found		Request reset	ZZZZZ	5	0	Wait	

State 3 — Display transmission status
DIS	User's system	
Description	Action Indicator	Message Type	Action	Response Indicator	Message Type	Next State	Next  Action	
Status record	)))))	2	Acknowledge status message	)))))	5	3	Wait	
Last status record	\\\\\	2 or 1
see Note1 	Return to Main Menu	\\\\\	5	1	Wait	
Error message	!!!!!	4	Extract state and previous message			as sent	Use previous message	
Chk error	corrupted indicator		Request resend	YYYYY	5	3	Wait	
Protocol violation	indicator not found		Request reset	ZZZZZ	5	0	Wait	

Note1:  If there are no old messages at all you will receive a ‘\\\\\’ in a type 1 string, otherwise you will receive a number of ‘)))))’ status records (possibly none), followed by a ‘\\\\\’ type 2 message.

State 4 — Select old messages
DIS	User's system	
Description	Action Indicator	Message Type	Action	Response Indicator	Message Type	Next State	Next  Action	
Old message record	=====	3	Acknowledge old message	=====	5	4	Wait	
Last old message record	/////

See Note1	3	Acknowledge last old message	/////	5	4	Wait	
Select old messages	66666

See Note2	1	Make selection of old messages

Selection pending	66666

PPPPP	6

5	7 or 1

4	Wait

Wait	
Error message	!!!!!	4	Extract state and previous message			as sent	Use previous message	
Chk error	corrupted indicator		Request resend	YYYYY	5	4	Wait	
Protocol violation	indicator not found		Request reset	ZZZZZ	5	0	Wait	
Note1: If the number of old messages can be divided by three then each of the sequence and filename fields of the type 5 message will be completed, otherwise one or more trailing fields may be blank.
You will receive as many 'old message record' indicators (possibly zero) as is necessary to hold all the filenames prior to the 'last old message' indicator.
Note2: If the user is presented with options as to which old reports they wish to select, then there will be a time lag making the 66666 response.  In this case the user's s/w may elect to respond with a PPPPP, response pending, which may be repeated up to 20 times, to allow more time for the client to make a selection.  It is suggested that this response be made after 20 seconds real time to avoid a D09 timeout after 25 seconds.  In response the DIS system will reply with the 66666 action indicator for which a response is still pending.
The selection of old messages by the response indicator 66666 is by a comma separated list of items (the reference number is included in the 66666 action data).  Or alternatively you may use an asterisk '*' to select all reports. 
State 5 — Send messages
DIS	User's system	
Description	Action Indicator	Message Type	Action	Response Indicator	Message Type	Next State	Next  Action	
Ready to receive messages	-----	1	Send messages	-----	9	1	Wait	
Error message	!!!!!	4	Extract state and previous message			as sent	Use previous message	
Error	corrupted indicator		Request resend	YYYYY	5	5	Wait	
Protocol violation	indicator not found		Request reset	ZZZZZ	5	0	Wait	

State 6 — Receive new messages
DIS	User's system	
Description	Action Indicator	Message Type	Action	Response Indicator	Message Type	Next State	Next  Action	
Send new messages	|||||

See Note1	9	Receive and accept new messages

Receive and acknowledge part of the message

Reject new messages (error situation only)	|||||

KKKKK

!!!!!	5

6

6	1

6

1	Wait

Continue receiving the message

Wait	
Error message	!!!!!	4	Extract state and previous message			as sent	Use previous message	
Error	corrupted indicator		Request resend	YYYYY	5	6	Wait	
Protocol violation	indicator not found		Request reset	ZZZZZ	5	0	Wait	
Retry count exceeded	&&&&&	1	Acknowledge	&&&&&	5		Exit	

Note1: The purpose of two responses to 'Send new messages' is to allow for a positive or negative acknowledgement to be returned.  A positive acknowledgement (|||||) means the user has correctly received the entire message.  A negative acknowledgement (!!!!!) means a problem has occurred.  In this case transmission, validation, and other reports which are contained within the data of the message will not be flagged by DIS as having been received by the user.  If a positive acknowledgement is received, DIS will record that the user has successfully received these files and will remove them from the queue of files to send.

If the new messages are rejected, it is highly recommended that the user’s software insert an error message in the Information portion of the returned Type 6 message to indicate the nature of the problem.

It is not necessary to wait for the end of the message to respond with a negative acknowledgement as DIS will detect such while sending a Type 9 message and will abort the message mid-stream.  Although you may of course still receive some data after requesting an abort.  To help identify the end of the aborted data and the re-commencement of the AUTELS protocol, DIS will send out 10 bytes of binary 1s (Hex "ff") followed by a carriage return prior to the Control-B indicating the start of the next AUTELS message.

A request resend may be sent to request the type 9 message be resent, but must only be sent after the entire type 9 message has been received.  If you wish to abort the transfer you must use the negative acknowledgement.  The request resend is included for consistency with the rest of AUTELS - it is recommended that you use the negative acknowledgement rather than the resend option.

Note: The ‘KKKKK’ response indicator is a new indicator introduced into AUTELS as at Version 11.20 and later to improve download of large files over slow communications lines.  If the user has a slow Internet or Dial IP connection, it is possible for DIS to send the complete file and to time out before the complete file has been received by the user’s PC.  DIS will then send a type 4 string with a D09 (no response) error.  This error condition occurs because data is buffered in the network, and it takes longer for the PC to receive the buffered data than the DIS timeout value (25sec).  The effect of sending ‘KKKKK’ is to reset the DIS timer, thus preventing the error condition.  The data contained in the type 6 string of the ‘KKKKK’ should contain an ASCII representation of the decimal position in the file (in bytes) that is being acknowledged (do not include the type 9 string header).  A ‘KKKKK’ only acknowledges part of the file, it must not be used to acknowledge the end of the file.  It is recommended that a ‘KKKKK’ be sent every 20 seconds during download of any file that takes more than 20 seconds to complete the download.  Note that DIS will accept a maximum of 200 repeated ‘KKKKK’ strings before it will time out and log the user out.

State 7 — Receive other messages
DIS	User's system	
Description	Action Indicator	Message Type	Action	Response Indicator	Message Type	Next State	Next  Action	
Send other messages	77777

See Note1	9	Receive other messages

Receive and acknowledge part of the message

Reject other messages (error situation only)	77777

KKKKK

!!!!!	5

6

6	1

7

1	Wait

Continue receiving the message

Wait	
Error message	!!!!!	4	Extract state and previous message			as sent	Use previous message	
Chk error	corrupted indicator		Request resend	YYYYY	5	7	Wait	
Protocol violation	Indicator not found		Request reset	ZZZZZ	5	0	Wait	
Retry count exceeded	&&&&&	1	Acknowledge	&&&&&	5		Exit	

Note1: The purpose of two responses to 'Send other messages' is to allow for a positive or negative acknowledgement to be returned.  A positive acknowledgement (77777) means the user has correctly received the entire message.  A negative acknowledgement (!!!!!) means a problem has occurred.
If the other messages are rejected, it is highly recommended that the user’s software insert an error message in the Information portion of the returned Type 6 message to indicate the nature of the problem.

It is not necessary to wait for the end of the message to respond with a negative acknowledgement as DIS will detect such while sending a Type 9 message and will abort the message mid-stream.  Although you may of course still receive some data after requesting an abort.  To help identify the end of the aborted data and the re-commencement of the AUTELS protocol, DIS will send out 10 bytes of binary 1s (Hex "ff") followed by a carriage return prior to the Control-B indicating the start of the next AUTELS message.

A request resend may be sent to request the type 9 message be resent, but must only be sent after the entire type 9 message has been received.  If you wish to abort the transfer you must use the negative acknowledgement.  The request resend is included for consistency with the rest of AUTELS - it is recommended that you use the negative acknowledgement rather than the resend option.

Note: The ‘KKKKK’ response indicator is a new indicator introduced into AUTELS as at Version 11.2 and later to improve download of large files over slow communications lines.  If the user has a slow Internet or Dial IP connection, it is possible for DIS to send the complete file and to time out before the complete file has been received by the user’s PC.  DIS will then send a type 4 string with a D09 (no response) error.  This error condition occurs because data is buffered in the network, and it takes longer for the PC to receive the buffered data than the DIS timeout value (25sec).  The effect of sending ‘KKKKK’ is to reset the DIS timer, thus preventing the error condition.  The data contained in the type 6 string of the ‘KKKKK’ should contain an ASCII representation of the decimal position in the file (in bytes) that is being acknowledged (do not include the type 9 string header).  A ‘KKKKK’ only acknowledges part of the file, it must not be used to acknowledge the end of the file.  It is recommended that a ‘KKKKK’ be sent every 20 seconds during download of any file that takes more than 20 seconds to complete the download.  Note that DIS will accept a maximum of 200 repeated ‘KKKKK’ strings before it will time out and log the user out.
7	Reports Sent to Users by DIS
7.1	Overview
There is one report received by all users of  DIS: the Transmission Report. This report is designed to inform users about the status of forms (files) sent to DIS.  It assists users to manage transmission problems.  If a user is registered as an ELS user, a validation report will also be received for each transmission of forms.

Attention:	If a user sends messages to a secondary ceg, then they must connect with that CEG to receive the Transmission Reports (and Validation Reports) for forms sent there.	

Developers of AUTELS mode software may alter the format of these reports but cannot omit or change data items, field names or the order of their appearance in the report. The page headers and report termination line may be altered but their meaning must be preserved.

7.2	Transmission Reports
Transmission Reports are prepared after each transmission by a user. They list all forms (files) in the transmission that have been received by DIS.  Note that a compressed file may contain many files.
Transmission Reports are prepared before the messages sent by users are processed. The only information available is the file names — DIS knows nothing of the file contents and what form may be contained at this stage. A Transmission Report is only a record of files received, it lists the file names after the .ZIP file has been decompressed  — i.e. it lists the contents of the compressed file.  The only exception for ELS users is if DIS cannot decompress a file.  In this case, the filename of the compressed file is listed in the Transmission Report.
The filename of Transmission Reports is always of the form  TRANS_ss.nnn  (where  ss  identifies the CEG site and nnn is the transmission number assigned by DIS). Transmission numbers (from each CEG to each agent) are sequential.  They range from  1 to 999 and then start again at zero.
Transmission Reports are ASCII files composed of printable characters.
Transmission Reports should be made available for viewing and printing by the user as soon as it is received by AUTELS software.
The following illustrates the format of a Transmission Report:

ATO Adelaide//16 Jan 2007//Page 1
TRANSMISSION REPORT NUMBER  TRANS_AD.321

Name//Appr_No
Address  City  Postcode

TRANS NUMBER	321
DATE/TIME OF TRANS	16 Jan 2007//10:46:48
FILES RECEIVED	3
TRANS COMPLETE	[Yes|No]
**T11 Transmission successfully completed**

TXID
ASE099_I.ABX
CASE094
ACASE0789_AS.QWE

**T10 END OF TRANSMISSION REPORT**

So that Reports can be manipulated by AUTELS mode software, the data is organized as follows:
•	All lines are left aligned and terminated by CR/LF
•	Data items in brackets [  ] are optional
•	The first three lines (including one line consisting of CR/LF only) comprise a header for printed pages which is repeated at the top of each page
•	The variable data in the first line consists of three fields separated by two slash characters  //
•	The next nine lines of the first page only, including two lines of CR/LF only, consist of a combination of fixed identification fields and variable data fields
•	two lines identify the user
•	four lines start with fixed identification fields of 20 upper case characters
•	the last line may also display a transmission error message (tabulated below)
•	all variable fields are terminated by // or CR/LF
•	there are no leading or trailing space characters in variable fields
•	the time is in 24 hour format
•	The next group of lines contains the user assigned file names for messages received by the ceg
•	fields are up to 16 characters in length
•	there is one line for each file successfully received by the ceg
•	Messages always start in column 1 and are preceded by **Tnn  and a space character
If a transmission was completely successful, the message preceding the list of transmitted files is:
**T11 Transmission was successfully completed**
Transmission error handling
If a transmission was abnormal, the reason precedes the list of transmitted files. Possible DIS messages are:

**T13 No files were received **	No files were received by DIS	
**T14 Failure encountered before transmission was completed **	The transmission failed before it completed due to communications failure in the middle of sending the data	
**T17 Transmission error - unable to decompress, no files received **	DIS could not decompress a file.  This may be caused by a compressed file being corrupted or not in the correct format, or a file was sent that had not been compressed, or the file sent did not have a .ZIP suffix in the filename, or the compressed file contained directories. The file causing this problem is deleted by DIS.	

If a Transmission Report contains any of these error messages, then no files were successfully received by DIS. The user must then arrange for those forms to be re-transmitted.
If DIS encounters some problem decompressing a file, the following message is placed in the transmission report:
 	**T02  file compression error, file deleted**
This message is to inform the user that the file has not been accepted by DIS, and all forms contained in this file must be retransmitted.  Possible causes of this message are the user sending:
•	A compressed file that does not have a .ZIP suffix in the filename,
•	A .ZIP file that is not a compressed file,
•	A corrupted or invalid .ZIP file,
•	A compressed file that has a directory, or other compressed file, within it.

If a user assigned filename is invalid (after decompression), DIS places the following message in the transmission report:
		**T01 File deleted**
This message is to inform the user that the file has not been accepted by DIS and has been deleted.  Possible causes of this message are the user sending:
•	A file with no filename,
•	A file with the name of the form   BULL_ss.nnn, TRANS_ss.nnn, VALID_ss.nnn or RPTttnnn.
•	A file with the filename .ZIP compressed into the .ZIP file.
A Transmission Report always terminates with one of two messages:
**T10 END OF TRANSMISSION REPORT**
—or—
**T20 CEG failure - Check this transmission report - If you have sent any transmissions after this one they must be re-transmitted**
A ‘T20’ message means the CEG failed during the previous session (and thereby disconnected the user). This is extremely rare, but when it does occur, a user gets an AUTELS error message before the latest Transmission Report is received.
A Transmission Report ending with a ‘T20’ message must be treated as the last correct report. Transmission Reports from the same CEG having transmission numbers greater than this report must be disregarded.  Thus any messages sent to DIS which are referred to in Transmission Reports with numbers higher than the number of a report ending with a ‘T20’ message must be re-transmitted.
For example, if the transmission report ending with a ‘T20’ message is named TRANS_SY.123, but another previous transmission report already received by the user is named TRANS_SY.124, then all messages sent in transmission 124 have been lost and must be re-transmitted to the ATO.
Because there is a very small but nevertheless real risk that one or more whole transmissions received by DIS may be lost or damaged, users are advised to store at least the last three transmissions and the last three day’s transmissions.  DIS does not inform users, which messages have been, transferred from the CEG to the ATO internal processing systems, but is indicated indirectly.  When a transmission has been transferred from the CEG to an ATO internal processing system, the user no longer needs to store it on their system.

7.3	ELS Validation Reports
Validation reports are produced for ELS registered users only.
The Validation Report lists the messages that have been received by DIS and have been edit checked by the ELS validation process.  File names for Validation Reports have the form  VALID_ss.nnn, where  ss  is the CEG identifier and nnn is the transmission number assigned by dis. Developers who wish to process the data in Validation Reports should consult the ELS specification.
8	Testing Facilities For Software Producers
8.1	Overview
This chapter describes DIS facilities available to software producers to help them debug their software.
These facilities are available only on the National Office CEG and are not to be used by production users.
8.2	Test systems 
The test facility in Canberra runs three DIS test systems.  The lodgment service test systems are called G1 and G2.  The bulletin service test system is called NO.  Another test address G2/NO switches between G2 and NO to allow s/w developers to test a fall-over to a bulletin system when making a connection to a lodgment service, G1 is then available for secondary lodgment.  You may elect to cater for just one, two, or three secondary lodgment services.
 
ID	Purpose	IP address	Port	
G2	For s/w developer testing a connection to a lodgment service.	203.202.43.5	7586	
NO	For s/w developer testing a connection to a bulletin service.	203.202.43.6	7586	
G1	For s/w developer testing secondary lodgment.	203.202.43.7	7586	
G2/NO	For s/w developer testing a connection to a lodgment service which regularly switches to a bulletin service.	 203.202.43.8	7586	

The G2 system is the main lodgment service testing facility for software developers, but G1 is also available for lodgement (there are no introduced errors as there once was).
The NO system is provided for any tests to a bulletin service.  The bulletins provided by a bulletin service are static and do not change - they advise the client to try a secondary lodgement service.  The NO system does not operate as other DIS systems, it will accept any User ID and password and you cannot send files.  In production there is no requirement to connect to the NO system deliberately.  Direct access to NO is intended for software developers only.
The G2/NO address is provided so software can test that it will correctly identify when it has been switched to a bulletin service (NO) system rather than the lodgement service that was targeted (G2).  The G1 lodgment service is then available for secondary lodgment.
A suggested method of handling secondary lodgment is:
(a)	CHECK PAST LODGMENTS
Have lodgments been made to a secondary lodgment service for which transmission and/or validation reports have not been received?  If so try and connect to the specific secondary lodgment service where previous lodgment occurred to retrieve reports only.  
Go to step (b)  
(b)	CONNECT TO PRIMARY, CHECK SITE, LODGE
Attempt connection to primary lodgment service.  Check which system you are connected to from the Type 0 AUTELS string.  If connected to primary lodgment service lodge, then finish.  
Otherwise go to step (c).
(c)	CONSIDER SECONDARY LODGMENT
Your previous connection failed or you connected to a bulletin service.  Check whether more secondary lodgment services exist (you may limit secondary lodgment to one, two or three secondary lodgment services).  If secondary lodgment possible go to step (d).  If not inform user, then finish.
(d)	CONNECT TO SECONDARY, CHECK SITE, LODGE
Attempt connection to secondary lodgment service.  Check which system you are connected to from the Type 0 AUTELS string.  If connected to secondary lodgment service lodge, then finish.  
Otherwise go to step (c).
Please refer to 2.9 - Secondary lodgment for more information.

8.3	VT100 test functions
Eight functions for testing software are available during VT100 communications. These features are also available on production CEGs but users are advised not to use them.
These functions are available only in conjunction with the DIS Main Menu and are accessed by sending a control character and pressing the Return key, as described below:
<Ctrl R><CR>
This option causes the current screen to be resent by DIS. This is useful whenever data corruption in the communications line causes the screen to display strange characters, or if the screen is formatted incorrectly.
<Ctrl V><CR>
This option displays the current version number and latest modification date of the DIS software. This feature may be useful to software producers who are waiting for a software upgrade of DIS.
<Ctrl Y><CR>
This option causes the current password to expire. This enables software producers to test their packages without having to wait 30 days for the password to expire.
<Ctrl B><CR>
This option causes the current bulletin to be made available for the next download.  This enables software developers to test their handling of bulletins.
<Ctrl A><CR>
This option causes any old messages to be made available for the next download.  This enables software developers to test retrieval of files without sending additional files.
<Ctrl L><CR>
This option causes DIS to lock the user’s account for access from Dial IP.  At the next login an agreement will need to be displayed to the end user on the next login.  This enables software developers to test their handling of DIS agreement(s).
<Ctrl P><CR>
This option causes DIS to generate a D14 (password used before) error when the password is changed in AUTELS mode, even if the password has not been used before.  Note that the password is not changed when the D14 error is generated and manual mode will continue to operate normally.  Once the D14 error occurs, the system will return back to normal so each Ctrl P will only generate one D14 error.
<Ctrl I><CR>
This option causes DIS to generate a D15 (password is invalid) error when the password is changed in AUTELS mode, even if the password is a valid password.  Note that the password is not changed when the D15 error is generated and manual mode will continue to operate normally.   Once the D14 error occurs, the system will return back to normal so each Ctrl P will only generate one D15 error.

9	Appendices
9.1	Appendix A - Error messages
Modem error messages
These depend on the type of modem being used by the user and will need to refer to the operations manual of the modem or contact the vendor from where the modem is purchased.
DIS Error Messages
The following are the error message codes and causes that are produced by DIS:
D01 = Invalid User ID or password
The user has attempted to log in using a User ID that is not registered on the CEG, or has used a password that does not match the current password registered for that User ID.  This error can occur only at log-in.
D02 = This User ID is in use by someone else
Two users have attempted to log in to the same CEG using the same User ID (this is not allowed) or a user has attempted to log in before the previous session has been closed.  This error can only occur at log-in.
D03 = Too many failed log in attempts, account LOCKED
Six (6) consecutive unsuccessful log-in attempts have occurred under that User ID. The account has been locked, and the user must contact the ATO to unlock it and resolve the problem that caused the invalid log-in attempts. This error can occur only on log-in after the account has been locked.
D04 = ATO file system problem
An internal software problem has occurred in DIS.  A user seeing this message should immediately contact the ATO and report the problem. This error is unlikely to occur, but if it does occur, it is most likely that DIS has lost access to the ELS user profiles, with the result that no user can log in or change password.  This error can only occur at log in or password change.
D05 = Access to this account is locked
The user’s account has been locked due to too many unsuccessful attempts to log in.  The user must contact the ATO to unlock the account and resolve the problem. This error can only occur at log in when the account is locked.
D06 = Passwords do not match
May occur when a user attempts to change a password. Either the old password does not match the current password in DIS, or the two new passwords are not the same. This error can only occur when attempting to change the password.
D07 = ATO software error
This error occurs when there is a fatal software error in the DIS software.  It may occur at any time.
D08 = Protocol violation
Occurs when AUTELS method software sends an invalid response indicator for a particular State.
D09 = No response
No response has been received from a user’s system.  DIS has timed out.
D10 = Transmission error
A transmission error has occurred while connected. 
D11 = Account locked to Dial IP access
D12 = Invalid network calling address.  This will occur if the user uses a different ELS approval number for ATO Access Code 1 from what is used for the ELS login ID.
D13 = Checksum error
DIS has detected a checksum error in an AUTELS response indicator, most likely due to data corruption. The user’s system should resend the response indicator. This error can occur after an AUTELS message is sent.
D14 = Password has been used before
This error may occur if a user attempts to change a password, but uses a new password that has been used previously. This error can only occur when attempting to change the password.
D15 = Your password is invalid
This error may occur if a user attempts to change a password, but the new password is invalid. An invalid password is less than 12 or more than 16 characters long, or contains illegal characters, or does not have at least one alpha and at least one numeric character, or more than two characters, in the same position, of the old password exist in the new.  This error can only occur when attempting to change the password.
D16 = Parity error
An attempt has been made to log into DIS using incorrect parity.  This may be caused by a faulty modem or, more likely, by parity set incorrectly in the user's software.  Garbage sent to DIS can also cause this error.

9.2	Appendix B - Example of connection to CEG
03-13-2003 11:55:03 - Standard Modem in use.
03-13-2003 11:55:03 - Modem type: Standard Modem
03-13-2003 11:55:03 - Modem inf path: mdmgen.inf
03-13-2003 11:55:03 - Modem inf section: Gen
03-13-2003 11:55:03 - 57600,N,8,1
03-13-2003 11:55:03 - 57600,N,8,1
03-13-2003 11:55:03 - Initializing modem.
03-13-2003 11:55:03 - Send: AT<cr>
03-13-2003 11:55:03 - Recv: AT<cr>
03-13-2003 11:55:03 - Recv: <cr><lf>OK<cr><lf>
03-13-2003 11:55:03 - Interpreted response: OK
03-13-2003 11:55:03 - Send: ATE0V1<cr>
03-13-2003 11:55:03 - Recv: ATE0V1<cr>
03-13-2003 11:55:03 - Recv: <cr><lf>OK<cr><lf>
03-13-2003 11:55:03 - Interpreted response: OK
03-13-2003 11:55:03 - Send: ATX4<cr>
03-13-2003 11:55:03 - Recv: <cr><lf>OK<cr><lf>
03-13-2003 11:55:03 - Interpreted response: OK
03-13-2003 11:55:03 - Send: ATM0<cr>
03-13-2003 11:55:03 - Recv: <cr><lf>OK<cr><lf>
03-13-2003 11:55:03 - Interpreted response: OK
03-13-2003 11:55:03 - Waiting for a call.
03-13-2003 11:55:03 - Send: ATS0=0<cr>
03-13-2003 11:55:03 - Recv: <cr><lf>OK<cr><lf>
03-13-2003 11:55:03 - Interpreted response: OK
03-13-2003 11:55:03 - 57600,N,8,1
03-13-2003 11:55:03 - Initializing modem.
03-13-2003 11:55:03 - Send: AT<cr>
03-13-2003 11:55:03 - Recv: <cr><lf>OK<cr><lf>
03-13-2003 11:55:03 - Interpreted response: OK
03-13-2003 11:55:03 - Send: ATE0V1<cr>
03-13-2003 11:55:03 - Recv: <cr><lf>OK<cr><lf>
03-13-2003 11:55:03 - Interpreted response: OK
03-13-2003 11:55:03 - Send: ATX4<cr>
03-13-2003 11:55:03 - Recv: <cr><lf>OK<cr><lf>
03-13-2003 11:55:03 - Interpreted response: OK
03-13-2003 11:55:03 - Send: ATM0<cr>
03-13-2003 11:55:03 - Recv: <cr><lf>OK<cr><lf>
03-13-2003 11:55:03 - Interpreted response: OK
03-13-2003 11:55:03 - Dialing.
03-13-2003 11:55:03 - Send: ATDT#,##########<cr>
03-13-2003 11:55:30 - Recv: <cr>
03-13-2003 11:55:30 - Interpreted response: Informative
03-13-2003 11:55:30 - Recv: <lf>
03-13-2003 11:55:30 - Interpreted response: Informative
03-13-2003 11:55:30 - Recv: CONNECT 57600
03-13-2003 11:55:30 - Interpreted response: Connect
03-13-2003 11:55:30 - Connection established at 57600bps.
03-13-2003 11:55:30 - Error-control off or unknown.
03-13-2003 11:55:30 - Data compression off or unknown.
03-13-2003 11:55:36 - VPN client connected using the Test profile
03-13-2003 11:55:55 - connecting to 203.202.43.5 using port 7586
03-13-2003 11:55:55 - DIS Message received is : _[2J_[1;2H11:55 pm_[1;33H13 March 2003
			    _[1;71HThursday_[1m_[?7l_[1m_[2;1
			    H*****************************************************************
			    ***************_[4;21HAUSTRALIAN  TAXATION  OFFICE TEST G2
		          _[6;26HCORPORATE EXTERNAL GATEWAY_[0m_[8;28HOOO_[8;50H
                      This service is for ATO_[9;12HAAAA            OOOO_[9;50H
                      authorised clients only._[10;11HAAAAAATTTTTTTTTTTOOOOOO_[10;50H
                      By continuing, you are_[11;10HAAA AAATTTTTTTTTTTOOO OOO_[11;50H
                      representing yourself_[12;9HAAA  AAA    TTT    OOO  OOO_[12;50H
                      as an authorised user,_[13;8HAAA   AAA    TTT    OOO   OOO_[13;50H
                      and as such are bound_[14;7HAAAAAAAAAA    TTT    OOO    OOO_[14;50H
                      by the Terms of_[15;6HAAAAAAAAAAA    TTT    OOO     OOO_[15;50HParticipation.  
                      The_[16;5HAAA      AAA    TTT     OOO   OOO_[16;50Hsystem is monitored_[17;4H
                      AAA       AAA             OOOOOOO_[17;50
                      Hand any misuse will be_[18;32Hooooo_[18;50H
                      reported to the_[19;33HOOO_[19;50Happropriate authority._[20;34HO_[21;1H
                      **************Press Return key to log-in, or ESC to disconnect*******_*****G2,
03-13-2003 11:56:35 - Message sent to DIS is : *****5
03-13-2003 11:56:35 - DIS Message received is : %%%%%13 Mar 2003 11:56:35+
03-13-2003 11:56:38 - Message sent to DIS is : %%%%%A95001\
03-13-2003 11:56:38 - DIS Message received is : (((((13 Mar 2003 11:56:38=
03-13-2003 11:56:41 - Message sent to DIS is : (((((today1:
03-13-2003 11:56:41 - DIS Message received is : [[[[[13 Mar 2003 11:56:4124]
03-13-2003 11:56:41 - Message sent to DIS is : [[[[[*
03-13-2003 11:56:41 - DIS Message received is : 1111113 Mar 2003 11:56:41%
03-13-2003 11:56:43 - Message sent to DIS is : AAAAA&
03-13-2003 11:56:44 - DIS Message received is : -----13 Mar 2003 11:56:44S
03-13-2003 11:56:45 - Message sent to DIS is : -----13 Mar 2003 11:56:450 8test.zip      7946PK___
                      _ _ ¦am.               A95001_1.txtíÊ±	À _@Á>à(_HaPH§82B ?ÈÁ«‑—këñvÆ
                      (}ÄÕî'Žügr_Çq_Çq_Çq_Çq_Çq_Çq_Çq_Çq_Çq_ÇíâæWh.5PK__²Þ__S   "+  PK___ _ _ ¦am.
                                     A95001_2.txtíÊ±	À _@Á>à(_HaPH§82B ?ÈÁ«‑—këñvÆ(}ÄÕî'Žügr_Çq
                      _Çq_Çq_Çq_Çq_Çq_Çq_Çq_Çq_ÇíâæWh.5PK__²Þ__S   "+  PK___ _ _ ¦am.            
                         A95001_3.txtíÊ±	À _@Á>à(_HaPH§82B ?ÈÁ«‑— _   Txid‹st7
                      °004200Žst126370_²‚-M                  ?Œ _G? __ $|Œô@b~Æq>žÎŽy™%‰êÅ
                      Å_©É™‰9qQQQ¼\ PK__@_»ÿK   Q   PK___ _ _ _ ¦am.²Þ__S   "+      
                                   A95001_1.txtPK___ _ _ _ ¦am.²Þ__S   "+           
    ?   A95001_2.txtPK___ 
                      _ _ _ ¦am.²Þ__S   "+               __  A95001_3.txtPK___ _ _ _ ¦am.@_»ÿK   
                      Q   _             §_  TxidPK__    _ _ à   $_    
03-13-2003 11:56:45 - DIS Message received is : 2222213 Mar 2003 11:56:45.
03-13-2003 11:56:46 - Message sent to DIS is : BBBBB+
03-13-2003 11:56:46 - DIS Message received is : +++++13 Mar 2003 11:56:46010zipped.zip      361H
03-13-2003 11:56:46 - Message sent to DIS is : +++++M
03-13-2003 11:56:46 - DIS Message received is : 1111113 Mar 2003 11:56:46*
03-13-2003 11:56:51 - Message sent to DIS is : AAAAA&
03-13-2003 11:56:51 - DIS Message received is : -----13 Mar 2003 11:56:51Q
03-13-2003 11:56:51 - Message sent to DIS is : XXXXXZ 
03-13-2003 11:56:51 - DIS Message received is: &&&&&13 Mar 2003 11:56:51.
03-13-2003 11:56:51 - Disconnected from 203.202.43.5 port 7586
03-13-2003 11:56:52 - Recv: <cr>
03-13-2003 11:56:52 - Hanging up the modem.
03-13-2003 11:56:52 - Hardware hangup by lowering DTR.
03-13-2003 11:56:52 - Recv: <cr><lf>NO CARRIER<cr><lf>
03-13-2003 11:56:52 - Interpreted response: No Carrier
03-13-2003 11:56:52 - Send: ATH<cr>
03-13-2003 11:56:52 - Recv: <cr><lf>OK<cr><lf>
03-13-2003 11:56:52 - Interpreted response: OK
03-13-2003 11:56:52 - 57600,N,8,1
03-13-2003 11:56:52 - Initializing modem.
03-13-2003 11:56:52 - Send: AT<cr>
03-13-2003 11:56:52 - Hanging up the modem.
03-13-2003 11:56:52 - Send: ATZ<cr>
03-13-2003 11:56:52 - Recv: <cr><lf>OK<cr><lf>
03-13-2003 11:56:52 - Modem closed.

9.3	Appendix C - Single byte checksum
The AUTELS protocol (refer to Section 6.3—AUTELS message formats) uses a single character arithmetic checksum to enable error detection on messages.  A block check is done on the characters between, but not including, the Header and the Chk character.
Standard ASCII specifies a set of 7 bit codes, but most computers use 8 bits to store this information. The eighth bit is called the parity bit.
The following is the equation to calculate the checksum in C notation:
Chk = ((Sum + ((Sum & 192)/64)) & 63) + 32
Sum is type integer and equals the arithmetic sum of the ASCII values of the characters between, but not including, the Header and the Chk character in the message. The parity bit for all characters must be 0 (not set).
Chk is type char.
The following paragraphs are an example of calculating this checksum.
Using the following Type 1 action indicator message, (a fake one with an indicator of ABCDE) we will demonstrate how to calculate and use the checksum. 
Action indicator message = <Ctrl B>ABCDE0<CR>
sum = A + B + C + D + E = 335 Decimal
Although we are interested in obtaining a seven-bit ASCII character value at the end of the calculation, it requires the use of integer type (16 bits). The examples of the calculation are thus shown as 16 bit values.
Bits 7 and 8 of this value are then moved into a new register by ANDing 192 to the sum, for example (sum & 192)
		Binary	
	335		0	0	0	0	0	0	1	0	1	0	0	1	1	1	1	
AND	192	0	0	0	0	0	0	0	0	1	1	0	0	0	0	0	0	
   =	64	0	0	0	0	0	0	0	0	0	1	0	0	0	0	0	0	

This register is shifted right six places by dividing by 64, for example ((Sum & 192) /64):
		Binary	
	64	0	0	0	0	0	0	0	0	0	1	0	0	0	0	0	0	
DIV	64	0	0	0	0	0	0	0	0	0	1	0	0	0	0	0	0	
   =	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	

This is added to the original sum, for example (Sum +((Sum & 192)/64))
		Binary	
	335	0	0	0	0	0	0	0	1	0	1	0	0	1	1	1	1	
  +	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	
  =	336	0	0	0	0	0	0	0	1	0	1	0	1	0	0	0	0	

Only bits 1 - 6 are required so other bits are masked out by ANDing this to 63 to obtain a six bit value, for example ((Sum + ((Sum & 192)/64)) & 63)
		Binary	
	336	0	0	0	0	0	0	0	1	0	1	0	1	0	0	0	0	
AND	63	0	0	0	0	0	0	0	0	0	0	1	1	1	1	1	1	
  =	16	0	0	0	0	0	0	0	0	0	0	0	1	0	0	0	0	

This is then converted to a printable character by adding 32, for example ((Sum + ((Sum & 192)/64)) & 63) + 32
		Binary	
	16	0	0	0	0	0	0	0	0	0	0	0	1	0	0	0	0	
  +	32	0	0	0	0	0	0	0	0	0	0	1	0	0	0	0	0	
  =	48	0	0	0	0	0	0	0	0	0	0	1	1	0	0	0	0	

Chk = 48 Decimal	Which is the decimal value of ASCII character 0 (zero). 
Chk = ‘0’ ASCII
This value can be compared with the checksum character — the last character before <CR> — sent in the message.
Action indicator message = <Ctrl B>ABCDE0<CR>
In this example the checksums match which means the message has been received without errors.

9.4	Appendix D - Firewall configuration
Communications traffic for DIS requires the following access:
AnyConnect VPN Client with TCP transport mode:
	Port: 		443
AnyConnect VPN Client with UDP transport mode:
	Ports: 	500 & 4500

VPN concentrator addresses:
Required destination	    	DNS name				   IP address
Melbourne/Adelaide CEG:	elsvpn1.ato.gov.au			180.149.192.196

Sydney/Brisbane CEG:	elsvpn2.ato.gov.au			61.88.100.161

Test CEG systems access:	elsvpntest.ato.gov.au			203.202.40.129

Some firewalls also require that Cisco Systems AnyConnect VPN client and the developed software product are configured as having access allowed to these destinations.

Please note: The IP addresses which the DNS names point to may change.  But any such change will be advised to software developers and users well before it is made.
9.5	
Appendix E - Glossary
Here follows a list of terms which should be used to identify specific aspects of ELS communications operation to avoid confusion.

Phrase	Precise meaning	
ELS	The Electronic Lodgment Service is run by the ATO principally for the use of tax agents who wish to electronically transmit documents (since 1990).	
DIS	The Document Interchange System is the front-end (communications component) of ELS. 	
CEG	Corporate External Gateway – computer system provided by the ATO for electronic commerce.	
RSF	Registered Software Facility.  A Web site provided by the ATO for software developers,	
ELS Approval Number	The 5 digit numeric string provided by the ATO to all tax agents who wish to use ELS.	
Dial IP	Telstra private IP network purchased by the ATO for tax agent usage.  Can be accessed by asynchronous dial up modem or ISDN.	
Dial IP Network access number	Telephone number for Dial IP asynchronous modem access (0198 303 290).	
Dial IP Network User ID	Tax agent’s approval number preceded by ‘D’, e.g. D95001.  This User ID is used to identify you to the Dial IP network.	
Dial IP Network password 	Provided by the ATO.  This password authenticates a user to the Dial IP network when used in conjunction with the Dial IP Network User ID.	
ISP	Internet service provider (e.g.Telstra, Optus)	
Internet	Global network accessed by purchasing a rental plan from an ISP.  Can be accessed by asynchronous dial up modem, Broadband, ADSL, or ISDN. 	
Internet User ID	A unique identity assigned to you by your ISP.	
Internet password	This password authenticates a user to an ISP when used in conjunction with Internet User ID.	
Cisco VPN Client	The Cisco 3000 series VPN client is bundled as part of the software an ELS user installs in order to use the Dial IP and/or Internet networks.  It performs encryption and other security functions.	
ATO Access Code1	Provided by the ATO.  Tax agent’s approval number preceded by ‘V’, e.g. V95001.  This access code is used to identify you to the Cisco VPN Client.  It needs to be entered into your ELS software once.	
ATO Access Code2	Provided by the ATO.  This string authenticates a user for the Cisco VPN Client when used in conjunction with ATO Access Code1.  It needs to be entered into your ELS software once.	
ELS User Id	Provided by the ATO.  Tax agent’s approval number preceded by category, e.g. ‘A95001’.  Used to authenticate to the DIS application.  Note:  Dial IP Network User ID, ATO Access Code1, and ELS User ID must all be based on the same approval number.	
ELS Password	This string authenticates a user to the DIS application when used in conjunction with the ELS User Id.  This password must be changed at least every 30 days.	
Tax Agents helpdesk	A telephone service provided by the ATO to assist Tax Agents (13 72 86).