[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[minion-cvs] clean up dir-spec somewhat
Update of /home/minion/cvsroot/doc/spec
In directory moria.mit.edu:/home2/arma/work/minion/doc/spec
Modified Files:
dir-spec.txt
Log Message:
clean up dir-spec somewhat
Index: dir-spec.txt
===================================================================
RCS file: /home/minion/cvsroot/doc/spec/dir-spec.txt,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -d -r1.10 -r1.11
--- dir-spec.txt 28 Jul 2003 00:49:08 -0000 1.10
+++ dir-spec.txt 2 Sep 2003 22:04:07 -0000 1.11
@@ -98,21 +98,23 @@
Formally, a Mix Information Message is a sequence of ASCII
characters, consisting of zero or more Sections. Each Section
contains a Header, and one or more Entries. Each Header consists
- of an left square-bracket ('[', ASCII 91), an Identifier, a right
+ of a left square-bracket ('[', ASCII 91), an Identifier, a right
square-bracket (']', ASCII 93), and an EOL. Each Entry consists of
an Identifier, a colon (':', ASCII 58), a Space, a Value, and an
EOL. An Identifier is a sequence of one or more printable nonspace
characters other than colon and brackets (ASCII 33-57, 59-90, 92,
- 94-126 inclusive). A Space is a sequence of one or more space ('
- ', ASCII 32) or tab ('\t' ASCII 9) characters. A Value is a
- sequence of zero or more printing ASCII characters, excluding NL
+ 94-126 inclusive). A Space is a sequence of one or more tab ('\t',
+ ASCII 9) or space (' ', ASCII 32) characters. A Value is a sequence
+ of zero or more printing ASCII characters, excluding NL
and CR (ASCII 9, 32-126 inclusive), and not beginning with a space
or a tab. An EOL is an optional Space, followed by either a CR
- ('\r', ASCII 13), an NL ('\n', ASCII 10), or a CR-NL sequence.
+ ('\r', ASCII 13), a NL ('\n', ASCII 10), or a CR-NL sequence.
[XXXX Is there any reason to handle non-ASCII here? I don't want to
walk down the road of having a dozen competing charsets and
encodings. -NM]
+ [XXXX Everybody using Minion is going to support ASCII, so I think
+ it's fine to make them use it here. -RD]
Here is a grammar, using C syntax for characters:
@@ -152,7 +154,7 @@
processors of Mix Information Exchange Messages MUST behave as
follows when encountering unrecognized headers or entries.
- When processessing a section with an unrecognized identifier, the
+ When processing a section with an unrecognized identifier, the
processor must ignore the section completely.
When processing a section with a recognized identifier, the
@@ -186,13 +188,13 @@
both styles and generate only ISO-style. Version 0.0.7 will
accept and generate only ISO style.]
- - All binary data is base-64 encoded, with all linebreaks and space
- removed.
+ - All binary data is base-64 encoded (with no whitespace, as
+ recommended by RFC 3548).
- All boolean values are encoded as 'yes' or 'no'.
- All RSA public keys are first encoded to binary with ASN.1, then
- encoded in base-64, with all linebreaks and space removed.
+ encoded in base-64 (again with no whitespace).
- 'Address Patterns' are encoded according to the following
grammar:
@@ -221,7 +223,7 @@
- Second, the message is converted to a "stub" format: the values
of any unsigned entries in the message are replaced with the
empty string. (Their entry lines now contain an identifier, a
- colon, a single ' ' character, and single a NL character.)
+ colon, a single ' ' character, and a single NL character.)
- Third, a SHA-1 digest is computed over the resulting stub
message.
@@ -241,7 +243,7 @@
The first section must be a 'Server' section. This section MUST
include each of the following entries in any order, exactly once.
- 'Descriptor-Version': the string "1.0".
+ 'Descriptor-Version': the string '1.0'
'Nickname': A human-readable identifier for this server. It
MUST be no more than 128 characters. It MUST contain only
@@ -270,8 +272,8 @@
descriptor. This date MUST be at least one day after the
date in Valid-After.
- 'Packet-Key': The public key used to encode encode subheaders
- for Type-III packets.
+ 'Packet-Key': The public key used to encode subheaders for
+ Type-III packets.
'Packet-Versions': A comma-separated list of allowable
major.minor versions for packets this server will process.
@@ -291,7 +293,7 @@
PGP key. Must be no more than 128 characters.
'Comments': Human-readable information about this server. Must
- be <1024 bytes long. It *must not* be necessary to read this
+ be <1024 bytes long. It MUST NOT be necessary to read this
information to use the server properly.
'Software': A string description of the software this server is
@@ -331,14 +333,15 @@
'Protocols': A comma-separated list of the versions of MMTP this
server accepts.
- The 'Incoming/MMTP' section MAY contain any number of entries of
- and any number of entries of the form:
+ The 'Incoming/MMTP' section MAY contain any number of entries of
+ the form:
'Allow': AddressPattern
'Deny': AddressPattern
- If this server supports outgoing MMTP connections, it MAY have a
- 'Outgoing/MMTP' section, with one entry each of the form:
+ If this server supports outgoing MMTP connections, it MAY have an
+ 'Outgoing/MMTP' section, with the following entries, exactly once
+ each:
'Version': The string '1.0'
@@ -354,11 +357,11 @@
These entries are order-significant; the first one to match wins.
The default policy is 'Deny: *'.
- The 'Testing' section MAY be generated some type III remailers to
- describe other information about their configuration that may be
- useful for debugging. Implementations MUST NOT require any
- specific entries or within 'Testing'; implementations also MUST
- NOT require any specific format for entries that may be present.
+ The 'Testing' section MAY be generated to describe other information
+ about their configuration that may be useful for debugging.
+ Implementations MUST NOT require any specific entries within 'Testing';
+ implementations also MUST NOT require any specific format for entries
+ that may be present.
If this server supports outgoing delivery mechanisms, it MAY have
corresponding delivery sections. See 'E2E-spec.txt' for more details
@@ -368,7 +371,7 @@
Note: A server MAY omit some of its capabilities from its descriptor.
It is permissible (for example) for a server that supports incoming
- MMTP connections to omit the Incoming/MMTP section.) A server
+ MMTP connections to omit the Incoming/MMTP section. A server
MUST NOT, however, advertise any capabilities it does not support.
3.1. Server Identity
@@ -381,7 +384,7 @@
For user convenience, a mix's Nickname also serves as a unique
identifier. Every nickname SHOULD correspond to a single identity
- key: directory servers and clients SHOULD reject descriptors that use
+ key: directory servers and clients SHOULD reject descriptors that
use the same nickname as a previously encountered descriptor but
change the identity key.
@@ -390,18 +393,18 @@
3.2. Descriptor liveness
When choosing between multiple server descriptors for the same Mix
- valid at the same time, implementations SHOULD choose the most
- recently published descriptor.
+ that are valid at the same time, implementations SHOULD choose the
+ most recently published descriptor.
The interval of time between a descriptor's 'Valid-After' and
- 'Valid-Until' dates is called its 'Lifetime'.
+ 'Valid-Until' dates is called its Lifetime.
If some descriptor's lifetime is in the past, that descriptor is said
- to be 'Expired'.
+ to be Expired.
If a descriptor's lifetime is all either in the past or contained
within the lifetimes of more recently published descriptors for the
- same server, that descriptor is said to be 'superceded'.
+ same server, that descriptor is said to be Superceded.
4. Directory Format
@@ -411,7 +414,7 @@
- A 'Directory' section,
- A 'Signature' section,
- A 'Recommended-Software' section,
- - One or more server decriptors (see section 3 above).
+ - One or more server descriptors (see section 3 above).
The 'Directory' section MUST contain the following entries:
@@ -433,7 +436,7 @@
The 'Signature' section MUST contain the following fields:
- 'DirectoryIdentity' : The Identity key of the directory server
- that generated this directory. This modulus of this key must be
+ that generated this directory. The modulus of this key must be
between 2048 and 4096 bits long, and the exponent must be 65537.
- 'DirectoryDigest' : The digest of the entire directory. The
@@ -447,7 +450,7 @@
entries:
- 'MixminionClient' : A comma-separated list of up-to-date versions
- versions of Mixminion. If a client is running a version more
+ of Mixminion. If a client is running a version more
recent than any on the list, it SHOULD issue a warning. If a
client is running a version not on the list, and some version on
the list is more recent than the client's version, the client
@@ -493,7 +496,7 @@
parameter, 'desc'.
The server MUST reply to an upload with a message of Content-Type
- test/plain, and contents of the form
+ text/plain, and contents of the form
UploadReply ::= StatusLine MessageLine
StatusLine ::= "Status: " Bit EOL
@@ -512,7 +515,7 @@
Finally, if the upload was successful, but the descriptor will only
be accepted into the directory when manually approved by the
administrator, the status MUST be 1, and the message MUST be a
- description of the status of the desctiptor, and MUST NOT be
+ description of the status of the descriptor, and MUST NOT be
'Accepted.'.
6. Generating server descriptors