On 20-Jan-06, at 7:33 PM, Pete Rowley wrote:
We can't mandate that the other party in the exchange implement
Isn't the point of issue here that there needs to be documented a
way to (stealing the words) "produce interoperable
implementations" so that it can be shown that it _works_ by having
"interoperable implementations" - this isn't a question of
mandating anything, but codifying how using the protocol over one
method of transport would work.
Nope...
Here's an illustration of the issue...
Usually in a protocol definition there are only two parties, the client
and the server. If some aspect of the protocol was optional say A
or B then someone could implement a client that did A and someone
else could produce a server that talked B. Compliant implementations
but not interoperable. The solution is to mandate A and make B
optional.
But, we have a different situation. Three parties and two exchanges...
Given parties A, B, and C where separate protocol exchanges can
occur between parties A and B, and between parties B and C...
I just don't think that every B has to be able to talk to every A and
be able to talk to every C.
This is probably easiest to state in first order predicate logic...
Given parties A, B, and C where separate protocol exchanges can
occur between parties A and B, and between parties B and C; it
must hold that a single instance of a transitive relationship must exist
between every A and some C through some B, and it must also
hold that there is a reverse transitive relationship instance from
every C to some A through some B, and that every B participates
in one of those relationships... ohhh... that's a transitive closure.
In other words: the transitive closure of all As includes all Cs
through all Bs. Hence it matters not what the transport actually is,
just that this constraint holds.
I think that's a good argument against mandating a transport.
What needs to be mandated to ensure interoperation is that...
An A must be able to talk to a B.
A B must be able to talk to an A and a C.
A C must be able to talk to a B.
I'll see about working that into charter style text tomorrow.
John
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
