Re: Unsupported message behaviour...

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

> well, the spec says 'reasonably non-intrusive'.  this is pretty
> intentionally vague.  the spec can't do UI design, really, so i'd like
> to allow as much latitude as possible in handling unknown messages.
> so, i guess my answer is 'any of those'.  if your users don't kill you
> for spraying weird #$# garbage all over their screen, you're pretty
> much ok.  the critical thing about the handling of errors is that they
> NOT cause the client to cease processing MCP requests, or leave the
> system in a state where the user has to clean up the aftermath.

Note that, in my MCP implementations, my reaction to an unknown MCP
message has been simply to drop it on the floor.  No user interaction,
no user display, no nothing.  This is as non-intrusive as it gets,
and IMO is the right thing except when debugging MCP protocols.

> in other news, after talking with jay and ken this weekend, i'm
> thinking about #$#MCP-protocol-end again.  this message would end the
> negotiation phase.  i'm not terribly happy with it, mostly because i
> really want to keep dynamic loading as a possibility, but i don't have
> a strong enough case to make to fight adding it, i think.

I don't object to the idea of an 'end' message, but so far I've seen
only a vague sort of unspecified one; I know people want 'end' but I
don't know what it _means_.  I'd like to see either Jay or Ken describe
the semantics of that message.  What blocks on it, what doesn't, etc.

Incidentally, Dave and I talked a little, and I think I browbeat him
into agreeing to punt dynamic loading to a future spec.  That is, a
reconnect would be required to change the set of protocols available
for use on a given connection.  (No adding, no deleting, no version
changes.)  Basically, I think there are too many unknown issues and
too little practical experience, and I think it would be disastrous
to try to spec it now.

Can anyone see the serious problem inherent in that decision?  Sigh.

--Erik