[standards-jig] IBB: Making it all "go"

Richard Dobson richard at dobson-i.net
Wed Apr 9 23:03:41 UTC 2003

>> I think this is perfectly valid and it should not really be the 
>> servers
>> responsibility to protect the low bandwidth client or other clients 
>> from
>> file transfer packets that get directed to them (that were not really
>> intended for them since another resource went offline), IMO the file
>> transfer packets should never be able to goto another resource and 
>> also
>> should not get stored offline which really means they should be using 
>> iq
>> instead of message, also if iq is used there isnt really a need for 
>> the seq
>> stuff, since only one packet will be being sent at once, the only 
>> problem is
>> this may slow the transfer down waiting for the responses before 
>> sending the
>> next, but since this is only designed to be used as a fall back and 
>> for tiny
>> files I dont see this as a real problem, IMO iq is definatelly the 
>> way to go
>> as message presents a lot more potensial problems in the long run 
>> IMO. Also
>> using iq means it is not unnecessarily dependent on other protocols 
>> such as
>> x:event and x:expire just to fix the problems with using message as 
>> the data
>> transport which IMO are not a problem with iq.
> 1.) It _must_ be the responsibility of the server to "protect" 
> low-bandwidth resources. The server is the only place in the system 
> where that protection can happen. We certainly can't depend upon 
> clients to respect other client's bandwidth -- if we could, there 
> would be no need for the concept of karma and rate-limiting.

Sure but designing a protocol so most of the these extra 
responsibilities are not needed on the server end is a better goal.

> 2.) The _opinion_  that IBB packets should never go to offline is not 
> universally shared. Why do you want to force a single behaviour when 
> you could have both for free?

Ok then, why realistically would you want the packets to be stored 
offline, and how does using message allow both?? I thought that almost 
all messages are stored offline if the user is offline, also what about 
the IMO serious problem of these packets going to other resources when 
the user goes offline and not getting stored offline, surely this stops 
any real reliable reasons for offline storage of file transfer 
messages, being that is cant be guaranteed that packets will be saved 
offline if a resource goes offline?

> 3.) Regardless if we use <iq> or <message>, we'll need sequence 
> numbers. We've already been over this.

Im sorry but thinking about it logically I dont think there is any need 
for seq numbers when using iq if you are only sending one packet at 
once, have think about it.

> 4.) Relying on x:event and x:expire is _not_ a bad thing -- that's 
> what they are there for. They are behavioral modifiers that are meant 
> to be used.

Yes but what's the point when the protocol IMO could be designed in IMO 
a better way which would negate those requirements, surely thats a good 

> 5.) Using <message> as a data transport is specifically what that 
> element was DESIGNED to do. <iq> is meant as a conversation 
> faciliator, not general purpose data transport. The design purpose of 
> protocol elements is an important consideration in this conversation 
> since we are discussing a protocol extension. Protocol extensions 
> should always blend with the environment in which they exist.

Depending on how you are doing a data transfer it doesn't necessarily 
mean that message is the best transport for it, message AFAIWC was for 
transferring text messages between clients with optional extended 
namespaces, now data transfer extends the requirements for message 
beyond its current scope, no messages in a particular transfer session 
must be lost (does really matter for text messages), the extended 
namespace relies on other messages i.e. has a multipart requirement 
(none of the previous extensions directly affect or rely on other 

> This whole argument around <iq> and <message> almost makes me wonder 
> if certain people would just prefer to get rid of <message> and mix 
> all the semantics therein into the <iq> element. It doesn't make any 
> sense to me.

Why?? I dont see how this relates to complete replacement of message?? 
File transfers just have different requirements which IMO could be 
better served using iq as the transport mechanism that using message.


More information about the Standards mailing list