Tomasz Sterna wrote: > On Pt, 2007-10-05 at 16:33 -0600, Peter Saint-Andre wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. > > Another question: > > 3.1.5. Server Processing of Outbound Subscription Approval > "The contact's server then MUST send a roster push to all of the contact's > interested resources." > > This does not differentiate whether the contact first asked for subscription.
Do you mean the "pre-approval" use case or the use case in which the roles are reversed after the parties already negotiated a one-way subscription, i.e., the scenario mentioned at the end of Section 3.1.5? That is: ****** In order to subscribe to the user's presence, the contact would then send a subscription request to the user. (XMPP clients will often automatically send the subscription request instead of requiring the contact to initiate the subscription request, since it is assumed that the desired end state is a mutual subscription.) Naturally, when the contact sends a subscription request to the user, the subscription states will be different from those shown in the foregoing examples (see Appendix A (Subscription States)) and the roles will be reversed. ****** > You always get a new roster item with subscription='from'. > > This stays in contrary to the 3.1.3.3. "pre-approval" that should create > new item of ask='subscribed' not subscription='from'. Right, section 3.1.5 doesn't talk about that. In fact all of Section 3.1 tries to walk you through the initial subscription process so you can understand it the first time, without needing to think about things like pre-approvals and bidirectional subscriptions. The gory details for exactly how to handle a given subscription-related stanza at a given point in the state chart are in Appendix A. Would it help to add pointers to Appendix A more often? > 3.1.5. also does not take into account if the item already have > subscription='from' > and pushes unneeded presence packet to the wire. Correct. See Appendix A. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
