INTERNET DRAFT                           A. Cornish, INETCO Systems Ltd.
Category: Informational              M. Cox, Alcatel Australia Pty. Ltd.
Title: draft-cornish-qtp-03.txt            R. Neill, INETCO Systems Ltd.
                                          I. Palmer, Lucent Technologies
                                          A. Telfer, INETCO Systems Ltd.
                                       C. Wignell, CoSine Communications
                                                                C. Young
                                                            January 2002


                    Quick Transaction Protocol - QTP

Status of this Memo

   This document is an individual contribution for inclusion in public
   internet standards of the Internet Engineering Task Force.  Comments
   should be submitted to the qtp@inetco.com mailing list.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   QTP is a simple protocol for multiplexing short-duration connections
   over an arbitrary transport service such as UDP.  QTP is an open
   standard to allow dial-up Credit Authorization Terminals (CAT) or
   Point-Of-Sale (POS) terminals to connect into IP hosts.

   These transactions require fast connection times, efficient
   concentration of many sessions, fault tolerant operation, and the
   ability to transfer access network addressing (called and calling
   numbers) along with transaction data.



Cornish et. al.             expires July 2002                  [Page 1]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


Table of Contents

1. INTRODUCTION                                                        3
   1.1 Typical Application                                             3
   1.2 Protocol Requirements                                           4
   1.3 Other Approaches                                                4
   1.4 QTP Attributes                                                  5
   1.5 Specification of Requirements                                   6
   1.6 Terminology                                                     6
2. QTP FRAMEWORK                                                       7
3. QTP MESSAGE FORMAT                                                  9
   3.1 Message Header                                                  9
   3.2 Message Types                                                  11
4. DETAILED MESSAGE TYPES                                             12
   4.1 Call Request                                                   12
   4.2 Call Acknowledgement                                           14
   4.3 Call Reject                                                    16
   4.4 Clear Request                                                  17
   4.5 Clear Acknowledgement                                          19
   4.6 Status Request                                                 20
   4.7 Status Report                                                  22
   4.8 Data                                                           24
5. ATTRIBUTES                                                         25
   5.1 Attribute Header                                               25
   5.2 Attribute Classes                                              26
   5.3 Attribute List                                                 27
   5.4 Message Type / Attribute Matrix                                28
   5.5 Attribute Definitions                                          30
6. PROTOCOL OPERATION                                                 41
   6.1 Protocol Startup                                               41
   6.2 Call Request (incoming)                                        43
   6.3 Call Request (outgoing)                                        43
   6.4 Call Clearing (incoming)                                       44
   6.5 Call Clearing (outgoing)                                       44
   6.6 Status Request                                                 44
   6.7 Status Reporting                                               45
   6.8 Data Transfer                                                  45
   6.9 Exception Handling                                             47
7. TRANSPORT                                                          48
   7.1 QTP over UDP                                                   48
   7.2 QTP over TCP                                                   49
8. SECURITY CONSIDERATIONS                                            49
9. REFERENCES                                                         50
10. AUTHORS' ADDRESSES                                                51
11. FULL COPYRIGHT STATEMENT                                          52






Cornish et. al.             expires July 2002                  [Page 2]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


1.  INTRODUCTION

   This document describes the QTP interface that can be used to carry
   short duration transactions.

   QTP was created to address the specific need for a multi-session
   protocol to connect dial-up transaction terminal sessions to an IP
   host.


1.1.  Typical Application

   At the time of creation of this protocol, most existing Point-Of-Sale
   (POS) and Credit Authorization Terminal (CAT) devices connect to
   telephone or X.25 access networks.  In many cases, these transactions
   are routed to an IP-based Transaction Processor (TP).

   A simplified POS system includes:

                        +-<NAS>-+      +-<TP>
   <Terminal>--<Access>-|       |-<IP>-|
                        +-<NAS>-+      +-<TP>

   where:

   Terminal  is the CAT or POS terminal device
   Access    is an Access Network such as telephone or X.25
   NAS       is a Network Access Server
   IP        is an IP network (usually private and secured)
   TP        is an authorizing Transaction Processing host

   When a transaction occurs, a telephone or X.25 connection is
   initiated by a Terminal to a NAS.  The NAS answers the call and
   establishes a data connection.

   Once connected, the terminal sends the transaction request, and waits
   for a transaction response.  When received, the terminal may
   disconnect immediately, or send an acknowledgement prior to
   disconnecting.  Request and response messages rarely exceed 200
   octets.  The entire sequence takes only a few seconds.

   The NAS acts as an IP network gateway, and routes the transaction
   request through to a TP.  It also ensures the transaction response is
   returned to the appropriate terminal.

   The application logic in both the NAS and TP may use access network
   addressing (called and calling numbers) and the contents of the
   transaction message to route and process the transaction.



Cornish et. al.             expires July 2002                  [Page 3]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   While most calls are initiated by terminals in response to customer
   transactions, there are some cases where the TP initiates connections
   to terminals.  This mode is usually associated with the TP soliciting
   audit information from the terminals or downloading "hot card" lists
   to terminals.

   Due to the high availability requirements of production transaction
   systems, live NAS and TP hosts are essential.


1.2.  Protocol Requirements

   A protocol suitable for this application must address the following
   requirements.

   *  The number of terminals concentrated into a single host may be in
      the tens of thousands.

   *  Each transaction, including connection, data transfer and
      disconnection occurs in a few seconds.  The protocol must be
      efficient and low-latency.

   *  Data transfer must support asynchronous message transfer.  Either
      the terminal or TP may initiate data exchanges.

   *  Application-layer logic includes aggressive measures for error
      recovery if data is lost or corrupted.  It is undesireable for
      lower-level transport services to provide recovery mechanisms
      operating on longer timeouts.

   *  An outage during a peak retail time is intolerable.  The overall
      system must include provisions for fault tolerance.

   *  The access network source and destination addresses are correlated
      with the transaction data.  The protocol must transfer called and
      calling number along with transaction data.

   *  The application logic invokes specific error recovery mechanisms
      if the access network connection terminates.  The protocol must
      provide connection information.


1.3.  Other Approaches

   Alternate were considered prior to undertaking the creation of a new
   protocol.

   These were ruled out on the basis that they did not suitably address



Cornish et. al.             expires July 2002                  [Page 4]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   the problem space defined by this application.


1.3.1.  Mapping to TCP Connections

   It is possible to map access network connections to corresponding TCP
   connections.  Access network addressing may be carried in a header,
   or mapped to specific TCP ports.  If the access network connection is
   broken, the corresponding TCP connection is disconnected.

   This approach is common in small-scale transaction processing
   systems, but experience indicates it is not scalable to large
   applications.

   *  At peak connection arrival rates, the overhead associated with
      setting up TCP sessions becomes prohibitive.

   *  During peak usage, the TCP port number resource within a TP
      becomes exhausted.

   *  In the event of dropped or corrupted IP datagrams, TCP will
      undertake retransmission, potentially delivering a message well
      after the application logic has undertaken recovery.

   *  It is prohibitively expensive to secure each transient TCP
      connection using methods such as SSL or TLS.


1.3.2.  Vendor Protocols

   Several vendor protocols are widely used for these types of
   applications.  In particular, Hypercom and Visa each have proprietary
   protocols for which they have assigned TCP and UDP port numbers [2].

   QTP was created to provide a public and non-restrictive alternative
   to these approaches.


1.4.  QTP Attributes

   Key features of QTP are:

   *  Efficient connection setup;

   *  Transfers access network call information, including
      calling/called numbers and modem speed;

   *  Independent of access network type (telephone, ISDN, X.25,...);



Cornish et. al.             expires July 2002                  [Page 5]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   *  Operation over connectionless or connection-oriented transports;

   *  Efficient concentration of connections at very high call rates;

   *  Support for outgoing and incoming transaction initiation;

   *  Dynamic adjustment to congestion or server failures;


1.5.  Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [3].

1.6.  Terminology

   This document uses the following terms:

   CAT          Credit Authorization Terminal.

   FI           Financial Institution.

   IP           Internet Protocol.

   ISDN         Integrated Services Digital Network

   LCN          Logical Channel Number

   Message      A single complete QTP unit, including message header and
                attributes.

   POS          Point-Of-Sale.

   PSTN         Public Switched Telephone Network

   QTP Entity   The QTP software element on a QTP host.  A QTP Entity is
                responsible for all the QTP sessions between it and
                other QTP entities.

   QTP Host     The computing environment in which one or more QTP
                entities resides.

   QTP Session  One logical connection provided by QTP Entities between
                a single application endpoint on one host and single
                application endpoint on a remote QTP entity.

   QTP          Quick Transaction Protocol. The protocol as described in



Cornish et. al.             expires July 2002                  [Page 6]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


                this document.

   TCP          Transport Control Protocol

   UDP          User Datagram Protocol.


2.  QTP FRAMEWORK

   In this document, the following framework is used to describe the
   operation of QTP.  This framework is not intended to imply a design
   or implementation architecture.


        [Transaction Terminals]
              | | |     |
           +--------------+
           (    Access    )
           (   Networks   )
           +--------------+
              | | |     |
       +-----------------------+            +-----------------------+
       |  +----------------+   |            |  +-----------------+  |
       |  | Network Access |   |            |  |  Transaction    |  |
       |  | Application(s) |   |            |  |  Processing     |  |
       |  | Supporting     |   |            |  |  Application(s) |  |
       |  | Multiple       |   |            |  |  Serving many   |  |
       |  | Transaction    |   |            |  |  Transaction    |  |
       |  | Connections    |   |            |  |  Connections    |  |
       |  +----------------+   |            |  +-----------------+  |
       |      | | |     |      |            |      | | |     |      |
       |    Logical Channels   |            |    Logical Channels   |
       |      1 2 3     n      |            |      1 2 3     n      |
       |      | | |     |      |            |      | | |     |      |
       |    +-------------+    |            |    +-------------+    |
       |    |             |<-------------------->|             |    |
       |    | QTP Entity  |<--------QTP--------->| QTP Entity  |    |
       |    |             |<------Sessions------>|             |    |
       |    |  [Control]  |<-------------------->|  [Control]  |    |
       |  +---------------+-+  |            |  +---------------+-+  |
       |  |Transport Service|==|============|==|Transport Service|  |
       |  +-----------------+  |  Network   |  +-----------------+  |
       |     QTP Host A        |            |     QTP Host B        |
       |(Network Access Server)|            |(Transaction Processor)|
       +-----------------------+            +-----------------------+

   In this framework, QTP Host A and QTP Host B exist in a network.




Cornish et. al.             expires July 2002                  [Page 7]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   QTP Host A acts as a Network Access Server, concentrating connections
   from multiple Transaction Terminals arriving from one or more Access
   Networks.  QTP Host B acts as a Transaction Processor, responding to
   transaction messages from terminals.

   Each Host supplies a Transport Service for a QTP Entity, which
   permits QTP messages to be exchanged between hosts.

   Each QTP Entity contains a Control point responsible for call control
   and management functions for the QTP Entity.

   Higher level applications establish or accept QTP Sessions with
   remote applications.

   Each QTP Session is an independent logical connection between one
   specific channel on one QTP Entity and a specific channel on another
   QTP Entity.  Higher level applications access individual QTP Sessions
   using a Logical Channel Number on the local QTP Entity.  QTP Sessions
   are defined by the Logical Channel Numbers on both QTP Entities
   involved in the connection.

   QTP is independent of the underlying Transport Service.  The
   Transport Service may be connectionless or connection-oriented, and
   provide reliable or unreliable message delivery.



























Cornish et. al.             expires July 2002                  [Page 8]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


3.  QTP MESSAGE FORMAT

3.1.  Message Header

   Each QTP message includes a message header as described below.

   All numbers are unsigned and are in network byte order (i.e. big
   endian).

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version| Rsvd  |M|A|P|0| Type  |        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Source LCN           |       Destination LCN         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Message Identifier (opt)    |  Message Identifier Ack (opt) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Data/Control Attributes ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


   Version (bits 0 through 3)

        Protocol Version. Set to 0x1.

   Rsvd (bits 4 through 7)

        Reserved for future use. Must be zero.

   Message Identifier Flag (bit 8)

        Indicates that the Message Identifier field exists.

   Message Identifier Ack Flag (bit 9)

        Indicates that the Message Identifier Ack field exists.

   Message Priority Flag (bit 10)

        If zero (0), indicates the QTP message is of normal priority.
        If set to one (1), the QTP message is of high priority.

   Type (bits 12 through 15)

        The type of QTP message as in Section 3.2 of this document.





Cornish et. al.             expires July 2002                  [Page 9]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   Message Length (two octets)

        The length in bytes of the entire QTP message including header.

   Source LCN (two octets)

        A Logical Channel Number used to identify the specific QTP
        Session originating a QTP message.

        QTP Messages returned by the receiving QTP Entity to this LCN
        will be associated with the same higher-layer application
        endpoint.  This number need not have any direct relationship
        with respect to physical ports.

        Both the Source LCN and Destination LCN are required in a QTP
        Message to uniquely identify a specific QTP Session.

        When a QTP Session is disconnected, the LCN becomes invalid
        until a new QTP Session is established which involves that LCN.

        An LCN value of zero (0) MUST NOT be used as a transaction
        source, but MAY be interpreted as the Control point within the
        QTP Entity.

   Destination LCN (two octets)

        A Logical Channel Number used to identify the specific QTP
        Session on the destination QTP Entity.  This number need not
        have any direct relationship with respect to physical ports.

        Both the Source LCN and Destination LCN are required in a QTP
        Message to uniquely identify a specific QTP Session.

        When a QTP Session is disconnected, the LCN becomes invalid
        until a new QTP Session is established which involves that LCN.

        Except where otherwise noted in this document, an LCN value of
        zero (0) MUST NOT be used as a transaction destination, but MAY
        be interpreted as the Control point on the destination QTP
        Entity.

   Message Identifier (two octets)

        Present if the "Message Identifier Flag" is set in the QTP
        header.  This is a number which uniquely identifies the QTP
        message for the indicated QTP Session.

        If this is present, a message on the same QTP Session MUST be



Cornish et. al.             expires July 2002                 [Page 10]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


        returned which includes this value in the "Message Identifier
        Ack" field.

        Use of a Message Identifier in any message is optional.

        If two messages are received on the same QTP Session with the
        same Message Identifier value, then the second message MUST be
        discarded, and a Message Identifier Ack MUST be returned.

   Message Identifier Ack (two octets)

        Present if the "Message Identifier Ack Flag" is set in the QTP
        header.

        This field explicitly acknowledges reception of a QTP Message to
        the remote end of the QTP Session.

        The Message Identifier Ack field contains the same value as the
        Message Identifier field in the message being acknowledged.

   Data/Control

        The remainder of the QTP Message contains data and/or control
        information formatted as Attributes, as described in this
        document.

3.2.  Message Types

   The following QTP message types have been defined.

        Message Type             Type Code
        ------------             ---------
        Call Request                0x1
        Call Ack                    0x2
        Call Reject                 0x3
        Clear Request               0x5
        Clear Ack                   0x6
        Status Request              0x9
        Status Report               0xA
        Data                        0xD











Cornish et. al.             expires July 2002                 [Page 11]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


4.  DETAILED MESSAGE TYPES

4.1.  Call Request

   The QTP header for a Call Request message is as follows.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version| Rsvd  |M|0|P|0| Type  |        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Source LCN           |       Destination LCN (0)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Message Identifier (opt)    |       Attribute(s)...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Version
       0x1

   Message Identifier Flag
       Indicates whether the Message Identifier field exists.

   Message Identifier Ack Flag
       0

   Priority
       The message priority, normally zero (0).

   Type
       0x1 for Call Request

   Message Length
       The length in bytes of the entire QTP message including header.

   Source LCN
       A non-zero unique number identifying the logical connection
       associated with the QTP Session on the host initiating the Call
       Request message.

   Destination LCN
       Call Request messages MUST include a destination LCN value of
       zero (0).  This directs the Call Request message to the Control
       point on the destination QTP Entity.

       The Control point in the destination QTP Entity is responsible
       for assigning an LCN at the destination if and only if the Call
       Request is accepted and a Call Acknowledgement is returned.




Cornish et. al.             expires July 2002                 [Page 12]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   Message Identifier
       Use of a Message Identifier is OPTIONAL.  If a Message Identifier
       is included, the corresponding Call Acknowledgement or Call
       Reject message returned by the destination QTP Entity MUST
       include a matching Message Identifier Ack value.

       If a Message Identifier is not included, the corresponding Call
       Acknowledgement or Call Reject message MUST NOT include a Message
       Identifier Ack field.

   Attributes
       Multiple attributes are REQUIRED within a Call Request message,
       including sufficient information for transaction connection
       establishment.

       Valid Call Request attribute(s) are as described elsewhere in
       this document.


































Cornish et. al.             expires July 2002                 [Page 13]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


4.2.  Call Acknowledgment

   The QTP header for a Call Acknowledgment message is as follows.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version| Rsvd  |M|A|P|0| Type  |        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Source LCN           |       Destination LCN         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Message Identifier (opt)    |  Message Identifier Ack (opt) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Attribute(s)...
      +-+-+-+-+-+-+-+-+-+-+-+-+-

   Version
       0x1

   Message Identifier Flag
       Indicates whether the Message Identifier field exists.

   Message Identifier Ack Flag
       Indicates whether the Message Identifier Ack field exists.

   Priority
       The message priority, normally zero (0).

   Type
       0x2 for Call Ack.

   Message Length
       The length in bytes of the entire QTP message including header.

   Source LCN
       A returned Call Ack message MUST include a non-zero Source LCN
       value, which is to be used to identify the QTP Session for the
       remainder of the life of the QTP Session.

       This value is assigned upon acceptance of the QTP Session.

   Destination LCN
       Set to the Source LCN supplied in the originating Call Request
       message.

   Message Identifier
       Use of a Message Identifier is OPTIONAL.  If a Message Identifier
       is included, the receiving QTP Entity MUST respond with a



Cornish et. al.             expires July 2002                 [Page 14]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


       matching Message Identifier Ack field in a returned QTP message
       within the same QTP Session.

   Message Identifier Ack
       A Message Identifier Ack field MUST be present if the originating
       Call Request message included a Message Identifier field.

   Attributes
       Valid Call Ack attribute(s) are as described elsewhere in this
       document.









































Cornish et. al.             expires July 2002                 [Page 15]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


4.3.  Call Reject

   The QTP header for a Call Reject message is as follows.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version| Rsvd  |0|A|P|0| Type  |        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Source LCN  (0)      |       Destination LCN         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Message Identifier Ack (opt) |        Attribute(s)...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Version
       0x1

   Message Identifier Flag
       0.  The Call Reject message MUST NOT contain a Message
       Identifier, as the QTP Session becomes invalid after the Call
       Reject is issued.

   Message Identifier Ack Flag
       Indicates whether the Message Identifier Ack field exists.

   Priority
       The message priority, normally zero (0).

   Type
       0x3 for Call Reject

   Message Length
       The length in bytes of the entire QTP message including header.

   Source LCN
       A returned Call Reject MUST include a zero (0) Source LCN value.

   Destination LCN
       Set to the Source LCN supplied in the originating Call Request
       message.

   Message Identifier Ack
       A Message Identifier Ack field MUST be included if the
       corresponding Call Request message included a Message Identifier
       field.






Cornish et. al.             expires July 2002                 [Page 16]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   Attribute(s)
       Valid Call Reject attribute(s) are as described elsewhere in this
       document.

4.4.  Clear Request

   The QTP header for a Clear Request message is as follows.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version| Rsvd  |M|A|P|0| Type  |        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Source LCN           |       Destination LCN         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Message Identifier (opt)    |  Message Identifier Ack (opt) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Attribute(s)...
      +-+-+-+-+-+-+-+-+-+-+-+-+-

   Version
       0x1

   Message Identifier Flag
       Indicates whether the Message Identifier field exists.

   Message Identifier Ack Flag
       Indicates whether the Message Identifier Ack field exists.

   Priority
       The message priority, normally zero (0).

   Type
       0x5 for Clear Request

   Message Length
       The length in bytes of the entire QTP message including header.

   Source LCN
       The number indicating the QTP Session on the QTP Entity
       originating the Clear Request message.

   Destination LCN
       The number indicating the LCN on the remote QTP Entity, supplied
       by the remote QTP Entity as the Source LCN in either the Call
       Request or Call Acknowledge message.





Cornish et. al.             expires July 2002                 [Page 17]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   Message Identifier
       Use of a Message Identifier is OPTIONAL.  If a Message Identifier
       is included, the corresponding Clear Ack message MUST include a
       matching Message Identifier Ack value.  If a Message Identifier
       is not included, the corresponding Clear Ack message MUST NOT
       include a Message Identifier Ack field.

   Message Identifier Ack
       A Message Identifier Ack field MUST be included if the preceding
       message received from the remote QTP Entity involving the same
       QTP Session included a Message Identifier field.

   Attribute(s)
       Valid Call Reject attribute(s) are as described elsewhere in this
       document.




































Cornish et. al.             expires July 2002                 [Page 18]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


4.5.  Clear Acknowledgement

   The QTP header for a Clear Acknowledgement message is as follows.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version| Rsvd  |0|A|P|0| Type  |        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Source LCN           |       Destination LCN         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Message Identifier Ack (opt) |        Attribute(s)...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Version
       0x1

   Message Identifier Flag
       0.  The Clear Ack message MUST NOT contain a Message Identifier,
       as the QTP Session becomes invalid after the Clear Ack is issued.

   Message Identifier Ack Flag
       Indicates whether the Message Identifier Ack field exists.

   Priority
       The message priority, normally zero (0).

   Type
       0x6 for Clear Ack

   Message Length
       The length in bytes of the entire QTP message including header.

   Source LCN
       The number indicating the QTP Session on the QTP Entity
       originating the Clear Ack message.

   Destination LCN
       The number indicating the LCN on the remote QTP Entity, supplied
       by the remote QTP Entity as the Source LCN in either the Call
       Request or Call Acknowledge message.

   Message Identifier Ack
       A Message Identifier Ack field MUST be included if the
       corresponding Clear Request message included a Message Identifier
       field.





Cornish et. al.             expires July 2002                 [Page 19]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   Attribute(s)
       Valid Clear Ack attribute(s) are as described elsewhere in this
       document.


4.6.  Status Request

   Status Request messages are used to solicit Status Reports, as well
   as to deliver Status and Statistics attributes.  The QTP header for a
   Status Request message is as follows.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version| Rsvd  |M|0|P|0| Type  |        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Source LCN           |       Destination LCN         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Message Identifier (opt)    |        Attribute(s)...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Version
       0x1

   Message Identifier Flag
       Indicates whether the Message Identifier field exists.

   Message Identifier Ack Flag
       0

   Priority
       The message priority, normally zero (0).

   Type
       0x9 for Status Request.

   Message Length
       The length in bytes of the entire QTP message including header.

   Source LCN
       A non-zero number indicating the QTP Session number or zero (0)
       for the Control point on the originating QTP Entity.

       A source LCN value of zero (0) indicates that status is being
       requested by the Control point in the QTP Entity.  A non-zero
       source LCN value indicates that status is being requested by a
       specific QTP Session.




Cornish et. al.             expires July 2002                 [Page 20]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   Destination LCN
       Either zero (0) for the Control point on the destination QTP
       Entity, or a non-zero number indicating the LCN for an individual
       QTP Session on the remote QTP Entity.

       A destination LCN value of zero (0) indicates that global status
       is being requested from the Control point on the destination QTP
       Entity.  A destination LCN value which is non-zero indicates that
       status is being requested for a specific QTP Session.

   Message Identifier
       Use of a Message Identifier field is OPTIONAL.  If a Message
       Identifier is included, the corresponding Status Report message
       MUST include a matching Message Identifier Ack value.  If a
       Message Identifier is not included, a corresponding Status Report
       message MUST be returned, but MUST NOT include a Message
       Identifier Ack field.

   Attribute n
       Except as specified elsewhere in this document, Status and
       Statistics attributes delivered in a Status Request have the same
       meaning as if delivered in a Status Report.

       Valid Status Request attribute(s) are as described elsewhere in
       this document.


























Cornish et. al.             expires July 2002                 [Page 21]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


4.7.  Status Report

   Status Reports MAY be solicited via a Status Request, or MAY be
   unsolicited.  A Status Report MAY be used by a QTP Entity to
   advertise its level of availability.

   The QTP header for a Status Report message is as follows.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version| Rsvd  |0|A|P|0| Type  |        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Source LCN           |       Destination LCN         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Message Identifier Ack (opt) |       Attribute(s)...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version
       0x1

   Message Identifier Flag
       0.  The Status Report message MUST NOT contain a Message
       Identifier.

   Message Identifier Ack Flag
       Indicates whether the Message Identifier Ack field exists.

   Priority
       The message priority, normally zero (0).

   Type
       0xA for Status Report.

   Message Length
       The length in bytes of the entire QTP message including header.

   Source LCN
       A non-zero number indicating the QTP Session number or zero (0)
       for the Control point on the originating QTP Entity.

       A source LCN value of zero (0) indicates that status is being
       supplied by the Control point in the QTP Entity which supplies
       status for the entire QTP Entity.  A non-zero source LCN value
       indicates that status is being supplied for a specific QTP
       Session.





Cornish et. al.             expires July 2002                 [Page 22]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   Destination LCN
       A non-zero number indicating the QTP Session number or zero (0)
       for the Control point on the destination QTP Entity.

       A destination LCN value of zero (0) indicates that status is
       being supplied to the Control point on the destination QTP
       Entity.  A destination LCN value which is non-zero indicates that
       status is being supplied to a specific QTP Session.

   Message Identifier Ack
       A Message Identifier Ack field MUST be included if the
       corresponding Status Request message included a Message
       Identifier field.

   Attribute(s)
       Valid Status Report attribute(s) are as described elsewhere in
       this document.


































Cornish et. al.             expires July 2002                 [Page 23]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


4.8.  Data

   The QTP header for a Data message is as follows.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version| Rsvd  |M|A|P|0| Type  |        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Source LCN           |       Destination LCN         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Message Identifier (opt)    |  Message Identifier Ack (opt) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Attribute(s)...
      +-+-+-+-+-+-+-+-+-+-+-+-+-

   Version
       0x1

   Message Identifier
       Use of a Message Identifier field is OPTIONAL.  If a Message
       Identifier is included, a corresponding Data or Clear Request
       message MUST include a matching Message Identifier Ack value.

   Message Identifier Ack
       This is only included if a preceding Call Ack or Data message
       involving the same QTP Session was received which included a
       Message Identifier.

   Priority
       The message priority, normally zero (0).

   Type
       0xD for Data.

   Source LCN
       The number indicating the QTP Session on the QTP Entity
       originating the Data message.

   Destination LCN
       The number indicating the QTP Session on the QTP Entity to which
       the Data message is being sent.

   Attribute(s)
       Valid Data attribute(s) are as described elsewhere in this
       document.





Cornish et. al.             expires July 2002                 [Page 24]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


5.  ATTRIBUTES

   Attributes are used within QTP to pass additional information not
   contained in the QTP message header.

   Attributes MUST NOT be nested.  That is, attributes MUST NOT be put
   within attributes.

   Attributes are divided into two categories.  "Core Attributes"
   perform session establishment and clearing, data transfer, and status
   reporting operations.  Core Attributes are sufficient for transaction
   communication.  Within the set of Core Attributes, some are classed
   as REQUIRED and some classed as OPTIONAL.

   "Vendor Attributes" are provided as a means to extend QTP to address
   implementation specific capabilities included in commercial products.
   Support for Vendor Attributes is OPTIONAL.

5.1.  Attribute Header

5.1.1.  Core Attributes

   Each Core Attribute consists of a 16 bit attribute number in the
   range 0x0000 to 0x9FFF, a 16 bit length field (that includes the
   attribute number and length fields), and the attribute value as shown
   below.

   Numeric attribute values are in network byte order.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Core Attribute n            |      Attribute n Length       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Attribute n Value . . . . .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.1.2.  Vendor Attributes

   Each Vendor Attribute consists of a 16 bit attribute number in the
   range 0xA000 to EFFF, a 16 bit length field (including the entire
   attribute header), a 16 bit Vendor Identifier field, and the
   attribute value(s) as specified by the vendor.

   The Vendor Identifier value is assigned and managed by IANA as the
   "SMI Network Management Private Enterprise Codes" available from the
   IANA Protocol Numbers list [4].




Cornish et. al.             expires July 2002                 [Page 25]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   Numeric attribute values are in network byte order.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Attribute n         |      Attribute n Length       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Vendor ID          |  Attribute n Value . . . . .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


5.2.  Attribute Classes

   Core Attribute values have been grouped into five (5) classes related
   to the phase of the transaction and other "out-of-band" control
   activities.

   A range of attribute values are available for vendor specific
   extensions.

   The classes include:

   *  Reserved                   (class 0x00)

   *  Session Establishment      (class 0x01)

   *  Data Transfer              (class 0x02)

   *  Session Management         (class 0x03)

   *  Element Status             (class 0x04)

   *  Statistical Information    (class 0x05)

   *  Unassigned                 (class 0x06-0x9F)

   *  Vendor Specific            (class 0xA0-0xEF)

   *  Reserved                   (class 0xF0-0xFF)












Cornish et. al.             expires July 2002                 [Page 26]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


5.3.  Attribute List

   For each attribute value, the first 8 bits indicate the Attribute
   Class, and the remaining 8 bits indicate the member of the class.

       Attribute Name                 Attribute  Class   Member
                                        Value
       ------------------------------  -------  -------  -------
       *Session Establishment
       Called Party Address            0x0100    0x01     0x00
       Calling Party Address           0x0101    0x01     0x01
       Profile                         0x0102    0x01     0x02
       Speed                           0x0103    0x01     0x03
       Idle Time-out                   0x0104    0x01     0x04
       Max Message                     0x0106    0x01     0x06
       Called Party Subaddr            0x0108    0x01     0x08
       Calling Party Subaddr           0x0109    0x01     0x09
       Protocol Identifier             0x010B    0x01     0x0B
       Cust Group Identifier           0x010C    0x01     0x0C

       *Data Transfer
       Data                            0x0200    0x02     0x00
       Management Info                 0x0201    0x02     0x01
       Qualified Data                  0x0202    0x02     0x02
       Data Block                      0x0203    0x02     0x03
       Call Data                       0x0204    0x02     0x04

       *Session Management
       Cause                           0x0300    0x03     0x00
       Remote Cause                    0x0301    0x03     0x01

       *Element Status
       Flow Control                    0x0400    0x04     0x00
       Station Status                  0x0401    0x04     0x01
       Ping                            0x0402    0x04     0x02
       Call State                      0x0403    0x04     0x03

       *Statistical Information
       Num Messages Received           0x0500    0x05     0x00
       Num Messages Transmitted        0x0501    0x05     0x01
       Num Unacked Messages            0x0502    0x05     0x02
       Time Since Last Restart         0x0503    0x05     0x03









Cornish et. al.             expires July 2002                 [Page 27]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


5.4.  Message Type / Attribute Matrix

   The following matrix indicates the valid attributes which must be,
   may be, or must not be, used and the number of occurrences of each
   attribute permitted for each message type.

   -     Indicates Attribute MUST NOT be used in the corresponding
         Message Type.

   *     Indicates exactly zero (0) or one (1) instance of this
         Attribute MAY be used in the corresponding Message Type.

   1     Indicates exactly one (1) instance of this Attribute MUST be
         used in the corresponding Message Type.

   0+    Indicates zero (0) or more instances of this Attribute MAY be
         used in the corresponding Message Type.


































Cornish et. al.             expires July 2002                 [Page 28]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   Message Type     Call  Call  Call  Clear Clear Status Status  Data
                     Req   Ack Reject  Req   Ack    Req  Report
   ------------     ----  ----  ----  ----  ----   ----   ----   ----
                    0x01  0x02  0x03  0x05  0x06   0x09   0x0a   0x0D
   ------------     ----  ----  ----  ----  ----   ----   ----   ----
   Attributes:

   0x0100 CalledAddr  *     -     -     -     -      -      -      -
   0x0101 CallingAddr *     -     -     -     -      -      -      -
   0x0102 Profile     *     *     -     -     -      -      -      -
   0x0103 Speed       *     *     -     -     -      -      -      -
   0x0104 IdleTimeout *     *     -     -     -      -      -      -
   0x0106 MaxMsg      *     *     -     -     -      -      -      -
   0x0108 CalledSub   *     -     -     -     -      -      -      -
   0x0109 CallingSub  *     -     -     -     -      -      -      -
   0x010B Protocol ID *     *     -     -     -      -      -      -
   0x010C Cust GID    *     *     -     -     -      -      -      -

   0x0200 Data        *     *     -     *     -      -      -      *
   0x0201 Mgmt Info   *     *     -     *     -      -      -      *
   0x0202 Q Data      *     *     -     *     -      -      -      *
   0x0203 Data Block  -     -     -     -     -      -      -      *
   0x0204 Call Data   *     *     -     *     -      -      -      -

   0x0300 Cause       -     -     1     1     *      -      -      -
   0x0301 Rem Cause   -     -     *     *     *      -      -      -

   0x0400 Flow Cntrl  -     -     -     -     -      *      *      -
   0x0401 Stn Status  -     -     -     -     -      *      *      -
   0x0402 Ping        -     -     -     -     -      *      *      -
   0x0403 Call State  -     -     -     -     -      *      *      -

   0x0500 #MsgRxIF    -     -     -     -     -      *      *      -
   0x0501 #MsgTxIF    -     -     -     -     -      *      *      -
   0x0502 #Unack      -     -     -     -     -      *      *      -
   0x0503 Time        -     -     -     -     -      *      *      -















Cornish et. al.             expires July 2002                 [Page 29]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


5.5.  Attribute Definitions

   This section defines the format of each attributes.  The hexadecimal
   value of each attribute is shown in brackets after the attribute
   name.

5.5.1.  Called Party Address  (0x0100)

   This attribute specifies the access network address (i.e. telephone
   number) supplied by the call originator.

   For transaction terminal initiated calls, this is the number dialed
   to connect to the transaction processing host.

   For calls originated by the transaction processor, this is the number
   dialed to reach a specific transaction terminal.

   The attribute value is an ASCII string of up to 40 characters.  The
   default address family is E.164 [5].

   Support for this attribute is REQUIRED.

   The field may be used for other address families (such as X.25 or
   Frame Relay network addressing) with pre-arrangement by sender and
   receiver.  Per-call configuration of the address family is for
   further study.


5.5.2.  Calling Party Address  (0x0101)

   This attribute specifies the Calling Line Identity, indicating the
   access network address of the call originator.

   For transaction terminal initiated calls, this is the telephone
   number associated with the terminal.

   For calls originated by the transaction processor, this is the
   telephone number associated with the service under the control of the
   transaction processor.

   The attribute value is an ASCII string of up to 40 characters.  The
   default address family is E.164.

   Support for this attribute is REQUIRED.

   The field may be used for other address families (such as X.25 or
   Frame Relay network addressing) with pre-arrangement by sender and
   receiver.  Per-call configuration of the address family is for



Cornish et. al.             expires July 2002                 [Page 30]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   further study.


5.5.3.  Profile (0x0102)

   This attribute enables access providers to classify user connections,
   such as indicating the local modem configuration profile to be used
   in the connection.  Its value is an ASCII string of up to 40
   characters.

   Support for this attribute is OPTIONAL.

   The definition of standard strings associated with common device
   profiles is for further study.

5.5.4.  Speed (0x0103)

   This attribute specifies the speed of the connection at the access
   point.  This value may be used by transaction processing systems to
   adjust timeouts or pace data messages.

   Its value is a ASCII string of up to 10 characters indicating the
   speed in bits per second.

   The default value for this attribute is "2400".

   Support for this attribute is OPTIONAL.

5.5.5.  Idle Time-out Delay (0x0104)

   This attribute specifies the time for which the QTP Session will be
   maintained in the absence of any data traffic.  If it is exceeded,
   the connection MAY be cleared by either end of the QTP Session.

   The value is a 16 bit number indicating the idle timer delay in
   seconds.  A zero value disables the timer.

   If not specified, idle QTP Sessions MAY be disconnected by either end
   of a QTP Session according to local policies.

   Support for this attribute is OPTIONAL.

5.5.6.  Maximum Message Size (0x0106)

   This attribute specifies the maximum QTP message size supported by
   the sender of the attribute.

   The value is a 16 bit number indicating the message size in octets.



Cornish et. al.             expires July 2002                 [Page 31]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   The message size includes the QTP message header size and the sum of
   the sizes of all the message attributes.

   Support for this attribute is OPTIONAL.

5.5.7.  Called Party Subaddress (0x0108)

   This attribute specifies the access network subaddress for the
   destination of a connection.  For the default address family the
   attribute specifies an ISDN subaddress.  Use of other address
   families is for further study.

   The attribute value is an ASCII string of up to 20 characters.

   Support for this attribute is OPTIONAL.

5.5.8.  Calling Party Subaddress (0x0109)

   This attribute specifies the access network subaddress for the
   initiator of a connection.  For the default address family the
   attribute specifies an ISDN subaddress.

   The attribute value is an ASCII string up to 20 characters.

   Support for this attribute is OPTIONAL.

5.5.9.  Protocol Identifier (0x010B)

   This attribute identifies the protocol of the higher-level
   application data supplied by the sender.

   The value is an 8 bit number and is obtained from the IANA
   administered Protocol Number list [4].

   If not specified, the contents of the Data Attributes are unknown to
   the QTP Entity, and data transparency MUST be maintained.

   Support for this attribute is OPTIONAL.













Cornish et. al.             expires July 2002                 [Page 32]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


5.5.10.  Customer Group Identifier (0x010C)

   This attribute specifies a Customer Group with which a QTP Session is
   to be associated.  Selection and assignment of Customer Groups are
   the responsibility of higher-level management applications.

   The attribute value is an ASCII string of up to 20 characters.

   If not specified, a QTP Session is not associated with a Customer
   Group.

   Support for this attribute is OPTIONAL.

5.5.11.  Data (0x0200)

   This attribute identifies transaction data.

   The attribute value consists of a string of octets of arbitrary
   length.

   Support for this attribute is REQUIRED.

5.5.12.  Management Information  (0x0201)

   This attribute provides the ability to transfer unformatted control
   and response data between QTP Entities out-of-band from the
   transaction data.

   The attribute value is a string of octets of arbitrary length.

   Support for this attribute is OPTIONAL.

5.5.13.  Qualified Data (0x0202)

   This attribute identifies that the data is to be used for session
   management (e.g. X.29 control messages, QLLC XID's, etc.).

   The attribute value is a string of octets of arbitrary length.

   Support for this attribute is OPTIONAL.











Cornish et. al.             expires July 2002                 [Page 33]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


5.5.14.  Data Block (0x0203)

   This attribute identifies a beginning, intermediate or final data
   block for segmented data transfers where the data object exceeds the
   maximum size of a single Data Attribute.

   The attribute value consists of a block header followed by segmented
   data.  The contents of the data block header are as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S|F|          Reserved         |        Sequence Number        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Block Data ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Start Data Block Flag (bit 0)

        Set to 1 only on the first data message in a block.

   Final Data Block Flag (bit 1)

        Set to 1 only on the final data message in block.

   Reserved (bits 2 to 15)

        Set to 0.

   Sequence Number (bits 16 to 31)

        A sequence number for each data block.  The starting block in
        the sequence MUST have a sequence number of zero (0), and
        increment by one (1) for each subsequent Data Block Attribute
        until the final Data Block is sent.  The sequence number is
        included to enable the receiver to re-assemble the original data
        in the correct order.

   Block Data (bits 32 ...)

        The segmented data message, consisting of a string of octets of
        arbitrary length.

        Support for this attribute is OPTIONAL.






Cornish et. al.             expires July 2002                 [Page 34]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


5.5.15.  Call Data (0x0204)

   This attribute contains unformatted Call Data that is supplied by a
   calling or called entity during session establishment.

   The attribute value is a string of octets of arbitrary length.

   Support for this attribute is OPTIONAL.

5.5.16.  Cause  (0x0300)

   This attribute specifies a QTP Session release cause.

   The format of the Cause Attribute Value field is as follows:

   Cause Value    8 bits

      Broken down into Class and Member subfields as follows
      3 Bits (0-2) : Class
      5 Bits (3-7) : Member

   Diagnostic     8 bits

      This is an optional supplemental field that may be supplied.  The
      Diagnostic field MUST be present when an Information field is
      supplied.

      Use of this field is for further study.

   Information    An ASCII string of up to 40 characters.

      This optional field permits additional information to be supplied
      regarding the cause of a call clear or call reject.

5.5.16.1.  Cause Classes

   The following cause classes are used to separate causes.

   Protocol Error (%000)
      The cause class "Protocol Error" is used for situations where a
      message format is invalid, a message field is invalid, or an
      attribute is invalid.

   Procedure Error (%001)
      The cause class "Procedure Error" is used in situations in which
      there is an inconsistency between messages, or between fields
      within a message.




Cornish et. al.             expires July 2002                 [Page 35]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   Invalid Message (%010)
      The cause class "Invalid Message" is used when there are syntax
      errors within individual attributes, or when a required attribute
      is missing.

   Network (%011)
      The cause class "Network" is used if a network destination is not
      reachable.

   Resource (%100)
      The cause class "Resource" is used when a required communications
      system resource is not available.

   User (%101)
      The cause class "User" is used in situations where the higher-
      layer application disconnects or refuses to accept an incoming
      connection, or a management entity is disabling call completion.

   Reserved (%110 and %111)

5.5.16.2.  Cause Values

   The following table contains the list of valid Cause Values per
   Class.



























Cornish et. al.             expires July 2002                 [Page 36]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


       Class   Member                                Value
       -----   ------------------------------        -----
       %000 Protocol Error
               %00001  Unsupported Version           0x01
               %00010  Invalid Use Of Flag           0x02
               %00011  Invalid Message Type          0x03
               %00100  Invalid Message Length        0x04
               %00101  Invalid Source LCN            0x05
               %00110  Invalid Dest LCN              0x06
               %00111  Invalid Attribute             0x07
               %01000  Invalid Attribute Length      0x08

       %001 Procedure Error
               %00001  Invalid LCN Pair              0x21
               %00010  Invalid Attribute Usage       0x22
               %00011  Time-out                      0x23
               %00100  Unsupported Attribute         0x24

       %010 Invalid Message
               %00001  Bad Calling Party Number      0x41
               %00010  Bad Called Party Number       0x42
               %00011  Bad Profile                   0x43
               %00100  Bad Speed                     0x44
               %00101  Missing Attribute             0x45

       %011 Network
               %00001  Number Busy                   0x61
               %00010  No Network User Responding    0x62
               %00011  Destination Unreachable       0x63
               %00100  Synchronization Error         0x64
               %00101  Network Congestion            0x65

       %100 Resource
               %00001  No Channel Available          0x81
               %00010  SW Resources Unavailable      0x82
               %00011  Network Resource Unavailable  0x83

       %101 User
               %00001  Normal Clearing               0xA1
               %00010  Maximum Packet Size Exceeded  0xA2
               %00011  Flooding                      0xA3
               %00100  Out Of Order                  0xA4
               %00101  Invalid Response              0xA5
               %00110  User Not Responding           0xA6

       Support for the Cause attribute is REQUIRED.





Cornish et. al.             expires July 2002                 [Page 37]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


5.5.17.  Remote Cause  (0x0301)

   This attribute contains a release cause supplied by the remote device
   or network.  The Remote Cause Attribute is independent of the Cause
   Attribute generated by the QTP Entity.

   This attribute would be used to supply the Q.931 release cause
   supplied by an ISDN access network.

   The value is a string of octets of arbitrary length.

   Support for this attribute is OPTIONAL.

5.5.18.  Flow Control (0x0400)

   This attribute is a global state value which indicates the ability of
   a QTP Entity to service further transactions with a remote QTP
   Entity.

   The attribute value is an 8 bit number indicating:

       Value   Transaction Call State
       -----   ----------------------
       0x01    Available(REQUIRED)
       0x02    Partially Congested(OPTIONAL)
       0x03    Congested(OPTIONAL)
       0x04    Shutdown(REQUIRED)

   A Flow Control state of "Available" indicates a QTP Entity is
   operational, and able to accept new QTP Sessions.

   A Flow Control state of "Partially Congested" indicates a QTP Entity
   is nearing capacity, but remains able to accept new QTP Sessions.

   A Flow Control state of "Congested" indicates a QTP Entity is at
   capacity, and is unable to create new QTP Sessions.  QTP messages
   associated with already-connected QTP sessions will continue without
   interruption.

   A Flow Control state of "Shutdown" indicates a QTP Entity has
   restarted or shutdown.  In this state, a QTP Entity MUST NOT accept
   new QTP Sessions, and QTP Sessions in progress prior to entering
   "Shutdown" state must be immediately terminated.

   Support for the attribute and "Available" and "Shutdown" states is
   REQUIRED.  Support for the "Partially Congested" and "Congested"
   states is OPTIONAL.




Cornish et. al.             expires July 2002                 [Page 38]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


5.5.19.  Station Status (0x0401)

   This attribute indicates the Primary or Secondary role of the sending
   QTP Entity with respect to the receiving QTP Entity.  A QTP Entity
   can advertise itself to another QTP Entity as either a primary route
   choice, or a secondary ("hot standby") alternative.  In this way,
   standby hosts are available to process transactions during situations
   of overload or host failures.

   When there are multiple QTP Entities with which QTP Sessions may be
   connected, where one or more QTP Entities are Primary and one or more
   QTP Entities are Secondary, the Primary QTP Entities SHOULD be used
   as the first choice in route selection.

   If all Primary QTP Entities become unavailable, the Secondary QTP
   Entities MAY be used.

   The attribute value is an 8 bit number with one (1) indicating
   Primary and two (2) indicating Secondary.

   Support for the Station Status Attribute and Primary value is
   REQUIRED.  Support for the Secondary value is OPTIONAL.

5.5.20.  Ping (0x0402)

   This attribute is used to identify if a remote QTP Entity exists and
   to determine network timing.

   When present in a Status Request message, it represents an echo
   request.  It MUST be responded to in a QTP Status Report regardless
   of the ability of the receiving QTP Entity to accept QTP Sessions.

   When present in a Status Report message, it represents an echo
   response.  It MUST contain the value supplied in the preceding Status
   Request.

   This attribute MUST NOT be contained in an unsolicited Status Report.

   The attribute value is a string of octets of arbitrary length.

   Support for this attribute is OPTIONAL.

5.5.21.  Call State  (0x0403)

   This attribute is used to identify the local state of a QTP Session.






Cornish et. al.             expires July 2002                 [Page 39]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   The attribute value is an 8 bit number indicating:

       Value   Transaction Call State
       -----   ----------------------
       0x00    Disconnected
       0x01    QTP Call received
       0x02    QTP Call sent
       0x03    QTP Clear received
       0x04    QTP Clear sent
       0x05    QTP Connected

   Support for this attribute is OPTIONAL.

5.5.22.  Number Of Messages Received on an Interface  (0x0500)

   This attribute is used to indicate the number of QTP messages the QTP
   Entity has received.  The value of this attribute is a 32 bit number.

   Support for this attribute is OPTIONAL.

5.5.23.  Number Of Messages Transmitted on an Interface  (0x0501)

   This attribute is used to indicate the number of QTP messages the QTP
   Entity has sent.  The value of this attribute is a 32 bit number.

   Support for this attribute is OPTIONAL.

5.5.24.  Number Of Unacknowledged Messages (on the system)  (0x0502)

   This attribute is a global counter on a QTP Entity used to indicate
   the number of unacknowledged QTP messages identified by the system.
   The value of this attribute is a 32 bit number.

   Support for this attribute is OPTIONAL.

5.5.25.  Time Since Last Restart  (0x0503)

   This attribute specifies the period of time over which the statistics
   have been collected.  The value of the attribute is a 32 bit number
   indicating the time since last restart in seconds.

   Support for this attribute is OPTIONAL.









Cornish et. al.             expires July 2002                 [Page 40]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


6.  PROTOCOL OPERATION

   QTP is a symmetrical protocol.  QTP Sessions may be initiated by
   either QTP Entity, hence transaction connections can be originated by
   either transaction terminals or transaction processing applications.

   QTP may be used over either unreliable transports or over reliable
   transports.

   Unreliable transports may be acceptable for transaction data, but are
   not sufficient for passing call establishment and other control
   information.  For this reason, session establishment and status
   messages are defined in command / response pairs.

   The following sequences show protocol operation in some of the more
   common environments.  This does not preclude the use of the protocol
   in other environments.

6.1.  Protocol Startup

   There are two basic startup methods a QTP Entity can employ.  The
   selection will depend primarily on the nature of the underlying
   transport service.

6.1.1.  Quick Startup

   In Quick Startup mode, a QTP Entity starts in the "Available" Flow
   Control state.

   As soon as a transport layer is available, a QTP Entity may initiate
   or accept QTP Sessions.

   In some cases it may be advisable to solicit the status of the remote
   QTP Entity prior to initiating QTP Sessions, however it is not a
   requirement for startup.

   Quick Startup Scenario

      [QTP Entity A]                [QTP Entity B]

      <QTP Entity Startup>          <QTP Entity Startup>
      <or Transport layer>          <or Transport layer>
      <connection rcvd   >          <connection rcvd   >

      <Ready for   >                <Ready for   >
      <QTP Sessions>                <QTP Sessions>

   This method of startup is acceptable when the transport service



Cornish et. al.             expires July 2002                 [Page 41]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   provides reliable message delivery.

6.1.2.  Safe Startup

   In Safe Startup mode, a QTP Entity starts in a "Shutdown" Flow
   Control state.

   As soon as a transport layer is available, it periodically issues
   Status Requests with a Message Identifier, and containing the Flow
   Control Attribute with a value of "Shutdown".

   Upon receipt of the acknowledging Status Report, it periodically
   issues Status Requests with a Message Identifier, and containing the
   Flow Control Attribute with a value of "Available".

   Upon receipt of the acknowledging Status Report, it is completed
   startup and may proceed to establish or accept QTP Sessions.

   Safe Startup using Status Reports

      [QTP Entity A]                [QTP Entity B]

      <QTP Entity Startup>
      <or Transport layer>
      <failure detected  >

                    Status Request
                    M=1, MI=x
                    FlowCtrl=Shutdown
                    ---------------->
                                    <If already running   >
                                    <QTP Entity restarts  >
                                    <clearing QTP Sessions>

                    Status Report
                    A=1, MIA=x
                    <----------------

                    Status Request
                    M=1, MI=y
                    FlowCtrl=Available
                    ---------------->

                    Status Report
                    A=1, MIA=y
                    <----------------
      <Ready for   >
      <QTP Sessions>



Cornish et. al.             expires July 2002                 [Page 42]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   This method of startup is recommended when the transport service
   provides unreliable message delivery.

6.2.  Call Request (incoming)

   On receiving an incoming CALL SETUP from a dial-up line or other
   access network, the QTP Entity on the Network Access Server host
   initiates a QTP Call Request to the QTP Entity on the appropriate
   Server.

   The QTP Entity on the Server has the option of accepting the call
   with a Call Ack or rejecting it with a Call Reject.

   Call Acceptance

      [Terminal]        [Access Device]        [Server]

      CALL SETUP                      Call Request
      ------------------>             ---------------->
                                      Call Ack
                                      <----------------

   Call Rejection

      [Terminal]        [Access Device]        [Server]

      CALL SETUP                      Call Request
      ------------------>             ---------------->
                                      Call Reject
                                      <----------------

6.3.  Call Request (outgoing)

   QTP is a bi-directional protocol.  As such, the Transaction
   Processing host may also set up an outgoing call to a terminal
   through a dial-up line or other access network.  As in the incoming
   case, this Call Request may be accepted or rejected.  The Call
   Rejection will contain the reason why the call was not accepted.

   Call Acceptance

      [Terminal]        [Access Device]        [Server]

      CALL SETUP                      Call Request
      <------------------             <----------------
                                      Call Ack
                                      ---------------->




Cornish et. al.             expires July 2002                 [Page 43]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   Call Rejection

      [Terminal]        [Access Device]        [Server]

      CALL SETUP                      Call Request
      <------------------             <----------------
       (busy, reorder,                Call Reject
        no answer ...)                ---------------->


6.4.  Call Clearing (incoming)

   When the access network connection with the terminal is disconnected,
   or if the Network Access Server chooses to terminate the connection,
   a Clear Request will be generated from the Access Device indicating
   the call is cleared and the reason for the clear.  The Clear Request
   message may contain transaction data.

      [Terminal]        [Access Device]        [Server]

                                      Clear Request
      CALL CLEAR                      Cause=Normal Clr
      ------------------>             ---------------->
                                      Clear Ack
                                      <----------------

6.5.  Call Clearing (outgoing)

   A connection can be cleared at any time although normally this is
   only done if a transaction is complete.  In the case of a Server
   clearing the call the reason for clearing the call will be contained
   in the Clear Request message.  The Clear Request message may contain
   transaction data.

      [Terminal]        [Access Device]        [Server]

                                      Clear Request
      CALL CLEAR                      Cause=Normal Clr
      <--------------------           <----------------
                                      Clear Ack
                                      ---------------->

6.6.  Status Request

   Status messages may be requested by either QTP Entity involved in a
   QTP connection.





Cornish et. al.             expires July 2002                 [Page 44]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


      [Terminal]        [Access Device]        [Server]

                                      Status Request
                                      <----------------
                                      Status Report
                                      ---------------->

6.7.  Status Reporting

   Status Reports may be initiated by either QTP Entity in response to
   Status Requests, or without being solicited by a Status Request.
   These may be used as a "keep-alive" indication.

      [Terminal]        [Access Device]        [Server]

                                      Status Report
                                      <----------------

6.7.1.  Status Reporting on Flow Control State Change

   When the Flow Control state changes in a QTP Entity, is SHOULD
   immediately notify the remote QTP Entity via a Status Report
   including the Flow Control Attribute.

   Alternatively, it MAY send a Status Request which includes a Message
   Identifier and the Flow Control attribute.  This approach is
   recommended when the transport layer does not provide reliable
   message delivery.

6.8.  Data Transfer

   Data messages may be issued with or without a Message Identifier.  If
   absent, data messages are not acknowledged in any way.

   If present, the receiver is required to respond with an
   acknowledgement in the form of a Message Identifier Ack.

   The acknowledgements may be used for two purposes.  When the
   underlying transport service is not reliable, it provides feedback to
   the sender that a data message was successfully delivered.  Secondly,
   the receiver can withhold acknowledgements for the purpose of
   throttling a sender.

   Using data message acknowledgements is useful if the data ingress
   rate can exceed the egress rate at the data receiver, and the sender
   has the ability to source throttle the data originator.

   The following sequence indicates the operation of data messages which



Cornish et. al.             expires July 2002                 [Page 45]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   do not require acknowledgement.

   Incoming Data

      [Terminal]        [Access Device]        [Server]

      DATA                            Data (M=0)
      ------------------>             ---------------->

   Outgoing Data

      [Terminal]        [Access Device]        [Server]

      DATA                            Data (M=0)
      <--------------------           <----------------

   The following sequences indicates the operation of data messages
   which include the Message Identifier, and therefore require
   acknowledgement.

   For the Incoming Data example, Data messages from the QTP Entity on
   the Access Device includes the Message Identifier, and the Server
   responds with Message Identifier Acknowledgements.

   In the Outgoing Data example, Data messages from the QTP Entity in
   the Server requests acknowledgements, and the Access Device responds
   with Message Identifier Acknowledgements.

   Incoming Data

      [Terminal]        [Access Device]        [Server]

      DATA A, DATA B                  Data A (M=1,MI=w)
      ------------------>             ---------------->
      DATA a                          Data a (A=1,MIA=w)
      <------------------             <----------------
                                      Data B (M=1,MI=x)
                                      ---------------->
      DATA b                          Data b (A=1,MIA=x)
      <------------------             <----------------











Cornish et. al.             expires July 2002                 [Page 46]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   Outgoing Data

      [Terminal]        [Access Device]        [Server]

      DATA A                          Data A (M=1, MI=y)
      <--------------------           <----------------
      DATA a                          Data a (A=1,MIA=y)
      -------------------->           ---------------->
      DATA B                          Data B (M=1, MI=z)
      <--------------------           <----------------
      DATA b                          Data b (A=1,MIA=z)
      -------------------->           ---------------->

6.9.  Exception Handling

6.9.1.  No Response to Call Request

   If an initiator does not receive a response to a Call Request message
   within a timeout period, it MUST re-send the Call Request.  The
   recommended value for the timeout is two (2) seconds.  If the second
   attempt is unsuccessful, the higher-layer application should be
   notified of a connection request failure.

6.9.2.  No Response to Clear Request

   The originator of a Clear Request Message MAY enter a "Clear Ack
   Pending" state awaiting a Clear Ack message.

   In the event that the Clear or Clear Ack is lost, the QTP Entity
   originating the Clear Request message MUST resend the Clear Request
   message and release all transaction resources associated with that
   QTP Session.

6.9.3.  No Response to Data Message requiring Acknowledgement

   If an initiator does not receive an acknowledgement to a Data message
   requiring acknowledgement within a timeout period, the initiator MUST
   resend the original message.

   If the second message is also not acknowledged, the sender must clear
   the call and release all QTP Session resources.

6.9.4.  No Response to Status Request

   If an initiator does not receive a response to a Status Request
   message within a timeout period, it MAY re-send the Status Request.
   This may be repeated indefinitely.




Cornish et. al.             expires July 2002                 [Page 47]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   If a QTP Entity fails to receive one or more Status Reports in
   response to a Status Requests, it MAY declare the transport
   connection to be inoperative.

   In this event, a QTP Entity MUST terminate all QTP Sessions and
   attempt to restart.

6.9.5.  Remote QTP Entity Shutdown or Restart

   If a QTP Entity receives a QTP Status Report in which the Flow
   Control Attribute is "Shutdown" all QTP Sessions involving the
   Shutdown QTP Entity MUST be terminated.

7.  TRANSPORT

   QTP may operate over a connectionless or connection-oriented
   transport layer.

7.1.  QTP over UDP

   The following section addresses the operation of QTP over UDP [6]
   transport.

   UDP is preferable to TCP for short duration transactions as it does
   not include provisions for reliable message delivery.  This is well
   explained in Section 2.3 the RADIUS specification [7]


7.1.1.  Initialization

   Since UDP is connectionless and unreliable, the Safe Startup mode
   MUST be used.


7.1.2.  QTP Message Transfer and Message Size Restriction

   One or more QTP messages MAY be encapsulated into a single UDP
   datagram.  However, a QTP message MUST NOT be split over a UDP
   datagram boundary.

   The upper size limit of a QTP message carried over UDP is therefore
   restricted by the maximum UDP message size.

   Since this limit varies in different UDP drivers, implementions
   SHOULD allow the upper size limit to be restricted as a configuration
   option.

   A conservative value for the maximum QTP message size which should be



Cornish et. al.             expires July 2002                 [Page 48]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   supported by any driver and network is 512 bytes.

   If the end-to-end transaction application layer deals with unreliable
   message delivery, data messages MAY be sent without requiring QTP
   acknowledgements.

   If the application layer expects reliable message delivery, the QTP
   Message Identifier flag MUST be set for all Data messages, which
   requires a corresponding Message Identifier Acknowledgement for each
   Data message.

7.1.3.  Well Known UDP Port Number for QTP

   Source Port  2935 [2]
                Or other port number selected by the sender.

   Destination Port
                2935 [2]
                Or other UDP port number pre-configured and agreed upon
                between the sender and receiver.

7.2.  QTP over TCP

   The use of QTP over TCP [8] transport is for further study.


8.  SECURITY CONSIDERATIONS

   The QTP protocol is intended to connect transaction processing
   systems supplied by different vendors through an open interface.  In
   many cases, at least one of the QTP Entities will be a transaction
   processing host, which requires physical and logical isolation from
   untrusted network entities.  The QTP protocol is intended for use in
   the associated secured financial transaction networks.

   Use of QTP in public or unsecured network environments without
   careful security precautions is not recommended or expected due to
   the following risks:

   *  Inbound communication requests are serviced without authenticating
      the message source.  This potentially permits any device with
      network access to emulate a transaction network access server or a
      transaction processing host.

   *  Potentially sensitive transaction call information is sent in
      clear text which could be easily monitored and recorded.  This
      would include telephone numbers for transaction terminals and
      transaction processing hosts.



Cornish et. al.             expires July 2002                 [Page 49]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


   *  Transaction messages are sent in the form supplied by terminals,
      which are not always in encrypted form.  This may expose user's
      credit card numbers, bank account numbers and other sensitive
      financial information;

   Use of QTP is not precluded from use in other applications which may
   require transport through public or other untrusted networks.

   Securing QTP requires that the underlying transport make available
   encryption, integrity and authentication services for all QTP
   traffic.  This secure transport operates on the entire QTP packet and
   is functionally independent of QTP and the transaction data being
   carried by QTP.  Protecting the QTP packet stream via a secure
   transport does, in turn, also protect the transaction data within the
   QTP packets.

   The selection of a secure transport service is for further study.


9.  REFERENCES

     [1]  Bradner, S., "The Internet Standards Process -- Revision 3",
          BCP 9, RFC 2026, Harvard University, October 1996.
     [2]  IANA, "Port Numbers", http://www.iana.org/numbers.html
     [3]  Bradner, S., "Key words for use in RFCs to Indicate
          Requirement Levels", BCP 14, RFC 2119, Harvard University,
          March 1997.
     [4]  IANA, "Protocol Numbers", http://www.iana.org/numbers.html
     [5]  ITU-T, E.164, "The International Public Telecommunication
          Numbering Plan", May 1997.
     [6]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
          USC/Information Sciences Institute, August 1980.
     [7]  Rigney, et. al., "Remote Authentication Dial In User
          Service (RADIUS)", RFC 2138, Livingston, April 1997.
     [8]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793
















Cornish et. al.             expires July 2002                 [Page 50]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


10.  AUTHORS' ADDRESSES

      Allan Cornish
      INETCO Systems Limited
      201-3773 Still Creek Ave.
      Burnaby, B.C., V5C 4E2
      Canada
      Phone:    +1 604-451-1567
      Fax:      +1 604-451-1565
      Email:    allan_cornish@inetco.com

      Michael Cox
      Alcatel Australia Pty. Ltd.
      280 Botany Rd.
      Alexandria, NSW, 2015
      Australia
      Phone:    +61 2-9699-0044
      Fax:      +61 2-9690-5247
      Email:    Michael.Cox@alcatel.com.au

      Robert Neill
      INETCO Systems Limited
      201-3773 Still Creek Ave.
      Burnaby, B.C., V5C 4E2
      Canada
      Phone:    +1 604-451-1567
      Fax:      +1 604-451-1565
      Email:    robert_neill@inetco.com

      Ian Palmer
      Lucent Technologies
      79 Victoria Parade,
      Collingwood, Victoria
      Australia. 3066.
      Phone:    +61 3 8413 9022
      Fax:      +61 3 8413 9000
      Email:    ipalmer@lucent.com

      Angus Telfer
      INETCO Systems Limited
      201-3773 Still Creek Ave.
      Burnaby, B.C., V5C 4E2
      Canada
      Phone:    +1 604-451-1567
      Fax:      +1 604-451-1565
      Email:    angus_telfer@inetco.com





Cornish et. al.             expires July 2002                 [Page 51]

INTERNET DRAFT      Quick Transaction Protocol (QTP)        January 2002


      Cliff Wignell
      CoSine Communications
      Level 50, 120 Collins Street,
      Melbourne, Victoria
      Australia, 3000.
      Phone:    +61 3 9225 5288
      Fax:      +61 3 9225 5172
      Email:    cwignell@cosinecom.com

      Cameron Young
      19111 - 117A Ave.
      Pitt Meadows, B.C. V3Y 2R3
      Canada
      Phone:    +1 604-465-9100
      Fax:      +1 604-465-9149
      Email:    cn_young@attcanada.ca


11.  FULL COPYRIGHT STATEMENT

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."






Cornish et. al.             expires July 2002                 [Page 52]