[Council] meeting minutes, 2007-08-08

Peter Saint-Andre stpeter at jabber.org
Mon Aug 13 15:26:38 CDT 2007

Kevin Smith wrote:
> Sorry this has been a while coming. My head hasn't stopped aching in
> almost 3 weeks.

Yeah, some of these specs can give you a real headache. :P

> On 8 Aug 2007, at 19:48, Peter Saint-Andre wrote:
>> 2. XEP-0004: Data Forms
> +1

Version 2.9 published.


>> 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:


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.


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?


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/88a2cc1c/attachment.bin 

More information about the Council mailing list