>From XEP-0001, regarding Final XEPs, "limited modifications may be made as >long as they are optional, backwards-compatible extensions rather than >modifications to the core protocol itself."
XEP-0030 requires that entities return "one or more <identity/> elements and one or more <feature/> elements", so the otherwise redundant 'disco#info' feature ensures this will always be the case, even in the (seemingly unlikely) situation where an entity somehow supports disco#info without supporting any additional features. So, is removing the requirement for this feature an optional, backwards-compatible extension? An obvious, and maybe more realistic, retort is "but will it break anything?" So, would it cause problems for implementations if they were to receive a reply containing zero features (since they were originally implemented expecting there will always be at least one)? Equally, would implementations have problems calculating the caps hash (XEP-0115) with zero features (the algorithm doesn't explicitly account for this)? It's also worth considering whether leaving it as-is causes harm. It's nice (desirable, even) to clean things and remove 'warts' like this, and there are likely many more scattered throughout the protocol, so it's worth noting for XMPP 2.0, but this has been the status quo for 22 years without being an issue. As for benefits: many implementations would now be 'correct' for not complaining when the feature isn't present (if implementations don't follow the specification, just change the specification); and there is a minor reduction in data transferred from having one less feature, though that's less notable where XEP-0115 is used (and there may be an initial increase caused by most hashes now being unknown, until that settles.) (Semi-relevant: https://github.com/xsf/xeps/pull/961 )
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
