[Council] meeting minutes, 2007-08-08

Kevin Smith kevin at kismith.co.uk
Mon Aug 13 14:21:22 CDT 2007

Sorry this has been a while coming. My head hasn't stopped aching in  
almost 3 weeks.

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


> 3. XEP-0060: Publish-Subscribe

No vote needed.

> 4. XEP-0163: PEP

Previously voted.

> 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.  
I think having the pseudo-random resources in the examples make  
things a bit ugly; do we need to change them? 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?

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. Thinking about it,  
we probably do need to make this compromise, sadly, because the <p>  
would get huge otherwise.

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

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

> 6. XEP-0084: User Avatar

No vote needed.

> 7. ProtoXEP: Persisting Objects via PEP


> 8. ProtoXEP: Private Data via PEP


> 9. ProtoXEP: Getting a User's Attention


> 10. ProtoXEP: Message Moderated Conferences

No vote needed.

> 11. ProtoXEP: Managing Message Moderators in MUC Rooms

No vote needed.

> ProtoXEP: Whiteboard

No vote needed; I agree with the rest of council that this is a  
specific instance of xml document editing.

> 13. ProtoXEP: Portable Import/Export Format for XMPP-IM Servers

This might need some modifications, as described on standards@, but +1.

> 14. ProtoXEP: Component Connections

+1, but I don't really see why it needs to be :server or :client  
namespace. This needs some error examples for hostname binding, I think.

> 15. ProtoXEP: Message Stanza Profiles

That has just taken me several hours. Phew.


Kevin Smith
Psi XMPP client project leader - http://psi-im.org

More information about the Council mailing list