💾 Archived View for rawtext.club › ~sloum › geminilist › 001657.gmi captured on 2020-11-07 at 02:22:33. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Uploading Gemini content

Sean Conner 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'tmixed up with the gemini: scheme itself.

This proposal is mostly based upon a new URL scheme, and I've spent theday diving deep into RFC-7595 (URI Scheme Guidelines June 2015, currentstandard). First, the good news---gemini fits the spec for a "PermanentStatus" 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 thecurrent 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 thingI 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. Sothe following are "okay" (ish) per the spec:

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

Further more, from RFC-6335 (Service Name and Port Number ProceduresAugust 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 astretch---it's not a "user", it's a "command", which doesn't semanticallyfollow 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 beinguploaded is *NOT* a replacement of a resource on the server, must data for aservice 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 receivethe data, so query data doesn't make semantic sense. The size and MIME typeare 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 thenumber of new schemes down to just one: "titan:". Here are the threeexamples 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 toreverse the flow).

-spc

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

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