Re: Multiple response modes

Peter Deutsch <> Wed, 01 December 1993 15:32 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa08395; 1 Dec 93 10:32 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08389; 1 Dec 93 10:32 EST
Received: from by CNRI.Reston.VA.US id aa09269; 1 Dec 93 10:32 EST
Received: by (4.1/UCD2.05) id AA26197; Wed, 1 Dec 93 07:12:20 PST
Received: from by (4.1/UCD2.05) id AA26012; Wed, 1 Dec 93 07:09:24 PST
Received: from expresso.Bunyip.Com by with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23126 (mail destined for on Wed, 1 Dec 93 10:11:33 -0500
Received: by (NX5.67c/NeXT-1.0) id AA09742; Wed, 1 Dec 93 10:03:14 -0500
Message-Id: <>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Peter Deutsch <>
Date: Wed, 1 Dec 1993 10:03:12 -0500
In-Reply-To: Rickard Schoultz's message as of Dec 1, 11:30
X-Mailer: Mail User's Shell (7.2.4 2/2/92)
To: Rickard Schoultz <>,
Subject: Re: Multiple response modes

[ You wrote: ]

> 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.

Yes, this was agreed to but not yet put into the document.

> 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
> 	  <some yet-to-be-defined structure>
> 	# END
> 	% 226 Transfer complete.
> Would that be acceptable?

Perfectly acceptable to me. If nobody else objects we can
consider it done. Do we want to _require_ the "Transfer
complete", or allow a closed connection to signal this?

I'm thinking of the problem SMTP has without a proper
acknowledged disconnect mechanism, but in that case a lost
ack causes retransmits of data (and at times a flood of
duplicate messages). Would this be a problem for us?

				- peterd


"The Internet destroys the Greek tragedy of time and space..."

                            - Daniel Pimienta <pimienta!>