[Council] meeting agenda, 2007-07-11

Peter Saint-Andre stpeter at jabber.org
Wed Jul 11 10:10:45 CDT 2007

Ian Paterson wrote:
> 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

We could change it to recommended. But I think it's safest for now to
remove it. Unfortunately.

> 3. XEP-0212: XMPP Basic Server 2008 - Advance version 0.5 to Draft?
> +1
> 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)

/me nods

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

SSN as recommended seems fine with me.

> So
> what do people think about including XEP-0201 "Best Practices for
> Message Threads" as a compromise?

Is XEP-0201 fully baked yet? If so, is it time to issue a last call on it?

> 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?
> +1
> 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?
> +1
> 10. XEP-0004: Data Forms - Approve version 2.9pre2
> +1
> 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.

Those seem reasonable. After I make those changes we'll probably let
this one lie still for two weeks and vote on it at the next meeting.

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

-1 on the clarifications? I agree that this needs a major revamp.

Speaking of which, I think we should remove the definition of the data
forms media stuff <http://www.xmpp.org/extensions/xep-0158.html#media>
from XEP-0158 and document it in a separate spec. I'd be happy to do that.

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

Bigger issues, but yes we need to clean this up.

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

Any particular reason? Avatars are typically public info. We can always
updated XEP-0184 with that once XEP-0060 is modified. Or hold off on the
Last Call until we make the core pubsub changes.

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



Peter Saint-Andre

-------------- 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/20070711/e79e0b0b/smime.bin

More information about the Council mailing list