[gopher] Gopher RFC propositions
printf("Hello, World!\n");
OK, so I've followed teh discussions about the proposed changes to the RFC. To be honest, I've not read of *any* change that would actually make sense. None of the changes proposed are backwards-compatible, and they really don't help the cause at all.
Say, the MIME thingy; yeah, let's decide that MIMEs are type M. Fine. What then? No client in teh whole universe supports such a filetype. And even if they did support it, why would I use it? I can serve out menus with type 1, text with type 0, html (which is stupid) with type h etc etc. There absolutely *no* need for sending out MIME, ever. Well... except for mailing list messages. But even then Jacob's neat mbox script works way better.
Anyway.
What I would like to see is (and I'm always right, so hear me out):
* what do about teh US-ASCII vs. Latin-1 vs. UTF-8 issue?
* are PDF's really type "p", or "d" - a definite list of filetypes
* should the server end the transmission with a dot or not?
And that's about it. Those are the *real* issues I've got (and since I'm always right, the world has) with the current RFC.
Other than those, I'd like to have an way for the client to advertise it's capabilities to the server. Currently, caps.txt handles the server->client capability exchange just fine, but the other way around is impossible. Thanks to the widespread usage of NAT server->client connection is impossible, so it has to be done some other way. I tried with extra headers, but they broke some of the servers still out there.
So, here's a proposition:
C:<opens up a TCP connection to victim.com, port 70>
C:caps.txt<TAB>Charset=UTF-8&ScreenWidth=120&UserAgent=Lynx¶m1=value1
S:<sends out it's caps.txt>
S:<closes teh connection>
C:<opens up teh connection again>
C:<sends the real request>
S:<sends the reply to the real request>
S:<closes the connection>
Now, true, that will break some of the servers out there (yes, there are servers out there which cannot handle type 7 search queries). But it wouldn't really matter since they don't know about caps.txt anyway. And that way in one neat TCP session we'd get the client to advertise its properties to the server, and vice versa.
Second proposition:
Let's just forget that f*cking dot, mmkay? No dot, anywhere, ever. This doesn't break *any* of teh existing clients (yes, I've tried them all) and it won't break any of the servers either. On the positive side, we'd get rid of those text documents ending with a lone mistaken dot, and the whole confusion where no one really knows when to send the dot, or when the expect it.
As for the filetype problem, I've got a list in my sources. Not definitive, but pretty good. But I'm open for suggestions....
- Kim
_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project
Reply to: