Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 5024


ODETTE File Transfer Protocol 2.0

Part 4 of 4, p. 100 to 135
Prev RFC Part


prevText      Top      Up      ToC       Page 100 
Appendix A.  Virtual File Mapping Example

   This example demonstrates the mapping of a Virtual File into a
   sequence of ODETTE-FTP Data Exchange Buffers.

   Each line in this extract from 'The Rime of the Ancient Mariner' by
   Coleridge [RIME] is separated by CR-LFs in a file that is being
   transmitted as a T format file.

             It is an ancient Mariner,
             And he stoppeth one of three.
             "By thy long grey beard and glittering eye,
             Now wherefore stopp'st thou me?

             "The Bridegroom's doors are opened wide,
             And I am next of kin;
             The guests are met, the feast is set:
             May'st hear the merry din."

             He holds him with his skinny hand,
             "There was a ship," quoth he.
             "Hold off! unhand me, grey-beard loon!"
             Eftsoons his hand dropt he.

             He holds him with his glittering eye--
             The Wedding-Guest stood still,
             And listens like a three years; child:
             The Mariner hath his will.

             The Wedding-Guest sat on a stone:
             He cannot chuse but hear;
             And thus spake on that ancient man,
             The bright-eyed Mariner.

             The ship was cheered, the harbour cleared,
             Merrily did we drop
             Below the kirk, below the hill,
             Below the light-house top.

   The Exchange Buffers below were built from the above.  The top line
   of each represents the ASCII code, while the two lines below give the
   hexadecimal value.

   Note that:

     . The "D" at the beginning of each Exchange Buffer is the command

Top      Up      ToC       Page 101 
     . The "?" preceding each subrecord is the header octet (see the
       hexadecimal value).

     Exchange Buffer 1

     D?It is an ancient Mariner,..And he stoppeth one of three..."By

     t?hy long grey beard and glittering eye,..Now wherefore stopp'st

      ?thou me?...."The Bridegroom's doors are opened wide,..And I am

      ?next of kin;..The guests are met, the feast is set:..May'st he

     a?r the merry din."....He holds him with his skinny hand,.."Ther

     e? was a ship," quoth he..."Hold off! unhand me, grey-beard loon

     !?"..Eftsoons his hand dropt he.....He holds him with his glitte

     r?ing eye--..The Wedding-Guest stood still,..And listens like a

     t?hree years; child:..The Mariner hath his will.....The Wedding-

     G?uest sat on a stone:..He cannot chuse but hear;..And thus spak

     e? on that ancient man,..The bright-eyed Mariner.....The ship wa

Top      Up      ToC       Page 102 
     s? cheered, the harbour cleared,..Merrily did we drop..Below the

      .kirk, below the hill,..Below the light-house top...

Top      Up      ToC       Page 103 
Appendix B.  ISO 646 Character Subset

   |            |   7| 0   | 0   | 0   | 0   | 1   | 1   | 1   | 1   |
   |            | B -+-----+-----+-----+-----+-----+-----+-----+-----|
   |            | I 6|  0  |  0  |  1  |  1  |  0  |  0  |  1  |  1  |
   |            | T -+-----+-----+-----+-----+-----+-----+-----+-----|
   |            |   5|   0 |   1 |   0 |   1 |   0 |   1 |   0 |   1 |
   |            |----+-----+-----+-----+-----+-----+-----+-----+-----|
   |            |    |     |     |     |     |     |     |     |     |
   |            |    |     |     |     |     |     |     |     |     |
   |------------|    |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
   |    BIT     |    |     |     |     |     |     |     |     |     |
   | 4  3  2  1 |    |     |     |     |     |     |     |     |     |
   | 0  0  0  0 |  0 |     |     | SP  |  0  |     |  P  |     |     |
   | 0  0  0  1 |  1 |     |     |     |  1  |  A  |  Q  |     |     |
   | 0  0  1  0 |  2 |     |     |     |  2  |  B  |  R  |     |     |
   | 0  0  1  1 |  3 |     |     |     |  3  |  C  |  S  |     |     |
   | 0  1  0  0 |  4 |     |     |     |  4  |  D  |  T  |     |     |
   | 0  1  0  1 |  5 |     |     |     |  5  |  E  |  U  |     |     |
   | 0  1  1  0 |  6 |     |     |  &  |  6  |  F  |  V  |     |     |
   | 0  1  1  1 |  7 |     |     |     |  7  |  G  |  W  |     |     |
   | 1  0  0  0 |  8 |     |     |  (  |  8  |  H  |  X  |     |     |
   | 1  0  0  1 |  9 |     |     |  )  |  9  |  I  |  Y  |     |     |
   | 1  0  1  0 | 10 |     |     |     |     |  J  |  Z  |     |     |
   | 1  0  1  1 | 11 |     |     |     |     |  K  |     |     |     |
   | 1  1  0  0 | 12 |     |     |     |     |  L  |     |     |     |
   | 1  1  0  1 | 13 |     |     |  -  |     |  M  |     |     |     |
   | 1  1  1  0 | 14 |     |     |  .  |     |  N  |     |     |     |
   | 1  1  1  1 | 15 |     |     |  /  |     |  O  |     |     |     |

Top      Up      ToC       Page 104 
Appendix C.  X.25 Specific Information

   The International Organization for Standardization (ISO) Open Systems
   Interconnection (OSI) model is the basis for ODETTE-FTP.

   ODETTE-FTP covers levels 4 to 7, and originally CCITT X.25 was the
   only recommended telecommunication protocol for OSI's layers 1, 2, 3.

    ISO Reference Model:

          +------------------------------+  <====  File Service
          | Level-7  FTP    application  |
          | Level-6  FTP    presentation |
          | Level-5  FTP    session      |
          | Level-4  FTP    transport    |
          |------------------------------|  <====  Network Service
          | Level-3         X.25         |
          | Level-2         X.25         |
          | Level-1         X.25         |

C.1.  X.25 Addressing Restrictions

   When an X.25 call is made over a PSDN, the Network User Address (NUA)
   of the destination must be specified in order that the PTT may route
   the call.  The call placed is directed to the termination equipment
   upon the user's premises.

   It is possible to provide extra information in the Call Request
   Packet in addition to the mandatory NUA required by the PTT.

   This extra information may be of 2 kinds:

    (a) A subaddress:

       It is simply an extension to the address and it is put into the
       called address field of the Call Request Packet.  This
       information (Address + Subaddress) is taken from the destination
       address field of the F_CONNECT_RQ; therefore, from the user's
       point of view, there is no distinction between the main address
       and subaddress parts.

Top      Up      ToC       Page 105 
    (b) User data:

       There is no standard for user data.  Moreover, there is no
       information in the F_CONNECT_RQ from which the ODETTE-entity may
       derive user data to be put in the N_CONNECT_RQ; therefore, user
       data shall not be used.

C.2.  Special Logic

   The SSID field SSIDSPEC specifies whether special logic must be
   applied (Y (yes) or N (no)) to the Data Exchange Buffer before the
   ODETTE-FTP moves the data into the NSDU (Network Service Data Unit)
   and passes control to the Network Service.

C.2.1.  When Special Logic Is Not To Be Used

   This logic is not applied to SSRM and SSID commands.

C.2.2.  The Need for "Enveloping" Exchange Buffers

   The "special-logic" parameter was created in order to allow the use
   of ODETTE-FTP over asynchronous links.  The "special-logic" could be
   needed to enable terminals to access an X.25 network via an
   asynchronous entry (through a PAD: Packet Assembly / Disassembly).
   The "special-logic" is not needed in case of a whole X.25 connection.
   This "special-logic" realises a CRC function in order to detect
   errors due to the asynchronous medium.

   Negotiation of the "special-logic" parameter in the SSID command is
   as follows:

           SSID                                       SSID

           special-logic=yes --------------------->

              <------------------------------------   special-logic=yes
              <------------------------------------   special-logic=no

           special-logic=no ---------------------->

              <------------------------------------   special-logic=no

   This logic is activated when the "special-logic" parameter in the
   SSID specifies Y (yes).

Top      Up      ToC       Page 106 
   Special logic processing, when activated, will function within level
   4 of the OSI model.

          +------------------------------+  <====  File Service
          | Level-7  FTP    application  |
          | Level-6  FTP    presentation |
          | Level-5  FTP    session      |
          | Level-4  FTP    transport    |
          |------------------------------|  <====  Network Service
          | Level-3         X.25         |
          | Level-2         X.25         |
          | Level-1         X.25         |

C.2.3.  Responsibilities of Special Logic

   When transmitting an Exchange Buffer and special logic is active,
   layer 4 will wrap the Exchange Buffer in synchronization and
   delineation characters, then protect the data integrity by means of a
   block checksum (BCS).  When receiving an Exchange Buffer and special
   logic is active, layer 4 will remove such things as synchronization
   and delineation characters, etc., before passing the Exchange Buffer
   to the higher layers.

C.2.4.  Extended Exchange Buffer Format

   Each envelope has a 1-byte header prefixed to it, and a 2-byte
   checksum appended to the end.  The checksum is derived in a manner
   specified in the ISO DIS 8073 TRANSPORT LAYER documentation.

Top      Up      ToC       Page 107 
   The layout of the data buffer will be structured as follows:

   | S | B |                                                  | B | C |
   | T | S |         COMPLETE EXCHANGE BUFFER (CEB)           | C | / |
   | X | N |                                                  | S | R |
     A   A                                                      A   A
     |   |                                                      |   |
     |   +-------------  Block sequence number                  |   |
     |                                                          |   |
     +-----------------  Synchronization character              |   |
                                                                |   |
                         Block checksum  -----------------------+   |
                         Delineation character  --------------------+

   The envelope is initialised with an STX and the checksum variables
   are set to 0.  The leading STX is not protected by the checksum
   calculation but is explicitly protected by a character compare at the
   receiver's end.  The Exchange Buffer is processed character by
   character.  As each character is removed from the Exchange Buffer, it
   is put through the checksum calculation and then, prior to its
   insertion in the envelope, it is put through the Shift-out
   transparency logic, which will result in either one or two characters
   being inserted.  When the contents of the Exchange Buffer have been
   entirely processed, then the checksum variables are brought up to
   date by inserting two X'00's through the checksum calculator and the
   two resultant checksum characters forwarded to the Shift-out
   transparency logic for insertion into the envelope.  Finally, a
   carriage return (CR) is appended to the envelope.  The segment is now
   ready for transmission to line.

   Upon receipt of a valid envelope that has the correct sequence
   number, the host should increment his sequence number register ready
   for the next transmission.

   The receiver will initialise his receiving buffer area upon receipt
   of an STX character, place the STX at the beginning of the buffer,
   and reset checksum variables.  All subsequent characters are
   processed using Shift-out logic before they are inserted into the
   buffer, at which point they will NOT be processed by the checksum
   calculator, although the character following the Shift-out (after
   subtracting X'20') will be.  The checksum characters themselves will
   be processed by the checksum calculator by virtue of the design of
   the checksum algorithm.

Top      Up      ToC       Page 108 
C.2.5.  Error recovery

C.2.5.1.  Mechanism

   The error correction scheme is implemented by the definition of three
   timers and the use of an ASCII NAK (Negative Acknowledgement)
   character followed by a C/R.  The <NAK><C/R> will flow between the
   two session partners, but only as a consequence of previous bad data.

   A user of the error recovery correcting extension must always work
   with a credit value of 1.  This can be forced upon any session
   partner at SSID negotiation.  The effect will be to force a simple
   half-duplex flip-flop protocol.

   Upon receipt of a bad block, send <NAK><C/R> to the session partner.

   Upon receipt of a <NAK><C/R>, a session partner should retransmit the
   last block in its entirety.

C.2.5.2.  Timers

   The majority of error conditions will be detected by a bad BCS
   sequence.  However, certain conditions cannot be so detected.  For
   example, a corrupt C/R will mean that the receiver will not know that
   the end of a block has been reached.  No matter how long he waits, no
   more data will come from the sender.  Thus, a timer is the only way
   to detect this type of corruption.  There are three timers needed to
   detect all possible malignant conditions of this type.

     T1 - Exchange Buffer Time Out (Inactivity or Response)
     T2 - Inter Character Time Out
     T3 - Data Carrier Detect Loss Time Out

   The three timers are in addition to the timer defined in the original


     Used to detect a high-level block Time Out, e.g., the Time Out
     between an SFID and its associated SFPA or SFNA response.

      Started - It is started after the last character of an exchange
                buffer has been sent to the line.

      Stopped - It is stopped when an STX has been received.

      Expiry  - Retransmit the whole block again, until such time as the
                retry limit has been reached.

Top      Up      ToC       Page 109 

     Used to detect errors in the reception of individual characters.

      Started - For an asynchronous entity, it is started upon receipt
                of each character while in synchronisation mode.  For an
                X.25 entity, it is started after a received block that
                did not terminate an Exchange Buffer.

      Stopped - Upon receipt of the next character.

      Expiry  - Send a <NAK><C/R>, drop out of synchronised mode, and go
                back and listen to line.


     Used by an asynchronous entity only and is used to detect a
     temporary carrier failure.

      Started - When DCD (Data Carrier Detect) is lost.

      Stopped - When DCD is regained.

      Expiry  - Disconnect the session.

C.2.5.3.  Types of Error

   Data corruption when it occurs can be categorised in one of five


    In this situation the STX is not seen and synchronisation is not
    achieved.  The terminating C/R is received out of synchronisation
    and hence the block is not seen by the receiver.  A <NAK><C/R> is
    transmitted to the sender to indicate this.  The sender should then
    retransmit the last block (each implementation will need to set a
    retry limit to be used for the number of consecutive times it
    attempts to retransmit a block -- a default limit of 5 is
    recommended).  All data received outside synchronisation (except
    <NAK><C/R>) are ignored.

Top      Up      ToC       Page 110 
        (A)                                    (B)

    Dropped Start of Text (STX)

          |   | B |         | B | C |
     -----|   | S |  CEB    | C | / |----->  Not sync
          |   | N |         | S | R |

                   | N | C |
             <-----| A | / |-----            Not sync
                   | K | R |

    Exchange Buffer Resent

          | S | B |         | B | C |
     -----| T | S |  CEB    | C | / |----->  Sync
          | X | N |         | S | R |


    This situation manifests itself as an extended period of
    synchronisation with no activity.  The T2 timer will detect this

        (A)                                    (B)

    Corrupt Carriage Return

          | S | B |         | B |   |
     -----| T | S |  CEB    | C |   |----->  No activity
          | X | N |         | S |   |

                   | N | C |                 T2
             <-----| A | / |-----            Timed out
                   | K | R |

Top      Up      ToC       Page 111 
    Exchange Buffer Resent

          | S | B |         | B | C |
     -----| T | S |  CEB    | C | / |----->  Sync
          | X | N |         | S | R |

   (3) BAD DATA

    In this situation, the receiver is unable to tell whether the error
    is bad data or bad BCS.  In either case, the response is to discard
    the Exchange Buffer and send a <NAK><C/R>.

        (A)                                    (B)

    Bad Data/BCS

          | S | B |         | B | C |        Bad data
     -----| T | S |  "%!    | C | / |----->  detected
          | X | N |         | S | R |

                   | N | C |
             <-----| A | / |-----            Discard Block
                   | K | R |

    Exchange Buffer Resent

          | S | B |         | B | C |
     -----| T | S |  CEB    | C | / |----->  Data OK
          | X | N |         | S | R |


    A circular sequential number (0 up to and including 9) is assigned
    to transmitted Exchange Buffers.  This is to aid detection of
    duplicate or out-of-sequence Exchange Buffers.  Once a duplicate
    block is detected, the Exchange Buffer in question is discarded.
    Once an out of sequence block is detected, this should result in a
    protocol violation.

Top      Up      ToC       Page 112 
    Example protocol sequence:

        (A)                                    (B)

    Exchange Buffer Being Sent

          | S |   |         | B | C |        Expecting
     -----| T | 0 |  EERP   | C | / |----->  BSN=0
          | X |   |         | S | R |        Transmission

    Exchange Buffer Being Sent

          | S |   |         | B | C |        Response to
     <----| T | 0 |  RTR    | C | / |-----   Previous
          | X |   |         | S | R |        Block

    Exchange Buffer Being Sent

          +-------------------------+        Expecting
          | S |   |         | B | C |        BSN=1 (Block
     -----| T | 1 |  SFID   | C | / |- // -> lost in
          | X |   |         | S | R |        Transmission)
          +-------------------------+        T1 Timed Out

    Exchange Buffer Being Sent

          | S |   |         | B | C |        Send last
     <----| T | 0 |  RTR    | C | / |-----   Block
          | X |   |         | S | R |        again

    Discard Block
    and start
    Timer T1

    T1 Timed Out

Top      Up      ToC       Page 113 
    Exchange Buffer Resent

          | S |   |         | B | C |        Expecting
     -----| T | 1 |  SFID   | C | / |----->  BSN=1
          | X |   |         | S | R |        Block OK

    Exchange Buffer Being Sent

          | S |   |         | B | C |        Response
     <----| T | 1 |  SFPA   | C | / |-----   BSN=1
          | X |   |         | S | R |        Block OK

    Exchange Buffer Being Sent

          | S |   |         | B | C |
     -----| T | 2 |  DATA   | C | / |----->  Data OK
          | X |   |         | S | R |

   Note: A credit value of 1 must be used to guarantee half-duplex

C.2.6.  Sequence of Events for Special Logic Processing

   The following functions will be executed in sequence:

   1. Calculation of the Block Sequence Number (BSN):

      BSN is set to zero by SSID.  First block will be sent with value
      zero.  Value of BSN is increased by one for each data buffer to be
      transmitted.  When BSN value exceeds 9, counter will be reset to

      Format: numeric/1 pos.

   2. Calculation of the Block Checksum (BCS):

      Calculation is done as specified in the ISO DIS 8073 TRANSPORT
      LAYER document.

      Format: binary/2 pos.

Top      Up      ToC       Page 114 
   3. Shift-out transparency  (See TRANSMIT/RECEIVE logic.)

      To avoid appearance of any control characters in the data stream,
      all the characters of the extended Exchange Buffer (with exception
      of the STX and carriage return characters enveloping the buffer)
      are put through a Shift-out logic, which result in a character
      being inserted (SO) and adding hex value '20' to the control

   4. The carriage return is inserted at the end of the data buffer.

   Note: After adding STX, BSN, BCS, CR, and SO-logic, the data buffer
         may exceed the Data Exchange Buffer size.

C.2.7.  Checksum Creation Algorithm

   These follow the ISO DIS 8073 TRANSPORT LAYER standard.


     The following symbols are used:

     C0,C1   Variables used in the algorithm
     L       Length of the complete NSDU
     X       Value of the first octet of the checksum parameter
     Y       Value of the second octet of the checksum parameter


     Addition is performed in one of the two following modes:

       a) modulo 255 arithmetic
       b) one's complement arithmetic in which if any of the variables
          has the value minus zero (i.e., 255) it shall be regarded as
          though if was plus zero (i.e., 0).


     . Set up the complete NSDU with the value of the checksum parameter
       field set to zero.

     . Initialise C0 and C1 to zero.

     . Process each octet sequentially from i=1 to L by

         a) adding the value of the octet to C0, then
         b) adding the value of C0 to C1.

Top      Up      ToC       Page 115 
     . Calculate X and Y such that

            X = C0 - C1
            Y = C1 - 2*C0

     . Place the values X and Y in the checksum bytes 1 and 2,

C.2.8.  Algorithm for checking checksum parameters

     . Initialise parameters C0 and C1 to zero.

     . Process each octet of NSDU sequentially from i=1 to L by

         a) adding the value of the octet to C0, then
         b) adding the value of C0 to C1.

     . If, when all the octets have been processed, either or both C0
       and C1 does not have the value zero, then the checksum formulas
       have not been satisfied.

     Note that the nature of the algorithm is such that it is not
     necessary to compare explicitly the stored checksum bytes.

C.2.9.  Shift-out Processing

       (Transparency for all control characters)

    TRANSMIT LOGIC  (values SO: X'0E' or X'8E')

     Buffer(1), ... , (n) is a character in the buffer to be sent.

     FOR i=1 to n                    /* for all octets of the buffer */

         IF    ((buffer(i)  &  X'7F')  <  X'20')

         THEN  output (SO)
               output (buffer(i)  +  X'20')

         ELSE  output (buffer(i))

Top      Up      ToC       Page 116 

    RECEIVE  LOGIC  (values SO: X'0E' or X'8E')

     Buffer(1), ... , (n) is a character in the received buffer.

     drop = false
     FOR i=1 to n                    /* for all octets of the buffer */

         IF    drop = true

         THEN  output (buffer(i)  -  X'20')
               drop = false

         ELSE  IF    buffer(i) = (X'0D'  or  X'8D')
               THEN  Stop
               ELSE  IF    buffer(i) = SO
                     THEN  drop = true
                     ELSE  output (buffer(i))


C.3.  PAD Parameter Profile

   Before an (ODETTE-FTP) asynchronous entity --> Modem --> PAD -->
   (ODETTE-FTP) native X.25 link can be established, the target PAD
   parameters must be set such that correct communication is
   established.  It is strongly recommended that the PAD parameters are
   set by the X.25 entity.  CCITT recommendations X.3, X.28, and X.29
   define the PAD parameters and procedures for exchange of control
   information and user data between a PAD and a packet mode Data
   Terminal Equipment (DTE).

   Following is the Parameter list and values used to set the PAD for
   ODETTE-FTP communication.  For further detailed information see the
   specification for CCITT X.25, X.28, X.29 and X.3.

   No. Description                    Value  Meaning
   1   Escape from Data Transfer       0     Controlled by host
   2   Echo                            0     No Echo
   3   Data Forwarding Signal          2     Carriage Return
   4   Selection of Idle Timer Delay   20    1 second
   5   Ancillary Device Control        0     X-ON, X-OFF not used
   6   PAD Service Signals             1     All except prompt
   7   Procedure on Break              2     Reset
   8   Discard Output                  0     Do not discard
   9   Padding after Carriage Return   0     No padding

Top      Up      ToC       Page 117 
   10  Line Folding                    0     No line folding
   11  Terminal Data Rate              -     Read only
   12  Flow Control of the PAD         0     No flow control used
   13  Linefeed Insertion after C/R    0     No linefeed
   14  Linefeed Padding                0     No linefeed padding
   15  Editing                         0     No editing
   16  Character Delete                127   Delete
   17  Line Delete                     24    <CTRL>X
   18  Line Display                    18    <CTRL>R
   19  Editing PAD Service Signals     0     No service signal
   20  Echo Mask                       0     No echo mask
   21  Parity Treatment                0     No parity check
   22  Page Wait                       0     No page wait

   Note 1:

   Refer to CCITT (1984)
   - Parameters 1 - 12 are mandatory and available internationally.
   - Parameters 13 - 22 may be available on certain networks and may
     also be available internationally.
   - A parameter value may be mandatory or optional.

   The ODETTE profile refers only to parameter values which must be
   internationally implemented if the parameter is made available

   The ODETTE-FTP "special-logic" parameter may be impossible on some
   PADs because they do not support of some of the parameters (13 - 22).
   (If the PAD is supporting parity check (21) by default, ODETTE-FTP
   special logic would be impossible.)

   It is a user responsibility to ensure special logic consistency when
   making the PAD subscription.

   Note 2:

   Some parameters may have to be set differently depending on:
   - Make and function of the start-stop mode DTE entity.
   - Start-stop mode DTE entity ODETTE-FTP monitor function.
   - PAD services implemented.
   - Packet mode DTE entity ODETTE-FTP monitor function.

Top      Up      ToC       Page 118 
Appendix D.  OFTP X.25 over ISDN Recommendation

   This appendix describes the recommendation of ODETTE Group 4 (1) for
   the use of OFTP (2) over X.25 over ISDN.

      (1) ODETTE Group 4 is responsible for the specification of
          Telecommunications standards and recommendations for use
          within the Automotive Industry.

      (2) OFTP (ODETTE File Transfer Protocol) is the communications
          standard specified by ODETTE Group 4 designed for the transfer
          of both EDI and non-EDI data.

   This document offers an introductory overview of a technical subject.
   It is structured to contain the ODETTE recommendation, together with
   introductory information for the person not familiar with ISDN, and
   notes on the issues associated with the implementation of the

   The first section provides the detailed ODETTE recommendation, which
   is followed by a general discussion.  If you are not familiar with
   the terminology, please read the subsequent sections first.

   How far an existing X.25 Line adapter may be replaced by an ISDN line
   adapter in an installation depends on the opportunities in view of
   connections (X.25 or ISDN) of the involved partners for file

   Companies that keep many connections to external partners (for
   example, car manufacturing companies) may use the OFTP file transfer
   in view of compatibility, which must always be considered anyway only
   in parallel to the X.25 network.

   It is not the aim of this recommendation to remove the OFTP file
   transfer generally from the X.25 network to the ISDN network.  This
   will not always be possible for international connections because of
   technical reasons, and this does not always make sense for
   connections with a low size of data to be transmitted.

   Certainly, the use of ISDN, when exchanging a high volume of data
   (for example, CAD/CAM files), is very much cheaper than the use of an
   X.25 network.  For such cases, this recommendation shall provide a
   cost-effective possibility for file transfer.

   This appendix is organized as follows.  D.1 defines the ODETTE
   recommendation in these terms, D.2 introduces the ISDN environment to
   the unfamiliar reader, D.3 describes the various methods of
   connecting to ISDN, and D.4 covers implementation issues.

Top      Up      ToC       Page 119 
D.1.  ODETTE ISDN Recommendation

   X.25:               Level 2          ISO 7776

                       Level 3          ISO 8208

                       Packet Size      128

                       Level 2          7
                       Window Size

                       Level 3          7
                       Window Size

                       First LCN        1

                       Number of LCNs   1

                       Facilities       Window Size and Packet Size
                                        negotiation shall be supported
                                        by everybody.  Call User Data
                                        should not be required.

                       Calling NUA      Optionally provided by the call

                       Called NUA       Should be set to a value where
                                        the last 'n' digits can be
                                        specified by the called party.

   ISDN:               Apart from requesting a 64K unrestricted digital
                       call, no ISDN features shall be required.

   Timeout control:    To avoid connections (B channels) within the
                       circuit-switched ISDN network remaining active
                       but unused for a long time, the adapter should
                       include a timeout control.

                       An ISDN connection (B channel) should be released
                       if no X.25 packets have been transmitted on this
                       connection for a longer time.  For flexibility a
                       variable user definable timer should be
                       incorporated into the adapter.

Top      Up      ToC       Page 120 
                       In the event of a timeout situation the adapter
                       has to release the ISDN connection and notify the
                       local OFTP by the transmission of a clear packet.

   The pages that follow are informational and do not form part of this

D.2.  Introduction to ISDN

   The use of digital encoding techniques over such high-quality,
   error-free backbone networks has allowed the PTTs to offer high
   bandwidths to the end user.  The service is named ISDN (Integrated
   Services Digital Network).

   The increasing need to transfer larger volumes of EDI data, in
   particular CAD/CAM drawings, has focused attention upon high-speed,
   low-cost communication.  The traditional X.25 over a Packet Switched
   Data Network (PSDN) has been a good general purpose communications
   subsystem.  Unfortunately, its cost and transfer speed make PSDN
   expensive for the new requirement.

   X.25 over the new ISDN provides both the transfer speed and cost
   benefits to satisfy the new requirements.

   We include the following terminology because for us to make sense of
   ISDN and X.25, it is important that we use definitions precisely and
   avoid the abuses of the past.

   ISDN:        Integrated Services Digital Network

   X.25:        X.25 is a communications protocol.  It defines the
                structure of data packets that comprise the protocol and
                the manner in which they are used.

   PSDN:        A PSDN (Packet Switched Data Network) is a network over
                which the X.25 protocol is operated.

   PSPDN:       A PSPDN (Packet Switched Public Data Network) is a PSDN
                operated by the PTTs.  PSPDNs are given trade names,
                such as PSS in the UK, Datex-P in Germany, and Transpac
                in France.

   BRI:         Basic Rate Interface, also known as Basic Rate Access,
                defines an ISDN facility with 2 x 64 K B channels.

   PRI:         Primary Rate Interface, also known as Primary Rate
                Access, defines an ISDN facility with 30 x 64 K B

Top      Up      ToC       Page 121 
   Channels:    ISDN is typically brought into a consumer's premises
                using a twisted pair of wire.  Over this wire, data can
                be transmitted in frequency bands.  These frequency
                bands are allocated as channels.

   B channels:  The B channels are the data channels and operate at 64
                Kb.  The two end users of a connection will communicate
                over a B channel.

   D channel:   Signalling on ISDN is performed over the D channel.
                Signalling is used to set up and release connections on
                the B channels.  In some countries, the D channel can
                also be used for limited X.25 access to the PTTs' PSDN.

                The D channel operates at the lower speed of 16 Kb as it
                is normally used only at the beginning and end of a

                                         Bandwidth Allocation:
                     2 Wire                 B2 - 64 Kb
                     Twisted Pair           B1 - 64 Kb
                                         D Channel - 16 Kb

                The standard for the operation of the D channel is
                called ETSI and is used in most European countries.
                However, some countries that started the introduction
                very early used proprietary standards, for example:

                     1TR6 - Used in Germany
                     BTNR - Used in the UK

                Although there are D channel variations, this will not
                affect communications over the B channels as the
                communication over the D channel is between the
                subscriber and the ISDN service provider.

                However, the consumer's equipment must be able to handle
                the channel D signalling operated by the ISDN service
                provider and so there may be a problem of equipment
                availability and certification.

                All the PTTs have committed to migrate to ETSI (also
                known as EURO-ISDN and Q.931) and many are currently
                supporting both their national variant and ETSI.  It is
                advisable that in this situation the subscriber select
                the ETSI variant to avoid unnecessary equipment

Top      Up      ToC       Page 122 
   Services:    The high-speed service is provided in two forms, Basic
                and Primary.

                Basic: 2+D, the D 2B channel operates at 16 Kb.  The
                Basic Rate access is normally provided to the subscriber
                over simple twisted pair cable.

                Primary: 30B+D, the D channel operates at 64 Kb.
                Primary Rate access is normally provided to the
                subscriber over shielded coaxial cable.  Note that the
                bandwidth for Primary is 2.048 Mbit/s.

   Protocols:   The B channel is a binary channel and is transparent to
                the flow of data.  Therefore, all of the currently
                available protocols can operate over a B channel.  The
                most common protocol is X.25.

   X.25:        The X.25 protocol is a primary protocol for open
                computer-to-computer communication.

   Passive Bus: It is possible to have an ISDN service enter a building
                and then have an 8-core cable laid within the building
                with multiple ISDN junction points, in the same way as
                one would have multiple telephone points (extensions)
                for a particular external telephone line.

   Connection Setup

      The adapter is responsible for analysing the outgoing X.25 call
      request and making an ISDN call to a derived ISDN address,
      establishing a new X.25 level-2 and level-3, and then propagating
      the X.25 Call Request Packet.

   Connection Termination

      The termination phase of the X.25 call is made with a Clear
      Request and finalised with a Clear Confirmation.  The recipient of
      the Clear Confirm should then close down the ISDN connection.

      The clear down of the ISDN connection should only be made if there
      are no other Switched Virtual Circuits (SVCs) active on the ISDN
      connection; note that the usage of multiple simultaneous SVCs is
      only by virtue of bilateral agreement.

Top      Up      ToC       Page 123 
D.3.  Equipment Types

   There are a number of ways in which ISDN/X.25 access can be made.

      Integrated Adapter

       This is normally a PC-based ISDN adapter inside a PC.  It is
       normal in such an environment that the OFTP application has the
       ability to manipulate the ISDN and X.25 aspects of the session
       independently and therefore have complete control.

       Equally important is that the speed of communication between the
       adapter and the application are at PC BUS speeds.  It is
       therefore more likely that the effective transmission speed will
       be nearer the 64K limit.

       The other benefit of such a direct linkage is that both 64K B
       channels may be used in parallel and both able to operate at

      Elementary Terminal Adapter

       In this scenario, the computer has an integral X.25 adapter
       communicating X.21 with a Terminal Adapter that fronts the ISDN
       network.  This allows a host with a X.25 capability to interface
       to ISDN, normally on a one-to-one basis.

       The interface between the Terminal Adapter and the PC will
       typically only support one 64K B channel.  This is obviously an
       inefficient usage of the ISDN service.

       Because the linkage between the computer and the Terminal Adapter
       is only X.25, then some modification/configuration may be needed
       inside the Terminal Adapter when new users are added.

      X.25 Switch

       This solution is normally found inside the larger corporates
       where an internal X.25 network is operated or where dual X.25 and
       ISDN is required.

       The main benefit of a switch is to support both PSDN and ISDN
       simultaneously.  Also, multiple X.21 lines may be implemented
       between the X.25 switch and the computer.

       This solution normally requires more effort to configure and may
       require obligations to be placed upon how incoming callers
       specify routing.

Top      Up      ToC       Page 124 
D.4.  Implementation

   The adoption of ISDN as an additional subsystem to support OFTP
   communications has associated implementation problems, which can be
   categorised as below:

      X.25/ISDN Addressing
      Making a Call
      Receiving a Call
      Logical Channel Assignment
      Facilities Negotiation
      ISDN Call Attributes
      Homologation Issues

D.4.1.  X.25/ISDN Addressing

   The original OFTP was designed to work over the X.25 networks
   provided by the PTTs (PSPDNs).  The national X.25 networks were
   interconnected to provide a global X.25 network, and a common
   addressing scheme was adopted by all.  Although there were a few
   differences in addressing within a national network, the interface to
   other countries was quite rigid and normalised.

   PSPDN Numbering

      The addressing scheme adopted in X.25 is a 15-digit number
      (Network User Address, NUA) where the first three identify the
      country, the fourth digit identifies the network within the
      country, and the remainder specify the individual subscriber plus
      an optional subaddress.  In the UK where a full X.25 numbering
      scheme is adopted, a NUA is, e.g., 234221200170, where 2342 is the
      DNIC (Data Network Identification Code) and 21200170 is the
      subscriber number.

   ISDN Numbering

      ISDN is an extension of the normal telephone system; consequently,
      it adopts (or rather is) the same numbering scheme as the
      telephone system (PSTN).

   The Numbering Conflict

      The PSDN and PSTN numbering schemes are two totally different
      numbering schemes.  There is no relationship between them.  It is
      this conflict that is at the heart of the matter.

Top      Up      ToC       Page 125 
D.4.2.  Making a Call

   It is a consequence of PSDN and PSTN being based upon different and
   unconnected numbering schemes that the key problem arises.

   For X.25 to work over ISDN, three main methods of addressing are

     Un-mapped:   The X.25 called NUA is used as the PSTN number.  Thus,
                  an X.25 call to 0733394023 will result in a PSTN call
                  to 0733394023 and the call request that consequently
                  flows will also be to 0733394023.

     Manipulated: The X.25 called NUA is manipulated by the subtraction
                  and/or addition of digits to derive a resultant PSTN
                  number.  Thus, 2394023 could be manipulated to derive
                  a PSTN number of 00944733394023, where the prefix 2 is
                  deleted and replaced by 00944733.

     Mapped:      The X.25 called NUA is used as a look-up into a table
                  of PSTN numbers.  Thus, an X.25 call to 234221200170
                  could be mapped to and result in a PSTN call to
                  0733394023 and the call request that consequently
                  flows will remain as 234221200170.

   Un-mapped Calls

      Un-mapped calls are where the host-specified X.25 NUA is converted
      directly to the corresponding ISDN number.

      Thus, an X.25 call issued by the host to X.25 NUA 0733394023 will
      result in an ISDN call to the PSTN number 0733394023.  After the
      call has been established, then HDLC/X.25 protocol setup will be
      established after which an X.25 call request will be transferred
      with the NUA 0733394023.

      When a PSTN call is made, the number of digits in the called
      number vary depending upon the location of the called party.

      When a number is called, it may be local, national, or

         local: 394023
         national: 0733 394023
         international: 009 44 733 394023

      Depending upon where a call originates, the corresponding X.25 NUA
      in the call request packet will vary dramatically.

Top      Up      ToC       Page 126 
      Such variation of X.25 NUA, in particular the changing prefix, can
      be difficult to be accommodated by X.25 routing logic in many

      When an international PSTN call is being made, then it is likely
      that the PSTN number exceeds 15 digits, which is the maximum
      length of an X.25 NUA.  Therefore, using un-mapped addressing may
      make some international calls impossible to make.

   Manipulated Calls

      The X.25 called NUA is manipulated by the subtraction and/or
      addition of digits to derive a resultant PSTN number.

      Let us assume that by internal convention we have identified the
      prefix '2' to indicate an international ISDN call.  Thus, an X.25
      call request of 244733394023 could be manipulated to derive a PSTN
      number of 00944733394023, where the prefix '2' is deleted and
      replaced by '009' (the international prefix).

      The X.25 called NUA would typically be left in its un-manipulated
      state.  As individual internal conventions vary, the X.25 called
      NUA will vary.  In the case above, it would be 244733394023, but
      another installation might have the convention where a prefix of
      '56' specifies the UK and so the NUA will be 56733394023, where
      the '56' is deleted and replaced with '00944' to derive the PSTN

   Mapped Calls

      The mapped method offers maximum flexibility in that:

         The PSTN number can exceed 15 digits.

         The X.25 NUA and PSTN number can be totally different.

      The problem with mapped calls is administrative.  IBM mainframes
      can't handle X.25 over ISDN at all, let alone support mapping.
      For the mainframe solution to work, an external X.25/ISDN router
      box is required and it is the responsibility of the external box
      to provide any mapping necessary.

      This means that any changes or addition of OFTP partners over ISDN
      will require access to the computer room or special configuration
      equipment to change the tables inside the external X.25/ISDN
      router box.

Top      Up      ToC       Page 127 
D.4.3.  Receiving a Call

      We have seen from the previous section that the called X.25 NUA
      from an ISDN incoming call may vary considerably.  If ISDN/X.25 is
      confined to a national boundary, then such variation will not be
      so great as most calls will have matching called X.25 NUA and PSTN

      X.25 switches and X.25 adapters normally route/accept/reject calls
      based upon their X.25 called NUA.  In particular, routing is made
      upon the X.25 called NUA subaddress.

      To derive this subaddress, there are 2 methods:

      1) the last 'n' digits are analysed.

      2) the base X.25 NUA of the line is removed from the called NUA.
         For example, if the called X.25 NUA is 23422120017010 and the
         PSDN subscriber NUA is 234221200170, then the subaddress
         derived from subtraction is 10.

   Obviously, the second method will not work if the incoming NUA

   ISDN Features

      ISDN, like X.25, has a core set of features that are then enriched
      with options.  In the original OFTP X.25 specification, it was
      decided that the Q-bit and D-bit options were not common to all
      networks or applications; they were therefore positively excluded
      from the specification.

      It is proposed that apart from the core ISDN features necessary to
      establish a call, no other features be used.


    There are two forms of ISDN subaddressing, overdialled and specific.

    The overdial method allows an ISDN number to be artificially
    extended.  A typical case would be where a private exchange has been
    installed in a larger company.  Assume that the base number is
    394023 and the computer is on internal extension 1234, then by
    specifying an ISDN number of 3940231234, direct access may be made
    to the internal extension.

Top      Up      ToC       Page 128 
    The problem with this method is that it extends to called number and
    may, especially for international access, exceed the ISDN numbering
    limits between countries.

    The other method of subaddressing is where a discrete subaddress is
    placed in a specific field in the ISDN call setup.

    The problem with this method, is that it requires the caller to
    place the subaddress in the ISDN call setup.  Not all ISDN
    implementations will allow this insertion.

    In conclusion, subaddressing of any kind should be avoided.

D.4.4.  Logical Channel Assignment

    An X.25 dataline will have associated with it a number of logical

    The number of channels is a part of the agreement between the PTT
    and the subscriber.  The number of channels subscribed to is
    important; call failure and similar problems will result if the
    number of logical channels defined at the two remote ends are

    If a DTE makes a call out, then the highest defined logical channel
    number will be selected.  If the remote Data Communications
    Equipment (DCE) does not have the same number of logical channels
    defined, then an invalid logical channel is being used from the
    perspective of the recipient DCE and the call will be rejected.

D.4.5.  Facilities Negotiation

    In the PSPDN environment, it is possible to subscribe to negotiation
    of window size and packet size.  Although this negotiation requested
    by the originator's DTE may be propagated to the remote DTE at the
    discretion of the originator's DCE, it is a local responsibility
    between the DTE and DCE pair.

    In the ISDN scenario where it is a DTE-DTE type connection, the
    window size and packet size may be left at the default value and
    consequently the values may be omitted from the call request.  If no
    values are specified, then it is vital that both DTEs have
    configured themselves to the recommended defaults.

    The symptom of a window size mismatch is a hang situation without
    any informational error codes.

Top      Up      ToC       Page 129 
    The symptoms of a packet size mismatch could work in some scenarios,
    but would otherwise issue error codes indicating invalid packet

   Window Size

      The CCITT X.25 window size has a default value of '2', although
      subscribers may have other default window sizes, e.g., '7', by
      virtue of agreement with the PTT.

      Window size negotiation can be explicitly requested by specifying
      the requested window size in the Facilities fields in the Call
      Request packet.

   Packet Size

      The CCITT X.25 packet size has a default value of '128' octets,
      although subscribers may have other default values, e.g., '1024',
      agreed with the PTT.

D.4.6.  ISDN Call Setup

      The initial setup of an ISDN call is initiated with the
      transmission of a Q.931 SETUP command.  Apart from requesting that
      a call be established, the SETUP command can optionally carry
      information about the calling party, the called party, routing
      information, the type of circuit required (e.g., voice or data),
      and information about the protocols that are requested to be

      Setup Parameters:

      Bearer capability            Information transfer and
                                   access attributes

      Called Party number          Destination's network address

      Called Party subaddress      Destination's complete

      Calling Party number         Source's network address

      Low-layer compatibility      Layer 1-3 indication

      High-layer compatibility     Layer 4-7 indication

Top      Up      ToC       Page 130 
D.4.7.  Homologation Issues

   Homologation procedures were adopted and vigorously enforced by the
   PTTs with respect to the quality and conformance of communications
   equipment connected to the services provided by the PTTs.

   In particular, commercial X.25 products had to be tested and approved
   before they could be connected to the PTTs' PSPDN.  The advantage of
   this to the subscriber was that there was very little chance of the
   approved equipment not working.

   With ISDN, similar approval standards are still enforced.  So the
   subscriber has the same confidence in their ISDN equipment.  Wrong,
   the ISDN equipment itself is approved, but the X.15 protocol that
   operates on top of ISDN is now outside of the scope of approval

   This means that quality of conformance to standards of X.25 over ISDN
   is subject to the variable quality procedures within the various ISDN
   equipment manufacturers.

   Although it is likely that commercial reputation will place pressure
   upon the manufacturers with a programming bug to correct such errors,
   it still requires the subscribers that do not communicate well to put
   time and effort into finding the party with the error.

   So far, tests have shown a number of subtle errors, such as timing
   problems, that have taken many days to find, prove, and fix.

D.4.8.  Growth

   Primary Rate Access

      If a user decides to plan for growth from the beginning, then the
      Primary Rate Access has apparent financial benefits.  Such
      apparent savings are usually lost due to the increased cost of
      user hardware to support such an interface.  The BRI for data
      usage is very common and cards/adapters are low in cost, whereas
      the PRI cards/adapters are few and far between and consequently
      highly priced.

   Basic Rate Access

      One way to grow with ISDN is to buy multiple BRI lines, increasing
      slowly in units of 2 x B channels.  The PTTs will be able to
      provide the same subscriber number for all the lines provided in a
      similar way to the traditional hunting group associated with PSTN
      type working.

Top      Up      ToC       Page 131 
D.4.9.  Performance

      The obvious benefit of ISDN is speed; unfortunately, the majority
      of computer systems in use today have a finite amount of computing
      power available.  The attachment of multiple active high-speed
      communication lines used in file transfer mode could take a
      significant amount of CPU resource to the detriment of other users
      on the system.

      Connecting an ISDN line with the default 2 B channels to your
      computer using an X.21 interface is going to give a consistent 64
      Kb throughput only if one of the B channels is active at any one

      If there are two 64 Kb channels active and contending for a single
      64 Kb X.21 interface, then effective throughput will be reduced
      significantly to just over 50%.

   Mainframe issues:

      Users with a mainframe front-end are also going to find cost an
      issue.  The scanners that scan the communications interfaces are
      based upon aggregate throughput.  A 64 Kb interface takes up a lot
      of cycles.

   Determining 'DTE' or 'DCE' Characteristics

      The following section is an extract from the ISO/IEC 8208
      (International Standards Organization, International
      Electrotechnical Commission) (1990-03-15) standard, which is an
      ISO extension of the CCITT X.25 standard.

      The restart procedure can be used to determine whether the DTE
      acts as a DCE or maintains its role as a DTE with respect to the
      logical channel selection during Virtual Call establishment and
      resolution of Virtual Call collision.

      When prepared to initialise the Packet Layer, the DTE shall
      initiate the restart procedure (i.e., transmit a RESTART REQUEST
      packet).  The determination is based on the response received from
      the data exchange equipment (DXE) as outlined below.

     a) If the DTE receives a RESTART INDICATION packet with a
        restarting cause code that is not 'DTE Originated' (i.e., it
        came from a DCE), then the DTE shall maintain its role as a DTE.

Top      Up      ToC       Page 132 
     b) If the DTE receives a RESTART INDICATION packet with a
        restarting cause code of 'DTE Originated' (i.e., it came from
        another DTE), then the DTE shall confirm the restart and act as
        a DCE.

     c) If the DTE receives a RESTART INDICATION packet with a
        restarting cause code of 'DTE Originated' (i.e., it came from
        another DTE) and it does not have an unconfirmed RESTART REQUEST
        packet outstanding (i.e., a restart collision), then the DTE
        shall consider this restart procedure completed but shall take
        no further action except to transmit another RESTART REQUEST
        packet after some randomly chosen time delay.

     d) If the DTE issues a RESTART REQUEST packet that is subsequently
        confirmed with a RESTART CONFIRMATION packet, then the DTE shall
        maintain its role as a DTE.


   This document draws extensively on revision 1.4 of the ODETTE File
   Transfer Specification [OFTP].

   Many people have contributed to the development of this protocol and
   their work is hereby acknowledged.

Normative References

              Gutmann, P., "Compressed Data Content Type for
              Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.

   [CMS]      Housley, R., "Cryptographic Message Syntax (CMS)", RFC
              3852, July 2004.

   [ISO-646]  International Organisation for Standardisation, ISO
              Standard 646:1991, "Information technology -- ISO 7-bit
              coded character set for information interchange", 1991.

   [PKCS#1]   Jonsson, J. and B. Kaliski, "Public-Key Cryptography
              Standards (PKCS) #1: RSA Cryptography Specifications
              Version 2.1", RFC 3447, February 2003.

   [TLS]      Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

   [UTF-8]    Yergeau, F., "UTF-8, A Transformation Format of ISO
              10646", STD 63, RFC 3629, November 2003.

Top      Up      ToC       Page 133 
   [ZLIB]     Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
              Specification version 3.3", RFC 1950, May 1996.

Informative References

   [ISO-6523] International Organisation for Standardisation, ISO
              Standard 6523:1984, "Data interchange -- Structures for
              the identification of organisations", 1984.

   [OFTP]     Organisation for Data Exchange by Tele Transmission in
              Europe, Odette File Transfer Protocol, Revision 1.4, April

   [FTP]      Postel, J. and J. Reynolds, "File Transfer Protocol", STD
              9, RFC 959, October 1985.

   [RFC793]   Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.

   [RIME]     Coleridge, Samuel Taylor, "The Rime of the Ancient
              Mariner", 1817.

   [X.509]    Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and
              Certificate Revocation List (CRL) Profile", RFC 3280,
              April 2002.

   [RFC3850]  Ramsdell, B., "Secure/Multipurpose Internet Mail
              Extensions (S/MIME) Version 3.1 Certificate Handling", RFC
              3850, July 2004.

Top      Up      ToC       Page 134 
ODETTE Address

   The ODETTE File Transfer Protocol is a product of the Technology
   Committee of Odette International.  The Technology Committee can be
   contacted via the ODETTE Central Office:

   Forbes House
   Halkin Street
   SW1X 7DS
   United Kingdom

   Phone: +44 (0)171 344 9227
   Fax:   +44 (0)171 235 7112

Author's Address

   Ieuan Friend
   Data Interchange Plc
   Rhys House
   The Minerva Business Park
   PE2 6FT
   United Kingdom

   Phone: +44 (0)1733 371 311

Top      Up      ToC       Page 135 
Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78 and at, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at