Hi Ralph, I totally agree, I've been thinking about this as well. It's just that I consider it too unrealistic to have that prominent XEP changed so significantly. Maybe I'm wrong?
I brought that up because if you're operating in a controlled environment, client wise you know what you can rely on, i.e. you know the exact behavior of your service component. In general, what's the philosophy being followed at other XEPs? Favor ease of implementation over conciseness of the protocol or rather the other way round? 2015-10-05 20:12 GMT+02:00 Ralph Meijer <ral...@ik.nu>: > On 2015-10-05 10:48, Stefan Strigler wrote: > > Hey there, > > > > when implementing parts of XEP-0060 I came across a maybe inconsistency > > when it's about unsubscribing from a Node (Section 6.2.2 > > - http://xmpp.org/extensions/xep-0060.html#subscriber-unsubscribe). > > > > If we'd allow to also have a the resulting subscription element in the > > response, the implementation can be kept more generic, you always reply > > with the resulting status of the subscription, no matter if it was a > > subscribe or an unsubscribe. > > > > Thus my PR at > > > > https://github.com/xsf/xeps/pull/106 > > > > I am aware that for unsubscribing the additional information given is > > redundant. That's why I changed it to MAY after I first suggested a > > SHOULD there. > > Hey Stefan, > > While I appreciate the suggestion, if the goal is to make the > implementation more consistent, how would you deal with entities that > don't return that element on the receiving end? Especially given you > suggest making it optional. I'd say that the potential gains are highest > for pubsub clients, but if you can't rely on a server giving that > element always, there's no gain, really. It doesn't even matter that > much if it is a MAY or SHOULD. > > -- > Cheers, > > ralphm >
