Joe Hildebrand wrote: > > On Dec 7, 2007, at 8:41 AM, Peter Saint-Andre wrote: > >> node='http://code.google.com/p/exodus/' >> >> That trailing slash is the default resource. I tend to put it into URLs >> for completeness, but it's not necessary by any means. > > Nod, I do the same for URLs, but this is a URI. E.g.: > http://jabber.org/protocol/muc > > Like I said, minor nit.
I'll randomize them a bit. > I've double-checked the sha-1 in section 5. I'll do that too. > In section 6.2, the verbiage doesn't talk about the construction of the > node attribute. I'd suggest the second paragraph read: > > <blockquote> > The disco#info request is sent to the full JID > (<[EMAIL PROTECTED]/resource>) of the entity that generated the caps > information, with a node that is constructed by concatenating the value > of the node attribute from the c element of the generating entity, the > "#" character, and the value of the ver attribute from the c element of > the generating entity. > </blockquote> > > (or something more readable. :) ) Thanks, suggested text is always appreciated. :) Further wordsmithing yields: *** 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. *** > In the last paragraph of section 6.2, "the client" should probably be > "the receiving client" for clarity. I've made it "the receiving entity" (it doesn't have to be a client) and I've cleaned up similar terminology throughout. > Section 6.3 is really cool. Perhaps because that was your suggestion. :) > 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. > If not, perhaps the JID can > either go in (yet another) attribute, or perhaps as CDATA inside the c > element? Not necessary, I think. > Section 7, second paragraph, "A client MAY query the server using > disco#info", or using the stream feature information from section 6.3. Nod. > 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. *** > Section 10, first paragraph, last sentence might want another clause > that says "however, this will interfere with the directed presence > functionality specified in section 8." Done. > Other than these nits, I'm +1. Great. I'm going to read it over again here, too. The SVN check-in related the foregoing comments is here: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0115.xml?r1=1461&r2=1477 And version 1.5pre11 is here: http://www.xmpp.org/extensions/tmp/xep-0115-1.5.html Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
