RFC 7595: > A scheme name is not a “protocol.” However, like a service name as defined in Section 5 of [RFC6335], it often identifies a particular protocol or application.

So a URI scheme consists of: - a unique scheme name - possible restrictions on syntax of scheme-specific-part (per RFC 7595) - information on the kinds of resources being identified - well-defined operations on identified resources - possible restrictions on encoding and allowed characters - known interoperability considerations and incompatibilities - any security considerations

along with other registrar-ish details, like contact info and registration status.

note, in general the web follows the URL Standard much more than the RFCs (see https://url.spec.whatwg.org/)

Neat. Looks like a lot of good practical advice.

ah yes, the Other URLs

and yes @dedbox that list looks about right

I think this, or something equally plain, would make the docs easier to read and write: > Standardize on the term URL. URI and IRI are just confusing. In practice a single algorithm is used for both so keeping them distinct is not helping anyone. URL also easily wins the search result popularity contest.

@dedbox I agree 100%

I would personally rather have a terminology section in the docs with @tech terms defined for “URI”, “URL”, “URN”, “persistent global name”, and “locator”

but I think that’s because I’m focused more on machine-to-machine communication with net2 than server-to-browser communication

and then not use the terms URI and URN :stuck_out_tongue:

link relations — which I really want to build stuff with — are often best described with URNs

but I think there’s much better stuff to focus on in net2 first so just using URL everywhere is fine for v1

also hi @samth

hi @notjack

I might or might not be attempting to make http2 for racket

:p

along with @dedbox

you work on a bunch of web standards stuff right?

I am in favor

I work on JS

for a very loose definition of “work”

I think I remember seeing some comments from you in a github thing about the es6 pattern matching syntax

yes

that is not surprising

also if you’ve written ES6 modules you can blame me

The import/export syntax is very comfortable.

oh fantastic I have an outlet for that now

(kidding)

glad y’all like it

it of course wasn’t just me

but that’s the primary thing I’ve done

I left my last job (node+angular) just before es6 modules started being everywhere, and since then I haven’t done any js at all in google

so alas I haven’t gotten to use much of the es6 goodies

but the modules were probably the part I was most happy with so thank you

Just got the net2 package stub installed and docs compiled. Looks pretty good already.

:thumbsup:

where is the net2 pkg?

https://github.com/jackfirth/racket-net2

apparently private :wink:

oh, sorry. I didn’t realize.

oh right I still gotta make that public

you could just let me into the secret club

@samth ’twas only private while I waited on google legal process to make sure I had copyright ownership

so that’s why slack didn’t make the link fancy

btw gotta add a few lines to tech.rkt to make the docs compile

I think I’ve got some stuff in my local clone that I haven’t pushed yet

@@ -17,7 +17,10 @@ (define-tech-helpers transport-tech "transport" connector-tech "connector" - listener-tech "listener") + listener-tech "listener" + transport-pool-tech "transport pool" + disposable-pool-tech "disposable pool" + transient-tech "transient")

I can push it tonight, unless you’d like to right now

and I’m gonna make it public now - good with you @dedbox?

yes

I’ll commit the change now.

wait

actually

?

to a dev branch

some of those tech terms are defined in the disposable package (transient and disposable pool) so that tech ref won’t work as is

oh, yeah some of my links are broken. That was just to see what was in there.

gotcha

Actually, I’ll leave it alone. The patch above is small and easy to read.

voila, the repo is public

@samth https://github.com/jackfirth/racket-net2

> Currently, including identifying user info in authorites (see RFC 3986 Section 3.2.1) is not supported due to historically widespread security problems and a lack of immediate use cases.

git@github.com:jackfirth/racket-net2.git

use case?

not sure if that’s something git/github specific or part of an http url

certainly not immediate, in either case

The https equivalent does not have the username. <https://github.com/jackfirth/racket-net2.git>

¯_(ツ)_/¯

unrelated: decided to rename “racket transport addresses” to “virtual addresses” since really all that’s important about them is that they’re addresses in some sort of software-defined network with reliable transport

I like it.

I want to port axon to other languages, so that’s convenient for me.

format I’m thinking of:

• virtual address is 64 bits so it fits into a long in most languages+platforms (32 bits seems too low for, say, a giant Erlang cluster where every process has an address)
• string form of virtual address is virt.<hex-encoded-bits> so implementations can read them one byte at a time if needed for prefix-routing
• string form of prefix-routable address range is virt-range.<nibble-count>.<hex-encoded-prefix-bits> (less sure on this one) so implementations can 1) use nibble-count as a max read length, 2) use . to split into three parts, and 3) guarantee that there won’t be “extra” hex encoded bits because you have to hex encoded bits in chunks of 4 (“nibbles”)

So the address space is flat, not hierarchical. This makes sense if the virtual address spaces of racket processes are not shared. So far, that seems to be the case.

Scheme names virt and virt-range are not yet registered.

Virtual ranges seem useful for “green” fan-in and fan-out, good for many IO-bound threads. Might give us some clarity on TCP/IP ranges.

I think prefix routing would let you build hierarchical addressing on top if you wanted, but yes

also virt and virt-range would not be schemes

you’d instead have something like this:

httpv:virt.<hex>/some/resource?query

oh, they’re registered names?

oh and port numbers would still be a thing so the same address could have multiple listeners

yes

Could we “upgrade” our HTTP scheme to support virtual addresses as registered names, or is that considered not playing well with others?

that would be the latter, because it makes it ambiguous - a virtual address could also be a dns address so it becomes unclear which one to use

RFC 7595 explains this, I think.