Multiple response modes

Rickard Schoultz <> Wed, 01 December 1993 10:58 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa01527; 1 Dec 93 5:58 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01521; 1 Dec 93 5:58 EST
Received: from by CNRI.Reston.VA.US id aa03607; 1 Dec 93 5:58 EST
Received: by (4.1/UCD2.05) id AA10155; Wed, 1 Dec 93 02:30:21 PST
Received: from by (4.1/UCD2.05) id AA10001; Wed, 1 Dec 93 02:28:09 PST
Received: from by (8.6.4/2.02) id LAA10805; Wed, 1 Dec 1993 11:30:21 +0100
Message-Id: <>
Subject: Multiple response modes
Date: Wed, 01 Dec 93 11:30:20 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Rickard Schoultz <>

A reply send from a whois++ server has a layout like:

	# response-mode
	# END

The whois++ document mentions a `Pointer' response mode, allowing the
server to point to another whois++ server (records on another server).
The index document also defines a `Servers-To-Ask' reply, which allows a
server tell the client to pass the query to another server.

It would be very useful if the server could respond with a mix of
response modes. One problem with that is that `# END' is defined as the
end of the response [of the FORMAT response MODE], so this means that we
have to use something else to mark the end of the whole response;
Preferably a system response since that is what we are doing.

A server could in this model yield:

	# USER foo123
	  Name:Grkl Mnpgh
	# END
	  <some yet-to-be-defined structure>
	# END
	% 226 Transfer complete.

Would that be acceptable?