(This is tangential to Dave's thread, but I didn't want to hijack that, hence a new one.)
XEP-0066 defines two OOB methods for transmitting a URI to another recipient, an 'iq' method and a 'message' method. The iq method contains a 'url' element and an optional 'desc' element, and the recipient is expected to indicate whether it succeeded or failed in opening the URI. The message method contains a 'body', a 'url' element, and an optional 'desc' element, and effectively works like "here is a URI, if you're interested" with no response required. I'm not aware of any clients using the OOB iq method, but I don't think it's a bad thing (outside of potential privacy leaks.) For the message method, I expect what happened was that at least one popular client, rather than leave the body empty, inserted the content of the url element into the body, and then others did the same, so now that has become a de facto requirement. While inserting the url into the body isn't wrong, it's obviously not the intention of the XEP - it does include separate body, url, and desc elements for a reason - so requiring it be that way is wrong. So, should we require everyone do this badly because some already do it badly (this is why we can't have nice things!) or do we clarify things a little and hope people might see the errors in their ways? I think as a minimal change to a Draft XEP, it would be okay to recommend that implementations copy the url into the body IF the body would otherwise be empty; that is essentially what these implementations are already doing, and an empty body wouldn't be much use otherwise. This doesn't then rule out the possibility of real a body text and possible description. There may be some argument to include the url in the body anyway for backwards compatibility, but given the XEP is over 14 years old and has a disco feature, is that really appropriate? If something can easily be made backwards-compatible then why not, but should we avoid doing anything advanced because it won't work properly in Pigeon? There is also the usual MUC issue, but things intended for one-to-one obviously aren't guaranteed to work there, and breaking everything just so they will work with MUC is going backwards. Wading into the realm of 'no UX requirements in XEPs,' I think it's appropriate to suggest implementations reveal the actual url in some obvious way (if it's not already present in the body.) Finally, with XEP-0095/0096 being deprecated, the (non-normative) SI Transfer parts could probably be stripped. Comments? Problems? Threats of physical violence?
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
