Uploading Gemini content
sean at conman.org
Sun Jun 14 04:11:19 BST 2020
To begin with, I'm going with the titan: scheme, to ensure that this isn't
mixed up with the gemini: scheme itself.
This proposal is mostly based upon a new URL scheme, and I've spent the
day diving deep into RFC-7595 (URI Scheme Guidelines June 2015, current
standard). First, the good news---gemini fits the spec for a "Permanent
Status" with the IETF. Next, these bits from the RFC:
The URI syntax provides a federated and extensible naming system,
where each scheme's specification can further restrict the syntax
and define the semantics of identifiers using that scheme.
Note: It is perfectly valid to say that "no operation apart from GET
is defined for this URI."
Both are quite good for the current definition of the gemini: scheme.
It's some other bits from section 3.4 that bodes somewhat well for the
current proposal (with a new scheme) under consideration:
It is also valid to say that "there's only one operation defined for
this URI, and it's not very GET-like." The important point is that
what is defined on this scheme is described ... The default
invocation, or dereferencing, of a URI SHOULD be "safe" in the sense
described by Section 3.4 of [W3CWebArch]; i.e., performing such an
invocation should not incur any additional obligations by doing so.
So doing a non-GET method based on a scheme is okay. That's the one thing
I was worried about, as I looked over all the currently registered schemes
 appear to *only* specify a location, not an action and a location. So
the following are "okay" (ish) per the spec:
Further more, from RFC-6335 (Service Name and Port Number Procedures
August 2011), section 5:
There may be more than one service name associated with a particular
transport protocol and port. There are three ways that such port
number overloading can occur:
o Overloading occurs when one service is an extension of another
service, and an in-band mechanism exists for determining if the
extension is present or not.
So I'm still "okay" (ish) with the new URL schemes.
I rejected the following URL:
While it's cute, and syntatically correct, semantically it's quite a
stretch---it's not a "user", it's a "command", which doesn't semantically
follow as a user nor a location. It's too much of an abuse for my liking.
Semantically, I would probably treat these three new schemes differently.
The first, titan+post: (or titan-post: which is easier to type) would be:
The size and MIME types are part of the query string, as the data being
uploaded is *NOT* a replacement of a resource on the server, must data for a
service to consume, so semantically, it makes sense as a query string.
Here request is being replaced---there's no "endpoint" per se to receive
the data, so query data doesn't make semantic sense. The size and MIME type
are inherent properties of the resource being uploaded, so by using the ';'
as a sub-delimeter in the path, it semantically relates to the resource.
That semantic relationship doesn't exist with a query string.
Nothing more to say, other than the resource is removed.
Upon reflection, given the semantic meanings involved, I can cut the
number of new schemes down to just one: "titan:". Here are the three
The logic goes something like this :
if the request has a query, it's an upload of data---accept data.
if the request has no query, and the path parameter (marked by ';')
if the request has no query, and the path parameter exists:
if size==0, delete the resource
if size>0, accept data and make the resource available.
So that's my current thinking (other than having a way of Gemini to
reverse the flow).
 Assuming proper authorization and data checks are made.
More information about the Gemini