[Council] meeting agenda, 2007-07-11

Ian Paterson ian.paterson at clientside.co.uk
Wed Jul 11 11:16:44 CDT 2007

Peter Saint-Andre wrote:
> Is XEP-0201 fully baked yet? If so, is it time to issue a last call on it?

Probably not baked yet, as you and Kevin said, SSN is probably a much 
better bet for inclusion in the Intermediate IM Client 2008 XEP.

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

Sorry, what I meant to explain, and thought I typed, was that I think we 
should hold off on another version of this XEP until we complete the 
revamp (not much work). I feel thay way because of the major security 
issue, and because, IMHO, the revamp has already been delayed for far to 

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

Bigger? The new field will be trivial to document. It will still be 
perfectly possible (although NOT RECOMMENDED) to use a 'password' form 

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

To hold off might be best. I'm envisioning a "Personal Publishing" XEP 
which is a profile of XEP-0060 parallel to PEP, that will require 
<preconditions/>. On top of that will be built XEP-0189, XEP-0184 and a 
new iq:private v2 XEP (amoungst others).

- Ian

More information about the Council mailing list