Re: Greetings and comments on MCP 2.1

[Michael Brundage <brundage@piaf.ipac.caltech.edu>]

On Wed, 6 Aug 1997, Erik Ostrom wrote:
> I just want to point out that the following is all my opinion, except where I 
> say "we", and even some of that is just my opinion; it's not the word of some 
> Official Body On MCP Development.  So take it in that spirit.

Ditto.  In my last message I tried to use 'I' for my personal opinions 
and 'we' for things Dave and I have explicitly talked about and agreed on.
The way I see it, you all have important things you can teach me, and
I'm totally excited about the opportunity to discuss all these ideas as 
a team.

(I love this stuff!  Am I really getting paid to do this??)

> > (2) I don't see the point of explicitly requiring an authentication key 
> 
> The problem is, if you don't specify it in the spec, then you don't 
> have a way to require it in all messages.

If this were true, then it would be true for every authentication scheme 
(including keys).  I.e., the protocol would have to provide explicit 
specifications for every kind of authentication one might want to use.

Why not, in the initial greeting, specify the kind of security the 
client wishes to use:

#$#mcp version=2.1 client-name=TWin security=authentication-key
#$#mcp version=2.1 client-name=WarmFuzzies security=none
#$#mcp version=2.1 client-name=NSA security=RC5
#$#mcp version=2.1 client-name="Microsoft MOO" security=lame

etc.

[This also implies that a security negotiation process may happen, for 
example if the server doesn't support RC5, then the server should be able 
to propose an alternate security method to the client, etc.]

Some security schemes will require extra data sent along with the message 
in order to decode or authenticate that message.  E.g.,

#$#audio-play sound="gong" volume="loud" authentication-key=astroscheibe
#$#audio-play sound="gong" volume="loud" digitalsignature=xj103asdjkl524
...

On the one hand, this allows open-ended security schemes, which I think 
is really important.  On the other hand, by leaving things open-ended, it 
gives no guidelines as to which keyword names will be reserved by the 
security system.  Perhaps one could pick a special character and say that 
any keywords starting (or ending, or whatever) with this character will be 
reserved for use by security systems. E.g., (if ^ flags security data)

#$#audio-play name=gong volume=loud ^digital-sig=foobar ^authority=rsa.com

Of course, one can argue that by including specific support for unpaired 
authkeys in OOB messages you're doing essentially this, by saying in essence 
"this value is used by the security system" without cluttering the 
keyword namespace (since there is no keyword associated with it) but it 
also unnecessarily limits the security data to a single value.

In any case, I don't see the need to bless the authentication key with 
special status.  To me, it's just another data value, and should be 
treated just as all the others are (i.e., as a keyword=value pair).

This doesn't cause problems so long as both the server and client know 
and support the security system being used.  The system design I envision 
could be pictured something like this:

+----------+   +----------+ +--------+
| Client   |   | Security | |  MCP   |    network
|          |---|          |-|        |-------\\--------- (same setup
| Features |   | System   | | Parser | (or maybe not)     on server side)
+----------+   +----------+ +--------+

So that incoming messages are first parsed into a command and a list of 
{key, value} pairs, then the security system (if any) gets to decide 
whether this is a secure action (stripping its data out of the {key, 
value} pairs), and then finally the client feature that handles the 
command is handed the {key, value} pairs to do as it likes. Similarly, 
outgoing messages are first pieced together by the client feature (which 
is ignorant of MCP; it simply constructs the {key, value} pairs), handed 
to the security system which stamps its approval (inserting its security 
data into the {key, value} list), and then the data is handed to the 
parser which constructs a valid MCP (or whatever protocol is being used) 
message for delivery.

> I'm ambivalent about "regularizing" auth keys.  Again, if used, they are used 
> across all messages; this seems less like a message argument and more like 
> part of the syntax.

It's true that whatever data pertaining to the security scheme in use 
does have a kind of special status beyond the other message data sent, 
but this doesn't mean it shouldn't be sent in the same way as ordinary 
message arguments.  As I've already pointed out, other security schemes 
may want to send more than just a single authkey with a message; also, 
one will want to be able to change the security system currently used, as in:

#$#security-change-key oldkey=ackackack newkey=doobedoowah

> > For example, I can 
> > imagine the entire message being encrypted.
> 
> Not sure how you're going to encrypt the message and still have it conform to 
> the BNF.

Sure, why not?  Constrained encoding.  It's like CD's which have (or at 
least initially had) the manufacturing limitation of no fewer than three 
pits in a row but no more than eleven (and likewise for lans).  
It's all just a SMOP :-)  (Not, mind you, that I intend to be the one to 
do it!)

[About : instead of = as a key/value delimiter]
Well, to be honest I was mostly making up justifications for what to me 
is a purely aesthetic decision.  You're absolutely right that *something* 
has to be used, and there's nothing wrong with using :.  I just prefer = 
-- I guess I feel it more clearly indicates what is happening. *shrug*

[Indicating the order of lines in multiline messages]
> And, more generally, this can be dealt with at a lower level than we've 
> concerned ourselves with in this spec.
[...]
> Ordering is a problem that you'll have to deal with elsewhere.

You're right.

> > In particular, instead of giving tagged data dummy values, give them the 
> > data tag itself, and then use that tag (by itself) in the additional 
> > lines sent.
> 
> I'm tired of having this argument, and so I'll relinquish my previous 
> position (that we should have a single data tag for each message and 
> its continuance;

Ack, I think I may have not explained myself very well.  (Also, I'm new 
to the list, so I've missed your previous posts about it...) In the current 
proposal for MCP 2.1 that I read, a multiline message works something 
like this (when it has several multiline data in it):

#$#blah multiline*: "" _data-tag: 123 multiline2*: ""

What I'm saying is that there is no point in assigning "dummy" values 
(empty strings) to the multiline keys. Instead, just do the same 
functionality in this way:

#$#blah multiline* = 123 multline2* = 456

This is more concise, means the same thing, and avoids reserving the 
special keyword name "_data-tag".

That is, instead of specifying separate _data-tag's, have the tag number 
be the value assigned to the multiline data.  You already know it's 
multiline (since the key name ended in *), so you know to treat its 
value specially (in this case, using its value as the data-tag instead 
of just ignoring its value entirely).

> Note that if you use data tags alone to indicate which message and argument a 
> particular #$#* line goes with, then you need to ensure uniqueness among all 
> contemporaneous argument tags; no additional complexity there, really, just 
> more work.

That's true.  But then, the MCP 2.1 spec that is currently online already 
specifies this (that all data tags are guaranteed to be unique for their 
lifetimes). That's why I suggested that there is no need to keep 
specifying the key name as in the currently proposed

#$#* 123 multiline: The text goes here.

but instead one could just do

#$#* 123 = The text goes here.

> > Also, I'm of the opinion that whitespace should be 
> > generally ignored, so I don't like the idea of specifying only one 
> > whitespace between delimiter and value.
> 
> Well, whitespace _within_ the body of a multiline argument is 
> significant; I'm not sure it's much different to ignore the 
> whitespace that _begins_ the body. However, I don't feel strongly 
> about this either.

I just mean that ordinarily, the messages

#$#audio-play name=gong

#$#audio-play name    =    gong

are equal.  So it is strange to me to suddenly say that

#$#* multiline= The text.
and
#$#* multiline=  The text.

are different (because the second one has two spaces instead of one 
between the delimiter and the value).  Instead, I think one should 
consistently ignore all whitespace that is not in quoted values.  Since 
multiline values are given special status (they don't need to be quoted, 
for efficiency), something special has to be done for them.  I'd rather 
see some character (" or . or * or something) indicate the beginning of 
the line, as in

#$#* multiline= *The text.

or

#$#* multiline=    *The text.

(which are now the same message, but distinct from

#$#* multiline= * The text.
)

> Backward compatibility for deployed systems should be a concern, 
> though; but Jay, you're not using multi-line at all, are you?

Is it?  Are any of you concerned with this?  I don't want to cause 
undue problems with already deployed systems.  For us, this isn't an 
issue.  Besides, I thought the multiline scheme in MCP 1.0 used @@@ 
prefixes, which MCP 2.* is obsoleting?  (In fact, Jupiter spliced multiline 
data into a single line, and never used multi-line messages at all.)
MCP 2.* seems different enough to me to warrant breaking compatibility 
with MCP 1.0, but I probably feel this way only because backwards 
compatibility isn't something I've thought about for this.

> > (3) I don't like the explicit versioning scheme.  In fact, I think that 
> > MCP itself will not change much beyond MCP 2.0 -- however, the feature 
> > set ("protocols") which the client supports will vary widely both in type 
> > and version, as will the logic behind the client/server negotiation 
> > process.
> 
> I would say instead that MCP itself will change much more slowly than the 
> feature set.

That's what I was trying to say, though you said it much better.
> 
> > #$#mcp version=2.1 client=Supernova client-version=1.6beta2
> >
> > In particular, we anticipate many different client types (with differing 
> > feature support) which might all support MCP 2.1; e.g.

> I'm pretty strongly opposed to this, if I understand it correctly.  
> Our design allows for negotiation strictly on a feature-by-feature 
> basis; I don't think that the server has any need to know what the 
> name of the client I'm using is, or that it should be making decisions 
> based on that information alone.  The MCP implementations I've been 
> involved with have among their goals:
> 
>   * Make it easy to add functionality to the client/server, or remove it.
>   * Interoperate with other clients/servers that support some of the same
>     functionality.
> 
> Requiring the server to know what a Supernova is or what features its version 
> 1.6beta 2 supports seems like a very bad idea.

I agree with you completely in all this.  Read our proposed MCP 2.0 at
http://supernova.ipac.caltech.edu/projects/np/mcp2_0.html
and you'll see that we too have extensive client feature negotiation in 
our proposal.  In fact, because our client is extensible, it would be 
impossible for the server to determine its feature set solely from the name 
and version of the client!  Moreover, when the server asks the client 
whether it supports a feature, and the client decides it does not, we 
want the client to then be able to ask the server where it can obtain 
that functionality.  Bypassing the client/server feature negotiation 
process would skip this important capability.

However, I think the client should be *allowed* to send other information 
than just the current mcp version, because the server may deem this 
relevant.  Andy had some really good points in his followup (which I'll 
reply to next) on this matter, so maybe I should put the rest of my 
thoughts on it there.

> Just to clear up a possible misunderstanding:  Ours would also be 
> #$#audio-play, if there were a defined protocol named #$#audio or 
> #$#audio-play.  The only messages that begin with #$#mcp are those that deal 
> with MCP itself--i.e., #$#mcp and the #$#mcp-negotiate protocol (and 
> #$#mcp-cord, although I still think that one's a mistake).

Okay, then we're talking about the same thing. But then I don't 
understand why you think #$#mcp-cord is a mistake -- isn't that something 
built-in (though optional) to MCP itself, and not really builtin to a 
specific "protocol"?

> (#$#* isn't a message name; it's part of the protocol's syntax.  The goal, I 
> think, was to minimize overhead for multiline messages.)

Works for me.

> This sounds entirely in keeping with what we have; the only difference I see 
> is in whether one considers #$#* lines (and #$#END) to be messages in 
> themselves, or simply part of the mechanism for sending messages.

To me, if it starts with #$# it's an out-of-band message, which somebody 
(an OOB handler) in the receiving end is tasked with handling.

[server/client driven negotiation]
> This is true, but only because VRML is (in your model) inherently 
> server-driven in practice as well as negotiation.  On the other hand, imagine 
> a file-upload protocol.  I could say "If the client does not upload files, 
> then it doesn't matter whether the server supports it or not.  
> However, if the  client does do file upload, then it needs to 
> determine whether the server supports this or not before using it." 
>[...] In our 
> spec, feature negotiation is neither server-driven nor client-driven; both 
> parties simply send their capabilities.  The goal was to have the negotiation 
> over with as quickly as possible.  If both sides send feature sets as soon as 
> they establish MCP contact, then each side knows that a supported feature is 
> present as soon as it receives one negotiate message from the other side.  In 
> a server-driven process, the server must wait for a full round trip before 
> acting.

I think I'm making terminology mistakes.  When I say our client does 
"protocol negotiation," I mean that the client can negotiate the 
substrate (MCP or whatever) which is used for all OOB traffic.  When I 
say it does "feature negotiation" (our "feature" = your "protocol"), I mean 
that the client can negotiate which features (file uploading, VRML, etc.) 
it supports.

Using this language, we believe that protocol negotiation must be 
client-driven.  Feature negotiation can go either way, depending on who 
wants to know what.  So I agree exactly with your first paragraph above.

I confused the issue in my last message when I said that feature 
negotiation is server driven.  I think that in general it will be 
largely server-driven, and so far I've been following the way Jupiter 
did things, by having the server send the client a features request after 
the protocol is agreed on.  I guess this is not really necessary; both 
server and client could just shout out "I support this!" to each other, 
and take things from there.  However, then I'm not entirely sure how to 
handle the feature negotiation:

If the client says to the server
#$#client-feature name=audio vendor=Bose version=3
while the server says to the client
#$#client-feature name=audio vendor=MIDI version=2
then whose responsibility is it now to resolve the conflict?

In the system I've been imagining so far, the server would ask the 
client, "What can you do?" Then the client replies with a list of things 
it can do.  Based on the type of client it is and the things it says it 
can do, the server may not need any more information.  If it does, it can 
request this on a feature-by-feature basis.  The client then responds to 
these requests.  If the server doesn't like a response (maybe there is a 
better version available now, or it can't support the version the client 
has) then it can suggest the client upgrade or suggest an alternative 
(possibly older) version.

On the other hand, If the server doesn't support something the client does, 
then that's pretty much the end of it.  While the user can make a decision 
right then whether to upgrade or not, that decision for the server is in 
the hands of the administrator(s) and is not an immediate kind of thing.  
So in this direction the feature negotiation process is far simpler and 
more abrupt -- everything is yes or no.  So if the client wants to do 
something and it needs to know the server will support it, it does a 
feature specific request (just like the server does when it wants more 
information about a client feature) and the server responds either 
favorably or not, and that's it.

Also, since our system is dynamic, we have to anticipate the possibility 
of feature capabilities being removed or added during the session.  So 
although there is an initial feature negotiation process, it can continue 
(or be restarted) at any time during the session.  Sometimes these 
messages will be initiated by the client (if the user turns off audio or 
video, for example) and sometimes by the server (if someone is working on 
a system and temporarily disables it, for example), so I was wrong to 
say or imply that feature negotiation is always server-driven.

All of this is (or should be) spelled out in our online proposal, and I 
welcome all your comments on it.


(Now to the next message...)

michael