Richard Smith wrote: > Johannes Wagener wrote: >> Proposed XMPP Extension: IO DATA > <snip> > > +1 > > I'd like to endorse this proposal. > > While AD-Hoc commands and Data Forms does offer a lot of flexibility, XMPP > could benefit from extended capability in terms of representation of in > terms of machine-to-machine communications that are outside of XMPP which is > operating as a transport layer. > > I would like to make a suggestion though. > > I can see this proposal being used in my application framework where I have > to ship lots of user interface specifications, SNMP information, accounting > information and other stuff around the XMPP network. My current > implementation is a hack on top of data-forms and various other namespace > hacks. My only reservation is with the error conditions. > > The proposal currently states that error conditions are handled according to > the AD-Hoc commands which IMO is not sufficient. > > Sure, sending a <cmd:bad-payload /> element in response to a submission is > possible, but it doesn't give the machine receiving this error any specific > detail as to the nature of the problem, other than a string. > > Would be nice if there was an <error> element that would specify a schema > for errors possibly? I don't know... > > Apologies if this doesn't make much sense, but it was written on the move...
Yes I think that makes a lot of sense. Given the limits on the number of child elements allowed in <error/> by the core XMPP spec, I think we'd need to include the IO-specific conditions as children of the ad-hoc commands errors. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
