Add link to networking proposal.

[badeend]

In response to issue #370

[linclark]

I wanted to talk through the scope of this pre-proposal before merging.

As you point out, networking is a very broad topic, and different protocols make sense for different use cases. Given that, I'm thinking we should split this out into separate proposals, in the same way that we're (retroactively) splitting up proxy-wasm into its component parts, like HTTP. With this kind of split between WASI modules, runtimes can make clear which protocols they offer support for and which they don't.

[badeend]

different protocols make sense for different use cases.

Agreed. Even within the same protocol there are different use cases (TCP servers vs TCP clients).

we're (retroactively) splitting up proxy-wasm into its component parts, like HTTP.

Yes, I've read that in the readme, but I couldn't find any details beyond that statement. Do you have any pointers to where this work is happening?

Given that, I'm thinking we should split this out into separate proposals. (...) With this kind of split between WASI modules, runtimes can make clear which protocols they offer support for and which they don't.

Seems fine to me. Do you have a specific granularity in mind? (besides a split per protocol)

[linclark]

Yes, I've read that in the readme, but I couldn't find any details beyond that statement. Do you have any pointers to where this work is happening?

On the same proposal page that lists proxy-wasm, you'll see HTTP In Phase 1. This repo has not yet been filled in because it's waiting on the async work that is happening in the component model. If you're interested in the discussions around HTTP and its relationship to async, you can review the WASI meeting minutes in the meetings repo. I also expect that there will be an update on the status of the async work in this week's meeting.

Seems fine to me. Do you have a specific granularity in mind? (besides a split per protocol)

I don't have any particular split in mind. A good way to start thinking through that might be a discussion in the bi-weekly meeting. If that's something you're interested in, feel free to add an item to the agenda by filing a PR.

[badeend]

I've been thinking about what you said and have been reading up on design discussions on the various github repos. I have overhauled the proposal accordingly. TLDR:

• MVP-ified the proposal. Dropped apis that were not strictly neccessary to create a functioning TCP/UDP application.
• Added an api to resolve domain names.
• Moved apis into seperate modules, creating a "layered" structure:
  • mod socket (Functions applicable to all sockets.)
    • mod socketip (Functions applicable to Internet sockets. This for example excludes UNIX sockets.)_
      • mod socket_udp
      • mod socket_tcp
  • mod ip_resolve_address
• Clarified what is deliberately not part of the proposal.
• Clarified the security model I have in mind.

I hope the current state of the proposal better reflects the intentions of WASI. If anything, it should be a better starting point for discussion.

I've requested an agenda item to be added for the 2022-02-10 meeting. (I can't make it 2022-01-27)

[linclark]

Thanks for taking the time on the updates, and for adding the agenda item. Looking forward to talking about this all more in a couple of weeks!