[Council] meeting agenda, 2007-07-11

Ian Paterson ian.paterson at clientside.co.uk
Wed Jul 11 07:09:01 CDT 2007

Peter Saint-Andre wrote:
> Ian, is there something else you want in [XEP-0060] for XEP-0189 purposes?

I don't think so. I should have more time to look at that in the next 
week or so.

> http://www.xmpp.org/council/agendas/2007-07-11.html

2. XEP-0211: XMPP Basic Client 2008 - Advance version 0.5 to Draft?

I agree with Peter, unfortunately we need to remove XEP-0115.

Otherwise, I'm +1

3. XEP-0212: XMPP Basic Server 2008 - Advance version 0.5 to Draft?


4. XEP-0213: XMPP Intermediate IM Client 2008 - Advance version 0.4 to Draft?

+1 (although I hate to see vcard-temp in there, we have to be pragmatic)

It would be nice to see Stanza Session Negotiation in there since that helps us towards e2e. Then again, most clients don't support it yet. So what do people think about including XEP-0201 "Best Practices for Message Threads" as a compromise?

5. XEP-0216: XMPP Intermediate IM Server 2008 - Advance version 0.2 to Draft?

+1 (although I hate to see vcard-temp in there, we have to be pragmatic)

6. XEP-0080: User Geolocation - Approve version 1.4pre3?


7. XEP-0060: Publish-Subscribe - Approve version 1.10pre1?
8. XEP-0163: PEP - Approve version 1.1pre4?

I agree with Peter, we should add the publish-with-preconditions stuff before publishing any revisions.

9. XEP-0108: User Activity - Approve version 1.2pre1?


10. XEP-0004: Data Forms - Approve version 2.9pre2

Can we also specify that:
1. The submittor SHOULD NOT change the values of 'hidden' fields, but it MAY (see XEP-0116)
2. A form submittion MAY include fields that were not included in the form that was received? In that case the receiver MUST ignore any fields that it does not understand.

11. XEP-0077: In-Band Registration - Approve version 2.3pre1?

-1, I think this protocol still needs a major revamp (IIRC I said that in January 2006 too).

I'd like to see us depricate elements like <password/> in favour of forms.

Most importantly, SASL auth does not *require* the server to know the user's password, a hash is sufficient. I strongly believe that we need to encourage that as the standard policy. We need to define and RECOMMEND a new 'hash' form field that allows a client to create an account by sending a hash of their password instead of their actual password. This protects user's passwords (Aunt Tillie uses the same password for many unrelated applications). It also protects server admins from lawsuits should their password files ever become compromised.

12. XEP-0084: User Avatar - Issue Last Call?

+1 I'd like to see this "personal-publishing-based-XEP" include example(s) of the <preconditions/> element.

13. Proto-XEP: Server Dialback - Accept as a XEP?


- Ian

More information about the Council mailing list