RetroBBS - comp.infosystems.gemini

Here is my idea of another protocol and file format, considering what are
the problems with Gemini (in my opinion), and how to be better (in my
opinion). There are both some things added and some removed compared with
Gemini; some of the goals are a bit different, although there are also
some similarities. (It is not intended to replace Gemini, just as much as
Gemini does not replace Gopher and HTTP.)

Note that it is currently a draft and is incomplete; changes may be made
in future, before it is finalized.

Link to document: http://zzo38computer.org/textfile/miscellaneous/newgemi
(This file is plain text)

Please make your comments/questions/suggestions/complaints about it.

A copy of the current version is below, but note that changes may be made
since this article is posted to Usenet:

*** BEGIN DOCUMENT ***

(DRAFT)

=== Protocol ===

The protocol can be TLS or non-TLS. Implementation of TLS is optional but
is recommended. The same port number can be used for TLS and non-TLS.

Unless otherwise specified, the text in the protocol is ASCII.

The first byte is the subprotocol, and then optional subprotocol parameter,
and then a space, and then the absolute URL (the scheme is mandatory), and
then a carriage return and a line feed. (See the below sections about the
definitions of the send and receive subprotocols. "Subprotocols" is similar
than the different methods of HTTP, such as GET and PUT.)

The server then sends the status line, which consists of a two-digit status
code, followed by a space and then the parameters (which may be empty), and
then another carriage return and line feed. Parameters are separated by
spaces, although the last parameter may include spaces (the client will
know how many parameters according to the major status code).

The URL may include a username/password (the usual format of username and
password in a URL is used); if so, the client should not display the
password (unless the user has enabled an option to tell it to not hide
passwords). The client software should also include a command to discard
any existing username/password, in order to log out.

However, if the URL contains # then the client should not include the #
and what comes afterward, since that part is only for the client.

If the host name of the URL does not match any host name that this server
serves, or if the scheme is different from this protocol, then it is a
proxy request (which the server may refuse if it wishes, due to whatever
criteria they want). Proxies should normally avoid converting the files
into a different format.

If it is not a proxy request, then the TLS and non-TLS variants of the
same protocol URI scheme should be treated as equivalent by the server
(but not by the client, which must treat them differently).

=== Status codes ===

The first digit is the major code, and the second digit is the minor code.
Clients may ignore the minor code.

0x = Interactive mode; used only for the "I" subprotocol.

1x = Requires input; the parameter is the prompt text, which it should
display to the user, and then the user enters any text, and the client
redirects to the same as the current URL but with ? added and then the text
entered by the user, which should be percent-encoded if necessary.

2x = The response is OK and the contents of the file will follow; after
this line is the data of the file. The parameters are:

* The file size in decimal notation, or ? if the size is unknown (e.g. if
it is a dynamic file).

* The file type/format. MIME has some problems and ULFI is better, but for
now, for compatibility you can use MIME; however, spaces are not allowed.
If the "charset" parameter is not included then the default according to
the file format should be used; "us-ascii" is a recommended default.

* Optionally, the version, which if present must consist only of uppercase
and lowercase letters, digits, and forward slash and plus sign. The client
should ignore this unless you are using the send subprotocol, and may need
to specify the previous version, to avoid edit conflicts. (The version is
not to be used for any other purpose.)

3x = Redirect. The parameter is another URL which it should redirect to,
which can be temporary or permanent.

4x = Temporary error. Has two parameters:

* The number of seconds which is recommended to wait before trying again;
it must be a unsigned 31-bit number, or it can be ? if it is unable to
estimate the required time before trying again.

* The error message text (optional).

5x = Permanent error. The parameter is an error message. The request should
not be repeated by automatic tasks, unless such tasks are manually reset by
the operator of the computer that controls such tasks.

6x = Client certificate required. The parameter is some text which may be
displayed to the user to specify what kind of client certificate should be
provided by the user. If the protocol is non-TLS, then this implies a
redirect to the corresponding TLS protocol if a client certificate has been
provided by the user. The user may specify which URLs the certificate can
be used for, and when to stop sending it with new requests; by default, it
should expire at the end of the session, although the user can always tell
it to remove client certificates at any time manually.

7x = Ready to receive; used only for the "S" subprotocol.

8x = Received data accepted; used only for the "S" subprotocol. The
parameters are same as for 2x but the data of the file is omitted. If
the file has been deleted then the parameters are omitted.

=== Detailed status codes ===

10 = Requires input. (This protocol does not have the 11 code that Gemini
has; putting the password in the query string isn't very good because then
it is a part of the URL and might not be hidden.)

20 = Response is OK.

21 = Response is OK, but it is only a part of the file and not the entire
file; this is used as the response of a range request. The file size
parameter is the entire file size, and not only the requested part.

30 = Temporary redirect.

31 = Permanent redirect. A client may automatically update bookmarks, etc
if this feature has not been disabled by the user.

40 = Temporary error with a not more specific code.

41 = Down for maintenance.

42 = A dynamic file has an unexpected temporary error such as time out.

43 = Proxy error; this request requires the server to make another
connection, but it is unable to do so, or is able to connect but cannot
receive a valid response.

44 = Slow down; the client is sending requests too fast and should wait
before trying again.

45 = Temporarily locked file; used with the "S" subprotocol.

50 = Permanent error with a not more specific code.

51 = File not found (maybe it is at Area 51).

52 = The file does not exist (probabily because it has been deliberately
removed) and is not expected to exist again; clients should remember this
and not request it again automatically. (This code also means a permanently
locked file, if used with the "S" subprotocol.)

53 = A proxied request was refused by the server. A server MAY also use
this status code if a username/password have been provided in the URL but
are not required to access this file (this is to simplify the server
implementation, so that it can check that it is not its own name and
therefore refuse the request).

54 = Forbidden request.

55 = Edit conflict; used with the "S" subprotocol.

59 = Bad request. This can be used for any bad request, but if the server
does not understand the requested subprotocol then it MUST use this one.

60 = A client certificate is required to access this file, but none has
been provided.

61 = The supplied client certificate is not authorized to access this file.
The certificate may be valid to access a different file, though (possibly
but not necessarily on the same server).

62 = The supplied client certificate is not valid (e.g. because it has
expired or because the signature is not valid).

70 = Ready to receive new file.

71 = Ready to receive to replace an existing file.

80 = Accepted received data and created a new file.

81 = Accepted received data to modify an existing file.

=== Receive subprotocol ===

This is the usual subprotocol, coded as "R".

The subprotocol parameter can be blank or can be a range request. Servers
are not required to support range requests, and can respond with a 59 code
if it is not implemented.

A range request consists of two nonnegative integers in decimal notation
with - in between; these are zero-based file offsets, of the first byte to
receive, and of the first byte to not receive (e.g. "3-9" means the six
bytes, being the fourth, fifth, ..., ninth bytes of the file). The end
address can be omitted in which case it means up to the end of the file.

=== Send subprotocol ===

This subprotocol is coded as "S".

The subprotocol parameter can be omitted, but if not omitted then it is the
version of the file being replaced; this can check for edit conflicts. (The
server MAY require the version to be specified.)

The response code should not be 2x nor 8x, but can be any other code. If it
is 7x then this means it is ready for the client to upload the file. If it
is 1x or 3x then they modify the URL and mean that the upload is required to
be made to a different URL instead of the one that was initially requested.

Click here to read the complete article

Rene Kita <mail@rkta.de> wrote:
> news@zzo38computer.org.invalid wrote:
> > Here is my idea of another protocol and file format, considering what are
> > the problems with Gemini (in my opinion), and how to be better (in my
> > opinion).
> [...]
> > Please make your comments/questions/suggestions/complaints about it.
>
> Maybe you should provide a summary what problems are solved by your
> protocol. Or give me any other reason why I should read those 500+
> lines.

OK, it is a good idea. (Note that some changes have been made to the
document since the version posted on Usenet though, but the link included
with it links to the most recent version.)

* Perhaps it is something between Gemini and Spartan and HTTP in case you
think that Gemini has some problems, although some things are avoided as
well as being added.

* Many things I find they are either too simple (e.g. Ogg container format)
or too complicated (e.g. the other multimedia container formats). (This is
not only the problem of media container formats, of course.)

* I want to consider low-level programming, and not only high-level.

* Many things are similar than Gemini, e.g. most of the status codes.

* Some things have been added, e.g. telling the file size (if known), and
optional range requests.

* Some things removed or deprecated, e.g. the 11 status code is removed
because there is a better way to send passwords.

* Some things are I have decided against, for simplicity and sometimes for
other reasons.

* MIME has some problems as a file format identification. (UTI has a
different set of problems.) ULFI (unordered labels file identification) is
better, I think.

* Unicode is no good. (There are better ways to handle international text.
And, in some cases (e.g. a computer command), ASCII is better.)

* Titan isn't very good in my opinion, to have the security token in the way
that is does and put file size in the URL (rather than a separate line), and
no handling of edit conflicts, etc.

* Many things are made optional.

* What some other protocol does or does not do, does not require that this
protocol also does or does not do; it has its own reasons to do and not do.

* See also my other article I posted recently to this newsgroup, which is a
response to various criticisms of Gemini (although I also have my own
criticisms, some of which are different than the ones quoted there), which
also explains some of my reasons.

However, this summary doesn't help much; read the actual document and the
responses of criticisms for further details, please.

--
Don't laugh at the moon when it is day time in France.

Subject	Author
Another protocol	news
Re: Another protocol	Rene Kita
Re: Another protocol	news
Re: Another protocol	Iuri Rezende Souza
Re: Another protocol	news
Re: Another protocol	John

"Nuclear war can ruin your whole compile." -- Karl Lehenbauer

devel / comp.infosystems.gemini / Another protocol