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



