Is streaming a normative protocol expectation? (was Re: Documents with mixed languages)

[Krixano]

Yes, you are right, actually, the Speculative Specification at the gemini homepage is the canonical one for the moment. The gitlab spec is for tracking changes to future versions of the spec.

What I'm frustrated with is that we have a bunch of evidence that shows that the intention has always been that clients could handle data before the close_notify, and yet people insist that this is not the case and that this is all just made-up crap being read into the spec. Intention behind what the spec says matters, because it's how we know whether the spec needs to be further clarified.
This is why I think we should absolutely refrain from judging implementations that are not "spec-compliant" based on a non-finalized *speculative* specification. Experimentation early on in Gemini was appreciated because it allowed people to test out the protocol to see what could be done with it - this included a simple change to some clients that allowed for handling of data before close_notify. There is *no doubt* in my mind that allowing this was intended. Whether the specification allows for this is another matter that needs to then be clarified. Which is why I have created a GitLab Issue here: https://gitlab.com/gemini-specification/protocol/-/issues/44

Christian Seibold

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Monday, December 13th, 2021 at 3:44 PM, romina xj ix k <gemini@xj-ix.luxe> wrote:

> On December 13, 2021 9:38:04 PM UTC, Luke Emmet luke@marmaladefoo.com wrote:
>
> > On 13-Dec-2021 20:55, Krixano wrote:
> >
> > > that portion of text no longer even being present in the latest version of the spec on gitlab: https://gitlab.com/gemini-specification/protocol/-/blob/master/specification.gmi
> >
> > Thanks for the link to the updated protocol, I was just going on the
> >
> > version on the gemini home capsule as the official version.
> >
> > Clearly whatever solderpunk puts in is what the spec is. And there is
> >
> > less said now in the current draft of the spec about the expected
> >
> > interleaving of client and server events. This leaves more room for
> >
> > servers to expect clients to process the data before it is completed.
> >
> > Still it seems unclear to me how a client can now tell between a faulty
> >
> > or excessively slow server and one that is valid but is streaming
> >
> > content very slowly. In the previous draft the expectation was the
> >
> > client waits for content, which will conclude, then it is processed. Now
> >
> > clients don't get to have a general expectation that the content will
> >
> > conclude or not as it comes down the pipe.
> >
> > Probably the best option is to try to guess whether the content might be
> >
> > a stream from the media type as spc suggests, although that seems like
> >
> > guesswork to me.
> >
> > Anyway, clients and servers probably need to have a connection timeout
> >
> > to prevent tar pits.
> >
> > regards
> >
> > -   Luke
>
> afaik the canonical spec lives on gemini.circumlunar.space not gitlab