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