[Council] caps (was: Re: meeting minutes, 2007-08-08)

Peter Saint-Andre stpeter at jabber.org
Mon Aug 13 16:01:28 CDT 2007


A few slight changes per Kevin's comments. See here:

http://www.xmpp.org/extensions/tmp/xep-0115-1.4.html

http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0115.xml?r1=1090&r2=1144

/psa


Peter Saint-Andre wrote:

>>> 5. XEP-0115: Entity Capabilities
>> I think I missed the reason for SHOULD and SHOULD NOT becoming should
>> and should not in the 'older clients' blurb, not that I really mind. 
> 
> See here:
> 
> http://tools.ietf.org/html/draft-peterson-informational-normativity
> 
> The capitalized normative terms refer to a protocol itself, not choice
> of protocol or requirements or things of that kind. It's a distinction
> that only a standardization weenie could love.
> 
>> I
>> think having the pseudo-random resources in the examples make things a
>> bit ugly; do we need to change them? 
> 
> No we don't. I made that change experimentally during the discussion of
> server-assigned resources, to see what things would look like. And the
> answer has come back: ugly as sin. :) Will revert.
> 
>> In the service discovery example,
>> Juliet's client sends an iq which includes a 'from'; is this a good
>> idea, or should it be omitted as it was before?
> 
> There's no harm in it, I think, since it's allowed by RFC 3920.
> 
>> "<ext>"
>> Maybe we have to make this compromise because of hash size compared to
>> the length of the old ext strings, but this does lose some amount of the
>> elegance; we can no longer know what a client supports when they remove
>> a plugin without another full disco. 
> 
> Well, not necessarily. It depends on (1) whether you've seen that
> particular plugin in action before and (2) whether you cached the
> relevant hash. But often, yes, you will need to re-disco.
> 
>> Thinking about it, we probably do
>> need to make this compromise, sadly, because the <p> would get huge
>> otherwise.
> 
> Right.
> 
> The consensus seems to be that "ext" is no longer relevant -- everything
> you need to know is in the hash.
> 
>> <node> / <ver>
>> I'd suggest we change node to be some amalgamation of the old node and
>> ver tags. It could, in the future, be useful to be able to identify
>> which implementation of a featureset you're being told about. With the
>> old node and ver you could and with the new one you can't; making node
>> node-ver would allow this.
> 
> So a node would be something like the following?
> 
> http://psi-im.org/caps#0.11
> 
> I don't see any harm in recommending that.
> 
>> "Unless the server optimizations shown later are being used, the client
>> MUST send this with every presence change"
>> We can tighten this up a bit to make clear that even if the server us
>> using the optimisations, a client should still be sending everything.
> 
> Correct. It's not the responsibility of the sending client to determine
> if the server is optimizing. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/council/attachments/20070813/0123432a/attachment-0001.bin 


More information about the Council mailing list