RFC 2243 (rfc2243) - Page 2 of 10


OTP Extended Responses



Alternative Format: Original Text Document



RFC 2243                 OTP Extended Responses            November 1997


2. Extended Challenges and Extended Responses

   This document builds on the protocol and terminology specified in RFC
   1938 and assumes that you have already read this document and
   understand its contents.

   An extended challenge is a single line of printable text terminated
   by either a new line sequence appropriate for the context of its use
   (e.g., ASCII CR followed by ASCII LF) or a whitespace character. It
   contains a standard OTP challenge, a whitespace character, and a list
   that generators use to determine which extended responses are
   supported by a server.

   An extended response is a single line of printable text terminated by
   a new line sequence appropriate for the context of its use. It
   contains two or more tokens that are separated with a single colon
   (':') character. The first token contains a type specifier that
   indicates the format of the rest of the response. The tokens that
   follow are argument data for the OTP extended response. At least one
   token of data MUST be present.

2.1. Syntax

   In UNIX manual page like syntax, the general form of an extended
   challenge could be described as:

       ext[,[, ...]]

   And the general form of an extended response could be described as:

      :[:[:...]]

   In augmented BNF syntax, the syntax of the general form of an
   extended challenge and an extended response is:

   extended-challenge = otp-challenge 1*LWSP-char capability-list
                        (NL / *LWSP-char)
   otp-challenge     = 
   capability-list   = "ext" *("," extension-set-id)
   extension-set-id  = * extended-response = type 1*(":" argument) NL type = token argument = token token = 1* NL =  Metz Standards Track