Subject: [Terminology] Client/Server

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 28 Feb 2021 14:03:53 -0500

So question, should the group limit itself to only considering problematic
terminology or should the scope be wider? A wider net might actually be
less contentious.

If we limit ourselves to the politically contentious terms, we end up in a
coded discussion on race. I am not willing to play that game. I have spent
too long running active measures in social media for the good guys to know
all the games. I am not prepared to tolerate the pretense that people wave
confederate flags in the faces of black people for any other reason than to
bully, intimidate and assert white supremacy.

A less contentious motivation for looking at terminology is that legacy
terminology encodes legacy assumptions of the way things are. Consider the
case of Client/Server.

Every two party communication is started by one of the parties and it is
useful to distinguish between the two. But as X-windows quickly
demonstrated, the side that initiates a communication is not always the
machine we tend to consider a server.

In X-Windows world, the machine on my desk is the server and the
mainframe in the basement is the client.

The Web shows another limitation of this approach. A Web Browser is a
client. But many Web applications running in the browser are essentially
servers for the same reason as in X-Windows. And so we have Web Sockets
which allow us to flip the switch and invite a server to create a client
session with us.

If we take this to the limit, what we have is a communication session that
is started by one machine and responded to by another which can then be
used to establish multiple subchannels going in both directions.

QUIC is starting to demonstrate some of this capability but what we have at
this point is merely a protocol. We don't yet have the APIs that realize
the full potential of the idea.

I find it better to use the terms initiator and responder to describe
session establishment because what is important in that relationship is
that the responder role is distinguished by the fact that the initiator has
to discover it.

In the 1980s computer paradigm, the term server for responder made sense
because the responder was typically the mainframe server in the basement.
Things are much more fluid today.

Using the terms initiator and responder allows us to make it clear that
these roles are limited to the process of session establishment. That helps
get our frame of reference clear.

Once we have a session established between Alice's phone and some cloud
service provider, either end of the connection might start a protocol
interaction within that session context.

The phone might drop a photograph onto the service

The service might tell the phone that the contacts catalog was updated.

Alice might join a chat group and start receiving asynchronous messages
from the chat discussion.

At the moment, the QUIC discussion is focused by the immediate requirements
of Web browsers. But there are other requirements possible.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 1 Mar 2021 09:38:58 +1300

On 01-Mar-21 08:03, Phillip Hallam-Baker wrote:
...
> I find it better to use the terms initiator and responder to describe session establishment because what is important in that relationship is that the responder role is distinguished by the fact that the initiator has to discover it.

You are absolutely correct. In the GRASP design we used the terms initiator and responder, and counterpart or peer once a negotiation starts. Negotiation is essentially a symmetric process, so it's confusing to use asymmetric terminology.

This is another case where a human can fix suspect text, but an algorithm really can't.

    Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 28 Feb 2021 17:05:04 -0500

On Sun, Feb 28, 2021 at 3:39 PM Brian E Carpenter <
[email-masked]> wrote:

> You are absolutely correct. In the GRASP design we used the terms
> initiator and responder, and counterpart or peer once a negotiation starts.
> Negotiation is essentially a symmetric process, so it's confusing to use
> asymmetric terminology.
>

I think we (myself, Brian, John) are in broad agreement here. But it is
important to make the case with precision. I found myself replacing
Master/Secondary with Primary/Secondary in one system and Active/Inactive
in another.

For the part of the communication I am most focused on in my work right
now, key agreement is an essentially asymmetric process as the parties
start off with asymmetric information and the objective is to get to a
symmetric position. But we have to be careful because we don't necessarily
get to a symmetric outcome. That is certainly not the case with TLS because
TLS is deployed in a fashion in which only the host is credentialed. The
client is not authenticated. Client auth could have happened but it didn't
and it won't.

Damn right I am reinventing the wheel. In the space of two and a bit years,
I have re-designed from scratch a replacement for PKIX, a replacement for
DNS and a replacement for TLS. And none of these are replacements because
they all do things in a different way to what went before. This is what I
call 'research'.

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 28 Feb 2021 23:20:06 +0000

*   So question, should the group limit itself to only considering problematic terminology or should the scope be wider? A wider net might actually be less contentious.

I would like to see us focus on the problematic terminology and then if the WG wants consider the larger picture.