Re: Multiple response modes

Rickard Schoultz <> Mon, 27 December 1993 15:41 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa25034; 27 Dec 93 10:41 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25028; 27 Dec 93 10:41 EST
Received: from by CNRI.Reston.VA.US id aa07805; 27 Dec 93 10:41 EST
Received: by (4.1/UCD2.05) id AA22763; Mon, 27 Dec 93 07:20:04 PST
Received: from by (4.1/UCD2.05) id AA22621; Mon, 27 Dec 93 07:14:22 PST
Received: from by (8.6.4/2.03) id QAA10879; Mon, 27 Dec 1993 16:16:44 +0100
Message-Id: <>
To: Peter Deutsch <>
Subject: Re: Multiple response modes
In-Reply-To: Your message of Wed, 01 Dec 93 10:03:12 -0500. <>
Date: Mon, 27 Dec 93 16:16:43 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Rickard Schoultz <>

I answered the letter attached below before, but I found another reason
why we need to make the "Transfer Complete" required: 

Suppose you are doing a query with a HOLD constraint, which would give
you the ability to put another query or issue another command.  Without
a transfer complete code, the client cannot know when the server reply
ends (not even if we would keep the record count, since the reply may be
a mix of response modes (see the attached letter)).


[Peter wrote:]
> [ Rickard 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!>
> -----------------------------------------------------------------------------