[Standards] Proposed XMPP Extension: IO DATA

Peter Saint-Andre stpeter at stpeter.im
Sat Apr 5 04:15:23 UTC 2008


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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080404/5f36cb7a/attachment.bin>


More information about the Standards mailing list