On Dec 18, 2007, at 12:03 PM, Peter Saint-Andre wrote:
The disco#info request is sent by the requesting entity to the
generating entity. The value of the 'to' attribute MUST be the exact
JID
of the generating entity, which in the case of a client will be the
full
JID (<[EMAIL PROTECTED]/resource>).
The disco 'node' attribute MUST be included for backwards-
compatibility.
The value of the 'node' attribute SHOULD be generated by concatenating
the value of the caps 'node' attribute (e.g.,
"http://code.google.com/p/exodus";) as provided by the generating
entity,
the "#" character, and the value of the caps 'ver' attribute (e.g.,
"8RovUdtOmiAjzj+xI7SK5BCw3A8=") as provided by the generating entity.
+1
Section 6.3 is really cool.
Perhaps because that was your suggestion. :)
Heh. Perhaps the idea was better than person that suggested it,
then. :)
Is it always going to be clear what the
associated JID will be for the stream?
I would think it's the 'from' address from the response stream header.
Did we decide those would always be there? Even for multi-homed
hosts? That makes sense. Perhaps there should be a note of that in
section 6.3, then.
Section 9, the MAY isn't as strong as I'd like. I think SHOULD is
too
strong. RECOMMENDED seems to be a synonym for SHOULD... Maybe MAY as
normative, with another sentence that says this is recommended (lower
case).
Some wordsmithing on my part yields:
***
It is RECOMMENDED for an application that processes entity
capabilities
information to cache associations between the 'ver' attribute and
discovered features within the scope of one presence session. This
obviates the need for extensive service discovery requests within a
session.
It is OPTIONAL for an application to cache associates across presence
sessions. However, since this obviates the need for extensive service
discovery requests at the beginning of a session, such caching is
strongly encouraged, especially in bandwidth-constrained environments.
+1
--
Joe Hildebrand
