Uploading Gemini content

[Sean Conner]

  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:

Section 1:

	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.

Section 3.4:

	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.

[W3CWebArch]	https://www.w3.org/TR/webarch/#safe-interaction

  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
[1] appear to *only* specify a location, not an action and a location.  So
the following are "okay" (ish) per the spec:

	titan+put:
	titan+post:
	titan+del:

  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:

	titan://put@example.com/path/to/new/item

  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:

	titan+post://example.com/post-handler/endpoint?size=1234&mime=text/plain

  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.

	titan+put://example.com/path/to/new/resource;size=1234&mime=text/plain

  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.

	tital+del://example.com/path/to/remove

  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
examples again:

	titan://example.com/post-handler/endpoint?size=1234&mime=text/plain
	titan://example.com/path/to/new/resource;size=1234&mime=text/plain
	titan://example.com/path/to/remove;size=0

  The logic goes something like this [2]:

	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 ';')
		doesn't exist---error.
	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).

  -spc

[1]	https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

[2]	Assuming proper authorization and data checks are made.