[Standards] definition of common attribute 'id'
Kurt.Zeilenga at Isode.com
Wed Aug 5 01:37:20 UTC 2009
The definition of 'id' (9.1.3 of 3920bis) says:
> The 'id' attribute MAY be used by a sending entity for internal
> tracking of stanzas that it sends and receives (especially for
> tracking the request-response interaction inherent in the semantics
> of IQ stanzas). The value of the 'id' attribute MAY be unique
> globally, within a domain, or within a stream. The semantics of IQ
> stanzas impose additional restrictions; see Section 9.2.3.
I think the first MAY is trying to do two things at once. It's trying
to 1) state that providing the 'id' attribute is at the sending
entity's option and 2) what the purpose of the attribute is. I think
it would be better to separate these. For instance:
The purpose of the id attribute is to allow a response stanza
to be associated with a particular request stanza.
Except where specified differently, the entity originating a
request stanza MAY include an 'id' attribute.
I note that 'sending entity' is a term that not well defined.
Elsewhere in the document, 'sending entity' simply refers to the
entity which sent a particular stanza (and 'receiving entity' simply
refers to an entity which received a particular stanza).
If we use this meaning here, this sentence could be read that the
entity sending a response stanza has the option not to include the id
attribute provided in the request stanza as it is 'sending' the
response stanza. Even if we took the 'sending entity' to refer to a
party sending a request, that would imply that a server sending a
request on behalf of a client MAY not include the id attribute the
client provided when it originated the request.
I would think for this feature to "work" in general, an entity
responding to a request containing an id attribute MUST provide an id
attribute with the same value as the request contained in the
request. This requirement does not appear to be well specified.
As far as unique, no uniqueness property should be assumed by the
receiving entity. The receiving property should treat id values as
While the originating entity of a request could ensure values they
generate have some uniqueness property, the only actual requirement is
that originating entities SHOULD produce values in a manner which
ensures that outstanding requests (requests they've sent but have yet
to receive a response for) do not share the same value. For instance,
an implementation which serializes it requests (never has more than
one outstanding) could use the same id value for all requests it
More information about the Standards