Received: with ECARTIS (v1.0.0; list gopher); Wed, 20 Mar 2002 16:50:59 -0500 (EST) Return-Path: <rhahn@tenletters.com> Delivered-To: gopher@complete.org Received: from quarry.com (mail.quarry.com [205.189.158.4]) by pi.glockenspiel.complete.org (Postfix) with ESMTP id 7F1943B80D for <gopher@complete.org>; Wed, 20 Mar 2002 16:50:55 -0500 (EST) Received: from [205.189.158.32] (205.189.158.32) by quarry.com with ESMTP (Eudora Internet Mail Server 3.0.1) for <gopher@complete.org>; Wed, 20 Mar 2002 16:50:56 -0500 Mime-Version: 1.0 X-Sender: rhahn@mail.quarry.com (Unverified) Message-Id: <p05010404b8beb412dd09@[205.189.158.32]> In-Reply-To: <DC4522A8-3C47-11D6-B325-0003930BF072@complete.org> References: <DC4522A8-3C47-11D6-B325-0003930BF072@complete.org> Date: Wed, 20 Mar 2002 16:51:02 -0500 To: gopher@complete.org From: Robert Hahn <rhahn@tenletters.com> Subject: [gopher] Re: \n.\n Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 514 X-ecartis-version: Ecartis v1.0.0 Sender: gopher-bounce@complete.org Errors-to: gopher-bounce@complete.org X-original-sender: rhahn@tenletters.com Precedence: bulk Reply-to: gopher@complete.org List-help: <mailto:ecartis@complete.org?Subject=help> List-unsubscribe: <mailto:gopher-request@complete.org?Subject=unsubscribe> List-software: Ecartis version 1.0.0 List-ID: Gopher <gopher.complete.org> X-List-ID: Gopher <gopher.complete.org> List-subscribe: <mailto:gopher-request@complete.org?Subject=subscribe> List-owner: <mailto:jgoerzen@complete.org> List-post: <mailto:gopher@complete.org> List-archive: <http://www.complete.org/mailinglists/archives/> X-list: gopher

John:

I would fully support this if you can explain to me how a gopher client is supposed to 'know' when the end of a file is and closes the connection.

I don't know much about server design and certainly about this implementation (yet), but I do understand that the gopher0 and + spec indicated that the reason for \n.\n is to indicate EOF.

thx, -rh

>I would like to abolish the adding of "." at the end of text gopher >documents. Since we have most of the world's gopher client and server >authors in this group, we can do it :-) > >Details: > >SERVER: > >All gopher servers MUST NOT add a "\n.\n" end-of-file marker to files >being transmitted. > >CLIENT: > >All gopher clients MUST NOT remove "\n.\n" from the end of files. > >Note: I say this for clients to because we don't want to have to deal >with the case of having a file that ends with a dot.