-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/2/09 1:54 PM, Peter Saint-Andre wrote: > On 11/2/09 11:42 AM, Tory Patnoe wrote: >> On 10/27/2009 01:58 PM, Peter Saint-Andre wrote: >>> As to whether the server needs to deliver inbound presence subscription >>> stanzas (subscribed, unsubscribe, unsubscribed), my reasoning is that if >>> the server does not deliver them to the client then the client has no >>> way to tell whether the roster push was generated by another resource or >>> triggered by the contact. >>> >> Would it not be better to put that information in the roster-push itself? > >> Perhaps with a copy of the triggering stanza as a sub-element to the >> roster push. That way client writers would not have to use two stanzas >> to trigger an event but look for a single stanza in the roster push >> while looking for extra details. > >> If the "double" stanza is preferred then I believe the presence stanza >> MUST be delivered _before_ the roster push. > > The double stanza is the way things have been specified since 1999. If > we define a new roster protocol (a hot topic of discussion a few months > ago), we'd add this feature to that protocol rather than force it into > the old protocol. I chatted with Tory about this offlist. He's right that the subscription-related presence stanza MUST be sent before the roster push, so I've updated my working copy of 3921bis to clarify that. I also checked RFC 3921 and it is a MUST there to pass along the subscription-related presence stanza. Thus the only difference between 3921 and 3921bis is that we have made the order of events explicit (presence stanza, then roster push). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrvTxEACgkQNL8k5A2w/vzB3gCfQj2dV6/GWWFi0QvWT73YCBFo gqsAoOfG/+tqs1iYRLwHYZOCxog2CZsI =pB3V -----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.