[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

re: Some comments on the spec...

whoosh.  i think i've got a start on making some of the changes vijay
suggested.  i quite agree that the document could use help in clarity
and coherence, but i don't want to substantially delay release to the
moo community at least.

dealing with the comments in turn:
 > 1. [Definition of in-band lines] If you are going to use the
 >    notion of a line being quoted, you should define it, or have a
 >    forward reference to the place where you are defining it so
 >    that it is clear that this is a technically precise term.
 >    [I am going to argue that there should be no such quoting.]

i made the definitions of in-band and out-of-band lines state
specifically what their formats are, and what a quoted string looks
like.  this should help with this problem.

 > 2. [Definition of Messages] Awkward text. Suggested rephrasing:
 >     An MCP {\em message} is of two kinds. It may consist of a
 >     single message line, which specifies the name of the message,
 >     and a set of keywords, with their values. If any of the keywords are
 >     marked to be {\em multiline}, the message may contain zero
 >     or more {\em message-continuation} lines (specifying the
 >     values for the multiline keywords), followed by a single {\em
 >     multiline-end} message line. 

still working on this rewording.

 > 3. [Network Line Translation section]
[comments elided]
as near as i can tell, the problem here was primarily one of
phrasing.  i think it's improved now.  let me know if it still is

 >  4. [Message Format]

i'm working on cleaning up this section, according to vijay's

 >     Isnt the authkey supposed to be optional? The BNF says so.

nope.  the BNF was wrong.  the only place the authkey need not appear
is in the initial exchange of mcp messages; i've noted this in the
section on authkeys.

the rest of the comments in this section will hafta wait until the
rewrite is done.

 >  5. [A note on version ranges] 
 >     This suffers from a semantical problem. May be too late to
 >     fix though. 

i'm with erik on this: we punt to a naming authority and documentation
for the shared (non-DNS) namespaces.

 >   6. [Authentication Keys]
 >     Typo at end of paragraph "In choosing an authentication
 >     key...". 

this is fixed, i think.

 >   7. [mcp-negotiate package]
 >     Probably worth saying explicitly:
 >     An endpoint must ignore any mcp-negotiate-can or
 >     mcp-negotiate-end messages received after the first
 >     mcp-negotiate-end message, and any messages received for a
 >     package for which an mcp-negotiate-can message has not yet
 >     been received. 

done, in the discussion of mcp-negotiate-end.

 >     The paragraph "To avoid some of the significant.." contains a
 >     typo ("protcol").
 >     The first part (upto ...", nor") must clearly be part of the
 >     spec. But the second part should not be, since there is no
 >     way for any piece of software to figure out whether or not
 >     this is the case. (If you cant enforce it, dont state it.) An
 >     implementation can be in complete input/output compliance
 >     with the spec while choosing to wait 10sec after the
 >     connection is opened, examining the mcp-negotiate-can
 >     messages received, and then sending mcp-negotiate-can
 >     messages based on that. There is no way to know that it did
 >     not do that. So no point in specifying the second part. 

ok; i took it out, but i'm still not comfortable NOT stating that this
is BAD BAD BAD BAD BAD NAUGHTY BAD and that you'll burn forever if
you do it in the level of hell reserved for the sorts of people who
do, ummmmmmmm, really nasty and stupid things.

 >   8. [Cord]
 >      I did not look at this carefully; I would prefer the
 >      more symmetric terminology "initiator" and "responder"
 >      rather than "intiattor" and "receiver". 


 >   9. [BNF]
 >       Is the ":" a terminator or a separator? Might 
 >        <keyval> ::= <key> ':' <space> <value>
 >       be better? 

 >       Also, doesnt TAB count as <space>? 

nope, though i don't have a strong feeling about it.

 > Lastly, should the specification place any limit on the number of
 > keywords in a message? Say, no more than 64K? :-)

well, we don't really have ANY limits specified right now.  i'm all
for leaving it that way and letting you spam your friends and enemies
into the middle of next week.