Channel renaming extension

[jwheare]

This PR replaces and builds on #308

Changes from the earlier PR so far:

• Drop MODE message from fallback requirements
• Switch to standard replies FAIL codes for new error cases
• Existing error numerics such as ERR_CHANOPRIVSNEEDED are preferred
• Move normative fallback mechanism to its own section and add an example
• Mention case changes explicitly
• Don't use RFC keywords in non-normative security section

Decisions that still need to finalised:

• Command name. Is RENAME too generic? Should it be CHANRENAME? Counter-point, we use JOIN PART KICK, not JOINCHAN, etc.
• Cap name. This should probably be changed to channel-rename

Decisions made (Edit 25/8/2020):

• RENAME is fine
• channel-rename will be the final (non-draft) cap name

[jwheare]

Anyone have any opinions on the unresolved decisions mentioned here?

[sadiepowell]

Command name. Is RENAME too generic? Should it be CHANRENAME? Counter-point, we use JOIN PART KICK, not JOINCHAN, etc.

I think its fine?

Cap name. This should probably be changed to channel-rename

Sounds good to me.

[dequis]

How illegal would it be if I also allowed renaming of users through this?

Bitlbee has this thing as a control channel command (not as a server command)

19:59 <@dx> help rename
19:59 <@root> Syntax: rename <oldnick> <newnick>
19:59 <@root> Syntax: rename -del <nick>
19:59 <@root>
19:59 <@root> Renick a user in your buddy list. Very useful, in fact just very important, if you got a lot of people with stupid account names (or hard ICQ numbers).
19:59 <@root>
19:59 <@root> rename -del can be used to erase your manually set nickname for a contact and reset it to what was automatically generated.
19:59 <@root>
19:59 <@root> Example:
19:59 <@root> <itsme> rename itsme_ you
19:59 <@root> * itsme_ is now known as you

Which doesn't support channels, but probably should some day. And the last time I saw this spec I was thinking that my implementation of this command could just quietly accept nicks in addition to channels, and do what the other rename command normally does with nicks.

[progval]

Sorry if this was mentioned before, but:

To help clients that weren't present in the channel during the name change, server implementations MAY implement JOIN redirection from the old channel to the new channel for as long as is deemed necessary.

Shouldn't it mention that, if the client negotiated the cap, the server should send RENAME instead of doing a JOIN redirection?

[jwheare]

@dequis: imo that's no more illegal than all the other cool tricks in bitlbee

[jwheare]

@progval I don't think so, no. JOIN redirection with 470 ERR_LINKCHANNEL happens before a JOIN happens. RENAME is for when you're in the channel at the time.

[progval]

So how should clients know the channel was RENAMEd if they weren't in the channel at the time?

[jwheare]

470 has a free form text field.

[progval]

but it doesn't solve the clients issues this spec aims to solve (moving logs, etc.). And bots can't understand the free form text

[jwheare]

Those are fair points. Are you imagining the RENAME being sent after an initial JOIN+burst to the old channel?

[progval]

I think that would be perfect, yes.

[jwheare]

It might be simpler if rename supporting clients were just given a standard FAIL command defined for this purpose, e.g. CHANNEL_RENAMED, so that they can try again, rather than joining the old channel and then renaming it. Fallback can still be 470.

[progval]

Sounds good too!

[jwheare]

Doing it this way also avoids any issues with clients renaming old channels to new ones twice, potentially corrupting logs or causing conflicts.

[jwheare]

Will aim to get this merged to the site as draft next week. Further comments most welcome.

[slingamn]

Sorry about the late comment. I have a question about the rationale for this change:

This fallback SHOULD NOT be used if the rename only changes the case of the channel name.

Oragono implements #272 for case canonicalization, which (AFAIK) all current client software ignores. Moreover, my belief is that there's no practical way to specify a Unicode casefolding algorithm that the client and server can fully agree on, since even if both are using PRECIS, it matters which version of the Unicode standard their PRECIS implementations are aware of. My sense is that the most promising approach is for clients to treat server-sent identifiers (in particular, nicknames and channel names) as opaque byte strings. (The most problematic area for this so far is MONITOR, since MONITOR + has to accept nicknames in non-canonical forms, and then MONITOR L and MONITOR S have to replay them.)

I don't fully understand the claim in this comment that clients doing this are broken. Is it mostly just about the prior existence of m_changecap? I think a reasonable outcome of the rename spec would be that m_changecap is deprecated, and all renaming (including case changes) should use RENAME, which should send PART and JOIN to fallback clients even for a case change.

[slingamn]

From discussion: the intent here is to refer only to the CASEMAPPING canonicalization behavior, which has a straightforward definition and which clients are expected to implement.

This doesn't seem to pose any concerns. Oragono will send the fallback for case changes (whether they fall under CASEMAPPING or UTF8MAPPING), but that's OK because this is just a SHOULD.

[jwheare]

Does that clear up any confusion?

[slingamn]

Yep, thanks.

[DarthGandalf]

Can servers automatically join the new channel when client tries to join the old channel?

[jwheare]

The point is to make it explicit to the client that a rename has happened. An automatic join doesn't give the chance to rename logs first.

[jwheare]

Any further comments or things to resolve or can this be merged as draft?

[jwheare]

Will merge next week if no further comments.

[jwheare]

Latest commits make a few changes that go beyond language style:

• 3rd reason param is always required when sending RENAME server -> client.
• Soften stance on changing prefix types. There may be valid reasons to allow these, but servers shouldn't feel like they have to allow them. This also avoids the weird "servers: don't do this, clients: support it anyway" stuff.

[jwheare]

Will leave this open for another week to allow any reviews of these changes.