On 2/24/09 8:53 AM, Jiří Zárevúcký wrote: > Hello all. > > I've been thinking about the current subscription management in the > XMPP-IM for some time now. I think it's not very well designed.
Where were you in 1999?!? We could have used your help back then. > For example, there's an obvious redundancy in the roster pushes and > subscription stanzas. For (almost) every subscription update / > request, there is a presence stanza and a roster push. But that only > applies to the contact, who receives the change. Also, the "ask" > attribute looks like a maimed boolean and roster pushes do not contain > all the state information - inbound request is missing. > > Even though the client can track most of the changes by tracking > roster pushes and subscription stanzas, there is one change client can > never track. When there is an inbound subscription request with no > item and user declines it, other resources get no push and no presence > stanza - no notification. That is not really a big problem, but all > this inconsistency in pushes and presence stanzas makes it all seem > very chaotic and untidy. Yep. But what is broken? We don't make protocol changes just for aesthetics. > Originally, I wanted to propose modifying roster pushes so they > contain all the state information (including eventual inbound > subscription request message), essentially leaving > subscription-managing presence stanzas only as the mean of requesting > the change, not presenting it to the other entity or the other > resources. Then one thing occured to me. Do we really need a separate > subscription handling for inbound and outbound presences? Users > generally don't want it separate. Users want mutual subscription. Is > there ever need to have one-side subscription? Sometimes. But I agree that for most end users they don't need that. IMHO this is a client interface issue, not a protocol issue. > Providing mechanism for just a mutual subscription, where there would > be only both-direction or pending or no subscription at all, would > immensely simplify things for both users and implementers. Yes, I > agree that immediate effect would be increasing complexity and need of > additional effort to maintain backward compatibility. There's the rub. This kind of effort is a non-starter. > That would be a > tricky task, but I believe that with proper interoperability rules, it > would be possible to make transition relatively painless. I believe > that in a long run, such change would be a huge improvement. For whom? > So, in case you are interested in this idea, I will continue with some > semantics I have on my mind. Otherwise, just tell me why do you think > it is not possible / feasible / wanted to implement it. I'm pretty > sure there is some hidden problem with this I don't realize. I suppose > many of you won't take me too seriously, since it would require too > massive change to the core protocol, but I'd appreciate if you thought > about it a bit. Thanks for any feedback. My feedback is: don't waste time on this kind of project. The problems with backwards-compatibility make it infeasible. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
