Re: Greetings and comments on MCP 2.1

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

> > > (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 think, at some level, it _is_ true for every authentication scheme.  There 
_should_ be a way to plug per-message authentication schemes, and I'd prefer 
it not look like just another message argument.  (Especially if we end up 
losing the _data-tag argument, the only other argument that is part of the MCP 
spec rather than an individual application's spec.)

What I don't want is to block MCP 2.1 on a generalized authentication 
mechanism.  In my mind this falls in the category of "things we can solve 
later"; but I think it very wise for MCP to have a minimal, optional 
authentication scheme until that's done (in some future version).

But, whatever.

>  I.e., the protocol would have to provide explicit 
> specifications for every kind of authentication one might want to use.

Like I was saying, I don't think the protocol would have to provide explicit 
specifications for every kind of authentication; but I think it should (at 
some future date) include a general specification for the use of per-message 
authentication.

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

Because I think this is a bigger problem than we should try to solve in spec 
at this stage.  For now, if the client wants to use an authentication key, it 
can send one; if it doesn't, it can omit it; and if you want to experiment by 
private agreement between a security-enhanced client and server, then please 
do!  Experimentation is the way we get enough experience to write a spec.

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

Yeah, I'm not talking about backward compatibility with MCP 1.0; I'm talking 
about compatibility with the three or more protocol versions that have called 
themselves MCP 2.0.  For most of us, it doesn't matter, because we've only 
deployed our implementations in very limited contexts; but Jay, who has MCP 
systems scattered around the globe or something, has in the past voiced 
objections to certain major changes.  I'll let him explain it.

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

Right, I misunderstood.  Sorry.

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

Well, there are at least two different ideas floating around about what the 
#$#mcp namespace is for:

  * Things that are described in the spec.
  * Things that are integral to MCP operation.

I tend toward the latter usage.  As far as I can tell, you can't get ANYWHERE 
with MCP 2.1 if you don't implement both the #$#mcp message and the 
#$#mcp-negotiate protocol suite.  But you can get along fine without the cord 
suite; some other protocols will require that you have it, but I think that 
kind of interaction is just to be expected.

Another way of looking at it is that we could just as easily release the cord 
protocol in a separate document.  In this case, there would be no real reason 
to place it under the MCP banner; it's just another protocol suite that 
implementations are free to implement or not.

(Of course, in the absence of a naming authority for protocol suites, we'd 
have to call it dns-att-and-mitre-and-caltech-cord or something.  Sigh.)

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

I don't understand what "vendor" means in this example.  If it implies 
different features, then I think those would be different feature names:

  #$#client-feature name=dns-com-bose-audio version=3
  #$#client-feature name=dns-com-midi-audio version=2

(or some such).  In this case, it seems clear that the client and server don't 
speak the same language.  If they're both offshoots of a base-line audio 
feature, then they'd both say explicitly that they have that.

  #$#client-feature name=standard-audio version=1

If vendor is just a noise word in the example, and if you're using version=X 
as shorthand for min-version=X max-version=X, then... our spec has nothing 
further to say about it.

Your spec includes a message for suggesting an upgrade, one of many things we 
were reluctant to spec without experience to guide us.  (Again, the idea was 
to leave it open to experimentation by private agreement.)  Have you been 
using this?  Is it sufficient?  Oh, and, what is the "url" argument of the 
message expected to contain?

At any rate, I think that whatever can be done in a call-and-response system 
can also be done in an everyone-shout-at-once system with a "done" message.  
When the "done" message arrives, you know everything the other side supports; 
if you have an "upgrade" message, you can send it at that point, and so on.

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

Well, the user can't necessarily upgrade "right then"--consider a client 
written in an insufficiently dynamic manner (or language).  And, in fact, it's 
possible that a server could upgrade just as quickly as a client can.  (E.g., 
the server could page all active wizards, and one of them could push a button 
if e wanted to perform the upgrade.)  So I think the protocol should be 
symmetric in this case.  But now I'm just engaging in esoterica.