Clarify distinction between SSH3 and SSH in documentation

[ei-grad]

Updated the description of 'SSH3' to better distinguish it from 'SSH'. The text now explicitly states 'SSH3 stands for the concatenation of Secure Shell and HTTP/3'. This adjustment enhances understanding by clarifying that SSH3 incorporates elements of both Secure Shell and HTTP/3, subtly differentiating it from the standard SSH protocol.

[francoismichel]

Hmmm, I kind of agree, but at the same time, we really want to go towards a new version of SSH at some point and it implements most of the mechanisms described in rfc4254. I agree it does not implement the mechanisms of other SSH-related RFCs. But should we really make it totally distinct from SSH ?

[asgeirn]

I'd suggest using the name SSH/3 to really emphasize that it's distinct from traditional SSH. The differences are quite significant from a network perspective.

[CameronNemo]

Just throwing my two cents in... if the eventual goal is standardization that is cool, but until then I think using something like h3shell or h3-secure-shell would make it really clear that this is a steep departure from standard SSH. Pivoting back to the SSH3 name if and when standardization occurs shouldn't be too difficult.

I worry putting "SSH" into the name at all is going to cause more harm then help, for the project and the wider ecosystem.

[mholt]

@asgeirn I like that idea, or what about "SS/H3" instead? SSH/3 reminds me too much of HTTP/3, which is a version number.

@CameronNemo But this isn't a shell, it's a secure transport for a shell; i.e. literally SSH protocol; only the transport and auth documents are different, but the actual connection is the same AFAIK.

[indianets]

SSH3 feels like the next version to SSH after SSH and SSHv2. Though the project has the same spirit and intentions, it needs clarification to distinguish from the current SSH protocol/software.

[sthagen]

I think the proposed change is a good and helpful first step.

In case it helps: I am not the parent, thus not attempting to name the child ... and with that being out of the way:

My feedback (on the naming of the project and the thoughtful and interesting proposals of my co-commenters) is:

1. suggest to contact the OpenSSH project (e.g. at @openssh esp. Damien Miller @djmdjm or @daztucker) and ask the people there on what they consider a good name and ... possibly even develop an association strategy?
2. numbers are weak (as name parts) and often interpreted as version or dimension values
3. slashes in names of client and server command line applications (we interact with on top of file systems) lead to additional names ... which is also weakening a name

W.r.t. suggestion 1 @francoismichel:

Explaining this project's goal to some OpenSSH project members may provide learning from them about their existing plans.
That may offer interesting synergy effects.
E.g. I find the project goals at https://www.openssh.com/goals.html are concise and if this (here) would be my project, I would kindly ask the OpenSSH maintainers what they think about a third protocol version (which might be compatible with SSH protocol version 2 on some level but maybe not on other levels, or for some features ...).
Offering support to existing open source projects even when then agreeing to disagree on some aspects, I personally consider a good way of development.

[stappersg]

It was #79 that made me making #85, #86 and #87. And then I found this merge request ...

[stappersg]

[ei-grad]

Just in case, rebased. Don't understand why the conflict have been arised.