Subject: [xmpp] definition of common attribute 'id'

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 4 Aug 2009 19:32:49 -0700

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

---

From: Jiří Zárevúcky <[email-masked]>
Date: Wed, 05 Aug 2009 17:32:49 +0200

> request stanza MAY include an 'id' attribute.

I find the text clear enough as it is, but it may need some 
clarification. Anyway, your proposed text is not entirely correct, as 
the stanza being responded to may not necessarily be a request (for 
example when some error occurs).
Following text would me more appropriate I think:

     The 'id' attribute is used to associate a response stanza (for 
example an IQ result or an error) with the stanza that caused it (for 
example IQ request or a sent message).
     The value of the 'id' attribute MUST be such that the sending 
entity is always able to associate the cause and response correctly.
     This usually means uniqueness to some extent for the sending 
entity, but it is fully opaque to the receiving entity.
     Unless otherwise specified, inclusion of the 'id' attribute is 
OPTIONAL.

> request.  This requirement does not appear to be well specified.

I think it was there somewhere. For IQ stanzas at least, it's implied. I 
can't find any mention in the section about stanza errors, though.

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 5 Aug 2009 11:31:31 -0700

On Aug 5, 2009, at 8:32 AM, Jiří Zárevúcky wrote:

> example an IQ result or an error) with the stanza that caused it  
> (for example IQ request or a sent message).

I think the term 'sending entity' is ambiguous here.  It could refer  
to any entity sending a stanza with an id attribute,
including an entity originating a request, forwarding a request,  
responding to a request, or forwarding a response to a request.

I think you mean 'originating entity', the identity which originated  
the request stanza and its id attribute.

I assume that the MUST applies to the originator, not to any other  
entity.  But this leaves no mandate to forward
or return id attributes.

> entity, but it is fully opaque to the receiving entity.

Again, I think you mean 'originating entity' instead of 'sending  
entity'.  As the sending entity is in the end
a receiving entity (of the response), it would be to replace "the  
receiving entity" with "other entities".

>    Unless otherwise specified, inclusion of the 'id' attribute is  

This is bad as it implies that any of those other entities can drop  
the 'id' attribute the originating provided.

-- Kurt

---

From: Jiří Zárevúcky <[email-masked]>
Date: Wed, 05 Aug 2009 22:01:34 +0200

> entity.  But this leaves no mandate to forward

Yes, I mean "originating entity".

> receiving entity" with "other entities".

Yes, "other entities" would be better there as well.

> the 'id' attribute the originating provided.

Any intermediate entity is not the originator. They just pass the stanza 
along and so this rule is irrelevant for them, as it applies to entity 
*creating* the stanza.
You are actually suggesting that the server can strip any optional parts 
from *your* stanzas, which is clearly nonsense.

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 5 Aug 2009 14:20:56 -0700

On Aug 5, 2009, at 1:01 PM, Jiří Zárevúcky wrote:
> Any intermediate entity is not the originator.

Yes, but this statement doesn't say it's the originators option.  It  
says it's anyone option (because it fails to
say who has the option).

> They just pass the stanza along and so this rule is irrelevant for  
> them, as it applies to entity *creating* the stanza.

I understand this is what's intended.  I just think the text doesn't  
clearly state what's is intended.

> You are actually suggesting that the server can strip any optional  
> parts from *your* stanzas, which is clearly nonsense.

I'm suggesting that the OPTIONAL statement could be taken as license  
to strip the 'id'.

-- Kurt

---

From: Jiří Zárevúcky <[email-masked]>
Date: Thu, 06 Aug 2009 00:46:17 +0200

> I'm suggesting that the OPTIONAL statement could be taken as license 

The attribute is optional to include, not optional to pass along. Server 
must pass everything, unless it has some specific rules for processing 
some specific data. Otherwise it would mean you could freely tamper with 
anything else, let's say remove 'from' or 'to' attributes, just because 
they're optional. That would be just absurd.

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 5 Aug 2009 16:21:45 -0700

On Aug 5, 2009, at 3:46 PM, Jiří Zárevúcky wrote:

>>>> This is bad as it implies that any of those other entities can  
>>>> drop the 'id' attribute the originating provided.
>>>>
>>>
>> Yes, but this statement doesn't say it's the originators option.   
>> It says it's anyone option (because it fails to
>> say who has the option).
>>
>> I understand this is what's intended.  I just think the text  
>> doesn't clearly state what's is intended.
>>
>> I'm suggesting that the OPTIONAL statement could be taken as  
>> license to strip the 'id'.
>>
>> -- Kurt
>
> The attribute is optional to include,

The statements:
	"inclusion of the 'id' attribute is optional"
and
	"inclusion of the 'id' attribute is OPTIONAL"
do not say the same thing.

"optional" means attribute is not required by schema.
"OPTIONAL" means that implementation of inclusion of the attribute is  
elective.

As you note that certain entities MUST implement inclusion of the  
attribute, such as when creating a stanza in forwarding/responding to  
a request with such an attribute, implementation of the inclusion of  
the attribute needs to MANDATORY.

---

From: Jiří Zárevúcky <[email-masked]>
Date: Thu, 06 Aug 2009 01:39:49 +0200

> the attribute needs to MANDATORY.

You're very wrong. These words mean level of requirement for given 
statement, but they don't have anything to do with implementation by 
themselves. I don't know how you got the idea. Many specifications 
wouldn't even make sense that way. See the RFC in question 
(http://www.ietf.org/rfc/rfc2119.txt).

To mean what you think it means, it would need to say "support for 'id' 
attribute is OPTIONAL", which it doesn't.

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 5 Aug 2009 19:24:06 -0700

On Aug 5, 2009, at 4:39 PM, Jiří Zárevúcky wrote:

>>>>> They just pass the stanza along and so this rule is irrelevant  
>>>>> for them, as it applies to entity *creating* the stanza.
>>>>
>>>>> You are actually suggesting that the server can strip any  
>>>>> optional parts from *your* stanzas, which is clearly nonsense.
>>>>
>> "OPTIONAL" means that implementation of inclusion of the attribute  
>> is elective.
>>
>> attribute, such as when creating a stanza in forwarding/responding  
>> to a request with such an attribute, implementation of the  
>> inclusion of the attribute needs to MANDATORY.
>>
>
> wouldn't even make sense that way. See the RFC in question (http://www.ietf.org/rfc/rfc2119.txt 
> ).

Paraphrasing RFC 2119:
    One vendor (in their implementation) may choose support inclusion  
of the attribute (in stanzas they send) while another vendor (in their  
implementation) may choose not to support inclusion of the attribute  
(in stanzas they send).
However, a you noted, for the tracking to work, all XMPP  
implementations MUST support inclusion of the attribute.  In  
particular, they MUST support inclusion when constructs a stanza when  
forwarding a request, responding to a request, or forwarding a  
response, support inclusion in that stanza the identifier they  
received.  What's OPTIONAL, is that in originating a request stanza  
(using the term here to refer to any stanza which requests an action,  
including delivery of a message or presence update), the originator of  
the request stanza MAY provide an id attribute.
Note: I use the terms request and response to refer to paired stanzas,  
such as iq request/response, or message/message-error pair, etc., even  
though only the second of the pair is not always produced.
As RFC 2119 should be used sparingly, I would only use them to express  
the mandate that XMPP entities constructing a stanza in response to a  
stanza or in forwarding a stanza SHALL, if the received stanza  
included an id attribute, include an id attribute with the same value  
in the stanza they send.
As to the option of originator, I actually suggest we don't use MAY or  
OPTIONAL.  Instead, I would use "the originator of the request stanza  
can provide an id attribute" (or the like) and I would strongly  
encourage them to do so with every stanza.   The reason why is that  
this promotes proper handling of errors.  As <message/> stanzas are  
only responded to when an error occurs, any client which send multiple  
<message/> stanza ought to be placing id's on them so that able to  
take appropriate action on return of an error.  An implementation  
which chooses not to send ids on <message> stanzas they originate is  
effectively saying they are ignore errors.  Ignoring errors can be  
quite harmful to the other entities and the Internet, hence one might  
even argue implementations SHOULD provide id attributes in requests  
they originate.
-- Kurt