💾 Archived View for rawtext.club › ~sloum › geminilist › 001657.gmi captured on 2020-09-24 at 01:44:10. Gemini links have been rewritten to link to archived 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.