[Council] meeting minutes, 2007-08-08

[Kevin Smith]

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

+1

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

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

+1

> 8. ProtoXEP: Private Data via PEP

+1

> 9. ProtoXEP: Getting a User's Attention

+1

> 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
+1

That has just taken me several hours. Phew.

/K

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