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.
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
Hi,
On Wed, Nov 9, 2011 at 11:14 PM, Dave Cridland d...@cridland.net 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
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
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
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 d...@cridland.net wrote:
The intent of this is good; something providing similar
Hi,
On Wed, Oct 5, 2011 at 1:55 AM, Kevin Smith ke...@kismith.co.uk 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
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
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 to
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
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, though.
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
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
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,
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 add
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 this to
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 the
17 matches
Mail list logo
