[Council] meeting agenda, 2007-07-11

[Ian Paterson]

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

Yes.

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

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

+1

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

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