First pass comments on /home/dave/mcp2.html

["Jay A. Carlson" <nop@kagoona.mitre.org>]

Dave pestered me to write down what I had previously said online 
about http://www.ccs.neu.edu/home/dave/mcp2.html.  I have a flock of 
managers chasing me with action items, so I'm going to keep this 
terse.  You'll certainly need a copy of mcp2.html in order to follow 
along.

| It is expressed in 7-bit ASCII, permitting it to be carried over 
channels with restricted character sets. 

At some point we're gonna ISO Latin-1ify the server; I dunno if this 
needs to be rephrased in light of this.

| Messages 
|
| The basic unit of MCP communication, messages are single lines 
terminated by a carriage return. The MCP protocol does not impose a 
message-length restriction. 

That's incorrect, I think.  Messages are presently network-newline 
separated records of printable ASCII (well plus space and tab) 
characters.  I skipped this problem in my rewrite by simply claiming 
that framing was defined elsewhere.

| The authentication key is generated at the beginning of the 
session; if it is incorrect, the message should be ignored.
| Implementations should reject any message containing a key which 
does not match their stored copy.

I still like the old capability of letting the client decide whether 
it wants to process a keyless message (no doubt based on preference 
settings) since it allows two major levels of trustedness server 
side.  Also, really archaic environments like MUSH would be 
(slightly) easier to retrofit insecure MCP to if keys weren't defined 
as "must".

| Values that match the syntax of a number or an identifier

Those two terms aren't defined here, of course.

| If an unrecognized or mangled MCP request is received, the 
implementation should either silently drop it on the floor, or notify 
the user in some reasonably unobtrusive way.

I'd like to point out that this policy solves a lot of horrible race 
conditions.  Trust me.

| #$#mcp min-version: 2.0 max-version: 2.0

We have a really gross authentication capability negotiation 
indicated here by authentication: 1.  I hope it's going away.

Also, we use #$#mcp version: 2.0 [to: 2.1] for our keywords as this 
is a little less annoying to telnet-only users.

| #$#mcp-negotiate-can

We just use #$#protocol name: spam from: 1.0 to: 2.0 here.

| The mcp-negotiate-required message is used to indicate that a 
required protocol was not  advertised. Generally, this message will 
be sent when the server is aware of the existence of a protocol for 
which it has not received an mcp-negotiate-can message from the 
client;

Given that the negotiation phase NEVER ENDS I'm not sure you can do 
this.

| #$#mcp-protocol-required protocol: edit min-version: 1.0 
max-version: 1.0

Why don't we make this a protocol that can be negotiated for 
separately?  I don't understand the semantics (even after all the 
explanatory text later), and it seems orthogonal to the core of 
protocol negotiation.

| The semantics of [cord type] "is understood" are fuzzy

I see the initial cord-open as connecting to a cord-type factory 
object; Smalltalk class methods, anyone?

BTW, I think behavior of cord implementations if one side 
unilaterally shuts down the cord while messages going the other way 
are still on the wire should be talked about.

| Appendix: BNF Grammar

The only glaring thing I see here is that <value> allows unquoted 
values with : characters in them.  If we prohibit that character from 
appearing nonquoted,

  a) we detect when some busted MCP implementation has dropped a 
value it should have sent (although parity will certainly catch half 
these errors)
  b) we can determine the category of a clause (key or value) without 
context.  I like lexers.

Welp, this is going to be no fun to read.  Somebody wanna write up a 
nice web browser with annotation built in?

Jay (harried)