Re: A few quick questions

[Nick Mathewson <nickm@alum.mit.edu>]

On Wed, 2002-09-25 at 11:07, P.J. McIntyre wrote: 
 [...]
> 1)the "mixmion architecture" document seems quite out of date in
> comparison with the "unresovled issues" one (cf section 4 of the first
> document). I take it that the "unresolved issues" doc is closer to a
> final version?

That's not the 'unresolved isssues' doc; that's the current spec:
    \title{Type III (Mixminion) MIX Protocol Specifications}
  
The "unresolved issues" section just happens to come first. :)

You can ignore MixMin-arch-2.tex: that's old.  You can also ignore
minion-design.*: that's a paper for publication, not our actual spec.

> 2)In the "header structure" section about half way through just below
> "calculate the junk..." HASH is called with two arguments twice (see
> both the following lines). I take it take the comma should be a | ?

Correct; patched.

> 3)<deleted>
> 
> 4)Near the bottom of the section ESHS is called with 8 arguments, but is
> specified as only taking 7. The way it is called passes it an apparently
> uninitialised variable "F": I take it this is a typo?

Yes; patched.

> 5)<Deleted>
> 
> 6)The Routing Info field: other than the TAG what can this field contain? 

The interpretation of RI depends on the routing type.  For FWD and
SWAP-FWD, the RI contains _only_  the IP, port, and MMTP keyid of the
next server. 

For SMTP and MBOX, see the table at the start of \subsection{Routing
Information}.  SMTP requires an email address; MBOX requires a username.

> And, related, there doesn't seem to be any input for generating headers 
> which would give you info for putting in either this field or Routing Type 
> (at the least there ought to be some way to specify MBOX and SWAP?)

Do you mean SMTP?  You always want the last subheader in the first chain
to be SWAP.  

The procedure "Create a single header" has a "routing type and
information of last header" input.  The step where it's used ("set
appropriate routng type and A_i) should probably be more explicit.

> 7)In the "constructing messages" section of the the "unresolved issues" 
> document in the line that starts "Process: // Phase 1 if ... " SPRPeNC is 
> called with two arguments, but is specified as requiring three. What should 
> the third be/have I completely misunderstood?

Correct; patched.

> 8)On the line below ther is an else just after an "end": It appears to be 
> orphaned!

Correct; patched.


BTW, everyone: I think we should definitely rework the flow of the
entire spec once we have our current E2E issues figured out.  It's
getting unreadable to the uninitiated.  (Let's not do it till then,
though, since most of what we currently say about SURB generation, RI
fields, message generation, and message decoding will need to be
updated.)

-- 
Nick