Ralph Meijer | 15 Jan 15:08 2016
Picon
Gravatar

Who's coming to FOSDEM / XMPP Summit 19?

Hi all,

Looking at the list of participants at for the upcoming Brusses summit 
at <http://wiki.xmpp.org/web/Summit_19>, I notice that 12 people have 
signed up to attend, so far. In order to plan Summit Lunches and the XSF 
Dinner, I have to know how many people are coming.

If you do plan on attending, please sign up on this page, or drop me a 
line at <xmpp:ralphm <at> ik.nu>. Please do this *as soon as possible* but 
before the end of day (*) 18 January. If you can provide any of the 
items on the gear list, do let me know.

Note that 12 participants is much lower than previous years, and while I 
am sure we can be (more?) productive with this group, we will probably 
need to re-evaluate doing Summits in this style.

Similarly, the list of people in our community planning to attend FOSDEM 
as listed at <http://wiki.xmpp.org/web/FOSDEM_2016> is pretty short. I'm 
going to assume that all people signed up for the Summit (bar Kevin) 
will be at FOSDEM and spend some time at the Realtime Lounge and Devroom.

Cheers,

ralphm

  *) I will be in San Francisco  on that day, so end-of-day UTC-7 is
     fine.
RFC Errata System | 12 Dec 18:11 2015

[Errata Verified] RFC7622 (4560)

The following errata report has been verified for RFC7622,
"Extensible Messaging and Presence Protocol (XMPP): Address Format". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7622&eid=4560

--------------------------------------
Status: Verified
Type: Editorial

Reported by: Peter Saint-Andre <stpeter <at> stpeter.im>
Date Reported: 2015-12-07
Verified by: Barry Leiba (IESG)

Section: 3.5

Original Text
-------------
   | 18| <juliet <at> example.com/ foo>    | Leading space in resourcepart |

Corrected Text
--------------
[nothing]

Notes
-----
Example 18 is wrong because a leading space is currently allowed by RFC 7622 (at least, it is not disallowed
by the OpaqueString profile defined in RFC 7613). It is true that leading and trailing spaces are
disallowed by the Nickname profile, but we do not reference that here. This example should be removed in
(Continue reading)

RFC Errata System | 7 Dec 21:50 2015

[Editorial Errata Reported] RFC7622 (4560)

The following errata report has been submitted for RFC7622,
"Extensible Messaging and Presence Protocol (XMPP): Address Format".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7622&eid=4560

--------------------------------------
Type: Editorial
Reported by: Peter Saint-Andre <stpeter <at> stpeter.im>

Section: 3.5

Original Text
-------------
   | 18| <juliet <at> example.com/ foo>    | Leading space in resourcepart |

Corrected Text
--------------
[nothing]

Notes
-----
Example 18 is wrong because a leading space is currently allowed by RFC 7622 (at least, it is not disallowed
by the OpaqueString profile defined in RFC 7613). It is true that leading and trailing spaces are
disallowed by the Nickname profile, but we do not reference that here. This example should be removed in
any updates to RFC 7622.

Instructions:
-------------
(Continue reading)

RFC Errata System | 14 Nov 20:10 2015

[Editorial Errata Reported] RFC7622 (4534)

The following errata report has been submitted for RFC7622,
"Extensible Messaging and Presence Protocol (XMPP): Address Format".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7622&eid=4534

--------------------------------------
Type: Editorial
Reported by: Sam Whited <swhited <at> atlassian.com>

Section: 3.2.2

Original Text
-------------

   An entity that performs enforcement in XMPP domainpart slots MUST
   prepare a string as described in Section 3.2.1 and MUST also apply
   the normalization, case-mapping, and width-mapping rules defined in
   [RFC5892].

Corrected Text
--------------

   An entity that performs enforcement in XMPP domainpart slots MUST
   prepare a string as described in Section 3.2.1 and MUST also apply
   the normalization, case-mapping, and width-mapping rules defined in
   [RFC5890].

Notes
(Continue reading)

Aditya Divekar | 29 Oct 20:07 2015
Picon

Getting Started

Hi,
I would like to start contributing to swift by taking on some beginner level bugs. Could you please point me in the right direction.
_______________________________________________
xmpp mailing list
xmpp <at> ietf.org
https://www.ietf.org/mailman/listinfo/xmpp
Martin Thomson | 29 Oct 08:08 2015
Picon
Gravatar

Re: New(ish) draft: Secure Messaging in XMPP

On 29 October 2015 at 09:02, Martin Thomson <martin.thomson <at> gmail.com> wrote:
> I don't think that Axolotl is a good model
> for the general use case.

Since Florian asked nicely, here's the text I wrote about a year ago
regarding PFS:

>>>
For a system where the messages are stored, this is largely a
pointless exercise. Destroying the messages is also necessary to
ensure that they cannot be recovered.

We value function over perfect security and consider logging to be a
critical part of a functional chat system.

Furthermore, forward secrecy requires that a round trip between two
parties occurs to establish a properly ephemeral key. This means that
any initial message to any other device either cannot have forward
secrecy, or it cannot include any content. In the latter case, content
could only be carried once the receiving device has replied with their
ephemeral share. (Other systems address this in part by provisioning a
public store with shares ahead of any need for others to use them, but
these systems work poorly in multi-party scenarios.)

In the case where there are multiple agents in a chat - a scenario we
consider to be critical for usability reasons - if any one user agent
is offline, any message encrypted for that agent has to use a key that
can only be unilaterally updated. Messages destined for the offline
agent will necessarily depend on the private keying material on that
agent, which cannot be updated.
<<<

I think that there was a separate note about the value of PFS for some
exchanges.
Adam Roach | 23 Oct 23:18 2015
Gravatar

New(ish) draft: Secure Messaging in XMPP

XMPP folks:

Martin and I put together a proposal for an approach that allows for 
end-to-end encrypted XMPP conversations, including in the presence of 
MUC. Although not a completely implementable spec, this should give a 
good idea about the direction we have in mind:

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00

Anyone interested in this work should give it a read and provide 
feedback. In particular, I'm curious if anyone interested in 
implementing this kind of thing has requirements can't be addressed with 
the high-level approach we're describing.

Thanks!

/a
IESG Secretary | 14 Sep 19:47 2015
Picon

WG Action: Conclusion of Extensible Messaging and Presence Protocol (xmpp)

The Extensible Messaging and Presence Protocol (xmpp) working group in 
the Applications and Real-Time Area has completed its milestones and is 
now concluded. Many thanks to all who have participated, and especially 
to the draft authors.

The mailing list will remain open for related discussion.
Ben Campbell | 12 Sep 19:38 2015

XMPP Completes

Hi,

With the recent approval of the posh and dna drafts, xmpp has completed 
all of it's milestones. The working group will now close. The mailing 
list will remain open in case there is need of further discussion of 
those drafts as they go through the RFC editing process.

I want to thank everyone for the work over the years. The group has been 
around for a long time, and undergone many changes. Kudos to all those 
who stuck around for the ride.

Thanks!

Ben.
RFC Errata System | 12 Sep 19:34 2015

[Errata Held for Document Update] RFC7622 (4470)

The following errata report has been held for document update 
for RFC7622, "Extensible Messaging and Presence Protocol (XMPP): Address Format". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7622&eid=4470

--------------------------------------
Status: Held for Document Update
Type: Editorial

Reported by: Stéphane Bortzmeyer <bortzmeyer+ietf <at> nic.fr>
Date Reported: 2015-09-10
Held by: Ben Campbell (IESG)

Section: 3.5

Original Text
-------------
<king <at> example.com/&#x265A>;

Corrected Text
--------------
<king <at> example.com/&#x265A;>

Notes
-----
Right angle bracket arrived too soon.

--------------------------------------
RFC7622 (draft-ietf-xmpp-6122bis-24)
--------------------------------------
Title               : Extensible Messaging and Presence Protocol (XMPP): Address Format
Publication Date    : September 2015
Author(s)           : P. Saint-Andre
Category            : PROPOSED STANDARD
Source              : Extensible Messaging and Presence Protocol
Area                : Applications and Real-Time
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
xmpp mailing list
xmpp <at> ietf.org
https://www.ietf.org/mailman/listinfo/xmpp
IETF Secretariat | 12 Sep 19:32 2015
Picon

Milestones changed for xmpp WG

Changed milestone "Define a solution for server-to-server connection
reuse.", resolved as "Done".

URL: https://datatracker.ietf.org/wg/xmpp/charter/

Gmane