💾 Archived View for rawtext.club › ~sloum › geminilist › 000972.gmi captured on 2020-10-31 at 15:03:47. Gemini links have been rewritten to link to archived content

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

Proposed minor spec changes, for comment.

plugd plugd at thelambdalab.xyz

Fri May 22 17:44:52 BST 2020

- - - - - - - - - - - - - - - - - - -

solderpunk writes:

On Fri, May 22, 2020 at 09:01:45AM +0200, plugd wrote:

And this is exactly what's going to happen with gemini too.

I kind of hope that it won't ever be possible for a text/gemini page to

*be* a trashpile. It's genuinely very hard to create something

"invalid". There is no concept of anything coming in opening/closing

pairs. Whitespace is always optional so it doesn't matter whether it's

there or not.

Definitely agree, at the moment it all seems very close to optimal. Andsorry, I didn't mean to sound so defeatist! I was just getting worriedthat some of the ideas being proposed for closing exploitation holes intext/gemini were of this "unenforceable" variety.

A link line where the first thing after =

can't be parsed as a URL is a

genuine invalidity, but remember that relative links are allowed, so

even:

=

one two three

is fine (a relative link to a path ending in "one", with label "two

three"). Something like:

=

foo://bar://baz:// Chew on this!

is a real problem, but it's not going to happen by accident.

True. And _all_ clients would have to go out of their way and conspiretogether to interpret this as anything but garbage.

... then again, if clients start to act defensively and ignore malformatted linklines, it wouldn't be impossible for document authors to startincorporating intentionally malformatted lines containing non-standarddirectives:

foo://bar://inline-image:cat.jpg

Has anybody developed a general theory of specification creep? :-)

Tim-------------- next part --------------A non-text attachment was scrubbed...Name: signature.ascType: application/pgp-signatureSize: 487 bytesDesc: not availableURL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200522/0ead0cbb/attachment.sig>