Node naming

[oddstr13]

From Discussion: Node names on the UKHASnet Wiki

In determining the specification of node names there is some discussion on what should be allowed:

The current "beta" parser allows mixed case and this is used by a small number of nodes.

The options are:

1. Allow mixed case and treat as case sensitive
   • "PiNODE" != "PINODE"
   • Pro: Doesn't break existing nodes
   • Pro: Larger name space
   • Con: mixed case could be confusing
   • Pro: Allows CamelCase names
2. Allow mixed case and treat as case in-sensitive
   • node names could be stored as provided or in upper case (giving two potential sub options)
   • "PiNODE" == "PINODE"
   • Pro: Doesn't break existing nodes
   • Con: mixed case could be confusing
   • ?? : May allow Camel Case names (depending on how names are stored)
3. Only allow a single case (Upper case only)
   • "PINODE" ("PiNode" isn't permitted)
   • Con: breaks existing nodes
   • Pro: Removes and confusion over name space

I, myself, vote for case sensitive, allowing both uppercase and lowercase, digits and some symbols, such as "+" | "-" | "_" | "/" | "?" | "&" | "$" | "@" | "%" | "=" | "." | ":" | "*" This list should be further refined, possibly defining special meaning for some.

A note about confusion between "NodeName" | "NODENAME" | "nodename" should be made in the relevant documentation, suggesting to avoid nodes of the same name, but with different casing, however not forbidding it.

[adamgreig]

I like the idea of IDs being like callsigns, where M0RND has the same semantic meaning as m0rnd, but the canonical version is always M0RND.

However, I really don't like the idea of case insensitive parsers, especially because it complicates comparison logic for embedded platforms and because it means that two different strings of bytes should have exactly the same meaning, which we don't do anywhere else.

I think this means my vote is foremost for 3, upper case only, though perhaps (as @philcrump suggests) we allow parsers to accept lower-case node IDs and convert immediately to upper case upon parsing. It would still be an "invalid packet" in some sense, and nodes that repeat might reject/treat it as a different callsign. Failing that, though, I'd prefer 1 to 2.

[russss]

Yeah, my preferred solution would be to specify uppercase only in the protocol, but carry on accepting lowercase names. This actually doesn't require any changes to the protocol spec. I don't think we want to get into making case-insensitive string comparisons on nodes.

[adamgreig]

Do you worry this leads to many future nodes still using lower case in callsigns, so we end up with a spec that broadly disagrees with reality as the status quo, and everyone ends up having to support lower-case node names everywhere anyway?

[russss]

Well, we could put a nasty warning on the node info pages where a lowercase node name is used.

I expect at some point in the not-too-distant future, we will want to make a breaking/version change in the protocol, and at that point we can forbid lowercase names outright.

[adamgreig]

Sounds good to me.