[spec] Oustanding issues
solderpunk at posteo.net
Sun Dec 27 10:47:01 GMT 2020
I'm trying to prepare a list of spec issues that I want to finalise as
soon as possible. I probably should have been more disciplined about
this, but the high traffic rate of the mailing list combined with the
fact that an awful lot of the discussion is about stuff that I'm not
interested in means I've kind of lost track of the important things.
Below is everything I'm aware of which has been previously raised which
I think is worthy of some kind of consideration/response. If you think
I've forgotten something, please let me know.
In arbitrary order:
* Obviously, the ongoing IRI vs URI issue.
* Clarification on the use of TLS close_notify has been requested.
This is actually mandated by both TLS 1.2 and 1.3 specs so technically
it's redundant to mention it in the Gemini spec, but given how poorly
implemented it is, some explicit reminding could not hurt. I think
there's a tiny wrinkle to consider here on *when* the client should
send this (due to a change in semantics between TLS 1.2 and 1.3).
* The question of how to handle fragments in redirects. I suppose a
similar question applies for queries, actually.
* The spec is a bit vague on under which circumstances the META part of
a response header may be empty, and on exactly what that means (e.g.
is a tab after the status code still required in any case?). This
needs to be tightened up, and I'm pretty sure this should be done by
just making non-empty META a requirement.
* There's been a request for recommendations on logging of queries. I
think this is out of scope for the itself, but an entirely
appropriate thing to mention in either the Best Practices document or
a separate companion standard for standard logging format.
* Sean has asked for the spec to require a redirect follow limit in
clients, rather than this just being a recommendation in the BP
* There was discussion of using a new 2x status code to convey
information about cacheability of content. I'm pretty sure I don't
want this, but I do feel a need to actually give a justification for
* There was discussion of using a new 2x status code to convey that a
resource is a stream. I'm not sure I want this (though less sure than
the cache thing), but at the very least the spec could use a bit of
clarity about the potential for content to be streamed. I know
streams are not universally popular, but there is little practical
difference between a stream and a large but finite file served over a
"jerky" internet connection, and it's very hard to actually explicitly
disallow streams, so I think they are here to stay. At the absolute
minimum, the BP document should mention that buffering responses up in
memory until they are complete and then processing them is a fragile
(but valid and, in practice, workable) approach.
* There's this long-standing issue of the fact that none of the
character sequences which identify the start of a non-text line type
were originally defined with spaces after them, but we've added that
requirement hodge-podge as ambiguities have appeared, and now we're in
a situation where half the line types need them and half don't.
Consistency suggests we require spaces everywhere, but this has been
surprisingly controversial and may break some things. But a final
ruling is required.
Most of these are not anywhere near as major as the IRI issue. I hope
to get all the non-IRI things sorted out in the next week or so. In
some cases I may start new threads here asking for feedback. In simpler
cases I might just make decrees.
More information about the Gemini