Re: well, here it is friday...

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

OK, time to go over the spec again, then.

I'm still not happy with some of the definitions.  Suggested instead: 

A _session_ is a bidirectional stream of _records_, each containing 
zero or more characters.  Each direction of a session must be ordered 
and reliable, but there need not be synchronization between the two 
directions.  The standard implementation is a TCP connection with 
network newlines (ASCII CR LF) separating printable ASCII characters, 
although other conventions could be used inside of a user community 
(e.g., ISO Latin-1 over SSL, or UTF-8 inside a private record framing 
system).

> The authentication key is generated at the beginning of the session; if it is incorrect, the message should be ignored.

I suppose I can live with this, since I can suggest to people in 
either totally secure or totally losing environments that they just 
ignore the "should".  I still wish auth keys were more clearly 
optional, but hey.

> MCP messages are like function calls;

This must be rewritten or clarified.  The average reader is going to 
assume they a) are synchronous b) return something.

> Authentication keys are case sensitive, however, and implementations must preserve the case of argument values.

(I don't think you want "and".)  Are implementations required to do 
case-sensitive compares?

While we're on the subject, are data tags case-sensitive/case-preservi
ng?

> the authentication-key argument need not be numeric, and may be any value which matches the syntax of an identifier.

Maybe make "identifier" all caps or give it some kind of 
typographical distinction to show it is a formal part of the BNF?  
(Well, "ident" in that case.)

> [...] (it's likely there exist implementations of something advertising itself as
the edit protocol; [...]

I know what you're getting at but I think this sentence needs to be 
rewritten.

> Protocol names beginning with the string 'dns', followed by a valid DNS name, reversed and having periods replaced by dashes, are reserved for use by the organization controlling the DNS name.

Perhaps a note that this subsumes traditional uses of "x-foo" as a 
prefix for private protocols?

> The mcp-negotiate protocol

I'm happy with this section.  What I'd suggest re negotiate-end is 
that in v2.0 applications are allowed to delay processing anything 
but mcp-negotate-can messages after a) receiving the first 
negotiate-can AND b) sending all of their negotate-cans UNTIL they 
receive a negotiate-end.  In fact, I'd guess that many applications 
would be happier assuming that the whole sequence can-can-can-can-end 
was atomic, but I dunno if I want to get into that mess....

Jay Carlson   nop@kagoona.mitre.org    nop@nop.com
The MITRE Corporation, Bedford MA

Flat text is just *never* what you want.       ---stephen p spackman