Re: Multiple response modes

Rickard Schoultz <schoultz@sunet.se> Mon, 27 December 1993 15:41 UTC

Received: from ietf.nri.reston.va.us 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 ucdavis.ucdavis.edu by CNRI.Reston.VA.US id aa07805; 27 Dec 93 10:41 EST
Received: by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA22763; Mon, 27 Dec 93 07:20:04 PST
X-Orig-Sender: ietf-wnils-request@ucdavis.edu
Received: from sunic.sunet.se by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA22621; Mon, 27 Dec 93 07:14:22 PST
Received: from localhost.sunet.se by sunic.sunet.se (8.6.4/2.03) id QAA10879; Mon, 27 Dec 1993 16:16:44 +0100
Message-Id: <199312271516.QAA10879@sunic.sunet.se>
To: Peter Deutsch <peterd@bunyip.com>
Cc: ietf-wnils@ucdavis.edu
Subject: Re: Multiple response modes
In-Reply-To: Your message of Wed, 01 Dec 93 10:03:12 -0500. <9312011503.AA09742@expresso.bunyip.com>
Date: Mon, 27 Dec 93 16:16:43 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Rickard Schoultz <schoultz@sunet.se>

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

-Rickard


[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
>> 	# POINTER
>> 	  <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!daniel@redid.org.do>
> -----------------------------------------------------------------------------