IQ's cannot be guaranteed unique on an incoming stream, since like someone said, incrementing numbers are often used. Non-uniqueness on a incoming stream certainly isn't an error condition - even if you wanted to argue it was, there isn't much the local client can do about it.
On 10/30/05, Chris Mullins <[EMAIL PROTECTED]> wrote: > Michael Finney Wrote: > > Must the 'id' attribute of an IQ stanza be unique? I do > > not see the answer in RFC 3920. > > > Section 9.1.3 of Core says: > > > It is OPTIONAL for the value of the 'id' attribute > > to be unique globally, within a domain, or within > > a stream. > > Much to my surprise, section 9.2.3 (IQ Semamtics), did not further > restrict this, and make the 'id' attribute unique on a stream. It only > says that the 'id' attribute is required for IQ packets. > > >From a practical perspective, the value of the 'id' attribute is > typically unique over a stream. We use GUID's by default which are > globally unique, but most SDK's, Clients, and Servers simply use an > incrementing number. > > Where this typically becomes an issue is on the client side - A client > may send out 5 or 6 (or 100 or 200) IQ requests. As the responses come > back from various clients and servers, the client needs to be able to > match them up with the original sending packet. If the ID attributes > aren't unique, then the matching logic need be very esoteric. > > -- > Chris Mullins > Coversant, Inc. >
