Re: well, here it is friday...

[Dave Kormann <davek@research.att.com>]

okokok, i addressed a bunch of jay's comments in the spec.  latest
update is in the usual place.

specific comments re jay's comments:

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

ok; i rewrote a chunk of this; i punted the 'other conventions' part
for now.  can you live without that statement?  i think it overly
complicates things.

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

ok; deleted that statement and merged the rest with the paragraph
above it.  it's kinda ugly now, and i'll probably tighten up the
wording a bit.

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

errrrrrrrrr, i think i _do_.  the sense of that statement is that
'these are the exceptions to case insensitivity'.  for the
'case-sensitive compares' part, compares on what?  the paragraph seems
pretty clear on the fact that message names and argument keywords are
case-insensitive, and auth-keys and argument values are
case-sensitive.

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

they should be explicitly case-sensitive.  fixed, and changed the
example to make it more obvious that a data-tag need not be a number.


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

this is already fixed in my copy.

 > 
 >> [...] (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.
 > 
 > Perhaps a note that this subsumes traditional uses of "x-foo" as a 
 > prefix for private protocols?
 > 

ok, did these, after a fashion.

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

okokok, noted that you can block processing any message _except_
mcp-negotiate-can until receipt of a negotiate-end.  this seems like a
somewhat backwards way of wording this, but i think it's reasonably
clear what we mean.
				dk