Groups | Search | Server Info | Login | Register

Groups > comp.infosystems > #143

Re: Request for comments: Scorpion protocol/file-format

Cross-posted to 2 groups.

Show all headers | View raw

In comp.infosystems news@zzo38computer.org.invalid wrote:
> 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".)

  You go into some detail, but not enough to answer "what is this for?"  It
looks like it's supposed to replace MIME but ... how?  There are no
examples, and a web search only brings up references to unordered lists in
HTML.

>>   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.)

  You aren't wrong, but uch a method isn't mentioned that much (if at all)
in most networking tutorials, and if you are going for implementation
simplicity (which you haven't explicitly stated) then yes, this is "more
technically difficult than you may think."  I would try an implemention
before pushing for this myself.  This was never done for HTTP---I wonder
why?

>>   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.

  Not strong enough.  In RFC-speak, MUST is stronger (mandatory) than
SHOULD.

>>   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.

  You still lack a description of what this is used for.  

>>   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.
> 
> 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).

  "Spies" that tamper with the file on the server can just as easily tamper
with the hash.  Tampering in transit is protected though.

>>   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.)

  Yes, most networking protocols for the Internet are big-endian, but man,
do people complain about it now that Intel won.  Besides, there are file
formats, like ZIP files, that are little-endian in nature.  I'm not arguing
for little-endian (like I said, I like big-endian myself).  I'm just saying
be prepared for pushback on this.

> A text-based format would be much more difficult for the client to parse, to

  And yet, in ULFI section, you have people parsing

	a.b:c	SAME AS	c:a.b
	a:b+c:d	SAME AS a:b:b.c:d

and you say "text-based format would be much more difficult for the client
to parse" with a straight face?  

> 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.

  One of the big complaints about text/gemini is the lack of nested lists.

> 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.

  From arguments I've seen about binary-data in otherwise text documents
[3], if it's can't be done in an existing editor, it's a non-starter.

>>   Tenth:  What is the purpose of ".special/conversion"?  What file formats
>> to what file formats?  
> 
> Any file formats to any file formats.

  Why is that a part of a *protocol* specification?

 -spc

[1]	Three Letter Acronym

[2]	Extended Three Letter Acronym

[3]	Whenever CSV (Comma separated values) files come up on Hacker News
	or Lobste.rs, inevitably, someone will mention that ASCII defines
	four explicit separator characters, FS (File Separator), GS (Group
	Separator), RS (Record Separator) and US (Unit Separator) and the
	use of those will fix most problems with CSV.  The pushback comes
	when opponents of ASCII separators claim a file that uses such
	characters can't be edited in a normal text editor so STFU!  It's so
	bad that people who push for TSV (Tab separated values) will get
	pushback for the (ab)use of tabs in a text file.

Back to comp.infosystems | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Request for comments: Scorpion protocol/file-format news@zzo38computer.org.invalid - 2024-04-07 18:04 -0700
  Re: Request for comments: Scorpion protocol/file-format sean@conman.org - 2024-04-08 06:42 +0000
    Re: Request for comments: Scorpion protocol/file-format news@zzo38computer.org.invalid - 2024-04-08 16:06 -0700
      Re: Request for comments: Scorpion protocol/file-format sean@conman.org - 2024-04-09 04:06 +0000
        Re: Request for comments: Scorpion protocol/file-format news@zzo38computer.org.invalid - 2024-04-10 16:01 -0700

csiph-web