[Standards] definition of common attribute 'id'

Kurt Zeilenga 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  
opaque value.
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  
-- Kurt

More information about the Standards mailing list