More silly text/gemini spec proposals

[Sean Conner]

It was thus said that the Great solderpunk once stated:
> On Fri, May 29, 2020 at 09:35:20AM +0000, solderpunk wrote:
> > On Fri, May 29, 2020 at 06:34:29AM +0200, Petite Abeille wrote:
> >  
> > > Ohhh...  shiny! 
> > > 
> > > data: urls could be perhaps an interesting way to inline content in text/gemini... LOLcats at long last! :D
> > > 
> > > Let's see what else is hiding in those marvelous URI schemes:
> > 
> > ...let's not take delight in actively trying to crush the spirit of this
> > thing?  I mean, the web is right there if that's what you want.
> 
> Ugh, sorry about this email.  I was irritable from a lack of good sleep
> and waking up to a whole slew of posts here about extra complications,
> just as I was starting to feel we were at last approaching a kind of
> "cross the t's and dot the lowercase j's" state where there wasn't much
> left to add.  But I have no idea what your intended tone was and it may
> well have just been tongue in cheek.  Mostly I was just annoyed at
> learning that these data:// URLs exist.  I hadn't been aware of them.
> And frankly...what the hell?  Who thought it was a good idea to turn a
> harmless way to indicate *where* some data can be found into a way to
> shoehorn in the data itself?  What are we supposed to use in a context
> where we don't want that to be a possibility?  Bah!

  As I mentioned in my previous email, data: URIs can be "followed" just as
any other URI, it's just that the data has already been "pre-cached" so to
speak.  And since it comes with a MIME-type as part of the scheme, it can be
displayed in a client as any other MIME-type, just not automatically
inlined.

  And trying to whitelist "acceptable" URI schemes is pointless as there are
scores of schemes that are defined:

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

not all of which actually point to a resource, like urn: (RFC-8141).  And
speaking of urn:, it's specification states (section 4.1):

   Because a URN is, syntactically, a URI under the "urn" scheme, in
   theory a URN can be placed in any protocol slot that allows for a URI
   (to name just a few, the "href" and "src" attributes in HTML, the
   base element in HTML, the "xml:base" attribute in XML [XML-BASE], and
   the "xmlns" attribute in XML for XML namespace names [XML-NAMES]).

   However, this does not imply that, semantically, it always makes
   sense in practice to place a URN in a given URI protocol slot; in
   particular, because a URN might not specify the location of a
   resource or even point indirectly to one, it might not be appropriate
   to place a URN in a URI protocol slot that points to a resource
   (e.g., the aforementioned "href" and "src" attributes).

   Ultimately, guidelines regarding when it is appropriate to use URIs
   under the "urn" scheme (or any other scheme) are the responsibility
   of specifications for individual URI protocol slots (e.g., the
   specification for the "xml:base" attribute in XML might recommend
   that it is inappropriate to use URNs in that protocol slot).  This
   specification cannot possibly anticipate all of the relevant cases,
   and it is not the place of this specification to require or restrict
   usage for individual protocol slots.

  So it might be prudent to state in the Gemini spec that

	1) urn: is not a valid URI type for links, and
	2) NO INLINING OF LINKS ALLOWED [1].

  -spc (You have my permission to do so 8-)

[1]	I have more to say about this in an upcoming email.