Groups | Search | Server Info | Login | Register

Groups > comp.protocols.misc > #75

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

Cross-posted to 2 groups.

Show all headers | View raw

sean@conman.org wrote:
> > 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?

I explained more below, because you had written another comment below.

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

Implementation simplicity is more important for mandatory parts than for
optional parts. Of course TLS is itself complicated, which is one of the
reasons for being made optional (although there are other reasons too).

I will try the implementation; so far I have not implemented TLS in the
server side at all. However, this will require more changes just to make
it work with TLS at all, so itmight take a while before I will manage to
implement this. (Other people are free to write their own implementations,
and if they want to implement TLS, then they will try this instead.)

(I have once accessed a HTTPS server that does support this actually,
although after sending an unencrypted HTTP request on port 443, I received
a valid HTTP response but it was just an error message that says that
unencrypted requests on port 443 are not allowed.)

> >>   Fourth:  impose a hard limit on clients following redirects ...
> > OK. I added it.
> 
>   Not strong enough.  In RFC-speak, MUST is stronger (mandatory) than
> SHOULD.

It says:
  If the number of consecutive redirects exceed the limit (which MUST be
  not more than five by default, although it may be configurable by the
  user), then the client MUST NOT automatically follow further redirects.

It does say MUST.

> >>   Sixth:  For the sub-protocol I ...
> > OK, I will add that; it is a good idea.
>   You still lack a description of what this is used for.  

The document does explain what it is used for. (If it is unclear, then
hopefully someone who can explain it better, is able to do so.)

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

That depends on where (and when) you got the hash from.

(The hash is useful for other purposes too, such as for caching, for finding
another copy of the file (if someone has it indexed by its hash then you can
verify that it is correct), verifying that if you linked to a file that the
file has not been changed since then, etc.)

TLS does not prevent the server operator from changing the files to
malicious ones, nor does it prevent some other stuff; TLS does not (and
cannot) solve everything.

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

I understand, but it isn't really a significant issue.

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

It is not generally necessary for implementations to compare ULFI for
equality. If you are looking for a piece with a specific name then you
will find it. (This is also true if you are looking for multiple names.)

It is possible that there are multiple names that an implementation will
recognize, with different meanings in each case (it is also possible that
it will treat multiples with the same meanings), and it might define the
priorities to decide which one to use (or use them together if they can).

As one example where it might use multiples at once, a EPUB file is also
a ZIP file, and you can easily specify both, so that an implementation that
can open ZIP archives but not EPUB can still display the ZIP archive (there
might also be some command for the user to select explicitly which one to
use if both are implemented, but usually the implementation would make one
of them to have priority). MIME does have such a mechanism too, but it
seems to be just "added on" and is not a clean way to do it, in my opinion.

Another alternative than MIME is UTI (used by Apple), which can specify
that a type conforms one or more other types. However, this has its own
problems, such as you will need all of the definitions in order to compare
them, and there are no parameters, and it will always be required to be
exactly one that conforms with one or more others (doing it this way is
sometimes wrong; e.g. a PostScript file can be text or binary and can be
considered as a document or as a program).

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

It is only because the existing editor is not written yet; people can try to
do so if you like to do. A converter program does already exist, so that is
another way to be done.

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

It is both the protocol specification and file format specification.

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

I am aware of this, and I am one of the people who have suggested the use
of ASCII separated values.

-- 
Don't laugh at the moon when it is day time in France.

Back to comp.protocols.misc | Previous | Next — Previous 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