Multiple response modes
Rickard Schoultz <schoultz@sunet.se> Wed, 01 December 1993 10:58 UTC
Received: from ietf.nri.reston.va.us 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 ucdavis.ucdavis.edu by CNRI.Reston.VA.US id aa03607; 1 Dec 93 5:58 EST
Received: by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA10155; Wed, 1 Dec 93 02:30:21 PST
X-Orig-Sender: ietf-wnils-request@ucdavis.edu
Received: from sunic.sunet.se by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA10001; Wed, 1 Dec 93 02:28:09 PST
Received: from localhost.sunet.se by sunic.sunet.se (8.6.4/2.02) id LAA10805; Wed, 1 Dec 1993 11:30:21 +0100
Message-Id: <199312011030.LAA10805@sunic.sunet.se>
To: ietf-wnils@ucdavis.edu
Subject: Multiple response modes
Date: Wed, 01 Dec 1993 11:30:20 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Rickard Schoultz <schoultz@sunet.se>
A reply send from a whois++ server has a layout like: # response-mode data # 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: # FULL # USER foo123 Name:Grkl Mnpgh # END # POINTER <some yet-to-be-defined structure> # END % 226 Transfer complete. Would that be acceptable? -Rickard
- Multiple response modes Rickard Schoultz
- Re: Multiple response modes Peter Deutsch
- Re: Multiple response modes Rickard Schoultz
- Re: Multiple response modes Rickard Schoultz