[jdev] IQ Semantics RFC 3920 9.2.3 IQ Semantics

[David Waite]

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 <chris.mullins at coversant.net> 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.
>