From 0b19ef1ba3c0b48262d2865e196f3cede67c4ec1 Mon Sep 17 00:00:00 2001 From: David Goulet Date: Wed, 4 May 2022 13:36:29 -0400 Subject: prop339: Fix couple typos Signed-off-by: David Goulet --- proposals/339-udp-over-tor.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/proposals/339-udp-over-tor.md b/proposals/339-udp-over-tor.md index e85d0f2..adacf30 100644 --- a/proposals/339-udp-over-tor.md +++ b/proposals/339-udp-over-tor.md @@ -100,7 +100,7 @@ a while, to know when we can treat a stream as definitively gone-away.) Optimistic traffic is permitted as with TCP streams: a client MAY send `DATAGRAM` messages immediately after its `BIND_UDP` message, without -waiting for a `CONNECTED`. These are dropped if the `BIND` fails. +waiting for a `CONNECTED`. These are dropped if the `BIND_UDP` fails. Clients and exits MAY drop incoming datagrams if their stream or circuit buffers are too full. (Once a DATAGRAM message has been sent @@ -249,7 +249,7 @@ Because of security concerns I don't suggest that we support unconnected sockets in the first version of this protocol. But _if we did_, here's how I'd suggest we do it. -1. We would add a new "`FLAG_UNCONNECTED`" flag for `BIND_UDP` messaages. +1. We would add a new "`FLAG_UNCONNECTED`" flag for `BIND_UDP` messages. 2. We would designate the ANY addresses 0.0.0.0:0 and [::]:0 as permitted in `BIND_UDP` messages, and as indicating unconnected sockets. These would @@ -278,7 +278,6 @@ p4u accept PortList p6u accept PortList ``` - (We need to include the policies in relay descriptors so that the authorities can include them in the microdescriptors when voting.) @@ -293,7 +292,6 @@ would not necessarily mean that they permitted datagram streams, if their exit policies did not say so. - # MTU notes and issues Internet time. I might have this wrong. -- cgit v1.2.3-54-g00ecf