Groups | Search | Server Info | Login | Register

Groups > comp.infosystems > #141

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:
> I would like to see what other people's criticism of Scorpion protocol
> and file format that I had made up. It is alternative than HTTP/HTML,
> Gemini, Gopher, Spartan, etc.

  My initial response to the specification:

  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.

  Second, URL support ... do you expect people to follow RFC-3986? 
RFC-3987?  Or the WHATWG living specification?

  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?

  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.

  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.

  Third the fourth:  What's with the weird SNI support?  The client should
use it, but the server should not?  What?

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

  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.

  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.  

  Sixth:  For the sub-protocol I, please use BNF for capability codes.  And
what's with terminal emulators?

  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.

  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.

  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?

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

  Thus ends my initial reaction to the specification.

  -spc

[1]	Three Letter Acronym

[2]	Extended Three Letter Acronym

[3]	Man-in-the-Middle

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