Subject: [xmpp] 9.1.3 replacement text suggestion:

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 6 Aug 2009 13:33:35 -0700

A another attempt at 9.1.3 replacement text:
The 'id' attribute purpose is to allow an entity sending a original  
stanza to identify the stanza, if any, received in response to that  
stanza.  For instance, it can be used to associate an error stanza  
with the stanza that caused the error.  While the attribute is  
optional attribute of the element (from a schema perspective), it  
appear in stanza is at time mandatory in the protocol, at other times  
its absence is mandatory in the protocol, and otherwise elective.
When an entity is sending a stanza in response to a received stanza or  
is forwarding a received stanza, the entity MUST NOT provide an 'id'  
attribute if the received stanza did not have an 'id' attribute,  
otherwise it SHALL provide an 'id' attribute with same value as the  
'id' of the received stanza had.
In other cases, unless otherwise required (such as in <iq> requests),  
providing a 'id' attribute is elective.  Though not required, it is  
strongly encouraged that entities provide 'id' attributes they can  
identity stanzas sent in response to those stanzas, such as error  
stanzas.

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 6 Aug 2009 13:40:01 -0700

Correcting a couple of typos (sorry) and other wordsmithing:

The 'id' attribute purpose is to allow an entity sending an original  
stanza to identify the stanza, if any, received in response to that  
stanza.  For instance, it can be used to associate an error stanza  
with the stanza that caused the error.  While the attribute is  
optional attribute of the stanza (from a schema/syntax perspective),  
its appearance in stanza is at time mandatory, at other times its  
absence is mandatory, and otherwise elective.

---

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

> identity stanzas sent in response to those stanzas, such as error 

For one, you are over-complicating it.
Look at the original text (which is just fine IMHO, by the way) and your 
replacement.
At times, I have hard time understanding what you mean. Wording is 
difficult to comprehend ("sending a original stanza to identify the 
stanza, " .. the original stanza? you have to read ahead to understand.) 
It's typical high-school example of using so complicated compound 
sentences it's actually almost unreadable. It might be just me of 
course, but I find it worse by orders of magnitude compared to the 
original text.
Sorry for such harsh critics, but I really think this is not the way to go.

Jiří

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 6 Aug 2009 14:01:37 -0700

On Aug 6, 2009, at 1:40 PM, Kurt Zeilenga wrote:

> When an entity is sending a stanza in response to a received stanza  
> or is forwarding a received stanza, the entity MUST NOT provide an  
> 'id' attribute if the received stanza did not have an 'id'  
> attribute, otherwise it SHALL provide an 'id' attribute with same  
> value as the 'id' of the received stanza had.
>
> In other cases, unless otherwise required (such as in <iq>  
> requests), providing a 'id' attribute is elective.  Though not  
> required, it is strongly encouraged that entities provide 'id'  
> attributes they can identity stanzas sent in response to those  
> stanzas, such as error stanzas.

The following paragraph would cover the only uniqueness requirement.

> The entity originating the value of the 'id' attribute need only  
> ensure the value is sufficiently unique to allow it to properly  
> relate its stanzas.

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 6 Aug 2009 15:56:39 -0700

Going back over the original text:

--- Sentence 1 ---

One could regard the sentence:
    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).
simply a statement of the purpose of the 'id' attribute.  That  
consider the meaning of the sentence if MAY is replaced with may,  
which simply expresses a possibility.  (Whether it really a  
possibility depends on what others do with it, which this section is  
quite silent on.)
Anyways, here is a restatement of the purpose of the attribute:
    The 'id' attribute purpose is to allow an entity, at its option,  
to relate stanzas it receives in response (or in error) to stanzas it  
originated.
Now, it's been noted that the MAY was intended to express either or  
both:
    The 'id' attribute is optional component of the stanza (which  
presence or absence may be required by the protocol in certain cases).
    The inclusion of the 'id' attribute by the sending entity is  
OPTIONAL.
The latter is quite problematic as 'sending entity' here could be  
taken as any entity sending any stanza, including stanza which are  
sent in response (or in error) to another stanza, or in forwarding a  
stanza.
The former is only problematic when one says "The 'id' attribute is  
optional" without clarification that the protocol mandates its  
presence/absence in certain cases (so that tracking can work).
--- Sentence 2 ---
   The value of the 'id' attribute MAY be unique globally, within a  
domain, or within a stream.
This sentence appears to be make a broad statement concerning the  
uniqueness of 'id' values.  Simply put, nothing in the protocol  
requires or ensures values be unique in any way.
What I assume this statement was intended to express was that values  
of the 'id' attribute should be created by the originating entity in a  
manner which allows for proper tracking.  This could simply be stated:
   The value of the 'id' attribute is any string which allows the  
originator of the stanza to adequately relate stanzas.
--- Sentence 3 ---
    The semantics of IQ stanzas impose additional restrictions; see  
Section 9.2.3.
No problem.
--- Unstated ---
Section 9.1.3 doesn't state any general requirements that 'id' values  
be preserved in responding to stanzas.
Section 9.1.3 doesn't state any general requirements that 'id' values  
be preserved in forwarding.
There seems to be no discussion of the stanza's 'id' attribute outside  
of 9.1.3 and 9.2.3.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 10 Aug 2009 15:03:50 -0600

> A another attempt at 9.1.3 replacement text:

It's not fully clear to me what you find unclear in the original text,
but I suggest the following clarifications...

***

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).

   The value of the 'id' attribute can be unique globally, within a
   domain, or within a stream.

   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 is <message/> or <presence/> then it is
   RECOMMENDED for the entity that returns a response or error stanza to
   include an 'id' attribute if the generated stanza included one; for
   <iq/> stanzas, it is REQUIRED.  The value of the 'id' attribute in a
   response or error stanza MUST match that of the generated stanza.

   Note: The semantics of IQ stanzas impose additional restrictions; see
   Section 9.2.3.

***

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 10 Aug 2009 15:40:05 -0700

On Aug 10, 2009, at 2:03 PM, Peter Saint-Andre wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

Your suggestion addresses many, but not all, of my concerns.

>   domain, or within a stream.

I am slightly concerned that this statement could be taken as meaning  
the receiving entity can make assumptions about the uniqueness of  
values it receives, such as two <iq/> requests originated by the  
entity in the same stream will have unique id values.  I would rather  
this be worded more clearly as guidance to the originating entity on  
how to produce suitable values.   However, for now, I'm let this lie.

>   response or error stanza MUST match that of the generated stanza.

Why would it be allowed for an entity not to include an 'id' attribute  
when the "generated stanza" included an 'id' attribute?  That is,  
shouldn't the RECOMMENDED be a REQUIRED.

Also, this text does not state a requirement that an entity sending a  
stanza in forwarding a stanza they receive is in anyway obligated to  
forward the id value, if any, they received.  I don't see where this  
is elsewhere required by the specification.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkqAizYACgkQNL8k5A2w/vwHUwCgmssY405mnQGDCjWX6T0Q7o5T
> tksAoKjsGBVZTZFDs9S8RjybPpR9bQh+
> =oG05
> -----END PGP SIGNATURE-----
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 10 Aug 2009 17:11:08 -0600

On 8/10/09 4:40 PM, Kurt Zeilenga wrote:
>> the receiving entity can make assumptions about the uniqueness of values
>> it receives, such as two <iq/> requests originated by the entity in the
>> same stream will have unique id values.  I would rather this be worded
>> more clearly as guidance to the originating entity on how to produce
>> suitable values.   However, for now, I'm let this lie.

It seems sensible to provide clear guidance to the originating entity. I
suggest the following:

   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.

>> shouldn't the RECOMMENDED be a REQUIRED.

Because that's the way it's always been. In large measure, both
<presence/> and <message/> stanzas are fire-and-forget communications
that the originating entity does not necessarily want or need to track
in the way that IQs are tracked. Changing that is part of a larger
discussion, I think.

>> forward the id value, if any, they received.  I don't see where this is
>> elsewhere required by the specification.

I don't understand your concept of forwarding. Do you mean routing or
delivering? These concepts are mostly clear in the specs: roughly, to
"route" means for a local server to take a stanza it has received and
send it along to a remote server, and to "deliver" means for a server to
take a stanza it has received and send it along to the intended
recipient. (This leaves components out of the description, but I think
that is OK for 3920bis and 3921bis.)

As far as your point goes, nothing in the specification says that an
intermediate entity (server) MUST leave any common attributes ('from',
'to', 'type', 'id', 'xml:lang') or defined elements (say, presence
<priority/> or message <subject/>) untouched. This has always been
assumed, because it's the whole point of the server to route or deliver
stanzas! If we need to spell this out, then I think it belongs somewhere
other than in the definition of the 'id' attribute.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Jack Moffitt <[email-masked]>
Date: Mon, 10 Aug 2009 17:17:49 -0600

> in the way that IQs are tracked. Changing that is part of a larger

I think Kurt meant (and if so, I agree), that if hte originating
stanza contained an id attribute, the response (if any) should be
required to contain the id attribute as well regardless of whether it
is an IQ or not.

jack.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 10 Aug 2009 17:20:20 -0600

> required to contain the id attribute as well regardless of whether it

I agree that's what Kurt meant. I am not sure if that's what we want the
spec to say. :)

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Florian Zeitz <[email-masked]>
Date: Tue, 11 Aug 2009 01:44:21 +0200

> I agree that's what Kurt meant. I am not sure if that's what we want the

I personally think that is what it should say, too.
While I understand that message and presence stanzas are generally fire
and forget, I'd argue that at least if the response is an error (which
the RFC suggests might happen) it is absolutely usless without an id.
Basically I suspect that if a message/presence stanza causes a response
it will be wiser to always have an id on that.

Florian

---

From: Jiří Zárevúcky <[email-masked]>
Date: Tue, 11 Aug 2009 03:16:52 +0200

On 08/11/2009 01:44 AM, Florian Zeitz wrote:
>>>> <presence/>  and<message/>  stanzas are fire-and-forget communications

Spec shouldn't require all stanzas to include the id attribute (the 
resource consumption overhead may be a bit too much for some devices 
IMO), but I think it's reasonable to require it's mirroring in errors 
when it's present. It's mostly just a matter of one simple operation, so 
I doubt it will hurt anyone to implement it.

It may also be worthwhile to note that for errors mirroring 'id', it's 
completely needless to mirror the content.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 10 Aug 2009 20:41:28 -0600

> it will be wiser to always have an id on that.

I thought about this some more after I sent my last message, and I think
you're right. It's a change from RFC 3920, but it seems appropriate.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 10 Aug 2009 20:47:31 -0600

> you're right. It's a change from RFC 3920, but it seems appropriate.

In my working copy I now have this:

   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.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 11 Aug 2009 09:31:37 +0100

>>On Aug 10, 2009, at 2:03 PM, Peter Saint-Andre wrote:
 [...]

>   attribute will be unique only within its current stream (session)
This is better.