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

[Erik Ostrom <eostrom@research.att.com>]

Thanks for posting, Jay.  Responses:

> | 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.

I don't think so, unless you mean to say that MCP should carry ISO
Latin-1, in which case uhh we should discuss that.  If "7-bit ASCII"
is wrong for that case, it's probably wrong now; we might be able to
let this rest, since it's not really intended as a formal description
of the character set.

> | 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.

This sounds right, except, do we include tab?

> side.  Also, really archaic environments like MUSH would be 
> (slightly) easier to retrofit insecure MCP to if keys weren't defined 
> as "must".

How so?

> | Values that match the syntax of a number or an identifier
> 
> Those two terms aren't defined here, of course.

Right, this should say something to the effect of "see below".  It
might also help to point out values in the above example that are
identifiers and values that aren't.  (I'm not really comfortable with
this whole "identifier"/"number" thing, but oh well.)

Enh.  There must be a better way to phrase and/or do this part.

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

Yep.  (Although it has other problems.)

> | #$#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.

Me too.

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

Yeesh, wish you'd told us that back in Boston.  I have no strong
objection to using that instead, though.

> | #$#mcp-negotiate-can
> 
> We just use #$#protocol name: spam from: 1.0 to: 2.0 here.

No opinion.

> | 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.

Sure you can.  If the server has not received the 'can' message, and
requires a protocol (whatever that means), it sends 'required'.  If
the client actually had it and the server just hadn't received the
'can' message, then the client at this point ignores the 'required'
message.  (To the server, this looks like `I sent "required" and the
client obtained the protocol and sent "can".')

> | #$#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.

Me too.  I can usually get it by sort of unfocusing my eyes and
staring at it until a third dimension suddenly pops into view, though.

> | 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?

I don't understand this.

> 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.

Okay.  My understanding is that the endpoint that shut down the cord,
which is now receiving messages on a cord it thinks is closed, should
just drop said messages.

If your application is such that the still-sending party needs to know
when the other side stopped listening, I think you need to work that
out within the application.  (Top of head, I think you probably need
ACK messages anyway, since you need to deal with the possibility of
the other side losing net.)

> | 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,

Sounds good.

Apologies for typos, telnet sucks for text editing (even with emacs on
the other end)

--Erik