Thu, 9 Feb 2017 02:05:35 + (UTC)
XMPP Extensions Editor wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Extensible SASL Profile
>
> Abstract: This document describes a replacement for the SASL profile
> documented in RFC 6120 which allows for greater e
On Wed, Feb 8, 2017 at 8:05 PM, XMPP Extensions Editor wrote:
> Title: Extensible SASL Profile
>
> Abstract: This document describes a replacement for the SASL profile
> documented in RFC 6120 which allows for greater extensibility.
Some early feedback about the new SASL profile:
One of the thi
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Extensible SASL Profile
Abstract: This document describes a replacement for the SASL profile documented
in RFC 6120 which allows for greater extensibility.
URL: http://xmpp.org/extensions/inbox/sasl2.html
The council will
On Wed, Feb 8, 2017 at 5:47 PM, Christian Schudt
wrote:
> Aren’t namespaces with a version? I.e. urn:xmpp:hints:0 instead of
> urn:xmpp:hints?
Just by convention (but I agree, it might be nice to have one just in
case a hint ever has to change; although I also think that's
unlikely). That being
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to
> clarify an existing protocol?
Partly.
XEP-0079: Advanced Message Processing already solves the same problem.
dropforward => no-copy
dropstored => no-store
> 2. Does the specification solve the problem s
Version 0.1.0 of XEP-0387 (XMPP Compliance Suites 2017) has been released.
Abstract:
This document defines XMPP protocol compliance levels for 2017.
Changelog: [See revision history] (ssw)
Diff: N/A
URL: http://xmpp.org/extensions/xep-0387.html
_
This message constitutes notice of a Last Call for comments on XEP-0352 (Client
State Indication).
Abstract: This document defines a way for the client to indicate its
active/inactive state.
URL: http://xmpp.org/extensions/xep-0352.html
This Last Call begins today and shall end at the close of
This message constitutes notice of a Last Call for comments on XEP-0334
(Message Processing Hints).
Abstract: This document defines a way to include hints to entities routing or
receiving a message.
URL: http://xmpp.org/extensions/xep-0334.html
This Last Call begins today and shall end at the
This message constitutes notice of a Last Call for comments on XEP-0280
(Message Carbons).
Abstract: In order to keep all IM clients for a user engaged in a conversation,
outbound messages are carbon-copied to all interested resources.
URL: http://xmpp.org/extensions/xep-0280.html
This Last Ca
This message constitutes notice of a Last Call for comments on XEP-0233 (XMPP
Server Registration for use with Kerberos V5).
Abstract: This specification defines the Kerberos principal name of an XMPP
server. It also details a method by which a connecting client can determine
this Kerberos prin
Version 0.1.0 of XEP-0386 (Bind 2.0) has been released.
Abstract: This specification provides a single-request replacement for several
activities an XMPP client needs to do at startup.
Changelog: First draft accepted by the XMPP Council. (XEP Editor: ssw)
Diff: N/A
URL: http://xmpp.org/extensi
Hi all,
Usability of most, if not all, XMPP clients has been subpar compared to similar
commercial software in the area of instant messaging and real-time
communication. At FOSDEM there were some nice talks about the general topic of
usability and design in the Open Source Design devroom [0]. O
On 8 February 2017 at 08:53, Evgeny Khramtsov wrote:
> Wed, 8 Feb 2017 08:19:17 +
> Dave Cridland wrote:
>
>> Right, I understand, and largely agree. I might scribble a draft to
>> address this, by clarifying what we really meant here.
>
> I see also two issues here ;)
>
Yup, I understand wh
On 08.02.2017 21:42, Evgeny Khramtsov wrote:
Wed, 8 Feb 2017 20:06:19 +0100
"Ruslan N. Marchenko" wrote:
RFC restricts nowhere
binding process to this extension
Actually it does, Section 14.4:
14 is a namespace section, so apparently it defines namespace relevant
to the given RFC.
A UR
Wed, 8 Feb 2017 20:06:19 +0100
"Ruslan N. Marchenko" wrote:
> RFC restricts nowhere
> binding process to this extension
Actually it does, Section 14.4:
> A URN sub-namespace for resource binding in the Extensible Messaging
> and Presence Protocol (XMPP) is defined as follows. (This namespace
Allow me to put my two cents
On 08.02.2017 09:53, Evgeny Khramtsov wrote:
Wed, 8 Feb 2017 08:19:17 +
Dave Cridland wrote:
Right, I understand, and largely agree. I might scribble a draft to
address this, by clarifying what we really meant here.
I see also two issues here ;)
1. RFC6120,
On Wed, Feb 8, 2017 at 9:47 AM, Kevin Smith wrote:
> Different use case, I’m afraid. Remote rosters don’t get to do broadcast
> presence.
Ah, yes, that's what we were missing. Makes sense; thanks all.
—Sam
___
Standards mailing list
Info: https://mail
On 8 Feb 2017, at 15:16, Sam Whited wrote:
>
> On Wed, Feb 8, 2017 at 3:32 AM, Steve Kille wrote:
>> 9. It is agreed that MIX Channels will be represented in the roster.
>>
>>
>> 10. It is intended to mark MIX clients in the roster with a server
>> generated annotation, so that MIX clients
Sam,
On Wed, 08 Feb 2017 15:16:00 + (GMT), Sam Whited wrote:
On Wed, Feb 8, 2017 at 3:32 AM, Steve Kille wrote:
9. It is agreed that MIX Channels will be represented in the roster.
10. It is intended to mark MIX clients in the roster with a server
generated annotation, so that MIX cl
On Wed, Feb 8, 2017 at 3:32 AM, Steve Kille wrote:
> 9. It is agreed that MIX Channels will be represented in the roster.
>
>
> 10. It is intended to mark MIX clients in the roster with a server
> generated annotation, so that MIX clients can clearly show MIX channels
> without needing to do di
Hi,
2017-01-18 17:36 GMT+01:00 Sam Whited :
> ## Consider advancing XEP-0233: XMPP Server Registration for use with
> Kerberos V5
>
> - Dave Cridland notes that Mili should probably be an author because she wrote
> a great deal of that one and that he's happy to LC it as well
> - Tobias also is
Hello,
On Wed, Jan 18, 2017 at 10:36:02AM -0600, Sam Whited wrote:
> # 2017-01-18 Council Meeting
>
> Logs: http://logs.xmpp.org/council/2017-01-18#16:01:18
>
>
> ## Roll call
>
> - Tobias (chairing)
> - Sam Whited
> - Dave Cridland
>
> Daniel and Link Mauve sent their apologies.
>
>
> ## M
On Wed, Feb 8, 2017 at 10:29 AM, Dave Cridland wrote:
> On 7 February 2017 at 16:25, Georg Lukas wrote:
>
Also, who gets to make changes? How are those agreed?
>
Council, like all XEPs, not much doubt about it. Right?
> All a XEP is, is simply a document with a process wrapped around it.
>
A
On Tue, Feb 7, 2017 at 5:33 PM, Sam Whited wrote:
> On Tue, Feb 7, 2017 at 10:25 AM, Georg Lukas wrote:
> > Can we make the "Compliance Suite" a stand-alone document that is not an
> > XEP?
>
> There is a lot of process around publishing and updating an XEP. It
> requires discussion, approval fr
On 06-02-17 15:53, Marvin Gülker wrote:
On Mon, Feb 06, 2017 at 03:25:15PM +0300, Evgeny Khramtsov wrote:
I guess that's your opinion? Or where is it stated in the RFC? is a mandatory-to-negotiate
feature (at least if included), thus, clients MUST NOT ignore it.
I tend to agree with this. RFC
This message is to summarize agreements made at the XMPP summit
1. We will take an approach with MIX to provide a core specification into
XEP-0369 and to put extensions in associated XEPs to avoid the core getting
larger than needed. In future a XEP indicating client and server
extensions ne
On 7 February 2017 at 16:25, Georg Lukas wrote:
> Hi,
>
> today the current Compliance Sutie work was discussed in xsf@ and I
> asked again why it needs a new number vs. just updating XEP-0375. This
> resulted in some yak shaving, and an interesting, albeit controversial,
> proposal:
>
> Can we ma
Wed, 8 Feb 2017 08:19:17 +
Dave Cridland wrote:
> Right, I understand, and largely agree. I might scribble a draft to
> address this, by clarifying what we really meant here.
I see also two issues here ;)
1. RFC6120, section 7.1 says:
> After a client authenticates with a server, it MUST b
Right, I understand, and largely agree. I might scribble a draft to address
this, by clarifying what we really meant here.
On 8 Feb 2017 06:30, "Evgeny Khramtsov" wrote:
> Tue, 7 Feb 2017 21:22:17 +
> Dave Cridland wrote:
>
> > On 7 February 2017 at 16:29, Evgeny Khramtsov
> > wrote:
> > >
29 matches
Mail list logo
