XEP-0077: In-Band Registration - Account creation via XMPP and HTTP
Hi, At the moment, it is not recommended to provide a web registration URL if the server supports account creation via IBR. I created https://github.com/xsf/xeps/pull/1299 to provide a web registration URL in addition to account creation via IBR. The client or user can decide which one to choose. Please let me know what you think about it. To the Council: 1. What exactly do you mean by *The language is weird*? 2. I tried to describe the use case. Could you please explain your doubts? 3. Why would such a change be problematic for a final XEP? 4. Where should I add that change instead? Thanks in advance :)
Hi Melvin, I'll give a comment from my perspective, not representing the whole Council: On Sat, 2024-08-31 at 12:00 +0200, Melvin Keskin wrote:
1. What exactly do you mean by *The language is weird*?
I'm not sure who said this, but this sentence for me sounds overly complicated: "In addition to or instead of the required fields or a data form in the IQ result, an instructions element as well as a URL encoded using XEP-0066 MAY be included".
2. I tried to describe the use case. Could you please explain your doubts?
What would be the purpose of providing two alternatives to do the same? This might be useful for backwards compatibility, but this is not the case here (as every client that would be able to display the Every client that implements the current version of XEP-0077 SHOULD support x:data, iq:register fields and x:oob. Given the described Precedence Order, the x:oob is always considered as a last option if nothing else works. As all clients SHOULD implement x:data forms and MUST support x:register fields, having x:oob next to x:register fields would be useless. For legacy compatibility, the XEP does allow x:data and iq:register fields to be present at the same time, but this is meaningless as soon as the client follows the SHOULD to support x:data. However at no point clients were allowed to not support iq:register fields.
3. Why would such a change be problematic for a final XEP?
As it is currently NOT RECOMMENDED, existing clients may misbehave if iq:register fields + x:oob are provided at the same time.
4. Where should I add that change instead?
As I have not understood the use case of having multiple ways to do the same thing, I also can't assess how to do it better ;) Marvin
On Sat, Aug 31, 2024 at 12:01 PM Melvin Keskin <melvo@olomono.de> wrote:
Hi,
At the moment, it is not recommended to provide a web registration URL if the server supports account creation via IBR. I created https://github.com/xsf/xeps/pull/1299 to provide a web registration URL in addition to account creation via IBR. The client or user can decide which one to choose.
Please let me know what you think about it.
To the Council: 1. What exactly do you mean by *The language is weird*?
Specifically the sentence "That approach does not limit future development as the former one did which recommended to provide either account creation via XMPP or a web registration URL." "the former (approach)" in this context seems to refer to the former version of the XEP. Which essentially puts the justification for the change (or the change log) into the text of the specification. As a reader of the XEP I have no idea nor do I care about the historical context of the XEP. A specification should just instruct readers what to do (with the limited justification) but not narrate the history of the XEP.
2. I tried to describe the use case. Could you please explain your doubts?
I have no doubt that in an experimental XEP this would be a useful change.
3. Why would such a change be problematic for a final XEP?
Because it may break existing clients as this is a pretty significant change to normative language. The bar for changing final XEPs should be *extremely* high. As in "we generally don’t do that". RFCs are immutable too. "Nice to have" doesn’t cut it.
4. Where should I add that change instead?
We are already developing successors to in band registration. Namely XEP-0389. Make sure your use case is covered there. cheers Daniel
participants (3)
-
Daniel Gultsch -
Marvin W -
Melvin Keskin