Council discussed this in their meeting this week (as you'll have seen
from the forwarded minutes), and agreed not to publish as a XEP at the
moment.
The overriding concern is that the XSF does not have the expertise or
experience to define what Council believes to be a new security model.
Assumin
On Wed Nov 9 14:46:19 2011, Jehan Pagès wrote:
> For changing passwords, on the other hand, I don't see a need to
change from
> XEP-0077.
I don't know if this is because servers or clients (or both?) do not
implement this part of XEP-0077 but I personally never saw any
client
where I could
On Wed Nov 9 14:46:19 2011, Jehan Pagès wrote:
> We can't do this here. It's not an impossible concept, but the
place to
> define such a standards would be in the IETF's Kitten working
group, not
> here. (In case anyone wonders, Kitten = "Son of Cat"; Cat =
"Common
> Authentication Technol
Hi,
On Wed, Nov 9, 2011 at 11:14 PM, Dave Cridland wrote:
> On Wed Nov 9 13:52:06 2011, Jehan Pagčs wrote:
>>
>> Re-reading a little this topic before passing to council vote, I add
>> my voice to this point too! That's another good reason why ad-hoc
>> commands are probably not adapted. The mor
On Wed Nov 9 13:52:06 2011, Jehan Pagès wrote:
Re-reading a little this topic before passing to council vote, I add
my voice to this point too! That's another good reason why ad-hoc
commands are probably not adapted. The more I think about it, the
less
I think ad-hoc fits password modificatio
Hi,
On Thu, Sep 22, 2011 at 4:03 AM, Alexander Holler wrote:
> Am 21.09.2011 20:10, schrieb Remko Tronçon:
>
>> Putting account management in ad-hoc commands means that we don't
>> expect clients to have a "Change password" button, but instead go
>> through the server provided "Change account set
Hi all,
sorry for the very delayed answer! I won't display any excuse because
I guess you don't care. ;-)
Anyway I'll try to answer the various remarks on the topic.
On Thu, Sep 22, 2011 at 12:53 AM, Dave Cridland wrote:
> The intent of this is good; something providing similar capabilities to
>
Hi,
On Wed, Oct 5, 2011 at 1:55 AM, Kevin Smith wrote:
> Council decided to postpone accepting/rejecting this protoXEP until a
> sense of community opinion had been gathered.
>
> What seem to me like reasonable objections to this approach have been
> given - are there people remaining silent who
On Oct 4, 2011, at 13:44, Dave Cridland wrote:
> On Tue Oct 4 18:07:04 2011, Kim Alvefur wrote:
>> Would it make any sense whatsoever to have account registration at the SASL
>> level?
> Possible, but not something for the XSF to do directly; we could talk to the
> IETF about it of course, tho
On Tue Oct 4 18:07:04 2011, Kim Alvefur wrote:
Would it make any sense whatsoever to have account registration at
the SASL level?
Possible, but not something for the XSF to do directly; we could talk
to the IETF about it of course, though.
My suggestion was just to bypass the whole thing
Would it make any sense whatsoever to have account registration at the SASL
level?
Just a thougt.
- Original message -
> Council decided to postpone accepting/rejecting this protoXEP until a
> sense of community opinion had been gathered.
>
> What seem to me like reasonable objections t
Council decided to postpone accepting/rejecting this protoXEP until a
sense of community opinion had been gathered.
What seem to me like reasonable objections to this approach have been
given - are there people remaining silent who believe this is the
right approach and should be moved onto the st
On Sep 21, 2011, at 13:24, Remko Tronçon wrote:
>> If it's a well-defined FORM_TYPE, a client could do something fancy for the
>> well-defined fields (e.g. {urn:xmpp:acct-mgmt:0:dataforms:update}newpass
>> gets a special strength meter nearby), and an "advanced"
>> button/tab/overlay/etc for t
> If it's a well-defined FORM_TYPE, a client could do something fancy for the
> well-defined fields (e.g. {urn:xmpp:acct-mgmt:0:dataforms:update}newpass gets
> a special strength meter nearby), and an "advanced" button/tab/overlay/etc
> for the non-standard things.
Right, but I always found thi
On Sep 21, 2011, at 12:10, Remko Tronçon wrote:
>> For both account management and registration, using the ad-hoc framework
>> seems most sensible - it would allow us maximum flexibility as well as
>> near-instant deployment.
>
> I don't think registration fits the ad-hoc use case, because it is
Am 21.09.2011 20:10, schrieb Remko Tronçon:
Putting account management in ad-hoc commands means that we don't
expect clients to have a "Change password" button, but instead go
through the server provided "Change account settings" dialog. It takes
away power from the client (it won't be able to a
> For both account management and registration, using the ad-hoc framework
> seems most sensible - it would allow us maximum flexibility as well as
> near-instant deployment.
I don't think registration fits the ad-hoc use case, because it is a
special action outside of the general session flow, wh
On Sep 21, 2011, at 8:53 AM, Dave Cridland wrote:
> Registration does indeed pose a problem - I see three strategies for dealing
> with it:
I think registration is divorce-able from management of existing accounts, and
should be divorced.
I suspect there is little actual demand from deployers
The intent of this is good; something providing similar capabilities
to XEP-0077, but in a consistent manner, seems like a good and
useful thing to be working on.
However, I don't think this is the right approach, to the extent that
I don't think this is fixable. Addressing the issues that
19 matches
Mail list logo
