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