Re: Multiple response modes

Rickard Schoultz <schoultz@sunet.se> Thu, 09 December 1993 15:53 UTC

Message-Id: <199312091503.QAA28816@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: Thu, 09 Dec 1993 16:03:41 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Rickard Schoultz <schoultz@sunet.se>

[Peter wrote:]
>[...]
>>[...]
>> 
>> 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 think the transfer complete message should be a protocol requirement,
or else some clients would (wrongly, but they would) see the "# END" as
a close connection signal.

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

I don't think so. But I think we would be better off with the TIMEOUT
constraint required.

-Rickard

Multiple response modes Rickard Schoultz
Re: Multiple response modes Peter Deutsch
Re: Multiple response modes Rickard Schoultz
Re: Multiple response modes Rickard Schoultz