Remko Tronçon;5491 Wrote: > > 6.2 is about how caps information relates to the actual result of disco > info. > 7 describes what things you should advertise to announce your support > for XEP-115. Every XEP has a section on what namespaces it uses. This > one is just an edge case because you can determine support through the > type of presence stanzas it sends, but still, this is the standard way > of announcing support. >
I agree. This is why I was writing that both sections should remain, but just that we should more clearly show that the contents in both response stanzas is the same. Just they are sent in different use case. This is just to make this XEP clearer. > > You can never deprecate service discovery, because caps builds on it. > Without service discovery, there is no caps. > Yes I agree too. I use the wrong word. I did not mean that the service discovery XEP is deprecated of course! I simply mean it like in "best practice". If all entities support caps, it seems obvious that best practices are that any entity should not send a service discovery request "out of the caps context" (which means to associate a caps node to a list of features, this association being cached for further use). If entities are still sending service discovery requests every time (even when you have already cached the node features through caps!), then the caps extension loses all its usefulness. > > > > If all communicating entities supports "caps", there should be no > > service discovery information request sent other than one to learn > the > > features associated to a caps information (section 6.2). > > Yes, there should: if the information is not cached yet. Section 5.4, > bullet 3.8 says that you should cache the result, which is another way > of stating that you shouldn't do disco request floods anymore. I guess > it doesn't hurt to make it more explicit. > > cheers, > Remko I agree also. And this is exactly what you quoted from me: "other than one to learn the features associated to a caps information". This is exactly what you says: the goal is simply to make explicit the fact that there should be no disco/flood, hence stop old disco practices (hence we just "depreciate" the old practice, NOT the "service discovery" of course, to come back to your previous remark) and use new one. So yes of course, send disco for not cached node/features association just once, then never again. And also disco requests should always be associated to a "node" (of course, this only when both entities supports caps) for further caching the association. In the end, I think we just agree on all this... All I propose is to add clarity to this XEP because I was implementing it on some software and was thinking the XEP could be made clearer. Jehan -- Jehan ------------------------------------------------------------------------ Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 View this thread: http://www.jabberforum.org/showthread.php?t=1175
