| Age | Commit message (Collapse) | Author |
|---|
|
prop340: clarify SENDME window accounting
See merge request tpo/core/torspec!265
|
|
prop340: Expand on why we don't allow DATA fragmentation
See merge request tpo/core/torspec!264
|
|
|
|
Slight clarifications about hsv3 relay crypto
See merge request tpo/core/torspec!261
|
|
I was going to propose allowing DATA fragmentation, but I think I've
talked myself out of it. I think it'll be useful to have a record of
this line of thought for future reference.
|
|
cert-spec: Put backticks around SIGNATURE
See merge request tpo/core/torspec!263
|
|
See !259
|
|
Rename "text vectors" to "test vectors" for correctness.
See merge request tpo/core/torspec!260
|
|
There was a missing link at one point, and another point where we
should have said what cryptography we were using.
|
|
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Clarifications about INTRODUCE1/2 extensions
See merge request tpo/core/torspec!255
|
|
Prop#349: Command state validation
See merge request tpo/core/torspec!257
|
|
|
|
|
|
|
|
Completely ignore unknown hspow-params
Closes #256
See merge request tpo/core/torspec!256
|
|
|
|
hspow: Clarifications to scheme and descriptor Item
See merge request tpo/core/torspec!254
|
|
|
|
I got the answer to this question from
proposals/324-rtt-congestion-control.txt
(This thing should have a proper identifier, not merely a descriptive
phrase, but that may be controversial.)
|
|
This sentence seems stray in this section. The information is alreayd
present with the wording
The same rules for multiplicity, ordering, and handling unknown types
apply to the extension fields here as described \[EST_INTRO\] above.
which appears earlier, for each of the two sections.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The text uses "scheme" and "version" a couple of times. The formal
protocol says "type". The terminology should be consistent. IMO
"scheme" is the best word to use. "version" is particularly bad.
Change all references to "type" and "version" to "scheme".
|
|
Revise the INTRO1_POW_EXT section
See merge request tpo/core/torspec!253
|
|
There were two different versions of this description in the doc, and
they were both wrong in different ways. One was newer and implied the
extension was encoded outside the encrypted section (it's inside). The
other was older and had some outdated references and recommendations
from when this was still a proposal, but it was in the correct location.
I consolidated the two and made the correct location of the extension
explicit.
|
|
Proposal 340 clarifications
See merge request tpo/core/torspec!252
|
|
|
|
Replace "payload" with "body"
See merge request tpo/core/torspec!248
|
|
Clarify rend-point behavior with relay cells
Closes #254
See merge request tpo/core/torspec!250
|
|
Beautify the table of relay commands
See merge request tpo/core/torspec!249
|
|
|
|
Previously, we didn't actually say that relay cells got
retransmitted; we only said that the circuits were "joined".
Closes #254 by clarifying that RELAY_EARLY cells are retransmitted
as RELAY cells.
|
|
|
|
|
|
|
|
|
|
|
|
This will get us some horizontal space.
|
|
Formerly it didn't have conflux, HS, or padding commands.
|
|
We had used these terms inconsistently; "payload" was far less
common.
Part of #253.
|
|
prop340: Tweaks, clarifications, open questions.
See merge request tpo/core/torspec!170
|
|
Revisions to proposal 348
See merge request tpo/core/torspec!247
|
|
Clarify when we use CREATE_FAST
See merge request tpo/core/torspec!245
|
|
- history: Added a mailing list thread recalled by Nathan Freitas
- TURN description revised to account for single allocation
per local port.
- Revised the distinction between different Tor stream usage strategies.
I moved the "One Stream per Mapping" section up and included it as part
of a series of "One stream per Local Port" variants. In that series I
started with the standardized TURN protocol, then switched gears to
Proposal 339 and a couple further iterations on its basic idea.
|
