-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Comment at bottom.
On 8/4/09 7:37 PM, Kurt Zeilenga wrote:
> 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 generates.
> -- Kurt
In draft-ietf-xmpp-3920bis-02 can be found the following text:
***
9.1.3. id
The 'id' attribute is used by the entity that generates a stanza
("the originating entity") to track any response or error stanza that
it might receive in relation to the generated stanza from another
entity (such as an intermediate server or the intended recipient).
It is up to the originating entity whether the value of the 'id'
attribute will be unique only within its current stream (session) or
unique globally.
For <message/> and <presence/> stanzas, it is RECOMMENDED for the
originating entity to include an 'id' attribute; for <iq/> stanzas,
it is REQUIRED.
If the generated stanza includes an 'id' attribute then it is
REQUIRED for the response or error stanza to also include an 'id'
attribute, where the value of the 'id' attribute MUST match that of
the generated stanza.
Note: The semantics of IQ stanzas impose additional restrictions; see
Section 9.2.3.
***
If that is still unclear, please post to this list.
/psa
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkqwIN4ACgkQNL8k5A2w/vz7SwCgsmvV4PGotQiLjJHy219Lfs/J
0XMAoJsLYqWcLZvfxPiKH188EVf3q8xk
=djqI
-----END PGP SIGNATURE-----
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.