[standards-jig] LAST CALL: SOCKS5 Bytestreams (JEP-0065)
temas at box5.net
Mon Jan 13 20:56:29 UTC 2003
This is something linuxwolf and I debated a lot while working on the
file transfer JEP. How do you require an IQ response? I mean, sure we
can write it, and we can say they are not compliant when they are
tested, but you can't ever make your client depend on receiving the
information, otherwise the client is easy to DoS cause it sits there
waiting for one event to happen. Granted that's an extreme case of
programming error, but it really messes with state.
On Mon, Jan 13, 2003 at 02:28:15PM -0600, Casey Crabb wrote:
> An issue I noticed with the JEP.
> Section 4.2, after example 5, before example 6:
> "Once the Target receives the IQ-set from the Initiator, it MUST either
> refuse or accept the bytestream offered by the Initiator. The IQ cannot
> be ignored.
> If the Target is unwilling to accept the bytestream, it MUST return an
> IQ-error to the Initiator with an error code of 406 ("Not Acceptable")."
> This works for objects that actually implement the jep, but since we
> cannot assume that an object has implemented it we either must
> a) have some sort of feature-negotiation involved before we send the
> request; or
> b) allow for the iq-set to be ignored.
> I understand why we don't want the iq-set to be ignored, but
> implementations should be able to time-out the listening sockets after a
> time if the iq-set is ignored.
> Standards-JIG mailing list
> Standards-JIG at jabber.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards