<div dir="ltr">Hi Ralph, <div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-10-05 20:12 GMT+02:00 Ralph Meijer <span dir="ltr"><<a href="mailto:ralphm@ik.nu" target="_blank">ralphm@ik.nu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2015-10-05 10:48, Stefan Strigler wrote:<br>
> Hey there,<br>
><br>
> when implementing parts of XEP-0060 I came across a maybe inconsistency<br>
> when it's about unsubscribing from a Node (Section 6.2.2<br>
> - <a href="http://xmpp.org/extensions/xep-0060.html#subscriber-unsubscribe" rel="noreferrer" target="_blank">http://xmpp.org/extensions/xep-0060.html#subscriber-unsubscribe</a>).<br>
><br>
> If we'd allow to also have a the resulting subscription element in the<br>
> response, the implementation can be kept more generic, you always reply<br>
> with the resulting status of the subscription, no matter if it was a<br>
> subscribe or an unsubscribe.<br>
><br>
> Thus my PR at<br>
><br>
> <a href="https://github.com/xsf/xeps/pull/106" rel="noreferrer" target="_blank">https://github.com/xsf/xeps/pull/106</a><br>
><br>
> I am aware that for unsubscribing the additional information given is<br>
> redundant. That's why I changed it to MAY after I first suggested a<br>
> SHOULD there.<br>
<br>
</span>Hey Stefan,<br>
<br>
While I appreciate the suggestion, if the goal is to make the<br>
implementation more consistent, how would you deal with entities that<br>
don't return that element on the receiving end? Especially given you<br>
suggest making it optional. I'd say that the potential gains are highest<br>
for pubsub clients, but if you can't rely on a server giving that<br>
element always, there's no gain, really. It doesn't even matter that<br>
much if it is a MAY or SHOULD.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Cheers,<br>
<br>
ralphm<br>
</font></span></blockquote></div><br></div>