sigh... really, i'm not dead.

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

OK; i've added the text about handling duplicate keywords after the
statement about case sensitivity.  Based on comments, i made the last
ocurrence of the duplicate significant.  I'm still willing to say they
should be dropped, though, if there are strong feelings.  Here's the
exact text, so you don't hafta go searching:

<P>Implementations should never send a message with duplicate argument
keywords; for example, the message
<PRE>
#$#say 12345 what: "Hi there!" WHAT: "Hey there..." from: Biff to: Betty
</PRE>
should not be generated.  To allow the protocol to be resilient in the
face of buggy implementations, however, implementations should accept
such messages, treating the <EM>last</EM> ocurrence of a duplicate
keyword as the correct one (i.e., in the example above, the text
<SAMP>"Hey there..."</SAMP> is treated as the value of the
<SAMP>what</SAMP> argument).</P>

Erik brought up a point about making clear when we ignore stuff and
when we don't.  Here's roughly what we have:
- If a message has an incorrect authentication key or data tag, it is
  ignored. 
- Unrecognized and "mangled" mcp requests are ignored or unobtrusively
  flagged.  i added some text describing as mangled some insane forms of
  multiline messages.
- unrecognized keywords are ignored or unobtrusively flagged

this leaves us with the special case of duplicate keywords.  i don't
really have strong feelings about the right way to do this, so feel
free to correct what i have.

i've also added some text about multiline messages with multiple
arguments (just making clear that they can have them) and more clearly
stating the format of #$#* messages (well, "clearly".  it's written by
me, so feel free to critique).

as for not specifying the multiline arguments on the initial message,
well, hrrrrrrrrrm.  i'm tempted to say, "we're this far along, let's
punt for this version", but maybe we could sorta take a voice vote on
this one?  as i said, my temptation is to leave it as it is, but i'm
open to changing that.

about the #$#text-line suggestion (john ramsdell suggested a
#$#text-line message which is completely equivalent to its text:
argument alone): i dunno.  this seems redundant to me.  the argument
was: 

> With this addition, one could implement an MCP parser that always
> returns an MCP object, and the MCP object for a text line would have
> text-line as its request and a text argument. 

couldn't you do this without the message?  just have your parser
fall-through on messages not beginning with '#$#' to create a
'non-mcp text line' MCP object?

in other news, we here at MCP central have received word of yet
another mcp 2.0 implementation rearing its ugly head on the west
coast.  troops, missionaries, and diplomats have been dispatched.
				dk