[Standards] Missing point in XEP-0115: Entity Capabilities ?
Jehan.3k7mvn at no-mx.jabberforum.org
Wed Dec 10 16:00:08 UTC 2008
Remko TronÃ§on;5491 Wrote:
> 6.2 is about how caps information relates to the actual result of disco
> 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
> > 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.
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's Profile: http://www.jabberforum.org/member.php?userid=16911
View this thread: http://www.jabberforum.org/showthread.php?t=1175
More information about the Standards