Deutsch English Français Italiano |
<a9cdb9ee-9582-465e-8355-2d01a8e6b40fn@googlegroups.com> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: news@zzo38computer.org.invalid Newsgroups: comp.infosystems,comp.protocols.misc Subject: Re: Request for comments: Scorpion protocol/file-format Date: Mon, 08 Apr 2024 16:06:58 -0700 Organization: A noiseless patient Spider Lines: 147 Message-ID: <1712562630.bystand@zzo38computer.org> References: <1712084972.bystand@zzo38computer.org> <uv03l6$3bfj5$1@dont-email.me> MIME-Version: 1.0 Injection-Date: Mon, 08 Apr 2024 23:05:34 +0200 (CEST) Injection-Info: dont-email.me; posting-host="d61130d451c1195ee88a544faf7cada8"; logging-data="3980085"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18a2r0s2iY8CuGvw9ZcuWvq" User-Agent: bystand/1.3.0pre1 Cancel-Lock: sha1:kSl+w7cpLGVVt+YrDTwWUPBjLjk= Bytes: 8030 Thank you for your comments. I will try to respond to them the best that I can, and will add whatever is necessary to the FAQ as well as to modify other parts of the document as appropriate. Some of the changes mentioned below I have done; others I have partially done or not added yet. I will continue to work on it later, though. sean@conman.org wrote: > First, what is ULFI? All I bring up when I search on that is "Upper Limb > Functional Index"---I can't seem to locate anything that is close to MIME. > If you do use TLAs [1] and ETLAs [2], please define it somewhere in the > document for those who are unfamiliar with it. Thank you; I will write about it. (In this context, ULFI is short for "Unordered Labels File Identification".) > Second, URL support ... do you expect people to follow RFC-3986? > RFC-3987? Or the WHATWG living specification? RFC 3986. (However, the "hashed:" scheme has its own rules.) > Third: On TLS, methinks you underestimate how difficult it is to check > the first byte of a request is 0x16 and have an existing TLS library take > over the connection if it is. I'm not saying it's impossible, just more > technically difficult than you may think. Have you implemented a server > that supports both TLS and non-TLS support on the same port? I thought you could use recv with the MSG_PEEK flag. (However, I did not actually try that (yet). If I am wrong, then you can tell me what is wrong with that, please.) > Third the second: More TLS---those who like TLS might take offence at > support for non-TLS---an attacker can easily MITM [3] requests to force > non-TLS requests, thus defeating the purpose of TLS in the first place. An implementation may allow the user to configure it to not use non-TLS for some (or all) servers. (This is similar than "HTTPS-Everywhere", but it is not specific to HTTP(S).) Additionally, the client is supposed to display a warning message if a redirect from TLS to non-TLS (or vice-versa) occurs. I think non-TLS has benefits such as improved simplicity and improved energy efficiency. However, sometimes encryption is desirable, so TLS is permitted, too. > Third the third: There will be a subset of people who hate TLS, and > demand that you don't use it, but use some other, possibly bespoke, > encryption system instead. Before taking these people seriously, demand a > proof-of-concept and an analysis by real cryptographers before you engage > with them. It'll save time. I have considered that, and have decided against it (at least for now), for the reasons you specify, and for reasons mentioned in the Gemini FAQ (see section 4.5.3). So, for now, it uses TLS. > Third the fourth: What's with the weird SNI support? The client should > use it, but the server should not? What? Maybe it is unclear. What I mean is that the server shouldn't require SNI since the host name is included in the request anyways. However, possibly SNI might be needed for the server to present the proper certificate to the client; if that is the case, then the server may present an invalid certificate when the wrong (or no) SNI is used. > Third the fifth: What do you mean by "clients SHOULD allow to use the > system's DNS services to implement encrypted Client Hello"? And what's with > the following? "if implemented, there MUST be an option to disable this > feature." Perhaps my specification is unclear. However, I am not sure how to write it more clearly. > Fourth: impose a hard limit on clients following redirects. I know from > experience that if this isn't mandatory, no one will implement it. Even if > it is mandatory, some won't implement it, but hopefully it'll be a smaller > subset who ignore this. OK. I added it. > Fifth: Some server implementor will hard code a 2147483647 on a 4x reply, > which is 69 years. Clients will obviously ignore such a silly request, > leading to an arms race. Don't bother with a timeout value. OK, it is a good point. Even in Gemini protocol they suggested removing the time specification in a 4x reply. > Sixth: For the sub-protocol I, please use BNF for capability codes. And > what's with terminal emulators? OK, I will add that; it is a good idea. > Seventh: The Hashed URI section---what? You first said relative URLs > aren't allowed in a request, so is this meant for documents? What does the > hash buy you here? And why number the hash algorithms instead of just > listing their names? This is getting complicated, quickly. That is correct that relative URLs aren't allowed in a request, although hashed: URLs are not necessarily relative (although they can be). Anyways, it isn't useful to be used in a request (although some servers might allow them in proxied requests (if the URL after the comma is absolute), but this is generally discouraged). Its use is that links to files can specify the hash so that you can verify on the client side that the file has not changed (and that spies have not tampered with it, if the source of the hash is trustworthy). > Eighth: oh, a new document format. Nice. Binary HTML. Even better. > Big endian---I don't mind, but it's not fasionable among kids today (because > Intel won; Motorola lost and get over it Boomer!) and will be complained > about. And by "nice" I mean "oh god!" You'll get people bitching about not > being able to include control data with their favorite editors and besides, > you're redefining well defined control codes. You are NOT going to get > acceptance of this, or the following database file format. The internet is supposed to big-endian, isn't it? Although I think that small-endian is better (independently of what computers use it), I think that it isn't that significant that it is worth violating the convention of internet in this way. (Also, uxn is big-endian.) A text-based format would be much more difficult for the client to parse, to have to handle difficult escaping and nesting and other stuff like that. A binary format will be simpler, especially a "flat" one such as this one, rather than being nested like HTML and XML. There are a few possibilities for how to write the document, such as using a specialized editor, or using a converter or a static site generator. > Ninth: ".special/crawl"? Really? Not "/robots.txt"? Or > "/.wellknown/robots.txt"? Sigh. Even Gemini repurposed "/robots.txt", a > well known and supported format. But if you insist on a new format, perhaps > a example (or four) could be included? I think that there are problems with the robots.txt format, including a possible confusion of what is mandatory and optional. I will add an example because you are correct it is a good idea to do so. (I did not add it yet; sorry. I will do so later.) > Tenth: What is the purpose of ".special/conversion"? What file formats > to what file formats? Any file formats to any file formats. -- Don't laugh at the moon when it is day time in France.