[Standards] XEP-0115 v. 1.5pre10

Joe Hildebrand hildjj at gmail.com
Tue Dec 18 11:26:57 CST 2007


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've double-checked the sha-1 in section 5.

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 (<node at domain.tld/ 
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. :) )

In the last paragraph of section 6.2, "the client" should probably be  
"the receiving client" for clarity.

Section 6.3 is really cool.  Is it always going to be clear what the  
associated JID will be for the stream?  If not, perhaps the JID can  
either go in (yet another) attribute, or perhaps as CDATA inside the c  
element?

Section 7, second paragraph, "A client MAY query the server using  
disco#info", or using the stream feature information from section 6.3.

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).

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."

Other than these nits, I'm +1.

-- 
Joe Hildebrand



More information about the Standards mailing list