@notjack checking in with progress on the model

I’ve made some sense of codecs without diving off the “framing” cliff.

Still need to read HTTP2 RFC

Messengers consume the transport API, which deals with byte arrays, so ~transports~ messengers are only useful with codecs that produce or consume byte arrays.

Call a byte array producer an encoder and a byte array consumer a decoder.

Then a messenger is an encoder, a decoder, and a transport.

Now we can think of encoders and decoders as pure functions of type X -> Bs and Bs -> X for any X, and we get composition for free.

So then any unary function can be a “codec.”

Let c be a pure function of type X -> Y, d a decoder of type Bs -> X, and e an encoder of type Y -> Bs.

Then c ○ d : Bs -> Y is also an encoder, and e ○ c : X -> Bs is also a decoder.

Now we can think of generally useful cs, ds, and es.

I think we’re ready to draft some docs and code stubs for URI and Transport APIs, if you wanna wing it on the URI aspect.

So far, a straght forward four-part struct would work: scheme : Symbol authority : Map Symbol String path : List Symbol query : Map Symbol String

If the URI operations handle uri-encoding and -decoding, we have a pretty clean abstraction.

Hrmm… Except maybe the authority part. That’s the ~most complex component~ part I understand least well at this point.

conveniently, the authority part is the only part of uris I want to implement for v1

it’s the minimal part needed to open connections

d’oh!

copying v1 scope from earlier convo for posterity:

• Data structures and parsers for for IP addresses (v4 and v6), DNS addresses, Racket Transport Addresses, and the parent “registered name” struct, along with authority struct
• Structs for “prefix-routable address ranges” like CIDR notation and DNS wildcards (*.<http://example.com\|example.com>)
• Transports, including a generic means of starting and ending an OpenSSL-powered TLS/SSL session over any existing transport with hostname verification in terms of the address range structs above
• Connectors and listeners, including connection pools

For v1, we can hard wire a simple schema on the dict, e.g., “key host must be associated with a string that [can / must not] be an IP address.”

But the cost is extensibility… maybe we should think that through first.

which dict do you mean?

authority

ah I was gonna make ip / DNS / others all subtypes of a common reg-name struct

I was overthinking it

The syntax for the authority part is simple.

Protocols can provide their own scheme+authority->connection-info adapters.

pretty much

(re-reading URI RFC now)

So a DNS address is a URI registered name.

The scheme can prescribe registered name resolution semantics.

right

In net2, where do we implement scheme-specific behaviors?

in some library/package/module specifically for that scheme, I think

e.g. http-specific stuff would be in net2/http

So do schemes contain protocols?

yes, I think that’s right

Or do protocols consume schemes?

the RFC 3986 idea is that a scheme is a definition of how to do stuff with some set of resources

every scheme has an RFC that registers it with the IANA

and that spec says exactly what the rest of URIs with that scheme can look like and what the bits of it mean

a scheme may choose to override parts of the generic URI RFC

or may choose to reuse as much of it as possible

but the scheme spec is the final say on what URIs with that scheme mean, how to interpret them, and how applications can consume them

so a decent way to look at it is that a scheme is a registered specification of some sort of protocol

so if somebody sends you a link, like “hey if you want to get in touch with my manager go to <somescheme://somewhere/blah?foo>” the very first thing you have to do is ask yourself “what the hell does somescheme: mean?”

if everybody is well-behaved then you can go to the IANA Scheme Registry (https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml) and search for somescheme, then you can find a link to the document registering and defining the scheme

not all scheme registrations are descriptive enough to be helpful, but at a minimum a scheme registration has to include contact information (names / email addresses) of somebody you can ask for more information

ok, so the IANA entry for HTTP is a link to the HTTP RFC

exactly

that’s easy enough to understand

So we can think of a scheme as a protocol constructor or factory.

and a protocol as a messenger constructor, and a messenger as a transport constructor.

There’s a really good RFC that’s a “best practices for new scheme registrations” and it has a lot of info about how to understand schemes

RFC 2718

The URI RFC links to it

heh I just opened it

From RFC 3986: > URI scheme specifications must define their own > syntax so that all strings matching their scheme-specific syntax will > also match the <absolute-URI> grammar

So at least the syntax is predictable.

Ok, so a scheme tells you what the other parts of a URI mean.

Including the protocol(s) necessary to interact with the resource being identified.

The RFC I’m thinking of is 7000-something, I think it’s linked to from the “updated by” section at the top of 3986

ah 7320

URI Design and Ownership

Yes that’s the one!

Wait nope there’s two

There’s that one and https://tools.ietf.org/html/rfc7595

The second is the one I was thinking of that focuses on schemes specifically