Received: with ECARTIS (v1.0.0; list gopher);
 Mon, 21 Oct 2002 19:37:07 -0500 (EST)
Return-Path: <hardburn@runbox.com>
Delivered-To: gopher@complete.org
Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94])
	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
	(Client did not present a certificate)
	by gesundheit.complete.org (Postfix) with ESMTP id 5913561BA5
	for <gopher@complete.org>; Mon, 21 Oct 2002 19:37:06 -0500 (EST)
Received: from [10.9.9.1] (helo=pluto.runbox.com)
	by tramp.runbox.com with esmtp (Exim 4.05-VA-mm1)
	id 183n2e-0004H7-00
	for gopher@complete.org; Tue, 22 Oct 2002 02:37:04 +0200
Received: from [204.71.148.90] (helo=enterprise)
	(Authenticated Sender=hardburn)
	by pluto.runbox.com with asmtp (Exim 3.35 #1)
	id 183n2M-0004Lq-00
	for gopher@complete.org; Tue, 22 Oct 2002 02:36:46 +0200
Content-type: text/plain; charset=us-ascii
From: Timm Murray <hardburn@runbox.com>
To: gopher@complete.org
Subject: [gopher] Gopher+ Uploading
Date: Mon, 21 Oct 2002 18:56:25 -0500
X-Mailer: KMail [version 1.4]
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <200210211856.29450.hardburn@runbox.com>
X-archive-position: 707
X-ecartis-version: Ecartis v1.0.0
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
X-original-sender: hardburn@runbox.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


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here's the start of a standard on uploading using Gopher+.  Unlike the 
authentication proposal, this one actually uses +ASK in a compatible way.


Gopher+ Uploading

By Timm Murray

This document describes a means of uploading files to a Gopher server using 
Gopher+ 
attributes.

In breaking with Gopher tradition, this document uses '\t' to denote a 
tab, '\r' to denote a cariage return, and '\n' to denote a newline.  
'C:' is a line of text sent by the client, and 'S: is a line sent by the 
server.  


MENU SELECTOR

'u' is defined as being the item type indicating an upload selector.  It is 
recommended 
that any upload fields use Gopher+ Authentication before allowing an upload.

Example:

uUpload a file\t/incoming\thost\tport\t*\r\n

Clients should expect to go through the +ASK exchange for the upload even if 
a '?' is not present in the Gopher+ section.


PREFORMING THE UPLOAD

After the optional authentication exchange, the client sends meta information 
about 
the file being uploaded.  The following exchange takes place:

C: [selector string] \r\n
S: +ASK \r\n
S: Ask: Size of file (bytes)? \r\n
S: Ask: Selector string to put under? \r\n
S: AskF: File to send \r\n
S: AskL: Additional information \r\n
C: <size of file, in bytes> \r\n
C: <description> \r\n
C: <selector string> \r\n
C: <filename> \r\n
C: <additional info> \r\n
C: <the file itself>

In keeping with Gopher+, a size of -1 means "read data until a period on a 
line 
by itself".  A size of -2 means "read data until I close the connection" (this 
meathod is strongly discouraged).  Any size of >= 0 means "read this many 
bytes, 
then close the connection".

The "description" sent MAY be used by servers for the 'user' field in menu 
entries.  
Clients SHOULD keep this under 70 characters, in keeping with Gopher tradition 
for 
'user' fields.  It MUST NOT contain any tab characters.

The "selector string" sent for the file MAY be ignored by servers.  It is used 
only as a 
guide for servers that choose to use it.

The filename sent MUST be ignored by servers.  The "AskF" statement mearly 
provides the 
client with a chance to open a file dialog box so the user can choose the file 
to send 
(or however else the client wishes to handle it).  Clients MAY send an empty 
string 
for the filename.

["Additional info" section]


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj20lCsACgkQqpueKcacfLTdagCguRtsvcY2WK1oN9qPuZP1peWe
8K4AoImav/1PR8igsulTeTPiy/g/cV7A
=LgIu
-----END PGP SIGNATURE-----