Proposed minor spec changes, for comment.

[plugd]

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.  And
sorry, I didn't mean to sound so defeatist!  I was just getting worried
that some of the ideas being proposed for closing exploitation holes in
text/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 conspire
together to interpret this as anything but garbage.

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

=> 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.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200522/0ead0cbb/attachment.sig>